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

On 22 Jan 2024, at 20:46, Peter F. Patel-Schneider <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.
If I am wrong, then I guess we agree!

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, while we should not enforce (2) in neither forms 2.a or 2.b.
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 - but please fix the definition.

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.