Re: Errors from entailment regimes

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

-- 

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