transitive-reflexive property paths and resources vs properties

[pfps]

See also ad-freiburg/qlever#2503

Given the following graph:

ex:a ex:b ex:c .

The query

SELECT * WHERE { ?x ex:b* ex:a }

produces a single result, but doesn't

SELECT * WHERE { ?x ex:b* ex:b }

produce no results?

Is this desired? Is there a test for it?

EDIT: As discussed below, the second query does produce a result.

[rubensworks]

This behaviour seems correct to me.

This part of the ZeroOrMorePath definition applies here AFAICS:

Definition: Node set of a graph

The node set of a graph G, nodes(G), is:

nodes(G) = { n | n is an RDF term that is used as a subject or object of a triple of G}

So in this case, since ex:a exists in the collection of subjects, SELECT * WHERE { ?x ex:b* ex:a } produces a result. But ex:b does not exist as a subject, so it does not produce a result.

EDIT: the above is not entirely correct. See @hartig's correction below.

Is this desired? Is there a test for it?

I would suspect there's a test for it, but I'm not sure. (if it is, it's here)

[hartig]

No. This is not correct. The result of the second query consists of one solution mapping as well, namely: m = { ?x -> ex:b }.

The relevant part of the spec is the definition of the evaluation of ZeroOrMorePath. It is the third case in that definition, which simply resorts to the first case and that one is based on the ALP function. In the definition of this function, ALP(x:term, ppe) calls ALP(x:term, ppe, V), which immediately adds x to V.

So, nodes(G) is not relevant here. In fact, it is not even relevant whether the object IRI of that property path pattern is in the queried graph or not. In other words, even when evaluating any of the two queries over the empty graph, the result consists of one solution mapping.

You can try these queries at "General purpose SPARQL processor" of https://sparql.org/ (which is implemented based on Apache Jena). If you don't provide a URL of a data file, the query that you enter is evaluated over the empty graph.

[RobinTF]

@hartig So what you're telling me is that

SELECT * {
  VALUES ?x { <foo> }
  ?x <bar>* ?x
}

does require <foo> to be in node(G), but

SELECT * {
  <foo> <bar>* <foo>
}

doesn't?

[hartig]

@RobinTF indirectly, yes!

But, again, this has nothing to do with Nodes(G), but just with how ZeroOrMorePath has been defined.

Also, just to be clear, even if I am one of the editors of v1.2 (and I have reformulated parts of the spec related to this particular discussion, i.e., parts of the spec to make them more clear), the expected behavior has been introduced in v1.1.

[RobinTF]

@hartig I'm aware that the definition of Nodes(G) is innocent, but it blows my mind that the spec is so inconsistent in that regard. To list another case that's more absurd:

SELECT * {
  <foo> <bar>*/<bar>*/<bar>* <foo>
}

Starting with two slashes the query now becomes equivalent again to my previous example with values. So in my opinion you should consider changing the spec for this particular case.

[hartig]

@RobinTF
Oops. I forgot to elaborate why your first query does indeed require to be in Nodes(G). The reason is that the spec combines the VALUES clause and the property path pattern via a join. The part of the spec related to this is Section 18.3.2.6 Translate Graph Patterns; especially, the case of 'GroupGraphPattern', in combination the case of 'InlineData' (which is how VALUES clauses are represented in the algebraic syntax ).

[hartig]

Edit The following is incorrect, as pointed out by Peter below.

@RobinTF
Oh, wait. Now I notice that your queries have IRIs in both the subject position and the object position of the property path pattern. That's different from the example queries in Peter's queries, and for such cases, Nodes(G) is relevant!

So, yes, for ..

SELECT * {
  <foo> <bar>*/<bar>*/<bar>* <foo>
}

.. the query result consists of a (single) solution mapping only if <foo> is a subject or an object of the graph being queried.

In contrast, for ..

SELECT * {
  <foo> <bar>*/<bar>*/<bar>* ?x
}

.. <foo> is in the result of that query no matter what the queried graph looks like.

(Again, this is nothing new for v1.2 but was already in v1.1)

[pfps]

@hartig Are you sure of the last? Isn't that translated into the join of three path clauses? Two of them are open, and thus use Node, right?

[pfps]

Wouldn't it be cleaner to have an unbound result instead of a result for all the nodes of the graph?

[hartig]

@hartig Are you sure of the last? Isn't that translated into the join of three path clauses? Two of them are open, and thus use Node, right?

Sorry!!! Indeed, you are right for that one! In this case, the spec rewrites the property path pattern into two joins with two fresh variables (for everyone else here, the part of the spec relevant to this point is the third case in the table in Section 18.3.2.4 Translate Property Path Patterns.

[rubensworks]

Starting with two slashes the query now becomes equivalent again to my previous example with values. So in my opinion you should consider changing the spec for this particular case.

I agree the definition feels a bit inconsistent.
But as @hartig noted before, this behaviour was already introduced in 1.1, so I don't think we should introduce a (breaking) change like this for 1.2. The cat's out of the bag at this point.

[RobinTF]

@hartig @rubensworks
In every other case replacing variables with fixed IRIs or literals does restrict the result set even more, but this particular one does suddenly add something to the result?

SELECT * { ?s ?p ?o }

cannot possibly produce fewer elements than

SELECT * { <foo> <bar> <buzz> }

But this doesn't apply to the exact same thing with the empty path?
For all kind of patterns you have the guarantee that if a binding is produced by said pattern that it originates from the dataset, but not in case of the empty path when one term is used on one side.

So it's not "a bit" inconsistent, it violates the basic pattern matching principle SPARQL is built on.

I totally get that for SPARQL 1.1 it is what it is and has been for ages at this point but I disagree that you can't change it for 1.2. At the end of the day SPARQL engine vendors may or may not comply with the standard as they see fit in certain scenarios and the only thing stopping them from adopting a new version of the standard is if the standard mandates anything outrageous that is not feasible to implement reasonably well. And this change would clearly not fall into this category because the code has to already be there for the

SELECT * {
  VALUES ?x { <foo> }
  ?x <bar>* ?x
}

scenario I already mentioned.

So I wouldn't consider this to be a breaking change (which it technically is), but instead a fix to an oversight in the definition of the original standard.

On a closing note: I really appreciate your work on the standard but I'm not happy with this particular instance of it.

[hannahbast]

@hartig @pfps @rubensworks According to https://sparql.org/sparql.html, each of the following eight queries just "copies" the object to ?x. That is, the result is either ex:s or ex:p, no matter whether we execute it on the empty graph or on the one-triple graph ex:s ex:p ex:o, and no matter whether we use a VALUES clause for the object or fix the object.

PREFIX ex: <http://example.org/> SELECT ?x WHERE { ?x ex:p* ex:s }
PREFIX ex: <http://example.org/> SELECT ?x WHERE { ?x ex:p* ex:p }
PREFIX ex: <http://example.org/> SELECT ?x WHERE { VALUES ?o { ex:s } ?x ex:p* ?o }
PREFIX ex: <http://example.org/> SELECT ?x WHERE { VALUES ?o { ex:p } ?x ex:p* ?o }
PREFIX ex: <http://example.org/> SELECT ?x FROM <https://qlever.dev/graphs/one-triple.ttl> WHERE { ?x ex:p* ex:s }
PREFIX ex: <http://example.org/> SELECT ?x FROM <https://qlever.dev/graphs/one-triple.ttl> WHERE { ?x ex:p* ex:p }
PREFIX ex: <http://example.org/> SELECT ?x FROM <https://qlever.dev/graphs/one-triple.ttl> WHERE { VALUES ?o { ex:s } ?x ex:p* ?o }
PREFIX ex: <http://example.org/> SELECT ?x FROM <https://qlever.dev/graphs/one-triple.ttl> WHERE { VALUES ?o { ex:p } ?x ex:p* ?o }

[hannahbast]

And just for completeness, when the object is ex:o and the input graph is ex:s ex:p ex:o, then there are two solutions for ?x, namely ex:o and ex:s, again no matter whether we specify the object via a VALUES clause or directly:

PREFIX ex: <http://example.org/> SELECT ?x FROM <https://qlever.dev/graphs/one-triple.ttl> WHERE { ?x ex:p* ex:o }
PREFIX ex: <http://example.org/> SELECT ?x FROM <https://qlever.dev/graphs/one-triple.ttl> WHERE { VALUES ?o { ex:o } ?x ex:p* ?o }