Re: From syntactic to interpreted triple

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
>
>