Ontology Modularization is one of the techniques that bear good promises of effective help towards scalability in ontology design, use, and management. The development of proper ontological modules should provide a mechanism for packaging coherent sets of concepts, relationships, axioms, and instances, and a means for reusing these sets in new environments, possibly heterogeneous with respect to the environment the modules were first built. The main contribution of this paper is to describe an approach for extracting views from domain ontology using existential dependency (ED) by reverse engineering process. The extraction process based on ED could provide a coherent fragment of ontology parts together with transitive closure of dependant parts. The goal of reverse engineering process is to output a possible conceptual model, which is more readable to extracting the views, on the basis of the code in which the ontology is implemented. Thus, a set of translation rules is used to convert owl ontology in a UML class diagram.
Ontology Modularization techniques identify coherent and often reusable regions
within an ontology. The ability to identify such modules, thus potentially reducing the
size or complexity of an ontology for a given task or set of concepts is increasingly
important in the Semantic Web as domain ontologies increase in terms of size,
complexity and expressivity[
In conceptual modelling, the Foundational Ontology is needed as domain independent
theoretical basis to guide and validate models of particular domains, as using of right
modelling concepts and rules is making a great influence on the quality of
Information Systems [
The rest of the paper is organized as follows: In section 2 we describe the architecture and the main steps of our approach. Section 3 introduces implementation of our system. Finally, we conclude this paper and outline our future work in section 4.
In this section, the global architecture of our system is presented. Figure 1 illustrates the main steps of the proposed approach.
The designer initiates transformation of domain ontology described in OWL file into UML class diagram by reverse engineering transformation. At first, system transforms ontology classes, then object and data type properties, and finally constraints.
Algorithm of mapping OWL Ontology to UML class diagram Input: OWL file ontology Output: UML class diagram Begin For all OWL class (concept) defined into ontology do Create UML class with same name.
If the ontological class is sub class of restriction then For all restriction do
If type of this restriction is : cardinality, minCardinality or maxCardinality then transforme these in multiplicities for propriety specified on Property of restriction
Else Define the name of role of toClasse classe with object property name specified in
Endif Endfor
Endif If this class is sub class of other class then
Define UML generalisation element
Endif Endfor For all DataTypeProperty Do
Create an attribute whose domain is class and whose range is the type of property Endfor For all ObjectProperty Do
Create UML association whose domain is class and whose range is class
Endfor End onProperty.
A Conversion tool implements a transformation from UML class diagram obtained in
step 2 to Guizzardi Metamodel (GM) [
Guizzardi’s concepts kind, subkind, phase, role and relator are all represented as stereotypes of the UML metaclass Class, for example, and all inherit the semantics of Class in UML. Any UML metaclass can be stereotyped.
Some examples of transformation rules:
Rule1: In UML Class Diagram, a collection of instances of classes are, respectively, instances of UML G-M profiles including concrete classes (<<kind>>, <<subkind>>, <<quantity>>, <<collective>>, <<phase>> and <<role>>).
Rule 2: In UML Class Diagram, concrete classes (and their instances) are related via UML G-M profiles including properties (<<mediation>>, <<derivation>>, <<characterisation>>, <<material>> and <<formal>>) as well as complex objects or part-whole (subQuantityOf, subCollectionOf, memberOf, componentOf).
Rule3: In UML CD, concrete classes (and instances) can be categorised accordingly by UML G-M profiles via abstract classes (<<category>>, <<roleMixin>> and <<mixin>>) and other rules.
This step present extraction cases and rules for how these views can be extracted using existential dependency, especially where the ontology is constructed using the GM formal ontology. We note that user in this case should specify certain individuals and classes. The extraction process produces a more focused and smaller portion and reduces the costs to the user. There are several systems under the 3G-M like systems of (kind, phase, role, mixin, quality, formal, relator, material, mode, Q-parthood, Cpartood, M-parthood and system of CF-parthood). All these systems contribute to the ED.
Some examples of extraction cases and rules: System of Kind: Super kind is Mandatory (+M), subkind is mandatory (+M), siblings are optional (-M): This case applies general rules “requires all superclasses’ and ‘siblings optional”.
System of Relator: A relator is mandatory (+M) and mediated classes are mandatory (+M) A mediated class is mandatory (+M), a relator is mandatory (+M) and a pair of mediated classes is mandatory (+M): Every instance of mediated class does not make sense without every instance of another (pair) mediated class witch the relator mediates to.
Superkind is an ultimate substance sortal that supplies a principle of identity. Superkind does not make sense without the roles and vice versa. Supermixin (role mixin) is optional (-M) since it does not supply a principle of identity. An application may not (-M) need sibling roles since they carry an incompatible principle of identity supplied by its superkind respectively. An individual must be not a member of its siblings. This case applies general rules: “some superclasses optional” and “siblings optional”.
Superkind is mandatory (+M), role is mandatory (+M), supermixin is optional (-M) and sibling roles are optional (-M).
Correctness of the extracted views translates the fact that no information is lost in the process.
Information preservation may be defined as the fact that the result of a query addressed to the collection is functionally (i.e., not from a performance viewpoint) the same as the result of the same query addressed to the original ontology.
The architecture of our system has been conceived to follow a Model-Driven
Approach. In particular, we have adopted the OMG MOF (Meta-Object Facility)
metamodeling architecture [
The full set of OCL expressions including: OCL expressions to specify derivation rules; OCL expressions to define default values; OCL expressions to specify operations created to support some OCL derivation rules and invariants, and invariants to model the constraints stated on the UML profile. An example of an OCL invariant representing the essential parthood axioms is shown in the code below. One can notice that in this expression the modal existential dependence constraint of essential parthood from UFO (Unified Foundational Ontology) is emulated via the existence condition (lower cardinality ≥ 1) plus the immutability constraint (isReadOnly = true).
Inv: if (self.isEssential = true) then self.target-> forAll(x | if x.oclIsKindOf(Property)
then ((x.oclAsType(Property).isReadOnly = true) and ((x.oclAsType(Property).lower
>= 1)) else false endif) else true endif
In This paper we describe our approach for extracting views from domain ontology by
reverse engineering process witch consists of transforming the OWL file ontology of
E-Tourism into UML class diagram. there is an implementation of the metamodel
proposed by Guizzardi [
Future work will concern the implementation of process of extracting views with rules proposed here to confirm the useful of our approach.