Detecting Ontological Conflicts in Protocols between Semantic Web Services

International Journal of Web & Semantic Technology (IJWest) Vol.1, Num.4, October 2010
Detecting Ontological Conflicts in Protocols between
Semantic Web Services
Priyankar Ghosh and Pallab Dasgupta
Department of Computer Science and Engineering,
Indian Institute of Technology Kharagpur, India
{priyankar, pallab}@cse.iitkgp.ernet.in
Abstract. The task of verifying the compatibility between interacting web services has tra-
ditionally been limited to checking the compatibility of the interaction protocol in terms of
message sequences and the type of data being exchanged. Since web services are developed
largely in an uncoordinated way, different services often use independently developed ontolo-
gies for the same domain instead of adhering to a single ontology as standard. In this work we
investigate the approaches that can be taken by the server to verify the possibility to reach a
state with semantically inconsistent results during the execution of a protocol with a client,
if the client ontology is published. Often database is used to store the actual data along with
the ontologies instead of storing the actual data as a part of the ontology description. It is
important to observe that at the current state of the database the semantic conflict state
may not be reached even if the verification done by the server indicates the possibility of
reaching a conflict state. A relational algebra based decision procedure is also developed to
incorporate the current state of the client and the server databases in the overall verification
procedure.
1 Introduction
Ontology is regarded as a formal specification of a (usually hierarchical) set of concepts and the
relations between them. The need for developing intelligent web services that can automatically
interact with other web services has been one of the primary forces behind recent research towards
standardization of ontologies of specific domains of interest [1, 2, 3, 4, 5]. For example, if several
online book stores follow the same ontology for the book domain, then it facilitates an intelligent
web service to automatically search these book stores to find books in a particular category.
In the context of next generation of web, it is envisaged that intelligent agents will find, combine,
and act upon information on the web, thereby perform the routine day-to-day jobs independently.
The protocols that will be used by such intelligent agents to communicate with the semantic
web services, will play an extremely important role towards materializing the next generation of
web. The protocol may contain branches which are decisions made on the basis of the previous
information exchange. Along with defining the information exchange between the client and server
in the form of a set query-answer, independent actions will be described as a part of the protocol.
The action may be automatically executed or may need manual intervention for completion, but
the information required to initiate the action is provided by answer of the previous queries. We
present an example of such protocol in Section 2.
When two communicating web services use ontologies, with respect to semantic conflict the
following scenarios are possible.
Scenario-1 : If the web services choose to use the same ontology, there will be no semantic conflict.
In this paper we observe that the requirement that the ontologies used by communicating web
services must match is a very strong requirement which is often not needed in practice.
Scenario-2 : If two communicating web services use different ontologies, then they may poten-
tially reach a state where there is a semantic conflict/mismatch arising out of the differences
between their ontologies. For example, suppose the ontologies of web service A and web service
B recognize the class vehicle and its sub-classes, namely, car, truck and bike. The ontology of
DOI : 10.5121/ijwest.2010.1403 28

A defines color as an attribute of class vehicle, where as the ontology of B defines color as an
attribute of the sub-classes car and bike only. Now suppose A wants to follow the following
protocol with B:
Step-1: Ask B for the registration number of a vehicle which is owned by a given person.
Step-2: If B finds the registration number, then ask B for the color of the vehicle.
Several executions of this protocol are possible for different valuations of the data exchanged
by the protocol. Semantic conflicts arising out of the differences in ontologies may occur in
some of these cases, but not always. For example:
– If B does not find the registration number, then Step-2 is not executed and there is no
semantic conflict.
– If B finds the registration number and the vehicle happens to be a truck, then Step-2 of
the protocol will lead to a semantic conflict, since in B’s ontology, the color attribute is
not defined for trucks.
– If B finds the registration number and the vehicle happens to be a car or a bike, then Step-2
will not lead to a semantic conflict, since in B’s ontology, the color attribute is defined for
cars and bikes.
If the ontology of A and the protocol is made available to B, then B can formally verify whether
any execution of the protocol may lead to a semantic conflict and warn A accordingly before
the actual execution of the protocol begins.
There has been considerable research in the recent past on matching ontologies and finding out
semantic conflicts/mismatches among two ontologies [6, 7, 8]. In many cases, two web services
may have conflicting ontologies, but the protocol between them may avoid the conflict scenarios.
Consider the scenario where the direction of query-answer is reversed, that is the same sequence
of queries are made by A and answered by B. Also A makes the query about the color of vehicle
only if the vehicle is not a truck. In this case the conflict will not be sensitized by the protocol.
In other words, two agents may not agree on all concepts in their universe, but may still be
able to support certain protocols as long as they avoid the contentious issues – a fact which is
often ignored in world politics! Therefore an approach which rules out communication between
two services on the grounds that their ontologies do not match is too conservative in practice.
Since the standardization of ontologies and their acceptance in industrial practice seems to be
a distant possibility, we believe that the verification problem presented in this paper and its
solution is very relevant at present.
Scenario-3 : The ontologies can be visualized as a combination of meta-data and a set of in-
stances. Classes, relations and data-types form the meta-data part of the ontology, whereas the
individuals and the valuations of the attributes are the actual data. It is often the case that
the actual data is stored in a database, and ontologies are used as a wrapper on top of the
databases. Therefore the state of the database has to be incorporated, while the server checks
whether the protocol can possibly reach conflict state. Since the protocol between the client
and the server typically have branches and the decision for making the next query is dependent
on the answer of the current query, the conflict that is present at the ontology level may not be
sensitized due to the the answers generated from the back-end database. We present a relation
algebra based decision procedure to check whether the conflict, that are present in the ontology
level, are actually present with respect to the current state of the back-end database.
Scenario-4 : It is important to observe that the protocol has different runs depending on the
instantiation of the variables that are used in the protocol. Since the conflict may not be
sensitized in a particular run of the protocol, the server may choose to start the protocol and
check the possibility to get into a conflict after every information exchange. Depending on how
the conversation progresses the server may either continue to run protocol, or may terminate
the conversation when it finds that the conflict is inevitable.
A preliminary version of this work is published in [9]. In that version we presented the verification
algorithm for Scenario-2. In this paper we include the algorithms for Scenario-3, i.e. the verification
of the spuriousness of an ontological conflict with respect to the current state of the back-end
database. We also show that the same algorithm can be used by the server for Scenario-4. The
29

paper is organized as follows. The syntax for describing a protocol is described in Section 2. In
Section 3 we present a graph based model for representing the ontologies. The proposed formal
method for detecting semantic conflicts at the ontology level is presented in Section 4. The notion
of ontology with database and query answering with the back-end database and the algorithm to
verify the conflicts at the ontology level in the presence of the database are presented in Section 5.
Related works are briefly discussed in Section 6. Finally we present the conclusion in Section 7.
2 Protocol and Conflict
In this section we present a formalism similar to SQL for the specification of the protocol. It may
be noted that other formalisms can also be used to specify a protocol as long as the formalism has
expressive power similar to the formalism used in this paper. We present two example protocols
and also describe the notion of the conflict that we have addressed in this paper.
2.1 Formal Description of the Protocol
Typically, a protocol consists of a sequence of queries and answers. The query specifies a set
of variables through “Get” keyword and specifies a set of classes using “from” keyword. The
valuations corresponding to the variable set are generated from those classes. Also an optional
“where” keyword is used to specify the conditions on the variables. The answer of a query is
a tuple of valuations corresponding to the variable set specified in the query. The branching is
specified using “if-else” statements.
2.2 Example of Protocol
[Protocol - 1 :] Consider the protocol shown in Figure 1. The protocol depicts a conversation
between a client and a server over the publication domain. The query of the client is about the
author of some specific manual. Then the client makes a query to retrieve a book by the author of
that manual. According to the ontology of the client, ‘Proceedings’ is a subclass of ‘Book’ and the
client makes the next query to retrieve the proceedings by the same author. If the server does not
recognize ‘Proceedings’ as a sub class of ‘Book’, the query can not be answered by the server due
to the mismatch in the ontologies.
[Protocol - 2 :] In Figure 2 we present another protocol that exchanges information about the
automobile domain. The client makes a query to retrieve a brand which has sold more than a
specific number of vehicles in a particular year. Then next query is made in the context of the
previous query to check whether that brand manufacture ‘Red Trucks’. According to the ontology
of the client the color is a property of the vehicle class and therefore all subclasses of vehicle class
will have the color attribute. However if the server recognizes ‘color’ as an attribute of some of the
sub-classes(suppose ‘car’ and ‘two-wheeler’) instead of as an attribute of the class ‘Vehicle’ itself,
the query can not be answered by the server due to the mismatch in the ontology.
[Protocol - 3 :] In this example we present a protocol of an intelligent agent. Consider the
semantic web service for an online store. The online store can queried to retrieve the relevant
information about the available items. Also consider a multi-cuisine restaurant which is a client of
that store. Whenever the stock of some item, say i1, falls below some level, the intelligent agent
that works on behalf of the restaurant, searches the availability of i1 by querying the online store.
Suppose i1 comes in two qualities, q1 and q2. The protocol, that is used by that agent to find and
buy the item under consideration, is presented below using a format similar to pseudo code. Here
the buy action is carried out by the agent automatically, if the precondition is satisfied.
30

Client Server
Get(title : t1, author : a, date : d1)
from Manual
where t1 = ‘ManualName′
ht1, a, d1i
Get(title : t2, author : a)
from Book
ht2, ai
if (t2! = null)
Get(title : t3, author : a, date : d2)
from Book.Proceedings
ht3, a, d2i
Fig. 1. Protocol on Publication Domain
Protocol for Buying an Item
Get the availability i1 of quality q1;
If (i1 of quality q1 is available)
Get the price of i1 of quality q1;
If (the price is less than C1)
Buy i1 of quantity Q1;
Else
Inform the Manager of the store;
Else
Get the price of i1 of quality q2;
If (the price is less than C2)
Buy i1 of quantity Q2;
Else
Inform the Manager of the store;
2.3 Notion of Mismatch between two Ontologies
We focus on the following two types of mismatch between the client and server ontologies in this
paper.
Specialization Mismatch(Type-1): In this type of incompatibility the client recognizes a class
c2 as the specialization of another class c1 whereas the server recognizes c2 as the specialization
of some other class c′
1. Our first example (Figure 1) is an instance of this type.
31

Client Server
Get(Brand : b1, ItemsSold : c1, Y ear : y1)
from SaleStats
where (c1 > 10000)(y1 = 2009)
hb1, c1, y1i
Get(Brand : b1, Model : mod, Date : d1, Color : col)
from V ehicle.T ruck
where (d1.year > 2000)(col = ‘Red′
)
hb1, mod, d1, coli
Fig. 2. Protocol on Automobile Domain
Attribute Assignment Mismatch(Type-2): A very common type of incompatibility arises
where the client and the server both recognize classes c′
1, . . . , c′
n as the specializations of an-
other class c1, but the client associates an attribute α with the super class c1, whereas the
server associates α with some of the sub classes c′
i, . . . , c′
j, 0 < i, j ≤ n. Since we view the
mismatches from the query answering perspective, we use the notion of this conflict from the
query perspective. If the set of variables that is used in a query q, is not available at server
side, we denote that as attribute level(Type-2) mismatch. Our first example (Figure 2) is an
instance of this type.
3 Graph Model of Ontology
While describing an ontology using OWL, the class and the attributes(modeled as properties in
the context of OWL) are used to represent the meta-data. We use a graph based approach to
model the meta-data that are described as classes and attributes in OWL. While using OWL, the
properties are used to express the attributes. Therefore we use the term property and attribute
interchangeably. We define the ontology graph as follows.
Definition 1. A graph model for an ontology O is G = (V, E) where, V is the set of vertices and
E is the set of directed edges. Each node vi ∈ V represents a class in the OWL ontology and vi
is associated with a property list L(vi) whose elements are the data properties of the class. The
directed edges can be of the following types
Inheritance-Edge : An inheritance-edge eij ∈ E from vi to vj, where vi, vj ∈ V , if vj is a sub
class of vi.
Property-Edge : An property-edge eij ∈ E from vi to vj, where vi, vj ∈ V , if vj is an object
property of vi.
4 Overview of the Method
In this section we present the relevant formalisms and present the overall algorithm for solving the
problem. The variable set and the class set specified in the query q are denoted by Sv(q) and Sc(q)
32

respectively. We present a graph search based structural matching algorithm to check the semantic
safety of the protocol.
Definition 2. The specialization sequence σ = hc1.c2. · · · .cki in a query q is the sequence of
classes that are concatenated through the ‘.’ operator, and for any two consecutive classes ci and
ci+1 in the sequence, ci is the super class of ci+1. Therefore the elements of Sc(q) can be individual
classes or specification sequences.
4.1 Structural Algorithm to Check the Semantic Consistency
Algorithm 1: Check-Consistency
input : The Protocol P and the Server Ontology Os
V ← {};
1
foreach query q in the protocol P do
2
foreach element τ in Sc(q) do
3
if τ is a specialization sequence then
4
c1 ← the first concept of τ;
5
ct ← FindMatch(Os, c1);
6
for i ← 2 to length(τ) do
7
cm ← the ith
concept of τ;
8
if any class c′
t equivalent to cm is not found as a sub class of ct in Os then
9
Report Mismatch at cm;
10
else
11
ct ← c′
t
12
end
13
end
14
V ← V ∪ property set for ct;
15
else
16
/* c is an individual class */
c1 ← τ;
17
ct ← FindMatch(Os, c1);
18
V ← V ∪ property set for ct;
19
end
20
end
21
if Sv(q) ( V then
22
Report {Sv(q) − V } as unmatched variables;
23
end
24
end
25
Function FindMatch(Os, ci)
Find the class ct which is equivalent to ci in Os;
1
if ct is not found in Os then
2
Report Mismatch at ci;
3
exit;
4
end
5
return ci;
6
4.2 Working Example
We present a working example to describe how the algorithm works. Consider the protocol shown
in Figure 1. We elaborate the steps of applying Algorithm 1 with respect to the fragments of the
33

client and server ontologies shown in Figure 3 and Figure 4 respectively. These fragments are taken
from the benchmark provided by [10]. The benchmark has one reference ontology and four other
real ontologies and the domain of these ontologies is bibliographic references. We have used the
reference ontology as the server ontology and another real ontology named INRIA as the client
ontology. We have used a pictorial representation which is similar to entity-relationship diagram
to show the fragments of the ontologies. The classes are represented by the rounded rectangles
and the ovals represent the properties of a particular class. The class hierarchy is shown using
arrows, that is a sub class is connected to its super class by an arrow which is directed towards the
sub class. The properties that belong to a particular class are connected to the rounded rectangle
corresponding to that class through a line.
Step-1: While applying Algorithm 1 to the server ontology, the individual class ‘Manual’ is
searched and since the search is successful, it is checked that the attributes that are asso-
ciated with class ‘Manual’ in the query in the protocol are actually answerable by the server
and this check turns out to be successful for the ontologies that are presented here.
Step-2: The next query uses the class ‘Book’. Algorithm 1 performs the consistency checking in
the way that is similar to the previous query and the check is successful.
Step-3: The third query uses a specialization sequence ‘Book.Proceedings’. Algorithm 1 searches
for the ‘Book’ class in the server ontology and then checks whether ‘Proceedings’ is a sub class
of ‘Book’ in the server ontology. Algorithm 1 reports a failure since in the server ontology
‘Proceedings’ is not a sub class of ‘Book’.
Reference Informal
Academic
Proceedings
Collection
Monograph
Book
title volume
date
series
author
edition
publisher
chapters
organisation
communications
editor
event
title
author
date
school
chapters
parts
title
date
humanCreator
title
Manual
Booklet
LectureNotes
Fig. 3. Fragment of Client Ontology
4.3 Proof of Correctness
Theorem 1. [Soundness] The mismatches returned by Algorithm 1 are correct.
34

Entry
Published
Composite
Informal
Book
title
Bookpart
Article
humanCreator
edition
author
inJournal
number
volume
date
author
numberOrVolume
publisher
title
series
pagesOrChapter
chapter
date
title
Monograph
Collection
Proceedings
date
TechReport
Booklet
Manual
Fig. 4. Fragment of Server Ontology
Proof. Algorithm 1 reports mismatch in three cases. We observe each of the cases as follows.
Mismatch in individual class: If Algorithm 1 does not find a matching class c which is used in
a query, a conflict is reported. Since the class is not recognized by the server, it is not possible
for the server to answer the query. Therefore the outcome of the algorithm is correct.
Mismatch in specialization sequence: Consider a specialization sequence σ = hc1.c2. · · · .cki
in a query q on which Algorithm 1 returns a mismatch. We prove the correctness of the con-
sistency checking by induction on the length k of σ.
Basis(k = 1): In this case there is only one class in the specialization sequence and this case
falls under the case of mismatch in individual classes.
Inductive Step: Suppose Algorithm 1 returns the mismatch correctly for specialization se-
quences having length k. We prove that Algorithm 1 reports the conflicts correctly for the
specialization sequences having length k + 1. There can be two possible cases.
a. The conflict is reported for a class that appears in the ith
location of the sequence, where
1 < i < k + 1. The reported mismatch is correct according to the inductive hypothesis.
b. The conflict is reported for the k + 1th
class of the sequence. In this case there exists
a matching specialization sequence at server ontology up to length k. But ck+1 is not a
sub class of class ck according to the server ontology. Therefore the conflict reported by
Algorithm 1 is correct.
Mismatch on variables: Suppose the set of variables that are specified by the client is Vc in a
query q corresponding to the class set Sc(q) and the failure is reported on some variable in
Vc. Since Algorithm 1 first finds the matches corresponding to the classes in Sc(q) and then
checks for the answerability with respect to the variable set, in this case every class in Sc(q)
is matched with suitable classes in the server side. Now Algorithm 1 reports conflict if there
exists any variable that is not recognized by the server as an attribute of at least one of the
classes that correspond to the classes in Sc(q). Therefore the reported conflict falls under the
Type-2 or attribute level conflict category. ⊓
⊔
35

Theorem 2. [Completeness] For any protocol P, if there is any mismatch of type-1 or type-2,
Algorithm 1 reports it.
Proof. This proof is done by construction. For each of the type of the mismatches we show that
Algorithm 1 uses a sequence of operations through which the mismatch is detected. We present
the proof for each mismatch type.
Type-1 Mismatch: Consider a specialization sequence σ = hc1.c2. · · · .cki which is used in query
q. Algorithm 1 starts by finding the class that is equivalent to c1 at the server side. If there
is only one class in σ then Algorithm 1 reports mismatch when the corresponding class is not
found in the server ontology. When the length of σ is greater than 1, Algorithm 1 continues to
check whether ci is a subclass of ci+1 where 1 < i < k. A mismatch is reported by Algorithm 1
whenever ci is a subclass of ci+1 for 1 < i < k. Hence if there exists any mismatch in any
specialization sequence, the algorithm reports it.
Type-2 Mismatch: Consider a query q made by the client and the set of variables is Vc in q.
The set of classes is denoted by Sc(q). We argue that, if there exists a Type-2 mismatch for
query q, Algorithm 1 reports it. For Type-2 mismatches Algorithm 1 first checks the presence
of the equivalent classes cs
i in the server ontology and computes the union Vs of the attributes
corresponding to every cs
i . If there is any variable/s in Vc that are not present in Vs, a conflict
is reported by Algorithm 1. Hence if there exists a Type-2 mismatch for a query, Algorithm 1
reports it. ⊓
⊔
5 Ontology with Back-end Database
In this section we describe the two level representation for describing ontologies – using OWL to
describe the classification and using database to store the instances. This type of representation
is helpful for describing domains with large number of instances. From the point of view of the
instances of classes, the classes in an ontology can be categorized as follows.
a. Classes of Abstract Type – these classes are used for purely the purpose of describing a domain
in hierarchically. These classes does not have any instances. They act only as the super class
of other classes.
b. Classes with Instances – these classes may act as super class of other classes but they have a
non-empty set of instances.
Consider the ontology fragment in Fig. 4. Here Entry, Informal, and Composite are the example of
abstract classes. On the other hand, Book, Monograph etc. are the example of classes with instances.
Although Book is a super class of Monograph and Collection, it is possible to have instances of
Book which are neither Monograph nor Collection.
While using the two level representation, it is important to keep the database schema consistent
with the wrapper ontology. A choice of describing the database schema could be maintaining a
table for each of the non-abstract classes present in the ontology. Alternative ways of describing the
database are possible, but we use this simplistic representation of the database schema to present
the proposed algorithm.
5.1 Query Answering in the Presence of the Database
When the server side adheres the two layer structure for its ontology, every query in the protocol
is answered by generating corresponding tuples from the back-end database. In the context of the
back-end database the occurrences of variables in a protocol, can be categorized into the following
types.
Uninstantiated: When a variable is placed in a query for the first time without initialization, it
is referred to as an uninstantiated occurrence of variable or in short uninstantiated variable.
The values for the variables are instantiated at the side where the query is evaluated.
36

Instantiated: Other than the first occurrence without initialization, all other occurrences of a
variable is referred to as instantiated occurrence of that variable or in short instantiated variable.
At these occurrences, the variables are already assigned to some value by the server. These
occurrences are used for value propagation.
[Evaluation Semantics of a Query :] The semantics of the evaluation of the query is similar
to the Conjunctive Datalog. The evaluator of the query tries to assign value to uninstantiated
variables and forms a tuple which satisfies logical and of the conditions specified in the where
clause of the query. Same variables in different classes specified in the where clause of the query
have to be assigned to the same value.
Consider the protocol presented in Fig. 1. In Section 4.2 we have shown that the protocol has
an ontological conflict, when the client and the server uses the ontologies in Fig. 3 and Fig. 4
respectively. Consider the fact, that the condition, (t2! = null) may always evaluate false due to
the actual data that is stored in the database of the server. In that case, the ontological conflict
in the last query, [Get(title : t3, author : a, date : d2) from Book.Proceedings], will never be
sensitized. In other words the conflicts at the ontology level may turn out to be spurious. We
define the spuriousness of an ontological conflict as follows.
Definition 3. An ontological conflict is spurious, when for all possible correct instantiations of
the variables, the conflict is not reachable from the start state of the protocol, due to the decisions
taken at different stages of the protocol. By correct instantiations we mean the instantiations that
conform to the evaluation semantics defined earlier.
5.2 Related Formalisms
Here we present the relevant formalisms for describing the algorithm to check the presence of the
conflict detected by Algo. 1 at the current state of the server database.
Definition 4. The assignable set of values for a variable ϕ is the set of values that can be assigned
to ϕ during the instantiation and it is denoted as AssignableSet(ϕ).
Suppose in a protocol P, a query q has variable set v = {ϕ1, ..., ϕn} and concept set C =
{C1, ..., Cm}. Let us also assume that in P all the variables of q are uninstantiated variables.
The notion of assignable set in the presence of the previously instantiated variables is discussed
later. The evaluation of the query basically assigns a values to each of the variables in that query.
All the variables together form a tuple τ = hval1, val2, . . . , valni such that if any variable ϕk is
common between class Ci and class Cj then both the classes have to assign same value to the vari-
able ϕk. All such possible tuples that can be populated by the evaluator side, form the assignable
set of values for v and the assignable set for a variable ϕi is:
AssignableSet(ϕi) = {val | ∃τ ∈ AssignableSet(v) ∧ τ = hval1, val2, ..., valni ∧ vali = val}
The dependencies among the variables play an important role for determining the AssignableSet
for a variable.
Definition 5. In a query, if some of the variables are previously instantiated, we say that the
previously instantiated set of variables is constraining the set of values of the uninstantiated vari-
ables. Suppose in the same query q, among the variables specified in q, ϕ1, · · · , ϕk are previously
instantiated and ϕk+1, · · · , ϕn are the variables that are instantiated by the evaluation of q. We
define the constrain relation RC and the ConstrainSet as follows.
RC = {(ϕi, ϕj)

Detecting Ontological Conflicts in Protocols between Semantic Web Services

where ϕi ∈ {ϕ1, · · · , ϕk} and ϕj ∈ {ϕk+1, ..., ϕn}}
ConstrainSet(ϕi) = {ϕk+1, ϕk+2, · · · , ϕn}
Consider the same query q. The AssignableSet for the set of variables of q is the set of all tuples τ
= hval1, val2, . . . ..., valni such that the following conditions hold.
37

– If any variable ϕk is placed in more than one concepts, all the concepts assign same values to
ϕk.
– (val1 ∈ A1) ∧ ... ∧ (valk ∈ Ak), where A1, · · · , Ak are the assignable sets of variable ϕ1, · · · , ϕk
respectively.
Definition 6. The RestrictSet for a variable set v is obtained by computing the transitive closure
of the RC on v.
We use the notion of the split operation on the assignable set of values of a variable and it works as
follows. Let a query, q, consists of concept Ci with a uninstantiated variable ϕi, and a previously
instantiated variable ϕj. Suppose a decision is made on the variable ϕj. In each branch, the possible
values of ϕj forms a subset of its assignable set. Since the value of ϕi is dependent on ϕj, in each
branch the possible values for ϕi also forms a subset of the assignable set of ϕi.
Definition 7. The SplitSet for a variable set v is a subset of RestrictSet(v) and is defined as:
SplitSet(v) = {ϕj | ϕj ∈ RestrictSet(ϕi) and ϕj appears in a condition in the path of the protocol
from the start of the protocol to the query with ontological conflict ϕi}
Definition 8. RelevantConditionSet of a variable set v is the set of conditions in true form on
the variable set vsplit, which have to be true for reaching the conflicting query.
5.3 Algorithm for Detecting Spurious Conflicts with respect to the Back-end
Databases
Algorithm 3: Verify the Conflicts on Back-end Database
Initialize a hash table Ht
;
1
/* In the hash table Ht
, a set of variables v forms the key, which is
mapped to the AssignableSet of the variable set v */
foreach conflicting query q do
2
v ← The set of instantiated variables specified in q;
3
if VerifyConflict(v) then
4
Report mismatch on variable v at database level;
5
else Report the conflict as spurious;
6
end
7
Function MakeSets(v)
Initialize set of variable sets vret
= {};
1
while v is not empty do
2
Find a query q that instantiates some of the variables in v;
3
Initialize variable set vtemp = {};
4
forall variable ϕi ∈ v and ϕi is instantiated by q do
5
v ← v − {ϕi};
6
vtemp ← vtemp ∪ {ϕi};
7
end
8
vret
← vret
∪ {vtemp};
9
end
10
Function SplitAssignableSet(δ, vsplit, c)
/* Suppose c1, · · · , ci ∈ c */
Relational algebra query qRel
← σ(c1∨c2∨...∨ci)(δ);
1
Compute qRel
and return the set of tuples;
2
38

Function VerifyConflict(v)
vrestrict ← The RestrictSet for the variable set v;
1
vsplit ← The SplitSet for the variable set v;
2
vs
restrict ← MakeSets(vrestrict);
3
Construct a priority queue Γ of variable sets;
4
/* Γ is ordered according to the order of the instantiations of its variable sets
*/
forall variable set vi ∈ vs
restrict do
5
Enqueue vi in Γ;
6
end
7
Table set St
← {};
8
while Γ is not empty do
9
u ← Dequeue (Γ);
10
if (VerifyConflict(u)) then
11
/* The set of possible valuations for u is not empty */
t ← Search Ht
and return the table containing u ;
12
if t /
∈ St
then
13
St
← St
∪ {t};
14
end
15
else
16
/* The set of possible valuations for u is empty, so the conflict is
spurious */
return false;
17
end
18
end
19
Find the query q that instantiates variable set v;
20
if vsplit != ∅ then
21
c ← The RelevantConditionSet on the variable set vsplit;
22
δ ← SplitAssignableSet(δ,vsplit, c);
23
end
24
if δ == ∅ then
25
Report the conflict on v as spurious;
26
return false;
27
else
28
Insert δ in Ht
;
29
return true;
30
end
31
Function GenerateAssignableSet(q, St
)
/* Suppose q is made with the concepts C1, ..., Cn and ϕi1, . . . , ϕik are the
uninstantiated variables corresponding to the concept Ci */
v ← {ϕij | ϕij 6= ∗};
1
if St
== Φ then
2
/* All the variables of q are uninstantiated */
Tuple set T ← (C1 ⋊
⋉ C2 ⋊
⋉ ... ⋊
⋉ Cn);
3
else
4
/* Some of the variables of q are previously instantiated and t1, ..., tm ∈ St
are
the tuple sets corresponding to those variables */
Tuple set T ← (C1 ⋊
⋉ C2 ⋊
⋉ . . . ⋊
⋉ Cn ⋊
⋉ t1 ⋊
⋉ . . . ⋊
⋉ tm);
5
end
6
Relational algebra query qRel
← πv(T );
7
Compute qRel
and return the set of tuples;
8
This algorithm can also be used by the server as the protocol progresses(described as Scenario-4 in
Section 1). In that case, the variables in the queries which are already executed, have some value
assigned to them and those variables will be considered as instantiated by the algorithm.
39

5.4 Proof of Correctness
The proof of correctness of Algo. 3 is presented below. Algo. 3 verifies the spuriousness of conflicts
returned by Algo. 1 on the server database.
Theorem 3. [Soundness] Algorithm 3 correctly reports the spuriousness of conflict on the set of
variables v′
, where v′
= v ∪ RestrictSet(v) and v is the set of previously instantiated variables in
a query q of protocol P with ontological conflict.
Proof. The proof is done using induction. We do the induction on the integer parameter n, where n
is the total number of VerifyConflict function calls done by Algorithm 3 for q. Among the different
VerifyConflict function calls, first call is done by Algorithm 3 and the others are recursive calls.
[Basis (n = 1) :] In this case RestrictSet(v) = φ. In this case if the AssignableSet(v) is ∅
Algo. 3 correctly reports the conflict as spurious, otherwise Algo. 3 reports the conflict as not
spurious, which is correct.
[Inductive Step :] We assume that the spuriousness of a conflict reported for the queries with
ontological conflict in n steps are true. We now prove that the spuriousness of a conflict that is
reported in (n + 1) steps are correct. Consider the VerifyConflict function call at Algo. 3 and
without loss of generality, we can assume this function call as the (n + 1)th
function call (in the
order of returning of the function calls). Therefore the other calls are recursive calls done by the
VerifyConflict to itself. The following two cases are possible.
a. The conflict may be detected as spurious by some call which is not the (n + 1)th
call. In this
case the spuriousness of the conflict is correct by the inductive hypothesis.
b. The conflict is detected as spurious at the (n + 1)th
call to VerifyConflict. All other previous
calls to VerifyConflict add a table to Ht
and the set of tables are kept in St
. After that,
function GenerateAssignableSet is called to compute the assignable set for the set of previously
instantiated variables v in the query q with ontological conflict. It follows from the description
of the function, that this function restricts the set of valuations of v by taking the natural
join with the valuations of variables in RestrictSet(v). Since the conflict is not detected as
spurious in the variables in RestrictSet(v), when the function detects the conflict as spurious,
the statement δ == ∅ is true. Therefore in the protocol q is not reachable from the start state
of the protocol. ⊓
⊔
Theorem 4. [Completeness] If there is a spurious conflict on the set of variables v′
, where v′
= v
∪ RestrictSet(v) and v is the previously instantiated variable set specified in a query q of protocol P
with ontological conflict, the algorithm reports it. We do the proof by establishing the contrapositive
of the statement, i.e. Algorithm 3 reports the ontological as not spurious, if q is reachable from the
start state of P.
Proof. Suppose v′
= {ϕ1, ..., ϕn}. Let the valuations of the variables in v′
are (val1, ..., valn) when
the conflict in q is not spurious. In this case the conflict may occur in the following way. Consider
the VerifyConflict function calls made to determine the spuriousness of the ontological conflict in
q, among which the first call is done by Algo. 3 and the subsequent calls are recursive calls. The
conflict is detected as not spurious, only if all the recursive calls to VerifyConflict add a table
to Ht
and the set of tables are kept in St
. Since the conflict is determined as not spurious, the
statement δ is not empty. Therefore in P, q is reachable from the start state of the protocol using
any instantiation of variables belonging to δ. ⊓
⊔
6 Related Works
Different aspects of web service interaction have been an active area of research. However most of
these researches consider the interaction at syntactic level. Foster et. al. addressed the compati-
bility verification of web services in [11]. They adopted a model based approach for checking the
40

Detecting Ontological Conflicts in Protocols between Semantic Web Services

More Related Content

What's hot (19)

Similar to Detecting Ontological Conflicts in Protocols between Semantic Web Services (20)

More from dannyijwest (20)

Recently uploaded (20)

Detecting Ontological Conflicts in Protocols between Semantic Web Services