LC Comment on Entailment Regimes: Treatment of Semantic Inconsistency

Dear all!

Document: SPARQL 1.1 Entailment Regimes
State: LCWD

The tables that specify the different entailment regimes have an entry 
"Inconsistency", which defines how systems should handle the case of 
inconsistent queried graphs. For example, for the OWL 2 Direct 
Entailment Regime, it is stated:

     If the queried ontology is inconsistent under
     OWL 2 Direct Semantics, the system MUST raise
     an error.

Proposal
--------

I propose to drop any normative treatment of inconsistent graphs. Having 
an informative discussion is sufficient in my opinion. Not treating this 
topic at all would also be fine.

Rational
--------

* Not for all specified entailment regimes can be guaranteed that 
consistency checking will always lead to a positive result if the 
queried graph is really consistent (the normal case): The OWL 2 
RDF-Based semantics is undecidable, and RIF-Core + OWL combinations and 
RIF-BLD entailment (although not directly specified in the spec) are as 
well. System implementers of query engines for these languages will not 
be able to create a compliant system. Even with a "SHOULD" instead of a 
"MUST", this would still lead to user expectations and to some 
"pressure" on implementers that such systems will at least have to 
"try". But trying could easily be hazardous for such systems, so an 
implementer may well decide to never try at all.

* Even for decidable regimes, the additional effort to decide 
consistency may heavily negatively affect efficiency, and implementers 
may not be willing to support this, but just tell users of their system 
to check decidability of a queried graph in a preprocessing step with a 
dedicated reasoning tool (an entailment checker) instead, which is very 
easily be done. But then, their query engine will not be compliant.

* Implementers may even feel that there is no real reason to 
specifically treat inconsistent queried graphs at all, but think that it 
is better to simply use their general query answering procedure to 
handle the special case in the same way as any other case, leading then 
to all possible results ("principle of explosion"). This is, for 
example, the case for some first-order logic reasoners with 
query-answering support, as for E 
(http://www4.informatik.tu-muenchen.de/~schulz/E/E.html). 
Implementations that build on top of such a system will not be compliant 
then, although they may be correctly and efficiently working systems in 
all other respects.

* I believe that many current query systems with reasoning support, at 
least the majority of "light-weight" RDF entailment-rule-based systems, 
such as those based on the Jena RDF framework (using the Jena rule-based 
OWL implementations), do not perform automatic consistency checking on 
every query, but one has to request an entailment check explicitly, if 
supported at all. So, a normative handling of inconsistency would ignore 
current practice.

* In general (a bit more philosophical), it is my opinion that the 
reasoning task "(in)consistency checking" should be considered separate 
from the task "query answering", and is IMO out of scope for the 
specification of SPARQL entailment regimes.

Best regards,
Michael

-- 
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schneider@fzi.de
WWW  : http://www.fzi.de/michael.schneider
==============================================================================
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Dipl. Wi.-Ing. Michael Flor, Prof. Dr. rer. nat. Ralf Reussner,
Prof. Dr. rer. nat. Dr. h.c. Wolffried Stucky, Prof. Dr. rer. nat. Rudi 
Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
==============================================================================

Received on Tuesday, 26 July 2011 13:11:28 UTC