Re: A question about referential opacity (again)

On 24/10/2023 19:57, Niklas Lindström wrote:
> On Tue, Oct 24, 2023 at 6:42 PM Andy Seaborne <andy@apache.org> wrote:
>>
>>
>>
>> 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?
> 
> I figure an efficient SPARQL parser might have some work to do in
> disambiguating this (excluding surrounding SELECT * { ... }):
> 
>      { ? ?p ?o } <x1> <x2> .
> 
> from:
> 
>      { ? ?p ?o } <x1> <x2> <x3> .

What does this mean? {....} is one term.

A triple is 3 terms, not 4.

Triples are separated by dots.


>
> Even if backtracking from a failed PropertyListPathNotEmpty up via
> TriplesSameSubjectPath and TriplesBlock and then attempting a
> GraphPatternNotTriples, there seems to be ambiguity. Is this:

> 
>      { ?s ?p ?o } <x1> <x2> { ?s ?p ?o } <x1> <x2> <x3> .
> 
> this:
> 
>      { ?s ?p ?o } <x1> <x2> .
>      { ?s ?p ?o }
>      <x1> <x2> <x3> .
> 
> or this:
> 
>      { ?s ?p ?o }
>      <x1> <x2> { ?s ?p ?o } .
>      <x1> <x2> <x3> .
> TriG parsers may have an easier time, but I'm not sure about the
> soundness of such grammar? These would both be allowed, yet mean quite
> different things:

The only unsimple case in TriG is

<name> { :s :p :o }

for

GRAPH <name> { :s :p :o }

which is a fixed lookahead of one over one terminal <name>. Seeing the 
"{" is enough.

>      { <s> <p> <o> } <x1> <x2> .
> 
> from:
> 
>      { <s> <p> <o> } <x1> <x2> <x3> .

??

> 
> Perhaps a marker for graph terms would do, e.g.:
> 
>      %{ <s> <p> <o> } <x1> <x2> .
> 
> (I suppose that could mark them as closed as well.)
> 
> Cheers,
> Niklas
> 
> 
>> <<>> 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

Received on Tuesday, 24 October 2023 19:14:07 UTC