**2.1.7 Maintenance of telecommunications service domain ontology**

The construction of domain ontology is the basis of ontology applications. However, as the different domain experts or ontology modelers may have the different understandings of the same domain concepts or relationships, some created ontologies may need to be further revised or improved in the practical utilization process. In addition, the knowledge of real world is growing and updated continuously. This also results that regular maintenance is necessary after ontoloies have been constructed. Ontology maintenance refers to a series of amendments, corrections, improvements and adaptive maintenance for ontology, which mainly consists of improving maintenance and adaptive maintenance. The improving maintenance is to revise or correct some existing errors of domain ontology. However, the adaptive maintenance refers to the extensions of existing domain ontology with the external real world changes, such as the knowledge increase or technology advances.

In addition, with the maturity of ontology technology, there are some ontologies developed by different research teams or communities to satisfy their different application needs. The main advantage of ontology is the knowledge sharing and reuse. How to realize the interoperation with these existent distributed ontologies is a big problem of ontology

evaluated against many criteria: its coverage of a particular domain and the richness, complexity and granularity of that coverage; the specific use cases, scenarios, requirements, applications, and data sources it was developed to address; and formal properties such as the consistency and completeness of the ontology. We can test and validate whether the domain ontology satisfy the requirement or not. If yes, these ontologies will be added to the ontology repository; if no, we have to return back to previous steps to make some revisions

In the specific use process, we often can find some existing shortcomings of domain ontology. The utilization of domain ontology to formally describe the concrete application scenario is a very effective evaluation approach. For example, when we defined the TSDO, we use network, service role and service category sub-ontologies to describe the network carrier resource (see Figure 7). We found that the operating scope of network carrier is an important characteristic. But the concept "NetworkOperator" of service role sub-ontology lacks this property. Actually, some carriers can provide services through out nation; however, some carriers can only provide services in a specific province or region. Therefore, the property "CoverageScope" should be added to the concept "NetworkOperator" of

Fig. 7. Ontology description of china mobile communication operator.

**2.1.7 Maintenance of telecommunications service domain ontology** 

real world changes, such as the knowledge increase or technology advances.

The construction of domain ontology is the basis of ontology applications. However, as the different domain experts or ontology modelers may have the different understandings of the same domain concepts or relationships, some created ontologies may need to be further revised or improved in the practical utilization process. In addition, the knowledge of real world is growing and updated continuously. This also results that regular maintenance is necessary after ontoloies have been constructed. Ontology maintenance refers to a series of amendments, corrections, improvements and adaptive maintenance for ontology, which mainly consists of improving maintenance and adaptive maintenance. The improving maintenance is to revise or correct some existing errors of domain ontology. However, the adaptive maintenance refers to the extensions of existing domain ontology with the external

In addition, with the maturity of ontology technology, there are some ontologies developed by different research teams or communities to satisfy their different application needs. The main advantage of ontology is the knowledge sharing and reuse. How to realize the interoperation with these existent distributed ontologies is a big problem of ontology

until the requirement is satisfied.

service role sub-ontology.

maintenance. Therefore, sometimes, it needs to integrate several existent ontologies to address the reuse of different ontology knowledge. To implement the different ontology integration, the relationships among different ontologies should be analyzed. As the distributed feature and openness of WWW, knowledge ontologies maybe have the direct or indirect semantic relationships. For example, two ontologies maybe involve some same or similar concepts. The main relationships consist of two kinds: one is the repeat of terminologies definition. Some terminologies of this ontology might be equivalent to those defined in that ontology. It consists of the class equivalent and the property equivalent. For this equivalent relationship, we can use equivalent ontology mapping method to resolve as shown in Figure 8. The other is the subsumption of terminologies definition. It means that some terminologies of one ontology might subsume the semantic scope of those terminologies defined in other ontology. It also involves the class subsumption and property subsumption. For example, Figure 9 shows two independent ontologies: ontology 1 and ontology 2. In fact, the concept "Netowrk" of ontology 1 subsumes the concept "Internet" of ontology 2 in the semantic scope. Therefore, we can use the subsumption relationship to integrate these two ontologies into a new ontology.

Fig. 8. Ontology integration based on the equivalent mapping.

Fig. 9. Ontology integration based on the subsumption relationship.

Telecommunications Service Domain Ontology:

**2.2.1 Overview of model-driven TSDO modeling approach** 

following sections.

models in CIM, PIM or PSM stage.

Fig. 10. Model-driven TSDO modelling approach.

Semantic Interoperation Foundation of Intelligent Integrated Services 193

described in section 2.1. By this approach, domain experts or general software developers, who are familiar with UML, can conveniently build the domain conceptual model by UML modelling tools and then this conceptual model can be automatically transformed into the corresponding ontology model encoded by a specific ontology language. As this approach separates domain conceptual model from the concrete ontology modelling languages like OWL, it enhances the reusability of domain conceptual model and reduces the technical difficulty of domain ontology modelling. The implementation details are described in the

MDA adopts the model-based development mode (Miller & Mukerji, 2003) as shown in Figure 10. Computation Independent Model (CIM) mainly describes the requirements of software system, which specify the system function and boundary. Platform Independent Model (PIM) is the high level abstraction of system function, without any information related to implementation techniques; Platform Specific Model (PSM) is the model which contains specific implementation platform technique information. The MDA–based development process is: firstly, establishing CIM based on the system requirements; secondly, according to the specifications of CIM, creating PIM with the platform independent modeling language, such as UML; thirdly, transforming the PIM to PSM according to some specific mapping rules; lastly, generating platform specific code automatically or semi automatically. In this process, modeller can further refine the created

According to the modelling idea of MDA, we presented a concrete model-driven TSDO modelling approach to provide a practical engineering implementation as shown in Figure 10. The definition of TSDO scope and the establishment of domain ontology framework belong to the CIM modelling stage. Modeller can employ use case diagram of UML to define the scope of TSDO and set up its framework. In this approach, PIM mainly focuses on the multi-channel domain concept acquisitions and the further conceptual integration and refinement, i.e. conceptual modelling. UML class diagram or use case diagram can be used to model the collected domain concepts and their relationships. After acquiring the domain terminologies, the following step is to integrate and refine these

### **2.2 A model-driven domain ontology modeling implementation approach**

From the above descriptions in section 2.1, it can be seen that the construction of TSDO is a complex work, which involves not only several steps like terminology acquisition, concept modelling and formal description, but also different modellers like domain experts, formalization modeller. Currently, it lacks of a unified modelling tool to efficiently support this methodology. As the ontology modelling languages consists of a large number of logical symbols and formal description knowledge, it is not easy for general domain experts or software developers to understand and master. Although there are some visual modelling tools like Protege (Stanford, 2004) to support ontology modelling, the ontology modelling process still lacks the relation with mature software engineering method. For the general software developers, the current ontology modelling approach is not easy to master and it needs a strong professional background. Therefore, in the actual process of building domain ontology, domain experts often use UML (Unified Modelling Language) (OMG, 2005a) modelling tool or other office software to acquire domain terminologies or create concepts model, and then formalization modellers formalize the conceptual model by a specific ontology language through ontology modelling tool like Protege. As the existing UML modelling tool do not support the ontology modelling directly and the common ontology modelling tools also do not support the requirements and high-level conceptual modelling, the above proposed modelling process has to switch between different modelling tools. A key problem is that the high-level conceptual model cannot be automatically transformed into formal model encoded by a specific ontology language. This brings a lot of management and maintenance inconveniences of ontology modelling. The existing ontology modelling approach has limited the large-scale ontology development. Therefore, it needs a practical engineering approach and a unified modelling tool to support this modelling methodology completely.

Essentially, ontology engineering emphasizes the ontology modelling and knowledge reasoning; however, software engineering focuses on the complete system development methodology which mainly pays attention to requirement analysis, system design, implementation and dose not have the logical reasoning capability. So how to use mature software engineering theory and method to support the ontology development is very significant. Today, Model Driven Development (MDD) (Selic, 2003) is gaining significant momentum in both the software industry and the software engineering academic community. Model Driven Architecture (OMG, 2003), standardized by the Object Management Group (OMG), is a new strategy for designing software systems. Its main goal is to separate system function specification from specific implementation technique completely, enabling system's kernel function specification to be independent of the specific implementation platform technology. Therefore, MDA can retain the neutrality of programming languages, middleware platforms and vendors. In the face of heterogeneous and evolving technology, MDA is supposed to ensure: portability, increased application reuse and reduced development time. Thereby MDA minimizes the affection of technique changes.

Considering the development of domain ontology is a complex process and MDA is a new modeling approach which focuses on the model rather than the specific implementation technical details, we integrated MDA with ontology engineering together, and proposed a model driven domain ontology modeling approach to support the modelling methodology

From the above descriptions in section 2.1, it can be seen that the construction of TSDO is a complex work, which involves not only several steps like terminology acquisition, concept modelling and formal description, but also different modellers like domain experts, formalization modeller. Currently, it lacks of a unified modelling tool to efficiently support this methodology. As the ontology modelling languages consists of a large number of logical symbols and formal description knowledge, it is not easy for general domain experts or software developers to understand and master. Although there are some visual modelling tools like Protege (Stanford, 2004) to support ontology modelling, the ontology modelling process still lacks the relation with mature software engineering method. For the general software developers, the current ontology modelling approach is not easy to master and it needs a strong professional background. Therefore, in the actual process of building domain ontology, domain experts often use UML (Unified Modelling Language) (OMG, 2005a) modelling tool or other office software to acquire domain terminologies or create concepts model, and then formalization modellers formalize the conceptual model by a specific ontology language through ontology modelling tool like Protege. As the existing UML modelling tool do not support the ontology modelling directly and the common ontology modelling tools also do not support the requirements and high-level conceptual modelling, the above proposed modelling process has to switch between different modelling tools. A key problem is that the high-level conceptual model cannot be automatically transformed into formal model encoded by a specific ontology language. This brings a lot of management and maintenance inconveniences of ontology modelling. The existing ontology modelling approach has limited the large-scale ontology development. Therefore, it needs a practical engineering approach and a unified modelling tool to support

Essentially, ontology engineering emphasizes the ontology modelling and knowledge reasoning; however, software engineering focuses on the complete system development methodology which mainly pays attention to requirement analysis, system design, implementation and dose not have the logical reasoning capability. So how to use mature software engineering theory and method to support the ontology development is very significant. Today, Model Driven Development (MDD) (Selic, 2003) is gaining significant momentum in both the software industry and the software engineering academic community. Model Driven Architecture (OMG, 2003), standardized by the Object Management Group (OMG), is a new strategy for designing software systems. Its main goal is to separate system function specification from specific implementation technique completely, enabling system's kernel function specification to be independent of the specific implementation platform technology. Therefore, MDA can retain the neutrality of programming languages, middleware platforms and vendors. In the face of heterogeneous and evolving technology, MDA is supposed to ensure: portability, increased application reuse and reduced development time.

Considering the development of domain ontology is a complex process and MDA is a new modeling approach which focuses on the model rather than the specific implementation technical details, we integrated MDA with ontology engineering together, and proposed a model driven domain ontology modeling approach to support the modelling methodology

**2.2 A model-driven domain ontology modeling implementation approach** 

this modelling methodology completely.

Thereby MDA minimizes the affection of technique changes.

described in section 2.1. By this approach, domain experts or general software developers, who are familiar with UML, can conveniently build the domain conceptual model by UML modelling tools and then this conceptual model can be automatically transformed into the corresponding ontology model encoded by a specific ontology language. As this approach separates domain conceptual model from the concrete ontology modelling languages like OWL, it enhances the reusability of domain conceptual model and reduces the technical difficulty of domain ontology modelling. The implementation details are described in the following sections.
