Re: From syntactic to interpreted triple

 > the meaning of the proposed semantics

Thomas - the discussions about statings and statements (RDF-WG 2004) are 
relevant to some of your points, as are discussions on this list about 
modelling based <<>> as the necessary hook.

     Andy

On 07/02/2021 14: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?
>>
>> See my answer to Pat's latest email:
>>
>> https://lists.w3.org/Archives/Public/public-rdf-star/2021Feb/0012.html
> 
> Until I brought it up a few weeks ago there was zilch work on how interpreted triples can or even should be represented based on RDF* embedded triples. There was only your repeated claim that it can be done whereas allegedly it’s impossible to do it the other way round (I would challenge that claim too but that’s another story). Given the importance of the more general use case I call this a sever lack of due diligance on your side. (*)
> 
> Now we have different proposals: Olaf’s (which you seem to endorse) which I have critized as outright ridiculous, and mine (see for example [0]), which so far nobody has said anything about (Olaf and yourself included).
> You can keep up the impression that this is just me being overly vocal about my opinion, but really: if you weren’t the editor, what other arguments would there be in your favor? What supporters do you have that actually care about semantics and not only about getting the spec out of the door, "pragmatists" style?
> How often have I now heard you apologize or pensively say "I agree" on the weekly call but without any consequences? It means nothing if you apologize or agree to a critique, you just steamroll on. Your semantics has been critized in more than one way by people much more knowledgeable than me: it doesn’t impress you, you say "I know it’s comtroversial :-)" - smiley included, no less - and just move on.
> You even try to put the working draft up for discussion by the greater community, just without the semantics. No matter what your excuses are: to me this is a blatantly obvious attempt to sneak your semantics into the spec without broad discussion. But you keep suggesting that it's just me who can’t live with something not being in my favourite way, "disgruntled employee"-style. Thank you very much.
> 
>>> 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. They don’t need extreme care, 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
>>>>
>>>>
>>>
>>
>

Received on Sunday, 7 February 2021 16:30:38 UTC