- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Wed, 3 Mar 2010 15:00:49 +0000
- To: Ivan Herman <ivan@w3.org>
- Cc: Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>, dcharbon@us.ibm.com, Andy Seaborne <andy.seaborne@talis.com>
On 3 March 2010 12:09, Ivan Herman <ivan@w3.org> wrote: > If I may chime in... Sure. Very welcome. Basically, I agree with all being said and that all errors could be handled with what is there. From how I understand the spec, systems can always give a detailed (human-friendly) error message, which might not always be displayed (HTTP) depending on the client. Nevertheless, I noticed that for the WSDL, there are more detailed error definitions for update, which I suppose have to be mapped to the same HTTP errors. If that's not possible, then the update errors (GraphAlreadyExists etc) are already problematic. If it is possible, then I think it would be nice if we could have such errors also for typical entailment errors, to encourage a consistent&informative behavior across different systems. For HTTP, these would then be mapped to the same error codes with a detailed message that might or might not be displayed to the user. Birte > On 2010-3-2 22:21 , Lee Feigenbaum wrote: >> Hi Birte, >> >> Thanks. Allow me to play devil's advocate for a bit to see if we do >> indeed need to pursue these errors. :) >> >> On 3/2/2010 12:09 PM, Birte Glimm wrote: >>> Hi all, >>> since entailment regimes is a time permitting feature, there might not >>> be teleconf time to discuss this, but there are a couple of occasions >>> when systems which use non-simple entailment might want to throw >>> entailment specific errors. I went through the ent regime spec and >>> looked at what kind of errors HermiT can throw and these things seem >>> to be needed: >>> 1) An error that indicates that the graph is not well-formed for the >>> regime. In OWL with Direct Semantics and in particular in the OWL >>> Direct Semantics profiles not all graphs are legal and this error >>> would indicate that the system cannot deal with the triples in the >>> active graph for the query. I guess that would still count as query >>> fault, e.g., of the form >>> <fault name="MalformedGraphForEntailmentRegime" >>> element="st:malformed-graph-for-entailment-regime"/> >> >> The analog of this for simple entailment seems to be if the RDF for a >> graph is malformed. SPARQL doesn't handle that, because we consider it >> out of scope for the query engine to raise errors for bad data in the >> store. Why is this different for entailment regimes? Are these errors >> only surfaced via queries? >> > You are right it is close, but it may be misleading. The same graph can > be perfectly kosher for one entailment regime and not for another, > which, for me, puts into a slightly different box as the simple > malformed graph. Put it another way, it may be much more informative, > ie, useful for the user if it is explicitly flagged as being incorrect > for a specific regime. > >>> 2) Under OWL Direct Semantics also BGPs can be malformed, i.e., the >>> BGP cannot be mapped into OWL objects. At the moment that results in >>> an empty query answers and is not an error, but we might want to >>> change that. In the latter case that would result in an error such as >>> <fault name="MalformedBGPForEntailmentRegime" >>> element="st:malformed-bgp-for-entailment-regime"/> >> >> Could this simply use the existing MalformedQuery fault? > > I think that is right. > >> >>> 3) An error that systems can throw when the queried graph is >>> inconsistent and the system has detected that. >>> <fault name="InconsistentGraph" element="st:inconsistent-graph"/> >> >> Same question as for #1. This seems like an error in the data, and not >> necessarily one that need be called out by the query protocol itself. >> > > Same answer as for #1:-) > >>> 4) Systems that implement the OWLReasoner interface can be configured >>> to raise an error if queries contain names that don't occur in the >>> graph. E.g., if I have a query with BGP: ?x a ex:C and ex:C that mean >>> the reasoner (again this applies to Direct Semantics) should compute >>> individuals that have (unknown) type ex:C. HermiT by default allows >>> such queries and we just switch to raising such errors in rare cases, >>> e.g., because it is useful to detect namespace errors. I personally >>> can live with just allowing such queries. They don't really do any >>> harm IMO. >> >> Could this be covered by either MalformedQuery or QueryRequestRefused? >> > > Probably yes (MalformedQuery) > > Ivan > >> Lee >> >>> Maybe somebody else has something to add. Other errors such as syntax >>> errors in the query etc are already captured in the protocol. Timeouts >>> seem to be handled as refused requests, so that's covered too. >>> >>> Birte >>> >>> >> > > -- > > Ivan Herman, W3C Semantic Web Activity Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 > PGP Key: http://www.ivan-herman.net/pgpkey.html > FOAF : http://www.ivan-herman.net/foaf.rdf > vCard : http://www.ivan-herman.net/HermanIvan.vcf > > -- Dr. Birte Glimm, Room 306 Computing Laboratory Parks Road Oxford OX1 3QD United Kingdom +44 (0)1865 283529
Received on Wednesday, 3 March 2010 15:01:23 UTC