Terminological Queries

The terminological query can be divided into two parts, namely a simple concept query and a defined concept query. In case of a simple concept query, the user has to choose a specific ontology. This makes the query simpler for a user to understand, but assumes that the user knows at least one concept from the ontology. Simple concept queries are fast, but not always expressive enough.

To overcome these problems we can use the defined concept query. On the base of the given common vocabulary, the user is able to define a concept that fits his vision of a concrete concept. A defined query is more complex to build, but it is much more unrestricted.

After launching the BUSTER client, the user can choose an application area (domain) (cf. figure 7.2a). Currently, we have three different domains, namely, an accommodation domain, a installation-supplies domain with parts of two well-known catalogue systems (ecl@ss and ETIM)1, and a geographical domain (Geoshare). We choose the installation-supplies domain to demon- strate the first types of queries.

www.eclass.de, www.etim.de, verified on June, 30, 2003. 1

Simple Concept Query

The user chooses an ontology depending on the current domain (see figure 7.2a). These terminologies are registered at the BUSTER server and are of- fered only when they are registered for the domain. The user is able to select one of the concepts of the ontology (eclass in this case) that fits his query best (e.g., Isolierstoffrohr (installation pipe), figure 7.2b). The BUSTER server re- ceives the query and integrates the known ontologies for the current domain by loading them into the connected reasoner (RACER in this case)2. This is possible only because every ontology is annotated with a common vocabulary following the hybrid approach described in section 3.

After re-classification, all sub-concepts (children) of the query concepts form the result. Figure 7.3a shows the result of this first query. BUSTER found two annotated information sources containing the concept ‘Isolierstoffrohr’ (insulation pipe) from the eclass ontology (cf. query and match on the right hand side of the figure).

Fig. 7.3. Result panel after querying BUSTER. In this case, a simple query has been chosen.

The power of the ontology-driven approach can be seen in figure 7.3b. We have chosen the ontology ‘ETIM’ and the concept ‘Installationsrohr’ (installa- tion pipe). Five results are given after querying the system. We can see that, besides exact matches, semantically equivalent concepts in other ontologies are presented. Figure 7.3b reveals that the ‘Installationsrohr’ from the ETIM catalogue is semantically equivalent to the ‘Metallschutzschlauch’ (metal pro- tection tube) from the ecl@ss ontology. Thus, this information source will be presented as an answer to the query.

Usually, the user will not be asked what reasoning service should be used. How- ever, this could make sense in certain situations, e.g., when certain features are needed (one example is concrete domains).

Defined Concept Query

Again, the user starts choosing an ontology according to the domain. Let’s assume the installation-supplies ontology has been chosen. The user gets prompted with pre-defined query templates, the reason being, that common domain-dependent templates should be offered. For instance, a search for a well-known product in the installation-supply domain such as pipes. The user chooses a query-template provided by the BUSTER server. This template contains attributes (slots) and values (filler) from the common vocabulary. The user interface is ontology-driven, which simply means that the available attributes and fillers are dynamically loaded and presented. The user cannot make a mistake, e.g., using unknown terms. The user defines the query by selecting reasonable values for the given attributes. ‘Yes’ specifies the occur- rence of the related filler, ‘No’ prohibits the occurrence and ‘n/a’ is chosen, if the value does not matter.

Fig. 7.4. An example for a defined concept query: the user has chosen the instal- lation-supplies ontology and the query template ‘pipes’.

The filled query-template is translated into a logical term. During the query process all CSDs related to the current domain are parsed for the subject-tag. Each subject is referenced to a name space, which points to an ontology that contains a concept description of the subject term. These on- tologies are then downloaded from ontology servers available on the WWW, and are merged with the defined concept query and transferred into available inference machines. After re-classification, all sub-concepts (children) of the query concepts form the result.

Figure 7.4 shows an example of a defined concept query. The user is inter- ested in information about pipe products. As we can see, the pipe template has two slots ‘Material’ and ‘Ausführung’ (material and type) along with var-

Fig. 7.5. Result panel after querying BUSTER. In this case, a defined query has been chosen (template ‘pipe’).

ious fillers. We set the filler ‘Metall of the slot ‘Material’ to yes, indicating that the material of the pipe should be made out of metal.

The result of the query is shown in figure 7.5a. We see that the concept “Metallschutzschlauch” of the eclass ontology fits the description made. The other results that have been found reveal that the concept “Stahlpanzerrohr” also fits the query. If the user would also fill the slot “Ausführung” (type) with “glatt” (smooth) the result would differ: figure 7.5b shows that this time, the “Metallschutzschlauch” is not found because of its rough surface.

Since RACER allows for the operation in concrete domains, BUSTER also includes templates where the user can choose this functionality. If we switch the application area from installation supplies to ‘accommodation’ and again choose a defined query, we would get a template allowing us to edit the three slots: ‘capacity’, ‘single’, and ‘double’ for an accommodation3. Suppose we are looking for an accommodation that includes a conference room with 80 seats. Querying the system results in five matches (7.6a). The found informa- tion sources, hotels in this case, are congress hotels. If we would change the necessary seats to, lets say 25, we would get 12 matches (7.6b).

At this point we have to admit that this template is somewhat awkward for the user since the intended meaning of the slots are not clear. A solution would be a proper visualization of the ontology with the concept names and attributes. This however, is hard to implement since the defined concept query does not consist of concept names but a combination of slots.

Fig. 7.6. Result panel after querying BUSTER. In this case, a defined query has been chosen, accommodation domain (template ‘accommodation’).

The reason for this is not that obvious. A detailed look in the accom- modation T-Box4 reveals that the concept ‘congress hotel’ has a minimum number of capacity, set to 100. This means that information sources (hotels) annotated with this concept provide this number of seats. This, however, also includes the requested capacity of 80. Requesting a capacity of 25 means that the minimum number of seats should be 25 which is subsumed by the con- cept ‘congress hotel’ (min 100) and the concept ‘conference hotel’ where the minimum is defined to be 30.