revised draft of warning label section

From: Benjamin Grosof (
Date: 10/14/03

  • Next message: Benjamin Grosof: "some small edits for beginning of OWL Rules draft"
    % 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
    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.
    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
    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
     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:
    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.
    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.
    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
    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.
    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
    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:Class owlx:name="#PhysicianChild"/>
         <owlx:Variable owlx:name="x1"/>
    in combination with the OWL ontology axiom
       <owlx:Class owlx:name="PhysicianChild">
           <owlx:Class owlx:name="#Person"/>
           <owlx:ObjectRestriction owlx:property="#hasParent"/>
             <owlx:someValuesFrom owlx:class="#Physician"/>
    rather than specifying the rule as containing the atom
         <owlx:Class owlx:name="PhysicianChild">
             <owlx:Class owlx:name="#Person"/>
             <owlx:ObjectRestriction owlx:property="#hasParent">
               <owlx:someValuesFrom owlx:class="#Physician"/>
         <owlx:Variable owlx:name="x1"/>
    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:Class rdf:name="#Person"/>
           <owlx:ObjectRestriction owlx:property="#hasParent"/>
             <owlx:allValuesFrom owlx:class="#Deceased"/>
    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.
    [Motik et al 2003]
            Boris Motik, Raphael Volz, and Sean Bechhofer.  DLP component
            of KAON OWL support software package.  FZI / University of Karlsruhe,
            2003. ->
             Rule Markup Language Initiative.
    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 or

    This archive was generated by hypermail 2.1.4 : 10/14/03 EST