Re: Errors from entailment regimes

 From an HTTP perspective (not WSDL or SOAP) ...

There is a fixed, small set of HTTP error codes.

4XX are client errors. 5XX are server errors.

SPARQL uses "400 Bad Request" for a syntactically bad query string and 
"500 Internal Server Error" for a server refusing the request for any 
reason.  In query, it's either bad request or the server says no to a 
syntactically-ish request.

There is no concept of application-level errors so while the WSDL may 
spell out the differentcases, for HTTP, theer is a very limited choice. 
  We can give them better names in the document or fix in the currently 
model as Lee mentions.  I don't know if WSDL can map legally two error 
codes to the same HTTP response code.

If the data is unsuitable for the entailment regime, that seems to be to 
be more of a server error than a client error (client errors are 
mistakes in the request) especially for the case when the lcient is not 
naming the data explicitly.

The body of the response may include additional information but most 
HTTP clients are going to ignore that or at best expect HTML.

My conclusion is, for better or worse, that for HTTP we will just have 
the same two error codes and we don't have much room for manoeuvre.

 Andy

On 03/03/2010 12:09 PM, Ivan Herman wrote:
> If I may chime in...
>
> 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
>>>
>>>
>>
>

Received on Wednesday, 3 March 2010 13:30:49 UTC