- From: Steve Harris <steve.harris@garlik.com>
- Date: Thu, 24 Sep 2009 11:57:25 +0100
- To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 24 Sep 2009, at 10:56, Birte Glimm wrote: > 2009/9/24 Steve Harris <steve.harris@garlik.com>: >> On 24 Sep 2009, at 10:16, Bijan Parsia wrote: >> >>> On 24 Sep 2009, at 10:01, Steve Harris wrote: >>> [snip] >>>> >>>> My understanding is that it is a legal query, it's prohibited >>>> neither by >>>> the syntax, nor the query algebra. >>>> >>>> However, it can't ever match any RDF triples in the query >>>> processors >>>> data, as there can be no legal triples with literal subjects. >>> >>> Without inference. In the presence of RDFS interpretations, there >>> are >>> situations where one might reasonably think that >>> "<foo/>"^^rdf:XMLLiteral rdf:type rdfs:Literal. >>> >>> is entailed by: >>> :s :p "<foo/>"^^rdf:XMLLiteral. >>> >>> The only thing preventing that entailment would be a syntactic >>> restriction >>> on the form of things entailed (e.g., if we restrict ourselves to >>> legal RDF >>> graphs.) >> >> SPARQL/Query 1.0 is restricted to legal RDF graphs though, as per (my >> reading at least) of section 12.6. > > Well, but according to the RDFS semantics the tuple Bijan mentions is > entailed. It cannot be stated in any input graph, but it is an > entailment und RDFS entailment (never under simple entailment). Now as > Axel said, we have the restriction on extensions of SPARQL to other > entailment regimes (Section 12.6 of the current spec) that says: > "For any basic graph pattern BGP and pattern solution mapping P, > P(BGP) is well-formed for E." > So for the query > SELECT ?x WHERE { ?x rdf:type rdfs:Literal . } > I would get a mapping of "<foo/>"^^rdf:XMLLiteral for ?x if I consider > all entailed tuples (which is natural since we do entailment), but > since P(BGP)="<foo/>"^^rdf:XMLLiteral rdf:type rdfs:Literal . is not > well-formed for RDFS, I would rule it out as an answer. Agreed. > Another question that came up when reading the restriction from > Section 12.6 above was whether I should rule out answers or rule out > queries. In my current understanding I read it as every SPARQL query > is valid for all entailment regimes, but I can rule out answers that > would lead to solutions that are not well-formed for the entailment > regime. This becomes even more interesting if we look at OWL 2 DL > because there we have quite a lot of restrictions on what RDF tuples > constitute a valid OWL 2 DL ontology. There I can either allow all > queries and those with a BGP that can never be instantiated into a > valid OWL 2 DL statememt will just always have no answers or I can > rule out such queries. I personally prefer the latter approach since I > can then raise an error that explains to the user that the query is > not well-formed for OWL 2 DL for reason X. If I just return no answer, > users might not understand what is wrong and why they do not get > answers. As I understand the restrictions from 12.6 though, I should > take the return an empty answer approach. I think that 12.6 more indicates that you should rule out answers, but nothing stops you from issuing a warning to the user that the query can return no results due to the expression. We do that, e.g. if someone tries to apply a regex to a URI, which is common for people new to SPARQL. - Steve -- Steve Harris Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK +44(0)20 8973 2465 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Thursday, 24 September 2009 10:58:01 UTC