Re: From syntactic to interpreted triple

> On 22. Jan 2021, at 14:46, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> Thomas,
> 
> Before I attempt to answer your and James' question, I would first like to 
> establish a basis for answering by asking a question myself...
> 
> In your initial email in this thread, you wrote:
> 
>> 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.
> 
> So, in other words, you are saying that we can assume that his (or her) intend 
> was that it should be possible to infer the following triple:
> 
>    :automobiles :are :bad .
> 
> If that's what you had in mind, how would you do this in RDF and/or SPARQL?
> In particular, what did you have in mind to capture the necessary information 
> about the relationship between the URIs :cars and :automobiles, which would be 
> necessary to come to this inference?
> 
> This is not meant not be a trick question! I simply want to know your 
> preferred approach to establish this inference so that we have a common basis 
> for discussing the question that you and James have.

I just answered another mail in a more complete way. I suggest we keep the discussion there to avoid too many threads. Therefor I’ll just answer very briefly here: we’re talking about the semantic web here. The Non Unique Name Assumption and basic reasoning mechanisms belong to its very foundations. Mappings exist, subtype relations exist. You have to take all that into account when proposing an alternative approach to refication and n-ary relations. Otherwise you are either proposing a very specific solution for a niche problem (which indeed I think the proposed semantics with its literal-stye approach to reification does) or you are not on the semantic web anymore.

Thomas

> Thanks,
> Olaf
> 
> 
> On fredag 22 januari 2021 kl. 12:59:08 CET 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?
>> 
>> 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
> 
> 
>

Received on Saturday, 23 January 2021 14:06:05 UTC