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

Much of this this message is reiteration of points made previously but it 
appears that these points need to be reiterated.

It is important to realize that the presence of
   :a rdf:reifies << :b :c :d >> .
in an RDF graph is completely agnostic as to whether :b :c :d is a member of 
the RDF graph, is not a member of the RDF graph, is entailed by the RDF graph, 
is not entailed by the RDF graph, might be entailed by the RDF graph, or might 
not be entailed by the RDF graph.  So rdf:reifies is not concerned with 
assertional force, provenance, or any other related notion.  All that 
rdf:reifies provides is the standoff that is (almost) always needed between 
other statements and triple terms.

If one wants to specify provenance or assertional force rdf:reifies does 
nothing to get in the way.  All one has to do is to attach the provenance or 
assertional force to the subject of the rdf:reifies triple, as  in
   :a rdf:reifies << :b :c :d >> .
   :a prov:assertionalForce "1"^^xsd:integer .
   :a prov:source :nyt .

One could argue that this is somehow too wasteful or too fragile or too hard 
and that either a direct or different connection to the triple term is needed. 
  That's easy to do - just get rid of rdf:reifies and allow triple terms to 
occur in both subject and object positions.  Then one can say

   :a prov:asserts << :b :c :c >> .

or even

    << :b :c :c >> rdf:type rdfs:Assertion .

But none of that deserves to be in the RDF namespace.


peter




On 8/21/24 08:14, Thomas Lörtsch wrote:
> [sorry, belated response]
> 
>> On 17. Aug 2024, at 19:12, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>> I support the comments of Gregg Kellogg and provide the following extra information on this stance on triple terms and reification.
> 
> I assume you’re referring to [0]. I agree with that mail w.r.t. the proposed "rdf:id" name, but that is just naming and can be discussed at the end of this process, as long as we know what we are talking about (which of course the discussion of naming intertwined with the discussion of meanings makes a bit harder).
> 
> But I disagree on characterizing the current proposal as RISC. The secret of a succesfull RISC design is to find the exact right primitives, which takes skill and careful consideration. The current proposal is underspecified and underpowered in important ways, and that leads to unsufficient expressivity, resulting in verbosity and ambiguity.
> 
> I don’t find arguing with such slogans very helpful. In general e.g. light cars are better than heavy cars because they use less resources and are more agile and predictable in driving, but if the car gets too light safety is compromised. Every concept needs to be balanced, and those slogans like "light weight", "basic building blocks", "RISC" are often just marketing blabla.
> 
>> 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.
> 
> Which is irrelevant because the example illustrates how the fact that an annotation is meant to refer to something unasserted is lost. To cite the first paragraph of Souri’s mail that started this thread [2]:
> 
>>> 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).
> 
> That succinctly and fully describes the problem, and the motivation for a new predicate. What you find unconvincing - lack of some specific properties - is indeed sign of how fundamental this problem is. There is no more basic differentiation than if a statement is asserted to be true in a graph, or not. Anything else is just additional detail, and not relevant here (and, here I agree with others, can be handled by domain ontologies).
> 
>>    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.
> 
> Which is why Enrico in Friday’s SemTF meeting suggested to not use it, at all - hurray! And which is also why Souri and I argue that something more assertive is needed. Arguing with the lack of assertive force of rdf:reifies in this context is almost a mockery. That is not the solution, it is the problem.
> 
> What Souri describes is exactly the intuition that is to be expected, and even very knowledgeable and careful people like Niklas use it that way [3]. It is the natural interpretation. That the proposed baseline doesn’t support it is indeed the core of all the trouble with 'rdf:reifies’. The problem is that by following the definition by the book makes the concept useless to the task at hand: "statements about statements".
> 
> Put another way: statements about statements is the task of this WG, and statements are facts. However, reifications are not, and therefore a semantics based on reification misses the mark. It is good for statements about unasserted statements, and that has been established in discussions as an additional requirement. But, and here I fully agree with Souri, that is not our main objective. Most statements to be annotated are indeed meant to be true in the graph. That’s the intention that a construct has to capture (and the shorthand annotation _syntax_ supports it perfectly). Reification can't do that as you rightly stress, but some clever combination of constructs - like rdfs:states and syntactic sugar in Turtle-star and a fitting arrangement in SPARQL-star - can. And then, as a welcome side effect, refering to unasserted statements by reification also becomes unambiguous. That would be a complete solution. Everthing less expressive is a "hack" (citing Gregg here, albeit deliberatley contrary to the intent in which he used the term).
> 
>> Using a second predicate that has no semantics
> 
> I have provided a proposal for a semantics [1]. The precise wording may need more discussion, but the general direction is clear.
> 
>> 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.
> 
> What you suggest could be deemed non-monotonic? Ah, no, right, it’s reification, so not a fact anyway. So we are back again at the main problem. As long as you don’t acknowledge that, we won’t have a constructive discussion. But you don't WANT statement annotation to happen, you want us all to subscribe to E/R modelling and give up on graphs already. I discussed a similar concept with Fabio in the CG. IMO it is too complex to be feasible. It certainly has nothing to do with the idea of RDF.
> 
>> None of this affects the baseline, which does not touch on provenance or assertional force.
> 
> As far as the baseline is not affected that just shows that the baseline is insufficient.
> 
> Thomas
> 
>> peter
>>
> 
> 
> [0] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Aug/0081.html

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

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

> [3] https://gist.github.com/niklasl/f4a5dee1b991ff5a19a33360c6fd3078

Received on Wednesday, 21 August 2024 13:02:24 UTC