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://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0007.html


> 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.

Received on Tuesday, 6 August 2024 10:52:39 UTC