Re: From syntactic to interpreted triple

> On 22. Jan 2021, at 13:13, thomas lörtsch <tl@rat.io> wrote:
> 
> 
> 
>> On 21. Jan 2021, at 15:35, Olaf Hartig <olaf.hartig@liu.se> wrote:
>> 
>> Hi Thomas,
>> 
>> You are raising an interesting point that I was also thinking about recently, 
>> and I believe I have a solution.
>> 
>> First of all, regarding terminology, our groups' earlier discussions related 
>> to this topic used the terms "referential opacity" and "referential 
>> transparency" for what you call "syntactic triple" and "interpreted triple" 
>> now.
>> 
>> The proposed semantics adopts referential opacity. From my understanding, in 
>> comparison to a semantics that adopts referential transparency, adopting 
>> referential opacity (as in the proposed semantics) is less restrictive in the 
>> sense that it does not rule out the possibility to use referential 
>> transparency for selected cases. In other words, by using referential opacity 
>> as a basis (i.e., for the semantics of RDF*), on top of this basis you may 
>> still define specific cases for which the additional nested triples may be 
>> derived that you would expect under referential transparency. In contrast, if 
>> referential transparency is used as a basis, which says that such additional 
>> nested triples can be derived for all cases, then it is not possible to define 
>> on top of this basis that there are cases for which the additional triples 
>> should actually not be derived. At least, that's what I had understood from my 
>> discussions with Pierre-Antoine and Dörthe (please feel free to confirm or 
>> correct me on this).
> 
> Seems to be the same understanding as mine.
> 
>> 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? 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. That seems to need a new property like
> 
>  rdf*:isSubpropertyWithOpaqueSemanticsOf
> 
> or even
> 
>  rdf*:isSubpropertyWithOpaqueSemanticsInDomainOf
>  rdf*:isSubpropertyWithOpaqueSemanticsInRangeOf
>  rdf*:isSubpropertyWithOpaqueSemanticsInDomainAndRangeOf


Sorry, s/Opaque/Transparent/g.

> 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, 22 January 2021 13:10:56 UTC