Re: Errors from entailment regimes

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