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

OK, now we appear to be on the same page.

The well-formedness notion has only been included to make it easier to 
optimize the treatment of RDF reification.  In the CG there was discussion of 
this - essentially that making quoted triples be shorthand for reification was 
not possible because that for RDF reification to be adopted there was a need 
for optimized treatment of it and that it was too hard for implementors to do 
the switching between optimized and unoptimized data structures that might be 
required if RDF reifications were either missing triples or had duplicate 
triples.  Hence the notion of well-formed RDF graphs, which are supposed to 
make it easier for implementations to optimize the data structures for RDF 
reifications.

Whether this is necessary or reasonable is a separate notion.  The proposal 
has an option related to the treatment of ill-formed RDF graphs.   I suppose 
that this option could be expanded to require all implementations to correctly 
handle ill-formed RDF graphs and well-formedness be only a best-practices 
notion.

The core of the proposal would remain intact - named occurrences of triples is 
syntactic sugar for RDF reification and there are no changes to RDF graphs or 
simple entailment.

peter


On 1/23/24 06:28, Franconi Enrico wrote:
> 
> 
>> On 23 Jan 2024, at 12:22, Peter F. Patel-Schneider <pfpschneider@gmail.com> 
>> wrote:
>>
>> 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 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.
> 
> Indeed. This is my point.
> This syntactically excludes the well-formedness of the expansion of:
>    << :e1 | :s1 :p1 :o1 >> :p :o .
>    << :e1 | :s2 :p2 :o2 >> :p :o .
> which I argue should be allowed.
> —e.

Received on Tuesday, 23 January 2024 11:46:42 UTC