- From: Andy Seaborne <andy@apache.org>
- Date: Thu, 25 Jan 2024 10:51:29 +0000
- To: public-rdf-star-wg@w3.org
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