w3c / rdf-star

RDF-star specification
https://w3c.github.io/rdf-star/
Other
120 stars 23 forks source link

SPARQL-Star and Property Paths: how to bind RDF triples from path to nested triples of RDF-Star triples? #248

Open versant2612 opened 2 years ago

versant2612 commented 2 years ago

SPARQL property paths only return the start and end nodes of a path and do not allow variables in property path expressions. SPARQL property paths don't return intermediate nodes neither path triples. SPARQL property paths cannot retrieve and naturally represented a path in the tabular result format of SPARQL.

Considering RDF-Star and SPARQL-Star current specifications, is it possible to bind the RDF triples from a property path query to nested triples of RDF-Star triples?

For example

SELECT ?since ?t WHERE { ns:p3 ns:FRIENDS_OF+ ns:p2 AS path (?s ?p ?o) <<?s ?p ?o>> ns:date_of_start ?since. BIND(<<?s ?p ?o>> AS ?t) FILTER (?since > 2016) . }

Similar to the Cypher query bellow

WITH 2016 AS since MATCH rels= (p1:Person) - [:FRIENDS_OF*1..2]->(p2:Person) WHERE ALL(k1 in relationships(rels) WHERE k1.date_of_start > since) RETURN rels;

pchampin commented 2 years ago

Interesting use-case. Actually, I would bind this even more elegant if AS PATH expected a single variable, bound with quoted triples:

SELECT ?since ?t
WHERE {
    ns:p3 ns:FRIENDS_OF+ ns:p2 AS PATH ?t
    ?t ns:date_of_start ?since.
    FILTER (?since > 2016) .
}

If the specific components of ?t are required, one can still use the SUBJECT, PREDICATE and OBJECT functions introduced in SPARQL-star.

hartig commented 2 years ago

I'm confused. What is AS PATH?

That's not part of SPARQL. So, it is also not something to be expected in the current SPARQL-star spec, right? Or am I missing something?

pchampin commented 2 years ago

my understanding is that @versant2612 is proposing AS PATH as a future extension of SPARQL-star, for capturing all the triples matched by a property path.

hartig commented 2 years ago

If that's the case, then I think this is something broader (read: for SPARQL in general, not just for SPARQL-star). It would require an extension of the notion of solution mappings with a notion of paths as possible values (e.g., for the variable ?p in the example). Such things have been considered in the research literature. However, after extending the notion of solution mappings in such a way, a follow-up issue then might be that paths may have to be added to the data model as first class citizens; otherwise, how would such solution mappings be handled in CONSTRUCT queries? Note that all of these questions are not really about RDF-star and SPARQL-star but they are on the level of RDF and SPARQL.

versant2612 commented 2 years ago

Yes @pchampin and @hartig, I was wondering about a future extension of SPARQL Property Paths with this hypothetical example BUT My doubt is how to bind the RDF triples from a property path query to nested triples of RDF-Star triples considering that I need to filter these RDF triples based on their meta information like time or level of confidence or source.

SELECT ?since ?t WHERE { ns:p3 ns:FRIENDS_OF+ ns:p2 AS PATH ?t ?t ns:date_of_start ?since. FILTER (?since > 2016) . }

hartig commented 2 years ago

Without defining what your AS PATH is supposed to mean, and in particular, what kind of thing it may assign to variable ?t, it doesn't make much sense to talk about anything else that uses ?t.

afs commented 2 years ago

It isn't possible today.

Sketch/personal opinion:

SPARQL would be extended with a new type "path" in the data model. RDF terms, and RDF-star- terms are such types. Then, it is natural to extend SPARQL(-star) for assigning them to variables and having them in results. It would also naturally follow to have functions on paths.

Another approach is to have lists in the SPARQL data model and use theses for paths rather than paths directly.

There are going to be practical considerations. All the current elements RDF-terms are naturally "small" in some informal sense whereas paths/list might be large. This is more obvious with the nearby issue is adding graphs in the same style (c.f. N3 formulae).

It also requires both servers and client libraries to change.

Another nearby issue: variables in paths: https://github.com/w3c/sparql-12/issues/65