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

Re: Why nested triples?

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 19 Feb 2021 08:10:51 +1000
To: public-rdf-star@w3.org
Message-ID: <81aa36be-1c78-a7e3-5ff0-e7bd59e19754@topquadrant.com>
My input:

I think nested triples should not be allowed. They are largely 
unnecessary, will cause extra work and put limitations on the design 

As an implementer I can say that we don't support nested triples and do 
not want to (have to) support them.

Even in the case that RDF-star introduces a new term type, it would be 
easy to exclude certain combinations, such as that triple terms cannot 
be subject, predicate or object of another triple term. Similar 
restrictions (thankfully) already exist in normal, non-generalized RDF. 
Such restrictions mean that algorithms that actually use/display/consume 
RDF have fewer cases to cover, and this will help the adoption of 
RDF-star in industry.

There are in my experience significant downstream costs to users even if 
it sounds nice, consistent and symmetric from a spec point of view and 
for those who write low-level algorithms, parsers etc.


On 2021-02-19 12:02 am, 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?
Received on Thursday, 18 February 2021 22:11:11 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 18 February 2021 22:11:13 UTC