Re: RDF-star semantics: option 3 (first DRAFT)

On 16/02/2024 19:01, Franconi Enrico wrote:
> Simple entailment matching can be done once you have done the 
> /ENCODING/ in rdf:nameOf, rdf:subject, … (option 2). 
You got me confused here...
How does this notion of "encoding" fit in the "concrete syntax / 
abstract syntax / semantics" landscape ?

I assume that maybe , what you mean by "encoding" is the thing Adrian 
proposed yesterday: that we define RDF 1.2 "full" as option 3, but that 
we propose an encoding for people who want to stick to option 2. But for 
me we need to have a complete story for option 3 a.k.a. RDF 1.2 Full. 
Then we can discuss about the encoding.

If you mean something else by "encoding", then I really don't see what 
that is.

Also, "triple occurrences" in the abstract syntax is neither part of 
option 2 nor option 3 -- so whatever you mean by encoding, I must say 
this addition comes as a surprise...

   pa

> Indeed, this can be done also if we keep triple terms and rdf:nameOf 
> and drop triple occurrences, but also keeping the well-formedness 
> condition (rdf:nameOf triples are the only ones where triple terms can 
> appear, and only in object position).
> —e.
>
>
>> On 16 Feb 2024, at 18:48, Pierre-Antoine Champin 
>> <pierre-antoine@w3.org> wrote:
>> On 16/02/2024 18:37, Franconi Enrico wrote:
>>> I am advocating (in my last email) just the opposite approach:
>>>
>>> - *disallow* triple terms, e.g.:
>>>
>>>     (triple-term (iri "ex:s") (iri "ex:p") (iri "ex:o))
>>>
>>> - and *disallow* rdf:nameOf triples, e.g.:
>>>
>>>     (triple

>>>        (iri "ex:e")

>>>        (iri "rdf:nameOf")

>>>        (triple-term (iri "ex:s") (iri "ex:p") (iri "ex:o))
  )
>>>
>>> - *keep only* triple occurrences terms, e.g.:
>>>     (triple
>>>        (triple-occurence (iri "ex:e") (iri "ex:s") (iri "ex:p") (iri 
>>> "ex:o))
>>>        (iri "ex:a”)
>>>        (iri "ex:b”)
>>>       )
>>>
>>> Just like in CG, there is simple encoding (in the shape of option 2) 
>>> in which simple entailment based on matching works.
>>
>> Even if we disallow triple terms and keep only term occurrences, the 
>> entailment between the first 2 graphs in my email holds, despite the 
>> fact there is no subgraph of one that is an instance of the other -- 
>> i.e. no pattern matching between them.
>>
>> Besides simple entailment, this means that SPARQL results will be 
>> tricky to define. What should
>>
>>     SELECT ?x { ?x :a :b }
>>
>> return for this graph ?
>> x = (triple-occurrence (iri "ex:e") (iri "ex:s") (iri "ex:p") (iri 
>> "ex:o")) -- as suggested by the 1st graph?
>> Or x = (iri "ex:e"), as suggested by the 2nd graph?
>> Or both??
>>
>>> —e.
>>>
>>>
>>>> On 16 Feb 2024, at 18:17, Pierre-Antoine Champin 
>>>> <pierre-antoine@w3.org> wrote:
>>>>
>>>> Thanks Enrico for this proposal.
>>>>
>>>> I strongly suggest that we get rid of the orange part, with an 
>>>> argument similiar to what Andy brought up during the Semantics TF 
>>>> call today -- and pushing Andy's argument forward.
>>>>
>>>> The orange part make "triple occurrences"  part of the abstract 
>>>> syntax. Regardless of the name, I think it is a bad idea.
>>>>
>>>> In the following, I'll use a lisp-like representation of the 
>>>> *abstract* syntax, hopefully self-explanatory.
>>>>
>>>> (graph
>>>>   (triple
>>>>     (triple-occurence (iri "ex:e") (iri "ex:s") (iri "ex:p") (iri 
>>>> "ex:o))
>>>>     (iri "ex:a")
>>>>     (iri "ex:b")
>>>>   )
>>>>   (triple
>>>>     (iri "ex:e")
>>>>     (iri "ex:c")
>>>>     (iri "ex:d")
>>>>   )
>>>> )
>>>>
>>>> According to your semantics, it would be semantically equivalent to 
>>>> the following graph
>>>>
>>>> (graph
>>>>   (triple
>>>>     (iri "ex:e")
>>>>     (iri "ex:a")
>>>>     (iri "ex:b")
>>>>   )
>>>>   (triple
>>>>     (triple-occurence (iri "ex:e") (iri "ex:s") (iri "ex:p") (iri 
>>>> "ex:o))
>>>>     (iri "ex:c")
>>>>     (iri "ex:d")
>>>>   )
>>>> )
>>>>
>>>> which would also be equivalent to
>>>>
>>>> (graph
>>>>   (triple
>>>>     (iri "ex:e")
>>>>     (iri "ex:a")
>>>>     (iri "ex:b")
>>>>   )
>>>>   (triple
>>>>     (iri "ex:e")
>>>>     (iri "ex:c")
>>>>     (iri "ex:d")
>>>>   )
>>>>   (triple
>>>>     (iri "ex:e")
>>>>     (iri "rdf:nameOf")
>>>>     (triple-term (iri "ex:e") (iri "ex:s") (iri "ex:p") (iri "ex:o))
>>>>   )
>>>> )
>>>>
>>>> We are talking about *simple entailment* here, not some 
>>>> sophisticated semantic extension.
>>>> This breaks a very important feature of the simple entailment in 
>>>> RDF 1.1, namely: it can be computed by doing simple pattern 
>>>> matching of graphs: 
>>>> https://www.w3.org/TR/rdf11-semantics/#dfn-interpolation

>>>>
>>>> Clearly, there is no simple pattern matching method that can detect 
>>>> that the 3 graphs above entail each other.
>>>>
>>>>   pa
>>>>
>>>>
>>>> On 16/02/2024 15:58, Franconi Enrico wrote:
>>>>> RDF‐star semantics: option 3 
>>>>> <https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-semantics:-option-3>
>>>>> github.com 
>>>>> <https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-semantics:-option-3>
>>>>>  <apple-touch-icon-180x180-a80b8e11abe2.png> 
>>>>> <https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-semantics:-option-3> 
>>>>>
>>>>>
>>>>> <https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-semantics:-option-3>
>>>>>
>>>> <OpenPGP_0x9D1EDAEEEF98D438.asc>
>>>
>> <OpenPGP_0x9D1EDAEEEF98D438.asc>
>