Re: transparency and entailment



> On 17 Feb 2024, at 20:18, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> I think that this characterization is not sufficient for transparency. Consider the CG semantics, which is a macro-expansion that then uses the usual RDF semantics, which does satisfy your criterion.  But the CG version of quoted triples is not transparent.

My characterisation is sufficient whenever RDF has a direct model-theoretic semantics, which the CG semantics is not (it is based on a translation).
RDF-star will have a direct model theoretic semantics, if I am going to remain in the WG :-)
—e.

> 
> peter
> 
> PS:  I suspect that you would want to include literals as well.
> 
> On 2/17/24 10:12, Franconi Enrico wrote:
>> To me, transparency means:
>> given a graph G, II is the set of all IRIs appearing in G and BB is the set of all bnode symbols appearing in G.
>> Then, ∀ i∈II and b∈BB, i and b have the same denotation non matter where they appear within the graph.
>> I guess that your definition below is somehow different, but probably it boils down to mine, which is more clear, I guess.
>> —e.
>>> On 16 Feb 2024, at 18:04, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:
>>> 
>>> Peter,
>>> 
>>> On 09/02/2024 20:24, Peter F. Patel-Schneider wrote:
>>>> There was some discussion of transparency in the semantics call today, with disagreement over just what transparency means.
>>>> 
>>>> My view is that transparency (for well-formed graphs) means that entailments are exactly the same if a subject, predicate, or object in a quoted triple is replaced by a semantically identical identifier.  So if an option for << e | s p o >> is transparent in D-entailment then
>>>> 
>>>> << :e | :s :p "4"^^xsd:integer >> :a :b .
>>>> 
>>>> entails
>>>> 
>>>> << :e | :s :p "04"^^xsd:integer >> :a :b .
>>>> 
>>>> in that option.
>>> 
>>> that's also my interpretation of "transparency".
>>> 
>>> (and I assume that the entailment in your example above works both ways)
>>> 
>>>> 
>>>> 
>>>> peter
>>>> 
>>> <OpenPGP_0x9D1EDAEEEF98D438.asc>

Received on Monday, 19 February 2024 11:52:24 UTC