Property path processing compliant with SPARQL1.1?

Hi,
It seems that property paths are problematic when the paths are spread over more than one graph. I wonder whether stardog (5.0.3) is compliant with SPARQL 1.1 in this respect.

The following example demonstrates the issue:

Given a simple data set of quads:

<http://example/a> <http://example/p1> <http://example/b> <http://graph1.example> .
<http://example/b> <http://example/p2> <http://example/c> <http://graph1.example> .	
<http://example/b> <http://example/p3> <http://example/c> <http://graph2.example> .

Note that the first two triples belong two graph1 whereas the last triple belongs to graph2!

Let’s do a query using property sequence path:

prefix : <http://example/>

select *
from <http://graph1.example>
from <http://graph2.example>
where {
  ?a :p1/:p2 ?c .
}

It returns as expected: :a and :b . Note that the involved properties :p1 and :p2 both occur in triples from graph1 only!

Now, the problematic query:

prefix : <http://example/>

select *
from <http://graph1.example>
from <http://graph2.example>
where {
  ?a :p1/:p3 ?c .
}

This returns nothing! Presumably, because :p1 and :p3 can be found only in different graphs.
However, when I cut the sequence path into two pieces I will get the connection again:

prefix : <http://example/>

select *
from <http://graph1.example>
from <http://graph2.example>
where {
  ?a :p1 ?b .
  ?b :p2 ?c .
}

It returns: :a, :b and :c.

To me this is strange, because I would expect that
select ?a ?c { ?a :p1/:p2 ?c } is the same as select ?a ?c { ?a :p1 ?b . ?b :p2 ?c } for any :p1, :p2.

Apparently, this holds in stardog (in SPARQL 1.1?) only when all involved triples are in the same graph. In my opinion it should hold in general, though. Any other opinions?

Best,
Immanuel

Hi Immanuel,

Good question. Now, I’m tempted to give you a very short answer by pointing to 18.1.7 of the spec which says this:

A property path does not span multiple graphs in a dataset.

So no, your two queries aren’t quite equivalent and Stardog does enforce named graph boundaries for property paths.

Unfortunately, I can’t really quite stop here because your query uses FROM clauses (as opposed to FROM NAMED). Those specify the default part of the query dataset (see 13.2). The default part is a single graph which is supposed to be obtained by the RDF Merge operation on all graphs in your FROM clauses. In other words, there should be no distinguished graphs for evaluating your query.

This means the 2nd query should return results, too.

The reason it doesn’t is because Stardog does not merge RDF graphs to obtain the default part of the query dataset in the case of multiple FROM clauses because of performance implications (think of removing duplicate triples, for example).

We recognized this problem for property paths and are working on configuration options to disable the named graphs check consistently for all kinds of path expressions.

Cheers,
Pavel

1 Like

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