Re: From syntactic to interpreted triple

On 22/01/2021 12:59, thomas lörtsch wrote:
>
>> On 21. Jan 2021, at 16:43, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
>>
>> +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>>.
> Paraphrasing James’ question to Olaf: how would you do that in SPARQL?
AFAIK, you can not write recursive queries in SPARQL, which makes it a 
limited rule langue compared to N3. But a simplified version of my N3 
example would be

CONSTRUCT {
     ?file :entailsForMe <<?s2 ?p2 ?o2>>.
} WHERE {
     ?file :contains <<?s ?p ?o>>.
     ?s owl:sameAs ?s2.
     ?p owl:sameAs ?p2.
     ?o owl:sameAs ?o2.
}

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