Re: From syntactic to interpreted triple

Thomas,

On 07/02/2021 15:14, thomas lörtsch wrote:
>> On 7. Feb 2021, at 11:36, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
>>
>>
>> On 05/02/2021 17:17, thomas lörtsch wrote:
>>> It is easy to come up with scenarios where it is either important to record exactly which IRI was used to refer to :Berlin or where it is not important at all.
>> Absolutely
>>> The latter is most probably the normal case (and the proposed RDF* semantics doesn’t cover it).
>> Can we agree that the proposed RDF* semantics covers it, although not in your favourite way?

"your favorite way" wasn't meant to be dismissive.

What I meant was: can we agree that

   "this can not be done"

is not entirely accurate, but that

   "this can be done, but could/should be done in a better way"

would be a fairer account of the situation?

>>> As we all know on the semantic web the shared vocabularies have huge importance and took a lot of work to establish. You woud really have to come up up with much more substantial arguments to justify the need for their extension (just to cover the Superman use case, if I may repeat).
>> I consider, on the contrary, that reusing existing vocabulary with property-graph-style annotations should be done with extreme care.
> Then please explain what this leaves of the promise of RDF* implementing Property Graph style modelling in RDF.

It can be done, although only using appropriate vocabularies. But that's 
not really something new: care must be taken in RDF whenever we reuse 
someone else's vocabulary. By misusing it, we might create confusion.

> They don’t need extreme care,

They (Property Graphs, I assume) need less care because 1) they don't 
have any built-in semantics, and 2) they don't reuse shared vocabulary. 
The meaning of the terms used in a PG (node labels, edge labels, 
properties) is entirely up the PG database author(s).

Other users of a PG database need to be careful, though. It is easy to 
got things wrong in your Cypher query if you try to find all of Alice's 
colleagues, but forget to take into account the dates on the "worksFor" 
edges. (referring to my original example, quoted below).


>   certainly not more care than any n-ary relation.
>> And by the way, this is totally independant of the ref-opaque / ref-transparent debate.
>>
>> Consider the vocabulary used in the LUBM benchmark. It allows us to describe, among other things, universities and their staff:
>>
>>    :uni1 a lubm:University.
>>    :alice lubm:worksFor :uni1.
>>    :bob lubm:worksFor :uni1.
>>
>> Relying on the shared semantics of that vocabulary, I can build interesting queries, for example for finding Alice's colleagues.
>>
>>    SELECT * { :alice lubm:worksFor _:u. ?x lubm:worksFor _:u. }
>>
>>
>> Now, reusing this vocabulary in a property-graph-manner seems like a natural extension.
>>
>>    :alice lubm:worksFor :uni1 { :from 2012; :until 2016 }.
>>    :bob lubm:worksFor :uni1 { :from 2018; :until 2020 }.
>>
>> But all of a sudden, the SPARQL query above becomes invalid, because it does not retrieves correctly the colleagues of Alice (as far as we can tell from that graph, Bob and Alice have never been colleague).
>>
>> I can think of different ways to solve this problem, but my point is not to solve it. Just to point out that adding property-graphs-style annotations do not always play well with existing RDF vocabularies (because they have not been designed with this in mind). So extending those vocabularies or coming up with new ones will be necessary in  some cases.
> I will not discuss this in this mail. I’ve seen it a lot of times already that you answer broad critique with discussions on very specific, even hardly related details. This mail is no exception. Maybe you really don’t see the forest because of all the trees. Then I’m afraid you’ll have to work on that.
>
> You propose a very special semantics for RDF* although RDF* was conceived and is expected to have a very broad range of applications. You not only do not examine the consequences, you even defend this neglect - although you do imagine that RDF* will lay the ground for RDF 2, as repeatedly stated on the wekly calls, so you do have far-reaching goals indeed. Again, I call this a severe lack of due diligance.
>
> I made a profound attempt to discuss the meaning of the proposed semantics two weeks ago [0] and I'm still waiting for a response that addresses its core issue: which RDF* semantics are possible and what sense do they make? Especially the editors, but not only they, should feel obliged to give this issue some serious thought and discussion. Because we’re always better off without any formal semantics at all than with one that - irrespective of any technical brilliance - doesn’t make sense.
>
> Thomas
>
>
>
> [0] https://lists.w3.org/Archives/Public/public-rdf-star/2021Jan/0123.html
>
>
> (*) And this is part of the RDF* effort from the very start: always only an absolute minimal amount of examples, always reference to the purity of the approach, and one misfit after the other dismissed as regrettable, misguided or out of scope. The sad truth is two-fold:
> - all that’s left for RDF* is the Superman-problem
> - but it will no matter be used for everything else as well, "regrettably" or not, gracing us with another pile of semantically unsound triples.
> Yes, I’ve said that before. And I’ll say it again if necessary.
>
>
>
>>    best
>>
>>> Thomas
>>>
>>>
>>>> Best,
>>>> Olaf
>>>>
>>>>
>>>>> Your turn again.
>>>>>
>>>>> Thomas
>>>>>
>>>>>> Best,
>>>>>> Olaf
>>>>>>
>>>>>>> I made
>>>>>>> that more explicit here. As the original statement refers to :cars under
>>>>>>> the Non Unique Name Assumption of the semantic web I want my annotation
>>>>>>> to
>>>>>>> do the same. How do I do that? Usage scenarios abound: people might have
>>>>>>> defined mappings from ex:cars to WikiPedia, to the American Automotive
>>>>>>> Makers Association's vocabulary etc and want to put those to use, people
>>>>>>> might search for annotations on al subtypes of :vehicles etc pp.
>>>>>>>
>>>>>>> Another example could be that I want to state an n-ary relation like
>>>>>>>
>>>>>>>  :me :travellingTo :Berlin .
>>>>>>>
>>>>>>>  << :me :travellingTo :Berlin >> :on : Wednesday .
>>>>>>>
>>>>>>> There exist different IRIs for me and for Berlin and they are all valid.
>>>>>>> I
>>>>>>> want the annotation to be valid with all those alternative IRIs, not just
>>>>>>> with the ones I arbitrarily chose.
>>>>>>>
>>>>>>> It’s the semantic web and the NUNA is one of its founding principles.
>>>>>>> Interoperability depends on it. RDF* as a syntax for Property raph style
>>>>>>> n-ary relations depends on it too. If the above stated problem isn’t easy
>>>>>>> to solve then that is a big problem for the proposed semantics.
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>> Best,
>>>>>>>> Olaf
>>>>>>>>
>>>>>>>>> That seems to need a
>>>>>>>>> new property like
>>>>>>>>>
>>>>>>>>>  rdf*:isSubpropertyWithOpaqueSemanticsOf
>>>>>>>>>
>>>>>>>>> or even
>>>>>>>>>
>>>>>>>>>  rdf*:isSubpropertyWithOpaqueSemanticsInDomainOf
>>>>>>>>>  rdf*:isSubpropertyWithOpaqueSemanticsInRangeOf
>>>>>>>>>  rdf*:isSubpropertyWithOpaqueSemanticsInDomainAndRangeOf
>>>>>>>>>
>>>>>>>>> as different embedded triples in subject and object position might have
>>>>>>>>> different semantics. So you’d get three subproperties per any property
>>>>>>>>> from
>>>>>>>>> any established vocabulary, right? Maybe not *all* of them but
>>>>>>>>> certainly
>>>>>>>>> not a few in between.
>>>>>>>>>
>>>>>>>>> If this is indeed your proposal then I think you’ll have to come up
>>>>>>>>> with
>>>>>>>>> something better. Or please explain what you meant instead.
>>>>>>>>>
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Olaf
>>>>>>>>>>
>>>>>>>>>> On torsdag 21 januari 2021 kl. 13:40:56 CET thomas lörtsch wrote:
>>>>>>>>>>> [I hope I’m using the right terminology in the right way. Advice is
>>>>>>>>>>> welcome.]
>>>>>>>>>>>
>>>>>>>>>>> The proposed semantics defines that the embedded triple refers to a
>>>>>>>>>>> triple
>>>>>>>>>>> on the syntactic level, not in the realm of interpretation. In
>>>>>>>>>>> defense
>>>>>>>>>>> of
>>>>>>>>>>> this rather peculiar arrangement Pierre-Antoine and Dörthe argued
>>>>>>>>>>> that
>>>>>>>>>>> going from the syntactic to the interpreted triple is always possible
>>>>>>>>>>> whereas the other way round it is not: once a triple is part of the
>>>>>>>>>>> interpretation we can not know what its original syntactic structure
>>>>>>>>>>> was.
>>>>>>>>>>> That’s true (at least in any normal setup) but let's assume I’d like
>>>>>>>>>>> to
>>>>>>>>>>> annotate not the syntactic triple but the interpreted triple. What
>>>>>>>>>>> would
>>>>>>>>>>> I
>>>>>>>>>>> actually have to do to construct a reference to an interpreted triple
>>>>>>>>>>> from
>>>>>>>>>>> an RDF* embedded triple?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Lets for example assume someone published the triple
>>>>>>>>>>>
>>>>>>>>>>>  :cars :are :bad .
>>>>>>>>>>>
>>>>>>>>>>> As he published that statement on the semantic web we can assume that
>>>>>>>>>>> his
>>>>>>>>>>> intend was to refer not only to :cars but just as well to
>>>>>>>>>>> :automobiles,
>>>>>>>>>>>
>>>>>>>>>>> :voitures etc. Now if we want to comment on that general
>>>>>>>>>>> :interpretation
>>>>>>>>>>> :of
>>>>>>>>>>>
>>>>>>>>>>> this statement, irrespective of the concrete vocabulary used,
>>>>>>>>>>> irrespective
>>>>>>>>>>> of any syntactic specifics, how would we do that? The proposed
>>>>>>>>>>> semantics
>>>>>>>>>>> of
>>>>>>>>>>>
>>>>>>>>>>>  << :cars :are :bad >> :a :disputedClaim .
>>>>>>>>>>>
>>>>>>>>>>> doesn’t cover this very common case as the embedded triple only
>>>>>>>>>>> refers
>>>>>>>>>>> to
>>>>>>>>>>> that very specific syntactic form. From this RDF* statement we
>>>>>>>>>>> couldn’t
>>>>>>>>>>> infer that
>>>>>>>>>>>
>>>>>>>>>>>  << :automobiles :are :bad >> :a :disputedClaim .
>>>>>>>>>>>
>>>>>>>>>>> even if we were using a reasonably complete mapping of car related
>>>>>>>>>>> vocabiularies. Adding all those derivable embedded triples to the
>>>>>>>>>>> database
>>>>>>>>>>> is not a viable option as it would increase operational costs
>>>>>>>>>>> enormously.
>>>>>>>>>>> We need a way to derive a reference to the interpreted triple from
>>>>>>>>>>> the
>>>>>>>>>>> syntactic triple that the RDF* embedded triple represents. But how?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thomas