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

The mapping from names to triples is not an injection, so there is no 
entailment (in an RDFS++ semantic extension of the syntactic sugar proposal) from

<< :e | :s :p :o >> :a :b .
<< :f | :s :p :o >> :a :b .

to

:e owl:sameAs :f .


To see this, just look at the expansion

:e rdf:type rdf:Statement .
:e rdf:subject :s .
:e rdf:predicate :p .
:e rdf:oject :o .
:e :a :b .
:f rdf:type rdf:Statement .
:f rdf:subject :s .
:f rdf:predicate :p .
:f rdf:oject :o .
:f :a :b .

and notice that there is no entailment of

:e owl:sameAs :f .

Well-formedness has no role here.  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 don't see how the following is a typical set of reification statements:

<< :w1 | :bill-clinton :related-to :hillary-rodham >> :starts 1975 .
<< :w1 | :42nd-potus :husband :1st-female-NY-senator >> :starts 1975 .

This expands (using the base expansion) to something like:

:1w rdf:type rdf:Statement .
:1w rdf:subject :bill-clinton .
:1w rdf:predicate :related-to .
:1w rdf:oject :hillary-rodham .
:1w :starts 1975 .
:1w rdf:type rdf:Statement .
:1w rdf:subject :42nd-potus .
:1w rdf:predicate  :husband .
:1w rdf:oject :1st-female-NY-senator .
:1w :starts 1975 .

which looks *very* weird to me.  I am not aware of any use of RDF reification 
that depends on the ability to have multiple subject, predicates, or objects.

In the optional expansion there is no problem with two reifications having the 
same name but the expansion is different.


peter


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.

Received on Monday, 22 January 2024 19:46:38 UTC