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

> On 16. Aug 2024, at 15:26, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote:
> 
> Dear Souri,
> 
> I got a little bit lost in the discussion and am not sure whether or not that is still your last proposal, but I wanted to say that what you proposed in an earlier mail, namely this one https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0079.html  is really problematic.
> 
> You had as examples
> 
> # mapping from relational data: one-to-one
> :stint1 rdf:id <<( :Bob :workedFor :A )>> . # S1
> :stint2 rdf:id <<( :Bob :workedFor :B )>> . # S2
> :stint3 rdf:id <<( :Bob :workedFor :A )>> . # S3
> 
> # R4 is marked as "Unreliable", a user terminology, using an extra triple – there is no interference from any of the pre-existing triples
> :stint4 rdf:id <<( :Bob :workedFor :B )>> . # R4
> :stint4 rdf:type :Unreliable .
> 
> The problem with this proposal is that RDF-star becomes non-monotonic and that is a property we (or at least I) do not want to have for a Web Logic: 
> 
> The graph 
> 
> :stint1 rdf:id <<( :Bob :workedFor :A )>> . # S1
> :stint2 rdf:id <<( :Bob :workedFor :B )>> . # S2
> :stint3 rdf:id <<( :Bob :workedFor :A )>> . # S3 
> 
> entails
> :Bob :workedFor :A.
> :Bob :workedFor :B.
> 
> But If I ADD a triple, such that
> 
> :stint1 rdf:id <<( :Bob :workedFor :A )>> . # S1
> :stint2 rdf:id <<( :Bob :workedFor :B )>> . # S2
> :stint3 rdf:id <<( :Bob :workedFor :A )>> . # S3 
> :stint2 rdf:type :Unreliable .
> 
> we only get 
> 
> :Bob :workedFor :A.
> 
> In contexts like the Web it is likely that you only copy some triples from a graph.

A nice way to say that statements may be deleted, albeit orthodoxy forbids such a thought ;-) But yes, meaning may change by addition or removal of triples if the intent to express something is dependend on the presence or absence of another triple. All approaches that try to express annotations on asserted and unasserted statements with only one predicate will suffer from that problem. The baseline proposal starts from reification, i.e. unasserted statments, Souri explored the opposite direction (because annotating an asserted fact is much more common than annoting an unasserted one) - but both approaches run into the same issues and are essentially non-monotonic (not by the book, but they risk to override the intuition behind an annotation (baseline) or a statement (Souris example)). Andy’s proposal of adding another statement expressly stating the "rdf:Stated"-ness suffers from the same problem (besides being verbose): what if the "Stated" statement gets lost, or added lateron. 

Having two different properties is the clean and simple solution on the surface. Yes, it demands entailment or special support in SPARQL, but that is a risk I’m more willing to take than the inherently underdefined expressivity of just one property.

Thomas

> In examples like this here, such things are problematic and I therefore would like to exclude this option. This of course should not stop us to discuss the other proposals.
> 
> Kind regards,
> Dörthe
> 
>> Am 16.08.2024 um 14:40 schrieb Souripriya Das <souripriya.das@oracle.com>:
>> 
>> Hi William,
>> 
>> So, in my approach to RDF1.2, there is no built-in dependency between "under id" assertion vs. assertion based on presence of triple in the graph. The following two triples can exist independently in an RDF graph without affecting one another (I am using rdf:asserts instead of rdf:states here, based on my thoughts in [1] about using explicit property names) – presence or absence of one does not affect the presence or absence of the other:
>>         :s :p : o .
>>         :id rdf:asserts <<( :s :p :o )>> .
>> 
>> Thanks,
>> Souri.
>> 
>> [1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0086.html
>> From: Souripriya Das <souripriya.das@oracle.com>
>> Sent: Friday, August 16, 2024 8:24 AM
>> To: William Van Woensel <william.vanwoensel@gmail.com>
>> Cc: public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
>> Subject: Re: [External] : example showing why rdf:state is essential
>>  
>> Hi William,
>> 
>> > ... "Bob workedFor B" gets asserted (albeit separately, or as a side-effect of rdf:states) ...
>> 
>> Maybe it was not clear in my original email [1] but there is no side-effect of (or any kind of entailed tuples from) rdf:states ... what the data creator enters is what is stored and SPARQL query only does pattern matching against the stored data.
>> 
>> Also, please look at the latest version email [2] where I made some changes regarding the use of rdf:states vs rdf:asserts in the "two-property scheme" and the "single-property scheme."
>> 
>> Thanks,
>> Souri.
>> 
>> [1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html <https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html__;!!ACWV5N9M2RV99hQ!MY-wnuPrWZumjwwtxF5IoFvIhV4NOrlWwxJE2VsBCadA-nZDgOgBF782fHYa5rRuza2ycxptdAeiGo6ng5N8PKDYpzDa$>
>> [2] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0086.html <https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0086.html__;!!ACWV5N9M2RV99hQ!MY-wnuPrWZumjwwtxF5IoFvIhV4NOrlWwxJE2VsBCadA-nZDgOgBF782fHYa5rRuza2ycxptdAeiGo6ng5N8PNtrRwYS$>
>> From: William Van Woensel <william.vanwoensel@gmail.com>
>> Sent: Friday, August 16, 2024 7:24 AM
>> To: Souripriya Das <souripriya.das@oracle.com>
>> Cc: public-rdf-star-wg@w3.org <public-rdf-star-wg@w3.org>
>> Subject: Re: [External] : example showing why rdf:state is essential
>>  
>> Hi Souripriya,
>> 
>> I'm still trying to understand the issue better:
>> 
>>> On Aug 15, 2024, at 3:15 PM, Souripriya Das <souripriya.das@oracle.com> wrote:
>>> 
>>> I did some re-thinking based on the comments I heard during today's meeting. Since our main (and only?) goal is to allow data creators to easily associate an id to a triple so that they can use it as subject or object of other triples (and also, support parallel edges), we can replace the rather meaningful (unfortunately) and hence confusing property name, rdf:reifies, with rdf:id – something that exactly satisfies our original goal (without venturing beyond).
>>> 
>>> So, suppose that RDF1.2 adds built-in support for the rdf:id property and triple-terms (only for use with rdf:id). Anything beyond this in this context is up to the data creator. SPARQL does not do anything other than pattern matching for it (although it may provide some shortcuts just for convenience). Note that other data models have built-in support for "asserted" data only. Even with RDF1.2, I'd expect use of reification to be rare or infrequent.
>>> 
>>> With this rdf:reifies -> rdf:id change, the example in my previous email becomes simple and would have no limitations and most importantly, cause no confusion for users.
>>> 
>>> # mapping from relational data: one-to-one
>>> :stint1 rdf:id <<( :Bob :workedFor :A )>> . # S1
>>> :stint2 rdf:id <<( :Bob :workedFor :B )>> . # S2
>>> :stint3 rdf:id <<( :Bob :workedFor :A )>> . # S3
>>> 
>>> # R4 is marked as "Unreliable", a user terminology, using an extra triple – there is no interference from any of the pre-existing triples
>>> :stint4 rdf:id <<( :Bob :workedFor :B )>> . # R4
>>> :stint4 rdf:type :Unreliable .
>> 
>> In your prior email, I believe the issue was that there were 2 asserted triples in the mix, i.e.,
>> :Bob :workedFor :A . # A4
>> :Bob :workedFor :B . # A5
>> 
>> Which "interfered" with a later non-asserted reification (e.g., describing the information as uncertain). But these asserted triples do not exist here, so, assuming that rdf:id has the same meaning as rdf:id, I don't fully understand the parallel. 
>> 
>> 
>> Thanks
>> 
>> William
>> 
>>> 
>>> # SPARQL query pattern
>>> 
>>> # returns info about all stints
>>> SELECT * { ?id rdf:id <<( ?s ?p ?o )>> . ?id ?p2 ?o2 }
>>> 
>>> # returns info about all stints EXCEPT those that the user marked as Unreliable
>>> SELECT * { ?id rdf:id <<( ?s ?p ?o )>> . FILTER NOT EXISTS { ?id rdf:type :Unreliable } . ?id ?p2 ?o2 }
>>> 
>>> Thanks,
>>> Souri.
>>> 
>>> 
>>> 
>>> 
>>>   
>>> From: Souripriya Das <souripriya.das@oracle.com <mailto:souripriya.das@oracle.com>>
>>> Sent: Thursday, August 15, 2024 11:59 AM
>>> To: RDF-star WG <public-rdf-star-wg@w3.org <mailto:public-rdf-star-wg@w3.org>>
>>> Subject: [External] : example showing why rdf:state is essential
>>>  
>>> I am trying to show that if rdf:states is not supported, once the "asserted" s-p-o triple is present, ALL existing and future "reified" s-p-o triples will now be considered as "asserted" (or occurrence of asserted triple). This limitation goes away if rdf:states is supported (along with rdf:reifies). 
>>> 
>>> Consider the following "WorkHistory" data, shown in relational form. 
>>> StintID | EmpName | Company | StartYear | EndYear
>>> ============
>>> 1 | Bob', | 'A' | 1980 | 1990
>>> 2 | 'Bob' | 'B' | 1990 | 2000
>>> 3 | 'Bob' | 'A' | 2000 | 2010
>>> 
>>> RDF1.2: when rdf:states is NOT supported
>>> ======
>>> # mapping from relational data (annotations not shown): NOT one-to-one
>>> :stint1 rdf:reifies <<( :Bob :workedFor :A )>> . # R1
>>> :stint2 rdf:reifies <<( :Bob :workedFor :B )>> . # R2
>>> :stint3 rdf:reifies <<( :Bob :workedFor :A )>> . # R3
>>> :Bob :workedFor :A . # A4
>>> :Bob :workedFor :B . # A5
>>> 
>>> Addition of uncertain data:
>>> ========
>>> # Adding the following triple to indicate that Bob might have worked for Company B, according to Alice
>>> # This will be counted as "asserted" because of presence of triple A5 above (just like triples R1, R2, and R3)
>>>  
>>> :stint4 rdf:reifies <<( :Bob :workedFor :B )>> . # R4
>>> 
>>> RDF1.2: if rdf:states is supported, we can do it
>>> ======
>>> # mapping from relational data: one-to-one
>>> :stint1 rdf:states <<( :Bob :workedFor :A )>> . # S1
>>> :stint2 rdf:states <<( :Bob :workedFor :B )>> . # S2
>>> :stint3 rdf:states <<( :Bob :workedFor :A )>> . # S3
>>> 
>>> # R4 is counted as "reified" – there is no interference from any of the pre-existing triples
>>> :stint4 rdf:reifies <<( :Bob :workedFor :B )>> . # R4
>>> 
>>> Thanks,
>>> Souri.
>