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

On 23/01/2024 09:24, Franconi Enrico wrote:
>
>
>> 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.
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.
>>
>