0

My data is partitioned using named graphs. One graph contains my ontology and human-readable labels for classes. The data in turn is divided up into a number of graphs, ex:data1, ex:data2, ... ex:data5000.

Now I wish to query each of the data graphs independently, while using the labels from the ontologies. First I thought this would be trivial but then I found that scoping in SPARQL can be a bit confusing. As a simple example:

Select all instances with their respective instance label. Also retrieve the optional class associated with each instance and the class label from the ontology.

If the scope of class stretched across both groups I would expect the following query to do the trick:

SELECT ?instance ?instanceLabel ?class ?classLabel
WHERE {
  GRAPH ?data {
    ?instance rdfs:label ?instanceLabel .
    OPTIONAL { ?instance a ?class }
  }

  GRAPH <http://myontology> {
    OPTIONAL {
      ?class rdfs:label ?classLabel
    }
  }
}

If the class is bound the result will be what I wanted, since the two groups are joined; however, due to scoping ?class can bind to anything in the ontology if its not bound in the first group.

The query I'm writing has about 15 similar optional fields (terribly expensive join...). When I tried re-writing with UNION it quickly became quite unwieldy due to the size of the original query. I've also tried nesting queries but that gives me the same issue with scoping. Is there anyone who has some SPARQL-trick up their sleeve that I've overlooked? Any suggestions on how to approach this would be appreciated.

Stanislav Kralin
  • 11,070
  • 4
  • 35
  • 58
Robin Keskisarkka
  • 877
  • 8
  • 18
  • Have you tried `OPTIONAL { GRAPH` instead of `GRAPH { OPTIONAL`? Or you can merge everything into your default graph using `FROM` (not `FROM NAMED`). – Stanislav Kralin Jun 09 '17 at 15:30
  • Stanislav is right, use `SELECT ... FROM WHERE` and then the triple patterns without the `GRAPH` keyword. – UninformedUser Jun 09 '17 at 19:25
  • Merging the graphs into the default graph has two unfortunate side-effects: 1) I can no longer data advantage of how my data is partitioned (with considerable loss in query performance), and 2) the data graphs may not be consistent (i.e. they may say the different things about the same resource) and may return results that are not in the original data. `OPTIONAL { GRAPH` for the ontology part is a good idea and I'll give it a try, but from my understanding of variable scoping the result should be the same. – Robin Keskisarkka Jun 12 '17 at 07:02
  • With `OPTIONAL { GRAPH` the variable scope is still not the desired one (they exist as separate groups). I've tried various variations, e.g. adding the ontology as the default graph, but as soon as I add the optional group to match the label the final join of the results will be incorrect. – Robin Keskisarkka Jun 12 '17 at 07:52

0 Answers0