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.

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.P roceedings**], 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.

37