TSINGHUA SCIENCE AND TECHNOLOGY ISSNll1007-0214ll13/14llpp716-723 Volume 15, Number 6, December 2010

 

Automatic Approach to Ontology Evolution Based on Change Impact Comparisons*

DONG Gan (董 干), GAO Zhipeng (高志鹏), QIU Xuesong (邱雪松)**

State Key Laboratory of Networking and Switching Technologies, Beijing University of Posts and Telecommunications, Beijing 100876, China

Abstract: Ontology evolution is the timely adaptation of ontologies to changing requirements, which is be-

coming more and more important as ontologies become widely used in different fields. This paper shows

how to address the problem of evolving ontologies with less manual case-based reasoning using an auto-

matic selection mechanism. An automatic ontology evolution strategy selection framework is presented that

automates the evolution. A minimal change impact algorithm is also developed for the framework. The

method is shown to be effective in a case study.

Key words: ontology; ontology evolution; automatic ontology evolution strategy selection (AOESS); minimal

change impact

Introduction

Ontology evolution has been identified as a six-phase evolutionary process[1]. Of the six phases, the seman-tics of the change phase is the key phase of the evolu-tion. Many researchers have studied the semantics of change, and have proposed many approaches. However, most rely on human participation during the ontology evolution, so the ontology engineers must be both do-main and ontology experts and there are many errors due to the complicated ontology structure. Therefore, the process needs to be automated to improve the speed and accuracy of the evolution process.

This paper describes an automatic ontology evolu-tion strategy selection (AOESS) framework which uses automatic selection to model the evolution process. The algorithm for the automatic selecting is presented

as well as applications to the AOESS framework.

1 State-of-the-Art

The initial ontology evolution research was related to object-oriented database schema evolution and ver-sioning research[2-4]. Noy and Klein[5] studied the dif-ferences and similarities between ontology evolution and schema evolution and the effect of differences between ontologies and database schemas. They ar-gued that, in theory, many issues in ontology evolution are exactly the same as issues in schema evolution.

Stojanovic et al.[1] proposed an approach to handle ontology evolution. They identified the six phases of ontology evolution which are now widely accepted. They proposed a method using evolution strategies which needed ontology engineers to either directly or indirectly select side-effects of the changes. This ap-proach was applied in KAON and OntoStudio (for-merly OntoEdit).

Haase and Stojanovic[6] also used the concept of resolution strategies based on the constraints of OWL-Lite for the detection and resolution of inconsis-tencies in OWL ontologies. However, the resolution of

Received: 2010-09-16; revised: 2010-09-25

* Supported by the National Key Basic Research and Development(973) Program of China (No. 2007CB310605), the National NaturalScience Foundation of China (Nos. 60802035 and 60902050), andFunds for Creative Research Groups of China (No. 60821001)

** To whom correspondence should be addressed. E-mail: xsqiu@bupt.edu.cn; Tel: 86-10-62283119

DONG Gan (董 干) et al.：Automatic Approach to Ontology Evolution Based on … 717

inconsistencies still need an ontologist to choose the most suitable solutions.

An alternative approach that is gaining acceptance uses belief change[7] techniques to manage the ontol-ogy evolution. Flouris and Plexousakis[8] presented some ideas for this research approach. Then Konstan-tinidis et al.[9] proposed a specific ontology evolution algorithm using belief change for RDF/S ontologies.

There have been many tools used for ontology evo-lution. Some of these tools are simply ontology editors, like Protégé[10], which is one of the most popular tools for ontology design and creation but is often used for ontology evolution and management. The functionality of Protégé has now been enhanced[11] to better support ontology evolution. However, Protégé has only one built-in evolution strategy even though there are sev-eral ways to correct the inconsistencies after a change. Another ontology editor often used for ontology evolu-tion is OilEd. It is rather restrictive in the sense that it disallows any change that would cause some inconsis-tency in the ontology, so it supports less update opera-tions than Protégé. KAON and OntoStudio are exam-ples of more specialized ontology evolution tools, where the user can set pre-defined evolution strategies that control how side-effects will be determined, thus allowing the tool to perform some changes automati-cally. OntoStudio provides more options for parame-terization, but uses a more restricted model and sup-ports fewer operations than KAON. Unfortunately, they both still need an ontology engineer to pre-define all the strategies or to manually choose the strategy when encountering an evolution strategy decision point.

2 AOESS Framework 2.1 Background and related definitions

A more general definition of ontology is given that can apply to most scenarios regardless of the language used to express the ontologies.

Definition 1 A structural ontology model is a 6-tuple:

: ( , , , , , ),c pO C P H H I K=

where C is a set of concepts; P is a set of properties which can be subdivided into relations, R, and attrib-utes, A, where relations mean the properties between

concepts, and attributes mean the properties between

concepts and literal values; cH C C⊆ × is an acyclic relation called the concept hierarchy which describes the inheritance relations of the concepts; similarly

pH P P⊆ × is an acyclic relation called the property hierarchy which describes the inheritance relation of properties; I is a set of instances; and K is a set of on-tological axioms and constraints which specify the in-tended interpretation of the defined terms in a given domain and the rules ontology must observe.

An example ontology is shown in Fig. 1. The ontol-ogy model illustrates a book ontology, which contains the concepts such as “Essay”, “Author”, and a set of properties between them (e.g., “translate”, “hasNation-ality”, etc.).

Fig. 1 An ontology with its instance

The concepts and properties are arranged in a hier-archy, for example, “Translator” is a child of the con-cept “Person”. Instances of the ontology concepts are shown in the dashed ellipse as well as properties be-tween the concepts. For example, “War and Peace” is an instance of the concept “Novel”. Similarly, “Leo Tolstoy” is an instance of “Author”, which is the do-main of property “writes” related to “War and Peace”. Note that the concept “Person” has two attributes “hasNationality” and “hasGender” with no property range, while the instance “Leo Tolstoy” has the two attributes with range “Russian” and “Male” respectively.

The logical integrity of the ontology is based on the ontology consistency concept. The ontology consis-tency is defined in terms of the consistency conditions that the ontology must satisfy that guarantee that none of the facts deducible from the consistency model mu-tually contradict so that the ontology and related ap-plications are secure. For simplicity, this analysis only considers evolution of a single ontology with the

Tsinghua Science and Technology, December 2010, 15(6): 716-723

 

718

ontology consistency for a single ontology defined as[12]:

Definition 2 Ontology, O, is consistent with re-spect to a set of consistency constrains, K, if and only if for all ,k K∈ O satisfies the constraint k(O) de-fined for the underlying ontology model.

The list of general constraints, GK has been defined as invariants[12]. However, several additional con-straints are added to the ontology model here:

GK1 Property hierarchy invariants The property hierarchy is a directed acyclic graph:

*/ , ( , ) .pp P p p H∃ ∈ ∈

GK2 Domain and range invariants A relation must have a domain concept and a range

concept. An attribute must have a domain concept but must not have a range concept:

1 1

2 2

( , domain( ))( , range( )),

p R c C c pc C c p

∀ ∈ ∃ ∈ ∈∃ ∈ ∈

∧

1 1

2 2

( , domain( ))( / , range( )).

p A c C c pc C c p

∀ ∈ ∃ ∈ ∈∃ ∈ ∈

∧

GK3 Subproperty domain and range invariants The domain (range) of a property is a subset of its

ancestor’s domain (range): *

1 2 1 2, , ( , ) pp P p P p p H∀ ∈ ∀ ∈ ∈ ⇒

1 2 1 2(domain( ) domain( )) (range( ) range( )).p p p p⊆ ⊆∧ Since ontology evolution is realized by applying

ontology changes, a possible set of changes has to be defined. A definition of these changes is given as: An ontology change, Ch, is a total mapping between on-tologies, i.e., O′ = Ch(O), where O is the ontology be-fore the change and O′ is afterwards. A formal, detailed structural representation of the ontology change is used here:

Definition 3 An ontology change Ch is a 4-tuple: Ch:= (name, args, preconditions, postconditions),

where the name is the change identifier, args is a list of one or more change arguments, preconditions comprise a set of assertions that must be true to be able to apply the change, and postconditions comprise a set of asser-tions that must be true after applying a change.

The change notation is simplified in the rest of this paper by the following simplified syntax: name(args, preconditions, postconditions). Moreover, name(args) is a simplified form used to denote a change when no confusion results, e.g., RemoveConcept(C). Stojano-vic[12] gave more details concerning the ontology

change definition. With this definition, the ontology, O′, after change,

Ch, may not be consistent. Another key ontology evo-lution concept is used to resolve inconsistencies:

Definition 4 Given an ontology, O, and a request for a change, Ch, the ontology evolution is the process defined as:

1 2 1OE( ,Ch) Ch (Ch ( (Ch (Ch( ))))) ,n nO O O− − ′= = where O is a consistent ontology; Ch is a requested change that can be applied to O; O1 = Ch(O) is an in-termediate ontology state which is inconsistent after the application of Ch, similarly Oi =

Chi−1(Oi−1) is an intermediate state after the application of Chi−1, where

(1, )i n∈ and Chi is a derived change; 1 1Ch ( )n nO O− −′= is a consistent ontology, which is the final evolution result of the evolution OE(O, Ch).

2.2 Evolution process

The six-phase ontology evolution process presented by Stojanovic et al.[1] is widely accepted in the literature. This work considers the evolution of a single ontology. The process is simplified to a three-phase process for this ontology evolution model. Figure 2 illustrates the evolution process.

Fig. 2 Ontology evolution process

The ontology evolution process starts with an old ontology with requests for changes captured and rep-resented formally and explicitly as one or more ontol-ogy change in the capturing phase. If the requested change is a complex change, it will be decomposed into a sequence of elementary changes each sent to the next phase in the sequence. Then the resolution phase prevents inconsistencies by computing additional changes that guarantee the transition of the ontology into another consistent state. The implementation phase applied all the required and derived changes to the ontology and related instances. This phase includes validation of the realized changes, which may uncover further problems and induce new changes to obtain

DONG Gan (董 干) et al.：Automatic Approach to Ontology Evolution Based on … 719

model consistency or to satisfy the user expectations. Thus the process model is cyclical.

Of the three phases, the resolution phase is the most crucial step which determines the direct and indirect changes caused by a given change request. This is not easy, because a change may cause other changes, which will cause additional changes throughout the ontology. A more complex ontology will result in a very complicated process. In addition, there may be several ways to resolve a change, since a change may cause different combinations of changes which all sat-isfy the consistency requirements. The user needs to choose which changes are needed in this situation, or pre-define them (evolution strategies) in the system. To reduce human involvement in the evolution process, Section 3 will describe an automatic approach to select the strategies using a minimal change impact algorithm.

This evolution process is implemented in the evolu-tion framework AOESS as an automatic evolution strategy selection process.

2.3 AOESS framework

The architecture of the AOESS is shown in Fig. 3. This system consists of capture, resolution, and implemen-tation components, which correspond to the three phases of the evolution process.

Fig. 3 AOESS framework

The capture module receives the change request from the user or captures the need of changes from the ontology structure due to existing inconsistencies. The captured change requirements lead to formal change representations that are passed to the next module in the queue.

The resolution module consists of dependence analysis and decision making components. When a change request arrives at the resolution module, it first enters the dependence analysis component, where all possible combinations of directly derived changes are identified based on the ontology structure and con-straints are defined. Then, only one decision is made at each decision point by the decision making module. The two modules recursively process the derived changes until no more additional changes are needed according to the algorithm introduced in Section 3. Then, an evolution strategy containing each decision at each decision point is created. The evolution strategy is formally defined as:

Definition 5 Given an ontology, O, and a request for a change, Ch, an evolution strategy Es is a 3-tuple:

1 2Es : ( , Ch, , , , ),nO d d d= ⟨ ⟩ where n denotes the number of decision points made during the evolution process and di is the change deci-sion made at each sequential decision point, where i∈[1, n]. Each di is related to a Chi, which is a change that must be applied if decision di is made. The appli-cation of Chj leads to an inconsistent ontology where n > 1 and [1, 1]j n∈ − , while application of Chn leads to an consistent ontology.

Finally, the requested change and derived changes in the form of the evolution strategy are sent to the im-plementation module, where all these changes are ap-plied to the ontology.

Notice that the ontology state after the implementa-tion should theoretically be consistent; however, in practice there may be new inconsistencies due to lack of synchronization of the ontology structure and the changing constraints. Thus, the inconsistencies must be captured again, which may lead to another evolution process.

3 Approach and Algorithm

As seen in Fig. 3, the evolution strategy selection is a crucial step in the ontology evolution process. Strate-gies selected in real time by an ontology engineer best meet the user’s needs. However, manual case-based reasoning is very tedious, error-prone and gives no formal guarantee that the cases and options considered are exhaustive, especially when the ontology is very large and complicated. Approaches that select the strategies before the evolution process as arguments

Tsinghua Science and Technology, December 2010, 15(6): 716-723 720

are semi-automatic, which makes the process smoother and reduces human involvement. However, the selec-tion mechanisms cannot guarantee that the selections made for different operations exhibit a faithful overall behavior[9], thus it is not flexible. This section de-scribes a completely automatic selection using a mini-mal change impact (MCI) algorithm.

Consider the problem shown in Fig. 4. Figure 4a shows a simple ontology structure, where A, B, C, D, E, and F are concepts, R is a property whose domain is B and range is D, S is a property whose domain is F and range is E. Consider the scenario that concept D is to be removed, i.e., change RemoveConcept(D) is re-quested. First the dependence analysis module of the algorithm analyzes the dependence of the required change. Directly deleting concept D will leave sub-concept F with no parent and property R with no range, which are inconsistencies. Thus, the dependent changes should be changes related to subconcept F and prop-erty R. These additional dependent change combina-tions could be regarded as different evolution strategies. Figure 4b shows one strategy that deletes all concepts and properties related to the concept requested to be removed, with RemoveProperty(R), RemoveConcept(F), and RemoveProperty(S) requested as additional changes. Figure 4c shows a strategy that preserves the subcon-cept of the concept to be removed, connects it to its parent concept, and propagates its properties if neces-sary, with Change-ParentOf(F, D, C) and SetRange(R,

F) as the additional changes. The strategy shown in Fig. 4d preserves the subconcept and reconnects it to the root, i.e., ChangeParentOf(F, D, A) and Se-tRange(R, F). In this example, the directly derived changes do not require new changes; however, in prac-tice ontologies can be much more complicated and the changes may be quite different.

Fig. 4 Ontology example and 3 different results after ap-plication of three evolution strategies to remove concept D

This example shows that there are two key problems to be solved: (1) how to determine the dependent changes and whether applying a change requires a de-cision point and (2) how to choose the decisions at each decision point.

For the first problem, the system defines all elemen-tary changes, all possible directly derived changes of

each elementary change (see Table 1) and all decision options for different scenarios (see Table 2) inferred from the constraints listed in Section 2. These two

Table 1 Elementary changes and directly derived changes of each change

No. Elementary change Description Possible directly derived

number of changes Impact factor

1 AddConcept(C, C0) Add concept C as a subconcept of concept C0 3 2 2 RemoveConcept(C) Remove concept C 2, 5, 7, 11, 12, 14, 15 4 3 AddParentOf(C, C0) Add an inheritance relation from concept C to C0 5 1 4 RemoveParentOf(C, C0) Remove the inheritance relation from concept C to C0 2, 3 1 5 ChangeParentOf(C, C0, C1) Change parent of concept C from C0 to C1 5 1

6 AddProperty(P, P0, C1, C2)Add property P, set property P0 as parent, C1 as domain, and C2 as range 8, 11, 12 1.5

7 RemoveProperty(P) Remove property P 7, 10 2 8 AddParentOf(P, P0) Add an inheritance relation from property P to P0 10 1 9 RemoveParentOf(P, P0) Remove the inheritance relation from property P to P0 1 10 ChangeParentOf(P, P0, P1) Change parent of property P from P0 to P1 10 1 11 SetDomain(P, C1) Set concept C1 as domain of property P 9 1 12 SetRange(P, C2) Set concept C2 as range of property P 9 1 13 AddInstance(I, C) Add I as an instance of concept C 15 1.5 14 RemoveInstance(I) Remove instance I 2

15 SetInstanceOf(I, C) Set I as an instance of concept C and remove it from the former concept 1

DONG Gan (董 干) et al.：Automatic Approach to Ontology Evolution Based on … 721

tables do not cover all the changes, but all changes can always be defined as series of elementary changes[13]. The elementary changes listed in Tables 1 and 2 in-clude all possible elementary changes as far as we know. These can be referenced to resolve dependency problems. Consider Ch as the requested elementary change. First, Table 2 is searched for Ch. If Ch does not exist in Table 2, Ch can be applied directly to the ontology with no inconsistencies; otherwise, the

dependency analysis module determines which situa-tion combination in Table 2 describes the ontology related to Ch. Each situation combination is a decision point with several decision combinations correspond-ing to different directly derived changes, each of which will be applied recursively in the algorithm until no more derived changes occur. Then, each decision se-quence that contains a set of derived changes is gener-ated as the evolution strategies for change Ch.

Table 2 Dependency rules

No. Context change Situation Decision 1 AddConcept(C, C0) Concept C is added as a subconcept of C0. Add concept C0 as a parent of C.

Orphaned concept is deleted. Orphaned concept is reconnected to parent of C. Subconcept of C becomes orphaned. Orphaned concept is reconnected to the root concept. Orphaned property is deleted. Property of C becomes no domain or no

range. Orphaned property is reconnected to subconcepts of C. Orphaned instance is deleted.

2 RemoveConcept(C)

Instance of C becomes orphaned. Orphaned instance is reconnected to parent of C.

3 AddParentOf(C, C0) A cycle is induced in the concept hierarchy because C used to be an ancestor of C0.

Remove the inheritance relation from each subconcept of C to C, and reattach to the original parent of C. Orphaned concept is deleted. Orphaned concept is reconnected to parent of C0. 4

RemoveParentOf(C, C0)

Concept C becomes orphaned. Orphaned concept is reconnected to the root concept.

5 ChangeParentOf(C, C0, C1)

A cycle is induced in the concept hierarchy because C used to be an ancestor of C0.

Remove the inheritance relation from each subconcept of C to C, and reattach to C0.

6 AddProperty(P, P0, C1, C2)

Property P is added as a subproperty of P0 with C1 as domain, C2 as range.

Add property P0 as parent of P, then set C1 as domain and C2 as range. Remove the subproperty. Reconnect the subproperty to the parent of P. 7 RemoveProperty(P) Subproperty of P becomes no parent. The subproperty is left alone.

8 AddParentOf(P, P0) A cycle is induced in the property hierarchy because P used to be an ancestor of P0.

Remove the inheritance relation from each subproperty of P to P, and reattach to the original parent of P.

9 ChangeParentOf(P, P0, P1)

A cycle is induced in the property hierarchy because P used to be an ancestor of P0.

Remove the inheritance relation from each subproperty of P to P, and reattach to P0.

10 SetDomain(P, C1) Domain of P is no longer included in the domain set of P’s ancestors.

Remove the inheritance relation from P to its parent.

11 SetRange(P, C2) Range of P is no longer included in the range set of P’s ancestor.

Remove the inheritance relation from P to its parent.

12 AddInstance(I, C) I is already an instance of another concept C1. Reset I as an instance of concept C.

The second problem of choosing the decisions at each decision point is solved using a minimal change based algorithm inspired by the belief revision litera-ture[7]. Like a database, the ontology is usually not an-ticipated to change too much, so the loss of informa-tion can be small. Hence, changes need to be made to

an ontology so the system seeks to make minimal changes while maintaining the consistency. However, different changes have different impacts on the ontol-ogy information. For example, removal of a concept has a more significant impact on the ontology knowl-edge system than adding a property. Therefore the

Tsinghua Science and Technology, December 2010, 15(6): 716-723 722

impact of different changes is quantified by an impact factor, denoted as fchangeName, which is a number repre-senting the level of impact of a change and equal the amount of the average derived changes of this specific type of change in number. Table 1 lists the impact fac-tor of each elementary change with higher impact fac-tors having more effect than lower ones. These do not need to be exactly the same as listed in the tables, but can be adjusted according to the ontology structure. The following notion is introduced to represent the impact:

Definition 6 Impact(Es) is an index of the impact of applying evolution strategy Es to the ontology de-fined as follows:

Ch Ch1Impact(Es) ,

i i

m

in f

== ∑ ∙

where each Chi is an elementary change type that must be performed in evolution strategy Es, 1, ,i m= (see Table 1, m is currently equal to 15), Chi

n denotes

the number of change types Chi , and Chif denotes the

impact factor of change type Chi. The MCI algorithm is then used for the decision

making. When a decision is to be selected from several decision options, the decision making module com-putes the impact of each strategy starting with each decision, and then chooses the minimum impact.

Analysis of impact of a single change in a decision option with selection of the smallest one may not en-sure that the chosen decision has the smallest impact on the entire ontology, because smaller impact changes may result in a larger total impact. Thus, the algorithm calls itself recursively at each decision point until deci-sion changes no longer cause other changes.

The algorithm pseudo code shown in Table 3 solves the two problems using the minimal change method. Due to the space limitation, the details of procedure ComputeImpactOf() in Table 3 are omitted.

Table 3 The minimal change impact algorithm for resolution process

Algorithm Dependency analysis

Input: Ontology O, DependencyRules R, RequestedChange Ch Output: ChangeList

1 ChangeList – change that has been identified, initialized to NULL before running the algorithm 2 Ostate – current ontology state, initialized to O before running the algorithm 3 if Ch does not exist in R then 4 append Ch to ChangeList 5 Ostate = Ch(O) 6 return ChangeList 7 else 8 SituationSet – a set that contains situations caused by applying Ch according to R (see Table 2) 9 Ostate = Ch(Ostate)

10 foreach situation in SituationSet do 11 foreach decision in situation decision options do 12 ComputeImpactOf(Ostate, Ch) 13 end 14 Choose the smallest impact decision MinImpactDecision 15 ChOfDecision – change that MinImpactDecision needs 16 append ChOfDecision to ChangeList 17 Ostate = ChOfDecision(Ostate) 18 DependencyAnalyzing(Ostate, R, ChOfDecision) 19 end 20 end

4 Case Study

The Wine ontology is used here to validate this ap-proach. Wine is a demonstration ontology project in-cluded in Protégé and originally created by W3C, which describes wines, foods, wineries, and their rela-tionships. The details of the ontology structure are

given in the example description in Protégé. An additional program was developed to simulate

the algorithm result using manual decisions or random decisions at decision points to simulate manual deci-sions. The change requests ‘RemoveConcept (Con-sumable_thing)’ and ‘RemoveParentOf(Wine, Drink)’ were submitted separately to the ontology. Then the decisions were made with the overall impact to the

DONG Gan (董 干) et al.：Automatic Approach to Ontology Evolution Based on … 723

ontology recorded for the automatic and manual ap-proaches with the results listed in Table 4.

Table 4 Experimental results

Automatic Manual A Manual B Change 1 0 / 6 2 / 6 53 / 171 Change 2 0 / 2 1 / 2 28 / 74

“Change 1” and “Change 2” in Table 4 represent ‘RemoveConcept(Consumable_thing)’ and ‘Remove-

ParentOf(Wine, Drink)’. The “Automatic” column represents the results for the automatic selection algo-rithm. “Manual A” represents the results when each decision point had the same decision as the automatic method (the evolution result would be the same as for the automatic method). “Manual B” represents the av-erage result of 10 runs using the manual selection method with each decision randomly selected at each decision point to simulate the manual selection process. The results are listed as the number of human in-volvements for a selection over the overall impact of the change and all its derived changes.

The results show that the automatic approach sig-nificantly reduces the human involvement during the evolution process. The automatic approach also has the lowest impact on the ontology which minimizes the information loss. The random decision method signifi-cantly increased the impact. The manual method (column “Manual A”) can have a similar result to the automatic method if decisions happen to be made in the same way as in the automatic method. However, in practice it is difficult to know how to manually make choices which have minimal impact. Therefore, these tests show the superiority of this automatic method compared to the manual selection strategy.

However, the manual selection strategy provides the best control of the evolution direction, at the expense of efficiency. This method puts more focus on effi-ciency and automation. This example shows that the evolution result of this method is quite reasonable and effective.

5 Conclusions and Future Work

This paper describes an automatic ontology evolution strategy implemented in a framework called AOESS for processing evolutionary ontology changes. An automatic selection strategy developed using the minimal change impact is used for decision making

based on the MCI algorithm. This method eliminates the need for manual case-based reasoning and human involvement which significantly improves automation of the ontology evolution process.

Future work will include improving the controllabil-ity of the evolution result and developing algorithms for the evolution of multiple ontologies. This approach for ontology evolution will also be used for problems in other related fields.

References

[1] Stojanovic L, Maedche A, Motik B, et al. User-driven ontology evolution management. In: EKAW’02. Siguenza, Spain, 2002: 285-300.

[2] Banerjee J, Kim W, Kim H J, et al. Semantics and imple-mentation of schema evolution in object-oriented data-bases. In: Proceedings of the COMAD’87. New York, USA, 1987: 311-322.

[3] Franconi E, Grandi F, Mandreoli F. A semantic approach for schema evolution and versioning in object-oriented da-tabases. In: Proceedings of CL’00. London, UK, 2000: 1048-1062.

[4] Kim W, Chou Hong-Tai. Versions of schema for ob-ject-oriented databases. In: Proceedings of VLDB’88. Los Angeles, USA, 1988: 148-159.

[5] Noy N F, Klein M. Ontology evolution: Not the same as schema evolution. Knowledge and Information Systems, 2004, 6(4): 428-440.

[6] Haase P, Stojanovic L. Consistent evolution of OWL on-tologies. In: Proceedings of ESWC’05. Heraklion, Greece, 2005: 182-197.

[7] Gardenfors P. Belief Revision: An Introduction. New York, USA: Cambridge University Press, 1992: 1-20.

[8] Flouris G, Plexousakis D. Bridging ontology evolution and belief change. In: Proceedings of SETN’06. Crete, Greece, 2006: 486-489.

[9] Konstantinidis K, Flouris G, Antoniou G, et al. On RDF/S ontology evolution. In: Proceedings of SWDB-ODBIS’07. Vienna, Austria, 2008: 21-42.

[10] Noy N F, Fergerson R W, Musen M A. The knowledge model of protege-2000: Combining interoperability and flexibility. In: Proceedings of EKAW’00. Juan-les-Pins, France, 2000: 69-82.

[11] Najla S, Wassim J, Faiez G. Extension of protege to sup-port evolution of ontology. In: DBKDA’09. Cancun, Mex-ico, 2009: 149-154.

[12] Stojanovic L. Methods and tools for ontology evolution [Dissertation]. Karlsruhe, Germany: University of Karlsruhe, 2004.

[13] Klein M, Noy N. A component-based framework for on-tology evolution. In: Proceedings of the IJCAI-03. Aca-pulco, Mexico, 2003.