METHOD AND APPARATUS FOR CORRECT MAPPINGS OF UML TO OWL

ONTOLOGY FORMAT

TECHNICAL FIELD

The present invention is related to converting unified modeling language (UML) into Web ontology language (OWL). (As used herein, references to the "present invention" or "invention" relate to exemplary embodiments and not necessarily to every embodiment encompassed by the appended claims.) More specifically, the present invention is related to converting unified modeling language (UML) into Web ontology language (OWL) by choosing a UML document from a memory and transforming automatically with a processing unit as input the UML document into OWL ontology as output without information loss.

BACKGROUND

This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.

Object and Information Modelling in many domain areas is dominated by the UML (Unified Modelling Language) 0. For example, the TeleManagement Forum (TMF) uses UML to capture their Shared Information and Data (SID) Model that is an information model that is specific to the telecommunications industry. However, UML is a graphical language that cannot be easily processed by machine. UML was designed for human viewing to help understand concepts rather than for direct use of UML models by an application. Ontology languages, such as the Web Ontology Language (OWL)O, provide a means to model and capture the classes, properties, and relationships of a domain in a manner similar to UML but with increased expressiveness within the language. In addition, ontology languages can be processed by machine at design time and at run-time and supports logical inference and reasoning.

It would be beneficial to translate the SID, and other UML, models into ontological representation employing Model Driven Architecture principles. For this purpose, Ontology Definition Meta-model (ODM) Adopted Specification 0 was defined by Object Management Group (OMG) focused on business semantics that specifically enable capabilities of business semantic for Model Driven Architecture (MDA) through formal grounding for its representation, management, interoperability and application. The specification defines the independent meta-models for several international standards for ontology, related profiles, mapping, and conventional modeling paradigms such as entity-relationship modeling. It also defines an OWL meta-model that provides an informal mapping from UML to OWL.

The UML version of the SID model is not directly utilized at run time within telecommunications applications. A semantic OWL version of the SID can be directly utilized at runtime. In addition, in relation to the UML version of the SID it is semantic OWL version of the SID that would natively have greater richness, which enables greater expression when modelling/capturing the classes, properties, and relationships of the SID domain. Furthermore, such richer expressiveness is especially useful when dealing with a range of complex domain models. In essence and under these criteria OWL could be considered superior to UML. Therefore, a key driver for using a semantic version of the SID is to enable a semantic approach to management in telecommunications environment.

At present, converting the SID from the UML format into a semantic OWL format is problematic and there is no solution to carrying out this conversion on a fully automated basis for more complex models.

Current attempts to automate the conversion of such models lead to failure or the loss of information that was present in the UML version of the SID model. It is necessary for current solutions to manually carry out a simplification task of the complex model that also includes changes, checks, and additions.

There are several identified problems that need to be addressed in order to automate the conversions process, and subsequently provide an overall automated mechanism for converting from UML SID to semantic OWL SID. The problems can be divided into 3 categories:

(1) Syntactic

Such as naming convention differences, when the space character can be part of UML entities names, whereas OWL names must be valid URI references with no space characters; or external references, which are unrecognized by translator or later within OWL file.

(2) Structural

Typical structural problem presents entity typing in UML. This can be done in several ways - within entity as its attribute; or as self-reliant element to which the entity has connection; or as external reference defined in sub-element of typed entity. Only the simplest UML models are recognized by translation engines.

(3) Semantic

Semantic problems are caused by the different meaning of certain concepts in UML as opposed to their meaning in OWL. As an example the ODM specification defines that the UML 'package' is mapped into an OWL 'ontology'. The understanding of package in UML is as a namespace for its members and other packages, thus UML does allow packages to be embedded into each other. An ontology in OWL can be seen as a container for individual elements contained in it, however it cannot contain other ontologies in the way UML treats packages. This leads to information loss during the mapping process as only the base package is translated correctly. In addition, there can be difficulties with inter-package references.

SUMMARY The present invention pertains to an apparatus for converting a unified modeling language, UML, document defining an information model for use in a telecommunications network into a Web ontology language, OWL, document. The apparatus comprises a memory adapted to store the UML document; and a processing unit adapted to transform automatically as input the UML document into OWL ontology document as output without information loss. The apparatus is adapted to use the OWL ontology document to respond at runtime to queries received from at least

one application controlling operation of at least one network element of said telecommunications network.

The present invention pertains to a method of controlling operation of a telecommunications network comprising converting a unified modeling language, UML, document into a Web ontology language, OWL, document. The UML document defines an information model for use in said telecommunications network. Said converting comprises the steps of retrieving the UML document from a memory of a network element operating in said telecommunications network and transforming automatically with a processing unit as input the UML document into OWL ontology document as output without information loss. The final step comprises using the OWL ontology document to respond at runtime to queries received from at least one application controlling operation of at least one network element of said telecommunications network.

The present invention also pertains to an apparatus for converting a unified modeling language, UML, document into a Web ontology language, OWL, document. The apparatus comprises a memory for storing the UML document. The apparatus comprises a processing unit which transforms automatically as input the UML document into OWL ontology as output without information loss.

The present invention also pertains to a method for converting a unified modeling language, UML, document into a Web ontology language, OWL, document. The method comprises the steps of retrieving the UML document from a memory. There is the step of transforming automatically with a processing unit as input the UML document into OWL ontology as output without information loss.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, the preferred embodiment of the invention and preferred methods of practicing the invention are illustrated in which: Figure 1 is a flow chart regarding the present invention. Figure 2 is a block diagram of the apparatus of the present invention.

DETAILED DESCRIPTION

Referring now to the drawings wherein like reference numerals refer to similar or identical parts throughout the several views, and more specifically to figure 2 thereof, there is shown an apparatus 10 for converting unified modeling language (UML) into Web ontology language (OWL). The apparatus 10 comprises a memory 12 with a UML document stored therein. The apparatus 10 comprises a processing unit 14 which transforms automatically as input the UML document into OWL ontology as output without information loss.

The processing unit 14 can transform the input using a plurality of rules. Each rule having a matching pattern which is used to identify the element that will undergo a transformation; and a transformation part where the exact transformation operations to be executed on a matched elements are defined. The plurality of rules can include a root element transformation rule, a typed element transformation rule, a name attribute transformation rule and a packaged elements transformation rule. The root element transformation rule can create a local copy of elements referenced, removes import statements and removes applied profiles, creates and adds base package, and creates name spaces and adds their declarations to attributes.

The typed element transformation rule can find a reference to an external element, finds the external element's local replacement, creates an attribute for the element, and removes the element containing a reference to an external resource. The name attribute transformation rule can replace all space characters for attribute value. The packaged elements transformation rule can obtain corresponding namespace and, for all children of the element, adds a namespace prefix to the element's name attribute before removing the package. The present invention pertains to a method for converting unified modeling language (UML) into Web ontology language (OWL). The method comprises the steps of choosing a UML document from a memory 12. There is the step of transforming automatically with a processing unit 14 as input the UML document into OWL ontology as output without information loss. The transforming step can include the step of using a plurality of rules. Each rule has a matching pattern which is used to identify the element that will undergo a transformation; and a transformation part where the exact transformation operations to

be executed on a matched elements are defined. The step of using a plurality of rules can include the step of using a root element transformation rule, a typed element transformation rule, a name attribute transformation rule and a packaged elements transformation rule. The step of using a root element transformation rule can include the steps of creating a local copy of elements referenced, removing import statements and removing applied profiles, creating and adding base package, and creating namespaces and adding their declarations to attributes.

The step of using a typed element transformation rule can include the steps of finding a reference to an external element, finding the external element's local replacement, creating of an attribute for the element, and removing the element containing reference to an external resource. The step of using a name attribute transformation rule can include the step of replacing all space characters for attribute value. The step of using a packaged elements transformation rule can include the step of obtaining corresponding namespace and, for all children of stated element, add a namespace prefix to the element's name attribute before removing the package.

The using the root element transformation rule step can include the steps of searching for elements that are root elements; for each root element located identifying each referenced external element type; and creating a type, ID, and name attribute for each referenced element type in XML. The using the typed element transformation rule can include the step of searching for elements e with external element reference; creating for elements e an XML attribute (typeA) and setting a name parameter for typeA to type. The using the name attribute transformation rule step can include the step of matching pattern blocks for name attributes nameA, which is an XML attribute containing attribute name that has a value, name. The using the packaged element transformation rule step can include the step of looking for a package, which is an XML element containing an attribute type that has a value of umLPackage.

The using the root element transformation step can include the step of creating a typed element for the external element type, adding created attributes to the typed element created, adding the created typed element to the root element; for each package, seeking all parent packages' names, concatenating the names into one string using a "." between names to create a new package name (pName), concatenating the original package name using the ".", adding a namespace declaration to the root

element (XML Attribute) with the PName as its identification, adding the XML Attribute to the root element with a name that corresponds to the root element name, and placing all translated elements from the root element into the package.

The using the typed element transformation rule step can include the step of setting a value parameter for typeA by obtaining a typed XML element that is defined as a child of the element e with name, type, obtaining a reference that the child contains, obtaining a local replacement for the reference, and setting a value parameter to be a local replacement of the reference; and adding typeA to element e attributes before removing the type attribute containing the external reference. The using the name attribute transformation rule step can include the step of transforming the attribute nameA value parameter by replacing all occurrences of space character in a string that was found. The using the packaged element transformation rule step can include the steps of transforming attribute finds a namespace assigned to the package, and for each element that is declared as a child of the package, adding a prefix to its name attribute, and removing the package.

In the operation of the invention, the SID model (or other complex UML models) is put in UML format through a pre-processing stage whereby the problems with the existing solutions addressed on an automatic basis.

This pre-processing stage is carried out using a novel pre-processing algorithm, which transforms the original input UML SID document without information loss and provides an output document that is significantly different in terms of its syntax, form, and structure. This output document has advantages over the previous document in terms of simplicity and being able to be converted automatically an ontological format.

Transformation was defined in the ATLAS Transformation Language (ATL) 0 and in order to carry out the pre-processing of SID UML the ATL engine is used. However, the algorithm (see below) is defined in generic pseudo-code and can thus be realized using many different transformation languages and executed by the corresponding transformation engine, e.g. another transformation complying with Query/Views/Transformation Specification (QVT) 0; or using XSLT transformation and so on. The initial UML document is pre-processed according to the algorithm presented below.

As mentioned above, the algorithm presented in Table 1 is defined using a transformation language, therefore it has a form of logical rules rather than sequence of commands. Every rule consists of two parts: matching pattern - which is used to identify an element that will undergo the transformation; and transformation part - where the exact transformation operations to be executed on a matched element are defined.

Each rule in the algorithm in Table 1 is executed, which identifies the element with a matching pattern and executes the associated transformation part. This is done for every matched element and for every rule. The algorithm works at the XML level because every UML (.uml) file conforms to this language. The XML ecore metamodel [6] is used to identify a model element and references to this metamodel are made in Table 1 using the XML tag (green text).

Table 1 presents the algorithm, which is defined using a transformation language; therefore it has a form of logical rules rather than sequence of commands. Every rule can be identified by the RULE prefix. A rule consists of two parts, namely a matching pattern and a transformation part. The matching pattern is used to identify an

element that will undergo the transformation and the transformation part defines the exact transformation operations to be executed on a matched element.

In Table 1, the rule that is presented first addresses root element preprocessing. The matching pattern looks for elements that are root elements. When found the transformation identifies each referenced external element type that is included in the element. For each of these the algorithm then (i) creates a type, id, and name attribute for the element as proper in XML, (ii) creates a type element for this external type, (iii) adds created attributes to type element created in (ii), and finally in (iv) adds the created typed element to root element that was matched in the matching pattern. In addition, each package contained in the root element is also addressed. For each package (i) the names of all parent packages are sought, (ii) these names are concatenated into one string using a "." between names to create a new package name (pName), (iii) the original package name is also concatenated using the "." principle, (iv) a namespace declaration is added to the root element (XML Attribute) with the pName as its identification, and (v) the attribute is added to the root element. This transformation rule ends by (i) adding package to this root element with a name that corresponds to the root element name, and (ii) place all translated elements from root element into this package.

The rule that is presented second in Table 1 addresses typed element preprocessing. The matching pattern looks for elements, e, with external element reference. When found the transformation creates an XML Attribute (typeA) and sets the name parameter for typeA to 'type' . In addition, the value parameter for typeA is also set. This is set by (i) getting the type XML Element that is defined as the child of the current element (e) with name 'type', (ii) getting the reference that the child contains, (iii) getting the local replacement for this reference, and (iv) setting the value parameter to be the local replacement of the reference. Finally, typeA is added to element (e) attributes before removing the type attribute containing the external reference.

The rule that is presented third in Table 1 addresses name attribute change. The matching pattern looks for name attributes nameA, which is an XML Attribute containing attribute name that has the value 'name'. When found the transformation

transforms attribute nameA value parameter by replacing all occurrences of space character in the string that was found.

The rule that is presented last in Table 1 addresses element in package preprocessing. The matching pattern looks for a package, which is an XML Element containing the attribute type (xsi:type) that has a value of "uml:Package". The transformation finds the namespace (ns) assigned to this package and, for each element that is declared as a child of this package, the algorithm adds a prefix (<ns>:) to its name attribute so that name is set as "<ns>:name". The package is then removed.

Figure 1 presents a diagrammatic explanation of the algorithm shown in Table 1. There are three levels in the diagram shown in Figure 1. In level 1 a very high level of the algorithm is present, which states that a source UML model is transformed into a more simplified UML model. Level 2 expands on the detail of the transformation rules by stating the four sets of transformation rules. Finally, the four sub-diagrams (3a, 3b, 3c, and 3d) in level 3 explain each of the transformation rules as identified in level 2. Figure 1 presents a diagrammatic explanation of the algorithm shown in Table

1. There are three levels in the diagram shown in figure 1. In level 1 a very high level of the algorithm is present, which states that a source UML model is transformed into a more simplified UML model. Level 2 expands on the detail of the transformation rules by stating the four sets of transformation rules. Note that the first of four transformation rules (3a) reflects the first rule in Table 1. The second transformation rule (3b) reflects the second rule in Table 1, the third and fourth also follow in this fashion. Finally, the four sub-diagrams (3a, 3b, 3c, and 3d) in level 3 explain each of the transformation rules as identified in level 2. It is important to also note that these diagram server to help explain Table 1 and do not add to, or alter, Table 1. The Root Element matching pattern (3a) states that the transformation will create a local copy of elements that are referenced, create and add base package, create namespace and add their declarations to attributes, and remove import statements and applied profiles. The Type Element matching pattern (3b) states that the transformation will find reference to external element, find its local replacement, create an attribute for element, and remove element containing reference to external resource. The matching pattern Name Attribute (3c) states that the transform will replace all space characters for attribute value. The matching pattern Package Element (3d) states that the

transformation will get corresponding namespace, and (for all children of the stated element) will add namespace prefix to its name attribute. The package will then be removed.

In one embodiment of the present invention a method of controlling operation of a telecommunications network comprises converting a unified modeling language, UML, document defining an information model for use in said telecommunications network into Web ontology language, OWL, document. The input data for the conversion is more like an input structure, which has been created at design time in UML. However, the data that fits the structure can be sourced also from counters in the network elements, KPI datastores, network information datastores, and so forth. The UML document defines an information model for use in the telecommunications network e.g. TMF' s Shared Information and Data (SID) Model. It is, however, applicable to any other UML model. The steps of the conversion include retrieving the UML document from a memory 12 of a core network element of said telecommunications network and transforming it automatically as an input with a processing unit 14 into the OWL ontology document as output. The transformation is carried out without information loss as explained earlier in the more general description of the conversion between UML and OWL data structures. In today's telecommunications networks the conversion carried out according to embodiments of the present invention would take place in the core network as this is where the most powerful Solaris machines can provide the computaional requriements for the transformation. However, in the future the same transformation process could happen in the less powerful network elements, including base stations, radio network controlers and other. If a document is relatively simple the transformation could occur even in a Terminal Equipment. Finally, the method comprises using the OWL ontology document to respond at runtime to queries received from one or more applications controlling operation of one or more network elements, for example base stations or a radio network controller of said telecommunications network. The query can come from network elements, asking for example for counter data, and from performance services regarding more reasoning or inference information.

In one embodiment it could be a query received from a base station that is related to cell breathing. If in a set of base stations serving one geographical area one

cell fails the other base stations may attempt to cell breath outwards in order to cover the area of the fallen base station. This will result in coverage but may impact the ability of the larger set of cells to serve the same capacity. In a list of KPFs both coverage and capacity would be separate in a non-semantic database. However, in a semantic approach the impact can be described through additional annotation as inverse functional, in that increasing coverage effectively reduces capacity and also increasing capacity effectively reduces coverage. Therefore, a base station could send a query asking 'If I cell breath I know that, overall, the coverage will be increased but what else will be impacted?' . The semantic of the relationships will be able to inspect the KPFs and see that there is a correlation between coverage and capacity and reply with 'increasing coverage will decrease capacity' . The base station can now decide to cell breath outwards if capacity is not an issue, or decide not to cell breath outwards in order to maintain capacity. In this way the network is managed in a more automated and/or autonomic way. In another embodiment of the present invention an apparatus 10, e.g. a core network element, is disclosed for converting a unified modeling language, UML, document that defines an information model for use in a telecommunications network into a Web ontology language, OWL, document. The core network element comprises a memory 12 that is adapted to store the UML document and a processing unit 14 adapted to transform automatically as an input the UML document into OWL ontology document as an output. The transformation is carried out without information loss as explained with reference to the more general embodiment. The processing unit 14 in one embodiment is a microprocessor executing software embodying algorithm based on the method in accordance with the present invention. The core network element uses the OWL ontology document to respond at runtime to queries received from one or more applications controlling operation of one or more network elements of said telecommunications network.

It is important to note that the transformation takes a current information model format and transforms it into what is arguably the Web's future information model format. The benefits of using a semantic approach become available in the telecommunications network in relation to a transformed document. The benefits of a semantic approach include:

extendibility and reusability of the information model; interoperability between information models of different vendors used in the network, e.g. Key Performance Indicators; validity and consistency checking; - mapping between different vendors' terminology.

In general, the advantages of this invention are wide ranging. There is a vast amount of domain models currently developed in UML and a mechanism for converting these models to a more interoperable and run-time usable format is a valuable asset. This is valid not only for transformations to OWL, but also for other work with existing UML models, e.g. with other visualization tool. There are known issues when trying to use UML model different tool than the model was created by, these are caused by small differences in details when recording the model. The simplification of UML definition brings more interoperability to UML modeling.

This invention provides a real and tangible technical effect as, initially, the telecoms SID (Shared Information and Data) UML model is in one form with a certain syntax, form, and structure. In the current state of art this initial SID document cannot be automatically converted into an ontological language such as OWL. Therefore, this patent proposes a novel technique not found in prior art that takes the initial SID document and as an output provides a document that has a significantly different syntax, form, and structure. This outputted SID document has advantages over the previous SID document in terms of its simplicity and ability to be converted automatically into an ontological format. This automatic conversion aspect is a real challenge in automated systems and the possibility of a semantic version of the SID is key in areas such as LTE/SAE. Therefore, this invention is an enabler to added semantics and thus more open interfaces. Additionally, specific advantages of the invention are as follows:

(1) Pre-processing of the UML model (i.e. SID model) makes it possible to translate more complex models with existing transformation engines, which was not possible previously. (2) Enables the correct transformation from SID UML, through pre- processed UML, to the semantic OWL format of SID preserving information. Information that was previously lost is now maintained.

(3) Automated process that removes the need for the already stated manual aspects of transformation as was necessary previously.

(4) Processed UML is structurally more simplified and is therefore easier to convert to a range of formats such as OWL, XML, and also be used across various UML tools. Therefore, there is increased interoperability.

Thus, the listed advantages of the invention address the specific issues outlined above.

Abbreviations 3G - Third Generation Mobile Network

ATL -ATLAS Transformation Language

CDR - Call Data Records

MDA - Model Driven Architecture

ODM - Ontology Definition Meta-model OMG - Object Management Group

OWL - Web Ontology Language

LTE/SAE - Long Term Evolution/System Architecture Evolution

SID Model - Shared Information and Data Model

TMF - TeleManagement Forum UML - Unified Modelling Language

References

[1] OMG: UML (2.1.1) specification. 2007.

[2] W3C: OWL specification. 2004. [3] OMG: ODM specification. 2007.

[4] ATLAS group: ATLAS Transformation Language. 2006.

[5] OMG. MOF 2.0 Query/Views/Transformation Specification. 2007.

[6] Eclipse ecore Metamodel. 2007.

Although the invention has been described in detail in the foregoing embodiments for the purpose of illustration, it is to be understood that such detail is solely for that purpose and that variations can be made therein by those skilled in the art

without departing from the spirit and scope of the invention except as it may be described by the following claims.