Re: OWL reasoning in rules

(trimmed crossposts)

On 25 May 2007, at 11:02, Ian Horrocks wrote:

> Hi Matt,
>
> It isn't completely clear whether you are asking about using some  
> kind of rule engine
[snip]

Note that this is one of the issues. "Rules" isn't a well-defined  
term. Do you mean logic programming rules (and if so, do you mean  
datalog, disjunctive datalog, prolog, and then for several of these,  
with what sort of specific features and semantics), production rules,  
ECA rules, first order logic conditionals?

Each one of these has different expressiveness (though there are  
overlap and subset relations). If you pick the "right" one (e.g., to  
simplify, first order logic) then there is a simple transliteration  
that will work (the so-called standard translation). However, you may  
not get a decision procedure out of your FOL reasoner (unless you  
tweak a load of parameters; see the excellent work of Renate Schmidt)  
and even when you do, it might not be very efficient (certainly on  
the standard translation; see the Hoolet papers).

Basically, reducing OWL to something a given rule engine can process  
requires theory and engineering to be correct and practical...just as  
with any other implementation technique. There are a large number of  
tradeoffs along the way.

Also, many rule engines presume, and thus are tuned for, relatively  
few rules and a lot of data (see the datalog family). Many OWL  
ontologies are the reverse (sometimes no data!). So there can be  
other mismatches.

Some fragments of OWL align more neatly with some rule engines. If  
you look at the OWL 1.1tractable fragment documents:
	http://webont.org/owl/1.1/tractable.html

You'll see that many of the fragments have more or less direct  
translations to horn rules. The complexity results give some hints as  
well.

As Ian said, incompleteness (in the sense of not being a decision  
procedure, but many of the rules variants aren't even complete; i.e.,  
using the standard translation to FOL and naively using a FOL  
reasoner will get you a sound and complete reasoner, but not a  
decision procedure (thus 'incomplete' in the sense ian was saying)).

One might be willing to trade completeness/decidability for other  
things (though the cleanest way to do this is to define a fragment).  
However, the current infrastructure for helping users *understand*  
the significance of failed computations is pretty non-existent.  
Working on it :)

Cheers,
Bijan.

Received on Friday, 25 May 2007 10:33:06 UTC