Reification and Entailment

Hi everyone, sorry in advance if I'm starting yet another thread on 
visited topics, but I'm starting to get a bit lost in all the emails. 
Would it be possible to find a place to organize and have a clear views 
of the different points of disagreement and the different arguments? 
Maybe github issues? Like "Reification, what it is, why you should be 
worried" with some definition and criticism, so we don't have to read 
all the history of the minutes and mailing list to piece together the 
opinions on a given topic. I don't know but I'm loosing track a bit.

Anyway, I see a lot of discussions about the semantics of entailment we 
want for the future quoted triples. I also remember a discussion a while 
back about defining quoted triples by reification, and I'm unclear what 
the consensus was at the end of the thread, if there was one. Some 
people seemed to be satisfied with the proposition, but I don't know 
about the majority. Now that I'm starting to have a better understanding 
of the problem, I'd like to give my opinion on both, so you can tell my 
why I'm wrong or stating the obvious :)

# On reification

I happen to think this is a good idea, that quoted triples could be just 
syntactic sugar for (some) `rdf:Statement`. The problem of course is the 
design of a function that can map RDF-star constructions including 
quoted triples to RDF ones. There is a definition by the community group 
[1], and also I believe one defined a few months ago in the mailing 
list. In both cases, I was not satisfied about or did not understand how 
they dealt with open triples containing blank nodes.

[1]: https://www.w3.org/2021/12/rdf-star.html#mapping

For me, such function must allow two things when two graphs are merged 
(after desugarization):
   - ground triples must be merged when equivalent
   - open triples from different graphs must not be merged. That's the 
point I'm not seeing in the previous propositions but I may be wrong.

Here is my attempt at yet-again defining the same mapping function `map` 
from RDF-star to RDF:
```
map(<IRI>) = <IRI>
map(_:blank) = _:blank
map("literal") = "literal"
map(<<S P O>>) = reify(map(S), map(P), map(O))
```

where `reify` helps convert a quoted triple into a `rdf:Statement`:
```
reify(S, P, O) = <http://www.w3.org/reify/S/P/O> if (S P O) is groud
                = _:S:P:O                         otherwise
```
for each RDF components `S`, `P`, `O`, if `S P O` is ground:
```
<http://www.w3.org/reify/S/P/O> a rdf:Statement;
   rdf:subject S;
   rdf:predicate P;
   rdf:object O.
```
and if `S P O` is open:
```
_:S:P:O a rdf:Statement;
   rdf:subject S;
   rdf:predicate P;
   rdf:object O.
```

Ground triples are given a unique IRI, which allows two graphs 
containing the same quoted ground triples to be merged together. Open 
triples are given a blank node identifier unique to the graph it appears 
in. Of course we must be careful how we build the 
`http://www.w3.org/reify/S/P/O` and `_:S:P:O` blank id, but you get the 
idea.

Some remarks:

  * I know there have been some concerns in the meetings about having
    RDF-star generate made up IRIs.
  * I also know the CG avoided using `rdf:Statement` but it seemed
    appropriate to me (I'm sure they had a good reason though).
  * Finally in the minutes [2] Enrico stated "the way of using reified
    triples to represent model predication does not have a simple
    counter part in model theory". But I'm not sure I understand that
    (and if I'm not sure, then I probably don't).

[2]: https://www.w3.org/2023/01/12-rdf-star-minutes.html


# Entailment

Now that quoted triples are mere `rdf:Statements` we need to sort out 
how to define entailment over them. I don't think we will be able to do 
much here. The way I see it, we already reified statements so let's 
reify entailment. We could define some `rdf:entails` relation between 
`rdf:Statement`s, where:

   (`S1 P1 O1` entails `S2 P2 O2`)
   entails
   `<<S1 P1 O1>> rdf:entails <<S2 P2 O2>>`

After that, let the user define the entailment semantics for each 
property with extensions. It is still technically referencially opaque 
(if I understand correctly), but I think that's the least we can do, and 
maybe the most actually. Because as far as I understand the expected 
entailment can widely differs from property to property so I don't think 
we will be able to generalize more than that. I see a wide variety of 
cases with different expected entailment:

  * Epistemic properties like `:knows` and `:deduce` where we expect
    `<<S1 P1 O1>> rdf:entails <<S2 P2 O2>>` and
    `:Bob :knows <<S1 P1 O1>>` entails
    `:Bob :deduce <<S2 P2 O2>>`
  * Some stronger `:knowsOrDeduce` where we expect
    `<<S1 P1 O1>> rdf:entails <<S2 P2 O2>>` and
    `:Bob :knowsOrDeduce <<S1 P1 O1>>` entails
    `:Bob :knowsOrDeduce <<S2 P2 O2>>`
  * Annotations like `:label` where we expect
    `<<S1 P1 O1>> rdf:entails <<S2 P2 O2>>` and
    `<<S1 P1 O1>> :label "My favorite statement"` does NOT entail
    `<<S2 P2 O2>> :label "My favorite statement"`
  * Some other relation that is closed by `rdf:entails` like
    `:isAsserted`, where we expect
    `<<S1 P1 O1>> rdf:entails <<S2 P2 O2>>` and
    `<<S1 P1 O1>> :isAsserted "true"^^xsd:boolean` entails
    `<<S2 P2 O2>> :isAsserted "true"^^xsd:boolean`
  * ... and more


One of those cases could be handled natively with selective referential 
transparency [3], but that's just one case.

[3]: https://www.w3.org/2021/12/rdf-star.html#selective-ref-transparency

# SPARQL-star

I don't know much about SPARQL, I never used it, but I at least know 
that if quoted triples are plain ol' `rdf:Statement`s, then it already 
works with current implementations. And I'm pretty sure we can use the 
same desugarisation `map` function on queries. And for the response, 
some resugarisation `unmap` function maybe, it shouldn't be hard to define.

Best,
-- 
Timothée