Re: Errors from entailment regimes

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?

> 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?

> 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.

> 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?

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 Tuesday, 2 March 2010 21:21:55 UTC