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

(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://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html
[2] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0081.html
________________________________
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