W3C home > Mailing lists > Public > public-rdf-star@w3.org > January 2021

Re: From syntactic to interpreted triple

From: thomas lörtsch <tl@rat.io>
Date: Sat, 23 Jan 2021 18:55:47 +0100
Cc: public-rdf-star@w3.org
Message-Id: <C70A4FE8-ADA8-4DCB-A27A-F0F6A786ABBE@rat.io>
To: Olaf Hartig <olaf.hartig@liu.se>

> On 23. Jan 2021, at 18:34, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 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).

My second example below - me, travelling to Berlin on wednesday - is an example of an n-ary relation as it is common to Property Graphs. This has nothing to do with provenance and such. Absolutely any property can be used in such a way. 

Besides, having to define referentially transparent versions of all provenance related properties would be bad enough. I fear you don’t give this problem enough consideration.

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

To quote from there:

> On 23. Jan 2021, at 18:20, Olaf Hartig <olaf.hartig@liu.se> wrote:

> First of all, as I already mentioned in my initial response to Thomas, if we 
> use a referential-opacity semantics for RDF*, then there must be something in 
> this data of yours that indicates that you want to use referential 
> transparency for this particular case. In the following, I am assuming that 
> the URI :claim is what gives the indication. More precisely, I am assuming 
> that the meaning of the class denoted by this URI is as follows. Every 
> embedded triple that is stated to be of rdf:type :claim is meant to be treated 
> in terms of referential transparency. 

That won’t work either. You can’t just (require to) define new properties or IRIs whenever referential transparency is needed. That would lead to a balkanization of the semantic web - for what purpose? Right: to ensure that the Superman problem can be solved efficiently. This is just ridiculous.

You’ll probably have to provide a way similar to the one Pierre-Antoine outlined for referencing occurrences because it’s the embedded triple that plays different roles, not the other nodes in the assertion. 

Your turn again.


> 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:56:10 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 23 January 2021 17:56:10 UTC