W3C home > Mailing lists > Public > public-rdf-star@w3.org > February 2021

Re: Why nested triples?

From: Andy Seaborne <andy@apache.org>
Date: Thu, 18 Feb 2021 15:26:33 +0000
To: public-rdf-star@w3.org
Message-ID: <1351ba91-201e-1296-9d8e-6b0fffbfd0f5@apache.org>

On 18/02/2021 14:02, Antoine Zimmermann wrote:
> The RDF-star syntax allows for arbitrary nesting of triples like so:
> << :s :p << << :a :b :c >> :y :z >> a :nesting .
> Why is it so, why is it useful/needed?
> There are no examples of nested triples. There are no justifications in 
> the spec for allowing this. As far as I know, there are no examples in 
> the past documents that defined RDF*. I did not see any use cases 
> discussed for them.
> However, I have seen discussions that may serve as counter arguments: 
> when asked why embedded triples are limited to single triples rather 
> than sets of triples, it has been answered that RDF* is used to model 
> property-graph-like annotations that only concern one edge at a time. In 
> this case, nested triples should not be allowed, using the same 
> arguments (as far as I know, it is not possible to nest edge-annotations 
> in property graph systems).
> Nesting makes parsers more complicated, makes it more difficult to 
> define the semantics of the data model as well as of the query language.
> If some use cases justify nested triples, then why not use cases justify 
> embedded sets of triples?
> Also, a question to implementers: do you support nested embedded triples?


Related note: It's natural because then it is only an additional RDF 
term type. Otherwise there are two sets of grammar rules - with and 
without <<>>; this cascades down the grammar. It's not one extra rule; 
it's one extra subtree of rules. See "path" in SPARQL where there are 
with and without cases, and both those get replicated.

Received on Thursday, 18 February 2021 15:26:48 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 18 February 2021 15:26:49 UTC