Re: Why nested triples?

> On 21. Feb 2021, at 15:03, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> 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

I admit that I forgot about that comment, but also because it doesn’t answer my question, which I’d like to restate as follows: 
given two intuitions - the seminal example regarding provenance, and that the triple is the same triple everywhere - I personally would have a strong feeling about the usecase, provenance, and a much weaker one about its formal representation, the triple type. And if some day I became aware that the two intuitions contradict each other I would really make an effort to safe the usecase, and not the formal representation. 
But maybe that’s just me and anyways, I don’t intend to pound on this issue any longer.

>> 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.

There is quite some stuff going on here that doesn’t make anything easier: foremost the proposed hybrid semantics which is really problematic, but also other stuff like nesting of embedded triples and support for unasserted assertions. So  not "to extend the approach with a lot of other features" doesn’t seem to be a strict rule, but rather arbitrarily applied.

It seems like the original approach tried to be more things at the same time than it can actually be, so adaptations are necessary. That is not worrying, but rather was to be expected. A lot of the problems that RDF* encounters are due to the inherent complexity of the topic. It can only hope to strike the right balance but it will not be able to solve every problem and wish - that is quite clear and not RDF*’s fault. 

But now aspects are dumped and others are added without much rigor and considerate discussion, but rather opportunistically it seems. The result so far feels quite unbalanced to me. I’m not talking about occurrences needing an extra triple - in fact I made my peace with that. I’m also not talking about multiple triples: if RDF* concentrates on the Property Graph usecase then constraining emvbedded triples to single triples makes sense (there is of course a problem lurking here too: RDF* can’t address individual nodes in embedded statements, thereby lacking severly in expressivity compared to Property Graphs). 

My biggest gripe however is the meaning of the proposed semantics which is really far from adequate for the intended uses and audience but in its present form - with syntactic triples the default, and interpreted triples needing newly forged properties (by your proposal) -  much rather will be dead on arrival. I fear however I will have to write another mail on that topic.

Thomas



> 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 Thursday, 25 February 2021 21:35:39 UTC