Re: Why nested triples?

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.

     Andy

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