Re: owl:sameAs/referential opacity Re: Can RDFstar be defined as only syntactic sugar on top of RDF (Re: weakness of embedded triples)

On 11/21/20 7:55 AM, thomas lörtsch wrote:
>
>> [snip]
> This sounds intriguing for several reasons but I still don’t understand how it works. You gave an example for simple entailment a few weeks ago on this thread [0]. That seemed clear to me first but then I seem to miss a step.
>  
> If I got it right, under simple entailment the graph < :a :b :c > entails the graph < _:x :b :c > because from the existance of ':a' we can entail the existance of "something". 
More or less.  It's more like < :a :b :c > requires that the interpretation of
:a is related to the interpretation of :c by the relation that is associated
with the interpretation of :b.  (Remember that :a :b and :c are just bits of
syntax, not things in the world.)  Then < _:x _b :c > is true if there is
something that is related to the interpretation of :c by the relation that is
associated with the interpretation of :b.  The interpretation of :a is a
something that meets this requirement.  So any world where < :a :b :c > is
true also has < _:x :b :c > true, therefore the entailment is valid.
> And if I got it right again, in this discussion referential transparence means that the resource is referencable in the interpretation domain and therefor available to entailments whereas under referential opaqueness it doesn’t get interpreted and is not visible in the domain.
>
> But how does all this translate to the Superman scenario?
> Given that
>
>  ex:ClarkKent owl:sameAs ex:Superman
>
> why is it that the graph
>
>  _:b rdf:subject ex:ClarkKent 
>
> entails
>
>  _:b rdf:subject ex:Superman
>  
> whereas
>
>  ex:X rdf:subject ex:ClarkKent 
>
> doesn’t entail
>
>  ex:X rdf:subject ex:Superman
>
> ???

I don't like this example at all.   It requires that there be something to
force the interpretation of ex:ClarkKent be the same as the interpretation of
ex:Superman, which is not part of RDF.   So let's do an example with something
that is part of RDF  Oh wait, there isn't such an example.   The best that can
be done is to work in RDF plus the standard interpretation of integers, so
that the interpretation of "42"^^xsd:integer is the same as the interpretation
of "042"^^xsd:integer.

So here you get < _:x ex:b "42"^^xsd:integer > entailing < _:x ex:b
"042"^^xsd:integer > and < ex:a ex:b "42"^^xsd:integer > entailing < ex:a ex:b
"042"^^xsd:integer >


>
> Properly parapharsing your example from [0] would give that
>
>  ex:X rdf:subject ex:ClarkKent 
>
> doesn’t entail
>
>  ex:Y rdf:subject ex:Superman // Y instead of X
>
> - which I understand - but is that the question here? 
> Isn’t the entailment that 
>
>  ex:X rdf:subject ex:Superman    // X again
>
> the entailment that the RDF* semantics proposal tries to suppress?
The issue with respect to RDF* is just what the meaning of embedded triples is
supposed to be.   There are many different possibilities, some of which are
defined by mappings from RDF* to RDF.

In one of these mappings embedded triples become blank nodes, so we get
something like

< ex:q ex:r << ex:a ex:b "42"^xsd:integer >> >

being turned into

< ex:q ex:r _:ex_aex_b_42_xsd_integer >
< _:ex_a_ex_b_42_xsd_integer rdf:type rdf:Statement >
< _:ex_a_ex_b_42_xsd_integer rdf:subject ex:a >
< _:ex_a_ex_b_42_xsd_integer rdf:predicate ex:b >
< _:ex_a_ex_b_42_xsd_integer rdf:object "42"^xsd:integer >

and

< ex:q ex:r << ex:a ex:b "042"^xsd:integer >> >

being turned into

< ex:q ex:r _:ex_aex_b_042_xsd_integer >
< _:ex_a_ex_b_042_xsd_integer rdf:type rdf:Statement >
< _:ex_a_ex_b_042_xsd_integer rdf:subject ex:a >
< _:ex_a_ex_b_042_xsd_integer rdf:predicate ex:b >
< _:ex_a_ex_b_042_xsd_integer rdf:object "042"^xsd:integer >

Here the former entails the latter because the identity of the blank node
bdoesn't matter.
(Yes, blank nodes don't have identifiers per se.  I'm just using the
identifier as a way of identifying the blank node itself.  And yes, triples
and literals don't have CURIES.  I'm just using them as shorthands for IRIs
and parts of literals.)


In another these mappings embedded triples become IRIs, so we get something like

< ex:q ex:r << ex:a ex:b "42"^xsd:integer >> >

being turned into

< ex:q ex:r ET:ex_aex_b_42_xsd_integer >
< ET:ex_a_ex_b_42_xsd_integer rdf:type rdf:Statement >
< ET:ex_a_ex_b_42_xsd_integer rdf:subject ex:a >
< ET:ex_a_ex_b_42_xsd_integer rdf:predicate ex:b >
< ET:ex_a_ex_b_42_xsd_integer rdf:object "42"^xsd:integer >

and

< ex:q ex:r << ex:a ex:b "042"^xsd:integer >> >

being turned into

< ex:q ex:r ET:ex_aex_b_042_xsd_integer >
< ET:ex_a_ex_b_042_xsd_integer rdf:type rdf:Statement >
< ET:ex_a_ex_b_042_xsd_integer rdf:subject ex:a >
< ET:ex_a_ex_b_042_xsd_integer rdf:predicate ex:b >
< ET:ex_a_ex_b_042_xsd_integer rdf:object "042"^xsd:integer >

Here the former does not entail the latter because there is nothing in the
former that constrains the interpretation of ET:ex_a_ex_b_042_xsd_integer.

It is true, of course that the former entails

< ex:q ex:r _:ex_aex_b_042_xsd_integer >
< _:ex_a_ex_b_042_xsd_integer rdf:type rdf:Statement >
< _:ex_a_ex_b_042_xsd_integer rdf:subject ex:a >
< _:ex_a_ex_b_042_xsd_integer rdf:predicate ex:b >
< _:ex_a_ex_b_042_xsd_integer rdf:object "042"^xsd:integer >

but in this version of RDF* this last is not the meaning of an embedded triple.


So it's not about two different literals (or IRIs) having the same
interpretation but instead about whether embedded triples become blank nodes
or IRIs.


>
>
> Thomas
>
>
>> This gives something to talk about that doesn't underdefined terms like triple
>> token and triple type but nonetheless distinguishes between a triple and an
>> occurrence of a triple in a document.
>>
>> peter
> [0] https://lists.w3.org/Archives/Public/public-rdf-star/2020Oct/0085.html
>

Received on Saturday, 21 November 2020 15:06:39 UTC