Re: From syntactic to interpreted triple

Hi Thomas,

On lördag 23 januari 2021 kl. 14:55:57 CET thomas lörtsch wrote:
> [...]
> >> 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?
> > 
> > I don't see why that would be necessary. Once I have introduced a property
> > such as ex:statedBy (for which I have defined that
> > referential-transparency
> > inferences can be made for nested triples that have this property as their
> > predicate), then I can use this property for any embedded triple.
> 
> Of course you don’t have to define it anew in every case you want to use it
> but you have to define a new property for all properties already defined,
> or at least a good part of them.

I don't think so. Notice, that properties such as my example ex:statedBy are 
meant to be used in the predicate position of *nested* triples. In contrast, 
most existing properties are not meant to be used for this purpose (of course, 
there are exceptions such as, e.g., properties in the Dublin Core vocabulary).

> I find that a very high burden. See below
> where I discuss several rdf*:isSubpropertyWithOpaqueSemantics (and
> s/Opaque/Transparent/g) .
> [...]
> > From my reading of your initial example, you wanted the property
> > ex:statedBy to have a meaning that allows for referential-transparency
> > inferences. So, if you simply define it to have this meaning, then it is
> > the property that was intended to be used, isn't it?
> 
> [Just for keeping track of the flow of discussion: I didn’t introduce the
> property ex:statedBy, you did]

You are right! I realized this after sending the email and working on my 
response to James' email.

> If one introduces an all new property for
> every case where one desires to annotate a triple in a referentially
> transparent way one would arrive at the problematic situation described
> above, or even more problematic as now there is not even a relation between
> the vocablaries we already have and the newly defined properties.
> 
> My initial example can be looked up below, but here it is again, somewhat
> shortened: somebody published the statement
>  :cars :are :bad .
> 
> on the web. I want to annotate this statement by asserting
> 
>  << :cars :are :bad >> rdf:type :disputedClaim .
> 
> In my original exampe I used the property :a to allude to rdf:type.

Yes, I am aware that the "a" in your original example was the syntactic short 
form for rdf:type. I have explicitly discussed this example in the response to 
James that I have sent a few minutes ago.

Best,
Olaf


> I made
> that more explicit here. As the original statement refers to :cars under
> the Non Unique Name Assumption of the semantic web I want my annotation to
> do the same. How do I do that? Usage scenarios abound: people might have
> defined mappings from ex:cars to WikiPedia, to the American Automotive
> Makers Association's vocabulary etc and want to put those to use, people
> might search for annotations on al subtypes of :vehicles etc pp.
> 
> Another example could be that I want to state an n-ary relation like
> 
>  :me :travellingTo :Berlin .
> 
>  << :me :travellingTo :Berlin >> :on : Wednesday .
> 
> There exist different IRIs for me and for Berlin and they are all valid. I
> want the annotation to be valid with all those alternative IRIs, not just
> with the ones I arbitrarily chose.
> 
> It’s the semantic web and the NUNA is one of its founding principles.
> Interoperability depends on it. RDF* as a syntax for Property raph style
> n-ary relations depends on it too. If the above stated problem isn’t easy
> to solve then that is a big problem for the proposed semantics.
> 
> Thomas
> 
> > Best,
> > Olaf
> > 
> >> That seems to need a
> >> new property like
> >> 
> >>  rdf*:isSubpropertyWithOpaqueSemanticsOf
> >> 
> >> or even
> >> 
> >>  rdf*:isSubpropertyWithOpaqueSemanticsInDomainOf
> >>  rdf*:isSubpropertyWithOpaqueSemanticsInRangeOf
> >>  rdf*:isSubpropertyWithOpaqueSemanticsInDomainAndRangeOf
> >> 
> >> 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 Saturday, 23 January 2021 17:34:23 UTC