Re: [External] : example showing why rdf:state is essential

Hi Souripriya,

Ok, after thinking about it some more ... Is the problem related to the "open world" of the web?

Let me first clarify my assumptions:

- The way that A5, i.e.,
 :Bob :workedFor :B . # A5

Interferes with the following:
 :stint4 rdf:id <<( :Bob :workedFor :B )>> ; :start 2010 ; :end 2020 . 
 :stint4 rdf:type :UnreliableForMyApp .
 
Is that A5 asserts in the graph what the above describes to be unreliable, _under the semantics of your application_ (not the default rdf-star semantics). So, A5 conflicts with your application-specific "uncertain" annotation.

- Someone other than the author of the annotation added A5 (which is perfectly possible, since it's an open world); else, the author could simply remove it from the graph.

But, in your solution, this other person could also add the following:
 :stintX rdf:id <<( :Bob :workedFor :B )>> .
 :stintX rdf:type : HundredPercentCertain .

(Assuming that, in your application, this is a way of expressing full certainty about a statement.)

So, the issue still exists - someone else can put statements that, in an application-dependent way, conflict with your own statements. (This was originally the case as well, due to the application-specific meaning of UnreliableForMyApp).

Also, in both cases, you could define applications-specific semantics to flag these conflicts. E.g. (using N3)

{ ?s ?p ?o .
 ?id rdf:id <<( ?s ?p ?o )>> .
 ?id rdf:type :UnreliableForMyApp .

} => {
 <> :conflict ( ?s ?p ?o ) 
}

And

{ ?id rdf:id <<( ?s ?p ?o )>> .
 ?id rdf:type :HundredPercentReliable .
 ?id2 rdf:id <<( ?s ?p ?o )>> .
 ?id2 rdf:type :UnreliableForMyApp .

} => {
 <> :conflict ( ?s ?p ?o ) 
}


Just let me know if I'm getting something tragically wrong.


W

> On Aug 17, 2024, at 7:51 AM, Souripriya Das <souripriya.das@oracle.com> wrote:
> 
> Hi Thomas,
> 
> Yes, SPARQL1.2 can provide shortcuts to support various combinations of the three different types of tuples that are supported in the two-property approach (that use rdf:asserts and rdf:reifies), as I had outlined originally in [1] and reproduced here with a slightly more elaborate terminology.
> Types of tuples :
> ============
>     type [gA: graph-scoped Assertion] => :s :p :o . ==> (asserted, graph-scoped) s-p-o triple
>     type [iA: id-scoped Assertion] => :id rdf:asserts <<( :s :p :o )>> . ==> "asserted, id-scoped" id-s-p-o tuple
>     type [iR: id-scoped Reification] => :id rdf:reifies <<( :s :p :o )>> . ==> "reified, id-scoped" id-s-p-o tuple
> 
> SPARQL pattern extensions: (to allow retrieval of all seven non-empty elements in the power set: [gA], [iA], [iR], [gA | iA], [iA | iR], [gA | iR], [gA | iA | iR] )
> =======================
> 0) [gA] => ?s ?p ?o . # graph-scoped Assertions ==> s-p-o triples only
> 1) [gA | iA] => ?id ~ ?s ?p ?o . # graph-scoped Assertions UNION id-scoped Assertions ==> s-p-o triples and "asserted" id-s-p-o tuples
> 2) [gA | iR] => ?id | ?s ?p ?o . # graph-scoped Assertions UNION id-scoped Reifications==> s-p-o triples and "reified" id-s-p-o tuples
> 3) [gA | iA | iR] => ?id * ?s ?p ?o . # all types of tuples => graph-scoped Assertions UNION id-scoped Assertions UNION id-scoped Reifications
> 
> Use FILTER bound(?id)=TRUE to exclude the graph-scoped Assertions (i.e., exclude the s-p-o triples) in choices 1, 2, and 3 above to implement retrieval choices [iA], [iR], [iA | iR], respectively.
> 
> Here are some sample queries and results (for the data shown in [2]):
> =========================
> - select (count(?for) as ?count) where { ?id ~ :Bob :workedFor ?for } .
>     RESULT: [ ?count = 3 ]
> - select (count(?for) as ?count) where { ?id * :Bob :workedFor ?for } .
>     RESULT: [ ?count = 4 ]
> Thanks,
> Souri.
> 
> [1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0053.html
> [2] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0104.html
> From: Thomas Lörtsch <tl@rat.io>
> Sent: Saturday, August 17, 2024 4:28 AM
> To: public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>; Souripriya Das <souripriya.das@oracle.com>; James Anderson <anderson.james.1955@gmail.com>; RDF-star Working Group <public-rdf-star-wg@w3.org>
> Subject: Re: [External] : example showing why rdf:state is essential
>  
> Hi Souri,
> 
> IMO the answer should be 3, because the whole point of this rdfs:states thing is to go beyond what reification (and rdf:reifies or whatever its name will end up to be) can provide, and interpret triple terms in the rdfs:range of rdfs:states as actually stated. That sure is beyond simple RDF entailment, but IIUC SPARQL-star can do it. 
> 
> Therefore, wouldn't it be more practical to define that any query runs over standard triples AND also triple terms that are the object of an rdfs:states relation? (maybe not always always, but triggered by a keyword like WITH QUALIFIED)? Wouldn't that perfectly capture the intention that triple terms in the rdfs:range of rdfs:states are assumed/expected to be true in the graph? Maybe call this SPARQL-star entailment? IIUC this is the approach taken in the original RDF* proposal, so given that RDF* had multiple implementations, including pretty high profile ones, it should be practical, right?
> 
> Best,
> Thomas
> 
> 
> Am 17. August 2024 05:53:01 MESZ schrieb Souripriya Das <souripriya.das@oracle.com>:
> Hi James,
> 
> >> 1) Two-property example:
> >>
> >> # mapping from relational data: one-to-one, using RDF1.2-supported "asserted under id" tuples (that use the rdf:asserts property)
> >> :stint1 rdf:asserts <<( :Bob :workedFor :A )>> ; :start 1980 ; :end 1990 .
> >> :stint2 rdf:asserts <<( :Bob :workedFor :B )>> ; :start 1990 ; :end 2000 .
> >> :stint3 rdf:asserts <<( :Bob :workedFor :A )>> ; :start 2000 ; :end 2010 .
> >>
> >> # adding some unreliable info using RDF1.2-supported "reified under id" tuple (that use the rdf:reifies property)
> >> :stint4 rdf:reifies <<( :Bob :workedFor :B )>> ; :start 2010 ; :end 2020 .
> > under this proposal, what would be the result of the following sparql query
> 
> > select (count (?for) as ?count)
> > where { :Bob :workedFor ?for }
> 
> > were it applied to a graph which included those four statements?
> 
> The result will be [ ?count = 0 ]. This is because no s-p-o triple was loaded and due to the "no side-effect" principle of this approach, no such s-p-o triple was automatically generated. In general, asserted id-s-p-o tuples do not have the side-effect of generating the corresponding s-p-o triples.
> 
> Here are some related variations of the above query that will produce different results:
> - select (count(?for) as ?count) where { ?id rdf:asserts <<( :Bob :workedFor ?for )>> } .
>     RESULT: [ ?count = 3 ]
> - select (count(?for) as ?count) where { ?id rdf:reifies <<( :Bob :workedFor ?for )>> } .
>     RESULT: [ ?count = 1 ]
> - select (count(?for) as ?count) where { ?id ?p <<( :Bob :workedFor ?for )>> . FILTER( ?p IN (rdf:asserts, rdf:reifies) ) } .
>     RESULT: [ ?count = 4 ]
> 
> Thanks,
> Souri.
> 
> From: James Anderson <anderson.james.1955@gmail.com>
> Sent: Friday, August 16, 2024 8:43 PM
> To: RDF-star Working Group <public-rdf-star-wg@w3.org>
> Subject: Re: [External] : example showing why rdf:state is essential
>  
> good morning;
> 
> > On 16. Aug 2024, at 23:15, Souripriya Das <souripriya.das@oracle.com> wrote:
> > 
> > ...
> > 
> > 1) Two-property example:
> > 
> > # mapping from relational data: one-to-one, using RDF1.2-supported "asserted under id" tuples (that use the rdf:asserts property)
> > :stint1 rdf:asserts <<( :Bob :workedFor :A )>> ; :start 1980 ; :end 1990 .
> > :stint2 rdf:asserts <<( :Bob :workedFor :B )>> ; :start 1990 ; :end 2000 .
> > :stint3 rdf:asserts <<( :Bob :workedFor :A )>> ; :start 2000 ; :end 2010 .
> > 
> > # adding some unreliable info using RDF1.2-supported "reified under id" tuple (that use the rdf:reifies property)
> > :stint4 rdf:reifies <<( :Bob :workedFor :B )>> ; :start 2010 ; :end 2020 .
> 
> under this proposal, what would be the result of the following sparql query
> 
> select (count (?for) as ?count)
> where { :Bob :workedFor ?for }
> 
> were it applied to a graph which included those four statements?
> 
> ---
> james anderson | james@dydra.com | https://urldefense.com/v3/__https://dydra.com__;!!ACWV5N9M2RV99hQ!O59l_7OCGsyoa5ODrrwqZX8bOZsd3C4m0i87102jVP-7bTsuGnmqQhuZQZcTSaaEL0KpjNh47UVAcjmNyOqSRn9IwmfNyA$