A Framework to Specify Hypertext Interfaces for

A Framework to Specify Hypertext Interfaces for Ontology Engineering Gilles Falquet, Claire-Lise Mottaz Jiang Centre Universitaire d'Informatique, Université de Genève Rue du Général-Dufour 24, CH-1211 Genève 4, Switzerland [email protected], [email protected] Abstract Ontology construction is a complex process involving different types of users and multiple tasks. Moreover, it should take place in an integrated environment including the other elements of the organizational memory, such as databases and document bases. In this paper we show that various hypertext interfaces can be created easily using a declarative approach that was originally developed to enable the publication of databases. We first describe the formal ontology model we use and present the hypertext view technique and its application on databases. Then we show how to apply this technique on formal ontologies and finally propose some design principles for hypertext views on ontologies.

1

Introduction

In the past decade, the importance of knowledge management (KM) has been increasingly recognised in organisations. Knowledge management involves collecting and storing knowledge expressed in various forms to facilitate its conservation, access, sharing and reuse. The repository used to integrate all these pieces of knowledge is often called an organizational memory (OM). The OM can contain all kinds of documents, for example catologs, reports, specifications, user manuals, etc. but also formalized knowledge such as an ontology.

1.1

Formal Ontologies

A formal ontology is a set of interrelated concepts together with their definition expressed in a formal language (having a formal syntax and a formal interpretation). During the last decade several formalisms have been proposed to express that kind of knowledge. They range from simple semantic networks (labelled graphs of concepts and relationships) to first order logic. Although first order logic

is highly expressive, its undecidability prevents its acceptance as a universal ontology description language. In the recent years, ontology researchers and engineers have turned to formalisms that are less expressive but decidable, such as frame-based systems and description logics [Brachman et al., 1991; Horrocks et al., 2000].

1.2

Designing Ontologies

The construction of the ontology itself involves two process: formalization of the definitions and "consensualization" on these definitions. The formalization of definition consists in transforming a textual (natural language) definition into a formal one. This is not an easy task, especially if the chosen formalism is very expressive or if the person is not an experienced "ontologist". It is often necessary to go through a few intermediate phases: first write a textual definition from the information collected in documents, then write a first formal definition, using only basic constructs of the language, then add more subtle elements. Consensualization is not a straightforward task either. The ontology should reflect a consensual view of the domain. However, ontology building is usually a collaborative task that includes both domain experts and ontology experts. In addition, in an organisation, there are many different kind of individuals, each having his personal view of the domain according to his background and function. Thus, debates and conflicts on concept definitions are inevitable. Conflicts can occur either on the meaning or on the form of a definition: even people who agree on the meaning of a concept will not necessary use the same words to write its definition. Consensualization consist in trying to reconciliate those different viewpoints in order to get a coherent ontology. To support collaborative work on ontologies, we added IBIS-like components to our concept model. IBIS [Kuntz and Rittel, 1972] provides a structure to discuss and explore open problems: the discussion begins with a question for which the participants can propose possible solutions. The solutions are then argumented positively or negatively. In the case of ontology building,

one of the recurrent question is: "What is the definition of concept X ?" The idea is that participants can express their opinion by creating a definition (possible solution) and linking it to a concept. Then one tries to progress towards consensus, for example by linking each definition to an adequate point of view. In [Falquet and Mottaz Jiang, 2000] we proposed a methodology for analysing and solving definitions conflicts.

1.3

Organizational Memory Structure

Defining concepts in a specific domain entails using general concepts, or concepts from another domain, that are considered to be univocally defined. For example, definitions in the wine domain use concepts such as red, white, and region, that do not belong the domain. It is reasonable to assume that terminological work in a specific domain is possible only if there is an agreement on the concepts that are outside the domain. This is why we consider those concepts as atomic. The ontology thus consists of a working ontology, the one that is being built or maintained, and one or several (fixed) auxiliary ontologies (for example a lexical ontology like WordNet) As we have shown in [Falquet and Mottaz Jiang, 2000 and 2002] the collaborative work on an ontology requires specific data structures to support the building and maintenance processes. For instance, in a multiple-point of view approach, every concept definition must be attached to a point of view. Moreover, conflict detection and resolution implies that users can attach issues, arguments, and endorsements to elements of the ontology. The pure ontology structure together with these process support structures form what we call the multipoint of view ontology. Since most of the factual information of an organization are contained in databases and document bases, these two storage structures must be considered as part of the organizational memory. In addition, the ontology development process can and must refer to information found in the organization’s databases and/or document bases. Thus we consider that an integrated organizational memory is composed of the parts shown on the following figure. We will see in section 4 that the interface model we propose can generate integrated views of the whole organizational memory.

Auxiliary Ontologies

Extended ontology / method support Ontology

Database(s)

Document base(s)

Fig. 1. Components of the organizational memory

1.4

The Complexity of the Ontology Interfacing Problem

There are several reasons that make it difficult to build efficient user interfaces for ontologies. Let us consider an ontology that is stored in a database. The schema of such a database can be quite simple, a few tables are sufficient to represent the objects of an ontology (see section 3.2 for an example), so one could be tempted to apply usual database interfacing techniques. This means presenting the database content in tabular form and use forms to input new data. But this approach won't work because the complexity does not lie in the database schema but in the data themselves. Indeed, the data form a complex network of interrelated objects that represent concept definitions and links between concepts. Even with simple knowledge representation models (like semantic networks or frame-based systems), the definition of a concept refers to other concepts. More expressive models, like description logic and first order logic, need more sophisticated representations (e.g. syntax trees). Moreover, there exist implicit relationships between concepts (subsumption, equivalence, degrees of similarity, syntactic symilarity, etc.) that play an important role in ontology design. Thus the user interface cannot be simply derived from the database schema. It must provide the user with interface objects that are well adapted to the graph and tree nature of this particular kind of data. Again, this is not easy because there is no universal technique for presenting a complex graph on a screen. Thus the interface designer must select the most efficient presentation techniques, and this may depend on the ontology's structure or on the domain's structure. Another difficulty stems from the semantics of data. The objects stored in an ontology database represent abstract things, namely concepts, that may have complex descriptions. Thus, working on an ontology (defining concepts, linking them, placing them in a hierarchy, etc.) is a hard task, compared to working with a database that represents simple and well known objects (e.g. a library database, a flight reservation system, or a product database). The ontology interface must thus help the user understand the data he or she is working with. For instance, it must provide tools to compare concepts, to view examples, to give explanations, etc. Finally, as mentioned in 1.3, data that represent the ontology form only a part of the extended ontology. The extended ontology contains data to support the design process (e.g. IBIS support, representation of different point of views, etc.). It is clear that the ontology interface must not only provide access to these data but also support the intended design process. This means that the interface must show an integrated view of the extended ontology. Since the extended ontology has a more complex schema than the ontology alone, it is quite obvious that there is no single "optimal" interface for this database.

For all these reasons, it is probably vain to work on the definition of an ontology engineering interface. What we propose here is a general formalism to specify ontology engineering interfaces (independent of the ontology formalism and the design methodology).

2 State of the Art This section starts with a short review of existing ontology development tools. Then, we briefly present the relationships between hypertexts, knowledge representation and databases. It motivates the use of the hypertext paradigm to build efficient knowledge base interfaces.

2.1

-

Ontology Development Tools

Over the past few years, many ontology and knowledge base development tools have been developed [OntoWeb, 2002; KAON, 2003]. Some of them, like Protégé [Fridman Noy et al., 2000] and OilEd [OntoWeb, 2002] are intended for a single user. Other tools provide different ways to support collaborative work. For instance, WebODE [Gómez-Pérez et al., 1998] and OntoLingua [Farquhar et al., 1996] have mecanisms that enable to manage groups of users and control access to the ontologies. WebOnto [Domingue, 1998] (through Tadzebao) and APECKS [Tennison and Shadbolt, 1998] both have a synchronous dicussion feature. CO4 [Euzenat, 1996] uses a vote protocol to create a consensual knowledge base. Tools that are intended for multiple users usually feature a web-based interface (hypertextual or graphical, using for example Java Applets). For authoring and querying, the most used paradigm is forms. Each of these tools has a slightly different presentation style, but what is common is that they only display explicit information coming directly from the representation language. They do not use deduced or computed information. Some systems include analysis tools. For example, CODE4 [Skuce and Lethbridge, 1995] provides a "property matrix" to compare properties of two or more concepts. WebGrid [Gaines and Shaw, 1996] can be used to compare the conceptual systems of two experts. In [Ng, 2000], Ng presents the InfoLens, a technique that is aimed at finding patterns within large knowledge bases. Some tools, for instance SemNet [Fairchild et al., 1988] include new visual formalisms to represent knowledge bases, while others, like Ontobroker [Fensel, 2001] use general visualization techniques, such as hyperbolic trees [Lamping et al., 1995]. Even though there exists many tools to develop ontologies, some important needs remain currently neglected: -

-

In many cases, one has to work directly on formalized definitions. This supposes that the formalization work has occured before the actual edition of the ontology. Exceptions to this are WebODE and Terminae [Biébow and Szulman, 1999]. WebODE uses intermediary

-

representations (tables) to "hide" the underlying formalism and thus tries to be more user-friendly towards non-ontologists. Terminae actually supports the formalisation process by following the traditional methodology used by terminologists, with the addition of a few steps. Concerning collaboration, many ontology editors are more intended to store the result of the consensualization than to support its process. In systems that do include some support to the process (such as Tadzebao, APECKS or CO4), it is still difficult to have a general view of the various viewpoints. The ontology must be tightly integrated with information sources (OM). In fact, when an ontology builder works, he or she must constantly refer to data sources or documents to validate his or her conceptualization. Hence, the engineering environment should provide him or her quick and easy access to reference material. This is in fact not often the case, except in tools such as Terminae. A single interface cannot be the best in all situations. It must be possible to customize the tool’s interface according to the specificities of the domain and to the reference data and documents. This customization must be structural (i.e. not limited to changing the appearance of objects on screen) and it must be simple (i.e. not requiring specific programming). Protégé and LinkFactory [OntoWeb, 2002] are in fact extensible, but imply the programming of plugins (Protégé) or Java beans (LinkFactory).

In this paper we propose a framework for specifying ontology engineering interfaces that take into account the above-mentioned issues. This framework relies on the hypertext view principles and techniques. We will first motivate our approach by presenting the long-standing relationships between hypertexts, knowledge bases, and databases. Then we will present the declarative hypertext view technique and its application on ontologies and organizational memories. The next section will present design principles to build hypertext views for ontology engineering in an organizational memory context.

2.2

Knowledge Representation and Hypertexts

Designers and developers of hypertext systems, in particular “pre-Web” systems, have often sought to represent formalized and non formalized knowledge in the same hypertext. In fact, hypertexts have often been considered as a means for sharing knowledge among a community of users (this was also one of the motivations the pushed the Web’s development at CERN). KMS [Ackscyn et al., 1988], AquaNet [Marshall et al., 1991], MacWeb [Nanard and Nanard, 1993] and WebMap [Gaines and Shaw, 1995] are examples of systems where there is an underlying knowledge model to structure the hypertext or to facilitate information retrieval. The importance of the knowledge

formalisation aspect has been particularly stressed in MacWeb. The MacWeb model clearly identifies a document level (information), a knowledge level (a semantic network of concepts), an anchoring level that connects (parts of) documents to concepts (characterization), and a task level that produces virtual documents derived from the three other levels. Since the hypertext paradigm has already been used in knowledge sharing systems, it is not surprising that this kind of database interface is well adapted to presenting knowledge base contents.

2.3

Database Interfaces Publishing of Databases

and

Hypertext

Databases have long been used to store common data and share them efficiently and reliably among a number of users. Since there exist many tools to develop database applications and interfaces, it seems natural to simply store the ontology in a database and to build ontology engineering tools with database development tools. However, these tools are intended to develop "typical" database applications and are not specifically targeted at knowledge or ontology management applications. In particuliar, they usually provide form-based or table-based views of the data. A hypertext view is a derived (computed) hypertext that represents the contents of some underlying information source. The idea is to provide the user with an easy to use hypertext interface that enables him or her to navigate within the information source. Thus it replaces database querying or other complex access mechanisms with just hypertext link following. We can define the notion of hypertext view of a database as a set of hypertext nodes and links that -

present the contents of the database to the hypertext user, replace database querying by hypertext navigation, enables the authorized user to act on the database in order to update its content.

The hypertext paradigm has already been widely and successfuly used to present database contents on the web and there already exist several tools to build web interfaces for databases (see for instance PHP (www.php.net), ColdFusion (www.macromedia.com) or Oracle Web Server (www.oracle.com) among others). Although these systems provide user-friendly interfaces to databases, developing hypertext interfaces with these systems is still a demanding and error-prone task because -

the approach is procedural (programs or scripts must be written to produce page contents), the languages are weakly typed and there is no compiletime type checking.

The declarative specification of hypertext views is a more promising approach because it does not require any procedural programming. In this approach a set of construction rules specifies the hypertext structure and contents. These rules usually take the form of node schemas, which contain a data selection part, a content construction part, and a link construction part. Since the specification language has a high level of abstraction, new hypertext views can be specified by non-programmers. In addition, a declarative view specification is easier to study than a programatic one. Thus the interface designer is enabled to analyze the interface structure, for instance to check its properties. In the rest of this paper we will show that -

-

the declarative specification of hypertext views is an efficient approach to rapidly build effective and customizable (extensible) hypertext interfaces to knowledge bases, this formalism can be used to describe a design methodology for building interfaces to knowledge bases and to the whole organizational memory.

3 A Hypertext View Approach to Specify Ontology Interfaces In this section we will show how to create ontology engineering tools with a hypertext view specification system. The first step consists in defining an appropriate data structure to store an ontology in a database (reification). Then one can define node schemas on this database.

3.1

Description Logics and its Representation

The approach we propose is applicable to any ontology formalism. However, in order to enable the illustration of this approach with concrete examples, we briefly present the model we used in our experimentation. We use a formal concept model that belongs to the description logics (DL) family. This model and its semantics correspond to the SQ language of [Horrocks et al., 2000]. The main advantage of this formalism is that it is simple enough to use for non-specialists and that it has a greater expressive power than object or "semantic" models like UML or RDF [Lassila and Swick, 1998]. In fact, it is slightly more powerful than the type of DL on which OWL or DAML+OIL are based because number restrictions and range restrictions can be grouped together. In this language, a concept is defined using one the following constructs: -

an atomic concept is simply defined by its identifier (there is no further definition in the ontology) the union, intersection, or difference of two concepts

-

a role restriction - exists (min, max) role: range every instance of the concept is linked to at least min and at most max instances of concept range through role - all role: range if an instance of this concept is linked through role to another instance, this last instance must belong to concept range

In addition, a subconceptOf constraint can be used to indicate that this concept's extension is included in another concept's extension. Example concept WINE is subconceptOf POTABLE-LIQUID ( all MAKER (1,*): WINERY and all GRAPE-SLOT (1,*): WINE-GRAPE and all region (1,*): WINE-REGION )

This definition means that "A wine is a potable liquid, it has at least one maker; all makers having to be wineries and it is made of one or several grapes, all of them being winegrapes and it is produced in one or more regions and all of these regions must be wine-regions". (The form all MAKER (1, *) : WINERY is an abbreviation for (all MAKER: WINERY) and (exists (1, *) MAKER: WINERY)). A more detailed description of this concept model can be found in [Falquet and Mottaz Jiang, 2000]. The data structure shown on Figure 2, can represent any concept defined with this model (it forms the meta-ontology level). It forms the purely ontological part of the organizational memory. subconcept

concept argument

atomic

rangeRestriction

id

intersection

appliesTo

union

roleRestriction min max quantifier role

Fig. 2. Structure of the ontology in UML-like notation

(the appliesTo association is not strictly necessary, it is a shortcut to directly reach the role restrictions that belong to a concept's definition)

3.2

An Ontology Formalism

Interface

Specification

In the rest of this paper we will make use of the Lazy hypertext view specification language [Falquet et al., 1998]. The Lazy language was designed to specify and implement hypertext views on relational and object databases. The language has been applied to generate different Web applications, ranging from virtual museums to electronic books or accounting. Since the language is purely declarative, hypertext views can be specified without any programming . Principles The hypertext specification language is based on the concept of node schema. A node is comprised of -

a set of parameters a content specification (made of element specifications) link specifications a selection condition (what database objets to select)

The instantiation of a node consists in interpreting a node schema for a given set of arguments and on the current state of the database. An instance of a node schema is obtained by first selecting the objects (e.g. relation tuples) of the data collection(s) that satisfy the selection expression. Then the content and link specifications are evaluated on each selected object to generate node contents and links to other nodes. Since the purpose of this paper is not to describe the details of the specification language, but to show its principles, we will base our presentation on examples. Hypertext node schemas on a DL ontology In the following examples, we will suppose that the ontology is stored in a relational database (an implementation of the conceptual schema in Figure 2). This database contains the following tables: table Concept(id, defCategory) table AtomicConcept(id) table RoleRestriction(id, appliesTo, quantifier, min, max, role, rangeRestriction) table SubConcept(sub, sup) -- sub is (the identifier of) a subconcept of sup. table DefinedBySetOperation(id, operation) table Argument (soConcept, argConcept) -- argConcept is an argument of soConcept, which is defined by a set operation

Consider the following node schema node SubConceptsOf[c] "Subconcepts of " , c { sub , href RolesOf [sub] ("details") } from SubConcept selected by super = c

This schema is defined on the SubConcept table, it selects all the (super, sub) tuples of this table that have their super attribute equal to c, i.e. all the relationships between c and one of its subconcepts. Thus, an instance SubConceptsOf [c] of this schema will show the identities (sub) of all the suconcepts of c. The content specifications between { and } are generated for each selected tuple. In addition, a reference link is generated that points to the node instance of the RolesOf schema defined below. Figure 3.1 shows an instance of this schema.1

3. Fig. 3. A node instance SubConceptsOf[POTABLE-LIQUID]

node RolesOf[c] "Role restrictions on " , c { quantifier, role, min max rangeRestriction } href SubConceptsOf [c] ("View subconcepts") from RoleRestriction selected by appliesTo = c

This schema is intended to show all the role restrictions that apply to a given concept c (figure 3.2). The href link outside the repeated part is generated only once, to produce a link to the node showing the subconcepts of c. The figure below shows a part of the hypertext view made of three node instances connected through hyperlinks.

1.

In the Lazy model there are three types of links: reference links (the well known web links), inclusion links (to include the content of another node at this location), and expand in place links (clicking on such a link will open the target node at the link location, i.e. within the source node). These last two types of links are essential to build usable interfaces. For instance, inclusion links make it possible to build complex hierarchical nodes while expand-in-place links enable the user to interactively explore complex structures by opening and closing sub-components. We will see in the next sections examples illustrating the usefulness of these types of links. If we slightly modify the SubConceptsOf node, by adding an expand-in-place link to the same node schema, we immediately obtain a typical "class browser" view. node Browse[c] { subID , href RolesOf [sub] ("details") , expand href Browse [sub] ("sub") } from SubConcepts selected superID = c

Figure 4.1 shows an instance of Browse after three 'expand' links have been followed (opened). We can also define a schema that shows the complete definition of a concept by including a node to display its superconcepts and a node (e.g. RolesOf defined above) to display its role restrictions. An example of a node instance is shown in the figure below (figure. 4.2). 2.

1

The instances shown here have been obtaines with the Lazy system. This system compiles node specifications and executes the compiled code when a node instance is requested. A detailed presentation of Lazy can be found in [Falquet et al., 1998 and 2001; Lazy, 2003].

ontology backbone (and provided these ontologies are written in the same formalism), one can create a few core reusable interface elements. Those elements can be combined to create various basic interfaces suited to the needs of different users. The interface design process we propose consists of several steps: 1. 2.

3.

Build a hypertext view of the ontology (by assembling basic reusable elements). Extend this view to the ontology engineering structures that are necessary to support ontology building and maintenance (support for multiple point of views, collaboration, conflict resolution, etc.). Extend the hypertext view to encompass the whole organizational memory.

In this section, we will successively present the parts of this design process.

4.1

Basic Interface Elements

Several authors have stressed the importance of navigation when building a knowledge base. According to Ng [Ng, 2000], at the highest level, there are three different ontology modeling tasks: authoring, exploring and verifying. Navigation plays an essential role in all these tasks:

1.

-

2. Fig. 4. Node instances Browse[WINE] (class browser) and Def[WINE] (role restrictions)

Finally, active links can make the hypertext view active. When an active link is followed, it (possibly) sends input field values to the node server and then triggers an action on the underlying databases (insert, delete, update, or procedure call). This enables the user to update the databases by navigating in the active hypertext view.

4 Towards an Interface Design Methodology for Organizational Memories Every organisational memory is different (according to the activity area of the organisation, the type of documents it contains, etc). Thus is is not possible to propose just one "one size fits all" interface that can be used everywhere. However, for organisational memories that have a formal

Obviously, navigation is the easiest way to explore an ontology. Before adding any new concept, it is necessary to navigate through the ontology to find the appropriate location and to verify that it does not already exist. Then, one should gain a good knowledge of the already used vocabulary, so as to avoid introducing unnecessary heterogeneity to facilitate later retrieval. While doing verifications such as checking domain coverage or ontology coherence, one must first have a thorough knowledge of what exists in the ontology.

Although the ontology representation is a simple data structure (e.g the one shown in figure 2), it is not an easy task to design an efficient hypertext view for this structure. However, a method based on refinement and augmentation of an initial hypertext view structure can lead to a suitable interface, as was shown in [Falquet et al., 2001 and 2003].

4.1.1 Initial Structure An initial structure is a basic hypertext interface that enables the user to visualize the whole ontology through navigation. The most obvious way of navigating in an ontology consists in following the semantic links between concepts. These links correspond to -

role restrictions (going from a concept to the concept is a range restriction of a role, e.g going from WINE to WINERY through the MAKER role - and vice versa),

-

operation arguments (going from a concept to the concept it is made of), subconcept constraints (going from a concept to its direct sup- or superconcepts).

Although it is possible to explore the internal organization of the ontology by following the semantic links, it is easy to get lost and it does not offer a general overview of the ontology (a well known interface design principle, mentioned by Schneiderman [Schneiderman, 1997], is to have both a general overview and local views). Thus, the initial structure should at the very least be added a simple concept browser and a node that displays the complete definition of a concept (as in figure 4). This initial structure can be specified by just a few node schemas that are very similar to those presented in section 3. The initial structure can be generated automatically. We have indeed implemented an initial structure generator for databases that could also be used for ontologies with only minor adaptations.

4.1.2 Other Navigations Patterns The class browser of the initial structure is generally a very useful tool. Indeed, most of the currently popular ontology development tool includes one. However, there remain some problems. For example, it is not always evident to determine from which top-level concept to begin the search for a more specific concept. This problem in fact occurs at each level of the hierarchy. Moreover, the browser functions well in the case of a taxonomical ontology, but not much so if the ontology has the shape of a network. For these reasons, it is necessary to offer other ways to locate the relevant concept, in particular, different types of navigation, for example, using computed links.

Syntactic similarity An important aim of ontology construction is to obtain a regular structure, in the sense that the same thing should be named and represented in the same way. It is for instance crucial to keep the number of role names as small as possible and to avoid synonyms in role names. Thus the ontology designer must be provided with tools that show how similar definitions have been formalized. For example, one could create a node showing the list of role names used in the ontology, with a link to a node giving the list of concepts using a particular role.

4.1.3 Assembling Basic Interface Elements Once the basic interface elements (node schemas) have been created, one can combine them to produce more complex nodes, according to the needs of different types of users. As basic interface elements are Lazy nodes, one can put them together using inclusion links. Below is an example of a complex hypertext node instance. Its node schema has been defined by including other nodes schemas. The node instance shown here includes the following nodes: -

-

a node that shows all the superconcepts of the concept cupboard, up to the top-level concept of the domain, a node that displays all the role restrictions, a node that gives the subconcepts of cupboard, a node schema that displays all the concepts whose distance to cupboard is less than 0.5 (in fact this node generates a list of concepts and distances that is passed as parameter to a 3D graph display applet), a node with a list of related documents.

Proximity (affinity) navigation The aim of this type of navigation is to discover similarities between concepts that are not directly connected (they can even lay far apart in the concept DAG). This navigation requires a similarity relation, or a distance, that is computed by comparing concept definitions (for instance, in [Falquet and Mottaz Jiang, 2000] we propose a conceptual distance based on tree comparison). Then links can be created between concepts whose distance to one another is below a given threshold. The following node schema displays a list of concepts that are considered as similar to c (according to the dist distance). node conceptsNear[c] { display concept information and links to detailed nodes } from Concept selected by dist(c, id) < threshold

Fig. 5. Example of complex view (ontology of the furniture domain)

4.1.4 Updating the Ontology The Lazy hypertext view definition language features an active link mechanism that is intended to trigger database actions (insert, delete, update) when a link is followed. In addition, the source anchor of an active links can collect user inputs (through a form mechanism). Thus, the interface designer can provide update mechanisms within the hypertext interface. For instance, the following node schemas is intended to add a role restriction to concept c. node newRoleRestrictionOn [ c ] active href RolesOf [c] ( set appliesTo = c, set min = textfield(10), set max = textfield(10), … on "save" do insert RoleRestriction )

The active href link of this schema will display a form to input attribut values (min, max, etc.) and a "save" button. When clicked, this button will first perform the specified insert action, with the given attribute values, then it will jump to the RolesOf[c] node. Navigation and active links can be combined to produce sophisticated update patterns. For instance, values can be collected along a multi-step navigation path and eventually used by an active link to update the database.

4.2

Once this node has been defined, it can be referred to or included in other node schemas. Thus the user will be able to view the corresponding annotations when browsing or navigating the ontology. The following node schema shows how to insert new annotations for a given concept c. Its active link sets attribute values (the text value is taken from an input field) and when followed (by clicking "save") it inserts a new tuple into the database. node WriteNoteOn[c] active href ViewConcept[c] ( set onConcept = c, set text = textfield() , set author = USER on "save" do insert into Annotation )

The following figure shows a node that displays concepts together with expand-in-place links to their annotations (the annotations on WINE have been opened) and to a WriteNoteOn node (the user is currently writing a note on TEA).

Extensibility of the Model

Ontology engineering, whatever the approach or method, requires additional data structures to be coupled with the pure knowledge representation structure. For instance, in a multi-point of view approach, every definition must be related to a point of view. In a collaborative environment, specific data structure must be set up to represent comments, issues, arguments, decisions, etc. These engineering data must of course appear in the ontology engineering interface. Moreover, they can influence or dictate the design of the user interface. Example. Adding an annotation functionality to the ontology interface. The annotation data structure is simply a table that holds the annotations texts, authors, and references to the annotated concepts definitions. Annotation(text, author, onConcept)

Then it is sufficient to add a node schema of the following form to view annotations in the interface. node NotesOn[c] { show the annotation text and author } from Annotation selected by onConcept = c

Fig. 6. Viewing and editing annotations

4.3

Seamless Integration of the Ontology in the Organizational Memory

The integration of the ontology in the organizational memory cannot be automated. Indeed, it depends on how documents and data are organized. For example, in order to be able to create a link between the ontology and the database, one has to know the database schema, which is of course different in every organisation. The same is also true for documents: how are they stored ?

4.3.1 Accessing Related Data Suppose that a ”wine” ontology is built on top of a database that contains information about wine prices, availability, etc. If this database has a table wine(name, color, maker, region, productionYear, quantity-on-hand, etc.) one can construct a view that shows both ontological information and operational data. This shows that the hypertext view technique can integrate in a single view different levels of abstraction. In fact, this is a common situation and it shows the necessity to have a sophisticated mechanism to link the ontology and the database. It is clearly insufficient to state the equation “domain concept = database table or database class”. Some concepts do indeed correspond to a database table, but there can also be the case where a concept corresponds to a table attribute. Some concepts even have no correspondance at all in the database. In our situation, the view mechanism precisely plays this role of sophisticated matching between the ontology and data levels.

4.3.2 Accessing Related Documents Documents are often the primary source of information to create and validate an ontology. It is thus important to provide the ontology designer with views of the document base. If the document base is stored in a database, it is straightforward to define hypertext views on the document base and to interconnect the ontology and the document base. The ontology can in turn serve as a meta-navigation tool within the documents. If the documents are stored outside the database, one can easily create a link between them and their related domain concepts, using the same extension mecanism as for the annotations. It consists in creating a table containing the concept identifier, and some important informations on the document, such as its title and location. For example: relatedDocument(concept, docTitle, docURL)

Then it is sufficient to add a node schema of the following form to view a concept’s related documents in the interface. node relatedDoc[c] { docTitle, href docURL } from relatedDocument selected by concept = c

5

Conclusion

In this paper, we show that sophisticated user interfaces for collaborative ontology engineering can be specified by defining simple hypertext node schemas. Since the node schema definition language is concise and simple, the interface can easily be extended and maintained by non programmers and non database specialists. Although based on simple constructs, the specification language is nevertheless sufficiently powerful to define views to represent recursive structures (e.g. a definition tree, or a

subconcept hierarchy) or to build complex heterogeneous nodes. This delarative language is also well adapted to an incremental approach of interface design. Hence, we proposed an interface design methodology that starts with an initial interface on the core ontology and then extends and refines it. Another important point is the integration capability offered by hypertext view approach. These interfaces can span not only the ontology but also related parts of the information system (data bases, document bases), thus providing integrated environments for the knowledge workers.

Acknowledgements We would like to thank the anonymous referees for their insightful comments that helped us improve this paper.

References [Ackscyn et al., 1988] Ackscyn, R., McCracken, D., Yoder, E. KMS: a distributed hypermedia system for managing knowledge in organizations, in Communications of the ACM 31, 820-835, July 1988. [Biébow and Szulman, 1999] Biébow B., Szulman S. TERMINAE: A Linguistic-Based Tool for the Building of a Domain Ontology, EKAW 99 Proceeding, Springer Verlag, 1999. [Brachman et al., 1991] Brachman, R., McGuinness, D., Patel-Schneider, P., Borgida, A. and Resnick, L. Living with CLASSIC: When and How to Use a KL-ONE-Like Language, in Principles of Semantic Networks. Morgan Kaufman. pp. 401-456. May 1991. [Domingue, 1998] Domingue, J. Tadzebao and WebOnto: Discussing, Browsing, and Editing Ontologies on the Web., Proceedings of the 11th Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW 98), Banff, Canada, 1998. [Euzenat, 1996] Euzenat J. Corporate memory through cooperative creation of knowledge bases and hyperdocuments, Proceedings of the Tenth Knowledge Acquisition Workshop (KAW 96), Banff, Canada, 1996. [Fairchild et al., 1988] Fairchild, K. M., Poltrock, S. E., Furnas, G. W. SemNet: Three-Dimensional Graphic Representationof Large Knowledge Bases, in Guidon, R. (Ed.), Cognitive Science and its Application for HumanComputer Interaction, Lawrence Erlbaum, Hillsdale, NJ, USA, 1998. [Falquet et al., 1998] Falquet G., Guyot J., Nerima L. Languages and Tools to Specify Hypertext Views on Databases, WebDB'98, Valencia, Spain, March 1998, selected papers, LNCS 1590. [Falquet et al., 2001] Falquet G., Guyot J., Nerima L., Park S. Design and Analysis of Virtual Museums, in

Proceedings of the Museums and the Web Conference, Seattle, 2001 [Falquet and Mottaz, 1999] Falquet G., Mottaz C.-L. A Model for the Collaborative Design of Multi-Point-ofView Terminological Knowledge Bases, in Proceedings of the Knowledge Management and Organizational Memory workshop of the IJCAI 99 Conference, Stockholm, 1999. [Falquet and Mottaz, 2002] Falquet G., Mottaz C.-L. A Model for the Collaborative Design of Multi-Point-ofView Terminological Knowledge Bases, in Dieng-Kuntz R., Matta N. (eds) Knowledge Management and Organizational Memories, Kluwer, 2002. [Falquet and Mottaz Jiang, 2000] Falquet G., Mottaz Jiang C.-L. Conflict Resolution in the Collaborative Design of Terminological Knowledge Bases, EKAW 2000, Juanles-Pins, LNAI 1937, Springer-Verlag, 2000. [Falquet and Mottaz Jiang, 2001] Falquet G., Mottaz Jiang C.-L. Navigation hypertexte dans une ontologie multipoints de vue, in Proceedings of the Nimestic01 Conference, Nîmes, 2001. [Falquet et al., 2003] Falquet, G., Guyot, J., Nerima, L., Park, S. Design and Analysis of Active Hypertext Views on Databases in P. Van Bommel (Ed.) Information Modeling for Internet Applications, Idea Group Publishing, 2003. [Farquhar et al., 1996] Farquhar A., Fikes R., Rice J. The Ontolingua Server: a Tool for Collaborative Ontology Construction, Proceedings of the Tenth Knowledge Acquisition Workshop (KAW 96), Banff, Canada, 1996. [Fensel, 2001] Fensel D. Ontologies: a Silver Bullet for Knowledge Management and Electronic Commerce, Springer Verlag, 2001. [Fernandez et al., 1998] Fernandez, M., Florescu, D., Kang, J., Levy A., Suciu, D. Catching the boat with Strudel: experience with a web-site management system, In Proceedings of SIGMOD'98 Conference, 1998. [Fridman Noy et al., 2000] Fridman Noy N., Grosso W., Musen M. A. Knowledge-Acquisition Interfaces for Domain Experts: An Empirical Evaluation of Protégé2000, SMI Technical report SMI-2000-0825, http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI2000-0825.html, 2000. [Gaines and Shaw, 1995] Gaines B. R., Shaw M. L. G. WebMap: Concept Mapping on the Web, World Wide Web Journal 1 (1) 171-183, 1995. [Gaines and Shaw, 1996] Gaines B. R., Shaw M. L. G. WebGrid: Knowledge Modeling and Inference through the World Wide Web, Technical Report, Knowledge Science Institute, University of Calgary, Canada, http://repgrid.com/reports/KBS/KMD/index.html, 1996. [Gómez-Pérez et al., 1998] Gómez-Pérez A., Fernández M., Blázquez M., García-Pinar J. M. Building Ontologies at

the Knowledge Level using the Ontology Design Environment, Proceedings of the 11th Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW 98), Banff, Canada, 1998. [Horrocks et al., 2000] Horrocks I., Sattler U., Tobies S. Practical Reasoning for Very Expressive Description Logics, Logic Journal of the IGPL, Volume 8, Issue 3, 2000. [KAON, 2003] http://kaon.semanticweb.org/ [Kietz et al., 2000] Kietz J.-U., Maedche A., Volz R. A Method for Semi-Automatic Ontology Acquisition from a Corporate Intranet. EKAW 2000 workshop on Ontologies and Texts, 2000. [Kuntz and Rittel, 1972] Kuntz, W., Rittel, H. Issues as elements of information systems. Working Paper No 131, Institute of Urban and Regional Development, University of California at Berkeley, 1972. [Lamping et al., 1995] Lamping, J., Rao, R. , Pirolli, P. The Hyperbolic Browser: A Focus+Context Technique for Visualizing Large Hierarchies, in Proc. ACM CHI’95 Conf., New York, 1995. [Lassila and Swick, 1998] Lassila O., Swick R. Resource Description Framework (RDF) Model and Syntax Specification, W3C Working Draft, 08 October 1998. [Lazy, 2003] Lazy system home page. http://cui.unige.ch/isi/lazy, 2003 [Marshall et al., 1991] Marshall C., Halasz F., Rogers R., Janssen W. Aquanet: A Hypertext Tool to Hold Your Knowledge in Place, in UK Conference on Hypertext, pp.261-275, 1991. [Nanard and Nanard, 1993] Nanard, J., Nanard, M. Should Anchors be Typed Too ? An Experiment with MacWeb, in Proc. of the HT’93 Conf., 51-62, 1993. [Ng, 2000] Ng G. K. C. Interactive Visualisation Techniques for Ontology Development, PhD thesis, University of Manchester, UK, 2000. [OntoEdit, 2002] OntoEdit, retrieved from http://www.ontoprise.de on May 10, 2002. [OntoWeb, 2002] OntoWeb (Ontology-based information exchange for knowledge management and electronic commerce) A survey on ontology tools, 2002. [Schneiderman, 1997] Schneiderman B. Designing the User Interface, Addison-Wesley, 1997. [Skuce and Lethbridge, 1995] Skuce D., Lethbridge T. CODE4: A Unified System for Managing Conceptual Knowledge, International Journal of Human-Computer Studies, 1995. [Studer et al., 1998] Studer R., Benjamins V., Fensel D. Knowledge engineering: Principles and methods. IEEE Transactions on Data and Knowledge Engineering, 25:161 – 197, 1998.

[Swartout et al., 1996] Swartout B., Patil R., Knight K., Russ T. Toward Distributed Use of Large-Scale Ontologies, Proceedings of the Tenth Knowledge Acquisition Workshop (KAW 96), Banff, Canada, 1996. [Tennison and Shadbolt, 1998] Tennison J., Shadbolt N. R. APECKS: a Tool to Support Living Ontologies, Proceedings of the 11th Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW 98), Banff, Canada, 1998. [Ushold and King, 1995] Ushold M., King M. Towards a Methodology for Building Ontologies, Workshop on Basic Ontological Issues in Knowledge Sharing (in conjunction with IJCAI-95), 1995.