Allow use of variables in property paths

[jaw111]

Why?

It would be useful to be able to find how resources are related by allowing use of variables in property path syntax.

Previous work

not known

Proposed solution

Extend the syntax to allow use of variables in paths:

?s foaf:knows/?p/a foaf:Person .

Whilst above could also be achieved without property paths, where this would come in useful is to match arbitrary length paths:

[ a foaf:Person ] ?p+ [ a foaf:Person ] .
?s foaf:knows/?p? [ a foaf:Person ] .

Considerations for backward compatibility

not known

[TallTed]

There is a lot of gut appeal to this idea.

However, it's a performance (if not a server) killer, especially but not only with the potentially infinite "arbitrary length" paths.

+ is problematic at best. The syntactic sugar of earlier property path drafts, which allowed for upper limits of such path expansion (e.g., elt{n,m}, elt{n}, elt{,n}), is much preferred to the currently required manual repetition.

So -- while I very much like the idea of variables in property paths, I think it must accompany a shift toward the elt{n,m}, elt{n}, elt{n,}, elt{,n} -- and may require some limits be placed on what property path operators can be used with variables.

[PaulWarrenOU]

I wonder about the use case. In '?p+', I assume we are looking for a chain of identical predicates (which bind to ?p). A more common use case might be to look for any unbounded chain - i.e. with a mixture of predicates.

[ericprud]

If you exclude unbounded max cardinality paths, I don't think this changes the expressivity of SPARQL and doesn't change the complexity/performance. For example, ?s foaf:knows/?p/a foaf:Person . =

?s foaf:knows [
  ?p [ a foaf:Person ]
] .

I think you only have to worry about '?p+' and '?p*'. If you exclude ?p{n,x}, you duck two tough questions; 1. @PaulWarrenOU's issue about whether it has a homogeneous binding, and if if not, 2. how to make sense of a result set where the different bindings of ?p for a single path traversal are spread () across multiple solutions.

Requiring unary cardinality does not address @jaw111 or @PaulWarrenOU's desire to search arbitrary paths but does does provide a tractable baseline.

[versant2612]

Recently I read a paper that introduced Extended Property Paths (EPPs), which allows to capture in a succinct way a larger class of navigational queries than the current navigational core of SPARQL 1.1. They used _o to denote the object and _p the predicate of the last traversed triple for Tests operations and presented other operations such as Path Difference, Path Conjunction, Arbitrary Path Length with Tests, Path Repetitions.

Fionda, V., Pirrò, G., & Consens, M.P. (2019). Querying knowledge graphs with extended property paths. Semantic Web, 10, 1127-1168.

I thought that, besides _o and _p, there should also be possible to reference the hole triple as _t in order to bind RDF triples from path to nested triples of RDF-Star triples.

[TallTed]

Making life easier for anyone else curious, here is a PDF of the "Querying knowledge graphs with extended property paths" paper discussed above.

[TomT0m]

One usecase may be the use of subproperties in a path. In Wikidata for example there are discussions on whether or not it is possible to do subproperties of "parent" if they are an open list of subproperties, with property paths.

If we have "mother / father / wathever" subproperties of "parent", how can we express

?person [?p :subproperty of :parent]+ ?personancester

to get all the ancesters whatever the property used robustly if some properties are added ?

More generally it seem that the Wikidata community has expressed the desire to use subproperties, and it's not really something that is easy to use in sparql, you have to use a variable for the property, which makes it unusable in paths. In particular there are several properties that are subproperties of "instance of" https://w.wiki/9$qC or "subclass of" https://w.wiki/9$qE subproperties.

This is a discussion in which the community desire appears https://www.wikidata.org/wiki/Wikidata:Property_proposal/term_in_higher_taxon

It's on the over hand a common pattern to use a path "subclass of*/instance of" to get all the instances of a class, including its subclasses, so both are incompatibles and this is an issue for the Wikidata community desires in modelling.

(My personal opinion of this is that community may be misguided on this but it does not change the community desires)