APECKS: a Tool to Support Living Ontologies

1.1 Ontology Servers

Ontology Servers provide ontologies for general use in knowledge intensive applications through the Internet. This section details and examines a number of these Ontology Servers in terms of the manner in which interaction between the server and users is handled, and how interaction between users is handled.

1.2 Collaborative Knowledge

Some argue that the primary aim in the construction of ontologies, for knowledge engineers, is to create a single ontology that can be used in every possible knowledge intensive application. This perfect ontology could then be trimmed down to provide a knowledge base suited for a particular task or domain using techniques such as those described by Swartout et al. (1996). It is still a moot point whether monolithic ontologies can be built: alternatively, smaller ontologies can be brought together to create a knowledge resource. Whichever method is used, the ideals of correctness and consistency remain and large scale collaborative effort towards the creation of ontologies needs to be supported.

Ideally, the easiest way to achieve a consistent and comprehensive ontology is to base it on the knowledge of a single expert. However, in many if not most cases, a single expert is not sufficient due to the restricted nature of their knowledge which may be specialised, out of date or culturally specific. Thus multiple experts are used to create a larger and more accurate picture.

Unfortunately, experts differ in terms of their goals, priorities, opinions and beliefs. The task of the knowledge engineer, in creating a 'correct' ontology, is to sort the factual wheat from the fictional chaff and pull out a core of useful knowledge. In the main, the correct knowledge is taken to be equivalent to the consensual knowledge, and thus the knowledge engineer's task becomes one of finding consensus within the divergent knowledge of the experts. This leads to the type of assertion as made by Farquhar et al. (1996), that ontologies, by definition, represent consensual knowledge: the single accepted definitions of technical terms used within the domain.

It can be argued that the expertise of a knowledge engineer lies in the art of constructing these consensual ontologies from the knowledge of a number of experts, and there are a number of techniques that can be used to compare expert knowledge, such as Shaw & Gaines' (1989) consensus/conflict/correspondence/contrast classification and Boy's (1996) Group Elicitation Method. Where differences occur between experts, the knowledge engineer acts as a negotiator or simply chooses which source to trust on the basis of their estimated reliability. In this way, knowledge engineers play an essential role in the construction of a consistent ontology.

However, one of the desired consequences of internet-accessible knowledge engineering tools, and to a lesser extent those that are computer-aided generally, is that less direct intervention on the part of the knowledge engineer is required. Instead of a knowledge engineer leading the expert through a number of knowledge acquisition techniques, the expert can be left to carry them out in their own time. Ontology servers have generally been designed for by use by knowledge engineers: could they also be used directly by experts?

While allowing experts direct access to ontologies saves time for the knowledge engineer, it may also cause problems in the creation of consensual ontologies. Without the knowledge engineer taking on the role of middle man, how can consensus be achieved in these systems? How can different knowledge engineers reach consensus on the ontologies they create, which may, after all, be different? The answers in currently available ontology servers range from a free-for-all, where any user can make changes, through to consensual systems where all users must agree before a change can be made.

At the most basic level of management of multi-user ontologies, access to ontologies can be restricted through the use of user and group read and write permissions, set by the owner of an ontology, as in the Ontolingua server. These permissions can be supported by the use of communication techniques as outlined above which enable the users to keep track of the changes that others are making.

Within the Ontosaurus Browser (Swartout et al., 1996), changes can only be made by an individual user if they are consistent with the rest of the ontology. This is made possible due to the reasoning capabilities built-in to the LOOM representation language and prevents inconsistent ontologies from being built. This facility is not only useful for multi-user ontology construction, but also for checking the consistency of knowledge from a single user.

Co₄ (Euzenat, 1996a & 1996b) goes one step further in structuring the interactions between individuals working on the same ontology. Ontologies are built into a hierarchy of group knowledge bases, each one of which represents the consensual knowledge for the users that are subscribed to that group. At the bottom of the hierarchy, each user can have a number of knowledge bases which they can alter as they please. When a change is proposed for the group base, each of the users subscribed to it is notified of the proposal and may either accept or reject it. If all users accept the proposal, the group knowledge base is changed, but if a single user objects, the change is not made in its present form. This procedure models itself on the submission procedure for academic journals. Individual users can also choose not to accept any changes into their own individual knowledge bases, even if they are accepted on a group level.

In Swartout et al. (1996)'s vision of the future in knowledge base design through a collaborative ontology servers, knowledge engineers are able to familiarise themselves with the domain and construct an initial knowledge base from a pre-existing ontology. This ontology can be translated into the many formats, such as KIF, LOOM or C++, for use by the system they are building. If a knowledge engineer has knowledge to add to the ontology, they can 'check out' part of the ontology, update it, and then 'check it back in'. At this point, the system itself assesses the new knowledge for compatibility with the previous version of the ontology. Other users are able to look at a record of the changes that have occurred to the knowledge base.

The problems with the use of these systems directly by experts, in our view, lie in the avoidance of consideration of the causes of a lack of consensus between them. As discussed earlier, characteristics of individual experts may have an implicit influence on the decisions they make. Making these implicit differences explicit can enhance understanding of the domain, and doing this is one of the tasks of the knowledge engineer. Where a knowledge engineer is unavailable, as in these ontology servers, experts may argue a particular point, having changes blocked or continuously changed back without reaching an understanding of the true differences between them.

Our approach seeks to enable experts to address the sources of their disagreements and to argue with a productive end. It is also hoped that this approach will also enable the knowledge engineers who use ontology servers to discuss their differences more thoroughly, leading to a better understanding of the criteria on which ontology design is based. This approach is instantiated in an ontology server named APECKS (Adaptive Presentation Environment for Collaborative Knowledge Structuring).

2.1 Personal Ontologies

Existing ontology servers hold unrelated ontologies which can only be accessed for changes by those to whom permission has explicitly been given. On top of this, preference is given to the existing state of affairs, with changes having to satisfy certain constraints, such as consistency with the rest of the representation or the agreement of all the other collaborators. This may, we argue, lead to stagnant and restricted ontologies.

APECKS, on the other hand, is based on personal ontologies, representing an individual's understanding of a domain. Creating such ontologies is quick and easy, with support for copying and adapting the whole or part of other peoples', and anyone can create them. The ontologies can exist in a state of inconsistency within themselves, or with other individual's ontologies, so that the reasons for these inconsistencies can be explored. The emphasis in the creation of ontologies within APECKS is on change and exploration: a brainstorming process. This, we contend, will lead to dynamic and diverse ontologies.

2.2 Use of Networked Resources

While current ontology servers can be accessed by users either through a hypertext interface or programmatically, their focus is, as their name suggests, on serving information: they do not access other networked resources. APECKS, on the other hand, is envisioned as acting as a client as well as a server, accessing network-accessible knowledge acquisition applications and other ontology servers. Currently, it uses WebGrid (Gaines & Shaw, 1996a & 1996b) to support knowledge acquisition. In the future, it is envisioned that the ontologies held by other ontology servers would be accessed by APECKS and used just like the other personal ontologies APECKS holds. In this way, APECKS positions itself in the centre of the network of knowledge on the Internet.

2.3 Knowledge Acquisition Support

Existing ontology servers give support to knowledge engineers in the construction of ontologies. APECKS is geared towards the support of domain experts, who are not necessarily experts in the construction of ontologies. APECKS currently carries out basic knowledge acquisition itself. Other, more sophisticated techniques can be slotted into APECKS as they become available in internet-accessible tools. WebGrid (Gaines & Shaw, 1996a & 1996b), for example, is already used to give support for repertory grids within APECKS.

2.4 Design Rationale

Within linear communication media, it is easy for a user to tell when a change has occurred, when a post has been added to a newsgroup or when someone has said something. With hyper-communication media, where communication is structured in a hypertext network of comments and annotations, it is harder for the user to identify where changes have been made.

Chronological awareness tools have been developed which generate information about changes in hypertext structures (Chen & Gaines, 1996) which can be client-side or server-side. Server-side chronological awareness tools such as CHRONO (Chen, 1996) keep track of changes to documents within a file structure on a server and create a page listing these changes.

Change is very important within APECKS, so support is needed for recording the changes, recording the reasons for the changes and making the rationale available and explicit to users. When they return to the system after a period of absence, users are notified of changes related to their personal ontologies. These changes can be annotated, giving the reasons behind the alterations. This rationale can later be searched by other users seeking to answer questions about why certain actions were taken.

2.5 Structured Communication

The real innovation of APECKS, however, lies in its support for collaboration between users through the comparison of their personal ontologies. APECKS automatically compares the personal ontologies constructed by its users in terms of the consensus/conflict/correspondence/contrast classification put forward by Shaw & Gaines (1989). Ontologies are not just compared in terms of whether they are consistent with each other or not, but the degree of consistency with each other.

Users of APECKS are prompted to take action or communicate with each other on the basis of the comparisons made between their personal ontologies. For example, if one ontology classifies rocks in terms of their 'quartz content' while another does so in exactly the same way, but uses the term 'silica content', APECKS would recognise this as a state of correspondence (different terminology being used for the same concept). The users who constructed these ontologies would be prompted to either change the term to bring them into line with the other or to start a discussion about why different terms were being used.

Discussion based on comparisons between ontologies has two useful consequences. The first is that domain-related detail is uncovered. In the case of 'quartz content' vs. 'silica content', discussion would uncover that higher silica content causes higher quartz content within a rock, a detail that may have been missing otherwise. In this way, richer, more detailed ontologies are built up.

The second consequence of discussion is that criteria used in the construction of ontologies are made explicit. In this example, the reason for using the term 'quartz content' may be an assumption that identifying the degree of quartz content is easier for geologists in the field that estimating a percentage of silica, which might lead to the explicit construction of a premise such as "The users of the KBS will be geologists in the field." The explicit statement of the criteria under which the ontologies are constructed provides meta-information about their purpose that is usually left implicit.

3.1 Technology

APECKS is based on a internet-accessible multi-user text-based virtual environment named MOO (Multi-user domain - object-oriented; Curtis, 1992). The original and primary purpose of MOOs was to provide a communication facility that is environmentally richer than inter-relay chat (IRC) and less adventure-oriented than multi-user dungeons (MUDs). This somewhat unconventional system is used as the basis for APECKS for a number of reasons:

Object oriented database

MOOs consist of two parts: an object-oriented database which defines each individual MOO and a server program which interprets and runs the database file. The object-oriented nature of MOOs means that object-oriented representations, like the frame representations used in knowledge engineering, are very simple to employ.

Internet accessibility

MOOs are accessible via the internet using the telnet protocol. The mechanisms for opening, closing and maintaining connections between computers necessary for ontology servers are built into the MOO server program. Several MOO developers have built on top of this and made available MOO databases which allow objects within them to be viewed and manipulated through the WWW.

Programmability and rapid prototyping

MOOs are programming environments. Any object within a MOO database can be programmed to interact with users or other objects. Because these programs are part of the database itself, they do not have to be compiled, leading to rapid prototyping. For the purposes of behaving as a WWW server, MOOs can be programmed to dynamically generate HTML.

Multi-user synchronous communication

MOOs allow multiple users to connect to them and interact with each other using synchronous text-based communication. Built into the standard LambdaMOO database (Curtis, 1992) are user representations, which facilitate user modelling, and other communication methods, such as asynchronous mail.

For APECKS, three modifications were made to the standard LambdaMOO database (Curtis, 1992). Firstly, the APECKS database understands HTTP, and can therefore act as both a WWW server and, when in the role of a proxy or gateway, a WWW client. Secondly, the APECKS database generates vanilla HTML (without any Java applets or ECMAScript [6]) dynamically on the basis of its internal object representations, enabling the user to interact with the objects using a WWW browser. Finally, a number of 'generic' objects were added to the database, which form the basis of the Knowledge Representation Schema used by APECKS.

3.2 Knowledge Representation Schema

APECKS is a Frame Representation System which represents ontologies in a manner based on that defined by the Frame Ontology (Karp & Gruber, 1997). Representing knowledge using the frames defined by the Frame Ontology means that translation between the representation within the APECKS system and that in other frame representation systems can be facilitated by Ontolingua and the Generic Frame Protocol (Karp, Myers & Gruber, 1995, Karp & Gruber, 1997). Since the Frame Ontology is used as the basis of the representation of knowledge in Ontolingua, it also means that network-accessible Ontolingua ontologies can be seamlessly incorporated into the APECKS ontology representation.

The basis of the APECKS knowledge representation is a number of individuals which are grouped into classes and have slots, which define values and have facets. It handles multiple inheritance through the class hierarchy, such that the value of a slot for an individual can be inherited from its types (classes). Slots can hold many different kinds of values, and can hold many at the same time. Some restrictions apply within APECKS as the knowledge representation is only intended as a proof of concept: the class hierarchy is, in the main, determined by the membership of individuals to classes rather than being directly defined by the user; users cannot define facets or axioms. In the main, these restrictions serve to make it easier for users who are not knowledge engineers to understand and use the system.

Knowledge stored within an APECKS database is divided into a number of domains. This division is necessary since, instead of only holding a single ontology for a domain, APECKS represents a number of ontologies each of which is defined by a single user. Any user may define multiple ontologies within a single domain, representing different aspects of the domain or different tasks that might be carried out within it. Each of these ontologies is known as a role. None of the defined ontologies are shared in the manner of Ontolingua shared sessions or as in Ontosaurus. Instead, each role is represented almost entirely separately, in a similar manner to the separate knowledge bases in Co₄.

There is some overlap between roles, however, in that the same individuals can be classified in many different roles. Each individual has slots for information which define it uniquely, such as its name and description, but the class membership of an individual, its inherited slots and the values of those slots, may vary from role to role. A representation of the similarities and differences between two or more roles is known as a comparison: these are discussed in greater detail in the section on ontology comparison, below.

On top of those objects which encode the ontologies, there are objects which facilitate discussion about them. There are two types of these objects: criteria, which are short, general, assertions about the reasons for a particular state of affairs; and annotations, which are longer discussions, sometimes with more than one author. These are discussed in greater detail in the section on communication within APECKS, below.

3.3 Ontology Browsing

The ontologies stored within APECKS can be browsed either through the WWW or, in the future, through a text-based virtual environment interface within the MOO.

WWW Interface

Within APECKS, each object (individual, class, slot, role, domain, comparison, criterion or annotation) has a number of WWW pages associated with it. These pages are each dynamically created on the basis of the current state of the object and the identity of the user (which determines whether they have permission to edit the object). The pages that are generated in this way vary according to the type of object.

The main view of the object gives essential information about it, including its name and description and other relevant information depending on the type of object, such as slot values, subclasses and slot constraints. These characteristics can be edited using HTML forms within a separate page.

The changes view gives a list of all the changes that have happened to the object since the list of changes was last looked at. This page also offers a search engine, allowing a user to search for changes on an object by date, the person who made the change, and other details about the change. In the future, it is envisioned that users of APECKS will be notified when they first connect of changes that have happened to roles related to their own, as well as annotations by other people which have been made to their own roles.

The comments view gives a list of the annotations and criteria that pertain to the object. This page also offers a search engine, allowing a user to search for comments on an object by date, the person who made the comment, for keywords within the comment and other objects to which the comment is related.

Finally, to support use by domain experts as well as knowledge engineers, help is available for every type of object. For roles and classes, users may also view pages which display list of suggested actions, supporting knowledge acquisition from the user. These are discussed in detail in the section on the ontology construction phase of APECKS use, below. Separate pages also give links to views of related objects within other roles.

A screenshot of the view of an individual, 'Granite', is shown in Figure 1. Each of the pages shown within APECKS contains a status bar which indicates the type of object, the domain it is in, and (where applicable) the role that it is being viewed under and the class whose instances are being looked at. Under the status bar is a button bar allowing the user to navigate to a different page or create new objects, such as annotations.

Figure 1: A screenshot of the individual 'Granite' in the role 'Gold Standard within APECKS.

4.1 Seeding

The seeding process is a short stage during which the system is set up with information to start the collaborative process. The user community can be given identities at this stage, or create their own identities automatically later. The next step is create an object to hold information about the domain as a whole.

Individuals within the domain are then created and given names, descriptions and, if applicable, URLs of images of the individuals. These form a starting basis for the construction of roles by the other users of the system. Individuals can be created by other users as necessary to give extra examples: the initial set is simply a starting point.

If the user seeding the domain has a good idea about how the roles within the domain should be designed, they might also create a set of criteria to prompt other users in that direction. More about the purpose of criteria is given below, in the section on discussing ontologies.

4.2 Ontology Construction

The second stage, and one that is continuous throughout the life of the system, is one of construction of ontologies by individual users. Users first construct a role to represent their personal view of the domain and the individuals within it. Within that role, they are then free to classify any or all of the individuals within the domain according to their own view.

APECKS supports this process of ontology construction for knowledge engineers by allowing them to explicitly create new individuals, classes, and slots and assigning properties to them. However, because APECKS is also intended for use by people who are not experts at the construction of ontologies, extra knowledge acquisition support is given both internally and externally, in the form of WebGrid (Gaines & Shaw, 1996a & 1996b).

4.3 Ontology Comparison

Once roles have been at least partially constructed, the process of comparing them to locate differences between experts can begin. The comparisons between roles are made using the consensus/conflict/correspondence/contrast classification expounded by Shaw & Gaines (1989). Table 1 shows the four classifications of relationships between conceptual structures.

The above classification was intended for use on repertory grids, which have a flat structure where each element has a rating for each construct. The relationships between ontologies are more complicated than the relationships between grids. Firstly, some of the slots defined within the ontology may not hold values that are suitable for comparisons: these are 'key' values which define an individual uniquely, such as its name or a description of the individual. Secondly, and more importantly, elements within ontologies are not only defined by the values they have in their slots, but also by their position in the class heterarchy.

There are two ways in which the class structure represented within different roles can be compared:

1. Recoding the class structure in terms of categorical slots on the individuals represented within the role or boolean rating scales which represent whether or not an individual is a member of a class.
2. Comparing the classes defined within the ontologies in terms of their instances. In the same way as the names of slots (terminology) and the values that they hold on individuals (attributes) can indicate consensus, conflict, correspondence or contrast between experts, so can the names of classes (terminology) and their instances (attributes). If, within two roles, there are two classes that are named the same and have the same instances as members, this indicates correspondence between the experts. If, within two roles, there are two classes that are not named the same, and yet have the same set of instances as members, this indicates correspondence between the experts. Similarly, if there are two classes that are named the same and have different sets of instances as members, this indicates conflict. Having no overlap in either terminology or the set of instances indicates contrast.

APECKS supports both these methods of comparing class hierarchies and supports the comparison of slots and slot values by converting roles to grids and using WebGrid-II in a similar manner to that described above in the section on using WebGrid for knowledge acquisition.

The result of these comparisons is a number of pages which indicate how roles compare to one another and prompt users to take actions to explore any differences between them. At present, until WebGrid or another similar system gives programmatic analysis of its comparisons, users are only given prompts concerning the class hierarchies in the compared roles. They may then change either the name or instances of a class in a role that they own, or write an annotation justifying the hierarchy they have chosen to use.

Figure 2 shows part of a page which details the differences in the class structure between two roles. Figure 3 shows the WebGrid-II comparison of two roles. Both these figures are from a comparison of two roles: one based on the Gold Standard constructed for the Sisyphus III experiment (the 'Gold Standard' role) and the other on the example on the same material used in Gaines & Shaw (1996a) (the 'WebGrid Example' role).

As can be seen in Figure 2, users are presented with a classification of the degree of similarity between the classes within the roles. The classification not shown here, 'conflict' occurs when classes in the compared roles share the same name but have different instances. When this occurs, users are shown a table displaying those instances which are in the class within each role individually and which are within both. Wherever classes fall within the classification, users are prompted to change its name or instances, or to start discussion about the differences if necessary. In the example above, clicking on the prompt "Create an annotation explaining why you have used the name `small grain'." allows the creator of the 'Gold Standard' role to start asynchronous unstructured communication about the naming of classes.

Figure 3: Extract from a WebGrid comparison of two roles generated through APECKS. (Click for full image.)

Figure 3 illustrates the result of an analysis of the correspondence between the same roles as carried out through WebGrid-II. It also effectively illustrates the problems involved in translating between the richer knowledge structure maintained by APECKS and the flatter one used by WebGrid. In order to use WebGrid, class membership and slots with multiple values are translated into boolean rating scales. The following rows within the grid are particularly illustrative of the issues involved:

• The first row of Figure 3 shows a correspondence between the class 'fine grain size' within the 'WebGrid Example' role and the class 'small grain' within the 'Gold Standard' role. This correspondence is also identified by APECKS, as shown in the page extract above (Figure 2).
• The eighth row of Figure 3 shows how different ways of representing the same information can be seen as corresponding to each other. Within the 'WebGrid Example' role, silica content is coded on a rating scale from 1 (high silica content) to 9 (low silica content) while within the 'Gold Standard' role, the corresponding information is represented as three exclusive subclasses, 'acid', 'intermediate' and 'basic'.
• The ninth and thirteenth row illustrate how users might choose different ways of encoding slots. Within the 'WebGrid Example' role, the colouring of rocks is coded on a rating scale from 1 ('light - leucocratic') to 9 ('dark - melanocratic') whereas within the 'Gold Standard' role, the corresponding slot is categorical, with the three possible values 'melancratic (dark)', 'mesocratic (medium)' and 'leucocratic (light)'.
• The tenth row illustrates how comparing roles in this way can indicate causal knowledge which may otherwise be missing. The presence of alkali feldspar, encoded within the 'Gold Standard' role is related to the colour of the rock, encoded within the 'WebGrid Example' role.
• Some of the correspondence between the two roles indicate the greater detail within the 'Gold Standard' role. For example, the second row might indicate that rocks with porphyritic texture are being classed under 'fine grain size' within the 'WebGrid Example' role.
• Many of the rows, such as the third through to seventh, however, give information that is not of much use for furthering understanding of the domain. These rows show correspondences which appear to be artefacts of both the way slots which take multiple values are translated into constructs for WebGrid and the technique used to compare them. Within the 'Gold Standard' role, the slot 'minerals present' lists the minerals present within the rock. For the purposes of comparison, the slot is translated into multiple boolean rating scale constructs indicating whether or not each individual mineral is present within the rock. This leads to constructs which hold the same value across all elements.

4.4 Discussing Ontologies

Since APECKS is designed to promote communication between users, it is particularly important that it supports a range of styles of collaboration. Communication between individuals can be classified as asynchronous or synchronous, where synchronous communication requires that the participants be copresent, at least temporally, and asynchronous communication does not. Communication can also be classified in terms of the extent to which a structure is imposed on the participants. In structured communication, such as that in The Coordinator (Winograd, 1988), the purpose of each utterance is specified by the participants and they are prompted to follow formats of communication usually based on Speech Act Theory. In The Coordinator, the system prompted its users to send certain types of emails to each other in response to the types sent to them. Structured communication in which a system does not act as an intermediary requires that the participants understand explicit or implicit rules governing their exchanges, such as in word games or wedding ceremonies.

Discussion within APECKS usually occurs as a result of a comparison between two roles: users are expected to argue the case for creating the ontology in the way they have. APECKS supports three of the four combinations of synchronicity and structure in archived communication (unstructured synchronous communication, unstructured asynchronous communication, and structured asynchronous communication) by associating objects with each other using annotations or criteria objects.