3 ms·

Sorry, but this article fails big time: no mention at all of SPARQL. For application developers, having access to general public Knowledge Graphs like DBPedia

Sorry, but this article fails big time: no mention at all of SPARQL. For application developers, having access to general public Knowledge Graphs like DBPedia and WikiData can be a very good resource. While I am also a big fan of more general graph databases like Neo4J, not even mentioning SPARQL is such a HUGE OMISSION that I have to suspect some commercially motivated bias in this article. The decision of which graph data platform to use is not always black and white. Use SPARQL with a RDF/OWL data store or a more general graph data store like Neo4J as appropriate. Learn both technologies.

Garvey 7y ago
I assume it's not mentioned because it's not one of the Query Languages mentioned as part of the standardisation project. 'GQL is an upcoming International Standard language for property graph querying that is currently being created. The idea of a standalone graph query language to complement SQL was raised by ISO SC32/ WG3 members in early 2017, and is echoed in the GQL manifesto of May 2018. GQL supporters aim to develop a rock-solid next-generation declarative graph query language that builds on the foundations of SQL and integrates proven ideas from the existing openCypher, PGQL, GSQL, and G-CORE languages. The proposed SQL:2020 Property Graph Query Extensions already build on these existing languages.' https://www.gqlstandards.org/home https://www.gqlstandards.org/home
cjlm 7y ago
How are DBPedia & WikiData useful for application developers? As a reference or for actual integration into applications?
- staticautomatic 7y ago
  Depending on your domain, they can be super useful, if not indispensable, for Named Entity Recognition.
- virgil_disgr4ce 7y ago
  I use WikiData as a (non-realtime) data source for Swymm.org. I've written a bunch of pretty intense SPARQL queries as such and I agree that it's odd that SPARQL is not mentioned in the post.
tasogare 7y ago
Is there any SPARQL implementation that returns results under 10 seconds on a big dataset? Because, I never found a public SPARQL endpoint that gives remotely acceptable response time.
- bjoernbu 7y ago
  While there may be several things missing for many productive use cases (especially inserts/updates), I think QLever (https://github.com/ad-freiburg/QLever https://github.com/ad-freiburg/QLever) fits that description very well. There's also a public endpoint linked there.
- matteuan 7y ago
  Under 10 seconds on which query? If your query involves big joins over a large distributed data-set there won't be a technology that can do it for you. SPARQL is not the problem, you can write the same queries in Cypher or any other language, you will hit the same performance problems
- tannhaeuser 7y ago
  Of course there are. The SPARQL endpoints open for public access at no cost for the user, and potentially accessed by i-dont-know how many clients concurrently can't be used as benchmarks.
- virgil_disgr4ce 7y ago
  I'm not sure exactly what you mean by implementation here, but many (most?) of the Wikidata examples (on its public endpoint) are very fast, i.e.: https://query.wikidata.org/#%23Cats%0ASELECT%20%3Fitem%20%3FitemLabel%20%0AWHERE%20%0A%7B%0A%20%20%3Fitem%20wdt%3AP31%20wd%3AQ146.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D https://query.wikidata.org/#%23Cats%0ASELECT%20%3Fitem%20%3F...
- p_l 7y ago
  Someone already mentioned that public endpoints aren't good benchmarks. But there are many performant SPARQL-enabled databases (back when I wrote my Master's in 2014, that even included Oracle), and they are indeed quite performant - though there are details like batch/realtime materialization and the like. In my experience, AllegroGraph was pretty fast enough (apparently someone even uses it now to translate between HL7 schemas of multiple providers in USA)
tannhaeuser 7y ago
I agree that SPARQL must be considered, and so must Datalog and Prolog. Idk but I'm starting to believe that new-fangled standardization efforts (if you want to call those that) are starting over from scratch and actively avoid looking at prior art as a generation thing. I mean I don't know the people behind gql but I can get that younger devs think there's absolutely no reason that 1985-2010ers had all the fun. Though I could see why someone wouldn't like SPARQL and RDF, with its bulk reuse of other W3C and TBL concepts such as URLs, resulting in atom and predicate names verbosely and pointlessly beginning with "http://" http://".

Garvey 7y ago

I assume it's not mentioned because it's not one of the Query Languages mentioned as part of the standardisation project. 'GQL is an upcoming International Standard language for property graph querying that is currently being created. The idea of a standalone graph query language to complement SQL was raised by ISO SC32/ WG3 members in early 2017, and is echoed in the GQL manifesto of May 2018. GQL supporters aim to develop a rock-solid next-generation declarative graph query language that builds on the foundations of SQL and integrates proven ideas from the existing openCypher, PGQL, GSQL, and G-CORE languages. The proposed SQL:2020 Property Graph Query Extensions already build on these existing languages.' https://www.gqlstandards.org/home https://www.gqlstandards.org/home

cjlm 7y ago

How are DBPedia & WikiData useful for application developers? As a reference or for actual integration into applications?

staticautomatic 7y ago
Depending on your domain, they can be super useful, if not indispensable, for Named Entity Recognition.
virgil_disgr4ce 7y ago
I use WikiData as a (non-realtime) data source for Swymm.org. I've written a bunch of pretty intense SPARQL queries as such and I agree that it's odd that SPARQL is not mentioned in the post.

tasogare 7y ago

Is there any SPARQL implementation that returns results under 10 seconds on a big dataset? Because, I never found a public SPARQL endpoint that gives remotely acceptable response time.

bjoernbu 7y ago
While there may be several things missing for many productive use cases (especially inserts/updates), I think QLever (https://github.com/ad-freiburg/QLever https://github.com/ad-freiburg/QLever) fits that description very well. There's also a public endpoint linked there.
matteuan 7y ago
Under 10 seconds on which query? If your query involves big joins over a large distributed data-set there won't be a technology that can do it for you. SPARQL is not the problem, you can write the same queries in Cypher or any other language, you will hit the same performance problems
tannhaeuser 7y ago
Of course there are. The SPARQL endpoints open for public access at no cost for the user, and potentially accessed by i-dont-know how many clients concurrently can't be used as benchmarks.
virgil_disgr4ce 7y ago
I'm not sure exactly what you mean by implementation here, but many (most?) of the Wikidata examples (on its public endpoint) are very fast, i.e.: https://query.wikidata.org/#%23Cats%0ASELECT%20%3Fitem%20%3FitemLabel%20%0AWHERE%20%0A%7B%0A%20%20%3Fitem%20wdt%3AP31%20wd%3AQ146.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D https://query.wikidata.org/#%23Cats%0ASELECT%20%3Fitem%20%3F...
p_l 7y ago
Someone already mentioned that public endpoints aren't good benchmarks. But there are many performant SPARQL-enabled databases (back when I wrote my Master's in 2014, that even included Oracle), and they are indeed quite performant - though there are details like batch/realtime materialization and the like. In my experience, AllegroGraph was pretty fast enough (apparently someone even uses it now to translate between HL7 schemas of multiple providers in USA)

tannhaeuser 7y ago

I agree that SPARQL must be considered, and so must Datalog and Prolog. Idk but I'm starting to believe that new-fangled standardization efforts (if you want to call those that) are starting over from scratch and actively avoid looking at prior art as a generation thing. I mean I don't know the people behind gql but I can get that younger devs think there's absolutely no reason that 1985-2010ers had all the fun. Though I could see why someone wouldn't like SPARQL and RDF, with its bulk reuse of other W3C and TBL concepts such as URLs, resulting in atom and predicate names verbosely and pointlessly beginning with "http://" http://".