Re: Why nested triples?

Hi Thomas,

On fredag 19 februari 2021 kl. 18:41:36 CET thomas lörtsch wrote:
> [...]
> Design decisions generally tend to be hard to argue about but in this CG
> they quite often seem quite arbitrary. For example I never got an
> explanation why Olaf ditched the seminal example in favor of the abtract
> triple type.

That's not exactly what happened. I was always considering embedded triples to 
be just triples, i.e., what you call an "ab[s]tract triple type" here. That 
is, something whose identity is defined entirely by the three RDF*/RDF-star 
terms it consists of.

Regarding the seminal example, my reflection on it is documented in the 
following comment on a related github issue; note that I wrote this comment 
explicitly for you (and for Peter).

https://github.com/w3c/rdf-star/pull/75/#issuecomment-761588690


> Was it intuition, was it to avoid discussions about named
> graph semantics? Nobody seems to know, or care. This ship seems to be
> steered by tactical considerations, by hidden agendas and pragmatic
> coalitions. I don’t want to diminish the hard work on technical detail but
> I think it takes more than that to produce a good standard.

I think I said or wrote it before, but here you go again: My goal with this 
endeavor was to consolidate the material around RDF* and SPARQL* into a 
community-defined spec that provides a basis for existing (and future) 
implementors to make sure that their implementations of the RDF*/SPARQL* 
approach don't drift apart and become incompatible with one another. Hence, 
the idea was not to invent something completely new or to extend the approach 
with a lot of other features. I believe that several other people here share 
this goal.

Best,
Olaf

 
> Thomas
> 
> > 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 Sunday, 21 February 2021 14:03:43 UTC