Bryan Thompson

There is a stopword list. Stop words are highly common words with little semantic value. They are not indexed by search engines. On Mon, Jun 22, 2020 at 01:16 Birk Weiberg birk@users.sourceforge.net wrote: The problem also accoures with other prepositions like "in", "on", "for". reserved words in full text search? https://sourceforge.net/p/bigdata/discussion/676946/thread/f736f344b1/?limit=25#6534 Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/bigdata/discussion/676946/...

That would do it! Bryan On Thu, Aug 22, 2019 at 8:43 AM Joe O'Connor joeoc21@users.sourceforge.net wrote: I had seen that in fact, but similarly my override-xml file did nothing. I managed to solve the problem by decompressing the blazegraph-service.war file, editing the web.xml file directly, and recompressing. Timeout after exactly 10 minutes [Blazegraph Wikidata] Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/bigdata/discussion/676946/ To unsubscribe from...

Did you look at this part of the post? It describes where to create the overrides for the timeouts. https://sourceforge.net/p/bigdata/discussion/676946/thread/d3abb9bf12/#feb4/05e9 A lot of the post is concerned with whether the instance is setup correctly (heap, G1, JVM version, etc.) and what is taking the time. You should also look at that. Sometimes a query has a bad plan which simple takes too long. Sometimes it places too much pressure on the JVM heap. Sometimes it runs out of native memory....

I think that is a great question for the W3C SPARQL mailing list.... We are performing reorderings which are certainly legal for the case where there is no inference. In terms of entailment, our approach certainly assumes that the composition of the BGPs does not change the entailments. But I think this is true for the RDFS+ entailments which Blazegraph supports. Bryan On Tue, Jun 4, 2019 at 7:49 AM Median median89@users.sourceforge.net wrote: sparql 1.1 specification. Section 18.7. https://www.w3.org/TR/sparql11-query/#sparqlBGPExtend...

Can you point to that in the spec? On Tue, Jun 4, 2019 at 02:25 Median median89@users.sourceforge.net wrote: Dear Bryan, thaks for the info. A question comes to my mind: Could SPARQL entailment give rise different results of the aforementioned method of optimization? As entailment is applied to the BGP level, not the join level (according to SPARQL 1.1 specification). Meaning that in query1, the entailment will be applied to answer BGP(TP1), then to answer BGP(TP2), then the results will be joined....

Copying Michael. We do rewrite these patterns quite a bit. In the case you are describing, it looks like we are generating a left-to-right evaluation plan with pipelined join operators. We also have an optimization when there is an OPTIONAL with a single triple pattern. Blazegraph does tend to emphasize non-blocking (pipelined) plans when they correspond with the SPARQL bottom up semantics, primarily to obtain the benefit in terms of time to the first result and to keep down the memory associated...

Yes On Fri, Apr 19, 2019 at 10:21 heendung heendung@users.sourceforge.net wrote: Hi Bryan, I have a quick question abut meaning of the value in goodSet. For example, if I have 3 files(i.e. A.ttl.gz, B.ttl.gz, C.ttl.gz) and the output is {failSet=0,goodSet=3}, does that mean those 3 files were succesfully loaded? Thanks! Time to load Wikidata dump into Blazegraph https://sourceforge.net/p/bigdata/discussion/676946/thread/3e98f2b97e/?limit=25#e369 Sent from sourceforge.net because you indicated interest...

Stas, can you comment on the configuration? Maybe post what wikidata uses and the load times? I will note that HDD vs SDD is a huge difference. They are much slower. On Tue, Apr 16, 2019 at 15:19 heendung heendung@users.sourceforge.net wrote: I am loading Wikidata dump files into Blazegraph, but it seems that the loading takes a lot of times: loading: 847529288 stmts added in 271240.911 secs, rate= 3124, commitLatency=0ms, {failSet=0,goodSet=110} loading: 868123530 stmts added in 284586.467 secs,...