Re: drop referentially opaque semantics in embedded triples

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; it is about 
binding and scoping.

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.

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 Monday, 10 May 2021 17:05:36 UTC