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

Am 19. August 2024 18:11:14 MESZ schrieb "Peter F. Patel-Schneider" <pfpschneider@gmail.com>:
>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)?

Why do you ask Souri, but not me? I have provided answers to these questions. 

. t

>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://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0077.html <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 <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
>> 
>

Received on Monday, 19 August 2024 21:26:22 UTC