Re: A question about referential opacity (again)

On 24/10/2023 16:40, Niklas Lindström wrote:
> Dear Dörthe,
> 
> I assume that your worry is that for graph terms to work, you'd have
> to match its signature (or arity)? I don't think that's an issue. If
> this:
> 
>      << dbr:Linköping ex:locatedIn dbr:Sweden >> ex:statedAt
> "2023-10-23"^^xsd:date .
> 
> Was replaced with, or equivalent to (ignoring that this N3 cannot work
> in TriG without lookahead parsing dealing with ambiguity, due to
> default graph blocks):
> 
>      { dbr:Linköping ex:locatedIn dbr:Sweden } ex:statedAt
> "2023-10-23"^^xsd:date.
> 
> And that thus, this is also possible:
> 
>      {
>        dbr:Linköping a ex:City ;
>          ex:locatedIn dbr:Sweden
>      } ex:statedAt "2023-10-23"^^xsd:date.
> 
> Then I'd assume a query like (again ignoring that this syntax probably
> won't fly in SPARQL):

Why not?

<<>> has little impact on BGP matching and it too goes inside an RDF 
term to match.

> 
>      SELECT ?p ?o ?date {
>        { dbr:Linköping ?p ?o } ex:statedAt ?date
>      }
> 
> Would yield:
> 
>      | ex:locatedIn | dbr:Sweden | "2023-10-23"^^xsd:date |
> 
> In fact, this:
> 
>      SELECT ?p ?o ?date {
>        { dbr:Linköping ?p ?o. ?s1 ?p1 ?o1 } ex:statedAt ?date
>      }
> 
> should match too, just binding ?s1, ?p1 and ?o1 to each of the two
> triples in turn (so an unperformant query, with unused redundant
> results).
> 
> This is based on what I think James also answered, that for named
> graphs, if you have:
> 
>      _:g1 {
>        dbr:Linköping a ex:City ;
>          ex:locatedIn dbr:Sweden
>      }
>      _:g1 ex:statedAt "2023-10-23"^^xsd:date ;
>        ex:source wikipedia:Linköping .
> 
> then this works:
> 
>      SELECT ?p ?o ?date {
>        graph ?g { dbr:Linköping ?p ?o. ?s1 ?p1 ?o1 }
>        ?g ex:statedAt ?date .
>      }
> 
> This is because SPARQL BGPs in graph blocks match what's there;
> they're not excluding graphs containing more triples. (I'm sure e.g.
> Andy would phrase this much more correctly.)
> 
> This all said, I'm unconvinced of either triple or graph terms, as
> they make it possible to talk about the abstract type itself, as
> opposed to a reified occurrence thereof (which when talked about is a
> token of the type). But I'll write more about that in another reply.
> 
> All the best,
> Niklas
> 
> On Mon, Oct 23, 2023 at 6:07 PM Doerthe Arndt
> <doerthe.arndt@tu-dresden.de> wrote:
>>
>> Dear Thomas, all,
>>
>> In addition to what Peter said about RDF-star semantics and opacity, I’d like to clarify the community group semantics a little bit more: remember that we talk about the meaning of triple terms and not of the constituents (subject, predicate, object) of these terms. What was done in the unstar-mapping was a kind of reification with which we represented the triple with a blank node and then connected the iris of the constituents to this blank node (using the correct predicates) and also the lexical representation of these constituents. With this „trick“ we allowed that the quoted triple interpretation to be aware of the lexical representation of the triple and, if needed, to differentiate between triples having different interpretations, but that was not forced and as Peter also mentioned, the concrete interpretation was left open.
>>
>> For the working group semantics several possibilities have been discussed and they all rely on an interpretation function for the triple term (for example IT in Enrico’s case). This function maps to a resource (and it can do more, but does not need to). The interpretation function for the triple term can be applied on triples from the domain of discourse (then we can indeed combine it with IS or some alternative IS’), but it would for example also be possible to apply the IT function directly on the graphical representation of the triple (of course we need to be careful with blank nodes here). My point is just: please try to see the triple term  as a whole also as a resource to better understand the opacity.
>>
>> To the rest of the discussion and the added complexity: apart from all the theoretical aspects we discuss here (and where I agree that graphs are more complex than triples), please also note that we would have to decide howto deal with quoted graph terms in practice. In SPARQL queries, it is relatively easy to search for a triple term having dbr:Linköping as subject, like:
>>
>> Select ?p ?o ?date
>> {
>>    << dbr:Linköping ?p ?o>> ex:statedAt ?date
>> }
>>
>> But to make a similar query for graphs, we either need to know the exact structure of the graph (that is: how many triples does it contain?) or we need to come up with extra Filter functions for SPARQL.
>> If we have
>>
>>    { dbr:Linköping a ex:City; ex:locatedIn dbr:Sweden}  ex:statedAt „23.10.2023“^^xsd:date.
>>
>> A query
>>
>> Select ?p ?o ?date
>> {
>>    {dbr:Linköping ?p ?o. ?s1 ?p1 ?o1} ex:statedAt ?date
>> }
>>
>> Would fire, but
>>
>> Select ?p ?o ?date
>> {
>>    {dbr:Linköping ?p ?o. ?s1 ?p1 ?o1. ?s2 ?p2 ?o3} ex:statedAt ?date
>> }
>>
>> would not. I am sure we can solve this problem together, but this adds complexity since we need to have a discussion on how we would like to solve it.
>>
>> Side note: in N3 we would have a predicate log:includes for that and while it makes this case easier, it also adds complexity simply because your graph terms can contain blank nodes and you are back to a problem of simple entailment… (and I will not go further unless you ask :) )- In N3 you would do something like (I try to make it „SPARQL-style“ but I am not sure whether or not this makes it clear, so, feel free to ask):
>>
>> Select ?p ?o ?date
>> {
>>    ?graph  ex:statedAt ?date.
>>    ?graph log:includes {dbr:Linköping ?p ?o. }.
>> }
>>
>>
>> The log:includes is some kind of function which can give you elements of your graph.
>>
>> I just added this here as one example to illustrate that Peter is right here: things get more complex if we have graph terms. I am sure that we can solve that together and I would like to do that with all of you, but at the same time I am worried that it will take too long…
>>
>> Kind regards,
>> Dörthe
>>
>>
>>> Am 23.10.2023 um 16:47 schrieb Peter F. Patel-Schneider <pfpschneider@gmail.com>:
>>>
>>> There is no restrictions on the sharing of resources between different interpretations in the RDF semantics.  Different interpretations of the same RDF graph can share resources.  Different interpretations of different RDF graphs in an RDF dataset can share resources.  Different interpretations of different RDF graphs that are not in an RDF dataset can share resources.
>>>
>>> But there is nothing in the formal semantics of RDF graphs that depends on sharing or not sharing, except for the denotations of literals.  So no formal consequences would arise from forbidding interpretations sharing resources, again except for value spaces of datatypes.
>>>
>>> On the other hand, much of the "intended" meaning of RDF graphs implies that different interpretations share resources, i.e., that the denotation of many IRIs are intended to be in some sense fixed between some interpretations.  One can even imagine a variation on RDF semantics where the denotation of an IRI is required to be the same in all interpretations.   This semantics would have to be somewhat unusual but it could be made to work.
>>>
>>> Requiring denotation of IRIs to be fixed within an RDF dataset would likely also need an unusual semantics if it was to handle things like beliefs (or indeed any other kind of varying view of the identity of things in the world).
>>>
>>> peter
>>>
>>>
>>>
>>>
>>> On 10/23/23 09:00, Niklas Lindström wrote:
>>>> On Sat, Oct 21, 2023 at 2:22 PM Peter F. Patel-Schneider
>>>> <pfpschneider@gmail.com> wrote:
>>>>>
>>>>> It's important to be clear as to what is formal and what is informal in
>>>>> discussions of this sort.
>>>>>
>>>>> Formally in the current semantics for RDF, all IRIs are mapped (via the map
>>>>> IS) to resources by interpretations in RDF.  One generally says that an IRI E
>>>>> denotes or refers to IS(E).
>>>> Is it correct that the interpretation I of a graph G in a dataset D
>>>> must not by definition share its "domain/universe" (that is its
>>>> non-empty set IR of resources) with another graph G' in D (or any
>>>> other dataset)? That is, this is undefined (i.e. this is the lack of
>>>> semantics for datasets)?
>>>> And if these universes may be different, is there possibly a different
>>>> interpretation for each graph within the same dataset (or any
>>>> combination of shared and isolated interpretations)?
>>>> And finally, would the definition of such shared or not shared
>>>> interpretations constitute a semantics for datasets? (Possibly, but
>>>> perhaps not necessarily, in conjunction with a definition for what the
>>>> relation is between the name and the graph in a named graph pair?)
>>>> /Niklas
>>>>> A formal semantics that provides for referential opacity of IRIs generally
>>>>> provides a different mapping (let's call it IS') for IRIs that occur in opaque
>>>>> contexts, i.e., inside triple terms.   The details may differ, but the targets
>>>>> of this mapping are usually either left unspecified or are to some synthetic
>>>>> resources (such as copies of IRIs).
>>>>>
>>>>> So if one was to construct an interpretation in this sort of formal semantics
>>>>> that actually included real cities in the world as resources and whose IS
>>>>> mapping mapped IRIs that are generally accepted as names of cities to the
>>>>> actual cities one would say that in transparent contexts, i.e., subjects,
>>>>> objects, and properties of asserted triples, dbr:Linköping refers to the city
>>>>> of Linköping but in opaque contexts, i.e., in triple terms, refers to
>>>>> something else.  (It may be possible that some interpretations dbr:Linköping
>>>>> in an opaque context does refer to the city, but the important point is that
>>>>> there are interpretations where dbr:Linköping in an opaque context does not
>>>>> refer to the city and that absent special constructs to force transparency on
>>>>> opaque contexts there is no way to force an RDF graph to be false in all these
>>>>> interpretations.)
>>>>>
>>>>> peter
>>>>>
>>>>> PS: The coordination group semantics uses a different mechanism entirely,
>>>>> instead syntactically transforming graphs that contain triple terms to regular
>>>>> RDF graphs.  Among other things, the opacity mechanism in this treatment
>>>>> transforms IRIs in triple terms to literal strings.  So part of this semantics
>>>>> is a relationship (similar to but not exactly denotes) from IRIs in opaque
>>>>> contexts to sequences of Unicode code points.
>>>>>
>>>>> PPS:  There are other ways of obtaining opacity.  If the working group
>>>>> switches to graph terms the kind of semantics described above might not be
>>>>> adequate and some other treatment might have to be used.
>>>>>
>>>>>
>>>>>
>>>>> On 10/21/23 07:00, Thomas Lörtsch wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> Enrico was kind enough to guide me through the work of the Semantics TF in a one-on-one TelCo a week ago. However, when I now look at my notes, I’m again confused.
>>>>>>
>>>>>> If I understood Enrico correctly then a referentially opaque IRI doesn’t refer to anything. However, it was my understanding of the CG report semantics that IRIs in quoted triples are interpreted, but strictly following the syntactic form. My reading of the unstar-mapping supports that intuition [1].
>>>>>> To give an example, I understood referential opacity as meaning that "dbr:Linköping" and "DBR:LINKÖPING" both refer to the city of Linköping, and yet are not equal (and can not infered to be equal) because their lexical representation differs.
>>>>>> But according to how I understood Enrico they don’t refer to anything.
>>>>>>
>>>>>> Was I wrong all along? Am I just not getting it and does there exist a world in which both interpretations are true? Or has the TF diverged from the CG? Or is there no consensus in the TF?
>>>>>>
>>>>>>
>>>>>> Best,
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [0] https://github.com/w3c/rdf-star-wg/wiki/Semantics%3A-Behaviour-catalogue
>>>>>> [1] https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html#mapping
>>>>>
>>>
>>
>

Received on Tuesday, 24 October 2023 16:41:53 UTC