Re: From syntactic to interpreted triple

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.

peter

Received on Monday, 8 February 2021 13:37:26 UTC