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

In my opinion the definition requires fixing since it disallows:
  :e1 rdf:subject :s1 ; rdf:predicate :p1 ; rdf:object :o1.
  :e1 rdf:subject :s2 ; rdf:predicate :p2 ; rdf:object :o2.
If you want to allow the above case, then we agree and I am happy again :-)
cheers
—e.


On 23 Jan 2024, at 10:42, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:



On 23/01/2024 09:24, Franconi Enrico wrote:


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

The mapping from names to triples is not an injection,

From what I read in your document:

Definition: An RDF graph is reification well-formed iff any node in it that is the subject of a triple in the graph with predicate rdf:subject, rdf:predicate, or rdf:object must be the subject of exactly one triple in the graph with each of these predicates. [bold/underline is mine]

So, the definition I am reading from you requires a bijection.
I don't see any bijection here...
If anything, there is a functional relation from the "triple name" (the subject of rdf:subject, rdf:predicate and rdf:object) and the 3-uple made of the objects of the 3 "reification triples".
Nothing in the definition requires it to be inverse functional, neither syntactically nor semantically.

The following is well-formed (and does not entail that :e1 and :e2 are owl:sameAs):

  :e1 rdf:subject :s ; rdf:predicate :p ; rdf:object :o.
  :e2 rdf:subject :s ; rdf:predicate :p ; rdf:object :o.

If I am wrong, then I guess we agree!
I think we do :)

All well-formedness says is that you can't mess up the reification structures, i.e., you can't add something like

:e rdf:subject :t .

to the above graph and retain well-formedness.

I believe that here we are confusing two distinct aspects:

  1.  avoiding dangling links in the expansion to :e rdf:subject :s.
    :e rdf:predicate :p.
    :e rdf:predicate :o.
  2.  having a bijection between triples and their names,
which, in turn, should be clarified whether it is intended
  2a.  syntactically or
  2b.  semantically

I believe that (1) should be always enforced,
and this is precisely what I (and, I believe, Souri and Andy) meant by "atomicity", nothing less, nothing more.
Well-formed-ness was an attempt to "softly" enforce this without changing the abstract syntax.
Andy and Souri seem to prefer a "stronger" enforcement, via a change in the abstract syntax.
while we should not enforce (2) in neither forms 2.a or 2.b.
Also agreed. The main motivation for naming triples was, in the first place, to overcome the issue of "unicity" that the CG proposal had.
We should describe in the best practices section the case where users should use RDF* to encode reification with bijection, by just self-imposing such restriction.
But there are many cases where this shouldn’t be the case.
It seems that we agree here, so I am happy -
me too :-)
but please fix the definition.
I still disagree that the definition you quote at the top of this email requires fixing...

cheers
—e.

On 1/22/24 10:51, Franconi Enrico wrote:
In this message I want to argue against the notion of reification well-formed graph (i.e., atomicity).
Adding atomicity violates a necessary aspect of the proposal (as written by pfps):
"There is no intended meaning of the new concrete syntax beyond what it expands to".
According to atomicity:
(1)
<<:a | :s1 :p1 :o1>> :s :o .
<<:b | :s2 :p2 :o2>> :s :o .
:s1 :same-as :s2 .
:p1 :same-as :p2 .
:o1 :same-as :o2 .
should entail
:a :same-as :b .
Atomicity adds an intended meaning: it assumes that the same triple has systematically the same identifier, and therefore (1) should be a valid entailment.
If you don’t like entailment (1), then you contradict the intention of atomicity, UNLESS you assume full opacity.
(2)
<<:a | :s1 :p1 :o1>> :s :o .
<<:b | :s2 :p2 :o2>> :s :o .
:a :same-as :b .
should entail
:s1 :same-as :s2 .
:p1 :same-as :p2 .
:o1 :same-as :o2 .
Atomicity adds an intended meaning: it assumes that a resource identifies at most one triple.
If you don’t like entailment (2), then you contradict the intention of atomicity, UNLESS you assume full opacity.
So, (1) and (2) show that _EITHER_ you assume full opacity (and therefore you are assuming an intended meaning), _OR_ you accept the above entailments (and therefore you are assuming an intended meaning).
Note also that entailments like the above make the life of SPARQL BGP matching more complex.
I also understand that most (if not all) use cases assume transparency.
(3)
Atomicity would disallow writing typical reification statements like:
<< :w1 | :bill-clinton :related-to :hillary-rodham >> :starts 1975 .
<< :w1 | :42nd-potus :husband :1st-female-NY-senator >> :starts 1975 .
cheers
—e.


<OpenPGP_0x9D1EDAEEEF98D438.asc>