Querying nested quoted triples at an unknown depth

[rubensworks]

I'm opening this issue because I noticed that SPARQL-star doesn't offer a way to handle queries over nested quoted triples at an unknown depth.

Let's take the following dataset as an example:

:Alice :says << :Bob :says << :Carol :says << :Violets :haveColor :Blue >> >> >>
:Alice :says << :Bob :says << :Violets :haveColor :Yellow >> >>
:Alice :says << :Violets :haveColor :Red >>

Unless I'm missing something, there is no way to query all colors of :Violet,
aside from taking the union of quoted triple patterns at different hardcoded depths.

This could be solved by providing a similar syntax to property paths,
but instead of defining paths of predicates between triples,
it would define paths between predicates while going deeper inside quoted triples.
For example, such a query could look like:

:Alice :says*' << :Violets :haveColor ?color >>

I'm opening this issue mainly to discuss whether or not we need and want to support such functionality in SPARQL.
The proposed syntax above and precise solution to this problem is therefore not important (yet).
This example is purely fictional, and I have no indications yet whether or not this case often occurs in practise.

[hartig]

Your observation is right. I am afraid, however, that trying to add such a functionality is a rabbit hole. Assuming we would define support for your particular example, someone may come along and want the same but with a restriction to specific subjects of quoted triples along the way, or concatenations of predicates (e.g., (says/believes)*), or alternating between going into a quoted triple in the subject and then going into a quoted triple in the object, etc.

[TallTed]

I guarantee real-world scenarios where someone will want (need) to query for all occurrences of :Violets, whether in asserted triples, quoted triples, nested quoted triples, or otherwise, and whether Subject or Object in any such case.

Such results would allow such a querent to adjust their confidence in assertions made by asserters who (in)accurately (as judged by this querent) describe :Violets, whether they assert :haveColor :violet, :taxonomy :plant, :taxonomy :animal, etc.

[gkellogg]

Eventually, there should be entailments which flatten a graph with recursive quoted triples to being only asserted triples, at which point it would be available to a pattern such as {_:b unstar:subject ?s; unstar:predicate :haveColor; unstar:object :violet}, as well as be available via property paths using something like {:Alice :says*[unstar:subject ?s; unstar:predicate :haveColor; unstar:object :violet]}.

[rubensworks]

I agree that we probably won't be able to provide all possible request functionalities,
while this may be achievable using entailments.

If the WG agrees that this is not a direction we want to go into, then I can definitely live with that.
But I do think it's one we should properly investigate.

---

An alternative approach that is inspired by the GRAPH syntax
could allow the QUOTED keyword to be used to access any quoted triple (at any nested depth):

SELECT ?person ?color {
  {
    QUOTED ?qOuter {
      ?person :says ?qInner
    }
  } UNION { # Union is necessary because :Alice's statement about :Red is not quoted
    ?person :says ?qInner
  }
  QUOTED ?qInner {
    :Violets :haveColor ?color
  }
}

Dataset:

:Alice :says << :Bob :says << :Carol :says << :Violets :haveColor :Blue >> >> >>
:Alice :says << :Bob :says << :Violets :haveColor :Yellow >> >>
:Alice :says << :Violets :haveColor :Red >>

Results:

person	color
:Carol	:Blue
:Bob	:Yellow
:Alice	:Red

This would not allow access to quoted triples at specific nested depths, but given that such recursion problems are a more general limitation in SPARQL, this may be acceptable here.

---

The advantage (or maybe not?) of this approach is that it blurs the boundary between quoted triples and named graphs,
and could allow people to more easily transition from named graphs to quoted triples.

[afs]

Another approach to explore is to add to the property path functionality.

Beyond the WG timeframe, property path needs to add expressivity for conditions on the path and returning paths themselves. This feels similar to the quote triple examples here so looking for a common approach, either in style or adding a "go into" operator.

[rubensworks]

This issue was discussed during the weekly meeting of July 6 (https://www.w3.org/2023/07/06-rdf-star-minutes.html).

The conclusion of the group is that this issue is highly important.
However, given the limited scope and duration of this WG, we decided to leave this to a future WG.
This is because designing a proper solution to the general problem of expressing paths with fixed/variable depths and selecting intermediary results will require a significant effort.
It's better to do this properly instead of rushing in a limited interim solution that we might regret in the future.