A Rule-Based Approach For Semantic Annotation Evolution

Computational Intelligence, Volume 23, Number 3, 2007
A RULE-BASED APPROACH FOR SEMANTIC
ANNOTATION EVOLUTION
P.-H. LUONG AND R. DIENG-KUNTZ
INRIA Sophia Antipolis, France
An approach for managing knowledge in an organization in the new infrastructure of Semantic Web consists
of building a corporate semantic web (CSW). The main components of a CSW are (i) evolving resources distributed
over an intranet and indexed using (ii) semantic annotations expressed with the vocabulary provided by (iii) a shared
ontology. However, changes in the operating environment may lead to some inconsistencies in the system and they
result in need of modifications of the CSW components. These changes need to be evolved and well managed. In
this paper we present a rule-based approach allowing us to detect and correct semantic annotation inconsistencies.
This rule-based approach is implemented in the CoSWEM system enabling to manage the evolution of such a CSW,
especially to address the evolution of semantic annotations when its underlying ontologies change.
Key words: corporate semantic web, semantic annotation evolution, rule-based, inconsistency, constraints.
1. INTRODUCTION
Organizational knowledge is considered as one of the most important assets of organi-
zations, which decisively influences its competitiveness. More and more organizations set
up a Knowledge Management (KM) system to better facilitate the access, sharing, and reuse
of that knowledge as well as creation of new organizational knowledge (Dieng-Kuntz et al.
2005). One approach for managing knowledge in an organization consists of capturing orga-
nizational knowledge and building an Organizational memory or Corporate memory (Kuhn
and Abecker 1997). In the next generation of Semantic Web aiming at a better coopera-
tion among humans and machines (Berners-Lee, Hendler, and Lassila 2001), organizational
memories can be materialized as a corporate semantic web (CSW), which are composed
of heterogeneous, evolving resources distributed over an intranet and indexed using seman-
tic annotations expressed with the vocabulary provided by a shared ontology (Dieng-Kuntz
2005).
However, organizations live in dynamic and changing environments because of the
changes in their business, technologies, and processes. These changes often lead to con-
tinuous changes in the organization’s KM system in which ontologies are the evolving factor
because they are used as a backbone for providing and accessing knowledge sources in
ontology-based KM systems (Stojanovic, Stojanovic, and Handschuh 2002b). Ontological
changes in underlying ontologies then need to be propagated to all semantic annotations that
are created based on the shared vocabulary of these ontologies. Consequently, such modi-
fications influence activities and performance of the KM system and they are still not well
addressed (Lindgren et al. 2000).
In this paper, we introduce the CSW as a particular approach to KM and analyze its
evolution problem. We present the CoSWEM1
system enabling to manage the evolution of
such a CSW and we focus particularly on the evolution of semantic annotations when their
underlying ontologies change. In this system, a rule-based approach is implemented to detect
inconsistent annotations and to guide the process of solving these inconsistencies by applying
correction rules and resolution procedures. First of all, we introduce our CSW approach and
its evolution problems in Section 2. We describe the CoSWEM system architecture and its
main functions. In Section 3, we present some scenarios for the semantic annotation evolution
1Corporate Semantic Web Evolution Management.
C
2007 Blackwell Publishing, 350 Main Street, Malden, MA 02148, USA, and 9600 Garsington Road, Oxford OX4 2DQ, UK.

SEMANTIC ANNOTATION EVOLUTION 321
FIGURE 1. Architecture of a corporate semantic web.
and we emphasize an encountered scenario that describes the influence of ontological change
to the consistency of semantic annotations. In the next section, we propose a rule-based
approach including inconsistency detection rules and correction rules. Then, we present a
short description of implementation illustrating how inconsistent semantic annotations are
detected and corrected within our work in Section 5. Before giving a conclusion and further
work in the last section, we summarize briefly in Section 6 a survey of current researches on
the evolution of ontology and ontology-based KM systems, the impacts of theirs changes on
components of the system as well as our discussion on the similarity between our work and
several existing studies.
2. EVOLUTION MANAGEMENT FOR A CORPORATE SEMANTIC WEB
2.1. Corporate Semantic Web Approach
With the purpose of deployment organizational knowledge using Internet and Web tech-
nologies for an organization, many researches have been carried out to study the integration
of a corporate memory (Dieng-Kuntz et al. 2005) in a new Semantic Web environment.
Semantic Web aims at making the semantic contents of Web resources understandable not
only by human but also by programs, for a better cooperation among humans and machines
(Berners-Lee et al. 2001). The ACACIA2
research team has been studying the materializa-
tion of a corporate memory as a CSW (Dieng-Kuntz 2005) using ontologies to formalize the
vocabulary shared by a community, and semantic annotations based on these ontologies to
describe heterogeneous knowledge sources and facilitate their access via intranet/internet
(see Figure 1).
Considering our illustrating example in biomedical domain, this CSW consists of:
- Resources: they can be documents, databases that store biomedical information. These
resources also correspond to people, services, software, or programs.
2http://www-sop.inria.fr/acacia/.

322 COMPUTATIONAL INTELLIGENCE
- Ontologies: they describe the conceptual vocabulary in biomedical domain (i.e., ontology
for a biomedical domain, patient and hospital, etc.).
- Ontology-based semantic annotations: they use the conceptual vocabulary defined in
ontologies to describe resources, for example biomedical information, symptoms, exper-
iments stored in the databases or patient profiles.
2.2. Evolution Problems of a Corporate Semantic Web
When one of three main components of a CSW is changed, it might have an impact on
the consistency of the overall system. In this case, other related parts may need to evolve as
well to reflect the changes. Among these three components, ontologies are the evolving factor
because their domains are changing fast (new concepts may appear, concepts are removed,
concept hierarchy is reorganized, etc.), the ontologies describing this domain have to change
accordingly, to reflect the changed real-world situation. The authors of Noy and Klein (2004)
have proposed three types of changes in ontology evolution: changes in domain, changes
in conceptualization, and changes in specification. Stojanovic (2004) has also classified
three levels of ontology changes such as elementary, composite, and complex change. A
modification in one part of the ontology may generate inconsistencies in other parts of the
same ontology, in the ontology-based instances as well as in dependent ontologies and in the
applications using this modified ontology (Stojanovic et al. 2002a). Moreover, changes in
ontology could impact to the semantic annotations that use concepts or properties defined in
this ontology. Like the ontologies, resources also influence on the semantic annotations in
case of change because the latter describe the content of knowledge sources. Another kind
of changes in semantic annotations can affect to the system consistency when user makes
some modifications in these annotations without reference to its underlying ontology (e.g.,
regardless of use of terms that are defined in ontology).
Because all three components of a CSW can be changed to adapt new requirements of
organization, these changes make evolution of knowledge system. To manage changes in a
CSW, we have proposed an evolution management system CoSWEM (Luong and Dieng-
Kuntz 2006) that aims at managing the evolution of each component and the evolution-
ary relation among components. However, in this paper we emphasize the propagation of
the ontological changes to the semantic annotations to keep an overall consistency. This
change propagation phase can be considered in the process of semantic annotation evolution
(Figure 8).
We examine a simple example of change propagation in which a doctor needs to create
semantic annotations describing a patient’s profile. These semantic annotations use several
specific terms that are defined in the biomedical ontology containing the concept Fever
and its subconcept Malaria Fever. For instance, s/he describes some information in the
profile of her/his patient John Beeman who has a disease Malaria Fever in the following
annotation:

FIGURE 2. Architecture of the CoSWEM system.
After some executed changes in the biomedical ontology (e.g., the concept Malaria Fever
is deleted), this existing statement of annotation will be inconsistent with respect to the
ontology because of lack of the reference to the deleted concept Malaria Fever. One possible
solution in this case is to replace the deleted concept name Malaria Fever in annotation by
its parent name Fever.
2.3. Corporate Semantic Web Evolution Management (CoSWEM) System
In this section, we present architecture of system that allows managing the evolution of
a CSW. We describe this evolution management system in common with the architecture
of a CSW. This associate presentation gives an overview of operations and the interactive
relations among components of system.
The evolution management system consists of these main components as below:
- Client side component: We distinguish two types of requirement changes that can influence
the consistency of system. Business requirement changes are normally requested from
enterprise or users interested in business aspects. Technical changes are brought out from
ontology/annotation engineer who understands the technical aspects of system. Users send
request for changes to an intermediary component that sends them the notification after
resolution of the changes.
- Intermediary component: All requested changes are preprocessed in this intermediary
layer. First, they are captured and represented in an appropriate format (elementary and
composite changes). These changes are then classified according to type of changes oc-
curred in which parts (resource, ontology, or annotation) and they will be resolved in the
evolution component. This layer has also function to notify to users about the result of
resolving changes and about which parts have been updated.
- Evolution component: This main component of system helps to solve evolution problems
in each part. We divide evolving changes into three types of evolutions corresponding to
the parts of a CSW. Normally, changes in resources and ontologies would lead to changes in
semantic annotations. However, in the scope of our research, we focus only on the changes
in ontologies which would result in the modifications of semantic annotations. During

the change resolution, we need an evolution log that captures all changes executed in the
evolution process. This evolution log also helps to solve more easily the next changes or
operation undo by relying on the traces recorded in log file.
3. SEMANTIC ANNOTATION EVOLUTION
Because the ontology has to be continually changed, the need for the ontology evolution
is inevitable. Stojanovic et al. (2002b) showed that a modification in one part of ontology can
have an impact on the consistency of other parts of the same ontology, in the dependent on-
tologies and the applications using this modified ontology. In particular, changes in ontology
can affect the consistency of semantic annotations which use the concepts or the properties
defined in this modified ontology. Inspired from researches on the database schema evolution
(Roddick 1996), on the ontology evolution (Stojanovic 2004), and on the ontology versioning
(Klein et al. 2002; Klein 2004), we consider the semantic annotation evolution as a process
of adjustment of semantic annotation to the generated inconsistencies because of the changes
on the ontology or the annotation itself.
To describe the inconsistency of semantic annotation, we define what a consistency
constraint is and what an inconsistent semantic annotation is. We also give a definition of
an annotation model that is based on the data model RDF presented in Miller and Manola
(2004).
Definition 1. A consistency constraint ensures a consistent agreement among semantic an-
notations entities with respect to their underlying ontology.
Definition 2. A semantic annotation is defined to be inconsistent with respect to its ontology
model if it violates the consistency constraints defined for annotation model.
Definition 3. An annotation model is a tuple SA := (RA, CA, PA, L, TA) where:
- RA : set of resources
- CA : set of concept names defined in ontology (CA ⊂ RA)
- PA : set of property names defined in ontology (PA ⊂ RA)
- L : set of literal values
- TA : set of triples (s, p, v.) where s ∈ RA, p ∈ PA and v ∈ (RA ∪ L)
3.1. Scenarios
Here below are some scenarios that can impact to the consistency of semantic annotations:
- Scenario 1: User makes some modifications on his/her underlying ontology results in a
new ontology version. Because of these ontological changes, semantic annotations may
be affected leading to the inconsistent state with respect to the new ontology version.
- Scenario 2: User changes his/her annotations without referring to the underlying ontology
which is used by these annotations. The modified annotations can be inconsistent with
respect to the ontology.
- Scenario 3: User imports annotations from another source. These imported annotations
and the old annotations are based on the same ontology. There would be similar annotations
(or triples) which describe the same resource.
- Scenario 4: User makes migration of the annotation base from another representation
formalism (for example, migration of RDF(S) toward OWL-Lite). There would be incon-
sistencies of syntax on these annotations.

FIGURE 3. A part of ontology (a) and semantic annotation based on this ontology (b).
However, we find that the first scenario is more encountered in reality. In this article,
we will focus on this particular context: changes in underlying ontology can impact to the
consistency of the semantic annotations which are using the defined terms in this underlying
ontology. We use the RDF(S) language to model the ontology and to describe a triple (s p
v.) of the annotation in RDF. This triple represents a statement on the resource which can be
expressed as a subject s has a property p whose value is v.
We examine an example with a part of ontology (see Figure 3a) containing concept Patient
which is domain of the property hasDisease. The Patient concept is also father concept of its
subconcepts Newborn Patient, Child Patient, and Adult Patient. The Adult Patient concept,
having two subconcepts Middle-aged Patient and Aged Patient, is domain of the property
worksOn. The Disease and Organization concepts are ranges of the corresponding properties
hasDisease and worksOn. In addition, we have also some triples in semantic annotations
based on this part of ontology (see Figure 3b).
Suppose that this part of ontology was modified by removing the Adult Patient concept,
its two subconcepts are reconnected to the concept Patient and the property worksOn receives
from now on the Middle-aged Patient concept as its domain. Moreover, the concepts New-
born Patient and Child Patient are merged and replaced by the new Young Patient concept.
After having applied these changes, we receive a new ontology version (see Figure 4a) in
which some elements were changed compared to its old version. Some triples become incon-
sistent now (see Figure 4b) because of the loss of the reference links toward the corresponding
terms in ontology before its modification. We will analyze the causes and its solutions for
the inconsistent triples (e.g., triples in lines 2, 3, 4, and 6) in Section 4.
3.2. Change Representation
During the evolution, changes must be identified and represented in suitable formats.
Stojanovic (2004) classified the three levels of changes of ontology (i) elementary change,
(ii) composite change, and (iii) complex change. In the same way, the ontology operations are
also divided according to two dimensions (i) atomic/composite and (ii) simple/rich (Klein
FIGURE 4. The modified ontology (a) and the semantic annotation becomes inconsistent (b).

FIGURE 5. Taxonomy of ontology changes.
2004). In our approach, we study all the changes in ontology which can affect the consistency
of its dependent parts, of other dependent ontologies and particularly the ontological changes
affecting consistency on the concerned semantic annotations. We have built a list of the
necessary changes for the process of ontology and semantic annotation evolution containing
two types of following changes:
- Elementary changes: ontology change that modifies only one entity of the ontology
model and cannot be broken up (e.g., RenameConcept, DeleteConcept, DeleteDomain-
ConceptLink, etc.)
- Composite changes: ontology change that modifies several entities of the ontology model
and can be broken up (e.g., MergeConcept, DivideConcept, etc.)
To have the explicit representation of changes, we develop the so-called evolution ontol-
ogy enabling to formalize the ontology changes (see Figure 5) which can occur during the
evolution. We have also created in this evolution ontology some necessary properties such
as hasVersionBefore, hasDate, hasAuthor. . .which allow to model what changes, when, by
whom, and how changes are performed in an ontology.
3.3. Evolution Strategies for Semantic Annotation
When we make some modifications in the ontology, not only other parts of this ontology
might fall into inconsistent state but also its semantic annotations could be influenced. In this
case, the construction of evolution strategies allows us to control appeared inconsistencies.
Stojanovic (2004) proposes some evolution strategies for ontology in which she defines res-
olution point and elementary strategies for each case of change of ontology. These evolution
strategies ensure that the ontology and other dependent parts of ontology will remain consis-
tent after having applied some changes to the ontology. Moreover, they are also responsible
for avoiding the illegal changes. However, her evolution strategies only cover some effects
of simple changes and she did not mention the evolution strategies for semantic annotations.
In this section, we would like to present a complete set of evolution strategies which
try to solve the inconsistencies caused by all the two types of ontological change: simple
and composite change. Corresponding to each ontological change having an impact on the
consistency of annotations, we have built an equivalent strategy to correct the inconsistencies

appearing in the semantic annotations. To illustrate our evolution strategies, we examine one
of the cases of change: suppression of a middle concept c in the ontology. Suppose that c2 is
father concept of the middle concept c, c0 is root concept, p is a property which can receive
the concepts c, c2, c0 as its domain/range. The evolution strategies for this case are described
in the table below (see Table 1):
TABLE 1. Evolution Strategies for Ontology and Semantic Annotations in Case of Deletion of a Middle
Concept in Ontology
Evolution Strategies: For the Evolution Strategies: For the
Dependent Elements of Ontology Related Annotations
SO-1: To process the instances of the deleted
concept c: 4 options
SA-1: To process the triple containing instances
of the deleted concept c : 4 options
(1) Delete all instances of the concept c (1) Delete this triple
(2) Attach all instances of the concept c to its
father concept c2
(2) If the father concept c2 ∈ domain(p) or c2 ∈
range(p) then we replace the name of type c
for its instances in triple by the name of type
c2. Else, we remove this triple.
(3) Attach all instances of the concept c to its
root concept c0
(3) If the root concept c0 ∈ domain(p) or c0 ∈
range(p) then we replace the name of type c
for its instances by the name of type c0 in
triple. Else, we remove this triple.
(4) Attach all instances of the concept c to any
concept cx indicated by user
(4) If the indicated concept cx ∈ domain(p) or
cx ∈ range(p) then we replace the name of
type c for its instances by the name of type
cx in triple. Else, we remove this triple.
SO-2: To process the subconcepts of c : 4
options
SA-2: To process the triples containing the
resources of type c :
(1) Delete all subconcepts of c (1) No changes in these triples
(2) Attach all subconcepts of c to its father
concept
(3) Attach all subconcepts of c to its root
concept
(4) Attach all subconcepts of c to any concept
indicated by user
Note: The evolution strategies must be repeated
for all subconcepts of c and for all the
semantic annotations related to these
subconcepts.
SO-3: To process the properties related to the
deleted concept c : 3 options
SA-3: To process the triples containing the
resources of type c and the property p : 3
options
(1) Remove c from domain of the property p (1) Delete all triples containing the resource of
type c
(2) If c ∈ domain(p) and there does exist a
concept c2 which is ancestor of c such as
c2 ∈ domain(p), then remove c from domain
of the property p
(2) Replace the name of type c of resources by
the name of its father concept type c2 in
annotation.
(3) If c ∈ domain(p) and there does not exist a
concept c2 which is ancestor of c such as
c2 ∈ domain(p), then remove c from domain
of the property p
(3) Delete all triples containing the resource of
type c and the property p in annotation

FIGURE 6. Ontology evolution with a trace between two versions.
FIGURE 7. Ontology evolution without a trace between two versions.
3.4. Process of Semantic Annotation Evolution in the CoSWEM System
After having applied changes to the ontology, this ontology is evolved to another new
version. We distinguish two cases of ontology evolution which can influence the consistent
state of semantic annotation: (i) ontology evolution with trace and (ii) ontology evolution
without trace of the changes which were carried out between two versions of the ontology.
In the first case (see Figure 6), all the executed changes as well as the results of operations
between two versions O1 and O2 of the ontology are preserved in a log of changes. This log
file contains the trace of changes trace(O1 → O2) which were carried out between these
ontology versions. These executed changes are represented in a more formal way according
to our classification of changes and they are expressed in terms of the evolution ontology.
This log of changes is quite similar to the evolution log presented in Stojanovic (2004) which
tracks the history of an ontology as an ordered sequence of ontology changes. Then, we apply
evolution strategy corresponding to each ontological change to restore the consistent state
for the influenced semantic annotations.
The second case (see Figure 7) often occurs in the dynamic and distributed context of
Semantic Web. It is not always that one can keep the trace between ontology versions. We
can reuse the results of existing research on the ontology versioning allowing us to find
the similarities and the differences diff (O1, O2) between two ontology versions O1 and O2
as well as the changes carried out between these versions (Klein et al. 2002; Klein 2004).
According to this approach, we can detect some executed ontological changes; we can then
follow the procedures of resolution of the inconsistencies presented in the first case to repair
the inconsistent semantic annotations.
However, we have proposed another process allowing us to find the annotations related
to the modified ontology in an annotation base and particularly the inconsistent annotations
affected by the ontological changes. This process comprises two principal steps: (i) incon-
sistency detection and (ii) inconsistency correction of annotations. The main steps of this
process are described as following:
Step 1: query semantic annotations, using Corese
Corese, a semantic search engine developed by the Acacia team (Corby et al. 2004,
2006), allows us to query the annotation bases taking into account the concept hierarchy and
the relation hierarchy defined in the ontology. It makes inferences on the whole annotation
base according to user’s queries. In this step, Corese especially can be used to retrieve from
existing annotation bases:

- Annotations related to the modified ontology by using their reference link to this ontology.
- Potential inconsistent annotations (they may include both related consistent and inconsis-
tent annotations) by using a set of ontology changes. A potential inconsistent annotation
means that it relates to the ontological change but its consistency constraint has not been
verified.
Step 2: apply inconsistency detection rules
We apply inconsistency detection rules in this step to detect the real inconsistent anno-
tations from a set of potential inconsistent annotations. A real inconsistent annotation means
that it violates the consistency constraint defined for the annotation. These detection rules are
formulated from a set of constraints and are expressed in the syntax of Corese rule language.
Step 3: apply inconsistency correction rules and resolution procedures
After having determined real inconsistent annotations from a set of potential inconsis-
tent annotations, these annotations will be repaired by applying correction rules. We have
established all possible solutions that solve the propagation of ontological changes to their
semantic annotations to keep consistency status.
Step 4: version management
This step enables us to manage versions of the ontology and its semantic annotation in
case of storing different versions.
In this process, we focus on the Step 2 which is responsible for checking the consistency
of the semantic annotations with respect to its underlying ontology. This step also enables
to find “parts” in the semantic annotation that violate consistency constraints. The Step 3 is
responsible for ensuring the consistency of the semantic annotation by applying the correction
rules and the resolution procedures that resolve the detected inconsistencies. The involved
actors in this process (see Figure 8) are the SystemEngineer who manages the overall system,
the Annotator who creates annotations based on existing ontology, the OntologyProvider who
provides changing ontology source.
4. RULE-BASED APPROACH FOR SOLVING INCONSISTENCIES
OF SEMANTIC ANNOTATION
Our rule-based approach is constructed from some consistency constraints that must be
satisfied for any annotation model. Consistency is an attribute of a (logical) system that is
constituted so that none of the facts deducible from the model contradicts another (Stojanovic
2004). Therefore, we have proposed some consistency constraints that can be considered as
an agreement among semantic annotations entities with respect to their underlying ontology.
Based on these consistency constraints, we have created some inconsistency detection rules
using syntax of Corese rule language.
4.1. Consistency Constraints
To express consistency constraints, we take the notation from Miller and Manola (2004)
to describe an RDF triple in annotation as a triple (s p v.). This triple makes statement about
resource and it can be expressed as a subject s has a property p whose value is v. We use the
primitive rdf:type to indicate a resource as instance of specific types or classes (e.g., resource

FIGURE 8. Process of semantic annotation evolution.
has type Class or Property), and other primitives with prefix rdfs: to describe classes or
relationship among these classes in the ontology.
- CC-1 (Constraint on concept): All the concepts used in the annotation must be defined
before in the ontology.
(s rdf:type c) =⇒ (c rdf:type rdfs:Class)
- CC-2 (Constraint on property): All the properties used in the annotation must be defined
before in the ontology.
(s p v.) =⇒ (p rdf:type rdf:Property)
- CC-3 (Constraint on property domain): The resource which is the domain of a property in
the annotation must be compatible with the domain of the corresponding property defined
in the ontology.
(p rdf:type rdf:Property) ∧ (p rdfs:domain d) ∧ (d1 p v.) =⇒ (d1 rdf:type d)
or =⇒ (d1 rdf:type d) ∨ (d1 rdf:type dx) if ∃ dx ∈ descendants(d) such that
(d1 rdf:type dx)
(Note: descendants(d) refers to all the descendant elements of d in the concept
hierarchy)
- CC-4 (Constraint on property range): The resource which is the range of a property in
the annotation must be compatible with the range of the corresponding property defined
in the ontology.
(p rdf:type rdf:Property) ∧ (p rdfs:range r) ∧ (s p r1.) =⇒ (r1 rdf:type r)
or =⇒ (r1 rdf:type r) ∨ (r1 rdf:type rx) if ∃rx ∈ descendants(r) such that
(r1 rdf:type rx)
(Note: descendants(r) refers to all the descendant elements of r in the concept
hierarchy)

- CC-5 (Constraint on datatype): The data type of a value of property in the annotation must
be compatible with the value of the corresponding property defined in the ontology.
(p rdf:type rdf:Property) ∧ (p rdfs:range r) ∧ (r rdf:type rdfs:Data type) ∧
(s p r1.) =⇒ (r1 rdf:type r)
4.2. Inconsistency Detection Rules
We have established several inconsistency detection rules enabling us to find inconsistent
annotations that are obsolete related to a modified ontology considered as a reference. These
rules are based on consistency constraints.
Given CO and PO sets of concepts and properties of ontology O, given CA and PA sets
of concepts and properties appearing in annotation A. All the triples in annotation have
the form (r pt v.) (r type ct .). Functions domain(p) and range(p) are used to list all the
concepts domain/range of the property p. We have constructed some groups of rule allowing
us to detect inconsistencies related to concepts, properties, domain/range and data type. In
the following paragraph, we present some rules which can be used to illustrate the above
example.
- Group 1 (detection rule for a resource which is a concept): If a concept is used in an
annotation but it has not been defined in ontology, then this annotation leads to inconsistent
state.
R-1 : ∀ triple t, If (ct ∈ CA) and (ct /
∈ CO) Then note(inconsistent)
R-2 : ∀ triple t, If (ct ∈ CA) and (ct ∈ CO) Then note(OK)
- Group 2 (detection rule for a resource which is a property): If a property is used in an
annotation but it has not been defined in ontology, then this annotation leads to inconsistent
state.
R-3 : ∀triple t, If (pt ∈ PA) and (pt /
∈ PO) Then note(inconsistent)
R-4 : ∀triple t, If (pt ∈ PA) and (pt ∈ PO) Then note(OK)
- Group 3 (detection rule for a resource which is a domain of property): If a property p
takes a resource of concept type c as its domain in annotation, but c has not been defined
as domain of p in ontology, then this annotation leads to inconsistent state.
R-5 : ∀triple t, If domain(pt ) ⊆ domain(PA) and domain(pt ) ⊂ domain(PO) Then
note(inconsistent)
R-6 : ∀triple t, If domain(pt ) ⊆ domain(PA) and domain(pt ) ⊆ domain(PO) Then
note(OK)
- Group 4 (detection rule for a resource which is a range of property): If a property p takes
a resource of concept type c as its range in annotation, but c has not been defined as range
of p in ontology, then this annotation leads to inconsistent state.
R-7 : ∀triple t, If range(pt ) ⊆ range(PA) and range(pt ) ⊂ range(PO) Then
note(inconsistent)
R-8 : ∀triple t, If range(pt ) ⊆ range(PA) and range(pt ) ⊆ range(PO) Then note(OK)
- Group 5 (detection rule for a data type): If a value of property p has data type d in
annotation, but d has not been defined as a data type of value of p in ontology, then
this annotation leads to inconsistent state. (DO and DA are sets of all defined data types
respectively in ontology and in annotation)
R-9 : ∀triple t, If (v ∈ dt ) and (dt ∈ DA) and (dt /
∈ DO) Then note(inconsistent)
R-10 : ∀triple t, If (v ∈ dt ) and (dt ∈ DA) and (dt ∈ DO) Then note(OK)
These detection rules are also represented in syntax of Corese rule language (including
some primitives in SPARQL). We have implemented these detection rules in Corese to make

use of its queries for the task of inconsistency detection. Below is an example of a rule that
detects inconsistent annotations containing a concept that has not been defined before in the
ontology.
Detection rule for concept resource: If a concept is used in an annotation but it has not
been defined in the ontology, then this annotation leads to inconsistent status.
With the constructed detection rules, we applied these detection rules on the set of
annotations related to the modified ontology. With the rule R-1, we can detect the triples
in lines 2, 3, and 4 (see Figure 9a) which become inconsistent because the loss of concept
reference toward the concepts Newborn Patient and Adult Patient. The rule R-5 detects the
triples in line 6 inconsistent because the domain relation between the concept Aged Patient
and the property worksOn was deleted in the new ontology version.
4.3. Inconsistency Correction Rules
After having collected all inconsistent annotations from a set of potential inconsistent
annotations, we need to correct these inconsistencies by applying some correction rules
on these annotations. These rules guide the execution of evolution strategies in which we
specified how to propagate the change resolution to inconsistent annotations to keep an overall
consistency (see Table 1).
We examine again the above example, after having detected inconsistencies, we find
that triples in lines 2, 3, 4, and 6 are in the inconsistent state (see Figure 9). Knowing that
the change DeleteConcept(Adult Patient) leads to the loss of the concept reference of the
resources in triples in lines 3 and 4 toward their ontological corresponding terms, we can
apply some below rules:
FIGURE 9. Some inconsistent triples before (a) and after (b) update.

- RC-1: If SO-3 (2) is applied for ontology Then apply SA-3 (2) for the annotation. This
rule will replace the name of concept type Adult Patient by the name of the concept type
Patient in triple in line 3 because the relation between the property hasDisease and the
concept Patient is still kept.
- RC-2: If SO-3 (3) is applied for ontology Then apply SA-3 (3) for the annotation. This rule
will remove the triple in line 4 because it does not exists the relation between the property
worksOn and the concept Patient which is father of the deleted concept Adult Patient.
5. IMPLEMENTATION
In this section, we present the validation of our approach in a real-world scenario. As
we know that ontologies are growing beyond the human ability to manage them, it would
not be possible to manage manually the effects of ontology changes to their concerned
semantic annotations. Therefore, we have been developing a Web based tool for supporting
the semantic annotation evolution when its underlying ontology changes. This supporting
tool has been carried out in the framework of a Semantic web server (SeWeSe) developed in
our project. In the first step, we have created an evolving source of ontology that describes
the medical domain, this evolving ontology also includes the part of ontology (see Figure 3)
presented in the previous section. In our annotation bases, we have several annotations using
the conceptual vocabulary defined in the evolving ontology to describe resources. Although
these ontology source and annotation bases are not so enormous with a huge of concepts and
properties, they can however cover almost all kinds of inconsistencies on the concept, the
property, the domain domain/range as well as the data type which we have mentioned. For
the next step, we will carry out our research validation on a European project Palette with a
bigger data source and in many various situations.
In our system, we use Corese,3
an ontology-based search engine for the Semantic Web
which is dedicated to the retrieval of Web resources annotated in RDF(S) (Corby et al. 2004,
2006) by using a query language based on RDF(S). Corese engine internally works on concep-
tual graphs (CG). It enables RDFS ontology and RDF annotations to be loaded and translated
into CG, and then, using the CG projection operator, allows the base of annotations to be
queried. Corese proposes a query language for RDF very similar to SPARQL;4
for each query,
an RDF graph is generated, related to the same RDF Schema as the one of the annotations
to which it is to be matched. When matching a query with an annotation, according to their
common ontology, both RDF graphs and their schemas are translated in the CG model. Here
below is an example enabling us to check whether the resources of type concept Child Patient
in semantic annotations have been still consistent with the new version of ontology after hav-
ing executed some changes in ontology). This kind of checking for concept resource can be
considered as a query to submit into Corese (see Figure 10a). Because the concept has been
removed in the new version of ontology, Corese has detected an inconsistency caused by
semantic error Undefined Class: http://www.inria.fr/2006/02/11/humans.rdfs#Child Patient
meaning that this Child Patient concept is not defined currently in ontology.
In another example, when we modify the underlying ontology (e.g., delete concept
Malaria Fever), the annotations based on this ontology may be in inconsistent status. Corese
enables us to retrieve all annotations related to this ontology change by applying query to
the annotation base (see Figure 10b). The following query determines Patient (?p) who has a
3COnceptual REsource Search Engine (http://www-sop.inria.fr/acacia/soft/corese/).
4http://www.w3.org/TR/rdf-sparql-query/.

FIGURE 10. A query example using Corese.
disease called Malaria Fever. This query also indicates the affected statement and the source
location of the annotation containing this statement (e.g., this statement is located in an RDF
annotation file human beta.rdf).
As mentioned in the previous section, we can apply the inconsistency detection rules
allowing us to find inconsistent annotations that are obsolete related to a modified ontology.
According to the executed changes in a part of ontology (see Figures 3 and 4), we can figure
out some inconsistent annotations (see Figure 11) affected by these ontological changes
relating to the concept, property, domain and range.
A sample screenshot of the inconsistency correction phase is given in Figure 12. With
this interface, user can choose a suitable evolution strategy to apply to repair the inconsistent
semantic annotations which are related to the concept Newborn Patient in the old ontology
version. In this example, user can choose one of the two possible solutions (i) replacing
the triples containing the concept Newborn Patient by another concept existing in the new
ontology version or (ii) removing all these triples containing the concept Newborn Patient.
We have also implemented in this phase an heuristic algorithm which enables user to choose
the most appropriate concept to replace (for example, we figure out with priority the concepts
having a meaning is close to the Newborn Patient concept).
6. RELATED WORK AND DISCUSSION
The majority of researches in the field of KM system, ontology or semantic annotation
focus mainly on construction issues. There are few studies coping with the changes and
providing maintenance facilities in KM system. In this section, we make a survey on these
existing studies and we try to give a comparison between our work and some other related
researches.
An interesting research on the evolution of KM system is presented in Lindgren et al.
(2000). This paper analyses two types of changes: (i) functional changes and (ii) structural
changes that can appear in KM systems. The authors in Heflin and Hendler (2000) point

FIGURE 11. Example of the detected inconsistent semantic annotations.
FIGURE 12. Example of solutions for the inconsistent semantic annotations.

out that ontologies on the Web will need to evolve. They provide a new formal definition of
ontologies for the use in dynamic, distributed environments and also present SHOE, a Web-
based knowledge representation language. Heflin and Hendler (2000) mentions the support
of multiple versions of ontologies and ontology reuse but it does not process the change
propagation between distributed and dependent ontologies. There are also some studies of
managing changes in ontologies (Noy and Klein 2004; Stojanovic 2004) that take ideas
from research on database schema evolution (Roddick 1996). Klein et al. (2002) describes
an ontology versioning system that allows access to data through different versions of the
ontology. This approach is based on the comparison of two ontology versions to detect
changes (Klein and Noy 2003). However the change detection phase is a complicated and
time-consuming process. It is impossible to determine the cause and the consequences of
a change, which is a crucial requirement for the consistency of the dependent ontologies
(Stojanovic et al. 2002a). Moreover, Noy and Klein (2004) and Klein (2004) have proposed a
framework for ontology evolution but their approach lacks a detailed analysis of the effect of
specific changes on the interpretation data. Leenheer et al. (2006) has described a versioning
tool for ontologies that are represented in the DIP language. This tool contributes to the
integrated ontology management tool suite, to be delivered in the DIP project. In contrast to
that approach of versioning which detects changes by comparing ontologies, Stojanovic et al.
(2002a,b) present their ontology evolution approach that allows access to all data only through
the newest ontology. In their paper (Haase and Sure 2004), the authors have also summarized
briefly these two main approaches of ontology evolution and versioning. The authors have
presented in Stojanovic et al. (2002a) a process of six-phases for ontology evolution with
some procedures of change resolution. They have focused on the two important phases (i)
semantic of change that enables the resolution of ontology changes in a systematic manner
by ensuring the consistency of the whole ontology and (ii) change propagation that brings
automatically dependent artefacts (ontology based instances, applications and dependent
ontologies) into a consistent state after an ontology update has been performed. Maedche et
al. (2003) has also presented an integrated framework for managing multiple and distributed
ontologies. This paper presents a conceptual modeling approach along with its mathematical
definition and formal semantics to solve the change propagation of distributed ontologies.
However, both Stojanovic et al. (2002a) and Maedche et al. (2003) have not mentioned about
the change propagation to the related annotations in case of related changes in ontologies.
In Rogozan and Paquette (2005b), the authors have introduced a combined approach that
supports the process of ontology evolution and ontology versioning by managing the history
of ontology changes.
There are very few approaches investigating the problems of propagation of the onto-
logical changes to semantic annotations. In Stojanovic et al. (2002b), the authors proposed a
framework CREAM to solve the evolution of metadata based on their existing research on the
ontology evolution. Another study of ontology evolution influence on metadata via relational
constraints of a database system is also given in Ceravolo et al. (2004). According to this
approach, the knowledge-based environments rely on a relational database to store the RDF
and RDFS used for representing respectively ontology-based assertions and the ontology
structure itself. Ontology maintenance events can be managed using database triggers for
automatically modifying property ranges or domains in the stored assertions.
Our work presented in this paper can be compared with some similar existing studies.
Regarding to the resolution of inconsistencies in semantic annotations in the context of
modifications in ontology, Stojanovic et al. (2002b) has presented the framework CREAM.
Nevertheless, this approach only presented their proposition of a framework for enabling
consistency of the descriptions of the knowledge sources in case of changes in the domain
ontology but they do not specify techniques to solve it. Rogozan and Paquette (2005a) has
also described a framework for maintaining the integrity of semantic annotation of resources

after the ontology evolution but this approach just modifies the reference links of object
to allow them to properly refer to the new ontology version. In Ceravolo et al. (2004),
a technique of using triggers in relational database for automatically modifying property
ranges or domains in the stored assertions has been introduced but it has not mentioned
the inconsistency resolution process. Our evolution management system CoSWEM not only
proposes the propagation process of the ontological changes to semantic annotations but
also specifies a rule-based approach to detect inconsistent annotations and the correction
procedures to solve these inconsistencies. Relying on rule-based approach, our work differs
from the rules for change in Klein (2004) for finding complex ontology changes. In contrast
to this method which is based on a set of rules and heuristics to generate a complex change
from a set of elementary changes, our approach relies on the executed ontological changes
stored in the evolution log. Our detection rules deal with the semantic annotations only related
to these changes instead of examining all annotation bases.
7. CONCLUSION AND PERSPECTIVES
We have presented in this paper the CSW as one particular approach for managing
knowledge for an organization in the new infrastructure of Semantic Web. However, such a
CSW system needs the ability to adapt efficiently to the changes from its components such
as ontologies, annotations or resources. For this reason, we have proposed the CoSWEM
system enabling us to manage its evolution, especially to manage effects on annotations
when the ontologies change. In this system, we have implemented a rule-based approach for
solving inconsistencies in semantic annotations. This approach enables to find inconsistent
annotations through inconsistency detection rules and then to repair these inconsistencies by
using correction rules and resolution procedures.
As further work, we will refine this rule-based approach and study some effective algo-
rithms on the process of correction and validation for semantic annotations changes. We will
also focus on the problem of versioning management allowing us to use different versions of
semantic annotations and ontologies in a CSW after some changes.
ACKNOWLEDGMENTS
We are grateful to our colleagues at the ACACIA team and in the Palette project for their
helpful discussion and sharing knowledge on our research. We also would like to thank Alain
Boucher, Ho Tuong Vinh, and students (promotion 11, group 2) at the Francophone Institute
for Computer Science who helped us to implement some experimental works.
REFERENCES
BERNERS-LEE, T., J. HENDLER, and O. LASSILA. 2001. The Semantic Web. Scientific American, 284(5):35–43.
CERAVOLO, P., A. CORALLO, G. ELIA, and A. ZILLI. 2004. Managing ontology evolution via relational constraints.
Knowledge-based intelligent information and engineering systems. In Proceedings of the 8th International
Conference, KES 2004, Wellington, New Zealand, pp. 335–341, Lecture Notes in Computer Science 3215,
Berlin, Springer.
CORBY, O., R. DIENG-KUNTZ, C. FARON-ZUCKER, and F. GANDON. 2006. Searching the Semantic Web: Approx-
imate query processing based on ontologies. IEEE Intelligent Systems Journal, 21(1):20–27.
CORBY, O., R. DIENG-KUNTZ, and C. FARON-ZUCKER. 2004. Querying the Semantic Web with the CORESE
search engine. In Proceddings of the 16th European Conference on Artificial Intelligence (ECAI’2004).
Edited by R. Lopez de Mantaras and L. Saitta. Valencia, Spain, 22–27 August, 2004, pp. 705–709, IOS
Press, Amsterdam.

DIENG-KUNTZ, R. 2005. Corporate Semantic Webs. In Encyclopaedia of Knowledge Management. Edited by D.
Schwartz. Idea Publishing Group, Hershey, PA, pp. 67–80.
DIENG-KUNTZ, R., O. CORBY, F. GANDON, A. GIBOIN, J. GOLEBIOWSKA, N. MATTA, and M. RIBIRE. 2005. Knowl-
edge Management-Methodes et outils pour la gestion des connaissances; une approche pluridisciplinaire du
Knowledge Management (2nd ed.). Dunod, Paris.
HAASE, P., and Y. SURE. 2004. D3.1.1.b State of the art on ontology evolution. SEKT/2004/D.3.1.1.b/v0.5.
Institute AIFB, University of Karlsruhe.
HEFLIN, J., and J. A. HENDLER. 2000. Dynamic ontologies on theWeb. In Proceedings of the 7th National
Conference on Artificial Intelligence AAAI-2000, Menlo Park, CA, August 2000, pp. 443–449. AAAI/MIT
Press, Cambridge, MA.
KLEIN, M. 2004. Change management for distributed ontologies. Ph.D. thesis, Vrije Universiteit Amsterdam.
KLEIN, M., and N. F. NOY. 2003. A component-based framework for ontology evolution. In Proceedings of
Workshop IJCAI’2003 on Ontologies and Distributed Systems, Acapulco, Mexico, CEUR-WS Volume 71,
available as Technical Report IR-504, Vrije Universiteit Amsterdam.
KLEIN, M., A. KIRYAKOV, D. OGNYANOV, and D. FENSEL. 2002. Ontology versioning and change detection
on the Web. In Proceedings of the 13th European Conference on Knowledge Engineering and Knowledge
Management (EKAW-2002), pp. 197–212, Siguenza, Spain, October 2002.
KUHN, O., and A. ABECKER. 1997. Corporate memories for knowledge management in industrial practice:
Prospects and challenges. Journal of Universal Computer Science, 3(8):929–954.
LEENHEER, P., J. KOPECKY, and E. SHARF. 2006. Requirements design for an ontology versioning tool doc-
ument accompanying DIP deliverable D2.4 “Ontology Versioning Tool”. FP6–507483–WP 2: Ontology
Management. June 5th, 2006.
LINDGREN, R., C. HARDLESS, U. NULDEN, and K. PESSI. 2000. The evolution of knowledge management system
need to be managed. Available at: http://www.viktoria.informatik.gu.se/groups/KnowledgeManagement/
Documents/kmman.pdf, 2000
LUONG, P.-H., and R. DIENG-KUNTZ. 2006. A rule-based approach for semantic annotation evolution in the
CoSWEM system. In Proceeding of the Canadian Semantic Web Working Symposium (CSWWS 2006), pp.
103–120, Quebec City, Canada, June 2006.
MAEDCHE,A.,B.MOTIK,andL.STOJANOVIC.2003.Managingmultipleanddistributedontologiesonthesemantic
web. The VLDB Journal, 12:286–302.
MILLER, E., and F. MANOLA. 2004. RDF primer. W3C resource description framework. Available at: http://
www.w3.org/RDF.
NOY, N. F., and M. KLEIN. 2004. Ontology evolution: Not the same as schema evolution. Knowledge and
Information Systems, 6(4):428–440.
RODDICK, J. F. 1996. A survey of schema versioning issues for database systems. Information and Software
Technology, 37(7):383–393.
ROGOZAN, D., and G. PAQUETTE 2005a. Semantic annotation in e-learning systems based on evolving ontologies.
SW-EL’05: Applications of Semantic Web Technologies for E-Learning, AIED’05 workshop, Amsterdam,
pp. 61–64.
ROGOZAN, D., and G. PAQUETTE. 2005b. Managing ontology changes on the Semantic Web. In Proceedings of
the 2005 IEEE/WIC/ACM International Conference on Web Intelligence (WI’05), pp. 430–433.
STOJANOVIC, L. 2004. Methods and tools for ontology evolution. Ph.D. Thesis, University of Karlsruhe.
STOJANOVIC, L., A. MAEDCHE, N. STOJANOVIC, and B. MOTIK. 2002a. User-driven ontology evolution man-
agement. In Proceedings of the 13th European Conference on Knowledge Engineering and Knowledge
Management (EKAW-2002), pp. 285–300, Springer-Verlag, Spain, October.
STOJANOVIC, L., N. STOJANOVIC, and S. HANDSCHUH. 2002b. Evolution of the metadata in the ontology-based
knowledge management systems. The 1st German Workshop on Experience Management: Sharing Experi-
ences about the Sharing of Experience, 2002, pp. 65–77.

A Rule-Based Approach For Semantic Annotation Evolution

Recommended

Recommended

More Related Content

Similar to A Rule-Based Approach For Semantic Annotation Evolution

Similar to A Rule-Based Approach For Semantic Annotation Evolution (20)

More from Maria Perkins

More from Maria Perkins (20)

Recently uploaded

Recently uploaded (20)

A Rule-Based Approach For Semantic Annotation Evolution