The basic phase of the demo of KADIS

The task in this phase is mainly to collect the selections from the user and compose them into a query, i.e., try to figure out what the user wants. Based on the document provided by Keith, there are mainly two steps: the first step asks the user to make some selections to make up the final query, and in the second step, the user makes some decisons for the manner to display the results.
In the first step, there are five different selections for the query for the moment. All of these selections should present with a concept at the ontological level. That means, it should not have much to do with the detail of each dataset. Because different reseachers might use different ways to describe the same concept, it's hard for one user to understand others' notes for one concept without detailed explanation. We plan use XML files to organize all ontological information about the datasets concerned. (Note: the ontological information is kind of representation of concept which can be understood by most people in the field of archaeology.

1. Dataset selection: all datasets existing in the collections are displayed in a checkbox list.
2. Taxonomic level: a treeview plus checkbox is used to display the hierarchical structure of the taxonomic categories.
3. FUI selection: it is connected with the selections made in 2.
4. Element selection: a list box may be used to display all elements in the datasets.

Design for KADIS demo

The goal of our work at this time is to create a website supporting the integration and the query of archaeological databases. There are at least two focuses: one is to satisfy the basic query demand from the user, and the other is to find a good way to display the conflicts generated in the integration of different databases and ask the user to give solutions through interactions.
So it's composed of two phases corresponding to the two focuses: the basic phase and the conflict-resolving phase.

1. Basic phase: At the point of a user, s/he makes a series of selections for the query, and then gets the result with some kind of format (e.g., txt, excel files etc.). Standing on the side of the system (or web application), it displays the necessary information about the query to the user (such as the datasets) with a friendly way, and outputs the results according to the user's requirements.
2. Conflict-resolving phase: when a new dataset is integrated into the existing database, some conflicts may happen for the different definitions used by the different reseachers. While a query is processed, it's the user who should provide its resolutions to the concerned conflicts in order to produce the right result. It's an interactive procedure.

Honestly, I don't believe there is a clear-cut boundary between these two phases. When displaying integrated database to the user, some conflicts must be resolved first. The processing of the query should be the kernel of the project, including the ontologies extraction, the dataset integration, and the query processing etc. But the demo just visualizes the idea of our project/proposal. It's enough to put the emphasis on the visualiztion and interaction.
In the implementation, we use classical client-server architecture. The basic idea is as the following: the archaeological datasets are stored in the serve. We use MySql database to store all of data for the moment. The ontological information about the datasets is organized with an XML format, in owl or xml files. When the user logs the website and starts to select, the client on the user's side will fetch relevant information from the server (one possible way is to read data from the XML or mysql database, generate suitable html pages and send them back to the client browers) .