Re: From syntactic to interpreted triple

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.

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 Friday, 22 January 2021 13:46:32 UTC