Abstract:
A method is provided for integrating model and domain semantics in business models. The method includes a business model inputting step for inputting the business model to be realized; a domain semantics locating step for locating the domain semantics of the modeling element of the business model within the domain ontology and outputting the corresponding domain model semantics; a model semantics transforming step for transforming the modeling element of the business model into business model semantics that are represented by a model ontology; and a unified semantic model forming step for combining the aforesaid business model semantics and domain model semantics and then outputting a unified semantic model. The teachings disclosed are directed to facilitate the integration and utilization of the semantics embedded in business models.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application claims priority under 35 U.S.C. § 119 to Chinese Application No. 200510109557.X filed Oct. 25, 2005, the entire text of which is specifically incorporated by reference herein.  
       BACKGROUND OF THE INVENTION  
       [0002]     With the widely adoption of model-driven approach in today&#39;s enterprises, business is being modeled as large amount of models residing in multi-layers (like strategy, operation, execution, implementation and etc.). But the semantics (meaning) within these models are still not well integrated and thus makes these models hard to understand, communicate, reuse and utilize.  
         [0003]     Business semantics in models can be roughly divided into two categories:  
         [0004]     1. Model-level semantics (hereinafter referred to as model semantics)  
         [0005]     This level of semantics is usually embedded in the model meta-structure. Using business process model as a sample, each modeling element (e.g., activity, data object, control and etc.) and the relationship among multiple modeling elements (e.g., one activity will send/receive a data object) stands for a specific and clear meaning.  
         [0006]     2. Domain-level semantics (hereinafter referred to as domain semantics)  
         [0007]     This level of semantics is usually represented as domain knowledge and referenced in the word/phrases used by the business models. Each word used in the title, caption, or comment for the modeling elements/relationship stands for some specific and exact meaning in the domain semantics.  
         [0008]     Currently, we have the following challenges in well manipulating and leveraging business semantics.  
         [0009]     Firstly, different business modeling methods have different meta-model as a specification of the model semantics, and only these models that share the same meta-model can share a common base of semantics.  
         [0010]     Secondly, there is no well-established standard to regulate and interpret the meaning embedded in the words and phrases within business models.  
         [0011]     And more importantly, the model semantics and domain semantics, albeit important to business, are usually isolated when are actually divided into two isolated parts.  
         [0012]     Some existing methods and approaches have been proposed and applied by different companies and organizations, implicitly or explicitly, to address the problem as identified above.  
         [0013]     Unified Modeling Language (UML) is designed by OMG (Object Management Group) to specify, visualize and document models for software systems. With an objective to be a common modeling language for different kind of software elements, UML can be regarded as an effort to unify the model semantics. Meta Object Framework (MOF) is the specification in UML to support meta-model specification. All the models that conform to the same meta-model will share a common base of model-level semantics and thus be inter-operable. Yet the problem for UML lies in 1) it is still very hard to enforce all the modeling method to use a common language (like MOF) as its meta-model description language; 2) two models following different meta-model (even both are MOF based) still cannot share model-level semantics completely, it is still hard to establish relationship among these models.  
         [0014]     Ontology is regarded by many as the best way to address the problem related to domain semantics. RDF(S) and DAML/OWL are defined by standard organizations to formally represent the concept and their relationships within a specific domain (such as Banking and Telecom). The major challenge, however, lies in the difficulty to have a common ontology acceptable to all related parties.  
         [0015]     Both approaches described above, actually, don&#39;t take enough consideration for the business semantics isolation problem. That is, with today&#39;s approaches, models are either looked as a set of meta-structure without domain content (which needs to be understood by human being), or just a concept/relationship hierarchy without connection with the environment to which it applied. Yet when we need to have further understanding and utilizing of the models, through computer aided mechanisms, both levels of semantics are not just important, but actually indispensable. This problem has become a major obstacle for the further application of model-driven approach in well attacking business problems.  
         [0016]     As a summary, today&#39;s problems in utilizing business semantics can be summarized as:  
         [0017]     1. The model semantics and domain semantics are usually isolated in real business practices, making their integrated computation impossible.  
         [0018]     2. The domain semantics within business models are ambiguous and there lacks a mechanism to share domain semantics among business models that follow different meta models.  
       BRIEF SUMMARY OF THE INVENTION  
       [0019]     An aspect of the present invention provides a method and apparatus to integrate model and domain semantics in business models, which can overcome the aforementioned drawbacks of the prior art. To this end, an exemplary method for integrating model and domain semantics in business models is provided. The method includes a business model inputting step for inputting the business model to be realized; a domain semantic locating step for locating the domain semantics of the modeling element of the business model within the domain ontology and output the corresponding domain model semantics; a model semantics transforming step for transforming the modeling element of the business model into business model semantics that are represented by model ontology; and a unified semantic model forming step for combining the aforesaid business model semantics and domain model semantics and then outputting the formed unified semantic model.  
         [0020]     Another exemplary aspect of the invention is an apparatus for integrating model-level and domain-level semantics in business models. The apparatus includes a domain semantics locator configured to locate the domain semantics of the modeling element of the input business model within the domain ontology and output the corresponding domain model semantics; a model semantics transformer configured to transform the input modeling element of the business model into business model semantics that is represented by model ontology; and a unified semantic model builder configured to combine the aforesaid business model semantics and domain model semantics and then output the formed unified semantic model.  
         [0021]     One point addressed is how to associate and combine the two kinds of semantics (domain-level and model-level) embedded in business models, given the fact that they may be created by different people following different meta-model and domain notations. Furthermore, a unique approach of using USM as a common base for both the model and domain semantics embedded in models is presented. In contrast to the common usage of ontology to represent concepts within a particular domain, the invention creatively uses it to represent the model semantics for a particular modeling method. The Unified Semantic Model (USM) uses concept and relationship as fundamental modeling elements and is organized in the form of Ontology. During the integration of model semantics and domain semantics, business models will be transformed into the representation of USM, then domain semantics within business models will be specified and located to the corresponding concepts/relationships in domain ontology, by annotating the words/phases that are used in the caption or comments of modeling elements. After that, the semantics within business models, no matter as model or domain, will be transformed into a unified semantic model, which can then be used to support further work like analysis, inference and so on.  
         [0022]     To guarantee the quality of the generated USM, an inference engine will be used to validate the USM based on some constraints embedded in the domain and model ontology, and user-provided rules or policies.  
         [0023]     The steps of the method provided by the invention herein can be automated by algorithms in software or assisted by tooling with graphical user interfaces.  
         [0024]     The following advantages may be achieved:  
         [0025]     Firstly, both domain and model semantics are captured and utilized, making full usage of existing models will create more meaningful business result and value.  
         [0026]     Secondly, all the models in known modeling method and format are supported, without the need to enforce any strong preconditions for the modelers.  
         [0027]     Finally, the integration of business semantics into Unified Semantic Model makes it possible to have multiple further usages, the business value is tremendous. 
     
    
     BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS  
       [0028]     These and other features, aspects and advantages of the present invention will more fully understood when considered with respect to the following detailed description, the contents of the accompanying drawings where:  
         [0029]      FIG. 1  illustrates a schematic block diagram showing the specification and localization, according to the present invention, of the model and domain semantics of business models into model ontology and domain ontology;  
         [0030]      FIG. 2  illustrates a schematic block diagram showing the apparatus&#39; system architecture according to the present invention for integrating model and domain semantics in business models;  
         [0031]      FIG. 3  illustrates a flowchart of the method according to the present invention for integrating model and domain semantics in business models;  
         [0032]      FIG. 4  illustrates the metamodel for business process in UML;  
         [0033]      FIG. 5  illustrates a sample domain ontology for banking;  
         [0034]      FIG. 6  illustrates a sample credit loan business process;  
         [0035]      FIG. 7  illustrates the normalization of the credit loan business process as shown in  FIG. 6 .  
         [0036]      FIG. 8  illustrates the specific process flow of the model semantics transformation and domain semantics localization of business model. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0037]      FIG. 1  schematically illustrates the specification and the localization of the model semantics and the domain semantics to model ontology and domain ontology, respectively, according to the method of the present invention for integrating model semantics and domain semantics in business model. More particularly, the model ontology captures model semantics and the domain ontology captures domain semantics, respectively. And then, by linking the modeling element of the business model to model ontology, and annotating words and phrases within modeling elements, such as caption or comments, as concepts/relationships in domain ontology, the semantics of a business model can be explicitly specified. The common ontology representation guarantees that both model-level and domain-level semantics can be transformed into Unified Semantic Model.  
         [0038]      FIG. 2  shows the system architecture of the apparatus  20  according to the present invention for integrating model semantics and domain semantics in business model. The apparatus  20  has three major inputs: business models, i.e., Business Strategy/Operation and Solution Composition/Implementation level models; Meta models for business models, usually in terms of UML models; User-defined rules to describe constraints on the unified semantic model.  
         [0039]     In addition, the output of the apparatus is Unified Semantic Model that has been verified by constraints embedded in model/domain ontology, and rules/policies provided by users.  
         [0040]     The apparatus  20  shown in  FIG. 2  comprises the following components: a domain semantics locator  21  used to locate domain concepts/relationships within model descriptions; a model semantics transformer  22  used to transform business models into ontology representation; unified semantic model builder  23  used to form unified semantic model from the business models processed by the domain semantics locator  21  and model semantics transformer  22 . The apparatus  20  may optionally further comprises an inference engine  24 , which may be either a general purpose rule engine or an enhanced description logic engine, and can infer new facts based on existing knowledge and deduce some conclusions from these facts. The apparatus  20  may further comprises a semantic model validator  25  used to validate unified semantic model based on user-defined rules and constraints embedded in domain/model ontology. The apparatus  20  also comprises an ontology repository  26  having domain ontology  261  and model ontology  262  that are used to store domain ontology and model ontology respectively.  
         [0041]     Furthermore, the apparatus  20  may optionally comprises model normalizer  27  and model ontology generator  28  to support the processing procedure of the apparatus  20 . The said model normalizer  27  can check and normalize vocabularies used in captions or comments within business model elements, based on vocabularies in domain ontology  261 , and then the normalized business model is input into the said domain semantics locator  21  and model semantics transformer  22  for appropriate process. The model ontology generator  28  can generate model ontology representation based on metamodels in UML or XSD.  
         [0042]      FIG. 3  illustrates a flowchart of the method according to the present invention for integrating model and domain semantics in business models.  
         [0043]     A simple and complete example to realize the method of the present invention using the apparatus  20  thereof will be described below.  
         [0044]     The apparatus  20  of the present invention may choose to generate model ontology  262  by the model ontology generator  28  based on metamodel prior the step S 31  in  FIG. 3 . Let us use business process modeling as an example.  FIG. 4  is a metamodel for business process in UML, which shows all the major modeling elements when modeling business processes, such as Activity, IA and DataLane etc.  
         [0045]     Then the model ontology generator  28  generate model ontology  262  based on the metamodel for business process. A specific example of the model ontology  262  generated based on the metamodel in UML of  FIG. 4  will be described below:  
                                     ...         //define the classes within model ontology         &lt;owl:Ontology       rdf:about=“http://semantics.crl.ibm.com/process”/&gt;         &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/process#Activity”/&gt;         //corresponding to the &lt;Activity&gt; in  FIG. 4           &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/process#ActivityLane”&gt;       //corresponding to the &lt; ActivityLane &gt; in  FIG. 4           &lt;owl:Class       rdf:about=“http://semantics.crl.ibm.com/process#BusinessProcess”/&gt;       //corresponding to the &lt; BusinessProcess &gt; in  FIG. 4           &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/process#Choice”/&gt;         //corresponding to the &lt; Choice &gt; in  FIG. 4           &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/process#ControlFlow       ”/&gt;         //corresponding to the &lt; ControlFlow &gt; in  FIG. 4           &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/process#IA”/&gt;         //corresponding to the &lt; IA &gt; in  FIG. 4           &lt;owl:Class       rdf:about=“http://semantics.crl.ibm.com/process#InformationFlow”/&gt;         //corresponding to the &lt; InformationFlow &gt; in  FIG. 4           ...//It should be noted that not all the classes within the       model ontology are shown here.         //define relationship hasActivity         &lt;owl:ObjectProperty       rdf:about=“http://semantics.crl.ibm.com/process#hasActivity”&gt;         //the name of the relationship is hasActivity         &lt;rdfs:domain         rdf:about=“http://semantics.crl.ibm.com/process#ActivityLane”/       &gt;         //the head of the relationship is ActivityLane         &lt;rdfs:range         rdf:about=“http://semantics.crl.ibm.com/process#Activity”/&gt;         //the foot of the relationship is Activity         &lt;/owl:ObjectProperty&gt;         //define the relationship hasActivityLane         &lt;owl:ObjectProperty       rdf:about=“http://semantics.crl.ibm.com/process#hasActivityLane”&gt;         //the name of the relationship is hasActivityLane         &lt;rdfs:domain       rdf:about=“http://semantics.crl.ibm.com/process#BusinessProcess”/&gt;         //the head of the relationship is BusinessProcess         &lt;rdfs:range       rdf:about=“http://semantics.crl.ibm.com/process#ActivityLane”/&gt;         //the foot of the relationship is ActivityLane         &lt;/owl:ObjectProperty&gt;         ...                  
 
         [0046]     The generated model ontology  262  will be stored in the Ontology Repository  26 .  
         [0047]     The apparatus  20  of the present invention also prepares domain ontology  261  prior step S 31 . The domain ontology  261  captures domain semantics that are used in business models. It comes from industry standards or domain experts, and can be reused.  FIG. 5  is a sample domain ontology for banking.  
         [0048]     The following example shows a domain ontology for banking.  
                                     ...         //define domain ontology banking         &lt;owl:Ontology         rdf:about=“http://semantics.crl.ibm.com/banking”/&gt;         //define class Operation, corresponding to the &lt;Operation&gt;       in  FIG. 5           &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/banking#Operation”/       &gt;         //define class Transaction, corresponding to the       &lt;Transaction &gt; in  FIG. 5           &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/banking#Transaction       ”&gt;         &lt;rdfs:subClassOf       rdf:about=“http://semantics.crl.ibm.com/banking#Operation”/&gt;         Indicating to be sub-class of &lt;operation&gt;         &lt;/owl:Class&gt;         //define class Non Transaction, corresponding to the &lt;Non       Transaction&gt;in  FIG. 5           &lt;owl:Class       rdf:about=“http://semantics.crl.ibm.com/banking#NonTransaction”&gt;         &lt;rdfs:subClassOf       rdf:about=“http://semantics.crl.ibm.com/banking#Operation”/&gt;         Indicating to be sub-class of &lt;operation&gt;         &lt;owl:disjointWith       rdf:about=“http://semantics.crl.ibm.com/banking#Transaction”/&gt;         Indicating there is no connection with Transaction         &lt;/owl:Class&gt;         //define instance Inward, corresponding to the &lt;Inward&gt;in                 &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/banking#Inward”&gt;         &lt;rdfs:type         rdf:about=“http://semantics.crl.ibm.com/banking#Transaction       ”/&gt;         //indicating it belongs to class Transaction         &lt;owl:sameAs         rdf:about=“http://semantics.crl.ibm.com/banking#Loan”/&gt;         //indicating it is the same as Loan         &lt;/owl:Class&gt;         //define instance Outward, corresponding to &lt;Outward&gt;in                 &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/banking#Outward”&gt;         &lt;rdfs:type         rdf:about=“http://semantics.crl.ibm.com/banking#Transaction       ”/&gt;         //indicating it belongs to class Transaction         &lt;owl:differentFrom       rdf:about=“http://semantics.crl.ibm.com/banking#Inward”/&gt;         //indicating it is different from Inward         &lt;owl:sameAs         rdf:about=“http://semantics.crl.ibm.com/banking#Debit”/&gt;         //indicating it is the same as Debit         &lt;/owl:Class&gt;         //define Instance Inquiry, corresponding to &lt;Inquiry&gt; in                 &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/banking#Inquiry”&gt;         &lt;rdfs:type       rdf:about=“http://semantics.crl.ibm.com/banking#NonTransaction”/&gt;         //indicating it belongs to class Non Transaction         &lt;/owl:Class&gt;         //define instance Settlement, corresponding to       &lt;Settlement&gt;in  FIG. 5           &lt;owl:Class         rdf:about=“http://semantics.crl.ibm.com/banking#Settlement”       &gt;         &lt;rdfs:type       rdf:about=“http://semantics.crl.ibm.com/banking#NonTransaction”/&gt;         //indicating it belongs to class Non Transaction         &lt;/owl:Class&gt;         ...                  
 
         [0049]     The apparatus  20  of the present invention may optionally normalize the business model to be processed prior step S 31 .  FIG. 6  is an example of credit loan business process, wherein doing “query” activity first, and then doing “loan”, “debit” and “clearance” activities in parallel. The semantics of the process, although looks quite clear for human, is not so for machine because the semantics within the flow structure and the semantics for the specific usage domain (here Banking industry) are not so well integrated.  
         [0050]     Based on text analysis technologies, vocabularies used in the business process will be analyzed and normalized based on vocabularies in domain ontology. Referring to  FIG. 7 , model normalizer  27  will generate, according to the existing normalization technologies and based on the domain ontology as shown in  FIG. 5 , a normalized business process, wherein ‘query’ has been normalized as ‘inquiry’, and ‘clearance’ has been normalized as ‘settlement’.  
         [0051]     Referring back to  FIG. 3 , the business model to be processed is input in step S 31  (may be processed with normalization).  
         [0052]     In step S 32 , normalized business model will be transformed into business model semantics represented by model ontology by model semantics transformer  22 . The domain semantics locator  21  will traverse the generated business model semantics, and then look up and locate the domain concepts or relationships occurs in business model semantics within domain ontology  261 . The domain semantics locator  21  and model semantics transformer  22  will take domain ontology, model ontology and normalized business model as inputs. The domain semantics locator  21  will locate words/phrases within captions/comments in the modeling elements of the business model to corresponding concepts/relationships in domain ontology  261 . And the model semantics transformer  22  will transform business models into business model semantics. The specific process flow of step S 32  is as shown in  FIG. 8 .  
         [0053]     In  FIG. 8 , the model semantics transformer  22  extracts modeling element of business model from normalized business model in step S 80 . In step S 81 , the model semantics transformer  22  locates modeling element within the model ontology  262 . And it is determined in step S 82  whether said modeling element exists, and if it is determined that no modeling element exists, then the process proceeds and exception is thrown in step S 83 . If it is determined in step S 82  that the said modeling element exists, then an instance of model ontology is created in step S 84  for the modeling element, and the ontology representation of business model, i.e., business model semantics, will be output. In step S 85 , the specific items (e.g. caption, comment) are extracted. And in step S 86 , the words/phrases of the modeling element are analyzed. In step S 87 , the domain semantics locator  21  retrieves said words/phrases in the domain ontology  261 . And it is determined in step S 88  whether there exist the said words/phrases, and if it is determined that said words/phrases do not exist, then the process proceeds and abnormity is lodged in step S 83 . If it is determined in step S 88  that there exists such words/phrases, then an instance of the domain ontology is created in step S 89  for the specific item, and the ontology representation for domain concepts, i.e., domain model semantics, will be output.  
         [0054]     In step S 33  in  FIG. 3 , the business model semantics and domain model semantics generated by the aforesaid process are combined herein by unified semantic model builder  23 , and the unified semantic model will be output.  
         [0055]     Here is the sample unified semantic model that is generated for the business process shown in  FIG. 7 .  
                                                     //define process as CreditLoan             &lt;process:BusinessProcess           rdf:about=“http://semantics.crl.ibm.com/SinoPac#CreditLoan”/&gt;             //define activity A001             &lt;process:Activity           rdf:about=“http://semantics.crl.ibm.com/SinoPac#A001”&gt;             &lt;process:activityLabel           rdf:about=“http://semantics.crl.ibm.com/banking#Inquiry”/&gt;             //indicating the activity A001 is Inquiry             &lt;process:precede             rdf:about=“http://semantics.crl.ibm.com/SinoPac#A002”/&gt;             //indicating A001 is before A002             &lt;/process:Activity&gt;             //define activity A002             &lt;process:Activity             rdf:about=“http://semantics.crl.ibm.com/SinoPac#A002”&gt;             &lt;process:activityLabel           rdf:about=“http://semantics.crl.ibm.com/banking#Loan”/&gt;             //indicating activity A002 is Loan             &lt;process:parallel             rdf:about=“http://semantics.crl.ibm.com/SinoPac#A003”/&gt;             //indicating activity A002 and A003 are executed in a           parallel way             &lt;process:parallel             rdf:about=“http://semantics.crl.ibm.com/SinoPac#A004”/&gt;             //indicating activity A002 and A003 are executed in a           parallel way             &lt;/process:Activity&gt;             //define activity A003             &lt;process:Activity             rdf:about=“http://semantics.crl.ibm.com/SinoPac#A003”&gt;             &lt;process:activityLabel           rdf:about=“http://semantics.crl.ibm.com/banking#Debit”/&gt;             //indicating activity A003 is Debit             &lt;/process:Activity&gt;             //define activity A004             &lt;process:Activity             rdf:about=“http://semantics.crl.ibm.com/SinoPac#A004”&gt;             &lt;process:activityLabel           rdf:about=“http://semantics.crl.ibm.com/banking#Settlement”/&gt;             //indicating activity A004 is Settlement             &lt;/process:Activity&gt;                      
 
         [0056]     In  FIG. 3 , the method of the present invention may optionally choose to include validation for unified semantic model, after step S 33  is completed. That is to say, after the unified semantic model is formed, some constraint rules can be defined as part of the ontology to validate the unified semantic model. For example, we can specify some rules like following:  
         [0057]     to say that each “Activity” element in a business process model should represent for an “Operation” concept in the banking domain ontology;  
         [0058]     to say that each “Object” element in a business process model should represent for a “Document” concept in the banking domain ontology  
         [0059]     These constraints can also be transformed into the semantics model as follows:  
                                     //define constraint activityLabel, indicating ‘Activity’       element should represent for an “Operation” concept in the banking       domain ontology &lt;owl:ObjectProperty       rdf:about=“http://semantics.crl.ibm.com/constraints#activityLabel”&gt;         &lt;rdfs:domain       rdf:about=“http://semantics.crl.ibm.com/process#Activity”/&gt;         &lt;rdfs:range       rdf:about=“http://semantics.crl.ibm.com/banking#Operation”/&gt;         &lt;/owl:ObjectProperty&gt;         //define constraint objectLabel, indicating “Object”       element should represent for a ‘Document’ concept in the banking domain       ontology         &lt;owl:ObjectProperty       rdf:about=“http://semantics.crl.ibm.com/constraints#objectLabel”&gt;         &lt;rdfs:domain       rdf:about=“http://semantics.crl.ibm.com/process#Object”/&gt;         &lt;rdfs:range       rdf:about=“http://semantics.crl.ibm.com/banking#Document”/&gt;         &lt;/owl:ObjectProperty&gt;                  
 
         [0060]     Then we can input the unified semantic model, containing model ontology, domain ontology, instances of model ontology (generated from normalized business operational models) and constraint ontology, to Inference Engine and check the consistency of the semantics model.  
         [0061]     Here are two more complex rules that are provided by users.  
         [0062]     Rule1: We should do “inquiry” before any kind of “transaction” 
                                                     //define activity A001             &lt;process:Activity           rdf:about=“http://semantics.crl.ibm.com/SinoPac#A001”&gt;             &lt;process:activityLabel           rdf:about=“http://semantics.crl.ibm.com/banking#Inquiry”/&gt;             //define relationship precede             &lt;process:precede           rdf:about=“http://semantics.crl.ibm.com/process#Operation”/&gt;             &lt;/process:Activity&gt;             Rule2: We should do “settlement” after any kind of           “transaction”             //define activity A004             &lt;process:Activity           rdf:about=“http://semantics.crl.ibm.com/SinoPac#A004”&gt;             &lt;process:activityLabel           rdf:about=“http://semantics.crl.ibm.com/banking#Inquiry”/&gt;             &lt;process:after           rdf:about=“http://semantics.crl.ibm.com/process#Operation”/&gt;             &lt;/process:Activity&gt;             //define relationship after             &lt;owl:ObjectProperty           rdf:about=“http://semantics.crl.ibm.com/process#after”&gt;             &lt;owl:inverseOf           rdf:about=“http://semantics.crl.ibm.com/process#precede”/&gt;             &lt;/owl:ObjectProperty&gt;                      
 
         [0063]     It is apparent that Rule 2 will make the semantics model generated in  FIG. 7  inconsistent with Rule 2, since according to the instance of domain ontology for banking in  FIG. 5 , the ‘Loan’ in  FIG. 7  belongs to ‘transaction’. That is to say, in  FIG. 7 , ‘transaction’ is parallel with ‘settlement’ rather than followed by ‘settlement’, thus it is inconsistent with Rule 2. Other application programs may receive inconsistent result of examination and adopt appropriate measures to alarm user, or automatically correct error so as to make semantics model be consistent.  
         [0064]     The method according to the present invention may be encoded as program stored on the computer-readable storage medium, and can be realized by executing the program by a computer. Therefore, the present invention also includes the computer program product that is encoded according to the method of the present invention, as well as the computer readable medium storing the said computer program.  
         [0065]     The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.  
         [0066]     The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.  
         [0067]     Having thus described the invention of the present application in detail and by reference to embodiments thereof, it will be apparent that modifications and variations are possible without departing from the scope of the invention defined in the appended claims.