From: Benjamin Grosof (bgrosof@mit.edu)
Date: 05/20/02
Towards DAML-Rules: How to Combine Rules with Description Logic Ontologies cf. DAML+OIL Benjamin Grosof MIT Sloan School of Management bgrosof@mit.edu http://ebusiness.mit.edu/bgrosof Version 1 5/20/2002 1. Introduction (also serves as Abstract) In this short working paper, we give an overview of how to combine Declarative Logic Program rules (LP) cf. RuleML rules with Description Logic (DL) ontologies cf. DAML+OIL (http://www.daml.org). We mainly consider rules that are Declarative Logic Programs (LP) cf. RuleML (http://www.dfki.de/ruleml and http://ebusiness.mit.edu/bgrosof); however, the discussion also applies to classical-logic rules (Horn or expressive superset). There are actually several different fundamental ways to combine rules with DL/DAML+OIL ontologies. The first is to build rules on top of ontologies. The second is to specify an ontology for rule syntax. The third is to use LP rules to specify restricted DL-form ontology knowledge. The fourth is, conversely, to use DL ontology to specify restricted LP-form rule knowledge. The third and fourth rely upon the fact that DL and LP have a substantial expressive overlap. Note that, alternatively, one could perform these same combinations, of rules with DL/DAML+OIL, if instead a classical-logic language is employed to specify rules in lieu of LP/RuleML, e.g., if one employs an expressive subset of First-Order-Logic/KIF/CommonLogic that includes Horn rules. This overview provides a basis, in both theory and applications, for designing DAML-Rules, i.e., a rule KR (syntax and semantics) for DAML (http://www.daml.org). Any subset of these four combinations can be used. We propose that DAML-Rules be constructed and explored with an emphasis roughly in the sequence we gave for the combinations: first, enable rules to be on top of ontologies, and develop application scenarios; then, specify a DAML+OIL ontology for rules syntax and provide tools for specifying rules in that syntax; finally, explore theory and examples of using the expressive overlap of LP and DL. The reason for this sequencing is primarily pragmatic. Existing implemented rule systems are most easily modified initially by simply adding the capability for predicates to be URI's, to couple them loosely to DAML+OIL inference engines and knowledge bases. Then a precise specification can be developed for a DAML+OIL ontology of rules and parsing/translation tools developed to talk to existing implemented rule systems and DAML+OIL. More theory is needed about using the expressive overlap of LP and DL. Importantly, applications prospects and industry legacy both demand especially the combination of rules on top of ontologies. A longer version of this paper will contain formal knowledge representation semantics (and associated theory) for these combinations. 2. Combination #1: "Rules On Top of Ontologies" The first way to combine rules with ontologies is to "build rules on top of ontologies", i.e., to specify rules, e.g., in RuleML, using one or more domain ontologies specified in Description Logic (DL), e.g., in DAML+OIL. This is one kind of "KR-fusion" between LP and DL. 2.1 Approach In this approach, a class from the DL ontology is treated as a unary predicate that may appear in the rules. Likewise, a property from the DL ontology is treated as a binary predicate that may appear in the rules. Assertions about instances in a class are treated as rule atoms (e.g., facts) in which the class predicate appears. Assertions about property links between class instances are treated as rule atoms in which the property predicate appears. A first version of this approach has been done, in which RuleML rulesets are (each) built on top of (one or more) DAML+OIL ontologies. This is described in the submitted working paper "Representing Agent Contracts with Exceptions using XML Rules, Ontologies, and Process Descriptions" by B. Grosof and T. Poon, available at http://ebusiness.mit.edu/bgrosof. RuleML permits a predicate symbol (or a logical function symbol) to be a URI; we make heavy use of this capability since the names of DAML+OIL classes are URI's. (To our knowledge, ours is the first published description and example of such integration of DAML+OIL into RuleML.) The approach has been implemented, and the prototype (part of SweetDeal) will soon be publicly available. This approach is used for an application interesting in itself: to represent rule-based e-contracts in which some provisions specify how to handle exceptions (problematic conditions that may arise). Two ontologies about business processes are used. The first (sp.daml) is a new DAML+OIL representation of a fragment of the MIT Process Handbook, a previously-existing large taxonomic ontology of business processes that has been used for a number of serious industry design efforts in business process automation. The second ontology (sd.daml) is an entirely new DAML+OIL ontology about contracts and exceptions and exception handlers, which complements the first ontology. ("sp" stands for "SweetProcess", and "sd" for "SweetDeal".) 2.2 Examples Next we give an excerpt from that paper (p. 12 there) containing an example. For concise human-readability, the rules are written in a Prolog-like text-file syntax which straightforwardly translates to RuleML. "//" prefixes a comment line, "<...>" encloses a label/name for a rule, "{...}" encloses a subset/module of rules, ";" indicates the end of a rule. URI's, for DAML+OIL classes or properties, are used as predicates. "Merely detecting late delivery is not enough; the buyer also wants to get a penalty (partial refund) if late delivery occurs. Continuing our example, we next give a rules module to specify a penalty of $200 per day late, via an exception handler process lateDeliveryPenalty. Again, this handler is itself rule-based. lateDeliveryPenalty_module { // lateDeliveryPenalty is an instance of PenalizeForContingency // (and thus of AvoidException, ExceptionHandler, and Process) http://xmlcontracting.org/sp.daml#PenalizeForContingency(lateDeliveryPenalty) ; // Any late delivery exception ?EI can be (potentially) handled by // lateDeliveryPenalty, which might (i.e., is intended to) avoid it. <penaltyHandlesIt_def(?EI)> http://xmlcontracting.org/sp.daml#isHandledBy(?EI,lateDeliveryPenalty) <- http://xmlcontracting.org/sd.daml#LateDelivery(?EI) ; http://xmlcontracting.org/sd.daml#avoids(lateDeliveryPenalty, ?EI) <- http://xmlcontracting.org/sd.daml#LateDelivery(?EI) ; // penalty = - overdueDays * 200 ; (negative payment by buyer) <lateDeliveryPenalty_def> payment(?R, contingentPenalty, ?Penalty) <- http://xmlcontracting.org/sd.daml#result(co123,?R) AND http://xmlcontracting.org/sd.daml#exceptionOccurred(?R,?EI) AND http://xmlcontracting.org/sp.daml#isHandledBy(?EI,lateDeliveryPenalty) AND shippingDate(co123,?CODate) AND shippingDate(?R,?RDate) AND Subtract(?RDate,?CODate,?OverdueDays) AND Multiply(?OverdueDays, 200, ?Res1) AND Multiply(?Res1, -1, ?Penalty) ; }" 3. Combination #2: "Ontology of Rule Syntax" The second way to combine rules with ontologies is to specify an "ontology of rule syntax", i.e., to use Description Logic, e.g., DAML+OIL, to specify a "meta-ontology" for rules, e.g., for RuleML. 3.1 Approach In this approach, an ontology is given for the rule language itself. E.g., "Rule", "Head", "Body", "Atom", "Predicate", and "Ruleset" are each a DL class. The ontology is thus essentially a specification of the syntax of the rule language. We can thus say it is an ontology for the rule KR's syntax, or that is a *syntactic ontology* for the rule KR. A first version of this approach has been done, in which DAML+OIL is used to give a syntactic ontology for the RuleML. This is described in the submitted working paper "SweetJess: Translating DamlRuleML To Jess" by B. Grosof, M. Gandhe, and T. Finin, available at http://ebusiness.mit.edu/bgrosof, and the full ontology is at http://gentoo.cs.umbc.edu/~mgandh1/#Ontology. (Warning: the full ontology is an early version which is somewhat rough and buggy.) Implementation of a translator to various rule systems including Jess is in progress. 3.2 Examples Next, we give a reformatted excerpt from that paper (p. 5 there) containing examples of DAML+OIL class specifications for elements of RuleML syntax. "*********** DAML+OIL Class for an Individual in RuleML ***************** <daml:Class rdf:ID="Ind"> <rdfs:label>Ind</rdfs:label> <rdfs:comment>Ind stands for Individual. It is a 0-ary logical function symbol. </rdfs:comment> </daml:Class> *********** DAML+OIL Class for an Implication (i.e. rule) in RuleML *********** <daml:Class rdf:ID="Imp"> <rdfs:label>Imp </rdfs:label> <rdfs:comment>Imp stands for Implication rule, i.e., an if-then rule. </rdfs:comment> <rdfs:subClassOf> <daml:Restriction daml:minCardinality="0"> <daml:onProperty rdf:resource="#_rlab"/> <rdfs:comment>_rlab stands for rule label</rdfs:comment> </daml:Restriction > </rdfs:subClassOf> <rdfs:subClassOf> <daml:Restriction daml:Cardinality="1"> <daml:onProperty rdf:resource="#_head"/> </daml:Restriction > </rdfs:subClassOf> <rdfs:subClassOf> <daml:Restriction daml:Cardinality="1"> <daml:onProperty rdf:resource="#_body"/> </daml:Restriction > </rdfs:subClassOf> </daml:Class>" Next, we give another reformatted excerpt from that paper (p. 6 there), containing an example rule encoded in the DAML+OIL syntax. ' "The discount for a customer buying a product is 5 percent if the customer is premium and the product is regular.' ************* DamlRuleML Representation *********** <damlRuleML:imp> <damlRuleML:_rlab> <damlRuleML:ind>discountRule</damlRuleML:ind> </damlRuleML:_rlab> <damlRuleML:_body> <damlRuleML:andb> <damlRuleML:atom> <damlRuleML:_opr> <damlRuleML:rel>Premium<damlRuleML:rel> </damlRuleML:_opr> <damlRuleML:var>Customer</damlRuleML:var> </damlRuleML:atom> <damlRuleML:atom> <damlRuleML:_opr> <damlRuleML:rel>Regular<damlRuleML:rel> </damlRuleML:_opr> <damlRuleML:var>Product</damlRuleML:var> </damlRuleML:atom> <damlRuleML:atom> <damlRuleML:_opr> <damlRuleML:rel>Buys<damlRuleML:rel> </damlRuleML:_opr> <damlRuleML:var>Customer</damlRuleML:var> <damlRuleML:var>Product</damlRuleML:var> </damlRuleML:atom> </damlRuleML:andb> </damlRuleML:_body> <damlRuleML:_head> <damlRuleML:atom> <damlRuleML:cterm> <damlRuleML:_opc> <damlRuleML:ctor>GiveDiscount<damlRuleML:ctor> </damlRuleML:_opc> <damlRuleML:var>Customer</damlRuleML:var> <damlRuleML:var>Product</damlRuleML:var> <damlRuleML:ind>percent5</damlRuleML:ind> </damlRuleML:cterm> </damlRuleML:atom> </damlRuleML:_head> </damlRuleML:imp> ' 4. Combination #3: "Ontology Via Rules" The third way to combine rules with ontologies is to specify "ontology via rules", i.e., to use LP rules to specify restricted DL-form ontology knowledge. This is another kind of "KR-fusion" between LP and DL. 4.1 Approach This approach relies upon the fact that DL and LP have a substantial expressive overlap. This overlap is described in a short working paper "Combining Rules with Ontologies for the Semantic Web: A Proposal for DAML-Rules, Combining DAML+OIL with RuleML" by B. Grosof and I. Horrocks, Aug. 2001. (This was first distributed to the DAML-EU Joint Committee.) Next, we give an excerpt (pp. 1-2 there) from that working paper, which summarizes the theoretical basis for this approach. ' "KR-fusion": this is to fuse the two logical KR's -- DL and LP -- so that information from each can be used in the other. The KR-fusion technique enables one to "build rules on top of ontologies" in a powerful fashion: it enables the rule KR to have access to the DL ontological definitions for the vocabulary primitives (e.g., predicate, individual, and function constants) used by the rules. Conversely, the KR-fusion technique likewise enables one to "build ontologies on top of rules" powerfully: it enables ontological definitions to be supplemented by rules, or imported into DL from rules. The KR-fusion technique is thus potentially quite useful and powerful, but it is also challenging to develop fully. As an initial step, we give a partial theory (with deep declarative KR semantics) for translation and integration of DL to and fro LP. More specifically, we focus on logically-monotonic LP (mon-LP), beginning with Horn LP, which is close (but not identical) to the Horn-clauses subclass of first-order-logic (Horn-FOL). Part of our theory includes defining the expressive intersection of DL and mon-LP / Horn-FOL. (Neither DL nor mon-LP/Horn-FOL expressively subsumes the other.) Our theory enables one to view axioms (e.g., premises) either as DL or mon-LP/Horn-FOL, and to translate them back and forth. Interestingly, the axioms might also be conclusions (e.g., ground facts) drawn from more expressively-general DL or LP/Horn-FOL beyond the intersection. The KR-fusion technique enables one to have a choice of either DL inferencing tools or mon-LP/Horn-FOL inferencing tools, for information in the expressive intersection. The KR-fusion technique also lays the groundwork for a possible new integral yet hybrid KR that combines some DL expressiveness with some mon-LP/Horn-FOL expressiveness and goes beyond the expressive intersection. Of course, general FOL is a candidate for such a hybrid KR; however, general FOL is often impractical due to its computational complexity/semi-decidability. To be truly valuable, a new such hybrid KR would have usefully increased expressiveness along with efficient algorithms for important tasks. But finding that new KR remains for further exploration. ' 4.2 Examples Next, we give an excerpt (pp. 3-4 there) from that working paper, which gives generic examples of expressing ontology via rules, and vice versa. For conciseness, these are expressed in abstract DL and LP syntax, which map straightforwardly to DAML+OIL and RuleML respectively. ' Here are some of the simpler parts of the mapping between DL and mon-LP for their expressive intersection. Preamble: DL class: is represented in mon-LP as a predicate with arity 1. DL property: is represented in mon-LP as a predicate with arity 2. "?" prefix indicates a logical variable, in mon-LP syntax below. Mapping examples: class C is SUBCLASS of class D: D(?X) <- C(?X). DOMAIN of property P is class C: C(?X) <- P(?X,?Y). RANGE of property P is class D: D(?Y) <- P(?X,?Y). Q is a SUB-PROPERTY of P: P(?X,?Y) <- Q(?X,?Y). property P is TRANSITIVE: P(?X,?Z) <- P(?X,?Y) and P(?Y,?Z). property P is SYMMETRIC: P(?Y,?X) <- P(?X,?Y). ' a is an instance of class C (where a is ground): C(a). (a,b) is an instance of property P (where a,b are ground): P(a,b). ' 4.3 Limitations An example of something simple to specify in DL but not possible to represent fully in LP (or Horn) is an existential, e.g., to specify that the minimum cardinality of a class is 1. 5. Combination #4: "Rules Via Ontology" The fourth way to combine rules with ontologies is "rules via ontology", i.e., to use DL ontology to specify restricted LP-form rule knowledge. This is the converse of the third way. Like the third way of combination, this relies upon the fact that DL and LP have a substantial expressive overlap, discussed in the last section. This is yet another kind of "KR-fusion" of LP and DL. 5.1 Limitations An example of something simple to specify in mon-LP but awkward to represent in DL is a rule whose predicates have arity of three or more, whose arguments are a mix of variables and individual constants, and which has several body atoms. An example of something simple to specify in more general LP but not possible to represent fully in DL is prioritized override among rules, e.g., to represent default inheritance. Another such example is the procedural attachment to associate an action method with the predicate appearing in the head of a rule. 6. Which Combinations to Pursue See the second, third, and fourth paragraphs of section 1. Acknowledgements Thanks to Harold Boley, Said Tabet, Ian Horrocks, Stefan Decker, Peter Patel-Schneider, Michael Dean, Patrick Hayes, Jim Hendler, Richard Fikes, Tim Berners-Lee, and Deborah McGuinness for helpful discussions. Prof. Benjamin Grosof, MIT Sloan Sch. of Mgmt. (http://mitsloan.mit.edu) Contracts and Policies for E-Commerce, XML Rules and Agent Communication, Web Services bgrosof@mit.edu http://ebusiness.mit.edu/bgrosof/
This archive was generated by hypermail 2.1.4 : 05/20/02 EDT