Re: voting against use of rdf:ReificationProperty

I agree with William, and he laid it out nicely, that only one property (like rdf:reifies) and a lot of additional statements to capture all the nuances is not a good idea. 

However, I also think that all those nuances still fall into two main categories, namely if the annotated triple term is meant to be true in the graph or not: 
- most of them are meant to be true (see use cases, see real world data) 
- those that aren't can’t be introduced first and then taken back (that would jeopardize monotonicity)

This difference is fundamental and use cases call explicitly for the ability to annotated statements without stating them. The tricky part, and where there is disagreement in this WG - is if that "without stating them" constitutes a propositional attitude, i.e. the explicit desire to not state them, or is it captured faithfully enough by just not stating them, and if they are stated for another reason, or by another user, then so be it...

The approach taken so far - to have only one reification property and model the difference with additional statements - takes the latter approach, but, depending on the users intuition, this can lead to ambiguity and non-monotonic behaviour, especially when integrating data from different sources. Also the syntactic sugar suggested for Turtle-star isn’t safe when roundtripping with N-triples. In short it is impossible to reliably capture the _intent_ to annotate a statement without stating it.

Therefore two basic properties are needed - rdf:reifies and rdfs:states - and then, if need be, additional statements or subproperties of rdf:reifies and rdfs:states may add nuance. Those nuances IMO belong into user land, i.e. domain ontologies, but not the RDF specification.

An argument against more (and also against less) properties is that we support some properties with extra syntactic sugar:
- << :s :p :o >> is mapped to rdf:reifies
- annotation syntax is currently also mapped to rdf:reifies but IMO should be mapped to rdfs:states (because that’s what it does: it annotates a stated triple)
That syntactic sugar, once defined, can’t be re-mapped to other properties. And not every desirable nuance can have its own syntactic sugar. That suggests that additional nuance is more likely to be provided by additional statements than by more specific properties. Or am I speculating too much here?

Thomas


> On 29. Aug 2024, at 22:05, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> 
> I agree with Dominik: RDF as few restrictions, really none beyond what the Abstract and Concrete syntaxes allow. Being able to infer that the predicate of a triple including a triple term is an instance of rdf:ReificationPropery is the proper way to handle this. RDFS entailment could infer that the object is a triple term if used with rdf:reifies, given that rdf:reifies has a domain of something like rdf:Statement. If this results in non-sensical entailements, then that is an indication that there is likely a modeling error.
> 
> RDF allows other things to be stated that don’t make sense, but aren’t generally restricted. Implementations can decide how to handle graphs which include inconsistencies, such as by generating warnings.
> 
> Gregg Kellogg
> gregg@greggkellogg.net
> 
>> On Aug 29, 2024, at 12:37 PM, ddooss@wp.pl wrote:
>> 
>> Hi William,
>> 
>> I definitely agree with the proposal to introduce ReificationProperty. This approach is very much in line with the spirit of RDF. Shifting this to semantic rules and extending the vocabulary is the kind of solution that has been the foundation for previous versions of RDF. The examples you provided are spot on and clearly illustrate the benefits of this approach.
>> 
>> Best regards,
>> Dominik
>> Dnia 29 sierpnia 2024 20:31 William Van Woensel <william.vanwoensel@gmail.com> napisał(a):
>> 
>> Hi Gregory,
>> 
>> Re your question on this during today's meeting. FWIW, my interpretation on the usefulness of ReificationProperty:
>> 
>> (1) Using any property (instead of just rdf:reifies/rdf:asserts) with a triple term object.
>> Souri mentioned in a prior message <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0147.html> a need to distinguish between the "veracity" of the triples within triple terms; e.g., one is a hypothesis, another is truth; one is asserted, another is not; etc. 
>> 
>> If rdf:reifies is the only "reification property" available, then this requires something like (using Souri's example):
>> 
>> :id rdf:reifies <<( :s1 :p1 :o1 )>> ; a :Hypothesis .
>> :id rdf:reifies <<( :s2 :p2 :o2 )>> ; a :Truth .
>> 
>> I.e., multiple triples each time. If separate rdf:asserts (for hypothesis, non-asserted, etc) and rdf:reifies (for truth, asserted, etc.) are available, then this fits in a single statement:
>> 
>> :id rdf:reifies <<( :s1 :p1 :o1 )>> .
>> :id rdf:asserts <<( :s2 :p2 :o2 )>> .
>> 
>> Andy later pointed out <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0148.html> that there are other possible meanings that can be associated. (I may be missing many, many messages and discussions before, in between, or after.) IMO, one can indeed say that "hypothesis", "unknown", "conflicting" all fit under rdf:reifies - i.e., one doesn't want to assert the triple of the triple term - but with different slightly semantics each time. Using only 1 property for all those cases would mean that one still needs multiple statements, e.g., 
>> 
>> :id rdf:reifies <<( :s2 :p2 :o2 )>> ; a :Hypothesis .
>> :id rdf:reifies <<( :s3 :p3 :o3 )>> ; a :Conflicting .
>> 
>> Etc. Instead of a limited set of properties (rdf:asserts, rdf:reifies), allowing custom properties there supports any type of nuanced meaning: 
>> 
>> :id rdf:hypothesis <<( :s2 :p2 :o2 )>> .
>> :id rdf:truth <<( :s3 :p3 :o3 )>> .
>> 
>> One can then have rules, queries, or application logic that assigns some custom semantics to these properties. 
>> 
>> I appreciate the flexibility this brings, while still allowing a 1-triple description (e.g., for easy mapping to a DB table). Right now I don't see how it makes it harder to implement RDF-star; it does allow people to shoot themselves in the foot a bit more (well, a lot of things do; this is a typical trade-off) but for that we have ReificationProperty:
>> 
>> - Inferring that a property with a triple term object has type ReificationProperty.
>> Looking at the inferences of your statements, rdf:hypothesis or rdf:truth (from the example above) will show up as instances of ReificationProperty. This may or may not be in line with your expectations. Someone may have wrongfully used foaf:name as a reification property; it will show up as such in your inferences, thus "flagging" the issue. You may even have explicit OWL constructs, rules, or application code in place to raise inconsistencies in those cases. As Enrico said, these inferences simply explicate what is already implicit in your data; but this explication can be quite useful.
>> 
>> 
>> Regards,
>> 
>> William
>> 
>>> On Aug 27, 2024, at 8:07 AM, William Van Woensel <william.vanwoensel@gmail.com> wrote:
>>> 
>>> Hi Souri,
>>> 
>>> Could you elaborate on how this would make it harder to implement RDF 1.2? (I was not at the semantics TF - it seems that rather important issues are discussed there, but I'm unsure how to join.)
>>> 
>>> I'm also not seeing how it could lead to people messing up their data.
>>> 
>>> 
>>> Thanks
>>> 
>>> William
>>> 
>>>> On Aug 26, 2024, at 9:02 AM, Souripriya Das <souripriya.das@oracle.com> wrote:
>>>> 
>>>> Although during our last Semantic TF meeting I had put +1 in the straw poll regarding allowing any property to have triple-term as value as long as the property is (or can be inferred to be) of rdf:type rdf:ReificationProperty, thinking about it a bit more I have changed my opinion. I think it is giving too much freedom to the user that may lead them to mess up their data more easily and it will make it harder to implement RDF1.2. So, I would now vote against the use of rdf:reificationProperty and instead, vote for allowing only pre-designated properties in RDF1.2 (like rdf:reifies, and, if deemed important, rdf:asserts) to have triple-term as their values.
>>>> 
>>>> Thanks,
>>>> Souri.
>>> 
>> 
>