RDF Dataset (trig) and Turtle (ttl)

Support
1

Hello Everyone,

I have a dataset that I curate with others online. Once upon a time, I used Turtle to store this. However, it was slightly clunky in the sense that I wanted to segregate things into their own namespaces but keep links between the various things. I thought that Named Graphs and TRiG would help me do this. So, I converted my Turtle files into TRiG files. For personal reasons as sadly this is not my day job, I have not had the time to get the time to test out the search capabilities with Stardog and TRiG.

So tonight I had some time and a nudge from another person who wanted to use Stardog to search the database. I got everything up and running with the latest Stardog which was something that I was looking forward to (and I have to say working with Stardog Studio is very nice and slick). I loaded the TRiG files form the above git repo and tried to do this query with reasoning enabled and SameAs on Full:

prefix foaf: <http://xmlns.com/foaf/0.1/>
prefix rel: <http://purl.org/vocab/relationship/>
prefix irishRel: <http://example.com/earlyIrishRelationship.ttl#>
prefix owl: <http://www.w3.org/2002/07/owl#>

select ?id where {
    graph ?g {
        ?id rel:ancestorOf <http://example.com/LU/de_genelogia_con_culaind.trig#CĂșCulaind>.
    }
}

I was expecting a large result set as there should have been many ancestors for this particular person. What I got was 1 result. The result happened to be the parent (http://example.com/LU/de_genelogia_con_culaind.trig#Soaldaim-4d4d44a4) which is kind of correct but not at all what I had expected. After playing around with some of the database settings (such as SameAs and query all graphs), I decided to cut the problem down to just one file (de_genelogia_con_culaind.trig) and converted it from TRiG back to Turtle (thus removing the named graph) and loaded that into a separate database for comparison. Then I ran with SameAs full and reasoning enabled the below:

prefix foaf: <http://xmlns.com/foaf/0.1/>
prefix rel: <http://purl.org/vocab/relationship/>
prefix irishRel: <http://example.com/earlyIrishRelationship.ttl#>
prefix owl: <http://www.w3.org/2002/07/owl#>

select ?id  where {
        ?id rel:ancestorOf <http://example.com/LU/de_genelogia_con_culaind.trig#CĂșCulaind>.
    }

This time I received 43 results with the expected chaining of ancestors. I am slightly relieved that I was able to get the results that I was looking for in a cut down version. However, I still wondering how reasoning and named graphs interact? Also, have I misunderstood named graphs entirely so that I will need to remove them from the project to make the reasoning work as I had expected it to work?

I am happy to share my database if need be.

Thank you very much in advance.

2

Your graph query is only going to return results where ?g is bound, so anything in the default graph would not be considered, nor would the results span multiple graphs. What you might want to try is setting query.all.graphs=true in your metadata, or running:

select ?id
from <tag:stardog:api:context:all>
where { }
1 Like
3

Hi Stephen,

Thank you very much for the answer. I did attempt to use query.all.graphs=true but I did not have success with that. I will try your query when I get home tonight. Can I ask a further question, could I use from named with all the graphs I want to query and remove graph ?g from the query?

4

You can indeed do this.

1 Like
5

Hi Christopher,

A minor correction: you can drop graph ?g if you enumerate your graphs using FROM, not FROM NAMED. In SPARQL the query dataset has two parts: the default scope and the named scope. The former is specified using FROM and the latter using FROM NAMED. Scans outside of a graph block match data in the graphs in the default scope, and scans within a graph block match data in the graphs in the named scope.

You can read more about this in SPARQL 1.1 Query Language

Let us know if you have further questions, this part of the spec isn't exactly obvious.

Cheers,
Pavel

1 Like
6

Hi Pavel,

Thank you for that! I was just re-reading that section as your response popped up. Yes, I agree it is not exactly obvious. I will get back to you when I have more information. Thank you again!

7

Thanks to Stephen and Pavel for their answers. I believe this is solved but if anyone ever has the same problems that I did, here is my understanding of it (others can, of course, correct me).

When you are working with Named Graphs, you will need to reference these in some way. The "from" construct basically says: "pull this graph named here into the default graph then run the query over that plus anything in the default graph". The "from named" construct basically says: "this graph will be used in the query below in the graph ?g { } construct". You can use the two together while I am not quite sure what will happen, the ones in the "from" construct will get pulled into the default graph and can be searched for outside of the "graph ?g { }" construct. Everything else will need to be referenced inside the "graph ?g { }" construct and will need to be explicitly named as in side the scope of the query.

Hopefully, that is about right.

Thanks!

8

Yes, this is basically correct except of the "plus anything in the default graph" part. When you use "FROM", your default graph is the union of the graphs in the FROM statements. I.e. the FROM statements define what your default graph is.

Best,
Pavel

1 Like
9

And if you've got query.all.graphs set to true FROM NAMED changes what the default graph is. I guess it's more like query all defined named graphs.

I've always found FROM/FROM NAMED to be somewhat more complicated than it first appears. It's not that they're complicated on their own but there are a lot of combinations especially when you add in query.named.graphs. It's also a little strange that there isn't a standard name for the default graph so if you use FROM there's no standard way to refer to what was in the default graph. I know Stardog has a name for it but as far as the standard goes it's like the default graph just disappears or maybe I'm missing something.

10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.