Re: Why nested triples?

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?

Yes.


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.

     Andy

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