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

Hi Souri,

I'm still a bit confused as to the underlying need for this change. (I may be missing something from prior meetings or messages before I joined - although I read Souri's original messages about this - in that case, apologies for the time wastage.)

I gathered the following from Souri's earlier responses (copied from my prior email):

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

Would this be correct?


Thanks

W

> On Aug 19, 2024, at 7:52 PM, Souripriya Das <souripriya.das@oracle.com> wrote:
> 
> Hi Peter,
> 
> Just realized that Thursday has been reserved for discussing the feasibility of creating "profiles." 
> 
> > What is the difference you want between rdf:reifies and rdf:asserts?  
> Two distinct properties are meant for use in being able to designate each triple-term (not triple) to one of the two types – asserted or reified. RDF does not attach any special semantics or entailment rules for these two types for triple-terms. Lack of any special semantics means if we wanted we could even name these two types anything -- A and B, for example.
> 
> Having two distinct properties makes it easy to separate one kind of triple-terms from the other kind which helps in avoiding verbosity of the data and avoiding additional patterns (or FILTER NOT EXISTS) in the SPARQL queries for retrieving only one of the two kinds of triple-patterns. 
> 
> Example 1: Compact data and low-complexity query with the two-property (rdf:asserts and rdf:reifies) approach
> =========
> RDF data: (100 triples)
> # 99 reliable triple-terms – if no reliability info, then assume reliable
> :id1 rdf:asserts <<( :s1 :p1 :o1 )>> .
> :id2 rdf:asserts <<( :s2 :p2 :o2 )>> .
> ...
> :id99 rdf:asserts <<( :s99 :p99 :o99 )>> .
> # one unreliable triple-term
> :id100 rdf:reifies <<( :s100 :p100 :o100 )>> .
> 
> SPARQL query to retrieve the reliable ones: (single BGP)
> select ?id ?s ?p ?o { ?id rdf:asserts <<( ?s ?p ?o )>> }  
> 
> Example 2: Increased verbosity of data and complexity of query with the single-property (say, rdf:reifies) approach
> =========
> RDF data: (200 triples)
> # 99 reliable triple-terms
> :id1 rdf:reifies <<( :s1 :p1 :o1 )>> ; :reliable "YES" .
> :id2 rdf:reifies <<( :s2 :p2 :o2 )>> ; :reliable "YES" .
> ...
> :id99 rdf:reifies <<( :s99 :p99 :o99 )>> ; :reliable "YES" .
> # one unreliable triple-term
> :id100 rdf:reifies <<( :s100 :p100 :o100 )>> ; :reliable "NO" .
> 
> SPARQL query to retrieve the reliable ones: (single BGP with two triple-patterns)
> select ?id ?s ?p ?o { ?id rdf:reifies <<( ?s ?p ?o )>> ; :reliable "YES" }  
> 
> Example 3: Limited increased in verbosity of data and but higher complexity of query with the single-property (say, rdf:reifies) approach
> =========
> RDF data: (101 triples)
> # 99 reliable triple-terms – if no reliability info, then assume reliable
> :id1 rdf:reifies <<( :s1 :p1 :o1 )>> .
> :id2 rdf:reifies <<( :s2 :p2 :o2 )>> .
> ...
> :id99 rdf:reifies <<( :s99 :p99 :o99 )>> .
> # one unreliable triple-term
> :id100 rdf:reifies <<( :s100 :p100 :o100 )>> ; :reliable "NO" .
> 
> SPARQL query to retrieve the reliable ones: (two BGPs + anti-join)
> select ?id ?s ?p ?o { ?id rdf:reifies <<( ?s ?p ?o )>> FILTER NOT EXISTS { ?id :reliable "NO" } }  
> 
> Do you
> want different simple entailments, different RDF entailments, or different
> RDFS entailments?  If none of these then what is the difference between them
> and why then should they both be in RDF (or RDFS)?
> 
> No special semantics in RDF. Hence no special entailments at all. The only purpose is to make it easy to distinguish between two types of triple-terms (could be to differentiate them in terms of reliability at a yes/no level, for example). If more fine-grained distinction is needed among the triple-terms, user can always create their own properties and classes.
> 
> Thanks,
> Souri.
> 
> From: Souripriya Das <souripriya.das@oracle.com>
> Sent: Monday, August 19, 2024 1:41 PM
> To: Peter F. Patel-Schneider <pfpschneider@gmail.com>; public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> Subject: Re: [External] : example showing why rdf:state is essential
>  
> Not sure if you read the final paragraph that starts with "Finally, ..." in my last email. Rest we can discuss on Thursday.
> From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
> Sent: Monday, August 19, 2024 12:11 PM
> To: Souripriya Das <souripriya.das@oracle.com>; public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> Subject: Re: [External] : example showing why rdf:state is essential
>  
> What is the difference you want between rdf:reifies and rdf:asserts?  Do you
> want different simple entailments, different RDF entailments, or different 
> RDFS entailments?  If none of these then what is the difference between them 
> and why then should they both be in RDF (or RDFS)?
> 
> peter
> 
> 
> On 8/19/24 06:51, Souripriya Das wrote:
> > (Just for reference, these comments were meant for my original email on this 
> > thread [1].)
> > 
> >      > I found the original pair of examples completely unconvincing.  The first
> >      > example has four different rdf:reifies triples prov[i]ding nothing about
> >      > provenance or assertive force.   But even if these triples were added
> > 
> > There is no need to include detailed provenance in the example to illustrate 
> > the issue. Here is a simpler example:
> > 
> > Example:
> > # I know for sure that Bob had a stint working for B, but I think he had a 
> > second stint there as well.
> > 
> > # ALT1: using two-property approach
> > :stint1 rdf:asserts <<( :Bob :workedFor :B )>> . # confident
> > :stint2 rdf:reifies <<( :Bob :workedFor :B )>> . # unsure
> > 
> > # ALT2: using single-property approach – had to add annotations to distinguish 
> > the two stints regarding sure or unsure
> > :stint1 rdf:reifies <<( :Bob :workedFor :B )>>
> >              ; :sure "YES" . # confident
> > :stint2 rdf:reifies <<( :Bob :workedFor :B )>> .
> >              ; :sure "NO" . # unsure
> > 
> > Clearly, ALT2 is more verbose because addition of the :sure properties is the 
> > only way to distinguish :stint1 to be different than :stint2. Even if the user 
> > adds the Bob-workedFor-B triple to ALT2, that will not help in distinguishing 
> > :stint1 from :stint2. Any related SPARQL queries in the ALT2 case would 
> > contain more patterns to match the :sure property and that may affect query 
> > performance. Support for the two-property approach in the baseline would 
> > eliminate such overheads.
> > 
> >      > ... there is nothing to say that :stint4 is in any way asserting
> >     anything just
> >      > because the triple it reifies is present in the graph.
> > 
> > 
> > I am actually looking for such independence, but I thought that there was a 
> > different opinion in the group – may be I misinterpreted something I heard in 
> > the discussions. Such independence in RDF1.2 will ensure that 1) in ALT1, 
> > there should not be any automatic addition of the Bob-workedFor-B triple just 
> > because :stint1 uses rdf:asserts, and 2) in both ALT1 and ALT2, even if the 
> > Bob-workedFor-B triple was added explicitly by the user, that should not cause 
> > the :stint2 to be seen as asserting the event it reifies. (Of course, user's 
> > application-level logic could interpret things that way, but that will happen 
> > outside of RDF1.2.)
> > 
> >      > ... Changing the name from rdf:reifies also does nothing to change the
> >      > situation.  The proposed rdf:id [d]oes have the unfortunate connotation
> >     of being
> >      > an identifier, which clashes with the many-to-many characteristic of
> >     rdf:reifies
> > 
> > 
> > We had some discussion during our Semantics TF meeting on Friday about the  
> > mismatch between the one-to-one connotation of rdf:id [2] vs. the many-to-many 
> > mapping that we are trying to express. Same issue IMO with rdf:reifies though 
> > – because AFAIU, one-to-one – not many-to-many – is the norm for reification 
> > too. One possible alternative I can think of is rdf:hasTriple – goes well with 
> > many-to-many.
> > 
> >      > Adding assertional force information to provenance nodes *does* provide
> >      > information about which provenance node supports the presence of triple
> >     in the
> >      > graph whether this is done via a property like prov:reliability or a class
> >      > like prov:Unreliable.
> > 
> >     None of this affects the baseline, which does not touch on provenance or
> >     assertional force.
> > 
> > I am hoping that within RDF1.2 there will be absolutely no built-in dependency 
> > between the presence (or absence) of an s-p-o triple and presence (or absence) 
> > of any corresponding id-s-p-o tuples (regardless whether the property used in 
> > the id-s-p-o tuples is rdf:asserts or rdf:reifies). Any such dependency, if 
> > needed, can be implemented by users using custom properties and/or classes 
> > that are outside of RDF1.2.
> > 
> > Finally, given the pushback I am seeing for the two-property approach, I think 
> > it is okay to go with the single-property approach (because I do expect that 
> > most RDF graphs in practice will contain only one kind of id-s-p-o tuples). 
> > However, keeping in mind the one-to-one connotation of rdf:reifies and its 
> > perceived complexity among (a significant chunk of) potential users of RDF1.2, 
> > I'd like the group to consider an alternate like rdf:hasTriple.
> > 
> > Thanks,
> > Souri.
> > 
> > [1] https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html__;!!ACWV5N9M2RV99hQ!ItvPTIiSyrTIl8AjjFjNckOMwtkcB-Dw8mO6Zm0yLwoBflqGJQtb3xMkKvTFOkCd6I8qQEzn0_HV9zN--ySPC-qOHw$ 
> > <https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html__;!!ACWV5N9M2RV99hQ!ItvPTIiSyrTIl8AjjFjNckOMwtkcB-Dw8mO6Zm0yLwoBflqGJQtb3xMkKvTFOkCd6I8qQEzn0_HV9zN--ySPC-qOHw$ >
> > [2] https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0081.html__;!!ACWV5N9M2RV99hQ!ItvPTIiSyrTIl8AjjFjNckOMwtkcB-Dw8mO6Zm0yLwoBflqGJQtb3xMkKvTFOkCd6I8qQEzn0_HV9zN--yQdkgJ8IQ$ 
> > <https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0081.html__;!!ACWV5N9M2RV99hQ!ItvPTIiSyrTIl8AjjFjNckOMwtkcB-Dw8mO6Zm0yLwoBflqGJQtb3xMkKvTFOkCd6I8qQEzn0_HV9zN--yQdkgJ8IQ$ >
> > ------------------------------------------------------------------------------
> > *From:* Peter F. Patel-Schneider <pfpschneider@gmail.com>
> > *Sent:* Saturday, August 17, 2024 1:12 PM
> > *To:* public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
> > *Subject:* Re: [External] : example showing why rdf:state is essential
> > I support the comments of Gregg Kellogg and provide the following extra
> > information on this stance on triple terms and reification.
> > 
> > 
> > I found the original pair of examples completely unconvincing.  The first
> > example has four different rdf:reifies triples provding nothing about
> > provenance or assertive force.   But even if these triples were added, for
> > example via
> > 
> > :stint1 prov:source :workhistory .
> > :stint1 prov:reliability :high .
> > ...
> > :stint4 prov:source :alice .
> > :stint4 prov:reliability :low .
> > 
> > there is nothing to say that :stint4 is in any way asserting anything just
> > because the triple it reifies is present in the graph.  To say otherwise is a
> > complete misreading of the meaning of rdf:reifies, which was only created to
> > provide an RDF-blessed predicate for the nearly-always-required-standoff when
> > using triple triples.
> > 
> > Using a second predicate that has no semantics does nothing to change the
> > situation.  Changing the name from rdf:reifies also does nothing to change the
> > situation.  The proposed rdf:id oes have the unfortunate connotation of being
> > an identifier, which clashes with the many-to-many characteristic of rdf:reifies.
> > 
> > Adding assertional force information to provenance nodes *does* provide
> > information about which provenance node supports the presence of triple in the
> > graph whether this is done via a property like prov:reliability or a class
> > like prov:Unreliable.
> > 
> > 
> > None of this affects the baseline, which does not touch on provenance or
> > assertional force.
> > 
> > 
> > peter
> >