Re: blank nodes are not transparent in the community group semantics

My takeaway from all this is that there may be a tension between calling blank 
nodes in quoted triples "transparent" and the non-entailments that some people 
want.

Also see some comments below.




On 5/5/23 06:26, Doerthe Arndt wrote:
> Dear Peter,
> 
> 
>>
>> I was thinking about the various semantics for RDF-star and noticed something strange when equality (or any means to enforce equality) is considered.
>>
>> In the community report I would have thought that
>>
>> _:k owl:sameAs :j .
>> _:l owl:sameAs :j .
>> :c :d << _:k :y :z >> .
>> :a :b << _:l :y :z >> .
>>
>> entails
>>
>> :a :b << _:m :y :z >> .
>> :c :d << _:m :y :z >> .
>>
>> because blank nodes are supposed to be transparent and so only their meaning counts.
> 
> That is very interesting because I would not have expected that derivation.
>   
> I would like to be able to get from
> 
> :a :b <<:a :x :z>>.
> 
> to
> 
> _:a :b <<_:a :x :z>>.
> 
> and I think that is problematic  if we also allow the entailment you envision. Let’s assume that we have
> 
> :a :b <<:a :x :z>>.
> :aa :b <<:aa :x :z>>.
> :a owl:sameAs :aa.
> 
> And that additionally, we would like
> <<:a :x :z>> and <<:aa :x :z>> be interpreted as different elements of the domain of discourse.
> 
> If we go for my entailment, we get
> 
> _:a :b <<_:a :x :z>>.
> _:aa :b <<_:aa :x :z>>.
> 
> _:a owl:sameAs _:aa.
> 
> with your entailment, we would get then that
> 
> _:a  :b <<_:aa :x :z>>.
> and
> _:aa  :b <<_:a :x :z>>.
> 
> and that is problematic.

There is a simpler and, to me, unassailable way to get this entailment.

From:

_:a :b <<_:a :x :z>>.
_:aa :b <<_:aa :x :z>>.
_:a owl:sameAs _:aa.

using the second and third triples we get directly

_:a :b <<_:aa :x :z>>.

without doing anything inside the quoted triples.  Similarly for

_:aa :b <<_:a :x :z>>.

> 
>  From my point of view, in the opaque quoted graph, not the meaning of a sign matters but its representation. So, if we quantify into a quoted graph, we suddenly do not only need to take the meaning of the blank node into account but also a possible literal or uri representation for it. Of course, this only works if the interpretation of the representation is the same as the meaning of the blank node (something like A(_:x)=IS(representation) or A(_:x)=IL(representation)). But these would be considerations to make if we’d go for direct semantics and would choose this point of view.
> 
> 
> Of course this discussion brings us back to the use cases: which entailments do we want to happen and which not?
> 
> 
> 
>>
>> But this is not the case because the first graph turns into (roughly)
>>
>> _:k owl:sameAs :j .
>> _:l owl:sameAs :j .
>> :a :b _:kyz .
>> _:kyz unstar:subject _:k .
>> _:kyz unstar:predicate :y .
>> _:kyz unstar:object :z .
>> _:kyz unstar:predicateLexical ":y"^^xsd:string .
>> _:kyz unstar:objectLexical ":z"^^xsd:string .
>> :c :d _:lyz .
>> _:lyz unstar:subject _:l .
>> _:lyz unstar:predicate :y .
>> _:lyz unstar:object :z .
>> _:lyz unstar:predicateLexical ":y"^^xsd:string .
>> _:lyz unstar:objectLexical ":z"^^xsd:string .
>>
>> and part of what the second graph turns into is
>>
>> :a :b _:myz .
>> :c :d _:myz .
>>
>> So the identity of _:k and _:l is important, not just their denotation.
> 
> As explained before, at least from my part, that was on purpose. Whether we want to keep that, is of course another discussion and will depend on the use cases.
> 
> 
> Kind regards,
> Dörthe
> 
>>
>> peter
>>
> 

Received on Friday, 5 May 2023 12:41:35 UTC