Re: Against the notion of reification well-formed graph (i.e., atomicity)

I am not sure whether I follow exactly your concerns.
Maybe the following could help.
By using my proposed revised sugar approach, (1) RDF 1.1 graphs are always well-formed, and the RDF-star extension does not play any role whatsoever; (2) if RDF-star graphs systematically use the syntactic sugar expression for reification, then entailments are always well-formed.
—e.

On 24 Jan 2024, at 08:43, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:



On 23/01/2024 15:38, Doerthe Arndt wrote:
Dear Pierre-Antoine,


Am 23.01.2024 um 14:01 schrieb Pierre-Antoine Champin <pierre-antoine@w3.org><mailto:pierre-antoine@w3.org>:


On 23/01/2024 13:30, Doerthe Arndt wrote:

Dear Peter,

Just to be sure (I am still forming an opinion): your proposal would be to add a definition of "wellformedness" (name might change) for  RDF graphs which is simply a property they may or may not have. Then, you envision that there are some applications which expect wellformed graphs as input and complain/warn in case of malformed input?

yes, that's a good summary

OK, I am not happy with the proposal, but could accept this compromise.


  Or should wellformedness be a global requirement for anyone sharing an RDF graph?

no, it would be a "soft" constraint, in the sens that complying implementations may chose to reject OR accept ill-formed graphs.

Back to your original question:

it is true that, given the appropriate semantic extension,
    :e rdf:subject :s ; :rdf:predicate :p ; rdf:object :o.
    :s owl:sameAs :s2.
(which is well-formed) would entail
    :e rdf:subject :s, :s2 ; :rdf:predicate :p ; rdf:object :o.
which is ill-formed. But it would then entail
    :e rdf:subject :s2 ; :rdf:predicate :p ; rdf:object :o.
which is well-formed.

Compare that to the fact that
      :s :p "foo".
entails
      :s :p "foo". "foo" a xsd:string.
which is not valid RDF, but which then entails
      :s :p [ a xsd:string ].
which is valid RDF.

These two examples differ in an important aspect: In the second case, I have a very clear syntax definition which says that literals are not allowed in subject position.
In the first example, I have different triples being logical consequence of the graph stated and I need to choose a representation. This feels rather arbitrary.

In that sense, the comparison you make does not really convince me. What if I want to do reasoning, produce well-formed reification and compare results of reasoners. There is no guidance which triples we need to produce.
I grant you that there are differences, but the gist of my argument was:
from the point of view of RDF reasoning, the constraints on the abstract syntax (compared to generalized RDF) are already arbitrary (and they are "strong" constraints, unlike well-formed-ness).

I don't believe that well-formed-ness should constrain reasoning. But, granted, that raises the question on how you "project" the (possibly ill-formed) result of reasoning into a well-formed graph.


I am also not sure whether we really need the well-formedness. Isn’t the situation similar to lists? We have some syntactic sugar to represent lists and there is nothing preventing the user from using the list-predicates however he wants. So how does syntactic sugar for reification (if that is what we want, I know, semantics is not agreed on yet) differ from syntactic sugar for lists? Why should we add a wellformedness condition to the spec for one of the two and not for the other?
I totally agree with what Adrian wrote: https://www.w3.org/mid/bbdf254e-8108-4406-ac3e-49c2b54162b8@zazuko.com


Kind regards,
Dörthe



Kind regards,
Dörthe



Am 23.01.2024 um 13:17 schrieb Peter F. Patel-Schneider <pfpschneider@gmail.com><mailto:pfpschneider@gmail.com>:



On 1/23/24 07:08, Thomas Lörtsch wrote:


On 23. Jan 2024, at 12:50, Peter F. Patel-Schneider <pfpschneider@gmail.com><mailto:pfpschneider@gmail.com> wrote:

On 1/23/24 06:30, Thomas Lörtsch wrote:


On 23. Jan 2024, at 12:22, Peter F. Patel-Schneider <pfpschneider@gmail.com><mailto:pfpschneider@gmail.com> wrote:



[..]


What the proposal does talk about is RDF reifications, nodes in an RDF graph that are subjects of rdf:subject, rdf:predicate, or rdf:object triples.  The well-formedness requirement states that an RDF graph is ill-formed if it has a node that is the subject of a triple with any of these predicates and is not the subject of exactly


Shouldn’t this be changed to *at least*? See my prior mail in response to Dörthe.


one triple with each of these predicates.  No bijection between triples and anything is either mentioned or implied.  The notion of well-formedness is completely syntactic.


[...]

The proposal is *exactly*.  Changing to *at least* could make it harder to optimize RDF reifications in implementations.

As far as I can tell, multiple subjects, predicates, or objects is more difficult to optimize than missing subjects, predicates, or objects, but I haven't implemented an RDF triple store that optimizes RDF reifications.


But what does it *mean*? Optimizations should only be applied after we know that it means what we want it to mean.
I just realized that saying *at least* makes an implicit assumption about different terms in object position refering to the same entity in the realm of interpretation, i.e. a kind of owl:sameAs-ness. That may be way beyond what we want fix, and insofar saying *exactly* might be the safer and more restrained definition.
Still it introduces a hint of opacity that I’m not happy with.
Thomas


peter


Not so.  The proposal makes no changes to the semantics of RDF.   (So far. There might be a semantic extension that does but I don't think that any change to the semantics, even if there is a semantic extension, is necessary.)

So the formal RDF meaning of an RDF graph like

:a rdf:subject :b, :c .

is unchanged.

Of course, users can add whatever intended meaning they want.  As far as I know, there is nothing in any RDF document that argues against users creating their own semantic extensions based on what RDF graphs mean for them.  There is not even any prohibition against users creating their own completely different meaning for RDF graphs.

peter




<OpenPGP_0x9D1EDAEEEF98D438.asc>

<OpenPGP_0x9D1EDAEEEF98D438.asc>