W3C home > Mailing lists > Public > public-owl-wg@w3.org > September 2008

Issue-130 (conformance)

From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
Date: Wed, 3 Sep 2008 21:35:13 +0100
Message-Id: <DA3D6943-FD82-4ABA-851B-699269AD7277@comlab.ox.ac.uk>
To: W3C OWL Working Group <public-owl-wg@w3.org>

The idea we came up with on the teleconf was to say that  
implementations MUST issue a warning when they can't be sure about a  
False answer, and to add that implementations not wanting to check  
the conditions could simply return Unknown instead of False. On  
closer examination, this doesn't make total sense and/or seems  
unnecessarily complicated.

In the first place, it is strange to say that implementations MUST do  
something, and then say that they can do something else instead. In  
the second place, it doesn't seem to make much sense to return False  
with a warning that this answer can't be trusted -- surely it would  
be much more sensible to return Unknown under these circumstances.  
This would allow the conformance conditions on OWL RL checkers to be  
greatly simplified, i.e., to say that they can only return False when  
the entailment doesn't hold (just like for the other checkers). We  
could then add a note for implementers pointing out that Theorem 1  
tells them just when it is safe for rule-based implementations to  
return False (when the conditions are satisfied and the entailment  
isn't found by the rules). The note can also say that if they don't  
want to implement the check they can simply avoid returning False.

To make this clearer/more concrete, I implemented this in the  
Conformance document [1].

Still to do: add something about what this would mean in the case of  
query answering, to the effect that a warning MAY/SHOULD/MUST be  
issued if "Unknown" would be the answer to any relevant entailment  
problem.

No doubt you will let me know what you think.

Ian

[1] http://www.w3.org/2007/OWL/wiki/Conformance
Received on Wednesday, 3 September 2008 20:35:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:06 UTC