Re: From syntactic to interpreted triple

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. 


peter


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

Received on Monday, 8 February 2021 18:01:50 UTC