Re: Why nested triples?

> On 20. Feb 2021, at 02:01, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> Don't get me wrong. I meant to give my input for the discussion only. If there was a vote, I would probably go -0.7, certainly not -1. Surely there are pros and cons of this decision.
> 
> On 2021-02-20 3:09 am, Miel Vander Sande wrote:
>> The use cases are not so future. In cultural heritage and GLAM sector, the need to express uncertainty and claims goes deep.  
>> 
>> An example from possible metadata on the graphic novel 'From Hell':
>> :AlanMoore :used << :StephenKnight :suggested <<:WilliamGull :operatedOn :AnnieCrook>> >> .
>> 
>> If you don't want to use nesting, then don't? I don't think it will be used much in practice, but I don't want to get into the situation where we have to invent stange constructs because we were being too pragmatic. Clearly, Jena and Ontotext already managed to implement the syntax, so it can't be that much of a showstopper.
> This is where I beg to differ. It is relatively straight forward for low-level APIs and storage systems to implement these changes, but it is a very different beast for downstream algorithms and user interfaces that are expected to support all these variations. How would forms render and edit such info. How would graphical displays work. If someone does "Find references", how would such nested info be displayed.

w.r.t. forms and graphical user interfaces IMO you only have to find one scalable abstraction  how to represent one additional level of nesting - and then just repliacte it from there. maybe easier said the done but surely possible. 
one idea: replace the embedded triple by an identifier that on demand shows the embedded triple, or links to it. etc. if you start with un-nested embedded triples as the default and normal case and add extra levels of embeddings through something like such a reference construct (that scales indefinitely) things shouldn’t be too hard to handle.

RDF graphs and the complex objects they may contain are boundless and can be very unevenly structured. in that context the added complexity of nested embedded tiples doesn’t strike me as particularily extreme. 

Thomas

> Keep in mind that when Jena or RDF4J add a fundamentally new feature then there will be 1000 other systems that use those APIs and now need to adapt to the consequences. Yes they can be done incrementally, but based on past experiences, some customer will soon ask for the corner cases and there we are looking at months of work.
> 
> Holger
> 
> 
> 
>> 
>> Op vr 19 feb. 2021 om 17:00 schreef thomas lörtsch <tl@rat.io>:
>> 
>> 
>> > On 19. Feb 2021, at 15:16, Andy Seaborne <andy@apache.org> wrote:
>> > 
>> > 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
>> 
>> This seems to me to be as arbitrary an argument as it can possibly get.
>> 
>> Thomas
>> 
>> 
>> 
>> > - 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 Wednesday, 24 February 2021 22:40:33 UTC