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

> :Bob :workedFor :B . # A5

> Where A4 "interferes" with:

> :stint4 rdf:reifies <<( :Bob :workedFor :B )>> . # R4



Yes, that is the reason, but A5, not A4, interferes (with R4) as I had indicated in that email [1]:

>> # This will be counted as "asserted" because of presence of triple A5 above (just like triples R1, R2, and R3)

Thanks,
Souri.

[1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html

________________________________
From: William Van Woensel <william.vanwoensel@gmail.com>
Sent: Friday, August 16, 2024 6:32 PM
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

And, just to be sure, the reason for your proposal is to avoid the example you gave before, i.e.,

: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

Where A4 "interferes" with:

:stint4 rdf:reifies <<( :Bob :workedFor :B )>> . # R4

Or is there another reason?


Thanks

W

On Aug 16, 2024, at 6:25 PM, William Van Woensel <william.vanwoensel@gmail.com> wrote:

Hi Souripriya,

Thanks a lot for your clarification - your proposal is a lot clearer to me now.


Thanks

W

On Aug 16, 2024, at 5:15 PM, Souripriya Das <souripriya.das@oracle.com> wrote:

Hi William,

>> The properties can be very explicit about distinguishing the asserted vs reified case. My preference would be: rdf:asserts (not rdf:states, because that is not explicitabout being "asserted") and rdf:reifies. This is my preferred approach as I think it is best to use distinct built-in properties so that the user does not have to devise their own ways for distinguishing the two cases (and SPARQL queries do not have to include a NOT EXISTS filter to exclude any reified triples).

> AFAICT the message was still about asserting statements and using different properties for asserting vs. just reifying. Do you want to use the properties to distinguish the asserted vs. reified case, but not actually do any asserting? I.e., it would be up to the author to use rdf:reifies and rdf:asserts in the correct way?
Presence or absence of an s-p-o triple in a graph is understood to indicate whether the s-p-o triple is asserted or not in the graph. When I said "asserted vs. reified case" above, I meant that within the scope of an "id", not the graph (s-p-o triple vs. id-s-p-o tuple). So, an s-p-o triple being asserted (or not) in a graph has nothing to do with an "asserted" id-s-p-o tuple (that is, the  triple :id rdf:asserts <<( :s :p :o )>>) being present (or not) in the graph. The latter, if present, indicates that s-p-o is asserted "under the specified id" and it does NOT say anything as to whether the s-p-o triple is asserted (present) in the graph or not. Same is true for "reified" id-s-p-o tuple (that is, the  triple :id rdf:reifies <<( :s :p :o )>>) as well.

In summary, presence or absence of these three kinds of things – asserted s-p-o triple, asserted id-s-p-o tuple, reified id-s-p-o tuple – are completely independent. Presence or absence of one does not have anything to do with presence or absence of another.

So, given such independence, let us ignore the s-p-o triples for the moment and only consider the id-s-p-o tuples. Each id-s-p-o tuple must be unique in an RDF graph and would have a value of either "asserted" or "reified". The data creator can decide when they are creating a unique id-s-p-o tuple, whether to mark it as  "asserted (under the specified id)" or "reified (under the specified id)" depending upon their own assessment (probably based on some combination of various application-specific criteria). RDF1.2 simply provides these two properties – rdf:asserts and rdf:reifies – to  allow them to use as two distinct bins.

In the following two-property example, the data creator thinks that the stint4-Bob-workedFor-B tuple is suspect and hence decides to use rdf:reifies as the predicate. In the single-property example shown later, the data creator has only a single property – rdf:id – available to her from RDF1.2, and so she has to use application-specific ways to specially mark the unreliable data.

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 .

If the group thinks that RDF1.2 does not need to support the two bins – "asserted under id" and "reified under id" – for the id-s-p-o tuples, then we can settle on providing just a single (neutral sounding) property, rdf:id (because all we are doing is associating an id to an s-p-o triple-term), for example. So, the above example, then has to be modeled as follows.

2) Single-property example:

# mapping from relational data: one-to-one, id association done using RDF1.2-supported id-s-p-o tuples (that use the rdf:id property)
:stint1 rdf:id <<( :Bob :workedFor :A )>> ; :start 1980 ; :end 1990 .
:stint2 rdf:id <<( :Bob :workedFor :B )>> :start 1990 ; :end 2000 .
:stint3 rdf:id <<( :Bob :workedFor :A )>> :start 2000 ; :end 2010 .

# adding some unreliable data using RDF1.2-supported id-s-p-o tuple (using the rdf:id property) along with use of a custom class created by the user
:stint4 rdf:id <<( :Bob :workedFor :B )>> :start 2010 ; :end 2020 .
:stint4 rdf:type :UnreliableForMyApp .

Thanks,
Souri.

________________________________
From: William Van Woensel <william.vanwoensel@gmail.com<mailto:william.vanwoensel@gmail.com>>
Sent: Friday, August 16, 2024 4:01 PM
To: Souripriya Das <souripriya.das@oracle.com<mailto:souripriya.das@oracle.com>>
Cc: public-rdf-star-wg@w3.org<mailto:public-rdf-star-wg@w3.org> <public-rdf-star-wg@w3.org<mailto:public-rdf-star-wg@w3.org>>
Subject: Re: [External] : example showing why rdf:state is essential

Hi Souripriya,

Ok:

> The properties can be very explicit about distinguishing the asserted vs reified case. My preference would be: rdf:asserts (not rdf:states, because that is not explicit about being "asserted") and rdf:reifies. This is my preferred approach as I think it is best to use distinct built-in properties so that the user does not have to devise their own ways for distinguishing the two cases (and SPARQL queries do not have to include a NOT EXISTS filter to exclude any reified triples).

AFAICT the message was still about asserting statements and using different properties for asserting vs. just reifying. Do you want to use the properties to distinguish the asserted vs. reified case, but not actually do any asserting? I.e., it would be up to the author to use rdf:reifies and rdf:asserts in the correct way?


Thanks

W

On Aug 16, 2024, at 2:16 PM, Souripriya Das <souripriya.das@oracle.com<mailto:souripriya.das@oracle.com>> wrote:

Hi W,

> In contrast to rdf:states, the rdf:asserts predicate would have the "side-effect" of asserting the triple as well?
Absolutely no side-effect. What you enter is what gets stored.

Please start with this email [1] where you may find a clearer and more up-to-date description of what I am trying to get to.

Thanks,
Souri.

[1] 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!ObgOsMpIaA2qJ2QvAd1CEyR1FLxhoMQG29HPb06TqI0PyefGEuOpBCot91mEmrTlFPDt3qdT0_JjZUDBtDH1wcnSRsGvYg$>
________________________________
From: William Van Woensel <william.vanwoensel@gmail.com<mailto:william.vanwoensel@gmail.com>>
Sent: Friday, August 16, 2024 9:29 AM
To: Souripriya Das <souripriya.das@oracle.com<mailto:souripriya.das@oracle.com>>
Cc: public-rdf-star-wg@w3.org<mailto:public-rdf-star-wg@w3.org> <public-rdf-star-wg@w3.org<mailto:public-rdf-star-wg@w3.org>>
Subject: Re: [External] : example showing why rdf:state is essential

Hi Souripriya,

Sorry, I'm confused now :-) So rdf:states and rdf:reifies would all have the same semantics (i.e., assigning an id to the quoted triple)? I got the wrong impression from your messages (not to take your words out of context, just to explain how I got the impression):

1) asserted data is the norm, reifications are exception (see, for example, LPG/relational and even RDF1.1 data) – we need to make associating an id to asserted data as easy as possible
2) very important to have one-to-one mapping when converting (asserted) data between LPG/relational and RDF1.2 (at abstract syntax/N-Triples level, not just Turtle) – an LPG edge or binary relationship should be equivalent to exactly one RDF1.2 triple, not more than one – which does not work if rdf:reifies is used because that requires presence of the asserted s-p-o triple as well (e.g., :s :p :o . :r rdf:reifies <<( :s :p :o )>> . vs. only having :r rdf:id <<( :s :p :o )>> ,)

So, rdf:states would not fill this need of a 1-1 mapping? What would your solution be then?

Just to be sure, in your proposed two-property scheme:

The properties can be very explicit about distinguishing the asserted vs reified case. My preference would be: rdf:asserts (not rdf:states, because that is not explicit about being "asserted") and rdf:reifies.

In contrast to rdf:states, the rdf:asserts predicate would have the "side-effect" of asserting the triple as well?

Apologies for my ignorance!


W

On Aug 16, 2024, at 8:24 AM, Souripriya Das <souripriya.das@oracle.com<mailto:souripriya.das@oracle.com>> wrote:

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.

So in the following, you need something different from asserted?

The properties can be very explicit about distinguishing the asserted vs reified case. My preference would be: rdf:asserts (not rdf:states, because that is not explicit about being "asserted") and rdf:reifies.



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!OOpDXR31-LzNpE83Pflkvwz6SWUp7kwqiNy0rM1BiAPV_T4TbI_F3bDbPdkdN8Iaky_xpMD30qy_AEHg0Lb5_QFGFUl3lg$>
[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!OOpDXR31-LzNpE83Pflkvwz6SWUp7kwqiNy0rM1BiAPV_T4TbI_F3bDbPdkdN8Iaky_xpMD30qy_AEHg0Lb5_QHwrHL3-w$>
________________________________
From: William Van Woensel <william.vanwoensel@gmail.com<mailto:william.vanwoensel@gmail.com>>
Sent: Friday, August 16, 2024 7:24 AM
To: Souripriya Das <souripriya.das@oracle.com<mailto:souripriya.das@oracle.com>>
Cc: public-rdf-star-wg@w3.org<mailto:public-rdf-star-wg@w3.org> <public-rdf-star-wg@w3.org<mailto: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<mailto: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.