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

(oops, you are right, my mistake :-)

On Fri., Aug. 16, 2024, 6:46 p.m. Souripriya Das, <souripriya.das@oracle.com>
wrote:

> > :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 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?
>
> 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>
> *Sent:* Friday, August 16, 2024 4:01 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
>
> 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>
> 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>
> *Sent:* Friday, August 16, 2024 9:29 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,
>
> 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>
> 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>
> *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>
> *Sent:* Thursday, August 15, 2024 11:59 AM
> *To:* RDF-star WG <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.
>
>
>
>