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

Re: drop referentially opaque semantics in embedded triples

From: Andy Seaborne <andy@apache.org>
Date: Wed, 12 May 2021 00:56:54 +0100
To: thomas lörtsch <tl@rat.io>
Cc: public-rdf-star@w3.org
Message-ID: <5743fcd2-82b0-2a6b-b8f5-e44a4e4e0283@apache.org>


On 11/05/2021 12:49, thomas lörtsch wrote:
> 
> 
>> On 10. May 2021, at 19:05, Andy Seaborne <andy@apache.org> wrote:
>>
>> On 07/05/2021 16:20, Peter F. Patel-Schneider wrote:
>>
>>> An excellent description of the problems with referential opacity in embedded triples.   I agree wholeheartedly.  I particularly like the detailed investigation into the use cases.
>>> I also note that referential opacity works poorly for the annotation syntax (PG mode).  With referential opacity
>>> :berlin :population 3644826 {| :determination-method :statistical-updating |}
>>> does not entail
>>> :berlin :population 03644826 {| :determination-method :statistical-updating |}
>>> which I take to be completely unexpected.
>>> (I purposefully picked an example that did not need any external identity relationship.)
>>
>> The transparency/opaque language isn't that helpful for me;
> 
> Well, you asked me a few months ago not to invent new terms. So I tried hard to use the terms that belong to the semantcs vocabulary when talking abot the semantics.
> 
>> it is about binding and scoping.
> 
> Let’s see if that really get’s to the gist of it.
> 
>> In a programming language situation, a quoted expression is not the expression. It may capture context when written (lexical/static scoping - capture) or when executed (dynamic scoping).
>>
>> Graph :A asserts
>>
>>     :ship1 :name 'Happy Cat' .
>>
>> Graph :B reads :A and says
>>
>>     << :ship1 :name 'Happy Cat' >> :source :A .
>>     :ship1 :name 'Happy Cat'
>>     :ship1 owl:sameAs :ship2 .
>>
>> (yes - external information)
>>
>> Is A the source of ":ship2 :name 'Happy Cat'"?
>>
>> No - that is because later entailment of owl:sameAs was not "in-scope" at :A.
> 
> Here is already the central issue: the answer could just as well be "Yes", not "No" as you suggest. In fact on the semantic web it should be Yes!
> 
> In an application it might be No, depending on purpose and inclination. 

Where does it say ":ship2 :name 'Happy Cat'"?

How can I write the proof chain that B can pass on, using transparent 
references, that says what A asserted and B's additional conclusion?

Or by
> (and don’t forget they [semantics -ed] are meant to be used EVERYWHRE, not just for adding provenance annotations).
are you rejecting provenance?

Show me how that is done and I will be more comfortable with it.

Доверяй, но проверяй (trust but verify)

The question is "what did A assert?"
A never mentioned :ship2 at all.
B can not witness that.

B can decide what is likes in its graph.
It's a choice - not prescriptive.

Define :source as "triple asserted" (like the original RDF*).

Define :determination-method as "D-entailment permitted"

It is modelling that can state whether entailment is meaningful.

Annotation syntax is a helper for authoring.

:paper :author ("X" "Y" "Z") .

gives the impression

:paper :author "X" .

Maybe :author is defined like that or maybe not.

     Andy

(For fun: insert issues of signing linked graphs)

> On the semantic web however we are not talking about identifiers but about the things they identify. That, IIUC, is the whole point that the formal model theoretic semantics is based on. In your example we are talking about a ship. That ship's name is 'Happy Cat', according to :A. The fact that the ship is so named doesn’t depend on the identifier that we use to refer to that ship nor is it of importance if we use :A or another equally correct identifier to refer to the source of that statement.
> 
> This introduces some wiggle room into the system that depending on our view is either useful or harmful.
> - One can argue that this wiggle room is what makes the semantic web robust and scalable to a decentralized global information system, as we are not clinging to words and wording when talking about things. That is the stance that the semantic web takes.
> - One can also argue that this introduces ambiguity which makes conversation harder. And yes, sometimes it does, as identifiers may convey more detail than we are aware (or rather: the sender and the receiver might have different pereceptions on what an identifier identifies).
> But still the basic design decision - and in my understanding that was well before the logicians entered the space - was that this ambiguity, this flexibility is actually more robust and useful than reliance on specific identifiers, on syntactic agreement, which may be very precise but also is stiff and brittle (and, in decentralized global network probably unattainable).
> 
> That is how the semantic web works, and the proposed semantics breaks that mechanism in non-obvious ways. Sure, as you show below, that break can be healed. But even if we thought that such effort was a good idea in the first place there is still no principled answer to the very basic questions: How? When? For whom exactly? Those are questions that would need to be answered to bring the proposed semantics in line with how the semantic web works everywhere else around those embedded triples (and don’t forget they are meant to be used EVERYWHRE, not just for adding provenance annotations). It would need to be defined in terms of a formal model theoretic semantics, not in SPARQL, as otherwise we are back to RDF 1.0 in 1999. And it still would have to present some very good reason to justify the disruption.
> 
> Thomas
> 
> 
> 
>> The definition of the vocabulary in {| |} will define what can be done with the embedded triple.
>>
>> :determination-method can say that D-entailment is valid.  Or it is natural because ^^xsd:integer is used. Who says :A has D-entailemnt?
>>
>> :source will says "the triple is in the graph".
>>
>> :B can decide what it wants to do.
>>
>> As a building block, we need to keep the item quoted as it was, not with additional implications from outside. This leaves the decision of how to unquote to later.
>>
>> :B may conclude that :A was also saying << :ship2 :name 'Happy Cat' >> but that is a conclusion for :B, not :A.
>>
>> A proof chain that ":ship2 :name 'Happy Cat'" would include
>>
>>   << :ship1 :name 'Happy Cat' >> :saidBy :A .
>>   << :ship1 owl:sameAs :ship2 . >> :saidBy :B .
>>
>> Including
>>   << :ship2 :name 'Happy Cat' >> :saidBy :A .
>> would be wrong.
>>
>> -- 
>>
>> The intuition of D-entailment comes from D-entailment being intuitively universal. Just using ^^xsd:integer implies that D-entailment is in effect.
>>
>> Adding an ontology to data from elsewhere should license conclusions in the scope of the ontology.
>>
>> Transparency is allowing retrospective conclusions
>> Opaque allows the embedded triple to used for entailment, or not.
>>
>> :B can decide what it wants to do.
>>
>> -- 
>>
>> We aim to provide a system where the use cases can be addressed - that is not the same as directly solving them with one mechanism.
>>
> 
Received on Tuesday, 11 May 2021 23:57:09 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 11 May 2021 23:57:11 UTC