Re: From syntactic to interpreted triple

+1 to what Olaf wrote below.

As an example, I used Jos' implementation of RDF* in EYE, and William 
Van Woensel super-nice N3 editor, to illustrate this with a small example:

     http://ppr.cs.dal.ca:3002/n3/editor/s/j7yBphsy

In this example, I have two predicates that link files to triples:

* :contains keeps referential opacity (nothing to do)

* :entailsForMe has some form of referential transparency (implemented 
through N3 rules: any triple with the same meaning as one contained in 
the file is also entailed for me by that file)

By running it in EYE (click "execute"), you can see that the conclusions 
contain:

   :report :contains <<:superman :can :fly>>.
   :report :entailsForMe <<:superman :can :fly>>.
   :report :entailsForMe <<:clark :can :fly>>.

but NOT

   :report :contains <<:clark :can :fly>>.


On 21/01/2021 15:35, Olaf Hartig 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).
>
> 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.
>
> 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
>
>