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

Thanks, Peter! Now it’s quite clear even to me. 
There’s two reasons why I like this proposal:

1) it reuses something that we already have: RDF standard reification. RDF standard reification may be controversial but it has its merits: it is, despite its verbosity, arguably a concise way to represent triples with triples and its semantics is, although neither normative nor complete, well formalized.

2) and more importantly: it better fits the purpose. RDF standard reification denotes triple occurrences whereas the proposed RDF* semantics denotes classes of triples (the classes themselves, not their extensions of all triple occurrences that belong to those classes). Given the envisioned usage - e.g. provenance recording of triple occurrences - the RDF standard reification based semantics is clearly a better fit. 
The current proposal will work as a hack but sooner or later it will get in the way of a semantics that properly denotes triple occurrences or that does indeed want to denote classes of triples, not triple occurrences. It is a SNAFU bound to happen. It also seems awkward to define in meticulous detail the class of triples with a leading zero in front of some integer when really one wants to refer to a particular occurrence - it might work in practice, but it feels wrong and weird and experience says that such hacks can cause a lot of pain in the long run. 

The current proposal does however fit well the case of annotating triples that have not been and shall not be asserted. Here the referents are indeed not triple occurrences but triple classes. So maybe use both semantics?

One thing is missing from both semantics: a sound way to refer to an actual triple occurrence. The proposed RDF* semantics has no way to do that properly - it would be just a hack on top of a hack. RDF standard reification as well doesn’t provide the link between the reified triple and the triple occurrence it reifies. I have never understood why it doesn’t or can’t do that. I would hope that it would be possible to define at least a default that a reified triple denotes a triple occurrence of that type in the same graph. If no such triple exists it might be defined to denote the triple itself (aka the abstract triple, triple type, class of such triples).


I have some further syntactic ideas that I’d like to get out before they get lost (in my head). 
They concern both semantics in both referantially opaque and transparent versions.

<< :a :b :c >> 
denotes a triple occurrence in the same graph. This the default case. 
If this is referentially opaque or transparent has to be decided.

<< :a :b :c [] >> 
same as before, but explicitly referentially transparent.

<< :a :b :c <> >> 
same as before, but explicitly referentially opaque.

<< :a :b :c () >> 
denotes the triple (aka abstract triple, triple type, class of such triples).
If this is referentially opaque or transparent has to be decided, probably along the default case above. 

<< :a :b :c {} >> 
denotes the extension of the triple class, all its occurrences.
Just for completeness. Maybe this is not useful or maybe it’s outright dangerous as it might invite paradoxes.

<< :a :b :c :g >> 
last not least the added :g would denote some triple occurrence in some spefic, probably distant graph. But it could also be a more explicit way to describe the current graph, and depending on the graph name (blank node or IRI) it would be referentially transparent or opaque.


Thomas



> On 21. Nov 2020, at 16:06, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> 
> 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 Sunday, 22 November 2020 22:34:33 UTC