Available online at www.sciencedirect.

com

Information and Software Technology 51 (2009) 83–97

www.elsevier.com/locate/infsof

Evaluating the validity of data instances against ontology

evolution over the Semantic Web
Li Qin a,*, Vijayalakshmi Atluri b
a
Department of Information Systems and Decision Sciences, Fairleigh Dickinson University, 1000 River Road, Teaneck, NJ 07666, USA
b
CIMIC and MSIS Department, Rutgers University, 180 University Avenue, Newark, NJ 07102, USA

Received 21 September 2006; received in revised form 16 January 2008; accepted 16 January 2008
Available online 26 January 2008

Abstract

It is natural for ontologies to evolve over time. These changes could be at structural and semantic levels. Due to changes to an ontol-
ogy, its data instances may become invalid, and as a result, may become non-interpretable. In this paper, we address precisely this prob-
lem, validity of data instances due to ontological evolution. Towards this end, we make the following three novel contributions to the area
of Semantic Web. First, we propose formal notions of structural validity and semantic validity of data instances, and then present
approaches to ensure them. Second, we propose semantic view as part of an ontology, and demonstrate that it is sufficient to validate
a data instance against the semantic view rather than the entire ontology. We discuss how the semantic view can be generated through
an implication analysis, i.e., how semantic changes to one component imply semantic changes to other components in the ontology.
Third, we propose a validity identification approach that employs locally maintaining a hash value of the semantic view at the data
instance.
Ó 2008 Elsevier B.V. All rights reserved.

Keywords: Ontology evolution; Data validity; Semantic Web

1. Introduction has become an important research area because ontology

Ontologies are formal, explicit specifications of shared
conceptualizations of a given domain of discourse [3]. Gen-
erally, an ontology for a domain contains a description of
important concepts, properties of each concept as well as
restrictions and axioms upon properties. Ontologies pro-
vide interpretation to the contents of the Semantic Web
data. Specifically, ontologies define and relate concepts
used to describe the web data, which are nothing but
instances to the concepts in ontologies.
Ontologies evolve over time since the targeted domain
changes with time. Changes can also be with respect to
how the domain is conceptualized, or the same conceptual-
ization is specified in a different way. Ontology evolution
*
Corresponding author. Tel.: +1 4137821715.
E-mail addresses: liqin@fdu.edu (L. Qin), atluri@cimic.rutgers.edu
(V. Atluri).
development is ubiquitous and ontologies have become
an integral part of many applications [12]. We classify the
changes to ontologies into two levels – structural and
semantic. Structural changes include changes abstracted
at the data model such as adding/removing concepts, add-
ing/removing restrictions over properties, etc. Note that
each structural change is limited to a specific component
in the ontology. Semantic changes obviously mean changes
to the semantics presented by the ontology. While struc-
tural changes are visible changes to the ontology, semantic
changes are not so obvious. These semantic changes are
derived through evaluating visible structural changes. Fur-
thermore, since the semantics of a concept is defined
through its relationships with other concepts, semantic
changes to other concepts may imply semantic changes to
this concept. As a result, in addition to the explicit seman-
tic changes brought by structural changes, implicit semantic
changes can be derived based on the semantic dependency

0950-5849/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved.
doi:10.1016/j.infsof.2008.01.004
84 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
among concepts and properties. Research on detecting
structural changes includes PromptDiff [14,17] and on
detecting semantic changes includes SemDiff [21].
Understanding the semantic changes to an ontology is
crucial to the functioning of its data instances and depen-
dent ontologies. Ontologies present semantics for interpret-
ing data instances. If an ontology is substituted by a new
version, its data instances may become non-interpretable.
This is because, the ontology components they comply with
may not be available in the new version, or the new version
brings an incorrect interpretation to the data instances.
Such a mismatch in the compliance may lead to mistaken
decisions and actions. Secondly, a dependent ontology of
this changed ontology has far-reaching effects on its data
instances and its dependent ontologies as well. When an
ontology imports and extends another ontology for reus-
ability and interoperability, it is semantically dependent
on what is defined in the imported ontology. Therefore, if
the imported ontology has changed, the dependent ontol-
ogy may not provide valid meaning for interpreting its data
instances. Since changes to an ontology are autonomous,
its data instances and dependent ontologies may become
invalidated. In this paper, we focus on the validity issue of
data instances due to ontological evolution. Similar
approaches can be applied to the validity of dependent
ontologies as well.
While the author of a data instance needs to ensure the
validity of the data instance, the consumers need to be pro-
tected from erroneous interpretation caused by ontology
evolution. As an example, the state or local department
of public health may publish guidelines and regulations
on disease control. If these data are presented as semantic
data instances, these government agencies will need to
ensure that they are valid data instances. On the other
hand, hospitals, clinics and doctors who are consumers of
these data also need these data to be valid and interpretable
in order to comply with the regulations and policies. Exist-
ing research is restricted to studying the impact of struc-
tural changes on data preservation [12], or the validity of
subsumption relations [9]. Moreover, existing work dis-
cusses ontology-level compatibility by assuming the entire
ontology affects the validity [4,5]. Therefore, there is a com-
pelling need for a close examination of the validity of data
instances when their ontologies evolve.
By structural validity against an ontology, we mean data
instances structurally comply with the ontology. A Struct-
Valid algorithm is used to evaluate the structural validity of
a data instance. Our notion of semantic validity of data
instances has structural validity as a prerequisite. Further-
more, the semantic validity of data instances determines
whether these instances can be correctly interpreted
through the ontology. For instance, if a concept in the
ontology becomes more specialized, then instances which
are semantically valid for the old version, cannot be inter-
preted through the new version; in other words, they may
not be semantically valid for the new version. Therefore,
the semantic changes between two ontology versions affect
the semantic validity of a data instance, and we propose a
SemValid algorithm to evaluate it. While the structural
validity is evaluated based on what is visible in an ontol-
ogy, the semantic validity cannot be evaluated in this
way. As a result, though the structural validity of a data
instance can be evaluated with respect to an ontology,
the semantic validity of a data instance is defined as a func-
tion of the changes between two versions. Given a seman-
tically valid data instance, we would like to determine
whether a set of ontology changes has changed the seman-
tics of the data instance.
Since a data instance instantiates only part of an ontol-
ogy, not every component in the ontology has impact on its
validity. On the other hand, if a semantic change to a com-
ponent of the ontology imply semantic changes to the
instantiated components by a data instance, then this
semantic change will ultimately affect the semantic validity
of this data instance. Therefore, in addition to the instanti-
ated components, other components may be significant to
the validity of the data instance as well. We propose seman-
tic view as a subset of the ontology, and demonstrate that
the semantic view rather than the entire ontology is respon-
sible for the validity of a data instance. Our definition of
semantic view is in line with ontology view [16] in terms
that it is ‘a portion of an ontology’. However, our pro-
posed semantic view for a specific data instance is a ‘view’
of the ontology whose changes directly or indirectly affect
its semantic validity. We show the semantic view be gener-
ated based on the implication analysis, which specifies how
semantic changes to one component imply semantic
changes to other components. We further propose a valid-
ity identification approach in which a data instance carries
a hash value of its semantic view when it is created. By sim-
ply re-computing the hash value of the semantic view and
comparing it with that stored by the data instance, one
can deduce whether the ontology has changed silently in
a way which may affect the semantic validity of the data
instance.
This paper is organized as follows. Section 2 presents the
preliminaries on ontologies and instances. Section 3 dis-
cusses the structural changes and semantic changes to
ontologies. In Section 4, we present the implication analysis
which is the key to identifying implicit semantic changes
from explicit ones and generating the semantic view. Sec-
tion 5 presents the structural and semantic validity of data
instances, and algorithms to evaluate them. In Section 6,
the semantic view along with its generation is presented.
Implementation of our approach is discussed in Section
7. Related work on detecting changes to ontologies and
the consequences of the ontology changes is presented in
Section 8. Section 9 presents our conclusions and an insight
into our future work.
2. Preliminaries
In this section, we present the preliminaries on ontolo-
gies and their instances.
 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
2.1. Ontologies
A well-cited definition for an ontology is given by
Gruber [3] as a ‘‘specification of a conceptualization”. An
ontology defined for a domain is a formal specification of
important concepts and relationships in the domain that
exist for software agents. An ontology, o, e.g. in OWL
[18], generally consists of the following components. We
use the ontology shown in Fig. 1 as an example to explain
these components.
(1) Concepts: Each ontology o contains a set of concepts,
CðoÞ ¼ fc1 ; c2 ; . . . ; cn g. Fig. 1 represents an Intensive
Care Unit (ICU) ontology, therefore, C(ICU
ontology) = {ICU, person, health care personnel,
patient, . . .}.
(2) Properties: Each ontology contains a set of proper-
ties. If a property relates A to B, then A is called
the domain of the property and B is called the
range of the property. For all the properties with
concept c as the domain, P ðcÞ ¼ DP ðcÞ [ OP ðcÞ,
where
 DP ðcÞ ¼ fdp1 ; dp2 ; . . . ; dpm g are datatype properties,
each taking a primitive data type as the range. We
use dpi ðcÞ to represent the datatype property dpi of
concept c.
 OP ðcÞ ¼ fop1 ; op2 ; . . . ; opn g are object properties, each
taking some concept(s) as the range. We use opi ðcÞ
to denote the object property opi of concept c.
Object properties can be of two types:
– class-level properties ðOP C ðcÞÞ are properties
relating two concepts.
– instance-level properties ðOP I ðcÞÞ are properties
relating instances.
part_of
person
name, age, address
subclassOf subclassOf
patient
health care personnel ID,
code, salary insurance_type
(insurance plan),
(insurance_plan),
billing_address
subclassOf subclassOf cardinality(ID)=1
monitored_by
doctor nurse
Fig. 1. Example of an ICU ontology.
85
For example, for concept ‘patient’ in Fig. 1, DP(patient) =
{ID, insurance_type, insurance_plan, billing_address}
and OP(patient) = {subclassOf, monitored_by}. sub-
classOf 2 OPC(patient) with subclassOf(patient) =
person and monitored_by 2 OPI(patient) with moni-
tored_by(patient) = monitoring device.
(3) Restrictions: For each property p, there exists a set of
restrictions on the range or cardinality of the prop-
erty, denoted by RðpÞ ¼ fr1 ; . . . ; rw g where rk ðpÞ is
the restriction rk of property p.
For example, ID 2 DP(patient) and R(ID) = {cardi-
nality} with cardinality(ID) = 1.
(4) Axioms: For each property p, there exists a set of axi-
oms with each defined by itself or in relation to
another property, denoted by AðpÞ ¼ fa1 ; a2 ; . . . ; an g.
ai ðpÞ represents the axiom ai of property p.
In our example, EquivalentProperty(insurance_type)
= insurance_plan is an axiom stating that these two
properties are semantically equivalent (note that
equivalent properties are put in the parenthesis in
the figure.).
Different ontology languages may support different types
of class-level object properties, restrictions and axioms upon
properties. For instance, OWL Full [18] supports at least the
following class-level object properties: subClassOf, equiva-
lentClass, intersectionOf, unionOf, complementOf. It sup-
ports restrictions such as cardinality, minCardinality,
maxCardinality, and axioms such as subPropertyOf, equiva-
lentProperty, TransitiveProperty, SymmetricProperty, Func-
tionalProperty, InverseFunctionalProperty, inverseOf, and so
on. Though our proposed approach does not depend on any
specific ontology language, we use OWL constructs for our
discussion in this paper.
ICU
part_of
equipment
dimensions
subclassOf subclassOf
treatment general
device equipment
task performed
tas _pe o ed
monitors
subclassOf
monitoring
device
channel_number
subclassOf
electrocardiograph
86 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
Concept hierarchy: Concepts in an ontology o are usu-
ally organized into a concept hierarchy. Given two con-
cepts c1 ; c2 2 CðoÞ where subclassOf ðc1 Þ ¼ c2 , we say
that c1 is a more specialized concept than c2 . We use
eqðcÞ and supðcÞ to represent the set of concepts which
are equivalent to c and superclass concepts of c, respec-
tively. Similarly, hierarchical relationship may exist
among properties. A property is a sub-property of
another property if it is a specialization of the other.
We use eqðpÞ to represent the set of properties which
are equivalent to p, and supðpÞ to represent the set of
properties of which p is a sub-property.
Ontologies share a lot of similarities with enhanced
entity-relationship (EER) models in that concepts and
properties in ontologies are equivalent to entities and
relationships/attributes in EER models. However, they
are different in many aspects. For instance, various axi-
oms in ontologies, which EER models do not support,
enable automated reasonings over the data instances.
Readers can refer to [12] for the similarities and differ-
ences between ontology evolution and database schema
evolution.
2.2. Ontology instances
Each concept c has a set of instances IðcÞ ¼ fi1 ; . . . ; in g.
Note that a data instance of concept c can instantiate any
property whose domain is concept c, or any of its equiva-
lent or superclass concepts. For a concept c, any data
instances of its subclass or equivalent concepts are also
data instances of c.
Each ii 2 IðcÞ is a 4-tuple, ii ¼ hURI i ; c; DP ðcÞ; OP I ðcÞi,
such that
(1) URI i is a uniform resource identifier (URI) [25] by
which ii can be universally identified and other
instances can refer to it.
(2) c is the concept that ii is asserted to instantiate. When
a data instance instantiates more than one concept,
we say it instantiates the intersection of these
concepts.
(3) DP ðcÞ is a set of datatype property instantiations and
each dpi 2 DP ðcÞ takes a specific value vj , denoted as
ii : dpi ¼ vj , where vj has a specified primitive data
type as its domain.
(4) OP I ðcÞ is a set of object property instantiations, and
each opi 2 OP I ðcÞ where opi ðcÞ ¼ cj takes an instance
ij of concept cj as its value, denoted as ii : opi ¼ ij .
For example, assume http://patients.org/#AW is a data
instance of concept ‘patient’ with several properties instan-
tiated as follows:
‘http://patients.org/#AW’:name = ‘Amy White’,
‘http://patients.org/#AW’:insurance_type = ‘NJ Plus’,
and so on.
3. Changes to ontologies
Since structural and semantic changes to an ontology
have impact on the validity of data instances, we discuss
them in detail in this section.
3.1. Structural changes
Types of structural changes to ontologies. Given two
ontology versions o and o0 , the structural changes between
them, dðo; o0 Þ ¼ fd1 ; d2 ; . . . ; dn g are defined as operations to
transform o to o0 . Following is a list of possible structural
changes.
(1) Structural changes to a concept, dc: addition of a
concept ðdca Þ, deletion of a concept ðdcd Þ, renaming
a concept ðdcr Þ, splitting a concept ðdcs Þ, and merging
of concepts ðdcm Þ.
(2) Structural changes to a property of a concept, dp:
addition of a property ðdpa Þ, deletion of a property
ðdpd Þ, moving a property ðdpm Þ, modifying (the
range of) a property ðdpu Þ, and renaming a property
ðdpr Þ.
(3) Structural changes to a restriction, dr: addition of a
restriction ðdra Þ, deletion of a restriction ðdrd Þ, and
modifying a restriction ðdru Þ.
(4) Structural changes to an axiom, da: addition of an
axiom ðdaa Þ, and deletion of an axiom ðdad Þ.
Structural changes including split and merge operations
are also used in PromptDiff [13]. Though one may consider
modifying a property as a deletion of the property followed
by an addition, we prefer describing it as modifying a prop-
erty when the property involved refers to the same prop-
erty. Besides, when a property is modified, we mean the
range of the property has been modified, not the property
itself.
Let the ontology in Fig. 1 be o and that in Fig. 2 be o0 .
The following structural changes have occurred in o0
from o:
 The range of the ‘subclassOf’ property for concept ‘mon-
itoring device’ is modified from concept ‘treatment
device’ to concept ‘equipment’;
 Restriction ‘cardinality = 1’ is added to property ‘code’
of concept ‘health care personnel’;
 Property ‘specialty’ with string as its range is added to
concept ‘doctor’;
 Property ‘task_performed’ is moved from concept ‘treat-
ment device’ to concept ‘equipment’.
3.2. Semantic changes
A structural change such as Modifying the range of a
property does not indicate any semantic change. We need
to further examine the semantic change behind by deter-
 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
part_of
person
name, age,
address
subclassOf subclassOf
health care Patient
personnel ID, insurance_type
code, salary (insurance_plan),
cardinality(code)=1
billing_address
cardinality(ID)=1
subclassOf subclassOf
doctor nurse
specialty
Fig. 2. Another version of the ICU ontology in Fig. 1.
mining whether the new property range is more generalized
or specialized. Of course, each of the following semantic
changes is caused and reflected by certain structural
changes we have defined.
Types of semantic changes to ontologies. Given two
ontology versions o and o0 , the set of semantic changes
between them, denoted as Dðo; o0 Þ ¼ fD1 ; D2 ; . . . ; Dn g, may
include:
(1) Changes to the generalization of a concept, Dcg : A
concept becomes more generalized ðDcg" Þ or more
specialized ðDcg# Þ if it moves up or down in the con-
cept hierarchy, respectively. Otherwise, the general-
ization of a concept becomes incomparable ðDcgy Þ,
if it has changed, but become neither more general-
ized nor specialized.
Ontology changes which cause a concept to be more
specialized or incomparable will invalidate its
instances due to the semantic change to the concept.
On the other hand, if a concept becomes more gener-
alized, though the semantic change to the concept
does not invalidate any data instances, there is still
a possibility that some of its instances become inval-
idated as a result of the semantic changes to its
properties.
(2) Changes to the descriptiveness of a concept, Dcd : a
concept becomes more descriptive ðDcd" Þ or less
descriptive ðDcd# Þ if datatype properties or instance-
level object properties are added to or deleted from
the concept, respectively.
Ontology changes which make a concept less descrip-
tive may invalidate some instances. For instance, if a
property is deleted from a concept, all the data
instances that have instantiated this property will
become invalid.
87
ICU
part_of
equipment
task_performed,
dimensions
subclassOf subclassOf subclassOf
monitors monitoring treatment general
device device equipment
monitored_ channel_number
by
subclassOf
electrocardiograph
(3) Changes to the generalization of a property, Dpg ,
with its domain or range: a property becomes more
generalized ðDpg" Þ or more specialized ðDpg# Þ with
its domain (or range) if its domain (or range)
becomes a more generalized or specialized concept,
respectively. Otherwise, its domain or range becomes
incomparable ðDpgy Þ if it is modified in a way which is
neither more generalized nor specialized. Note that
the semantic change to the domain or range of a
property can be either explicit (its domain or range
has changed to a different concept) or implicit (its
domain or range concept has changed implicitly).
Ontology changes which make a property more spe-
cialized or incomparable may invalidate some
instances. For instance, the range of a property is
changed from concept c1 to c2 where c2 is more spe-
cialized than c1 . Instances which have an instance
of c2 as the property value (any instance of c2 is also
an instance of c1 ) are valid before or after the change.
However, those instances with an instance of c1 (but
not c2 ) as the property value will not be valid after the
semantic change.
(4) Changes to restrictiveness of a property, Dpr : A prop-
erty becomes more restrictive ðDpr" Þ or less restrictive
ðDpr# Þ if changes to the restrictions of the property
further restrict or extend its semantics, respec-
tively.Ontology changes which make a property more
restrictive may invalidate some instances which vio-
late the new restrictions.
(5) Changes to axiom over a property, Dpa : The axiom
over the property becomes more extended ðDpa" Þ or
more restricted ðDpa# Þ if changes to its axiom further
extend or restrict its semantics, respectively. An
example axiom, which extends the meaning of the
property, is the declaration of a property to be tran-
88 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
sitive, which leads to additional reasoning without
invalidating the reasoning prior to the declaration.
On the other hand, the declaration of a property to
be functional will invalidate the instantiations where
the value to this property is not unique. It does not
introduce any new reasoning results, either. As a
result, this change will restrict the meaning of the
property.
Note that each of the above semantic changes is the
result of one single structural change and they may not
be able to represent the semantic change caused by multiple
structural changes altogether. For instance, adding a prop-
erty to a concept makes the concept more descriptive and
deleting another property from it makes it less descriptive.
Another example is that, the domain of a property can
become more specialized while its range becomes more gen-
eralized. We do not provide a corresponding semantic
change to describe the combinational effects of these
changes. The reason is that each ontology change as well
as their impact on data instances can be examined sepa-
rately. Using the same example, adding a property to a
concept does not invalidate any data instances while delet-
ing another property can cause some data instances to be
invalid. We need to look at each change separately during
validity evaluation.
For the ontology versions in Figs. 1 and 2, the following
explicit semantic changes are detected based on the struc-
tural changes: concept ‘monitoring device’ has become
more generalized since its ‘subclassOf’ property has taken
a more generalized concept as its range; property ‘code’
of ‘health care personnel’ has become more restrictive;
addition of property ‘specialty’ to concept ‘doctor’ has
made it more descriptive; property ‘task_performed’ has
become more generalized since it is moved to a more gen-
eralized concept.
One may argue that concept ‘monitoring device’ has
become more specialized in some sense since it can no
longer include any instances of ‘treatment device’ while
previously some instances of ‘treatment device’ could have
been monitoring devices. Our point is that ‘monitoring
device’ potentially allows more instances after the change.
For instance, ‘monitoring device’ can only include some
instances of ‘treatment device’ before the change; After
the change, it can include instances of ‘equipment’ which
may not belong to ‘treatment device’.
We suggest the changes between ontologies be repre-
sented using the same ontology language for the ontologies
themselves. Ontologies for annotating these changes, such
as that in [8], can be developed. This is out of the scope
of this paper.
4. Detection of implicit semantic changes from explicit
semantic changes
While the explicit semantic changes can be detected
based on the structural changes, implicit semantic changes
need to be derived from explicit semantic changes by using
implication analysis.
To facilitate the implication analysis, we introduce the
notion of isosem. Each isosem is nothing but a cluster of
semantically dependent properties of the concept in an
ontology.
Definition 1 (Isosem). Given a concept c 2 CðoÞ, we define
an isosem SðcÞ as a set of properties, where
SðcÞ ¼ fp1 ; . . . ; pk g such that p1 ; . . . ; pk 2 P ðcÞ and for each
pi 2 SðcÞ, either pi is the only property in SðcÞ or pj 2 SðcÞ
if pj is an equivalent property or sub-property (specializa-
tion) of pi (or vice versa).
Isosems are categorized into definitional isosems and
descriptive isosems based on the type of properties they
contain, as defined below.
Definition 2 (Definitional isosem). A definitional isosem of
concept c, denoted as S fðcÞ, is an isosem consisting of class-
level object properties.
Definition 3 (Descriptive isosem). A descriptive isosem of
concept c, denoted as S s ðcÞ, is an isosem consisting of
instance-level object properties or datatype properties.
Fig. 3 shows an example of how isosems of a concept
‘patient’ in Fig. 1 are abstracted from the properties. This
concept has one definitional isosem, S f (patient), and four
descriptive isosems, S s1 (patient), S s2 (patient), S s3 (patient)
and S s4 (patient), each of which is indicated as an inner cir-
cle with its constituent properties enclosed. Note that prop-
erties ‘insurance_plan’ and ‘insurance_type’ are clustered
into the same isosem since they are equivalent properties.
If these two properties have any subproperties such as ‘pri-
mary insurance’ and ‘secondary insurance’, then all these
properties will be clustered into the same descriptive
isosem.
Sf
person
S1s subclassOf S4s
String
billing String
ID patient address
Insurance monitored_by
_plan
monitoring
Insurance
String
device
_type
String S3s
S2s
Fig. 3. Abstraction of isosems from properties.
 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97 89

4.1. Implication analysis property of another property in the same isosem,

then the subproperty will depend on the superprop-
By conducting an implication analysis, we can deduce erty. For example, a ‘parent’ concept can have prop-
whether and how the semantic changes to a property or erties such as ‘has_child’, ‘has_son’, etc, where
isosem imply semantic changes to the other properties or ‘has_son’ is a subproperty of ‘has_child’. Then
isosems. This implication analysis is the basis for detecting semantic changes to ‘has_child’ will affect ‘has_son’
implicit semantic changes and generating semantic views, as well.
which will be discussed in Section 6. (2) Inter-isosem Dependency: If the property within a def-
initional isosem has changed, the domain of each
(1) Intra-isosem Dependency: Two properties pi and pj in property in the descriptive isosems of the same con-
the same isosem are semantically dependent. That is cept has changed implicitly. That is, Dpi ) Dpj ,
Dpi ) Dpj , where pi ; pj 2 S i ðci Þ, as shown in where pi 2 S f ðci Þ and pj 2 S s ðci Þ, which is shown in
Fig. 4(a). For instance, for concept ‘patient’, ‘insur- Fig. 4(b).
ance_plan’ and ‘insurance_type’ are clustered into For instance, if the definitional isosem of concept ‘mon-
the same isosem since they are equivalent properties. itoring device’ has changed, it implies a change to the
Therefore, they are semantically dependent upon domain of each property in its descriptive isosems,
one another. However, if one property is the sub- including properties ‘monitors’ and ‘channel_number’.

Sf(ci)
dependent
cj
pi cj pi
ci Si(ci) dependent ck Ss(ci)
pj ck ci
pj cl

(a) Intra-isosem Dependency (b) Inter-isosem Dependency

Sf(ci)
Sis(ci) independent
ck
cj pi
pi dependent
ci
ck
ci Sjs(ci) Sf(cj)
pj pj
cl
cj

(c) Inter-isosem Independency (d) Inter-concept Def-Def Dependency

Sf(ci)
dependent
ck
pi dependent Ss(cj) pj
ci cj
cj pj ci Ss(cj) pi Ss(ci)

(e) Inter-concept Def-Des Dependency (f ) Inter-concept Des-Des Dependency

Sjs(ci) Sks(ck)
ci pj ck pk cl
pi pl

cm cn
Sis(ci) independent Sls(cl)

(g) Inter-concept Independency

Fig. 4. Implication analysis of semantic changes.

90 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
(3) Inter-isosem Independency: Changes to the properties
within an isosem imply no changes to the other isos-
ems of the same concept, if they belong to the same
category. Formally, Dpi ;Dpj , if pi 2 S fi ðci Þ and
pj 2 S fj ðci Þ, or pi 2 S si ðci Þ and pj 2 S sj ðci Þ, as indicated
in Fig. 4(c).
The reason for this independency is that properties of
these two isosems would have been clustered into the
same isosem if semantic dependency existed.
(4) Inter-concept Def–Def Dependency: If the property in
a definitional isosem has changed, the property in the
definitional isosem of the child concepts has changed
implicitly, which is shown in Fig. 4(d). Formally,
Dpi ) Dpj , if pi 2 S f ðci Þ and pj 2 S f ðcj Þ, where cj is
a child concept of ci .
For instance, in the ontology versions shown in
Figs. 1 and 2, property ‘subclassOf’ in the definitional
isosem of concept ‘monitoring device’ has changed.
Concept ‘electrocardiograph’ is a child of ‘monitoring
device’. As a result, an implicit change is implied to the
definitional isosem of concept ‘electrocardiograph’.
(5) Inter-concept Def–Des Dependency: If the definitional
isosem of a concept has changed, the range of each
property in the descriptive isosem of another concept
has changed implicitly, if this property takes the for-
mer concept as its range, and belongs to a descriptive
isosem of the latter concept. This is depicted in
Fig. 4(e). Formally, Dpi ) Dpj , if pi 2 S f ðci Þ and
pj 2 S s ðcj Þ, where pj ðcj Þ ¼ ci . For instance, concept
‘patient’ has a descriptive isosem containing property
‘monitored_by’ and taking concept ‘monitoring
device’ as its range. Then changes to the definitional
isosem of ‘monitoring device’ imply changes to this
descriptive isosem of concept ‘patient’.
(6) Inter-concept Des–Des Dependency: If two descriptive
isosems contain semantically dependent properties, at
least one of the isosems is dependent on the other.
That is, Dpi ) Dpj where pi 2 S s ðci Þ; pj 2
s value taken by the property belongs to the range of
S ðcj Þ; ai ðpi Þ ¼ pj ðor aj ðpj Þ ¼ pi Þ, which is shown in
Fig. 4(f).In Fig. 1, the ‘billing_address’ property of
concept ‘patient’ is a sub-property of the ‘address’
property of concept ‘person’, and concept ‘person’
is the parent of concept ‘patient’. Then, changes to
the isosem containing ‘address’ property imply
changes to the isosem containing ‘billing_address’.
As another example, ‘monitored_by’ property of
‘patient’ is inverse of ‘monitors’ property of ‘monitor-
ing device’, each of which constitutes an isosem. Then
changes to one imply changes to the other.
(7) Inter-concept Independency: With Inter-concept Des–
Des Dependency as the exception, if concept ci is
indirectly associated with cl through ck , then the
semantics of ci is independent of changes to concept
cl if the isosem between ci and ck does not
change. Generally, as shown in Fig. 4(g), Dpi ;Dpl
where pi 2 S si ðci Þ; pl 2 S sl ðcl Þ; pj 2 S sj ðci Þ and pj ðci Þ ¼
ck ; pk 2 S sk ðck Þ and pk ðck Þ ¼ cl .
For example, ‘person’ and ‘monitoring device’ are
indirectly associated concepts, changes to the descrip-
tive isosems of ‘monitoring device’ do not affect any
descriptive isosems of ‘person’.
5. Structural and semantic validity
In this section, we show how changes detected to an
ontology can be used in evaluating the structural validity
and semantic validity of a data instance.
5.1. Structural validity
Structural changes to an ontology affect the structural
validity of its data instances. In this section, we define the
structural validity and propose how it can be evaluated.
Given a data instance and an ontology, we can evalu-
ate whether this data instance is structurally valid with
respect to this ontology. Obviously, if a data instance is
structurally valid against the old version of an ontology
but not structurally valid against the new version, then
the structural changes to the ontology invalidate the data
instance. Alternatively, if a data instance is structurally
valid against one version of the ontology, its structural
validity against a different ontology version can also be
evaluated based on the structural changes between the
two versions.
Definition 4 (Structural validity of data instances). A data
instance i 2 IðcÞ is structurally valid against an ontology o,
if the following conditions hold:
(1) Concept c exists in ontology o, i.e. c 2 CðoÞ;
(2) Each property instantiated by instance i belongs to
the instantiated concept c by either explicit specifica-
tion or inheritance in the ontology;
(3) For each property instantiated by instance i, the
the property and satisfies the restrictions of the
property.
As an example, if a property p is specified to concept c1
in the old version and moved to concept c2 in the new
version, then the data instances of concept c1 with property
p instantiated are not structurally valid against the new
version of the ontology unless c1 can inherit property p
from c2 .
Using our example ICU ontology, for an instance of
‘patient’ with property ‘monitored_by’ instantiated, the
instance is valid if this property takes a data instance of
‘monitoring device’ or ‘electrocardiograph’ as its value.
Note that we only require that the range of the property
is asserted to be an instance of concept ‘monitoring device’
or ‘electrocardiograph’. However, whether this property
value is structurally or semantically valid does not matter
to evaluating the validity of this instance of ‘patient’. Of
 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
course, this data instance of ‘patient’ will not be structur-
ally valid if it takes an instance of concepts such as ‘general
equipment’.
Algorithm 1 gives the detailed steps to evaluate the
structural validity of a data instance.
Algorithm 1
Evaluating the structural validity of data instances
½StructValidði; oÞ
Require: Data instance i 2 IðcÞ; i instantiates property
p, ontology o
StructValidði; oÞ ¼ truefdefault valueg
{Evaluating the structural validity of a data
instance i against an ontology o}
if c is a concept in ontology o then
for each p instantiated by instance i do
if p does not belong to concept c or any of its
superclass or equivalent concepts, OR the value taken
by p does not belong to the range of p or does not sat-
isfy the restrictions then
StructValidði; oÞ ¼ false
end if
end for
else
StructValidði; oÞ ¼ false
end if
Assume a data instance of the concept ‘patient’ in
ontology shown in Fig. 1 has properties ‘ID’, ‘name’,
‘insurance_type’ and ‘monitored_by’ instantiated. If con-
cept ‘patient’ or any of these instantiated properties are
deleted from the ontology, then this data instance will
not be structurally valid against the new version of the
ontology.
5.2. Semantic validity
Data instances can be interpreted correctly only if they
are semantically valid with respect to the ontology they
comply with. Their semantic validity need to be evaluated
when semantic changes take place to the ontology that they
comply with. Given that a data instance is semantically
valid to an ontology, we are interested in finding out how
semantic changes to this ontology affect the validity of its
data instance.
Definition 5 (Semantic validity of data instances). A data
instance i 2 IðcÞ where c 2 CðoÞ, is semantically valid
against o0 where c0 2 Cðo0 Þ, if the following conditions
hold:
(1) Data instance i is structurally valid against o0 , i.e.
StructValidði; o0 Þ ¼ true;
(2) Concept c does not get more specialized or
incomparable;
91
(3) For each instantiated property p, the axiom over p
does not get more restricted.
The structural validity is the prerequisite for the
semantic validity. However, the structural validity does
not necessarily lead to the semantic validity. For instance,
structural validity warrants that the data instance can
instantiate a concept. However, if this concept has
become more specialized, this data instance may no
longer be semantically valid. Though one should be able
to determine whether an instance is structurally valid
for an ontology irrespective of other ontology versions,
the semantic validity of a data instance can be evaluated
with the semantic changes between two versions of the
ontology given, on the basis of the structural validity.
In Algorithm 2, we show how to evaluate whether a data
instance i is semantically valid against a new version of an
ontology o0 , given that it is semantically valid against its
old version o and the semantic changes between the two
versions, Dðo; o0 Þ.
Algorithm 2
Evaluating the semantic validity of data instances
½SemValidði; o0 Þ
Require: Data instance i 2 IðcÞ; i instantiates property
p, ontology o and o0 ; Dðo; o0 Þ
SemValidði; o0 Þ ¼ true {default value}
{Evaluating the semantic validity of a data instance
i against ontology o0 }
if StructValidði; o0 Þ ¼ true then
if c0 has not become more specialized than c or
incomparable then
for each p instantiated by instance i do
if axiom over p gets more restricted then
SemValidði; o0 Þ ¼ false
end if
end for
else
SemValidði; o0 Þ ¼ false
end if
else
SemValidði; o0 Þ ¼ false
end if
For the ontology versions shown in Figs. 1 and 2, con-
sider the semantic validity of a data instance of concept
‘monitoring device’. The semantic changes between the
ontology versions include that this concept has become
more generalized. In this case, the data instance which is
semantically valid against the old version will be semanti-
cally valid against the new version except that they may
become invalidated due to semantic changes to the proper-
ties. On the other hand, if a concept becomes more special-
92 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
ized, then instances of this concept, which are semantically
valid for the old version, will be determined by the algo-
rithm as semantically invalid for the new version and
may be subject to further human analysis.
Instances are inter-related; however, as we mentioned in
discussing structural validity, a semantically invalid
instance does not invalidate its related instances simply
because they take a semantically invalid instance as the
property value. Evaluating semantic validity will become
impossible otherwise.
6. Validation using semantic view
Note that each data instance only instantiates part of an
ontology. Therefore, not all the changes to the ontology
have an impact on a particular data instance. Starting with
the ontology against which a data instance is semantically
valid, we call the part of this ontology whose semantic
change affects this data instance as the semantic view of
the ontology for this data instance.
The significance of the semantic view is that the seman-
tic validity of a data instance depends only on a portion of
the ontology, i.e. the semantic view, rather than the entire
ontology. As a result, changes to components outside the
semantic view will not affect the semantic validity of the
data instance and thus can be ignored during the
evaluation.
For a specific data instance, its semantic view in the
ontology not only includes the components that it instanti-
ates, but also any other components whose changes implic-
itly affect the instantiated components based on the
implication analysis presented in Section 4.1.
6.1. Semantic view
Definition 6 (Semantic view for a data instance). The
semantic view of an instance ii in its ontology oi , denoted
as SV ðii ; oi Þ, consists of all the components in oi whose
changes may lead to SemValidðii ; o0i Þ ¼ false.
Identifying the semantic view needs the knowledge of
implication analysis, i.e. the dependencies and independen-
cies between the components in the ontology. Below is how
the semantic view can be generated for a data instance.
6.1.1. Identifying the semantic view for a data instance
Given the instantiated concept, c, for a data instance i,
and all the instantiated properties of i; P ðiÞ, we perform
the following steps.
(1) Find the equivalent concepts of c; eqðcÞ, and the
superclass concepts of c; supðcÞ. Essentially, we apply
the Inter-concept Def–Def Dependency and Inter-
isosem Dependency.
For instance, consider the ontology in Fig. 1 for a
data instance of concept ‘patient’ with all the proper-
ties of ‘patient’ instantiated. Concept ‘person’ is
included in this step for the semantic view. This is
because, semantic changes to the properties in the
definitional isosem of ‘person’ would imply semantic
changes to those in the definitional isosem of ‘patient’
based on Inter-concept Def–Def Dependency; Based
on Inter-isosem Dependency, changes to the proper-
ties in the definitional isosem of ‘patient’ imply
semantic changes to its datatype properties and
instance-level object properties, which are instanti-
ated by this data instance of ‘patient’.
(2) For each object property instantiated by i where ck is
the range of this property, find the equivalent con-
cepts of ck ; eqðck Þ, and their superclass concepts,
supðck Þ. That is, we employ the Inter-concept Def–
Des Dependency and Inter-concept Def–Def Depen-
dency.
Consider the same data instance of ‘patient’. Based on
Inter-concept Def–Des Dependency, semantic changes
to the properties in definitional isosem of ‘monitoring
device’ imply changes to the isosem consisting of prop-
erty ‘monitored_by’ of ‘patient’ concept. Therefore,
concept ‘monitoring device’ should be included in the
semantic view. Furthermore, changes to the properties
in the definitional isosem of the superclass concepts
including ‘treatment device’ and ‘equipment’ imply
changes to those of ‘monitoring device’ based on
Inter-concept Def–Def Dependency. Concepts
obtained in this step include concepts ‘monitoring
device’, ‘treatment device’, and ‘equipment’.
(3) For each property p instantiated by i, find the equiv-
alent properties of p; eqðpÞ, their inverse properties,
denoted as invðpÞ, and their superproperties, supðpÞ.
These properties may belong to the same concept as
p or any concept in the set obtained in step 1 and 2.
This is based on Intra-isosem Dependency and
Inter-concept Des–Des Dependency.
For our example, the properties obtained in this step
include property ‘address’ where subpropertyOf(bill-
ing_address) = address and property ‘monitors’ where
inverseOf(monitors) = monitored_by. Semantic changes
to these properties imply changes to those of ‘patient’
based on Inter-concept Des–Des Dependency.
(4) The semantic view of ontology o for data instance i
consists of the concepts obtained in steps 1 and 2
(along with the class-level object properties among
them), the properties obtained in step 3 along with
their restrictions and axioms.
By applying all the dependencies in our implication anal-
ysis, all the ontology components in the semantic view for a
specific data instance are relevant to the semantic validity of
the data instance. All the other components of the ontology,
based on the Inter-isosem Independency and Inter-concept
Independency, do not affect the semantic validity of this
instance and therefore are not part of the semantic view.
This naturally leads to the following theorem:
 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97 93

Theorem 1. [Completeness and minimality of the semantic
view] The semantic view for a data instance includes all
(completeness) and only (minimality) the ontology components
which can affect the semantic validity of the data instance.
Proof. Based on our implication analysis, ontology compo-
nents in the semantic view are identified through the follow-
ing dependencies: Intra-isosem Dependency, Inter-isosem
Dependency, Inter-concept Def–Def Dependency, Inter-
concept Def–Des Dependency, and Inter-concept Des–Des
Dependency. Other ontology components are excluded from
the semantic view based on the following independencies:
Inter-isosem Independency, and Inter-concept Independency.
For a data instance i which instantiates concept ci and
property p from ontology o ðcj is the range of property p if
p is an object property). h
6.1.2. Proof for minimality
 Based on Inter-isosem Dependency and Inter-concept
Def–Def Dependency. ci ; eqðci Þ; supðci Þ 2 SV ði; oÞ
(including the class-level object properties among
them).The Inter-isosem Dependency indicates the defini-
tional isosem of concept ci affects its descriptive isosems,
consisting of instance-level properties instantiated by
any data instance of ci . Also, based on Inter-concept
Def–Def Dependency, eqðci Þ and supðci Þ have to be
included in the semantic view since changes to these con-
cepts may imply changes to ci .
 Based on Inter-concept Def–Des Dependency and Inter-
concept Def–Def Dependency. cj ; eqðcj Þ; supðcj Þ 2 SV
ði; oÞ (including the class-level object properties among
them).
cj is in the semantic view based on Inter-concept Def–Des
Dependency since changes to the definitional isosem of cj
imply changes to p. Again, eqðcj Þ and supðcj Þ are included
in the semantic view based on Inter-concept Def–Def
Dependency.
 Based on Intra-isosem Dependency and Inter-concept
Des–Des Dependency, p; eqðpÞ; supðpÞ; invðpÞ 2 SV ði; oÞ
(including their restrictions and axioms).
In addition to property p, other related properties
including eqðpÞ; supðpÞ, and invðpÞ are in the semantic
view based on Intra-isosem Dependency if they have
concept ci as the domain or based on Inter-concept
Des–Des Dependency if they have a different concept
as the domain.
By applying all the dependencies, we have shown that all
the ontology components in the semantic view are rele-
vant to the semantic validity of the data instance. In
other words, no component that is not relevant has been
included in the semantic view, and therefore we prove
the minimality.
6.1.3. Proof for completeness
 On the other hand, any other concepts and properties
along with their restrictions and axioms R SV ði; oÞ. This
is because, any other isosems of concept ci or any other
concept have no impact on the data instance based on
Inter-isosem Independency or Inter-concept Indepen-
dency.
This means that the semantic view has included all the
ontology components relevant to the semantic validity
of the data instance, and therefore we prove the complete-
ness of the semantic view.

ICU
part_of part_of

person equipment
name, age, address task_performed,
dimensions

subclassOf subclassOf
subclassOf subclassOf
treatment
patient device general
health care ID, task_ equipment
personnel insurance_type performed
code, salary (insurance_plan), monitors subclassOf
billing_address
cardinality(ID)= monitored_ monitoring
subclassOf 1 by device
subclassOf channel_number

doctor nurse subclassOf

electrocardiograph

Fig. 5. The semantic view of the ontology in Fig. 1 for a data instance of concept ‘patient’.
94 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
part_of
person
name, age, address
subclassOf subclassOf
health care Patient
personnel ID,
code, salary insurance_type
cardinality(code)= (insurance_plan),
1 billing_address monitored_by
subclassOf cardinality(ID)=
1 subclassOf
subclassOf
doctor nurse
specialty
Fig. 6. The semantic view of the ontology in Fig. 2 for a data instance of concept ‘patient’.
The semantic view thus obtained for the ‘patient’
instance is shown in Figs. 5 and 6 as the components within
the region of the curve. One can see that the semantic view
for this data instance is different when the ontology evolves
from Fig. 1 to Fig. 2.
Two instances will share the same semantic view if
they instantiate the same concept and properties in the
same ontology. Also, the semantic view for a data
instance will change when the instantiated components
of the data instance change. However, changes to the
specific values of the properties do not affect the semantic
view if the same properties are still instantiated by the
data instance.
As a note, the semantic view for a data instance will
include only the components relevant to the validity of
the data instance. Considering the independencies we pre-
sented in Section 4.1, the semantic view will not end up
to be the entire ontology. So, identifying the semantic view
becomes even more significant when the ontology is much
larger than the semantic view.
6.2. Change identification using semantic view
Our previous discussion of validity evaluation is based
on the assumption that both versions of the ontologies
are available. However, in a distributed and decentralized
environment such as the Semantic Web, there cannot be
such guarantees since the old version of an ontology may
be substituted by a new version and no notification can
be sent to entities where its data instances reside. In such
a case, the authors of data instances are concerned that
the semantics of data instances cannot be correctly inter-
preted based on the new version. Therefore, they would
like to identify whether the ontology has silently changed
ICU
part_of
equipment
task_performed,
dimensions
subclassOf subclassOf
subclassOf
monitors
monitoring treatment general
device device equipment
channel_number
electrocardiograph
in a way that affects the interpretation of their data
instances. On the other hand, from the perspective of the
consumers of these data instances, an interpretation, which
is not intended by the authors of data instances, is defi-
nitely undesirable. Therefore, the question is, how can
the silent changes to an ontology be identified? In this sec-
tion, we present our approach of using the semantic view to
address this problem.
When a data instance is created, it is semantically valid
with respect to its ontology. We suggest each data
instance carry a hash value of its semantic view at its cre-
ation. When the consumers attempt an interpretation of
this data instance, they identify its semantic view based
on the current version of the ontology, compute its hash
value and compare the hash value with that stored locally
by the data instance: if these two hash values match, it
means that the semantic view has not changed and thus
the data instance can be interpreted safely with the ontol-
ogy. When the hash values do not match, we cannot tell
exactly whether the data instance is still valid. The reason
is that this will require the knowledge of the changes
between the two versions, which can be obtained by find-
ing changes between two ontology versions structurally
[14] and semantically [17]. When the ontologies do not
change frequently, this hash value can provide a quick
assurance for the validity of the data instance. The hash
value should be based on an unordered hashing of the
RDF triples of its semantic view. Some existing algorithm
for computing the digest of an RDF/OWL graph [24,1,10]
can be adopted.
The author of a data instance can further specify how
the data instance should be interpreted when the computed
hash value for the semantic view does not match with the
locally stored one. One can specify one of the following
two options.
 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
(1) Cascaded: This means the data instance can be inter-
preted according to the new version of the ontology.
If this option is taken, the data instance may need to
be modified to remain valid against the new version
of the ontology. This can be opted if the ontology
is from a trusted source and the author of the data
instance would like the data instance to change with
the ontology.
(2) Rejected: This means the data instance cannot be
interpreted based on the new version of the ontology.
If this option is taken, the data instance will be
unavailable to its consumers. This can be opted when
the ontology is from an untrusted source.
7. Implementation discussion
Our algorithms themselves do not support reasonings
over ontologies, but exploit the reasoning services provided
by a reasoner. RacerPro [23], a Semantic Web reasoning
system, can act as the back-end inference server for pro-
cessing queries over OWL Lite and OWL DL. We use
RacerPro as a tool in implementing our approaches though
RacerPro does not determine validity by itself. The ontol-
ogies we use are represented in OWL, which is the most
popular ontology language. RacerPro provides Lisp-based
and Java-based APIs for building clients to access Racer-
Pro via TCP/IP.
Figs. 7 and 8 depict the architecture for implementing
our approach to evaluating the validity and to identifying
the semantic view for an instance, respectively. The Struc-
tural (Semantic) Validator in Fig. 7 and SemView Genera-
tor in Fig. 8 are clients which interact with the reasoning
server. As shown in Fig. 7, the ontologies and instances
are loaded into the reasoner first. In order to evaluate the
validity of a data instance, the Structural (Semantic) Vali-
dator needs to interact with a reasoner in which the Valida-
tor sends reasoning queries to the reasoner and receives
answers back from the reasoner. Similarly, as shown in
Fig. 8, the SemView Generator also needs the reasoning
services provided by a reasoner to identify the semantic
view for a given data instance and ontology. Examples of
Structural
(Semantic) Instance Ontologies
Changes
1 1
2 2
Reasoner
e.g. RacerPro
3 4
5 StructValid
Structural (Semantic) Validator (SemValid)
Fig. 7. Implementation architecture for validity evaluation for an instance.
95
Instance Ontology
1
1 Reasoner
2
e.g. RacerPro
3 4
5 Semantic
SemView Generator View
Fig. 8. Implementation architecture for identifying the semantic view for
an instance.
reasoning queries in our algorithms include, What are the
superclass (ancestor) concepts of a concept? What is the
inverse property of a given property? and so on. The API
functions used in our discussion below belong to JRacer
library (Java-based).
More specifically, to evaluate the structural validity of a
data instance against an ontology, the concept it instanti-
ates can be identified using RacerPro API function such
as individual-direct-types. API function concept can be used
to evaluate whether the concept belongs to the ontology or
not. Then, for each property instantiated by the data
instance, API function role-domain can be used to test
whether the property belongs to the concept or any of its
equivalent or superclass concepts. RacerPro can determine
the subsumption or equivalence between two concepts
through functions concept-subsumes and concept-equiva-
lent, respectively. For an object property of a data instance,
similar evaluations can be done for the instance taken as
the value of the property. RacerPro can automatically test
whether the value to a datatype property belongs to the
specified primitive data type. On the basis of the structural
validity, the semantic validity of a data instance against a
new version of an ontology can be evaluated with the
semantic changes provided as input.
When identifying the semantic view for a data instance,
the concept of the data instance can be identified through
API function individual-direct-types, its equivalent concepts
and superclass concepts can be identified through API
function concept-synonyms and concept-ancestors, respec-
tively. Similarly, the concept as the range of an object prop-
erty of the data instance can be identified along with its
own equivalent concepts and superclass concepts. For each
property of the data instance, the semantic view will also
include its equivalent properties identified through role-
synonyms, its superproperties identified through role-ances-
tors, and its inverse property identified through role-
inverse. We did not find API functions to retrieve all the
restrictions or axioms over a specific property; However,
RacerPro provides capabilities of querying about the char-
acteristics of a given property, e.g. transitive-p can deter-
96 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
mine whether the property is transitive or not. These con-
cepts, the taxonomy/associations among them along with
their restrictions and axioms are part of the semantic view.
8. Related work
Most related work on detecting changes to ontologies
concentrates on finding structural changes between ontol-
ogy versions. OntoView [6,7] is a web-based ontology ver-
sioning management system, in which structural changes
are identified by rules. It allows the ontology engineers to
compare versions of ontology, and to specify whether
(but not how) these structural changes entail any concep-
tual implications. PromptDiff [14,15] is a tool that utilizes
heuristics for matching components of ontology versions.
It integrates different heuristics matchers for comparing
ontology versions, where the matchers conform to monoto-
nicity principle, i.e. no matchers retract the results of previ-
ous matchers or its own results from previous runs. The
outcome of the algorithm is a structural diff, consisting of
frame pairs which are images of each other from different
versions or one of them is null. The change types are
described as changed, unchanged and isomorphic. Noy
and Klein [12] discussed how structural changes in ontolo-
gies affect the preservation of their data instances. Research
complementary to detecting changes to ontologies can be
found in finding similarities between independently devel-
oped ontologies for the purposes of merging and aligning
ontologies. Examples of such tools include Prompt [13],
GLUE [2], etc. Mitra et al. [11] presented an ontology map-
ping approach using Bayesian Network.
The above work, however, is limited to detecting
changes at structural level, but does not address detecting
changes occurring at the semantic level. Detecting changes
at the semantic level is crucial since ontologies are consid-
ered as a means for presenting semantics. Typically, seman-
tic changes are not clearly distinguishable from structural
changes in the existing work. For example, if the range to
a property is changed in the new version to a subclass of
the concept in the old version, the range of the property,
therefore certain semantic aspect of the concept owning
the property, becomes narrowed. This change should not
be described and treated as a structural change only.
Heflin and Hendler [4] presented SHOE, a web-based
knowledge representation language that supports multiple
versions of ontologies and discussed how the features of
SHOE address ontology versioning. More specifically, the
authors analyzed scenarios for semantic subsumption at
the ontology level. Compatibility between ontology ver-
sions was also discussed in [5] by assuming that the data
source that conforms to a specific version of the ontology
uses the whole ontology. Though it mentioned the possibil-
ity that an incomparable revision may not affect the inter-
pretation of a data source which uses the ontology part
unaffected by the revision, it lacks a close examination of
the implication within the ontology. The compatibility
measured at the ontology level [4,5] is too coarse-grained
for the diversity of changes which concurrently occur to
an ontology, noting that instantiation is done at a fine-
grained level of concepts and properties. Even the limited
discussion on describing semantic changes is confined to
equivalence and subsumption between concepts. Further-
more, changes to an ontology are examined mainly by con-
sidering each individual concept in isolation. As a result,
this analysis lacks an examination of the semantics of a
concept in relation to other associated concepts and there-
fore is not capable of analyzing the implication of the
semantic changes.
Noy and Klein [12] presented a systematic discussion on
the differences between ontology evolution and schema evo-
lution. Klen and Noy [8] described a framework integrated
with different representations of the changes between ontol-
ogy versions and the transformation from one representa-
tion to another. An ontology of (structural) change
operations was also presented. Klen and Stuckenschmidt
[9] discussed how the changes in one ontology affect another
ontology which uses concepts defined in the changed ontol-
ogy and reasonings based on the imported concept hierar-
chy. In particular, it studied how changes to the concept
hierarchy of the external ontology affect the validity of the
compiled subsumption relations which are added as axioms
to the local ontology.
Recently, [21] investigated how the semantic changes to
an ontology can be evaluated and detected. It proposes a
SemDiff algorithm that first detects explicit semantic
changes based on the structural changes and then detect
implicit semantic changes implied by other semantic
changes. However, it did not address the issue of structural
and semantic validity. In this paper, we exploited the types
of structural and semantic changes detected to verify
whether the instances are structurally and semantically
valid when the ontologies change.
We propose using hashing of values of the semantic view
in our change identification approach. Hashing a RDF/
OWL document can be done very efficiently. The complexity
of hashing in [24] is O(N) and that of [1,10] is O(NlogN).
Qin and Atluri [19,22] proposed utilizing ontologies in
guiding the change detection to the data instances under
the Semantic Web, and [20] proposed a methodology by
exploiting the semantic relationships among concepts to
specify access control policies such that undesired inference
of unauthorized information can be prevented.
9. Conclusions and future work
Ontologies are formal, explicit specifications of shared
conceptualizations that evolve over time. Changes to an
ontology may occur at two levels – structural and semantic.
When an old version of an ontology is substituted by a new
one, data instances that comply with the old version of the
ontology may become invalidated, and therefore be irre-
trievable and non-interpretable. Therefore, it is essential
to verify if the data instances are still valid under the new
version of the ontology.
 L. Qin, V. Atluri / Information and Software Technology 51 (2009) 83–97
In this paper, we have proposed approaches to verify both
structural validity and semantic validity of data instances.
We have also proposed the semantic view of an ontology
for a data instance as the portion of an ontology whose
changes directly or indirectly affect the validity of the data
instance. We have discussed how the semantic view can be
identified through implication analysis. Besides, by storing
a hash value of the semantic view, one can quickly identify
whether the ontology has changed, so that they can be pre-
vented from making any erroneous interpretation.
As part of our future work, we intend to address the
issue of efficiently propagating ontology changes to its data
instances and dependent ontologies.
References
[1] J. Carroll, Signing RDF graphs, Lecture Notes in Computer Science,
vol. 2870, Springer-Verlag, 2003.
[2] A. Doan, J. Madhavan, P. Domingos and A. Halevy, Learning to
map between ontologies on the Semantic Web, in: Proceedings of the
World-Wide Web Conference (WWW), 2002.
[3] T.R. Gruber, A translation approach to portable ontologies, Knowl-
edge Acquisition 5 (2) (1993) 199–220.
[4] J. Heflin, J. Hendler, Dynamic ontologies on the Web, in: Proceedings
of the 17th National Conference on Artificial Intelligence (AAAI-
2000), AAAI/MIT Press, Menlo Park, CA, 2000, pp. 443–449.
[5] M. Klein, D. Fensel, Ontology versioning for the Semantic Web, in:
Proceedings of the International Semantic Web Working symposium
(SWWS), Stanford University, California, USA, 2001, pp. 75–91.
[6] M. Klein, D. Fensel, A. Kiryakov and D. Ognyanov, Ontology
versioning and change detection on the Web, in: 13th International
Conference on Knowledge Engineering and Knowledge Management
(EKAW02), 2002.
[7] M. Klein, A. Kiryakov, D. Ognyanov and D. Fensel, Finding and
characterizing changes in ontologies, in: Proceedings of the 21st
International Conference on Conceptual Modeling (ER2002), Tam-
pere, Finland, 2002, pp. 79–89.
[8] M. Klein and N.F. Noy, A Component-based framework for
ontology evolution, in: Proceedings of the Workshop on Ontologies
and Distributed Systems, IJCAI’03, Acapulco, Mexico, 2003.
97
[9] M. Klein and H. Stuckenschmidt, Evolution management for
interconnected ontologies, in: Workshop on Semantic Integration at
ISWC 2003, Sanibel Island, Florida, 2003.
[10] S. Melnik, RDF API draft: Cryptographic digests of RDF models and
statements, http://www-db.stanford.edu/melnik/rdf/api.html#digest.
[11] Prasenjit Mitra, Natasha N. Noy and A.R. Jaiswal, Ontology
mapping discovery with uncertainty. Fourth International Semantic
Web Conference (ISWC), Galway, Ireland, November 8–10, 2005.
[12] N.F. Noy, M. Klein, Ontology evolution: not the same as schema
evolution, Knowledge and Information Systems 5 (2003).
[13] N.F. Noy and M.A. Musen, PROMPT: algorithm and tool for
automated ontology merging and alignment, in: Seventeenth National
Conference on Artificial Intelligence (AAAI2000), 2000.
[14] N.F. Noy and M.A. Musen, PromptDiff: a fixed-point algorithm for
comparing ontology versions, in: Proceedings of the National
Conference on Artificial Intelligence (AAAI), 2002.
[15] N.F. Noy, M.A. Musen, The PROMPT suite: interactive tools for
ontology merging and mapping, International Journal of Human-
Computer Studies 59 (6) (2003) 983–1024.
[16] N.F. Noy, M.A. Musen, Specifying Ontology Views by Traversal,
Third International Semantic Web Conference (ISWC2004), Hiro-
shima, Japan, 2004.
[17] N.F. Noy, S. Kunnatur, M. Klein, M.A. Musen, Tracking changes
during ontology evolution. Third International Semantic Web Con-
ference (ISWC2004), Hiroshima, Japan, 2004.
[18] OWL Web Ontology Language Guide. Available at http://
www.w3.org/TR/owl-guide/.
[19] L. Qin and V. Atluri, Ontology-guided change detection to the
Semantic Web data, in: 23rd International Conference on Conceptual
Modeling (ER 2004), pp. 624–638.
[20] L. Qin and V. Atluri, Concept-level access control for the Semantic
Web. ACM Workshop on XML Security, held in conjunction with
the 10th ACM Conference on Computer and Communications
Security, October 2003.
[21] L. Qin, V. Atluri, SemDiff: an approach to detecting semantic changes
to ontologies, International Journal of Semantic Web and Informa-
tion Systems 2 (4) (2006) 1–32.
[22] L. Qin, V. Atluri, An ontology-guided approach to change detection
of the Semantic Web data, Journal on Data Semantics V (2006) 130–
157, LNCS 3870.
[23] RacerPro, http://www.racer-systems.com.
[24] C. Sayers and A.H. Karp, Computing the Digest of an RDF Graph,
Technical Report HPL-2003-235, 2003.
[25] http://www.w3.org/Addressing/.