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

:s :p :o1 .
:s :p :o2 .
:t2 rdfs:states <<( :s :p :o2 )>> ;
    :x :y .
:t3 rdf:reifies <<( :s :p :o3 )>> ;
    :x :z .
:t4 rdfs:states <<( :s :p :o4 )>> ;
    :x :q .
...
OPTION 2 (asserted or stated)
=============================

SELECT *
WHERE {
    { :s :p ?o . }
    UNION
    { ?id rdfs:states <<( :s :p ?o )>> .
      OPTIONAL { ?id ?a ?b . } }
}

should return
?id ?o  ?a ?b
    :o1
    :o2
:t2 :o2 :x :y
:t4 :o4 :x :q

...

> ... As the example of ':t4' shows, stated triple terms do indeed become "kind of" asserted if queried like in Option 2 (and assuming that SPARQL-star provides some syntactic sugar that makes such queries easy to write, as suggested in earlier mails in this thread). That reflects a semantics that makes them entail the triple they describe, even if the entailment regime is not implemented (i.e., no reasoner or rule engine materializes the entailed statement). That may be considered dangerous, or nice, or something in between - to be discussed.

Not sure if I am missing something obvious, but I do not see any entailment here. SPARQL is simply matching the patterns in the two BGPs directly against the triples in the RDF1.2 graph.

Thanks,
Souri.

________________________________
From: Thomas Lörtsch <tl@rat.io>
Sent: Wednesday, August 14, 2024 4:23 AM
To: Gregory Williams <greg@evilfunhouse.com>
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



On 13. Aug 2024, at 17:41, Gregory Williams <greg@evilfunhouse.com> wrote:

On Aug 13, 2024, at 5:07 AM, Thomas Lörtsch <tl@rat.io> wrote:

I always stress that I’m not good at SPARQL, but I’m trying. The following queries are my attempts

[…]

Where does :t1 come from here? I would expect the first result to have a binding only for ?o.

There was indeed that mistake, and the same one in OPTION 3, and another one w.r.t. :o2, and also I forgot to illustrate the interesting case where a triple term is referred to via "rdfs:states", but not asserted in the graph. So pretty buggy, actually :-/
This is a new attempt, fixing these bugs and hopefully not introducing too many new ones...


Given the example data:

@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#<https://urldefense.com/v3/__http://www.w3.org/1999/02/22-rdf-syntax-ns*__;Iw!!ACWV5N9M2RV99hQ!K9efX17qeeW5huFx8pFVHsXixlsMD3d7kxcCeOdJn0xzZhj7wAxNkloGUrE8RQSIyqRw-iBpI6vR$>> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#<https://urldefense.com/v3/__http://www.w3.org/2000/01/rdf-schema*__;Iw!!ACWV5N9M2RV99hQ!K9efX17qeeW5huFx8pFVHsXixlsMD3d7kxcCeOdJn0xzZhj7wAxNkloGUrE8RQSIyqRw-iYvPDaM$>> .
@prefix :     <http://ex.org/<https://urldefense.com/v3/__http://ex.org/__;!!ACWV5N9M2RV99hQ!K9efX17qeeW5huFx8pFVHsXixlsMD3d7kxcCeOdJn0xzZhj7wAxNkloGUrE8RQSIyqRw-kOdVdHb$>> .

:s :p :o1 .
:s :p :o2 .
:t2 rdfs:states <<( :s :p :o2 )>> ;
    :x :y .
:t3 rdf:reifies <<( :s :p :o3 )>> ;
    :x :z .
:t4 rdfs:states <<( :s :p :o4 )>> ;
    :x :q .


OPTION 1 (only reified)
=======================

SELECT *
WHERE {
    ?id rdf:reifies <<( :s :p ?o )>> .
    OPTIONAL { ?id ?a ?b . }
}

should return
?id ?o  ?a ?b
:t3 :o3 :x :z


OPTION 2 (asserted or stated)
=============================

SELECT *
WHERE {
    { :s :p ?o . }
    UNION
    { ?id rdfs:states <<( :s :p ?o )>> .
      OPTIONAL { ?id ?a ?b . } }
}

should return
?id ?o  ?a ?b
    :o1
    :o2
:t2 :o2 :x :y
:t4 :o4 :x :q


OPTION 3 (everything)
=====================

SELECT *
WHERE {
    { :s :p ?o . }
    UNION
    { ?id rdfs:states <<( :s :p ?o )>> .
      OPTIONAL { ?id ?a ?b . } }
    UNION
    { ?id rdf:reifies <<( :s :p ?o )>> .
      OPTIONAL { ?id ?a ?b . } }
}

should return
?id ?o  ?a ?b
    :o1
    :o2
:t2 :o2 :x :y
:t3 :o3 :x :z
:t4 :o4 :x :q


These results show an aspect that was not visible in the first version, as there I forgot to add :o2. As the example of ':t4' shows, stated triple terms do indeed become "kind of" asserted if queried like in Option 2 (and assuming that SPARQL-star provides some syntactic sugar that makes such queries easy to write, as suggested in earlier mails in this thread). That reflects a semantics that makes them entail the triple they describe, even if the entailment regime is not implemented (i.e., no reasoner or rule engine materializes the entailed statement). That may be considered dangerous, or nice, or something in between - to be discussed.


Best,
Thomas