nghiên cứu phương pháp chuyển đổi giữa mô h̀nh mức khái niệm và ontology TT TIENG ANH

HUE UNIVERSITY
UNIVERSITY OF SCIENCES

VO HOANG LIEN MINH

RESEARCH ON TRANSFORMATION
METHODOLOGY BETWEEN CONCEPTUAL MODEL
AND ONTOLOGY

MAJOR: COMPUTER SCIENCE
CODE: 9.48.01.01

SUMMARY OF PHD THESIS


HUE, YEAR 2021

2


The thesis has been completed at Hue University – University of
Sciences
Supervisors:
- Assoc. Prof. Dr. Hoang Quang, Faculty of Information
Technology, University of Sciences, Hue University.
- Assoc. Prof. Dr. Hoang Huu Hanh, Director of International
Training Center Posts and Telecommunications Institute of
Technology.

Reviewer 1: Assoc. Prof. Dr. Dang Van Duc – Institute of Information
Technology, Viet Nam Academy of Science and Technology

……………………………………………………………......................
……………………………………………………………......................
Reviewer 2: Assoc. Prof. Dr. Tran Van Lang – Institute of Mechanism
and Application Information, Viet Nam Academy of Science and
Technology
……………………………………………………………......................
……………………………………………………………......................
Reviewer 3: Prof. Dr. Le Xuan Viet – Quy Nhon University
……………………………………………………………......................
……………………………………………………………......................
The thesis will be defended at Hue University’s thesis committee
meeting
at:
………………………………………………………………
3


This thesis can be found at the following library: The library of
University of Sciences, Hue University.

4


PREFACE
1. Necessity of the topic
The software industry has made many important breakthroughs in the
design of data models, especially conceptual models. Because they reflect
the real world well, entity-relationship models (ER models) and its
extensions are considered conceptual data models. In addition, in order to
model information systems with a set of attributes and methods to reflect

the data structure of a class, the UML class diagram is also one of the
conceptual data models used to describe and reflect the real world of
information systems.
According to the W3C, information provided by websites accounts for
nearly 70% of all information exchanged worldwide. The web has become a
large data system, and it is an indispensable information transmission
medium in these days. The question is how to effectively exploit
information on the Web, specifically how computers can understand and
support humans to process such information automatically. Therefore, the
semantic web was introduced, in which information is clearly defined, so
that humans and computers can work together more effectively.
Ontology is a scientific term used to describe the entities in the real
world and the relationships between those entities. Ontology provides a way
for both humans and machines to perceive information, thereby improving
two-way systems of interaction and knowledge sharing. Then, humans and
computers can work together, and computers "understand" and are able to
process information effectively. An important benefit of using ontology is
semantic search capabilities. So, W3C designed OWL as a language that
describes classes, properties, and relationships between objects in a way
that machines can understand web content.
However, most of the data has been modeled and stored in traditional
databases (relational databases, object oriented databases). Such data is
therefore beyond the reach of many applications of the semantic web. With
5


the current development of the semantic web, the integration of existing
web applications into the semantic web is becoming an urgent issue. In
addition, current applications are often designed from the conceptual data
model, while the semantic web is mainly built on ontologies represented by

OWL. Therefore, upgrading an information system by transformating
conceptual data models to ontology allows the inheritance of data structures
of older systems, so reduces design costs.
2. Research motivation
There are many researches proposing the transformation between
conceptual data model and ontology, such as: transforming ER model, UML
class diagram to OWL ontology, extracting from OWL ontology to ER
model... In the published researches, the authors have only proposed to
transform the general cases of the conceptual model and the OWL ontology.
But in reality, many information systems are designed to be sure to reflect
the nature of the real world, with many extended components. Applying the
transformation rules of previous studies will not fully transform the models.
Therefore, proposing a complete set of rules for transforming the
components of the conceptual model and OWL ontology is an important
issue in upgrading old information systems.
3. Research objectives
The purpose of this thesis is to research and develop transformation
methods between conceptual data models (such as ER model, EER model,
UML class diagram) and OWL. Therefore, the thesis implements specific
objectives including: (1) transforming the entity-relationship model into
OWL ontology; (2) transforming the UML class diagram into OWL
ontology; (3) extract conceptual data model from OWL ontology.
4. Object and scope of the study
- Research objects: OWL1, OWL2 and conceptual data models: entityrelationship model (ER), EER model, UML class diagram
- Research scope: It proposes a solution to transform between conceptual
data model and ontology.
6


5.

Research Methodology
- Theoretical research methodology: It aims to find out, collect, and

analyze published research works, journals, and articles published by
prestigious journals, seminars, or conferences, which helps to facilitate
researching,

and

supplementing

transformation

methods

between

conceptual data models and OWL ontology. Consequently, it enables to
evaluate strengths and weaknesses of preceding publications in comparison
with the recommended methods.
- Experimental methodology: It aims to install the principles of
conversion recommended by the thesis in order to prove the applicability of
the methods of conversion.
6. Thesis structure
The thesis includes the introduction, four chapters of content, conclusion
and references, as follows:
Chapter 1 presents an overview of conceptual data models, including
entity–relationship model, UML class diagram, semantic web concepts and
OWL ontology; surveys and analyzes several research works related to the

conversion between conceptual data model and OWL ontology; analyzes
the equivalence between the conceptual data model and the OWL ontology.
Thereby, the thesis will suggest more transformation rules between a
conceptual data model and OWL ontology.
Chapter 2 summarizes and analyzes the transformation results between
ER, EER and OWL ontology of researches, uniformly normalizes the
transformation rules according to the thesis's transformations; recommend
additional rules for transforming EER model to OWL ontology and presents
the transformation experiment results.
Chapter 3 summarizes and analyzes the transformation results between
UML class diagram and OWL ontology of several researches, uniformly
normalizes the transformation rules according to the thesis's transformation;
proposes additional rules for transforming a UML class diagram to an OWL
ontology based on the similarities between them; and presents the
7


transformation experiment results.
Chapter 4 suggests rules for extracting a conceptual data model from a
given OWL ontology. The extraction of a conceptual data model from a
given OWL is regarded as defining a backward mapping of the
transformation from conceptual data model to OWL ontology, allowing
"investigation" of a conceptual data model that could have been used to
design an ontology. Each extraction method is illustrated to verify the
results.
CHAPTER 1. OVERVIEW OF CONCEPTUAL DATA MODEL AND
ONTOLOGY
1.1 Introduction
1.2 Introduction of the conceptual data models
1.3 Introduction of the semantic web and ontology

1.4 Overview of ealier researches
1.4.1

The proposed results of entity-relationship model transformation to
OWL
Since 2005, there have been many studies proposing methods to
transform from ER or EER model to OWL ontology such as [1] [2] [3] [4].
In order to be able to propose transformation rules, all of these proposals
define the corresponding components between the ER model and OWL.
The earlier researches suggest the following transformation rules:
Transformation of entities type; Transformation of single_valued attribute;
Transformation of the relationship: Inheritance relationship (Is-A); Binary
relationship; n-ary relationship.
However, these studies have not suggested the transformation rules with
the components of Extended Entity Relationship (EER) model, specifically,
- Transformation of the weak entity and identifying relationship
- Transformation of the nested multi-valued composite attributes
- Transformation of recursive relationship
- Transformation of temporal aspects of EER
8


When performing the installation of a transformation program, if we do
not consider all possible cases of an input model, the output model cannot
be identified. Based on existing researches, the thesis proposes some
additional transformation rules from ER model to OWL in order to design
ontology as the stated purposes.
1.4.2

The proposed results of UML class diagram transformation to OWL

There have been many researchs on transforming from UML class
diagrams to OWL to reuse old systems [5] [6] [7] [8] [9] [10] [11] [ 12] [13]
[14]. The authors have analyzed the basic differences, thereby proposing
transformation rules: Transform class; Transform attribute; Transform
relations between classes: association, association with association classes,
aggregation, dependency, generalization/specialization.
Overall, previous researches have proposed transformation rules for the
cases of UML class diagrams, but these researches have not analyzed and
proposed the transformation of detailed cases of UML class diagrams,
including:
- Transformation of the attribute where the datatype is class;
- Transformation of the structured attributes;
- Transformation of the association with associated classes;
- Transformation of the recursive association;
- Transformation of the aggregation with a qualify;
- Transformation of the dependency.

1.4.3

The results of proposed extraction of the conceptual data model from
OWL
The authors [24] [25] have focused on developing a set of rules for
mapping OWL to ER and EER models by defining the basic components of
ER and EER models in a given OWL, as follows: mapping entities,
mapping attributes, mapping relationships.
Previous researches have proposed some mapping cases from OWL to
EER model. However, there are a number of output components that have
not been extracted, including:
9

-

Composite attribute

-

Recursive relationship

-

N-ary relationship

1.5 Summary of Chapter 1
The first chapter of the thesis introduced an overview about the
conceptual data models, the semantic web and OWL. This chapter outlines
the approach of the thesis, an overview of the results of the authors which
transform between conceptual data models and OWL. The following
chapters will present the research results of the thesis on these topics.
CHAPTER 2.
TRANSFORMATION OF ENTITY-RELATIONSHIP MODEL INTO
OWL
2.1 Introduction
The transformation of a conceptual model to OWL consists of two
stages: preprocessing and transformation. The preprocessing phase
transforms the conceptual data model into an XML/XMI document. The
transformation phase will apply algorithms to transform XML/XMI
documents into OWL ontology.

Figure 2.1 Conceptual data model into OWL framework architecture

2.2 Previous researches
2.3 Additional transformation rules
2.3.1 Transformation of the weak entity and identifying relationship
The author [6] shows that there is no difference when transforming the
strong entity type and the weak entity type, except for adding the datatype
property to class which represent the weak entity type. This datatype
property represents the primary key of the strong entity type. Semantics is
10


impossible to be assured by this approach in conducting the conversion. To
overcome this problem, the thesis adds two inverse object properties to
represent the identifying relationship.
Rules EER12.

Let consider that W is a weak type of identifying

relationship R and the owner entity type is E. Suppose that W has the partial
key KW, and KE is a key of E: Add the class C(W), the attributes attW of
the weak entity type W will transform into datatype properties DP(attW) of
class C(W) similar to the transformation of the attributes of the strong
entity; Add two inverse object properties E_R and W_R which show
relationship between classes C(E) and C(W); Set function characteristics
and minimum constraint to 1 to property W_R; Add the corresponding
min/max to the object properties W_R; Key of class C(W) was created by
combining the partial key KW with key KE of class C(E).
2.3.2 Transformation of the nested multivalued composite attribute
A nested multivalued composite attribute of an entity can be represented
by an identifying relationship between a weak entity and its owner entity, so
it is possible to transform each nested multi-valued composite attributes

with partial key into an identifying relationship in the ER model.
Rules EER13.

Let consider that entity E (or a nested multi-valued

composite attributes) and multi-valued composite attributes attE. The attE
has a set of sub attributes sub_attE and a partial key K_attE. The multivalued composite attributes attE is mapped to the identifying relationship
S_attE between the entity E and the weak entity W_attE. The weak entity
W_attE has sub attribute sub_attE and partial key K_attE: Add the class
C(W_attE), the attributes sub_attE of the multi-valued composite attributes
attE will transform into datatype properties DP(sub_attE) of class
C(W_attE); Add two inverse object properties E_W_attE and W_attE_E
which show relationship between classes C(E) and C(W_attE); Set function
characteristics and minimum constraint of 1 to property W_attE_E; Add the
corresponding min/max to the object properties E_W_attE ; Key of class
11


C(W_attE) was created by combining the partial key K_attE with key KE of
class C(E).
Table 2.1 Two inverse object properties added when transforming a nested
multi-valued composite attributes
Object

Domain

properties
E_W_attE
W_attE_E
2.3.3

C(E)

Range
C(W_attE

C(W_attE
)

)
C(E)

Transformation of the recursive relationship

Let consider that the recursive relationship R of the entity type E. Then,
R is called the symmetric if: ∀ e1, e2 ∈ E, (e1, e2) ∈ R  (e2, e1) ∈ R. And R
is called the asymmetric, if: ∃ e1, e2 ∈ E, (e1, e2) ∈ R và (e2, e1) ∉ R. The
thesis is considered in both cases: Symmetric recursive relationship and
Asymmetric recursive relationship.
2.3.4 The symmetric recursive relationship without attributes
Rules EER14.

For the symmetric recursive relationship R without

attributes on the entity E with role role: Add the object property with its
name is role, domain and range is class C(E); set SymmetricProperty and
ReflexiveProperty for the object property role; With the relationship 1:1,
add the maximum cardinality restriction by 1; With the minimum
cardinality constraint being 1-1, add minimum cardinality restriction by 1 to
this object property.

2.3.5 The symmetric recursive relationship with attributes
Rules EER15.

For the symmetric recursive relationship R without

attributes on the entity E: Add the class C(R), the attributes attR of the
relationship is transformed into the datatype properties attR of class C(R);
Add two inverse object properties E_R, R_E representing the relationship
between class C(R) and class C(E). Two properties are reflexive and other
12


characteristics of the relationship R. The object properties R_E has min and
max restriction being 1; Set min/max restriction on the object properties
E_R corresponding with value on role of the min/max cardinality constraint
which is different from 0 and N. If R is the binary relationship N:N, add the
object properties R_E to set of key properties of class C(R).
2.3.6 The asymmetric recursive relationship without attributes
Rules EER16.

Considering the symmetric recursive relationship R without

attributes on the entity type E with two roles are role1 and role2: Add two
object properties role1 and role2, domain and range is class C(E); set
AsymmetricProperty and ReflexiveProperty for the object property role1 and
role2; With the minimum cardinality constraint being 1-1, add the min/max
cardinality restriction by 1 to this object property.
2.3.7 The asymmetric recursive relationship with attributes
Rules EER17.

Considering the asymmetric recursive relationship R with

attribute attR on the entity type E with two roles role1 and role2: Add the
class C(R), attributes attR of the relationship R is transformed into the
datatype properties attR of class C(R). Add two inverse object properties
E_Role1, R_Role1 representing a relationship between class C(R) and C(E)
with roles role1. Add two inverse object properties E_role2, R_role2
representing a relationship between class C(R) and C(E) with roles role2.
Set min/max cardinality restriction for two properties R_role1 and R_role2 to
1; The min/max cardinality restriction of two object properties E_role1 and
E_role2 depending on the cardinality restriction of the roles in the
relationship R. If the relationship R is N-N add two object properties
R_role1, R_role2 to the set of key properties of class C(R).
2.4 Transformation of TimeER into OWL ontology
The TimeER [32] model is one of the most commonly used conceptual
data models with temporal aspects. The temporal aspects of the entities in
the database can be either: the lifespan of an entity (LS); the valid time
(VT); the transaction time (TT). Both the lifespan and the transaction time
13


LT; both the valid time and the transaction time BT (BiTemporal).
2.4.1 Initially ontology for representing the temporal aspect
In OWL, no component has the same meaning as the temporal
components in the TimeER model. To support the presentation of temporal
aspects in OWL, we need to create an additional class InstantDateTime and
object properties that represent the relationship between the class owl:Thing
class and the class InstantDateTime. Create class InstantDateTime
representing for a timeline. In this class, create the functional datatype
property hasDateTime with minimum cardinality restriction set to 1. This

property range is xsd:dateTime and it is the key property of a class
InstantDateTime.
Create six functional object properties with minimum cardinality
restriction set to one: hasVTs, hasVTe, hasLSs, hasLSe, hasTTs, hasTTe;
range set to class InstantDateTime and domain set to the class owl:Thing.
Six properties represent the relationships between class owl:Thing and class
InstantDateTime.
2.4.2 Transformation of temporal entity type
Rules EER18.

Each temporal aspect XX of the entity type E (XX can be

LS, LT, TT): Add the class C(E_XX) representing temporal aspect XX of the
entity type E; Add two inverse object properties: E_has_XX with domain is
class C(E) and range is class C(E_XX); XX_of_E with domain is class
C(E_XX) and range is class C(E), simultaneously XX_of_E has functional
characteristics and minimum cardinality restriction is 1. Set of key
properties of class C(E_XX) include properties XX_of_E and some
properties for representing the temporal restriction which depends on
temporal aspect XX as in Table 2.3.
Table 2.3 Key attributes corresponding to the temporal aspect
The temporal aspect

Key attributes

VT

hasVTs

LS

hasLSs
14


2.4.3

TT

hasTTs

LT

hasLSs, hasLSe, hasTTs

BT

hasVTs, hasVTe, hasTTs

Transformation of the temporal attributes of the entity type

Rules EER19.

Each attribute attA has the temporal aspect XX of the entity

type E: Create class C(attA_XX), transform attribute attA to the datatype
properties of class C(attA_XX); Create two inverse object properties:
attA_has_XX with domain is class C(E) and range is class C(attA_XX),
XX_of_attA with domain is class C(attA_XX) and range is class C(E),
XX_of_attA has functional characteristics and minimum cardinality

restriction is 1. Set of the key properties of class C(attA_XX) includes
property XX_of_attA and some properties which represent the temporal
restriction depend on the temporal aspect XX as shown in Table 2.3.
2.4.4 Transformation of the temporal relationship
Rules EER20.

Each relationship R has the temporal aspect XX among the

entities Ei: Create class C(R), the non-temporal attributes of the relationship
R was transformed into the datatype properties of class C(R);
Corresponding to each entity type Ei in the relationship R, create two
inverse datatype properties for representing the relationship between class
C(R) and C(Ei): Ei_has_R with domain is class C(Ei) and range is class
C(R); R_of_Ei with domain is class C(R), and range is class C(Ei), set
functional characteristics and minimum cardinality restriction is 1. If
min/max cardinality constraint of the entity Ei different from 0 and N then
add the min/max cardinality restriction corresponding to property Ei_has_R;
If R is the 1-1 binary or recursive relationship then key of class C(R)
consists of one of the two newly added whose range is the class
corresponding with the entity in relationship R and some properties
representing for the temporal restriction depend on the temporal aspects XX
as shown in Table 2.3. In contrast, the key of class C(R) includes newly
added feature attributes of which range is the class corresponding to the N15


side entity type and some properties representing for the temporal
restriction depend on the temporal aspects XX as shown in Table 2.3.
2.4.5 Transformation of the temporal attribute of the relationship
Rules EER21.

Each attribute attR has the temporal aspect XX of the

relationship R: Add class C(attR_XX), the attribute attR transformed into
the datatype property of class C(attR_XX); Add two inverse object
properties that represent the relationship between class C(R) and
C(attR_XX): attR_has_XX with domain being class C(R) and range being
class C(attR_XX); XX_of_attR with domain being class C(attR_XX) and
range being class C(R), and has functional characteristics. Minimum
cardinality restriction of two properties is set to 1; Key of class C(attR_XX)
consists of the properties XX_of_attR and some properties which represent
the temporal restrictions depend on the temporal aspect XX as shown in
Table 2.3.
2.5 Experimental results
The thesis has experimented on two sample data models, the CitationEnhanced Bibliographic Database [33] and the Elmasri model [2]. The
thesis transforms to OWL and calculates the accuracy [34] after
transforming between the method proposed and previous proposals, such as
S.R Upadhyaya [6], M. Fahad [7], I. Myroshnichenko [8], Pasapitch Chujai
[10].
Figure 2.27 Comparison of transformation performance on citationenhanced bibliographic database
With the citation-enhanced bibliographic database [15], the proposed
methods [6], [7], [8], [10] transform most of the cases, because this model
does not contain components indicated in Section 2.3. But with Elmasri
model [2] with more general cases, the methods [6], [7], [8], [10] cannot
transform. From the experimental results of the transformation methods, it
has proved the completeness of the proposed method for the problem of
transformating the extended ER model to OWL.
16


Figure 2.18 Comparison of transformation performance on Elmasri model

2.6 Summary of Chapter 2
In this chapter, the thesis introduces the method of transforming the
extended ER model to OWL. The thesis has added transformation rules: the
weak entity and identifying relationship; the nested multi-valued composite
attributes; recursive relationship; temporal aspect on the TimeER model. In
which, related to the recursive relationship, the thesis has classified and
propose transformation for these cases. Based on those transformation rules,
the thesis also proposed a method to convert TimeER model to OWL [CT1]
[CT3] [CT4].

17


CHAPTER 3.
TRANSFORMATION OF UML CLASS DIAGRAM INTO OWL
ONTOLOGY
3.1 Previous researches
3.2 Additional transformation rules
3.2.1

Transformation of structure attribute
The author [22] proposes to transform the structure attribute to a new
class and link by an object property. However, datatype properties in OWL
do support hierarchies, so transforming structured attributes to sub datatype
properties will represent more context, and it is no need to create new
classes or properties.

Rule UML10.

The structure attribute attU of class U which has the set of

sub attributes sub_attU is transformed into datatype property DP(attU) in
class C(U). The sub attribute sub_attU will transform into sub datatype
properties DP(sub_attU) of the datatype property DP(attU). The
DP(sub_attU)’s domain is DP(attU) and range is corresponding with data
type in OWL.
3.2.2

Transformation of the rescursive association
The author [22] has proposed a rule to transform the rescursive
association, however, the rescursive association has not been classified, so
the transformation has not properly reflected the nature of this association.
Checking the role allows us to classify all of the rescursive association:
symmetric or asymmetric.

Rule UML11.

Let consider the symmetric recursive association of class A

with role role: Add the object property with its name which is the name of
role, domain and range which is class C(A), set ReflexiveProperty for this
object property; If the cardinality constraint is 1-1, add the maximum
cardinality restriction by 1; With the minimum cardinality constraint being
1-1 add minimum cardinality restriction by 1 to this object property.

18


Rule UML12.

Considering the asymmetric recursive association of the

class A with two roles role1 and role2: Add a pair of inverse object
properties with their name being role1 and role2, domain and range being
class C(E); The cardinality constraint on the asymmetric recursive
association will converse the position between two classes when
transforming into OWL. For each role with min/max cardinality constraint
different 0 and N, add the min/max cardinality restriction corresponding to
the object properties.
3.2.3

Transformation of shared aggregation

The aggregation is a special kind of association between classes that
specifies that every instance of a given class (of parts) can be a part of
at most one whole. With that property, we come across with the following
findings:
-

Aggregation is an association between classes that are not symmetric, so
when transformating, you must set up the asymmetric with the
AsymmetricProperty axiom.

-

Aggregation is not reflexive, that is, a class has no aggregation to itself, so
when transforming, it must set up non-reflexivity with IrReflexiveProperty
axiom. This prevents instances from being related to itself by an object
property that represents an aggregation.

Rule UML13.

Let consider the shared aggregation class A associated with

component class F: Add class C(A) and C(F); Add two object properties for
representing the relationship between class C(A) and C(F): A_F with
domain is C(A), range is C(F); F_A with domain is C(F), range is C(A); Set
IrReflexiveProperty and AsymmetricProperty axiom for the object attribute
F_A. The cardinality constraint on the share aggregation will change the
position between two classes when transforming into OWL;
3.2.4 Transformation of the qualified aggregation
Rule UML14.
Let consider the aggregation with a qualify Q between the
whole class A and the component class F: the qualify Q is transformated to
a datatype property Q in class C(F), of which domain is class C(F) and the
19


range is the corresponding data type in OWL; Add two inverse object
properties which show relationship between class C(A) and C(F): A_F with
domain being C(A), range being C(F); F_A with domain being C(F), range
being C(E) and maxQualifiedCardinality cardinality restriction being 1. The
keys of class C(F) includes the datatype attribute Q and object property
F_A; The cardinality constraint on UML will change position between two
classes when transforming into OWL;
3.3 Experimental results
The thesis evaluates the proposed transformation rules by applying the
transformation method on two UML class diagrams, the Purchase Order
Application model [35] and Elmasri [2], then determines the output and
compare this result with previous methods.

Figure 3.13 Comparison of transformation performance on UML class
diagram Purchase Order Application
Figure 3.14 Comparison of transformation performance on UML class
diagram Elmasri
The thesis uses precision evaluation measure [34] after transforming the
thesis’s method proposed and previous proposals, such as S.Brockmans
[13], Noreddine Gherabi [16], Imnas Zarembo [18], Jesper Zedlitz [ 19]
[20] [21], Oussama [22]. The comparative data from Figures 3.13 and 3.14
show that the proposed conversion method is incomplete, but in which the
proposed thesis method is higher than that of other methods.
3.4 Summary of Chapter 3
Inheriting previous researches, the thesis has analyzed and proposed
additional transformation rules, as follow: Transformation of structure
attribute; Transformation of the rescursive association; Transformation of
shared aggregation; Transformation of the qualified aggregation. The
completeness of the proposed method is clearly shown through the
experimental results presented at the end of chapter [CT2] [CT7].
CHAPTER 4.
20


EXTRACTING A CONCEPTUAL DATA MODEL FROM OWL
ONTOLOGY
Extracting a conceptual data model from a given OWL ontology is
regarded as defining a backward mapping of the transformation from
conceptual data model to OWL ontology. Accordingly, the input and output
of this problem are determined as follows:
-

Input: OWL ontology.

-

Output: a conceptual data model.
The rules for identifying components of the output are made according
to the following general: Construct a condition to identify components so
that the "forward transformation" algorithm for this component is satisfied,
but not satisfied for the remaining components. This allows proving the
correctness of the rules by the exclusion method.
4.1 Extracting EER model from OWL
4.1.1

Previous researches

4.1.2

Additional extraction rules

4.1.2.1 Extracting composite attribute
In OWL, a rdfs:subPropertyOf axiom defines that the property is a
subproperty of some other property.
Rule OWL7.

The subproperty sub_dpC is defined with the structure

<rdfs:subPropertyOf rdf:resource="# sub_dpC" />, of which domain is
datatype property dpC and the range is the primitive data type, then
extracted to the subproperty sub_dpC of the composite attribute dpC.
4.1.2.2 Extracting the recursive relationship
Rule OWL8.

The object property OP with ReflexiveProperty of which

domain and scope are class C, then extract to the recursive relationship
without properties of the entity type E(C). If object property OP have
SymmetricProperty then extract to the symmetric recursive relationship of
the entity type E(C). The role name of recursive relationship is the name of
the object property, cardinality constraint’s recursive relationship depends
on minQualifiedCardinality and maxQualifiedCardinality.
21


Rule OWL9.

For every inverse object properties role1 and role2 with

ReflexiveProperty and AsymmetricProperty of which domain and range are
class C, then extract to the asymmetric recursive relationship of the entity
type E(C), two roles of recursive relationship are the name of those object
properties. The cardinality constraint’s recursive relationship depends on
minQualifiedCardinality và maxQualifiedCardinality of role1 and role2,
respectively.
4.1.2.3 Extracting n-ary relationship
Rule OWL10.

For every class C with two inverse object properties OP,

domain is class C, set of key attributes of class C includes object properties
with domain being class C and minQualifiedCardinality being 1, then
extract to 1:1 n-ary relationship. Depending on the minQualifiedCardinality

and maxQualifiedCardinality of the OP's inverse object properties that set
the cardinality constraint’s n-ary relationship.
In summary, the rules for extracting components of an EER model from
an OWL2 can be represented by the diagram as follows.

Figure 3.2. Cases extracted into EER model

22


4.1.3

Example

Figure 3.3 Extracted EER model
To illustrate the extraction method, the thesis is experimental on the
sample Library ontology [36], the results of the EER model are shown in
Figure 3.3.
4.2 Extracting UML class diagram from OWL
The extraction of an UML class diagram from a given OWL is regarded
as defining an inverse mapping of the transformation from UML class
diagram to OWL ontology. The thesis inherits the analysis of similarities
between UML class diagram with OWL to perform extracting OWL to
UML class diagram. The thesis analyzes on both OWL1 and OWL2
structures to generalize the transformation rules.
4.2.1

Extracting class

Rule OWL1.

A class

or

subclass

C

declared

by

owl:class

or

rdfs:subClassOf axiom will convert to a class U(C) in UML class diagram.

23


4.2.2

Extracting attribute

Rule OWL2.

The datatype property dpC of which domain is class C and

range is the primitive data type in OWL is extracted to attribute U(dpC) of
calss U(C), which has the corresponding data type in UML.
4.2.2.1 Extracting the key attribute
Rule OWL3.

The datatype property keyC with owl:hasKey axiom, of

which domain is class C and range is the primitive data type in OWL, that
is declared by owl:hasKey, is extracted to attribute U(keyC) of class U(C),
which has the corresponding data type in UML and label OCL is “unique” .
4.2.2.2 Extracting the structure attribute
Rule OWL4.

For every datatype property sub_dpC that is declared by

<rdfs: subPropertyOf rdf:resource=“#dpC"/>, and the range is the
primitive data type, then extract to the subproperty of datatype property
dpC with a range is the corresponding data type in OWL.
4.2.3

Extracting the relationship

In OWL, object properties are used to represent relationships between
classes, which is equivalent to association in UML class diagrams.
4.2.3.1 Extracting the association
An object property in OWL can be extracted to a one-way association. If
there are two object properties that have opposite properties between the
two classes, that is the instance of each direction in the two-way
associative. Specifies the number of objects that can participate in each end
of

the

relationship

by

the

minQualifiedCardinality

and

maxQualifiedCardinality constraints of two inverse object properties.
Rule OWL5.

For every object property OP between two classes C1 and C2

with inverse object properties OP (if any) is extracted to the association
R(OP) between two classes U(C1) and U(C2). The cardinality constraint of
R(OP) depends on minQualifiedCardinality và maxQualifiedCardinality of
the OP, but change position between two classes when extracting to UML.
4.2.3.2 Extracting the recursive association
In order to determine whether a recursive association is symmetric in
24


OWL, it is possible to depend on the object property that have
ReflexiveProperty and AsymmetricProperty construct.
Rule OWL6.

For every object property OP of which domain and range is

class C, with ReflexiveProperty construct will extract to the recursive
association U(C). If object property OP is declared SymmetricProperty
construct, then extract to symmetric recursive association U(C). The role
name of recursive association is the name of the object property, cardinality
constraint’s recursive association depends on minQualifiedCardinality và
maxQualifiedCardinality in this object property.
In order to determine whether a recursive association is asymmetric or
not, it is essential that the domain of two object properties must be on a
class, and those two object properties must have the ReflexiveProperty and
AsymmetricProperty construct.
Rule OWL7.

For every pair of inverse object properties role1 and role2 of

which domain and scope are both class C, with ReflexiveProperty and
AsymmetricProperty construct, will extract to the symmetric recursive
association of class U(C), two roles of recursive association are the name of
two object properties. The cardinality constraint’s recursive relationship
depends on minQualifiedCardinality và maxQualifiedCardinality of role1
and role2, respectively.
4.2.3.3 Extracting the generalization/specialization
Rule OWL8.

Extract

the

class–subclass

structure

in

OWL

to

generalization/specialization in UML, show as Table 3.3.
Table 3.3 Generalization/Specialization extraction cases
Generalization/
The class–subclass structure in OWL
Specialization
owl:disjointClasses or owl:complementOf
disjoint
owl:equivalentClass and owl:ObjectUnionOf
complement
disjoint
and
owl:disjointUnionOf
complete

25