
Querying an RDF triplestore using SPARQL and Relational pipes - xkucf03
https://relational-pipes.globalcode.info/v_0/examples-rdf-sparql.xhtml
======
matteuan
For research, I created experimental RDF storage on top of Parquet and Apache
Spark for querying big graphs[1]. It converts the RDF graph in a sort of
property graph, where we have a row for each entity and where the columns are
the all possible properties. The trick is to use a columnar format with the
proper encoding (in our case Parquet), to solve the problem of having a lot of
columns and a huge NULLs space. With this representation we can eliminate
costly joins for most of the common queries, but also reduce the size of the
necessary ones.

[1] PRoST [https://github.com/tf-dbis-uni-
freiburg/PRoST](https://github.com/tf-dbis-uni-freiburg/PRoST)

------
abbe98
Wikidata has a great SPARQL editor with plenty of examples and built in
visualizations:

[https://query.wikidata.org/](https://query.wikidata.org/)

~~~
pastage
My experience is that it's a opaque query tool and the wikidata editing
process does nothing to make it easier. Maybe if you know the ins and outs of
your data and at least a basic understanding of the query language.

------
melvinroest
This is an awesome post! I'll be rereading this a couple of times ;-)

> Several ways of connecting to an RDF triplestore

There is another way to connect to an RDF triple store [1]. It's done by a
company called Triply.

Triply made a product that is basically a GUI that allows you to host RDF data
and use SPARQL to query it. You can also query other public datasets [2].
Currently, it's a B2B offering only, but there is a consumer version in the
works. I wouldn't know when it comes out.

For now, you can try out the SPARQL querying feature on public datasets [2].

Disclaimer: I work there recently, this post is my own opinion, not of Triply.

[1] That uses Virtuoso or Jena under the hood.

[2] This example uses DBPedia:
[https://triplydb.com/wikimedia/dbpedia/sparql/dbpedia](https://triplydb.com/wikimedia/dbpedia/sparql/dbpedia)

------
f6v
I was wondering if there’re use cases for this in the real world where
relational database doesn’t cut it?

~~~
etimberg
I work in the energy space. A relatively common format for information
exchange is the Common Information Model ("CIM")[1] which is usually
serialized as RDF XML documents.

In Europe, this format is used as the standard data model for transmission
system operators (TSOs) to share network information needed to run the Europe
wide electrical grid. ENTSO-E [2] publishes a set of RDFS profiles that more
tightly scope the data model to their use cases. [3]

With that use case in mind, why would an RDF database be useful in this case:
data size. It's quite easy to get into millions of objects in the data graph
for a single distribution feeder. A large utility might have thousands of such
feeders, plus associated sub-transmission & transmission infrastructure (the
hierarchy is nicely shown in [4]).

This can be represented in a relational database, but a lot of the queries
start to become recursive. If object A connects to object B which connects to
object C, and you want to query everything connected to A, you don't know that
C exists until you've found object B.

Refs:

1\.
[https://en.wikipedia.org/wiki/Common_Information_Model_(elec...](https://en.wikipedia.org/wiki/Common_Information_Model_\(electricity\))

2\.
[https://en.wikipedia.org/wiki/European_Network_of_Transmissi...](https://en.wikipedia.org/wiki/European_Network_of_Transmission_System_Operators_for_Electricity)

3\. [https://cgmes.github.io/](https://cgmes.github.io/)

4\.
[https://en.wikipedia.org/wiki/Electric_power_distribution#/m...](https://en.wikipedia.org/wiki/Electric_power_distribution#/media/File:Electricity_Grid_Schematic_English.svg)

~~~
zozbot234
> This can be represented in a relational database, but a lot of the queries
> start to become recursive.

Recursive queries are natively supported in SQL, via Common Table Expression
(CTE's). It's not like a triplestore is doing anything different underneath.

