Re: From syntactic to interpreted triple

> On 5. Feb 2021, at 16:36, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> Hi Thomas,
> 
> (sorry for the late reply -- my day to day job again didn't allow me to spend 
> time here in the mailing list)
> 
> On lördag 23 januari 2021 kl. 18:55:47 CET thomas lörtsch wrote:
>>> On 23. Jan 2021, at 18:34, Olaf Hartig <olaf.hartig@liu.se> wrote:
>>> 
>>> Hi Thomas,
>>> 
>>> On lördag 23 januari 2021 kl. 14:55:57 CET thomas lörtsch wrote:
>>>> [...]
>>>> 
>>>>>> But doesn’t this mean that in every case that you want to comment on a
>>>>>> triple with referential transparency you have to define a new property
>>>>>> with those specific semantics?
>>>>> 
>>>>> I don't see why that would be necessary. Once I have introduced a
>>>>> property
>>>>> such as ex:statedBy (for which I have defined that
>>>>> referential-transparency
>>>>> inferences can be made for nested triples that have this property as
>>>>> their
>>>>> predicate), then I can use this property for any embedded triple.
>>>> 
>>>> Of course you don’t have to define it anew in every case you want to use
>>>> it
>>>> but you have to define a new property for all properties already defined,
>>>> or at least a good part of them.
>>> 
>>> I don't think so. Notice, that properties such as my example ex:statedBy
>>> are meant to be used in the predicate position of *nested* triples. In
>>> contrast, most existing properties are not meant to be used for this
>>> purpose (of course, there are exceptions such as, e.g., properties in the
>>> Dublin Core vocabulary).
>> 
>> My second example below - me, travelling to Berlin on wednesday - is an
>> example of an n-ary relation as it is common to Property Graphs. This has
>> nothing to do with provenance and such. Absolutely any property can be used
>> in such a way.
> 
> Would you use the ':on' property in that Berlin-travel example also in nested 
> triples in which the embedded triple is meant to be referentially opaque?
> If yes, would that ':on' property really have the same meaning in both cases?
> (i.e., in the case in which the embedded triple is meant to be referentially 
> transparent as in your Berlin-travel example and in the case in which the 
> embedded triple is meant to be referentially opaque)
> 
>> [...]
>>> First of all, as I already mentioned in my initial response to Thomas, if
>>> we use a referential-opacity semantics for RDF*, then there must be
>>> something in this data of yours that indicates that you want to use
>>> referential transparency for this particular case. In the following, I am
>>> assuming that the URI :claim is what gives the indication. More
>>> precisely, I am assuming that the meaning of the class denoted by this
>>> URI is as follows. Every embedded triple that is stated to be of rdf:type
>>> :claim is meant to be treated in terms of referential transparency.
>> 
>> That won’t work either. You can’t just (require to) define new properties or
>> IRIs whenever referential transparency is needed. That would lead to a
>> balkanization of the semantic web - for what purpose? Right: to ensure that
>> the Superman problem can be solved efficiently. This is just ridiculous.
>> 
>> You’ll probably have to provide a way similar to the one Pierre-Antoine
>> outlined for referencing occurrences because it’s the embedded triple that
>> plays different roles, not the other nodes in the assertion.
> 
> You are saying it. The embedded triple plays different roles. What role it 
> plays does not depend on the embedded triple itself but on the other nodes in 
> the assertion (such as the property in the predicate position of the nested 
> triple that contains the embedded triple).

No, it doesn’t. The example in question is the following:

>>>>  :me :travellingTo :Berlin .
>>>>  
>>>>  << :me :travellingTo :Berlin >> :on : Wednesday .


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. The latter is most probably the normal case (and the proposed RDF* semantics doesn’t cover it). Let’s assume the destination is not Berlin but a city in the east of Ukraine and we exchange triples with someone in Kiev or Moscow. In this secanrio the date of the journey will not have an influence on which semantics we choose, so the property shouldn’t need to change.   

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

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 Friday, 5 February 2021 16:18:05 UTC