**2.2.4 PIM to PSM step: Formalization of ontology conceptual model**

It can be seen that the high-level ontology conceptual model described by UML is independent of a specific ontology language. So, in order to generate the formal file encoded by a specific ontology language, we need to transform the PIM into PSM according to the concrete model transformation rules. Figure 15 shows the general model transformation mechanism of model driven architecture. Model transformation is essentially to map the source model elements to other elements of the target model. Models are usually the instantiation of its meta-model. The model transformation rules are generally defined in the metamodel level and then model transformation engine apply these rules to the model level to complete the model transformation.

Fig. 15. The principle of model transformation.

Therefore, in order to transform the high-level ontology conceptual model (i.e. PIM) into platform specific model (i.e. PSM), we need to define the transformation rules according to the source and target metamodels. In our proposed approach, the high-level ontology conceptual model (i.e. PIM) is modeled by UML2.0, and the source metamodel is UML2.0 metamodel obviously. So we need a target metamodel relating to specific ontology language to describe the formal ontology model (i.e. PSM). In fact, OMG (Object Management Organization), which is the promoter of MDA, has considered this problem. In May 2009, OMG released the Ontology Definition Metamodel (ODM) v1.0 (OMG, 2009) based on the

Telecommunications Service Domain Ontology:

owl:ObjectPropert Class

owl:DatatypeProperty Class

Table 2. A part of UML Profile for RDF and OWL.

is UML Profile for RDF and OWL in this proposed approach.

OWL vocabularies.

Semantic Interoperation Foundation of Intelligent Integrated Services 199

Therefore, in this approach, the metamodel of PSM employs the UML Profile for RDF and OWL defined in ODM specification. This profile is designed to support modelers developing vocabularies in Resource Description Framework (RDF) (W3C, 2004b) and richer ontologies in the Web Ontology Language (OWL) through reuse of UML notation using tools that support UML2 extension mechanisms. Table 2 specifies a part of stereotypes set that comprise the UML2 Profile for using UML to represent RDF/S and

**RDF**、**RDFS and OWL ontology UML Base Class UML Stereotype**  rdfs:Resource Class 《rdfsResource》 rdfs:Datatype Class 《rdfsDatatype》 rdfs:domain Association 《rdfsDomain》 rdfs:range Association 《rdfsRange》 rdfs:subClassOf Generalization 《rdfsSubClassOf》 rdfs:subPropertyOf Generalization 《rdfsSubPropertyOf》 owl:Class Class 《owlClass》 owl:Restriction Class 《owlRestriction》

> AssociationClass Property Association

> AssociationClass Property Association

owl:equivalentClass Constraint 《equivalentClass》 owl:disjointWith Constraint 《disjointWith》

After the source and target metamodels are determined, we can define the model transformation rules from high-level ontology conceptual model (i.e. PIM) to ontology language related model (i.e. PSM). For example, based on the Table 1 and Table 2, we can define the following model transformation rules to support the model transformation like Figure 17. Notably, the source metamodel is UML2.0 metamodel and the target metamodel

When the transformation rules are defined, the model transformation engine can scan the elements of source model and then transform them into the corresponding elements of target model according to the transformation rules. As model transformation is a key technique used in model-driven architecture. In 2002, OMG issued a Request for proposal (RFP) on MOF Query/View/Transformation to seek a standard compatible with the MDA recommendation suite (UML, MOF, OCL, etc.). Several replies were given by a number of companies and research institutions that evolved during three years to produce a common proposal that was submitted and approved. QVT (Query/View/Transformation) (OMG,

《objectProperty》

《datatypeProperty》

meta-modeling mechanism of MDA. This specification represents the foundation for an extremely important set of enabling capabilities for MDA based software engineering, namely the formal grounding for representation, management, interoperability, and application of business semantics. The ODM is applicable to knowledge representation, conceptual modeling, formal taxonomy development and ontology definition, and enables the use of a variety of enterprise models as starting points for ontology development. ODM is based on the Meta Object Facility (MOF) (OMG, 2006) meta-modeling architecture of MDA, illustrated by Fig.16, which is based on the traditional four layer metadata architecture. From top to bottom, meta-data is abstracted to 4 layers: M3 (meta-meta model), M2 (meta model), M1 (model) and M0 (object and instance). The under-layer is the instance of its up-layer in turn. M3 layer is the end of meta-layer, namely, MOF is self-described. MOF is a common, abstract language used to define meta-model. It defines some metamodeling constructs, such as Class, DataType, Association, Package, and Constraint. So the meta-model of ODM or UML can be defined by MOF, whose power just lies in its capability to enable interoperability among different meta-models. Currently, there are 2 approaches to construct meta-models in M2 layer. One is to make use of MOF to define a completely new meta-model from syntax to semantics. Although this approach supports to define a new meta-model that will perfectly match the concepts and relation of the concrete domain, this need the underlying programming realization of corresponding new modeling tool. This is heavy-weight meta-modeling, such as UML and ODM. The other is to extend the existent UML meta-model and then construct a standard UML Profile through UML extension mechanism (Stereotype, TaggedValue, Constraints). This approach allows both defining domain specific conception and relation through UML extension mechanism and using the intrinsic UML elements. So it's a light-weight meta-modeling approach and most of existent MDA tools support this UML Profiling-based meta-modeling mechanism currently. There is no need to develop a new modeling tool. From the above analysis, the UML Profiling-based meta-modeling mechanism approach is adopted in our approach.

Fig. 16. ODM: the integration of semantic web and model driven architecture.

meta-modeling mechanism of MDA. This specification represents the foundation for an extremely important set of enabling capabilities for MDA based software engineering, namely the formal grounding for representation, management, interoperability, and application of business semantics. The ODM is applicable to knowledge representation, conceptual modeling, formal taxonomy development and ontology definition, and enables the use of a variety of enterprise models as starting points for ontology development. ODM is based on the Meta Object Facility (MOF) (OMG, 2006) meta-modeling architecture of MDA, illustrated by Fig.16, which is based on the traditional four layer metadata architecture. From top to bottom, meta-data is abstracted to 4 layers: M3 (meta-meta model), M2 (meta model), M1 (model) and M0 (object and instance). The under-layer is the instance of its up-layer in turn. M3 layer is the end of meta-layer, namely, MOF is self-described. MOF is a common, abstract language used to define meta-model. It defines some metamodeling constructs, such as Class, DataType, Association, Package, and Constraint. So the meta-model of ODM or UML can be defined by MOF, whose power just lies in its capability to enable interoperability among different meta-models. Currently, there are 2 approaches to construct meta-models in M2 layer. One is to make use of MOF to define a completely new meta-model from syntax to semantics. Although this approach supports to define a new meta-model that will perfectly match the concepts and relation of the concrete domain, this need the underlying programming realization of corresponding new modeling tool. This is heavy-weight meta-modeling, such as UML and ODM. The other is to extend the existent UML meta-model and then construct a standard UML Profile through UML extension mechanism (Stereotype, TaggedValue, Constraints). This approach allows both defining domain specific conception and relation through UML extension mechanism and using the intrinsic UML elements. So it's a light-weight meta-modeling approach and most of existent MDA tools support this UML Profiling-based meta-modeling mechanism currently. There is no need to develop a new modeling tool. From the above analysis, the UML Profiling-based meta-modeling mechanism approach is adopted in our approach.

Fig. 16. ODM: the integration of semantic web and model driven architecture.

Therefore, in this approach, the metamodel of PSM employs the UML Profile for RDF and OWL defined in ODM specification. This profile is designed to support modelers developing vocabularies in Resource Description Framework (RDF) (W3C, 2004b) and richer ontologies in the Web Ontology Language (OWL) through reuse of UML notation using tools that support UML2 extension mechanisms. Table 2 specifies a part of stereotypes set that comprise the UML2 Profile for using UML to represent RDF/S and OWL vocabularies.


Table 2. A part of UML Profile for RDF and OWL.

After the source and target metamodels are determined, we can define the model transformation rules from high-level ontology conceptual model (i.e. PIM) to ontology language related model (i.e. PSM). For example, based on the Table 1 and Table 2, we can define the following model transformation rules to support the model transformation like Figure 17. Notably, the source metamodel is UML2.0 metamodel and the target metamodel is UML Profile for RDF and OWL in this proposed approach.

When the transformation rules are defined, the model transformation engine can scan the elements of source model and then transform them into the corresponding elements of target model according to the transformation rules. As model transformation is a key technique used in model-driven architecture. In 2002, OMG issued a Request for proposal (RFP) on MOF Query/View/Transformation to seek a standard compatible with the MDA recommendation suite (UML, MOF, OCL, etc.). Several replies were given by a number of companies and research institutions that evolved during three years to produce a common proposal that was submitted and approved. QVT (Query/View/Transformation) (OMG,

Telecommunications Service Domain Ontology:

**2.2.5.1 Model to code transformation theory** 

*Definition 2. Relation Matrix (RM)* 

1 2

*Definition 3. Connected subgraph* 

11 12 1 21 22 2

 

*aa a aa a*

*n n nn*

*aa a*

... ... ... ... ... ... ...

*n n*

Gn}, these subgraphs meet the following conditions:

*Definition 4. Model Transformation Automaton (MTA)* 

class node. ∀ q∈Q, q is called a state of MTA.

*aij* ( *aij* ≠ 0 ), δ:Q×Σ→Q in relation matrix.

• q0: The begin state of MTA, q0∈Q.

and Gj at the same time. That is, ¬∃ ∈ ∩ ∈ *x x Gi x Gj* , .

and y (without regard to the direction of the edge).

*Definition 1. Ontology model triples: UmlOnt (C, R, G).* 

technology.

firstly.

looks like

of relation node.

node.

Semantic Interoperation Foundation of Intelligent Integrated Services 201

In order to generate the formal ontology file encoded by OWL, the PSM based on UML Profile for RDFS and OWL should be transformed into ontology file encoded by OWL, which is a model to code transformation process, which involves the model scanning

Before we introduce the concrete transformation process, some related definitions are given

PSM based on the UML class diagram can be represented by a triple: UmlOnt(C, R, G). C is the class node set, and it is an ontology class definition of the concept in PSM. R is the relation node set, and it is the definition of the relations among ontology class. G is the relation set of C and R, which describes the relations among the nodes in C and R set.

Relation matrix is a n order square matrix, including elements *aij* in total of n \* n, which

describe the relations between the class nodes and relation nodes in the PSM. And *aij* indicates whether there is relation between class node *i* and class node *j,* as well as the type

Given a directed graph, which can be divided to several connected subgraphs {G1, G2, …,

• In any two connected subgraphs Gi and Gj, there is no such a node x which is both in Gi

• In a connected subgraph Gi, there always exist directed edge between any two nodes x

• Q: A nonempty and finite set of states and one state in it corresponds to an ontology

• Σ: Input events table, in which one input event corresponds to an ontology relation

• δ: Transfer function. One transfer function corresponds to a nonzero number

Model transformation automaton is a quintuple: MTA = (Q, Σ, δ, q0, F), including:

, denoted as A = ( ) *aij nn* ( i,j = 1, 2, 3, ……, n ) is used to

**2.2.5 PSM to code step: Formalization of ontology conceptual model** 

2008) is a standard set of languages for model transformation defined by the Object Management Group. Currently, some MDA tools have declared to support the complete or part functions of QVT. For example, by using the transformation rules, the source model in Figure 14 is transformed into a target model in Figure 18.

Fig. 17. A part of PIM to PSM transformation rules definitions.

Fig. 18. PSM: A part of ontology specific model based on UML Profile for RDF and OWL.
