Re: Why nested triples?

On 20/02/2021 01:01, Holger Knublauch 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.
> 
> 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.

There is a 3rd element in the equation.
If it were app-platform, they can co-evolve.

There is also the "standard" and it is slower to change.

     Andy

> Holger
> 
> 
>>
>> Op vr 19 feb. 2021 om 17:00 schreef thomas lörtsch <tl@rat.io 
>> <mailto:tl@rat.io>>:
>>
>>
>>
>>     > On 19. Feb 2021, at 15:16, Andy Seaborne <andy@apache.org
>>     <mailto: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 Friday, 26 February 2021 13:04:08 UTC