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

Re: Why nested triples?

From: Andy Seaborne <andy@apache.org>
Date: Fri, 19 Feb 2021 14:16:40 +0000
To: public-rdf-star@w3.org
Message-ID: <5b99b5b6-8848-fb5f-02a4-89b22ebc9cf5@apache.org>
It does not have to be as either/or.

An application/sub-system can mask nested embedded triples from a 
general parser.

Current use cases are not defining the limit of uses in the future.

"largely unnecessary" is to me a reason to include them, because we 
don't know the future use cases and patterns - as per Olaf's example.


On 18/02/2021 22:10, Holger Knublauch wrote:
> My input:
> I think nested triples should not be allowed. They are largely 
> unnecessary, will cause extra work and put limitations on the design 
> choices.
> 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.
> Holger
> 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 Friday, 19 February 2021 14:16:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 19 February 2021 14:16:55 UTC