Re: From syntactic to interpreted triple

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

Besides, having to define referentially transparent versions of all provenance related properties would be bad enough. I fear you don’t give this problem enough consideration.

>> I find that a very high burden. See below
>> where I discuss several rdf*:isSubpropertyWithOpaqueSemantics (and
>> s/Opaque/Transparent/g) .
>> [...]
>>> From my reading of your initial example, you wanted the property
>>> ex:statedBy to have a meaning that allows for referential-transparency
>>> inferences. So, if you simply define it to have this meaning, then it is
>>> the property that was intended to be used, isn't it?
>> 
>> [Just for keeping track of the flow of discussion: I didn’t introduce the
>> property ex:statedBy, you did]
> 
> You are right! I realized this after sending the email and working on my 
> response to James' email.
> 
>> If one introduces an all new property for
>> every case where one desires to annotate a triple in a referentially
>> transparent way one would arrive at the problematic situation described
>> above, or even more problematic as now there is not even a relation between
>> the vocablaries we already have and the newly defined properties.
>> 
>> My initial example can be looked up below, but here it is again, somewhat
>> shortened: somebody published the statement
>>  :cars :are :bad .
>> 
>> on the web. I want to annotate this statement by asserting
>> 
>>  << :cars :are :bad >> rdf:type :disputedClaim .
>> 
>> In my original exampe I used the property :a to allude to rdf:type.
> 
> Yes, I am aware that the "a" in your original example was the syntactic short 
> form for rdf:type. I have explicitly discussed this example in the response to 
> James that I have sent a few minutes ago.

To quote from there:

> On 23. Jan 2021, at 18:20, Olaf Hartig <olaf.hartig@liu.se> wrote:

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

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 Saturday, 23 January 2021 17:56:10 UTC