From: Benjamin Grosof (bgrosof@mit.edu)
Date: 10/14/03
______________________________________________________________________________________
% revised version of "warning label" section for OWL Rules draft
% by Benjamin Grosof and Michael Dean
% Oct. 14, 2003 13:00 EDT
%%%%
As I promised during the Tuesday 10/7/03 telecon, here's a revised
draft of a "warning label" section. It's substantially expanded and
reorganized. Mike also gave significant input on this second
iteration, as well.
Some suggestions for additional future edits on this section:
(these were partially raised during the 10/7/03 telecon discussion):
1. we should expand the examples, e.g., give a full rule rather
than just an atom.
2. we should give more details in terms of the abstract syntax,
both for the expressive restrictions and for the examples of
rules+ontologies
I think these edits can wait til after the Florida DAML etc.
meetings, however.
Also, I would recommend that the Abstract and Section 1 of the
overall OWL Rules draft should be revised a bit to reflect the
warning label and have "truth-in-advertising" -- perhaps
Ian and Peter would like to take a crack at that?
-- Benjamin
%%%%
As I promised during Tuesday's [9/30/03] telecon, here's the first
draft of a "warning label" intended as a new section in [1].
Additions, corrections, and other suggestions are welcome.
Mike
[1] http://www.cs.man.ac.uk/~horrocks/DAML/Rules/
%%%%
6. Usage Suggestions; Extensibility and Interoperability Cautions
There are known difficulties of the OWL Rules language for some users
/ purposes. In this section we discuss these and make usage
suggestions that address these difficulties: essentially, by avoiding
use of certain kinds of <i>complex class descriptions</i> directly
within rules.
6.1 Strictly-Horn Rules vs. Generalized Rules; Overall Expressiveness
The OWL Rules language can be viewed in terms of two fundamental
components of knowledge representation (KR) expressiveness: it
combines 1) a somewhat restricted form of *Horn rules* with 2) a form
of <i>Description Logic</i> (DL) ontology axioms cf. OWL. A simple
kind of such combination is for Horn rules to <i>refer</i> to class or
property predicates that are defined in a collection of DL ontology
axioms. "Refer" here means that a predicate (of a logical atom
appearing) in (the antecedent or consequent of) a Horn rule is
specified as the name (URI) of an OWL class or property. That is, a
simple kind of combination is to permit a Horn rule's atom to contain
a property or class <i>name</i>. We will call such a rule
<i>strictly-Horn</i>.
A more complicated kind of combination is for rules to be specified
directly as containing complex DL class expressions. In the OWL Rules
abstract syntax, a class-description can, in general, be a complex DL
class expression. Such a generalized form of rule is actually <i>not</i> a
Horn rule; it is significantly more expressive. In particular, these
generalized rules can express existential and negation information
that is not expressible (fully) equivalently within the Horn
expressive subclass of First Order Logic, nor within the declarative
Logic Programs knowledge representation. However, in general, the
combination of such generalized rules with OWL knowledge is not more
expressive than the combination of strictly-Horn rules with OWL
knowledge.
From the viewpoint of a user that employs the full expressiveness of OWL
and wants to add rules, permitting such generalized rules is thus
a convenience that does not increase the employed overall expressiveness
as compared to adding strictly-Horn rules. This is largely the
rationale for permitting such generalized rules in this version of
OWL Rules.
6.2 Interoperability, Extensibility, and Implementation Considerations
However, for some users / purposes, employing the full expressiveness
of OWL Rules may cause difficulties with interoperability,
extensibility, and/or implementation, especially in the near term:
<ol>
<li>
It is anticipated that many users of OWL Rules will desire to maximize
interoperability with existing (or future) OWL-based ontology systems
and applications. Currently many other OWL-based ontology systems do
not support rules -- neither strictly-Horn nor generalized. Adhering
to the strictly-Horn expressive restriction for OWL Rules rules has
the effect of pushing the specification of ontology knowledge into the
purely OWL portion of a knowledge base that combines OWL Rules
knowledge with OWL ontology knowledge. For such users, therefore,
restricting the rules to be strictly-Horn will increase the amount of
ontology knowledge purely in OWL that can be reused for, or reused
from, other OWL applications / knowledge bases. Also no currently
popular OWL implemented systems are yet using OWL-XML syntax.
<li>
It is also anticipated that many users of OWL Rules will desire to
maximize interoperability with existing (or future) rule systems of
currently commercially important (CCI) kinds. Such currently
commercially important rule systems include (at least) four families:
1) Prolog; 2) production rules (descended from OPS5); 3)
event-condition-action rules; and 4) SQL (where views, queries, and
facts are all rules). For users desiring such interoperability,
restricting the rules to be strictly-Horn will enable those rules to
be translated to, or translated from, those CCI rule systems and their
associated applications and knowledge bases.
<li>
It is additionally anticipated that many users of OWL Rules will
desire extensibility of rules expressiveness to include nonmonotonic
negation/priorities and/or procedural attachments. In particular,
many applications built using CCI rule systems exploit the expressive
features of negation-as-failure (NAF) and/or prioritized
defaults/conflict-handling, both of which are logically nonmonotonic;
and many such CCI rule applications use procedural attachments for
actions (in rule consequents) and/or tests (in rule antecedents). For
users desiring such extensibility, restricting the rules in OWL Rules
to be strictly-Horn will enable that extensibility, and will
facilitate combining OWL Rules rules knowledge with other CCI rules
knowledge.
<li>
Restricting the rules to be strictly-Horn will also simplify the job
of implementing an OWL Rules rules processor, in particular by
reducing the needed amount of syntactic processing and analysis of
expressiveness used by a ruleset.
</ol>
OWL Rules (in this version) does not itself support nonmonotonicity
nor procedural attachments. Moreover, it is not as yet known even at
the level of basic research how expressively to extend this rules
language <i>in its entirety</i> to support nonmonotonicity/NAF or
procedural attachments.
However, it is known how to extend an <i>expressive subset</i> of OWL
Rules to support nonmonotonicity/NAF and procedural attachments. This
extension is founded upon the declarative Logic Programs (LP)
knowledge representation (KR). RuleML [RuleML] is based (mainly) on
LP, and supports these extensions, e.g., in the Situated Courteous
Logic Programs (SCLP) sublanguage of RuleML V0.8. LP overlaps
expressively with DL and with OWL Rules. In particular, the
Description Logic Programs (DLP) KR [Grosof et al 2003] is not only an
expressive subset of LP, but it is also an expressive subset of DL,
and of Horn, and thus of OWL Rules. DLP is extensible
straightforwardly to enable nonmononotonicity/NAF and/or procedural
attachments, e.g., SCLP is a straightforward expressive extension of
DLP. By restricting any given usage of the expressiveness of OWL
Rules to that which is expressible in DLP, such extensibility will be
ensured.
The expressive limitations of DLP include prohibition of existentials
in a rule head, and correspondingly in a DL subsumption axiom's
superclass expression. Similarly, DLP includes the dual/equivalent
prohibition of universals in the rule body / DL-subclass. Note that
minimum-cardinality is a kind of existential, and maximum-cardinality
is a kind of universal. See [Grosof et al 2003] for details and
discussion. Note that the four CCI rule families, listed above,
fundamentally do not support existentials in a rule head. Tools for
translation of the DLP subset of OWL into RuleML are under
development, e.g., [Motik et al 2003].
6.3 Discussion of Usage Recommendations, with Examples
In light of the above, users who want to maximize interoperability
with a) existing rule engines and/or with b) OWL ontologies encoded in
RDF/XML (at least in the near term until OWL reasoners begin to
support OWL Rules directly) may want to limit their classAtoms to use
named classes defined in the same OWL XML file or external OWL XML or
RDF/XML documents, as this allows simpler translation of atoms into
other rule formats.
E.g., they may want to specify a rule containing the atom
<owlx:classAtom>
<owlx:Class owlx:name="#PhysicianChild"/>
<owlx:Variable owlx:name="x1"/>
</owlx:classAtom>
in combination with the OWL ontology axiom
<owlx:Class owlx:name="PhysicianChild">
<owlx:IntersectionOf>
<owlx:Class owlx:name="#Person"/>
<owlx:ObjectRestriction owlx:property="#hasParent"/>
<owlx:someValuesFrom owlx:class="#Physician"/>
</owlx:ObjectRestriction>
</owlx:IntersectionOf>
</owlx:Class>
rather than specifying the rule as containing the atom
<owlx:classAtom>
<owlx:Class owlx:name="PhysicianChild">
<owlx:IntersectionOf>
<owlx:Class owlx:name="#Person"/>
<owlx:ObjectRestriction owlx:property="#hasParent">
<owlx:someValuesFrom owlx:class="#Physician"/>
</owlx:ObjectRestriction>
</owlx:IntersectionOf>
</owlx:Class>
<owlx:Variable owlx:name="x1"/>
</owlx:classAtom>
Also in light of the discussion in the above subsections, users who
anticipate use of their rules with prioritized conflict resolution,
defaults, procedural attachments, or other advanced features of rule
engines, especially rule engines that are either precisely or roughly
based on Logic Programs, may want to limit their classAtoms to use
named classes in combination with OWL ontologies that are within the
expressiveness of Description Logic Programs [Grosof et al 2003].
This will ensure that such users avoid using expressive features of
OWL that are not expressible in LP. In particular, the use of
owl:someValuesFrom or owl:minCardinality in a rule consequent, or of
owl:allValuesFrom or owl:maxCardinality in a rule antecedent, are not
within the expressiveness of Description Logic Programs.
An example of an OWL class description whose use in a rule antecedent atom is
outside the expressiveness of Description Logic Programs is
<owlx:Class owlx:name="Orphan">
<owlx:IntersectionOf>
<owlx:Class rdf:name="#Person"/>
<owlx:ObjectRestriction owlx:property="#hasParent"/>
<owlx:allValuesFrom owlx:class="#Deceased"/>
</owlx:ObjectRestriction>
</owlx:IntersectionOf>
</owlx:Class>
because of the use of owl:allValuesFrom which is a universal. (A
universal in the antecedent corresponds to an existential in the
consequent -- both correspond to an existential at the outer scope of
the whole rule, which is not expressible in LP.) Use of such a class
within a rule antecedent's classAtom may cause difficulties for
extensibility and interoperablity with other rule systems, and perhaps
even in future versions of OWL Rules.
6.4 Fundamental Directions for Future
Development of theoretical foundations and algorithms to more fully
combine the results of Description Logic and Logic Programs is an
active area of research. OWL Rules is expected to grow as such
research comes to fruition.
In particular, development of tools to convert between OWL Rules and
RuleML V0.8 [RuleML] is an active area of research.
Additional References:
[Grosof et al 2003]
Description Logic Programs: Combining Logic
Programs with Description Logic. Benjamin Grosof,
Ian Horrocks, Raphael Volz, Stefan Decker. Proc.
WWW2003, Budapest, May 2003.
http://www2003.org/cdrom/papers/refereed/p117/p117-grosof.html;
also http://ebusiness.mit.edu/bgrosof/#DLP.
[Motik et al 2003]
Boris Motik, Raphael Volz, and Sean Bechhofer. DLP component
of KAON OWL support software package. FZI / University of Karlsruhe,
2003. http://kaon.semanticweb.org/owl ->
http://kaon.semanticweb.org/alphaworld/dlp.
[RuleML]
Rule Markup Language Initiative. http://www.ruleml.org
__________
Prof. Benjamin Grosof
Web Technologies for E-Commerce, Business Policies, E-Contracting, Rules,
XML, Agents, Semantic Web Services
MIT Sloan School of Management, Information Technology group
http://ebusiness.mit.edu/bgrosof or http://www.mit.edu/~bgrosof
This archive was generated by hypermail 2.1.4 : 10/14/03 EST