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

Re: Why nested triples?

From: Olaf Hartig <olaf.hartig@liu.se>
Date: Thu, 18 Feb 2021 15:56:43 +0100
To: public-rdf-star@w3.org
Message-ID: <7209287.JAXsN6dRJG@porty3>
Hi Antoine,

On torsdag 18 februari 2021 kl. 15:02:11 CET 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.

How's about something like the following?

:charlie :claims << :alice :claims <<:bob :age 23>> >> .


> 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?

I still think that a statement about a particular triple is something else 
than a statement about a set of triples (a.k.a. an RDF graph) that happens to 
contain a single triple.

For use cases in which you want to have sets of triples in the subject 
position or the object position of another triple, doesn't N3 allow you to do 
this?

> Also, a question to implementers: do you support nested embedded triples?

I know that Jena supports it.

Best,
Olaf
Received on Thursday, 18 February 2021 14:57:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 18 February 2021 14:57:18 UTC