Re: [Wikidata] Wikidata query performance paper

On 07.08.2016 22:58, Stas Malyshev wrote: Hi! the area for a long time). I guess the more difficult question then, is, which RDF/SPARQL implementation to choose (since any such implementation should cover as least points 1, 2 and 4 in a similar way), which in turn reduces down to the distinguis

Re: [Wikidata] Wikidata query performance paper

Hey Scott, While I'm not sure I can help with the details of the specific example you are mentioning, but the general area you are in -- dealing with answering questions posed in natural language -- is called "Question Answering". When dealing with data in an RDF format (as per Wikidata), th

Re: [Wikidata] Wikidata query performance paper

Thanks, Aidan, Stas and Wikidatans, Thanks for the feedback. While I'm not yet a SQL/SPARQL programmer, I wonder if one could make each word in the question concrete, a Qidentifier, and with rank-able outcomes, create Wikidata Q-items/identifiers with attributes possibly for each MIT OCW course i

Re: [Wikidata] Wikidata query performance paper

Hey Scott, On 07-08-2016 16:15, Info WorldUniversity wrote: Hi Aidan, Markus, Daniel and Wikidatans, As an emergence out of this conversation on Wikidata query performance, and re cc World University and School/Wikidata, as a theoretical challenge, how would you suggest coding WUaS/Wikidata ini

Re: [Wikidata] Wikidata query performance paper

Hi! > the area for a long time). I guess the more difficult question then, is, > which RDF/SPARQL implementation to choose (since any such implementation > should cover as least points 1, 2 and 4 in a similar way), which in turn > reduces down to the distinguishing questions of performance, licens

Re: [Wikidata] Wikidata query performance paper

Hi Aidan, Markus, Daniel and Wikidatans, As an emergence out of this conversation on Wikidata query performance, and re cc World University and School/Wikidata, as a theoretical challenge, how would you suggest coding WUaS/Wikidata initially to be able to answer this question - "What are most impt

Re: [Wikidata] Wikidata query performance paper

Hey Daniel, On 07-08-2016 7:03, Daniel Kinzler wrote: Hi Aidan! Thank you for this very interesting research! Query performance was of course on of the key factors for selecting the technology to use for the query services. However, it was only one among several more. The Wikidata use case is

Re: [Wikidata] Wikidata query performance paper

Hi Aidan! Thank you for this very interesting research! Query performance was of course on of the key factors for selecting the technology to use for the query services. However, it was only one among several more. The Wikidata use case is different from most common scenarios in some ways, for in

Re: [Wikidata] Wikidata query performance paper

On 06-08-2016 18:48, Stas Malyshev wrote: Hi! There's a brief summary in the paper of the models used. In terms of all the "gory" details of how everything was generated, (hopefully) all of the relevant details supporting the paper should be available here: http://users.dcc.uchile.cl/~dherna

Re: [Wikidata] Wikidata query performance paper

Hi! > There's a brief summary in the paper of the models used. In terms of all > the "gory" details of how everything was generated, (hopefully) all of > the relevant details supporting the paper should be available here: > > http://users.dcc.uchile.cl/~dhernand/wquery/ Yes, the gory part is wha

Re: [Wikidata] Wikidata query performance paper

On 06-08-2016 17:56, Stas Malyshev wrote: Hi! On a side note, the results we presented for BlazeGraph could improve dramatically if one could isolate queries that timed out. Once one query in a sequence timed-out (we used server-side timeouts), we observed that a run of queries would then timeo

Re: [Wikidata] Wikidata query performance paper

Hi Stas, [I'm sorry, I just realised this email was mysteriously sent before it was finished. I'll respond in a moment to your other mail.] On 06-08-2016 17:38, Stas Malyshev wrote: Hi! The paper was recently accepted for presentation at the International Semantic Web Conference (ISWC) 2016

Re: [Wikidata] Wikidata query performance paper

Hi! > On a side note, the results we presented for BlazeGraph could improve > dramatically if one could isolate queries that timed out. Once one query > in a sequence timed-out (we used server-side timeouts), we observed that > a run of queries would then timeout, possibly a locking problem or Co

Re: [Wikidata] Wikidata query performance paper

Hi! > The paper was recently accepted for presentation at the International > Semantic Web Conference (ISWC) 2016. A pre-print is available here: > > http://aidanhogan.com/docs/wikidata-sparql-relational-graph.pdf Thank you for the link! It would be interesting to see actual data representations

Re: [Wikidata] Wikidata query performance paper

Hey Markus, On 06-08-2016 15:29, Markus Kroetzsch wrote: Hi Aidan, Thanks, very interesting, though I have not read the details yet. I wonder if you have compared the actual query results you got from the different stores. As far as I know, Neo4J actually uses a very idiosyncratic query semant

Re: [Wikidata] Wikidata query performance paper

Hi Aidan, Thanks, very interesting, though I have not read the details yet. I wonder if you have compared the actual query results you got from the different stores. As far as I know, Neo4J actually uses a very idiosyncratic query semantics that is neither compatible with SPARQL (not even on

[Wikidata] Wikidata query performance paper

Hey all, Recently we wrote a paper discussing the query performance for Wikidata, comparing different possible representations of the knowledge-base in Postgres (a relational database), Neo4J (a graph database), Virtuoso (a SPARQL database) and BlazeGraph (the SPARQL database currently in use)