Re: [External] : Re: handling ("asserted") s-p-o triples and ("stated" or "reified") id-s-p-o 4-tuples in RDF/SPARQL

Here is a simplified version of the SPARQL pattern extensions needed to retrieve (asserted) s-p-o triples, stated id-s-p-o tuples, and reified id-s-p-o tuples. (See [1] and its followup in [2] for the original version.) Please note that this is purely for SPARQL –  entailment does not play any role.

Types of tuples :
============
    type [A] => :s :p :o . ==> (asserted) s-p-o triple
    type [S] => :id rdf:states <<( :s :p :o )>> . ==> "stated" id-s-p-o tuple (s-p-o triple under id)
    type [R] => :id rdf:reifies <<( :s :p :o )>> . ==> "reified" id-s-p-o tuple (s-p-o tuple under id)

SPARQL pattern extensions: (to allow retrieval of all seven non-empty subsets in the power set: [A], [S], [R], [AS], [SR], [AR], [ASR] )
=======================
0) [A] To find (asserted) s-p-o triples only ==> ?s ?p ?o .
1) [AS] To find (asserted) s-p-o triples and "stated" id-s-p-o tuples ==> ?id ~ ?s ?p ?o .
2) [AR] To find (asserted) s-p-o triples and "reified" id-s-p-o tuples ==> ?id | ?s ?p ?o .
3) [ASR] To find all – (asserted) s-p-o triples, "stated" id-s-p-o tuples, and "reified" id-s-p-o tuples ==> ?id * ?s ?p ?o .

Use FILTER bound(?id)=TRUE to exclude the (asserted) s-p-o triples in choices 1, 2, and 3 above to implement retrieval choices [S], [R], [SR], respectively.

Thanks,
Souri.

[1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0010.html (Souri, Mon, 5 Aug 2024 19:29:29 +0000)
[2] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0011.html (Souri, Mon, 5 Aug 2024 22:37:50 +0000)
________________________________
From: Souripriya Das <souripriya.das@oracle.com>
Sent: Tuesday, August 6, 2024 9:47 AM
To: Thomas Lörtsch <tl@rat.io>
Cc: RDF-star WG <public-rdf-star-wg@w3.org>
Subject: Re: [External] : Re: handling ("asserted") s-p-o triples and ("stated" or "reified") id-s-p-o 4-tuples in RDF/SPARQL

Hi Thomas,
>> We can impose the following constraint on RDF graph content:
>> The 4-tuple, id-s-p-o, must be unique in an RDF graph. If present, an id-s-p-o can either be "asserted" or "reified".
>>
>> SPARQL INSERT, upon successful completion, will have the following effect on the target RDF graph's content:
>> - INSERT DATA { :id rdf:states <<( :s :p :o )>> } => the graph will contain id-s-p-o as "stated".
>> - INSERT DATA { :id rdf:reifies <<( :s :p :o )>> } => the graph will contain id-s-p-o -- as "stated", if it was already present as "stated", and as "reified" otherwise.

> That misses solid support for annotations on statements without actually stating them, i.e. an annotation can not be understood as refering to an unstated (maybe even considered not true) triple if a token of that triple is present in the graph. In that respect it doesn’t go beyond the "working baseline".
>
> Why don’t you allow
>
>     :id rdf:states <<( :s :p :o )>> ;
>         rdf:reifies <<( :s :p :o )>> .
Use of two "parallel" 4-tuples (i.e., same s-p-o but distinct identifiers), one using rdf:states and the other using rdf:reifies, would allow annotations to be associated with the right "flavor" – "stated" or "reified" – of the same s-p-o.
        :id1 rdf:states <<( :s :p :o )>> .
        :id2 rdf:reifies <<( :s :p :o )>> .

Thanks,
Souri.

________________________________
From: Thomas Lörtsch <tl@rat.io>
Sent: Tuesday, August 6, 2024 6:52 AM
To: Souripriya Das <souripriya.das@oracle.com>
Cc: RDF-star WG <public-rdf-star-wg@w3.org>
Subject: [External] : Re: handling ("asserted") s-p-o triples and ("stated" or "reified") id-s-p-o 4-tuples in RDF/SPARQL



> On 5. Aug 2024, at 21:29, Souripriya Das <souripriya.das@oracle.com> wrote:
>
> Notations I am using below for the three proposed categories of tuples in RDF1.2:
> ============
> - A: "Asserted" triples => present in graph as s-p-o
> - S: "Stated under id" 4-tuples => id rdf:states s-p-o
> - R: "Reified under id" 4-tuples => id rdf:reifies s-p-o
>
> Issue A: Handling "stated" vs. "reified" for a given id and s-p-o?
> =============================
> I think it is better to stay within RDF for this and not involve RDFS rdfs:subPropertyOf.

I agree. Note that I went a slightly different route in my latest "Updated proposal" [0], replacing the rdfs:subPropertyOf relation with an RDFS entailment pattern, but in any case: I share the goal of staying within RDF.

> We can impose the following constraint on RDF graph content:
> The 4-tuple, id-s-p-o, must be unique in an RDF graph. If present, an id-s-p-o can either be "asserted" or "reified".
>
> SPARQL INSERT, upon successful completion, will have the following effect on the target RDF graph's content:
> - INSERT DATA { :id rdf:states <<( :s :p :o )>> } => the graph will contain id-s-p-o as "stated".
> - INSERT DATA { :id rdf:reifies <<( :s :p :o )>> } => the graph will contain id-s-p-o -- as "stated", if it was already present as "stated", and as "reified" otherwise.

That misses solid support for annotations on statements without actually stating them, i.e. an annotation can not be understood as refering to an unstated (maybe even considered not true) triple if a token of that triple is present in the graph. In that respect it doesn’t go beyond the "working baseline".

Why don’t you allow

    :id rdf:states <<( :s :p :o )>> ;
        rdf:reifies <<( :s :p :o )>> .

Is your :id a function of (:s :p :o)?

> Issue B: Should presence of "stated" id-s-p-o guarantee presence of asserted" s-p-o?
> ===================================
> I do not think we should include such a guarantee.

Well, a "guarantee" would probably involve entailment.

> This is lossy unless an implementation handles it using reference counts.

I don’t follow. What I’m proposing is rather a way of making SPARQL query not only triples but also stated triple terms. This seems to my naive eye like a simple "expansion" (hoping that I use the term correctly).

> It is better to keep presence or absence of "asserted" s-p-o triple completely independent of the presence or absence of "stated" id-s-p-o 4-tuples (for one or more values of id).

As hinted above I would find this approach more consistent if it always disambiguated three forms:
- triple
- stated triple term
- described/documented triple term
and treat "reified" as superproperty of all triple terms.

But it seems to me that this is orthogonal to my issue with "stated", namely that I'm trying to find a way in which an annotation can with some certainty be understood to refer to a statement that is true in the graph - "some certainty" meaning that the certainty guaranteed by entailment is not available, but hopefully can be "emulated" as proposed in my updated proposal [0].

Best,
Thomas


[0] https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0007.html__;!!ACWV5N9M2RV99hQ!PDW4kWQSwBzptj0gmnBo1agHMZZvywPt0ej3H90kC8o8WYaVeKoebjxbQrbvWz5TzKrPtsHdrxW5$


> SPARQL: Combinations to match:
> ===================
> - A =>                ?s ?p ?o .    # Asserted
> - S =>    ?id    ~    ?s ?p ?o .    # Stated
> - R =>    ?id   | |   ?s ?p ?o .    # Reified
> - AS =>   ?id    @    ?s ?p ?o .    # Asserted or Stated
> - AR =>   ?id   |+|   ?s ?p ?o .    # Asserted or Reified
> - SR =>   ?id   |~|   ?s ?p ?o .    # Stated or Reified
> - ASR =>  ?id   |@|   ?s ?p ?o .    # Asserted or Stated or Reified
> Note: When "asserted" s-p-o is matched, the ?id variable (if any) will not have a binding.

> Thanks,
> Souri.