Re: From syntactic to interpreted triple

On 08/02/2021 19:01, Peter F. Patel-Schneider wrote:
> On 2/8/21 11:08 AM, Pierre-Antoine Champin wrote:
>>
>> On 08/02/2021 14:37, Peter F. Patel-Schneider wrote:
>>> On 2/8/21 7:05 AM, Pierre-Antoine Champin wrote:
>>>
>>>> I didn't mean "the proposed semantics can consider embedded RDF* triples as
>>>> referentially transparent". I agree that it does not.
>>>>
>>>> What I meant is "the proposed semantics covers /that use case".
>>>> /Differently, of course, of how if would be covered with
>>>> referentially-transparent triples.
>>>>
>>> You appear to have been referring to the following exchange:
>>>
>>>
>>> On 2/7/21 5:11 AM, Pierre-Antoine Champin wrote:
>>>> On 05/02/2021 23:27, phayes@ihmc.us wrote:
>>> [...]
>>>>> <<:me :travelTo :Berin>> :on :Wednesday .
>>> [...]
>>>>> and it seems to be about :Berlin, the city, rather than ":Berin" the URI.
>>>>> So are y'all on the same wavelength?
>>>> On the question "is the embedded triple asserted or nor", I think we are.
>>>>
>>>> On the question of referential opacity vs. referential transparency, there
>>>> are indeed some discussions.
>>>> The point I have been making in favor of referential opacity is that it is
>>>> more flexible. In other words, use-cases that require referential transparency
>>>> can be addressed with referentially-opaque triples, but the opposite is not true.
>>>> In the "travel to Berlin" example above, of course that the annotation (:on
>>>> :Wednesday) is not about the triple itself, but about the situation described
>>>> by the triple. It seems to me that, as along as we agree that this is the
>>>> semantics of the predicate :on, and we use it consistently, this is not a problem.
>>>> Similarly, consider a predicate :heightInCm, whose range would be xsd:decimal :
>>>>
>>>>      :monalisa :heightInCm "77"^^xsd:decimal.
>>>>
>>>> The height of the Mona Lisa is not a decimal number, but we understand the
>>>> predicate to implictly refer to an intermediate concept (a physical length),
>>>> which in turns is related to the decimal value.
>>>> Does this make sense?
>>> The argument here appears to be that a use case is covered if the semantics
>>> makes strictly fewer entailments than required by the use case.  I don't buy
>>> into that argument.
>> Ok, I read "is covered" as "can be addressed". Arguably this is a very weak
>> notion of "covering", and if Thomas's intent was instead "can be /entirely/
>> addressed", then I retract my remark.
>>
>> That being said, RDF itself has a very weak semantics, and there are very
>> few use-cases that "can be entirely addressed" without additional axioms,
>> rules, or other forms of additional knowledge about the vocabulary used in
>> the graph... I assumed that it was ok for RDF* to require such additional
>> knowledge.
>>
>> Conversely, I am concerned that some entailments may be not just
>> un-required, but undesired for some use-cases. If such entailments were
>> baked into the core semantics of RDF*, then such use-cases could not be
>> addressed at all, regardless of the addition of rules or axioms...
>>
>>> peter
>>>
> Not necessarily.   Mapping semantics for embedded triples can be "extended"
> from transparent to opaque by adding extra triples.

I see how that works in the definition of the mapping, i.e. at the 
general level. But how do you locally add opacity to an embedded triple 
if its default semantics is transparent?

Concretely, assuming that 1) embedded triples are defined to be 
referentially transparent, and 2) C1 and C2 are two terms that are known 
to denote the same thing (either because they are recognized literals 
with the same value, or two IRIs marked as owl:sameAs under OWL-entailment).

Any triple of the form

   :s :p << :a :b C1 >>.

would entails

   :s :p << :a :b C2 >>.

correct?

So in my provenance use-case:

   # file1.ttl contains a triple with predicate :b and object C1 (and an 
unspecified subject)
   <file1.ttl> :contains << [] :b C1 >>.

would automatically entail

   <file1.ttl> :contains << [] :b C2 >>.

which is a spurious inference (file1.ttl does not mention C2, only C1.

I don't see how this could be fixed by adding extra triples, given the 
monotonicity of RDF semantics. Hence my claim that this this use-case 
can not be addressed using transparent embedded triples.

What am I missing?

>
> peter
>
>
> PS:  Of course, *none* of these approaches to embedded triples are ideal, as
> embedding logical syntax inside facts is a very complex notion.
>
>
>