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

On 25/01/2024 09:03, Niklas Lindström wrote:
> On Tue, Jan 23, 2024 at 12:55 PM Peter F. Patel-Schneider
> <pfpschneider@gmail.com> wrote:
>>
>>
>>
>> On 1/23/24 05:26, Doerthe Arndt wrote:
>>> Hi all,
>>>
>>> I am joining rather late to the discussion,  so apologies if all I write has
>>> already been said or my problem here is already solved (in the latter case I
>>> am very thankful for your explanations :) )
>>>
>>> So, to look to Enrico’s point from another direction, let’s assume that we
>>> have RDF and we would like to simply add support for owl:sameAs (for whatever
>>> reason).
>>>
>>> Now, we would normally have that from
>>>
>>> :s :p :o.
>>> :o owl:sameAs :k.
>>>
>>> we could derive
>>>
>>> :s :p :k.
>>>
>>> But what happens if we have
>>>
>>> :t rdf:subject :s;
>>> rdf:predicate :p;
>>> rdf:object :o.
>>>
>>> and
>>>
>>> :o owl:sameAs :k.
>>>
>>> following the same logic as above, we would derive
>>>
>>> :t rdf:object  :k.
>>>
>>> But with that derivation, we violate our wellformedness constraint which is a
>>> purely syntactical constraint. So, here, we seem to have a problem because we
>>> mix up syntax and semantics.  Maybe your proposals already contained a
>>> solution which I missed? How do we avoid such derivations?
>>>
>>> Kind regards,
>>> Dörthe
>>
>>
>> Not so.  There is no notion of adding the triple back into the RDF graph.  So
>> there is no ill-formed RDF graph here.
> 
> This is key. Along with a working notion of well-formedness (for both
> reification and lists), it could pretty much seal the deal from my
> perspective.

Not directly "adding" but merging two graphs produces a graph.

"well-formed" is not guaranteed unless only blank nodes are used for the 
name.

RDF/XML gives reification URIs.
https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-reifying

>> What implementations do internally is not affected.  All that implementations
>> are permitted to do is to reject ill-formed RDF graphs on input.  What they do
>> internally is not changed - an implementation that adds consequences to its
>> internal data structures is on its own.
> 
> What goes for querying and output? For instance, having something like
> `FILTER [NOT] ENTAILED [VAR*]` to SPARQL would be valuable (a
> standardized alternative to the mechanisms discussed in [1]). To be
> able to selectively query over the entailed triples could also solve
> some/most of the problem of referential opacity or transparency.
> 
> Best regards,
> Niklas
> 
> [1]: https://github.com/w3c/sparql-dev/issues/124
> 
> 
>> peter
>>
>>
>

Received on Thursday, 25 January 2024 10:51:37 UTC