Telecommunications Service Domain Ontology: Semantic Interoperation Foundation of Intelligent Integrated Services

Network is the bearer of services and services are the soul of network. The convergent network extends the original communications service type and gradually forms new convergent services which integrate the traditional telecommunication services and a large number of value-added services or contents on Internet (Kolberg et al., 2010). The integrated service is essentially to handle the data and services across heterogeneous networks and service platforms. Facing the heterogeneity and diversity of service resources, integrated services need to run in a multi-terminal, multi-access network and multi-platform heterogeneous environment. These tremendous changes of service environment present a significant interoperability challenge for traditional service provisioning theory. Nowadays, the provision of context-awareness, adaptive personalized services is the development goal of future ubiquitous network (Park et al., 2009). It can enable seamless information exchange between humans, with humans and with entities (e.g., mobile devices), as well as entities and entities at any time, any place and in any way. To meet the development needs of adaptive personalized convergent services, dynamic service discovery and composition technologies are explored widely in the telecommunication service field (Bashah et al., 2010; Niazi & Mahmoud, 2009).


Introduction
Network is the bearer of services and services are the soul of network.The convergent network extends the original communications service type and gradually forms new convergent services which integrate the traditional telecommunication services and a large number of value-added services or contents on Internet (Kolberg et al., 2010).The integrated service is essentially to handle the data and services across heterogeneous networks and service platforms.Facing the heterogeneity and diversity of service resources, integrated services need to run in a multi-terminal, multi-access network and multi-platform heterogeneous environment.These tremendous changes of service environment present a significant interoperability challenge for traditional service provisioning theory.Nowadays, the provision of context-awareness, adaptive personalized services is the development goal of future ubiquitous network (Park et al., 2009).It can enable seamless information exchange between humans, with humans and with entities (e.g., mobile devices), as well as entities and entities at any time, any place and in any way.To meet the development needs of adaptive personalized convergent services, dynamic service discovery and composition technologies are explored widely in the telecommunication service field (Bashah et al., 2010;Niazi & Mahmoud, 2009).
Today, semantic web service (McIlraith, 2001), as an establishing research paradigm, is defined as an augmentation of web service with semantic annotation, to facilitate the higher automation of service discovery, composition, invocation and monitoring in an open environment.Integration of the semantic web technology and telecommunications systems is explored widely in the telecommunication service field (Do & Jorstad, 2005;Vitvar & Viskova, 2005;Qiao et al., 2008a;Gutheim, 2011;Khan et al., 2011;Zander & Schandl, 2011).It is well known that ontology is the semantic interoperability and knowledge sharing foundation for semantic web services matching and context reasoning.Therefore, how to construct the telecommunications service domain ontology is an important factor of successfully applying semantic web services into telecommunication service systems (Veijalainen, 2007(Veijalainen, , 2008)).However, telecommunication service field consists of a large number of concepts/terminologies and relations.How to abstract the sharing domain concepts and reasonably organize them is a big challenge.Some related work has been done mainly in applying ontology technology to the mobile service domain.Based on the need for a standardized ontology that describes semantic models of the domains relevant for scalable NGN (Next Generation Network) service delivery platforms, the (Villalonga et al., 2009;Su et al., 2009) provide an overview of Mobile Ontology which comprises a core ontology and several subontologies, and its application examples in the service delivery platform.This work, as a part of IST SPICE project (IST SPICE project, 2008), is a meaningful attempt to establish a standardized ontology for mobile service delivery in NGN.In addition, IST SIMS project explored the semantic interfaces as a new means to specify and design service components and to guarantee compatibility in static and dynamic component compositions.And they also defined a domain-specific ontology, and its main purpose of the ontology is to establish a common description of the SIMS-related concepts and their semantics (Rój, 2008).The (Zhu et al., 2010) introduces a mobile ontology construction and retrieval system architecture.However, there lacks a general domain ontology modelling methodology for telecommunications service and the corresponding engineering approach to support the development work for domain ontology.The (Li et al., 2010) briefly introduced the constructing method of telecommunications service domain ontology (TSDO) proposed by our research team.However, the approach is not perfect at that time and still needs to be further improved.In fact, telecommunication service domain ontology, as the important semantic interoperability foundation of telecom network, still has no significant progress up to now.This has become the biggest obstacle to hamper the applications of semantic web technology in telecom field.
In this chapter, we clearly presented a practical domain ontology modelling approach for telecommunications service field.Under the guidance of this approach, our research team has created an open telecommunications service domain ontology knowledge repository which consists of around 430 telecommunications services-related ontology concepts/terminologies and 245 properties.Based on this domain ontology, we described the telecom network capability services in the semantic level to validate its feasibility.The semantic annotation facilitated the accurate service description, discovery of telecommunication network services and addressed the semantic interoperability problem.The proposed model-driven domain ontology modelling approach separates domain conceptual model from the concrete ontology modelling languages, it enhances the reusability of domain conceptual model and greatly reduces the technical difficulty of domain ontology modelling.
The remainder of this chapter is structured as follows.In Section 2 we presented a general domain ontology modelling methodology for telecommunications service field, and also proposed a specific model-driven domain ontology modelling approach to support the above presented methodology.Section 3 introduced the experimental environment and the demo service to validate the feasibility of domain ontology.Finally, conclusions are drawn.

Domain ontology modelling methodology for telecommunications service
Here, technical modelling details for the proposed approach are described, namely telecommunications service domain ontology modeling methodology and a corresponding model-driven implementation mechanism.

Domain ontology modeling methodology
Based on our practical experiences in recent years, a concrete domain ontology modeling methodology is summarized as shown in Figure 1.The modelling process is illustrated in detail as follows.

Define the scope of telecommunications service domain ontology
The first step is mainly to define the scope and border of domain ontology.Telecommunications service domain ontology mainly addresses the semantic interoperability of telecommunications service.This domain ontology mainly provides the shared domain vocabularies and knowledge to support the semantic web applications in the telecommunication service field, such as semantic telecom service description, service discovery, and service context modelling.Therefore, TSDO should involve the servicerelated domain concepts and knowledge.For example, telecom services often involve network type, network carrier, billing policy, user terminal, service quality, service customer, service category, .etc.In fact, telecommunication service field consists of a large number of concepts/terminologies and relations.Some concepts have the higher sharing degree.However, some concepts are only related to concrete application field, such as service context ontology, service description ontology.Therefore, how to abstract the sharing domain concepts and reasonably organize them is a big challenge.The reusability and extensibility are two important ontology modeling factors considered.So an efficient ontology hierarchy modelling approach is needed.
In practice, we adopted a layered ontology modeling method to organize the domain concepts to improve the reusability and extensibility (see Figure 2).Common ontology, like time and space ontologies, can be shared in the different domains, like telecom, medical domain or any other domains.The concrete domain ontology can be shared by the different domain-related application ontologies.For example, TSDO may be used to create the service context ontology, network management ontology, etc.This method well distinguishes the border of TSDO, common ontology and telecom service-related application ontology.

Set the framework of telecommunications service domain ontology
When the goal and scope of TSDO are clear, the specific organization framework of TSDO should be set up.As TSDO involves a large number of telecom service domain concepts and relationships, how to reasonably classify and organize these terminologies is an important issue.Specifically, we adopted a modular modelling approach to construct TSDO.The principle of modular modelling is the "strong cohesion and loose coupling" way.The correlations among different concepts are the main reference of module division.The goal of modular modelling is to ensure that the correlation of concepts in the same module is stronger.Based on this modular design principle, TSDO is divided into several subontologies as shown in Fig. 3.

Multi-channel acquisitions of telecom service-related domain concepts and knowledge
After the framework of TSDO is set up, it needs to collect domain concepts and knowledge (including terminologies and their relationships) from multi-channel ways for each subontology of TSDO.In general, the sources of knowledge acquisition include the released telecom service specifications, senior experts in the telecom field or some typical application Fig. 4. Some collected domain concepts about telecom network.
www.intechopen.comscenarios.In this step, modellers need to list the collected concepts, relations and explanations as far as possible.It's unnecessary to care about the meaning overlap between the concepts and to consider how to express these concepts and their relation in class, property or instance ways.For example, Figure 4 briefly shows the concepts collection about network ontology.

Conceptual modelling of telecommunications service domain ontology
After the acquisition of a large number of telecom service related concepts, we need to make the concept classification, concept aggregation, and remove the duplicated concepts according to certain domain knowledge and logic.The goal of this step is to construct a conceptual model of TSDO.This concept model describes the involved domain concepts and their relations of each sub-ontology in detail.Note that, the relationships between the concepts not only involve the concepts of the same sub-ontology, may also be related to the concepts of different sub-ontologies.The concrete building of conceptual model is divided into three steps: (1) Defining classes and class hierarchy.In the process of defining the classes, we need to discover the inheritance hierarchy between the concepts and then distinguish the super-classes and sub-classes.
(2) Defining the properties of classes.After the class is defined, its properties should be considered.There are two kinds of properties.One is datatype property, which is used to describe the features of the concept itself, such as name, age.The other is object property, which is used to depict the relationship between the concepts, like friendship relation between two people.(3) The definition of domain axiom and knowledge.When we use ontology to describe the real word things, there are often some contradictions or errors occurrences resulted by human negligence.For example, the range value of one person age property is negative, or a person has two biological fathers.
To prevent these common-sense errors, some domain axiom and knowledge should be established.The axiom is to restrict the relationships of the concepts to ensure the consistency of domain knowledge, such as the range value or cardinality of properties.www.intechopen.com Figure 5 shows the conceptual model of network ontology in part.Based on the terminologies collected in the above step, the class hierarchy and relationships are described.This conceptual model depicts the classification of network, the services provided by network and the operator of network.It can be seen that the ranges of object property "operatedBy" and "provides" are the concepts from ServiceRole and ServiceCategory subontologies respectively.In addition, we define the domain axioms through the constraints way.For example, we define that "FixedNetwork" is disjointed with "MobileNetwork", i.e. if N1 is an instance of concept "FixedNetwork", then it will not be an instance of concept "MobileNetwork".

Formalization of conceptual model of telecommunications service domain ontology
As the conceptual model is one high-level abstract model and independent of any concrete ontology modelling languages, we need to formalize this conceptual model through a specific ontology modelling language like OWL (Web Ontology Language) (W3C, 2004a).In general, we can use the common ontology modelling tools to formally describe the terminologies, relationships and axioms in the conceptual model.Figure 6 shows the formalization description of part concepts and relationships of Figure 5 by OWL language.
The concept is formally defined by "owl:Class", and the class hierarchy is organized by "owl:subClassOf".The "owl:ObjectProperty" is used to describe the relationships between the concepts and the "owl:disjointWith" clearly depicts the restrictions on the two disjointed concepts.
Fig. 6.Part of network ontology formalized by OWL.

Evaluation of telecommunications service domain ontology
Ontology evaluation is an important issue that must be addressed if TSDO are to be widely adopted in the semantic related telecommunications applications.Ontology can be 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 until the requirement is satisfied.
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 service role sub-ontology.

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 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.

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 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.

Overview of model-driven TSDO modeling approach
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 models in CIM, PIM or PSM stage.
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 concepts and their relationships to form a high-level domain ontology model, which is independent of a specific ontology description language.The PSM and code steps are used to realize the formalization of high-level domain ontology conceptual model by a specific ontology language.By the model to model transformation technology, the highlevel conceptual model (i.e.PIM ) can be transformed into an ontology language specific model (i.e.PSM).And then by using model to code transformation technology, the concrete ontology description file encoded by a specific ontology language like OWL (i.e.code) can be generated from the ontology language specific model (i.e.PSM).When we need to revise or maintain the created ontology, we can return back to the CIM or PIM to modify the related models and then generated the corresponding code again.In this mode-driven ontology development approach, all processes adopt the standard UML model or UML extension mechanism (i.e.UML Profile).The technical details are described in the following sections.However, although UML Class diagram has some constructs similar to the constructs of ontology representation language, there are still some ontology constructs which cannot be represented by UML constructs directly.We need to find the appropriate UML elements to represent some other ontology constructs, like objectProperty, equivalent class relation, and disjointing class relation.For instance, we can select the directedAssociation element of UML to represent the ObjectProperty and use the constraints anchored with association to represent the inverse, symmetric or transitive feature of ObjectProperty.An illustrated example is shown in Figure 13.

CIM
As a common software modeling language, most of software developers, system analysts and designers are familiar with UML.So, in order to decrease the technical threshold, it's a practical approach for the conceptual modeling of TSDO by UML.Although UML has some similar constructs with ontology language, however, the modeling goals and description capabilities of both languages have some differences.From the above analysis, in order to use UML to represent high-level ontology conceptual model, we need to define a specific tailored representation method to guide the modeler to build the conceptual model of domain ontology.Table 1 shows the main corresponding relation of UML elements with ontology elements.According to this semantic representation way, the modeler can use the UML elements to describe the semantic-enabled high-level ontology conceptual model like Figure 14.

UML Elements Ontology Elements Comments
Class Class

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  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 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.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  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, 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.www.intechopen.com

PSM to code step: Formalization of ontology conceptual model
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 technology.

Model to code transformation theory
Before we introduce the concrete transformation process, some related definitions are given firstly.
Definition , denoted as A ＝ () ij nn a ( i,j = 1, 2, 3, ……, n ) is used to describe the relations between the class nodes and relation nodes in the PSM.And ij a indicates whether there is relation between class node i and class node j, as well as the type of relation node.

Definition 3. Connected subgraph
Given a directed graph, which can be divided to several connected subgraphs {G1, G2, …, Gn}, these subgraphs meet the following conditions:

•
In any two connected subgraphs Gi and Gj, there is no such a node x which is both in Gi and Gj at the same time.That is, , • In a connected subgraph Gi, there always exist directed edge between any two nodes x and y (without regard to the direction of the edge).

Definition 4. Model Transformation Automaton (MTA)
Model transformation automaton is a quintuple: MTA = (Q, Σ, δ, q 0 , F), including: • Q: A nonempty and finite set of states and one state in it corresponds to an ontology class node.∀ q∈Q, q is called a state of MTA.q 0 : The begin state of MTA, q 0 ∈Q.
• F: The set of terminate states.F is included by Q.Any q∈F, q is called a terminate state of MTA.
According to the definitions given above, the transformation engine from PSM to formal file encoded by OWL can be described as: The model transformation engine firstly scans the PSM class graph, and the scanning result generates the ontology model triples UmlOnt(C, R, G).C is the set of all nodes in UML class graph, R is the set of all relations in UML class graph, G represents the structure relationship of the ontology class graph, which can be regarded as N connected subgraphs divided from a directed graph and these subgraphs correspond to N relation matrices {RM1, RM2, …, RMn }.One nonzero number ij a represents the relation type between the class node i and j, and these relations are all included in R.
When the transformation engine finishes scanning, it input the scan result to the model transformation automaton.In this MTA, the nonempty finite set of states corresponds to C in the ontology model triples; the input events table corresponds to R in the ontology model triples; the transfer function corresponds to G in the ontology model triples; q0 and F are elements in C. In the procedure of state transforming, the corresponding operations of model transformation are also performed in MTA.When the automaton arrives at the terminal, the transformation finishes.

The implementation mechanism of model to code transformation engine
In order to realize the model to code transformation according to the above mentioned theory, we design a model transformation engine based on Eclipse Plugin technology.In MDA, XML Metadata Interchange (XMI) (OMG, 2005b) is an Object Management Group (OMG) standard for exchanging metadata information via Extensible Markup Language (XML).As the most of MDA tools use XMI as an interchange format for UML models, the model transformation engine is responsible for scanning PSM encoded by XMI and then transforming PSM into ontology file encoded by OWL.The process of model to code transformation is indicated in Figure 19.

Model scanning module
When building ontology model, different modeling tool means different element label and different label structure in the model description file.Therefore, this chapter proposed a transitional model convert method, which adopts same data structure when describes different model format, i.e. the triples in Definition 1.This allows the model transformation is no longer constrained by the model structure.It thereby improves the versatility of transformation engine and is convenient to be maintained and updated.
The model scanning module in transformation engine scans the UML class graph encoded by XMI, and the scan result will generate two list sets in the transitional model.It is used to store the class nodes and relation nodes of UML graph, which corresponds to the C and R set in the UML ontology model triples.

Building relation matrix module
The function of relation matrix building module is used to generate the relation matrix of PSM, i.e. the G set in UML ontology model triples.There are mainly two kinds of nodes in UML class graph: class node and relation node.Relation node connects class node and distinguishes them by direction, which is very similar to the directed graph.Hence directed graph is adopted to represent UML class graph.Usually matrix is used to represent the graph, and the values in matrix represent the type of relation.In ontology model class graph, there may be several independent subgraphs, which satisfy the description in definition 2. Therefore, it is necessary to handle the relation matrix to produce N independent sub relation matrices.This method can reduce the order or relation matrix and thereby reduce store space of the model, which also improves the efficiency of model transformation.

Model transformation module
Model transformation module includes model transformation automaton and model transformation regulation table.In the process of states transition, the automaton performs transformation from PSM to OWL according to the corresponding transformation regulations.In this module, the automaton is separated with the model transformation regulations.Therefore, the changes of model transform regulation will not influence the running of automaton, and it is convenient to perform daily maintenance and update of the engine.
The model transformation automaton is a quintuple, and all information of this quintuple are included in the model transform transitional model, namely in the UML ontology description model triples (C, R, G).The states, input events and transformation function of the automaton correspond to the class nodes, relation nodes and relation matrix set respectively in PSM class graph.The begin state of automaton is the owlClass node or objectProperty/datatypeProperty node in class nodes and the terminate states set includes all class nodes whose out-degree are zero and all nodes have been transformed by the automaton.
The model transformation regulation table defines the transformation regulation from UML Profile for RDF and OWL to OWL language.In the states jump process of model transformation automaton, corresponding regulation is used to perform model transformation.In the process of formulating the transformation regulation, the relations between every label node should be unified, which makes the regulation can be formulated depending on the OWL label structure and the relations between UML model elements.And good regulation is easy to extend in the future.

Model output module
Model output module only stores the formalized result of the transformation to the appointed path.And in order to verify the validity of the OWL file transformed, user can import the generate code into protégé tool for verification.Protégé is an ontology editor developed by Stanford University, which represents the OWL structure in graphic interface and makes the verification of OWL code validity more quickly and conveniently.By using the above mentioned model to code transformation approach, the PSM of Figure 18 is transformed into the corresponding ontology encoded by OWL like Figure 20.

Experimental environment, use cases and evaluation
In this section, we describe our experimental environment, the implemented service use case and present the obtained evaluation results to validate the semantic interoperability enabled by telecommunications service domain ontology.

Experimental environment
In order to support this model-driven domain ontology modelling approach, Borland Together (Borland, 2006), a famous MDA tool, is employed in our experiment.By using UML extension mechanism, we implemented the UML Profile for RDF and OWL in Borland Together.In addition, Borland Together tool enable the model-to-model transformation, and this facilitates the transformation from PIM to PSM.Through the developed model-to-code transformation engine, we realize the transformation from PSM to ontology file encoded by OWL.At last, in order to verify whether the transformation is correct or not, the generated OWL file is imported in Protégé tool to test.By the experimental verification, the proposed model-driven ontology modelling approach can nicely support the constructing methodology of telecommunications service domain ontology.
Under the guidance of this approach, our research team has created a telecommunications service domain ontology knowledge repository which consists of around 430 telecommunications services-related ontology concepts/terminologies and 245 properties.Currently, these ontologies are published on our website (BUPT, 2009), see Figure 21.(Moerdijk & Klostermann, 2003).Thus, the telecommunication network services, such as call control, short messaging service, and location service, are available to the service developers in the form of APIs.This facilitates the value-added service development.With the development of distributed computing technology, Service-Oriented Architecture (SOA) is also imported into the telecommunications service domain by Parlay Web Service specifications.However, the open interface specifications of telecommunication networks are currently still in the syntactic level.As WSDL (Web Services Description Language)-based telecommunication network services lack the rich semantic annotation information, the keyword-based service matching cannot enable an accurate service discovery.So, currently value-added services often directly invoke the needed telecom network services provided by a specific network carrier.This results in the tight-coupling of application logic and service resources, which limits the provision of dynamically self-adaptive services.The applications cannot dynamically discover satisfied telecom network services and compose them according to the context environment.Facing the heterogeneous networks and personalized user demands, the self-adaptation has become a very important feature of future intelligent integrated service.Therefore, the semantic interoperability of telecom network and Internet in the service layer should be considered.
Based on this domain ontology, we described the telecom network capability services in the semantic level to validate its feasibility.We apply the semantic web service and ontology technologies to the telecommunications service domain, and present an infrastructure to enable the semantic interoperability of telecom network and Internet in the service layer (Qiao et al., 2008b).The proposed approach improves the accuracy of telecommunication network services description, discovery and matching, and unifies the semantic representations of telecommunication and Internet services.

Lessons learned
Currently, under the shift trend from Web2.0 to Web3.0 era, there have been some initial semantic web applications in Internet field.For example, the system of Twitter allows tweets to be tagged with information that will not appear in the message but can be read by computers (Twitter, 2010).Google is using structured data open standards such as microformats and RDFa to power the rich snippets feature.It's an experimental Semantic Web feature (Google, 2010).FOAF (Friend of a Friend) (FOAF, 2010) is a machine-readable ontology describing persons, their activities and their relations to other people and objects.As a "practical experiment" in the application of RDF and Semantic Web technologies to social networking, FOAF is becoming more and more popular now (FOAF, 2000).In addition, Linked Data (Linked Data, 2007) is a recommended best practice for exposing, sharing, and connecting pieces of data, information, and knowledge on the Semantic Web using URIs and RDF.
However, the semantic web applications in telecommunication services domain are still in an early research phase.Although RDF-based CC/PP (Composite Capability/Preference Profiles) (W3C, 2007) and UAProf (User Agent Profile) (OMA, 2001) are used to describe the terminal capability and user preference, other practical applications are very rare.Therefore, in order to eliminate the semantic gap between telecom network and Internet, the research on semantic web applications in telecommunications field still need to be further enhanced.Telecommunications service domain ontologies consist of various domain related concepts and knowledge, which is the base of semantic interoperability.The wide acceptance of standards and common practices of telecommunications service domain ontologies are still a way ahead.The promotion of the telecommunications service domain ontology by related standardization organizations would be in the foundation for the semantic interoperability of heterogeneous communications equipments and the industrial practical convergent service integration.

Conclusion
The network heterogeneity and service convergence are the main characteristics of future network.The provision of self-adaptive intelligent integrated services has become the pursuing goal of network carriers and value-added service providers.Dynamic discovery and composition of services are the important enabling technologies for self-adaptive integrated services.In the service discovery and composition process, semantic interoperability is a key issue.Actually, ontology, as a semantic interoperability and knowledge sharing foundation, has obtained more and more attentions.However, telecommunication service field consists of a large number of concepts/terminologies and relations.How to abstract the sharing domain concepts and reasonably organize them is a big challenge.In this chapter, we presented a practical domain ontology modelling approach for telecommunications service field.Based on this approach, we constructed an open telecommunication service domain ontology repository to support the knowledge sharing and reuse.This will partly facilitate the semantic interoperability of the telecommunications networks and the Internet in the service layer.

Fig. 3 .
Fig. 3.The framework of telecommunications service domain ontology.
Fig. 13.The indirect mapping example from UML to OWL.

Fig. 14 .
Fig. 14.PIM: A part of high-level conceptual model of network ontology.

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

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

Fig. 20
Fig. 20.A part of formal network ontology encoded by OWL.

Terminal Capability Ontology: defines
Specifically, TSDO mainly comprises six sub-ontologies, including Terminal Capability Ontology, Network Ontology, Service Role Ontology, Charging Ontology, Service Quality Ontology, and Service Category Ontology.1.main concepts about terminal software, terminal hardware, terminal browser and network characteristics supported by terminal.2.

Network Ontology: specifies
the network concepts, network category, network features, as well as the relationships of various networks, such as mobile network, internet, and fixed network, GSM, CDMA, UMTS, WCDMA, and WLAN.3.

Service Role Ontology: describes
the stakeholders' concepts of the service supply chain, for example, service provider, content provider, network operator, service user.4.

Service Category Ontology: describes
a telecommunications service classification.This ontology defines the relationship between various telecommunications services, like basic service, value-added service, voice service, data service, conference service, presence service, download service, browsing service, messaging service. 5. Charging Ontology: defines the charging-related concepts and rules about telecommunications services, including payment methods (such as prepaid and postpaid), charging types (such as time-based, volume-based, event-based, and contentbased), billing rates, as well as account balances.6.

Service Quality Ontology: A telecommunication
network must provide the services which have the end-to-end QoS guarantee.Depending on the technical characteristics, the QoS provided by different networks is varying.Service Quality Ontology mainly defines the QoS-related concepts about telecommunications service, including access network QoS, core network QoS and user's QoE, such as call delay, message size, call through rate, positioning accuracy, network bandwidth.

Table 1 .
The defined UML representation method for high-level conceptual model of domain ontology.

Table 2 .
specifies a part of stereotypes set that comprise the UML2 Profile for using UML to represent RDF/S and OWL vocabularies.A part of UML Profile for RDF and OWL.
1. Ontology model triples: UmlOnt (C, R, G).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.