Re: From syntactic to interpreted triple

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

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

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