Re: From syntactic to interpreted triple

> On 22. Jan 2021, at 15:29, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> On fredag 22 januari 2021 kl. 13:13:55 CET thomas lörtsch wrote:
>> [...]
>>> Given this understanding, you may indicate the cases in which you want to
>>> use referential transparency on top of a referential opacity semantics by
>>> using specific properties that you introduce for this purpose. For
>>> instance, you may introduce a property denoted by the URI ex:statedBy and
>>> define that referential transparency can be used for nested triples that
>>> have this property in their predicate position. This way, related to your
>>> example, if you have a nested triple
>>> 
>>> <<:cars :are :bad>> ex:statedBy :Alice
>>> 
>>> you can derive the following triple.
>>> 
>>> <<:automobiles :are :bad>> ex:statedBy :Alice
>>> 
>>> So, while the semantics of RDF* adopts referential opacity, you can build
>>> on it and define cases in which you want to have referential
>>> transparency.
>> 
>> 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 find that a very high burden. See below where I discuss several rdf*:isSubpropertyWithOpaqueSemantics (and s/Opaque/Transparent/g)
.
>> That would seem like an outrageous demand to me.
>> 
>> And even then: how would you define such a property? It probably should be a
>> subproperty of the property that you intend to use.
> 
> No, I don't think so. However, I have a bit of trouble responding to this 
> sentence because I am not certain what you mean by "the property that you 
> intend to use."
> 
> 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] 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. 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 13:56:49 UTC