- From: Thomas Lörtsch <tl@rat.io>
- Date: Fri, 23 Aug 2024 16:39:29 +0200
- To: Franconi Enrico <franconi@inf.unibz.it>
- Cc: Niklas Lindström <lindstream@gmail.com>, Andy Seaborne <andy@apache.org>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
> On 23. Aug 2024, at 14:43, Franconi Enrico <franconi@inf.unibz.it> wrote: > > On 23 Aug 2024, at 14:27, Thomas Lörtsch <tl@rat.io> wrote: >> Yes, I know this is tricky without entailment, but I have shown a way - combining an unambiguous definition of rdfs:asserts (it expects the triple term to be true in the graph) with the annotation syntax (which captures that expectation) and a configuration of SPARQL-star (to map BGP over a union of triples and rdfs:stated triple terms). > > Thomas, I don't understand why you want to emulate the missing entailments (that you don't want in RDFS) I certainly want them in RDFS. What makes you think that I don’t want them there? > within basic SPARQL. Eventually, the complexity will be the same as having it natively in RDFS. As a matter of facts, you want to implement part of typical RDFS reasoning in SPARQL (but not in simple entailment) I understand that we can’t have that sort of entailment in simple RDF. That’s why I try to emulate it in SPARQL. I want the user to not have to explicitly join queries over standard triples and rdfs:stated triple terms. To the user there should be no difference (unless of course s/he explicitly makes that distinction in the query) > . And why do you believe that your use case deserves this special bizzarre really not bizarre > and non-standard treatment because the standard often leans towards formal purity, not usability > , as oppsed to, say, rdfs:subClassOf, which seems to me much more important that rdfs:asserts. Because to me it seems that rdfs:states is much more important, especially in the context of our WG task, and because in contrast to say rdfs:subClassOf it is very predictable .t > —e > .
Received on Friday, 23 August 2024 14:39:39 UTC