In this paper, we focus on the impact of ontology changes on rules, or more speci cally on business rules authored over ontologies. For this we develop the MDR framework (Model-Detect-Repair) based on the MDROntology and a set of rules. As rules depend on the ontology entities, ontology changes may make them inconsistent. The MDR framework analyses an ontology change to detect its impact (e.g. inconsistency) on rules and propose solutions, called repair, to repair the change impact. The MDROntology includes, among others, a change model, ontology changes classi cation and the impact of such changes on rules.
Integration of ontologies and rules is a research area of interest especially for the semantic web community. Ontologies changes also take the attention of many research works, which propose solutions to manage the changes of the ontologies while maintaining their consistency. In this paper we focus on the integration of OWL-DL ontologies and business rules and on the impact on ontology changes on rules authored over ontologies. Business Rules are a description of a business policy, encoded in a natural controlled language. They de ne or specify constraints of some aspect of the business4 and enable automating business decisions. An example of a business rule is given in the following :
IF the yearly income of the borrower is less than 20000 and the amount of the loan is more than 60000 THEN reject the loan request;
The purpose of integration ontologies and business rules is to bring the
expressiveness of OWL ontologies to business users by means of business rules
authored in a controlled natural language. In [
This prototype, called OWL plug-in for WODM, is based on the Business Rule Management System (BRMS) WebSphere Operational Decision Management (WODM). Due to this new dependency of business rules on ontologies, changes to this ontologies have an impact on them and may cause inconsistencies.
To cope with the problem of inconsistencies, caused by ontology changes, we develop5 a new approach, Model-Detect-Repair (MDR), which supports consistency maintenance of business rules when ontologies evolve. The general idea of MDR consists of modeling the ontology change, detecting the inconsistencies that could be caused by it and propose solutions, called repairs, to resolve the inconsistencies. 2
MDROntology The MDROntology, represents the di erent entities that are important to detect the impact of ontology changes on rules. It contains the concepts to model business ontology changes, business rule inconsistencies and inconsistency repairs. The MDROntology contains more than one hundred concepts, the most important are: { Entity: represents the entities of an ontology (i.e. concept, property, and individual); { ChangeObject: represents the OWL-DL construct on which the change operates. Six categories of OWL-DL constructs are represented based on the W3C guide 6:
ClassAxiomConstruct: rdfs:subClassOf, owl:equivalentClass, owl:disjointWith; ClassDescription: owl:oneOf, owl:intersectionOf, owl:unionOf, owl:complementOf ; PropertyRestriction:
Cardinality restriction: owl:maxCardinality, owl:minCardinality, owl:cardinality; Value restriction: owl:allValuesFrom, owl:hasValue, owl:someValuesFrom.
PropertyRelation: owl:equivalentProperty and owl:inverseOf PropertyCharacteristic:owl:FunctionalProperty,owl:InverseFuctionalProperty, owl:SymmetricProperty,owl:TransitiveProperty ;
RDFConstruct: rdfs:subPropertyOf, rdfs:subClassOf, rdfs:domain, rdfs:range. { Change: represents ontology changes that have impacts on the rules. We distinguish between three categories of change
OWLConstructChange: consists of changes that impact a construct. We de ne six categories of OWLConstructChangewhich are ClassAxiomConstructChange, ClassDescriptionChange, PropertyRestrictionChange, PropertyRelationChange, PropertyCharacteristicChange and RDFConstructChange. 5 This work is partially founded by the European Commission under the project ON
TORULE (IST-2009-231875). 6 http://www.w3.org/TR/owl-ref/
StructuralChange: consists of adding or removing entities;
RenameOntologyEntity.
{ Rule: represents the business rules authored by business users, which are
impacted by a change. They have a ConditionPart and an ActionPart and
they are authored over the ontology entities (represented by the concept
Entity);
{ Inconsistency: represents the inconsistencies that could impact rules due
to an ontology change and we focus on 4 types on inconsistency [
Within the MDROntology a change is de ned as follows (see Figure 1): { a change has a ChangeObject which is the OWL construct impacted by the change (i.e. owl:subclassOf, owl:allValuesFrom, owl:oneOf. . . ); { a change is applied to a Change entity that can be a concept or a property; { a change has a change type: fAdd, Remove, Modifyg; { a change has impact on Rule; { a change has impact an Inconsistency hat is repaired by a Repair.
Nevertheless, depending on the change to apply to the ontology, more
information should be provided to enable detecting its impact on rules. For example,
in case of an enumeration change, the new collection of the enumeration is
provided (see Figure 2), in case of a rename entity change, the new name of an
entity, in case of a range change, the new range of a property. . .
The MDR approach is inspired by ONTO-EVOAL [
The general idea of the MDR approach is: (1) to model the changes that the business user wants to apply to an ontology, (2) to detect which changes produce inconsistencies and (3) to provide solutions to repair them.
Figure 3 gives an overview of our approach. We distinguish two di erent layers : the Business Layer and the MDR layer. The Business layer consists of the business ontology which is subject to changes and the business rules authored over this ontology by the business user. These business rules are possibly impacted by the ontology changes. The MDR layer depicts the architecture of our system. It contains the MDROntology which models our problem domain (e.g.ontology change, rules inconsistencies and inconsistency repairs). Additionally, it contains two rule sets, the Inconsistency Detection Rules (IDR) and the Repair Rules (RR). These rules are authored over the MDROntology using the OWL plug-in for WODM.The IDR detects which inconsistencies in the business rules are caused by the change, while the RR proposes the appropriate repairs for any combination of a change and an inconsistency. These repairs can be either changes to the business rule set or to the business ontology. The MDR (d) Re(RpaRir) Rule repairedBy
Repair hasRuleName
String Ontology concept Ontology property Property value
Property range “Add” “Remove” “Modify”
changeType hasChangeObject
hasLocalName ChangeObject (a) The user model (manually)
String (c) Iconsistency Detection Rule
(IDR) Inconsistency
hasImpact (b) Rule filter (automatically) Rule hasImpactOn
Change hasChangeEntity
Entity process to detect the impact of an ontology change on rules is as follow (see Figure 4); (a) It starts by modeling the required business ontology changes . This is done by the business user, by creating individuals of the MDROntology. These change instances refer to entities in the business ontology that are subject to change. This change model serves as input for the consistency process. (b) The Rule Filter module is executed to detected rules that are impacted by a change. This module updates the change model by adding the impacted rules. (c) The updated model is used to trigger the IDRs, in order to detect the type of inconsistencies on the impacted business rules. This step updates the change model with the detected inconsistencies for each impacted business rule. (d) Finally, this new updated model is used to trigger the RRs in order to nd possible repairs for each inconsistency. 4
The MDR approach is implemented as a WODM plug-in called the Change Management plug-in. To illustrate our work, we present a business scenario that stages two agents representing business users who are involved in the process of consistency maintenance.
Marc is the business analyst. His mission is to formalize the business knowledge. He has to make sure that the business model is correct, complete and valid. Alice is the domain expert. She is in charge of authoring the business rules. She understands quite well their formalization and uses business rules tools to update, create and test them.
The business ontology we will use in this section is an extract of the use case used in the ONTORULE project 7. The use case, provided by Audi, models a scenario of a car development. One domain constraint that must be veri ed is
Method description : Section
VirtualMethod
MicroSlipTest if R1 then the description of the micro slip test is the section
set the strap is conform to the regulation ; that the SolutionConcepts are conform to Regulations. The MicroSlipTest is a Method that is used to test the quality of a seat belt. When a Method is based on a Section, the required SolutionConcept for the Process that uses this Method must be conform to a Regulation. For this, we authored the rule described in Figure 5 using the OWL plug-in for WODM. This rule expresses,
that the required Strap (which is a SolutionConcept) for the MicroSlipTest conforms to a Regulation.
Let us consider an ontology change that consists of removing the subclass relation between VirtualMethod and MicroSlipTest. In this case, the rule R1 will be invalid as it tests the property description of MicroSlipTest, an inherited property that will be lost after the change application.
The application of the MDR approach will be as described in the following :
Marc requests the change by modeling its structure. An instantiation of the change concept corresponding to the subclass change that he wants to apply is given in Figure 6. When Marc activates the Change Management plug-in, a list of the requested changes is shown. Then, when Alice selects the change(s) to apply, the rule lter is triggered to detect the impacted rules. The impacted rules are detected based on the change entity and the change object. For example, in our case the impacted rules are the one using the change entity with an inherited property.
Depending on the modeled change, the IDRs are executed. Each change has to satisfy constraint(s). For the subclass change, the constraint to verify is that, in the rule set, there is no rule using the change entity with a property of its super class. If this constraint is not satis ed an inconsistency of type Invalid Rule will be detected by the following rule.
IF change.objectChange = subclassConstruct && change.type = "Remove" && change.hasImpactOn(a_rule) && a_rule.hasRuleEntity(changeEntity) && changeEntity.hasRuleProperty(prop) && super_concept in changeEntity.superClass && super_concept.hasProperty(prop) THEN change.add_inconsistency(invalid_rule); 3. Inconsistency repair
Depending on the change to apply and the detected inconsistency one or more repair are proposed. For this example, the proposed repairs are : { an alternative ontology change; a proposition of additional ontology change that will enable to avoid the inconsistency; In this case, one of the proposed repairs is to add the missing property ( .e description) to the concept MicroSlipTest. This repair is proposed by the following RR.
IF invalid_rule in change.impact && change.changeObject = subclassConstruct then
addMissingProperty(); { common repairs, which consist of removing the rule or the rule part that causes this inconsistency. These repairs are proposed independently of the requested change and the detected inconsistency. 5
In this paper, we presented the MDR framework built on top of the MDROntology. This approach enables the impact of ontology changes on rules authored OWL ontologies. This approach analyses the impact of a change, detects the inconsistencies that could be caused by its application and proposes repairs to resolve these inconsistencies. Nevertheless, in the current state of the work, the IDRs detect only three types of inconsistencies which are the Invalid Rule, Domain Violation and Rule Never Apply caused by enumeration change or subclass changes.
The IDRs de nes the constraints that each change should verify. The development of this kind of rules is not an easy task as it is necessary to cover the changes that impact an ontology and to de ne manually the constraint that each change should verify. It would be rewarding to develop a module enabling to automatically generate these rules depending on the change to apply in a way to detect more inconsistencies that could impact business rules.
Another important point to improve is the change modeling step. It would be interesting to develop a module that detects automatically an ontology change and models its structure, which will avoid the change modeling step.