From: Benjamin Grosof ([email protected])
Date: 10/16/03
(This version is a "long" version of the warning label. It has a few minor tweaks compared to the last one posted) % 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 <i>Horn rules</i> 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] DLP component of KAON OWL support software package. Boris Motik, Raphael Volz, and Sean Bechhofer. 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/16/03 EST