- From: Niklas Lindström <lindstream@gmail.com>
- Date: Thu, 25 Jan 2024 10:03:03 +0100
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Doerthe Arndt <doerthe.arndt@tu-dresden.de>, Franconi Enrico <franconi@inf.unibz.it>, Pierre-Antoine Champin <pierre-antoine@w3.org>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
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. > 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 09:03:37 UTC