Available via license: CC BY-NC-ND 4.0
Content may be subject to copyright.
- 1 -
The Ontolingua Server:
a Tool for Collaborative Ontology Construction
Adam Farquhar Richard Fikes James Rice
Knowledge Systems Laboratory
Stanford University
Gates Building 2A MC9020
Stanford, CA 94305
{afarquhar,fikes,rice}@ksl.stanford.edu
Abstract
Reusable ontologies are becoming increasingly important for tasks such as
information integration, knowledge-level interoperation, and knowledge-
base development. We have developed a set of tools and services to sup-
port the process of achieving consensus on common shared ontologies by
geographically distributed groups. These tools make use of the world-
wide web to enable wide access and provide users with the ability to pub-
lish, browse, create, and edit ontologies stored on an ontology server. Us-
ers can quickly assemble a new ontology from a library of modules. We
discuss how our system was constructed, how it exploits existing protocols
and browsing tools, and our experience supporting hundreds of users. We
describe applications using our tools to achieve consensus on ontologies
and to integrate information.
The Ontolingua Server may be accessed through the URL
http://ontolingua.stanford.edu/
1. INTRODUCTION
1.1 The Need for Ontologies
In order for an agent to make statements and ask queries about a subject domain, it must
use a conceptualization of that domain. A domain conceptualization names and describes
the entities that may exist in that domain and the relationships among those entities. It
therefore provides a vocabulary for representing and communicating knowledge about
the domain.
Explicit specifications of domain conceptualizations, called ontologies, are essential for
the development and use of intelligent systems as well as for the interoperation of hetero-
geneous systems. They provide the system developer with both the vocabulary for repre-
senting domain knowledge and a core of domain knowledge (i.e., the descriptions of the
vocabulary terms) to be represented. Ontologies inform the system user of the vocabu-
lary that is available for interacting with the system and about the domain and the mean-
ing that the system ascribes to terms in that vocabulary. Ontologies are also crucial for
enabling knowledge-level interoperation of agents, since meaningful interaction among
agents can occur only when they share a common interpretation of the vocabulary used in
their communications. Finally, ontologies are useful in many ways for human under-
standing and interaction. For example, they can serve as the embodiment of (and refer-
ence for) a consensus reached by a professional community (e.g., physicians) on the
meaning of a technical vocabulary that is to be used in their interactions (e.g., exchange
of patient records).
Ontology construction is difficult and time consuming. This high development cost is a
major barrier to the building of large scale intelligent systems and to widespread knowl-
- 2 -
edge-level interactions of computer-based agents. Since many conceptualizations are in-
tended to be useful for a wide variety of tasks, an important means of removing this bar-
rier is to encode ontologies in a reusable form so that large portions of an ontology for a
given application can be assembled from existing ontologies in ontology repositories.
We have been working to develop and disseminate effective easy-to-use tools for creat-
ing, evaluating, accessing, using, and maintaining reusable ontologies (Fikes et al. 1991).
We have developed a set of tools and services to support not only the development of
ontologies by individuals, but also the process of achieving consensus on common on-
tologies by distributed groups. These tools make use of the world-wide web to enable
wide access and provide users with the ability to publish, browse, create, and edit ontolo-
gies stored on an ontology server. The design of the web-based interface and the under-
lying infrastructure is detailed in (Rice et al. 1996). These tools and services provide
many of the facilities that are crucial for promoting the use of ontologies and knowledge-
level agent interaction including:
•A semi-formal representation language that supports the description of terms both in-
formally in natural language and formally in a rigorous computer interpretable
knowledge representation language. We use an extended version of the Ontolingua
language (Gruber 1992) which provides a frame-like syntax in addition to full first
order logic as specified in the Knowledge Interchange Format (KIF) (Genesereth and
Fikes 1992). The language supports semi-formal definitions through the use of
documentation strings and notes in addition to the formal specifications.
•Browsing and retrieval of ontologies from repositories. Browsing requires presenta-
tion of formal descriptions in an easily understood format. We make it easiest to ex-
press and browse knowledge that fits into an object-oriented frame view. We believe
that the growing popularity of object systems (languages, databases, CORBA, etc.)
substantially widens the group of people that are comfortable working in this para-
digm. The key, however, is that the presentation of these objects is separated from
their internal representation.
•Assembly, customization, and extension of ontologies from repositories. This re-
quires the ability to identify and resolve name conflicts and to augment descriptions
of terms from the assembled ontologies. We have extended our Ontolingua language
so that users can quickly assemble a new ontology from a library of modules, as well
as extend or restrict definitions from the library.
•Facilities for translating ontologies from repositories into typical application envi-
ronments. We have developed translators into a number of representations including
CORBA’s IDL (Mowbray and Zahavi 1995), Prolog, CLIPS, LOOM (MacGregor
1990), Epikit (Genesereth 1990), KIF.
•Facilities for programmatic access to ontologies so that remote applications have re-
liable access to up-to-date term definitions. We have defined a network protocol and
application program interface (API) to enable remote applications to use an Ontolin-
gua Server to learn about the vocabulary in an ontology and, for example, ask about
the relations between terms.
•Support for distributed, collaborative development of consensus ontologies. We have
developed a network accessible development environment (e.g., using Mosaic or
NetScape) with a rich set of features to support concurrent ontology development
such as fine-grained locking mechanisms and analysis of alternative definitions from
multiple authors.
Ontology development and use technology will succeed when it becomes commonplace
for people in a broad spectrum of communities to build and use ontologies routinely (e.g.,
- 3 -
as spread sheets are and e-mail is becoming). Another indicator of success will be the
availability and widespread use of large-scale repositories of reusable ontologies in di-
verse disciplines (e.g., software development, database design and maintenance, network-
based information retrieval, electronic commerce). These indicators of success should
emerge when the technology has progressed sufficiently so that the benefits provided by
using ontologies significantly outweigh the costs of developing them.
In Section 2 of this paper we discuss new features of the Ontolingua language that sup-
port assembly and reuse of existing ontologies from a repository. Section 3 addresses the
design of our ontology editing tools. Section 4 presents empirical evidence regarding the
usability of the Ontolingua Server and our experience supporting hundreds of users.
1.2 The Ontolingua Server Architecture
Readers
Authors
Remote collaborators
N
G
F
P
G
U
I
App.
Data-
base
Remote Applications
[e.g. T-Helper]
Translators:
Loom, IDL, CLIPS, ...
Library Server
Editor
H
T
T
P
N
G
F
P
Ontology Editor/Server
KB
App.
K
Q
M
L
I
n
t
f
Stand-alone Applications
[e.g. C.Net. Facilities]
Batch file
transfer
Figure 1: Architecture of the Ontolingua Server.
We have developed and deployed an ontology server that satisfies many of the require-
ments described in the previous section. To motivate the design and architecture of the
system, consider the problem of constructing and using an ontology for therapeutic drugs
(Gennari et al. 1995). Like many ontology projects, this is a substantial and challenging
problem. No single expert has the expertise necessary to construct such an ontology.
Thus, it is essential for experts to collaborate on construction. Furthermore, it is essential
for prospective users of such an ontology to examine, evaluate, and critique it. These
prospective users will be geographically distributed across a variety of organizations
(e.g., hospitals, insurers, government agencies). Once this ontology has been built, it can
be used in a number of ways. First, practitioners who want to be sure of a term’s mean-
ing can use it as a reference. Second, networked programmatic agents such as medical
expert systems can query an Ontolingua Server at run-time. For instance, the T-Helper
system (Gennari et al. 1995) can query an Ontolingua Server to determine the character-
- 4 -
istics of therapeutic drugs (e.g., is zidovine an anti-retroviral drug?). Third, standalone
programs can use ontologies as a skeleton for their own representations. In addition to
knowledge-based systems, it would be valuable to provide a starting point for construct-
ing database schema, and object-oriented programs.
The design and architecture of the Ontolingua Server supports these modes of use.
Figure 1 shows a schematic view of the system. The leftmost box depicts the general-
purpose Ontolingua editor and server. The server provides access to a library of ontolo-
gies, allows new ontologies to be created, and existing ontologies to be modified. There
are three primary modes of interaction with the Ontolingua Server indicated by the three
boxes on the right side of Figure 1.
First, remote distributed groups can use their web browsers to browse, build, and main-
tain ontologies stored at the server. The server interacts with them through the now wide-
spread hypertext transfer protocol (HTTP) and hypertext language (HTML) used on the
world wide web. This makes the server accessible by a very wide audience. Any user
familiar with common web browsing tools such as NetScape Navigator™ or NCSA’s
Mosaic can browse, build, and maintain ontologies stored at the server. The server allows
multiple users to work simultaneously on an ontology in a shared session. The editor
provides a number of features to support collaborative work (e.g., notifications, compari-
son, shared change logs). The design of the web-based interface and the underlying infra-
structure is detailed in (Rice et al. 1996).
Second, remote applications may query and modify ontologies stored at the server over
the Internet. These programmatic interactions use a network API that extends the Ge-
neric Frame Protocol (Karp, Myers, and Gruber 1995) with a network interface. The
network interface supports queries (e.g., is zidovudine an antiretroviral-drug) as well as
updates (e.g., create a subclass of vector-quantity called 3d-vector-quantity).
Third, a user can translate an ontology into a format used by a specific application
(Gruber 1993). The resulting translation can be used in a number of ways. For example,
a CLIPS translation produces a set of class definitions and inference rules that can run
directly in a CLIPS-based application. An Interface Definition Language (IDL) transla-
tion produces an IDL header file that a CORBA compliant program can use to interact
with an Object Request Broker (ORB). A KIF translation produces a file of logical sen-
tences that can be used by a logic-based facilitator, such as the one fielded by Commer-
ceNet to draw inferences in response to client queries and to route these queries correctly
(Keller 1996).
2. THE ONTOLINGUA LANGUAGE
The original Ontolingua language, as described in (Gruber 1993), was designed to sup-
port the design and specification of ontologies with a clear logical semantics. To accom-
plish this, Gruber started from KIF. KIF is a monotonic first order logic with a simple
syntax and some minor extensions to support reasoning about relations. Gruber extended
KIF with additional syntax to capture intuitive bundling of axioms into definitional forms
with ontological significance; and a Frame Ontology to define object-oriented and frame-
language terms. The Ontolingua Server has extended the original language in two ways.
First, it provides explicit support for building ontological modules that can be assembled,
extended, and refined in a new ontology. Second, it makes an explicit separation be-
tween an ontology’s presentation and representation.
The original Ontolingua language provided limited support for defining ontological mod-
ules in the form of a tree of named ontologies. As we shall see in Section 2.1, our users
found this simple model to be inadequate in several ways. Furthermore, the module sys-
tem did not have a clearly articulated semantics; this was in sharp conflict with the basic
goals of the language. We have subsequently introduced a new inclusion model which
- 5 -
makes a clear separation between the set of axioms in an ontology and the input-output
behavior of an implementation that must translate sequences of characters into axioms.
The separation of presentation and representation has always been implicit in Ontolin-
gua’s translation approach to sharing ontologies. In the current system, however, the ex-
plicit recognition of this distinction has become a key notion. The representation, the un-
derlying meaning, of an ontology is always defined by a set of KIF axioms. In Ontolin-
gua, the representation is always simple, clear, and unambiguous. The presentation is the
manner in which these KIF axioms are viewed and manipulated by a user. Designing a
good presentation involves user expectations and assumptions. It may even be complex,
murky, redundant, and ambiguous — if that is what the user wants or what the semantics
of a translation target demands.
As we shall see in Section 3, the presentation in the Ontolingua Server’s browsing and
editing environment, in particular, is tailored for object-oriented or frame-language de-
scriptions of the world. We hope that users find the presentation clear, but we guarantee
that each statement corresponds unambiguously to a KIF axiom. The vocabulary used in
this presentation is defined in the Frame Ontology. The Frame Ontology defines terms
including class, subclass-of, slot, slot-value-type, slot-cardinality, facet, and so on. If an
ontology is defined using this vocabulary, the Ontolingua Server can present it in a form
that many users find quite palatable.
A key property of the extended Ontolingua Language and its presentation in the Ontolin-
gua Server is that axioms that do not fit into the frame language are allowed. There is no
restriction on expressiveness. This is extremely important for an ontology development
environment. In contrast with an inference tool or a traditional knowledge representation
tool for which tractability is paramount, an ontology development tool must support ex-
pression. For example, if a user wishes to state the disjunction that a pass grade is
equivalent to an A, B, or C, an ontology development environment must allow her to
state it.
The Ontolingua Server, however, must operate on ontologies and, for instance, translate
them into less expressive languages. For this reason, the editing environment encourages
users to stay within the relatively simple frame sublanguage. Commands for creating
subclasses, adding slots, constraining slot values, and so on, are easy to find and use. The
frame-language axioms are presented simply and concisely. It is possible, however, for
users to write arbitrary KIF axioms. Even if, in the extreme case, an axiom is untranslat-
able, it will still serve as an important formal specification of the authors intention. In-
deed, because KIF, and consequently Ontolingua, is monotonic, performing weaker
translations will still retain their correctness.
To summarize, the underlying representation for an ontology is a set of KIF axioms.
These sentences are projected through a variety of lenses to produce the editor’s frame
pages, HTML documents, LOOM knowledge bases, Prolog clauses, and objects that can
be manipulated using the (N)GFP. A rich infrastructure, not described in this paper, al-
lows a new projection to be assembled from components.
2.1 Assembling an Ontology
We want ontologies to be practical and useful artifacts. This means that the effort re-
quired to construct new ontologies must be minimized and the overall effort required to
construct an ontology must be amortized over multiple uses and users. We enable ontol-
ogy writers to reuse existing ontologies in a flexible and powerful way. In this section,
we show how the Ontolingua Server allows users to reuse existing ontologies from a
modular structured library by inclusion, polymorphic refinement, and restriction.
- 6 -
Formally, ontologies in our system are specifications of axiomatic logical theories. An
ontology specification consists of a vocabulary of non-logical symbols and a set of KIF
axioms that constrain the acceptable referents of those symbols. An Ontolingua user
specifies these axioms in the form of definitions of classes, relations, functions, and con-
stants. Non-logical symbols are the names of relations, functions, and constants. In this
section, we describe our approach to providing ontology reuse in terms of operations on
sets of axioms and the non-logical symbols that occur in them.
Figure 2 shows several motivating examples that are drawn from our ontology building
experience. Example 1 shows the simplest relation between ontologies: inclusion. The
author of a National Semiconductor product ontology needs to represent basic informa-
tion about products, prices, services, and so on. She wants to include the entire contents
of the generic product ontology from the ontology library without modification.1 In Ex-
ample 2, we see that specialized ontologies may make simplifying assumptions that re-
strict the included axioms. For example, in the integer-arithmetic ontology, all numbers
are restricted to be integers. In Example 3, the author wishes to extend the addition op-
erator + in two distinct ways. The library contains axioms about the addition operator in
the KIF-numbers ontology (e.g., it is associative, commutative, has 0 as an identity ele-
ment, etc.). She wishes to extend the addition operator to apply to vectors in one ontol-
ogy and to apply to strings in another ontology — we refer to this operation as polymor-
1Notice that by “inclusion” here, we do not mean “cut and paste the contents of the product ontology into the National
Semicondustor ontology file”. This interpretation would result in unfortunate version dependencies.
Generic Products
Product
Service-Agreement
National Semiconductor
Operational-Amplifier
Subclass-of: Product
Example 1: Inclus ion
Example 2: Restriction
N umbers
+ is commutative and
associative
Integer Arithmetic
All numbers are integers
Medicine
Rollerblading is a likely
cause of wrist fractures
Example 4: Circularity
Medicine
Rollerblading is a likely
cause of wrist fractures
Numbers
+ is commutative and
associative
Example 3: Polymo rphic
Refinement
Vecto rs
+ on vectors is
vector addition
Strings
+ on strings is
concatenation
Extended Arithmetic
+ is commutative and
associative, is vector
addition on vectors, and
concatenation on strings.
Figure 2: There are many relationships between ontologies.
- 7 -
phic refinement. In Example 4, we see that the inclusion relations between ontologies
may be circular. We consider two ontologies: one for medicine and another for sports.
The medical ontology will need to refer to a variety of terms from the sports ontology
(e.g., roller-blading is a leading cause of wrist fractures in teens) and the sports ontology
must also refer to medical terms (e.g., weight-lifters may use anabolic steroids to increase
muscle growth). We must handle this sort of relationship carefully because the ontology
designers do not want either ontology to be polluted by the non-logical symbols from the
other.
Many knowledge representation systems have addressed these issues in one way or an-
other. Before turning to our solution, we will discuss some of the approaches that others
have used, illustrate some of their shortcomings, and use them to motivate our novel de-
sign choices.
The easiest and simplest approach is to provide no explicit support for modularizing rep-
resented knowledge — let the author beware. For instance, the THEO system (Mitchell
et al. 1989) uses a single knowledge base and a single set of axioms. In some sense, this
enables Examples 1, 3, and 4 to be represented, but it has two key drawbacks: First, it is
impossible to restrict definitions (Example 2). Second, by eliminating modularity, it
makes understanding and evaluating ontologies a nightmare. Authors using systems like
this often resort to lexical conventions to discriminate between symbols (e.g., +@kif-
numbers, +@vectors, +@strings). Without automated support, such conventions are difficult
to enforce. Furthermore, enforcing them may not even be desirable. In Example 3, the
axioms in the vectors ontology are about the same + operator as the axioms in kif-
numbers.
A fairly common extension is to allow a directed acyclic graph (DAG) of inclusion rela-
tions between “theories” such as provided by Genesereth’s Epikit. That mechanism sup-
ports modularity, restrictions, and incompatible augmentations. It has two drawbacks:
First, no cycles are allowed among theories. As we have seen, it is both natural and de-
sirable to have cyclic relationships between terms in ontologies.2 Second, in its simple
form, this mechanism results in unnecessary name conflicts. For instance, an ontology
for scientific course work might include ontologies for chemistry and academics, both of
which define tests, but in different ways. There must be a way of discriminating be-
tween tests in chemistry and tests in academics.
The LOOM system provides a DAG of inclusion relationships, but extends the simple
approach by allowing references to non-logical symbols in ontologies that have not been
included. Referencing a symbol in an unincluded ontology, however, does not include
all of the axioms from that ontology, but only minimal type information. This conflates
the declarative semantics, as defined by the axioms, with pragmatic information about
which axioms to apply during problem solving.
There are two distinct aspects to our solution: (1) the inclusion model which defines how
axioms and non-logical symbols are included in new ontologies, and (2) the input and
output model which defines the relationship between character strings input by (or output
to) the user and non-logical symbols in the ontologies.
2Indeed, we initially wanted to avoid the additional complexity introduced by allowing circular references, but our
users demanded it. For any particular example in which circular references occur, it is always possible to create a
new ontology, (e.g., sports-medicine) that contains the subset of the ontologies in the cycle. This is not a practical
solution, however, because it may require the entire structure of the ontology library to be changed to add a single
axiom. This would make it impossible to have a general-purpose library of ontological fragments that can be re-
used.
- 8 -
2.2 A Semantic Model for Ontology Inclusion
In order to facilitate the reuse of existing ontologies, the Ontolingua Server provides a
facility for including one ontology in another as follows. Each ontology is considered to
be specified by a vocabulary of non-logical symbols and a set of axioms. Formally, in-
cluding an ontology A in an ontology B requires specifying a translation of the vocabulary
of A into the vocabulary of B, applying that translation to the axioms of A, and adding the
translated axioms to the axioms in the specification of B. We say that the axioms in the
resulting set are "the axioms of ontology B" so that if B is later included in some other
ontology C, the ontology C will include translated versions of both the axioms in the
specification of B and the axioms of A . Thus, when we say “the axioms of ontology O”,
we mean the union of the “axioms in the specification of O” and the axioms of any ontol-
ogy included by O. This notion of inclusion defines a directed graph of inclusion relation-
ships that can contain cycles. We allow ontology inclusion to be transitive and say that
ontology A is included in ontology B if there is a path in the ontology inclusion graph
from A to B .
The Ontolingua Server eliminates symbol conflicts among ontologies in its internal rep-
resentation by making the symbol vocabulary of every ontology disjoint from the symbol
vocabulary of all other ontologies. That is, in the internal representation, the symbol S in
the vocabulary of ontology A is a different symbol from the symbol S in ontology B.
Given that symbol vocabularies are disjoint, the Ontolingua Server can assume in its in-
ternal representation that the translation used in all inclusion relationships is the identity
translation. Therefore, in the internal representation, including an ontology A in an on-
tology B simply means adding the axioms of A to the axioms of B .
Note that in this model of ontology inclusion, cyclic inclusion graphs are not a problem
since the only effect of ontology inclusion is to union sets of axioms.
If an ontology A contains an axiom that references a symbol in the vocabulary of an on-
tology B, then B is considered to be included in A. the Ontolingua Server allows users to
state explicit inclusion relationships between ontologies and implicitly creates inclusion
relationships based on symbol references in axioms.
2.3 A Syntactic Model for Input and Output
“... no more complex than the Common Lisp package system”
— James Rice
The semantic model introduced above provides a powerful, simple, and unambiguous
way for ontologies to be assembled and reused. However, in order to eliminate ambigu-
ity, it requires symbols to be given clumsy extended unique names that may be unknown
to the user. Moreover, it does not allow a user to perform important operations such as
renaming symbols from included ontologies or selectively controlling which symbols are
to be imported from included ontologies or exported to other ontologies. The Ontolingua
Server solves these problems with additional capabilities that are a part of its facilities for
converting symbol references in input/output text to and from the internal symbol repre-
sentation.
Ontolingua requires that any non-logical symbol referred to in an input or output stream
be defined in some ontology and be assigned a name. The ontology in which a symbol is
defined is called that symbol's home ontology. Similarly, each ontology has a name that
uniquely distinguishes it from any other ontology.
The Ontolingua Server interprets a symbol reference in an input stream or produces a
symbol reference in an output stream from the perspective of a given ontology. For ex-
- 9 -
ample, if the symbol S is defined in ontology A and also defined in ontology B, then from
the perspective of ontology A, the input text "S" is interpreted as “the symbol named S
defined in ontology A”, whereas from the perspective of ontology B, the input text "S" is
interpreted as "the symbol named S defined in ontology B".
The perspective from which any given symbol reference is to be interpreted can be ex-
plicitly specified by attaching a suffix to the symbol name consisting of the character "@"
following by the name of an ontology. So, for example, the symbol named S interpreted
from the perspective of ontology A can be explicitly referred to as "S@A". A symbol ref-
erence that includes the @«ontology name» suffix is said to be a fully qualified reference.
Fully qualified references enable symbols defined in any ontology to be referenced in any
other ontology.
The Ontolingua Server input/output system provides a symbol renaming facility that al-
lows a user to assign a name to a symbol which is local to the perspective of a given on-
tology. A renaming is specified by a rule that includes an ontology name, a symbol ref-
erence, and a name that is to be used as the local name of the given symbol from the per-
spective of the given ontology. Given such a renaming rule, the system will recognize
the local name as a reference to the given symbol when processing input in the given per-
spective, and will use the local name to refer to the given symbol when producing output
from the given perspective. So, for example, a renaming rule might specify that in ontol-
ogy A, the local name for auto@vehicles is to be car. This facility enables an ontology de-
veloper to refer to symbols from other ontologies using names that are appropriate to a
given ontology and to specify how naming conflicts among symbols from multiple on-
tologies are to be resolved.
For convenience of input and parsimony of output, the @«ontology name» suffix can be
omitted from symbol references when the symbol name itself is unambiguous from the
intended perspective. In particular, a given symbol can be referred to from the perspec-
tive of an ontology A simply as S if and only if the given symbol:
• Is defined in ontology A with name S;
• Has been renamed to S in ontology A; or
•Has been imported into ontology A.
A name that can be used to refer to a defined symbol from the perspective of a given on-
tology is said to be recognized in that ontology. Thus, the convention given above for
omitting the @«ontology name» suffix from symbol references implies that a name S is
recognized in an ontology A if and only if S is the name of a symbol defined in A, or S is
the name of a symbol that has been imported into A and has not been renamed in A, or
S is the local name for a symbol in A.
We now describe the mechanisms for importing symbols into an ontology.
Each defined symbol is designated as being public or as being private to the ontology in
which it is defined. The system considers symbols to be public by default so that users
can ignore the public/private distinction until they encounter or want to define private
symbols.3
The Ontolingua Server associates with each ontology a set of ontologies whose public
symbols are imported into the ontology. User commands are available for editing that set
of ontologies. However, in order to simplify the use of this symbol importing mecha-
3Users can change the default on a per-ontology basis.
- 10 -
nism, by default the Ontolingua Server automatically adds to this set any ontology that is
explicitly included. Thus, users can ignore the distinction between symbol importing and
explicit inclusion until they want to override that default.
In order to provide control over the importing of individual symbols, the Ontolingua
Server associates with each ontology a set of shadowed symbols that are blocked from
being imported into the ontology. That set of shadowed symbols overrides symbols in
the set of imported ontologies in that a symbol is imported into an ontology A only if the
symbol is a public symbol defined in an ontology that A imports and is not shadowed in
A, or the symbol is a public symbol in an ontology that does not import, but is imported
by means of an identity renaming (e.g., S@A goes to S@B)
The Ontolingua Server uses the shadowing mechanism to prevent ambiguities from oc-
curring in the text form of symbol references by automatically blocking the importation
into an ontology of any symbols which would have the same text form in that ontology's
perspective. Thus, if there is a symbol that can be referred to by S from the perspective
of ontology A, a different symbol that can be referred to by S from the perspective of on-
tology B, and the public symbols from both ontologies A and B are imported into ontol-
ogy C, then the Ontolingua Server automatically adds S@A and S@B to C's list of shad-
owed symbols in order to prevent "S" from being an ambiguous symbol reference from
the perspective of ontology C. This automatic shadowing occurs irrespective of the order
in which the definitions and inclusion relationships are specified. So, for example, if the
inclusion relationship between ontologies A and C already exists when a symbol that can
be referred to by S@A is defined, then S will be added to the set of symbols shadowed in
ontology C at the time S@A is defined.
2.4 Summary
To summarize, we note how Ontolingua supports ontology inclusion, circular dependen-
cies, and polymorphic refinement by reconsidering the examples from Figure 2.
Using Ontolingua, the ontology inclusion relationship in Example 1 would be explicitly
established by the developer of the National Semiconductor Products ontology either as
part of the definition of that ontology or as an editing operation after the ontology has
been defined. Given that inclusion relationship, public symbols from the Generic Prod-
ucts ontology, such as Service-Agreement, whose names do not conflict with other recog-
nized names in the perspective of the National Semiconductor ontology would, by de-
fault, be imported into the National Semiconductor Products ontology and therefore could
be referred to from the perspective of that ontology by their names (e.g., Service-
Agreement) without the @GenericProducts suffix.
The circular dependencies in the Medicine and Sports ontologies of Example 2 would be
established and presented by using fully qualified names to refer to symbols from the per-
spective of the other ontology. For example, in the Medicine ontology, roller-blading
would be referred to as roller-blading@sports, and in the Sports ontology, steroid tests
would be referred to as steroid-tests@medicine. The reference to roller-blading in the
Medicine ontology will cause the axioms of the home ontology of the symbol roller-
blading@sports to be implicitly included in the Medicine ontology, but would not cause the
public symbols from the Sports ontology to be imported into the Medicine ontology.
The polymorphic refinement of + in Example 3 is a case in which some of the subtle
properties of implicit ontology inclusion become apparent. If ontology X does not ex-
plicitly include the vectors, strings, or numbers ontologies, then references to
+@vectors and +@strings in X will cause numbers to be implicitly included in X, but
will not cause Vectors or Strings to be included since both +@vectors and +@strings refer
- 11 -
to a symbol whose home ontology is Numbers. If the vector addition axioms of ontology
Vectors and/or the string addition axioms of ontology Strings are to be included in ontol-
ogy X, then the user must state the inclusion relationship explicitly.
3. THE ONTOLINGUA DEVELOPMENT ENVIRONMENT
Our goal was to create a general environment to facilitate the development and sharing of
ontologies. Such an environment must assist the user in the basic development tasks of
browsing, creating, maintaining, sharing, and using ontologies. We also realized that
many of our users desire to develop ontologies through a consensus process; therefore,
we also needed to provide tools to help people collaborate during the development of
their ontologies. In this section, we will discuss the features implemented in our web-
based ontology environment which provide assistance with basic development tasks, fa-
cilitate collaboration, and improve ease-of-use.
3.1 Browsing Ontologies
An essential component of our browsing environment is being able to quickly jump from
one term in the ontology to another using hyperlinks. Selecting the name of a term takes
the user to a page displaying the definition of that term. The definition consists of both
informal documentation and formal statements about that term. Rather than displaying
this information in a purely logic-based form, we display this information in an object-
oriented or frame-based form (see Figure 3). In a frame, slots are displayed along the left
side of the screen and values corresponding to the slots are displayed following the name
Axioms that do not
fit in the frame
sublanguage are
listed in KIF at the
end.
Properties of the
class itself.
Properties that
apply to instances
of the class.
Every term is
hyperlinked
to its
definition.
This includes
basic terms
such as
superclass-
of.
“Go” buttons
link inferred
information to
the definition
that it came
from.
Figure 3: A screen image from the Ontolingua Server’s browsing environment
showing the class definition Automobile in the vehicles ontology.
- 12 -
of the slot. Information that can’t be displayed as slot or facet values appears later in the
page as axioms.
When users examine an entire ontology, they often want to see information about a term
that is inferable from the definition of other terms. To support this feature, the Ontolin-
gua Server performs the limited set of inferences are typically provided by frame-based
representation systems. These include inheritance from classes to subclasses and in-
stances, inverses, limited transitivity, and so on. Information that was directly asserted is
visually distinguished from inferred information. The direct assertions appear in a roman
font and inferred information appears in italics. The user can see where the inferred in-
formation was directly asserted by pressing a button labeled “GO” attached to each piece
of inferred information.
The Ontolingua Server provides class/subclass browsers that display an entire hierarchy
in a compact fashion to give the user a quick overview of an ontology. Rather than using
a node and arc graphic display, the hierarchy is displayed in an indented text form with
widgets that allow subtrees to be closed or opened (see Figure 4). The class browser in-
teracts with the ontology inclusion graph. The user can select the set of ontologies whose
contents should be included in the hierarchy. The user can also focus the display on a
single class to reduce clutter in large ontologies. For moderate sized ontologies (150-
1000 definitions), we find the indented text format preferable to a graphic display. Fur-
thermore, the textual display substantially reduces the number of bytes required to de-
scribe the hierarchy. This results in improved performance for our networked tools.
Figure 4: The class/slot and class/instance browsers provide a compact overview
of set of ontologies. Only objects in the selected ontologies are displayed.
- 13 -
3.2 Building Ontologies
We designed the ontology editing environment to have a similar appearance to the ontol-
ogy browsing environment so that the user would not need to learn two different inter-
faces. The difference between the editing environment and the browsing environment is
that two new types of icons appear in the editing environment: edit pens and insertion
icons. Edit pens appear in front of information that can be modified by the user. When
the user wishes to change that information, she selects the appropriate edit pen, and a
form for modifying the current information appears. Insertion icons appear wherever a
user is allowed to add information such as a new value or facet for a slot. When the user
selects one of the insertion icons, a form for entering new information appears. The
contents of these forms depends on the type of thing which is being added or edited.
Commands which don’t fit into this paradigm appear as menu options at the top of the
screen. For example, commands for creating new terms appear on these menus. The user
can select which type of term to create, and an appropriate form will prompt the user for
information about the new term.
Possible slots
matching
partial input
can be easily
inserted.
Facets can be
selected from
a menu or
typed in.
The user types
in a new facet
value. HTML
could be
included in
any string.
Figure 5: Users edit definitions by selecting one of the edit gadgets (pens, or ad-
dition icons). An input field is snipped into the page at the appropriate location.
The appearance of the editing and browsing modes are as similar as possible.
- 14 -
3.2.1 Maintaining Ontologies
The Ontolingua Server provides several features to assist with ontology maintenance.
Users can compare two ontologies and see the set of actions that would transform one
into the other. This is an easy way to monitor changes in ontology or undo modifications.
Users can analyze an ontology for inconsistencies and undefined terms. All slots, slot
values, facets, and facet values are checked to make sure that they conform to known
constraints (e.g., domain, range, slot value type, and cardinality constraints). During the
course of development, users often want to split an ontology into a set of more easily un-
derstood, more tightly focused modules. The server provides direct support for splitting a
large ontology into several smaller ontologies that may include each other.
Informal documentation is an important part of making ontologies maintainable. The
Ontolingua Server supports special keywords within the informal documentation known
as notes. A user can assign a keyword such as example, verified-by, see-also, modifica-
tion-by, and formerly-named to provide more structure to the informal documentation.
3.2.2 Sharing Ontologies
The Ontolingua Server provides a number of features to promote the sharing of ontolo-
gies. The primary mechanism for supporting ontology reuse is through the library of
ontologies which acts as a central repository for reusable ontologies. When someone has
an ontology that they believe is ready for others to use, they can choose to publish their
ontology in the Ontolingua Server. After the ontology has been approved, it becomes
available to anyone with access to the Ontolingua Server through the library.
The Ontolingua Server also provides several tools for searching for terms within ontolo-
gies in the library. A user may choose the general search facility which allows them to
use wild-cards in searching the entire library for terms whose name matches the specified
pattern. Context-sensitive searching is also available whenever the user needs to fill in
the name of a term such as when adding a value to a slot. In context-sensitive searching,
constraints on which terms are appropriate are used to limit the search.
3.2.3 Collaboratively Developing Ontologies
One of the features which clearly distinguishes the Ontolingua Server from other ontol-
ogy development environments is its support for distributed collaborative ontology con-
struction. Distributed access is provided by the web interface. Collaborative work is fa-
cilitated by (1) user and group access control, and (2) multi-user sessions.
The Ontolingua Server uses a notion of users and groups that is typical in most multi-user
file systems. As with file systems, read and write access to ontologies is controlled by
the ontology owner giving access to specific groups. This mechanism supports both ac-
cess protection as well as collaboration across groups of people who are defined within
the ontology development environment.
The server provides support for simultaneous work through group sessions. When a user
opens a session, she may assign a group ownership to it. This enables any other members
of that group to join the session and work simultaneously on the same set of ontologies.
A notification mechanism informs each user of the changes that other users have made.
Notifications are hyperlinked to the changed definitions and describe changes in terms of
basic operations such as add, delete, and modify (e.g., “Farquhar added the slot motor-of
to the class vehicle”). The synchronous nature of the web protocols makes this sort of
notification somewhat clumsy — the Server cannot notify users that a change has oc-
curred until they visit a new page. Recent advances in client-side tools, however, are re-
laxing these restrictions.
- 15 -
3.2.4 Ease of Use
In designing the interface to the Ontolingua Server, we wanted to make a tool which
would be simple for a novice to understand and use yet be powerful enough to support
experienced users. To accommodate such differing levels of users, we added a large va-
riety of user preferences for controlling the behavior of the user interface.
To make the interface simple, the Ontolingua Server provides four basic types of pages:
the table of contents for the ontology library, ontology summary pages, frame pages (for
classes, relations or instances), and the class browser. The Ontolingua Server provides a
wide variety of other features to make the environment easy to use. The hyperlinked en-
vironment has made it easy to provide tutorials, on-line documentation, and context-
sensitive help that can be selected at any time. In addition, the Server allows the user to
undo or redo any number of modifications they made to the ontology since they last
saved it.
3.3 Using Ontologies
Although the Ontolingua Server currently does not provide much inferential power, it
does provide some support for using ontologies. One way to use ontologies developed
with the Ontolingua Server is to translate the ontology into the representation language of
another system such as CLIPS, LOOM, or Prolog. Currently, the Ontolingua Server can
translate into ten different representations. Users can then transfer the translation via e-
mail. Users may also e-mail their ontologies as standalone hyperwebs, source code, or
formatted text.
4. RESULTS
In this section we discuss some of our experience in using and providing the Ontolingua
Server over the web. Our general approach of providing access to research software over
the web appears to be highly successful. It has increased the numbers of users and si-
multaneously reduced our development costs by more than an order of magnitude. We
have been able to reach a wide audience in a cost effective manner and provide them with
a high quality, robust, and useful tool with far higher functionality than would have been
possible had we been distributing our software in a conventional fashion.
Research organizations such as KSL have limited resources to devote to maintaining,
documenting, and distributing software. In general, we would rather invest our energies
in adding new functionality than in porting to yet one more platform or idiosyncratic
hardware and software configuration. Furthermore, the users of research software would
rather invest their time and energy evaluating and using it than in downloading, config-
uring, and compiling. We also save them from buying the necessary software licenses
and hardware platform needed to support our software.
There have been numerous other benefits: users who are already familiar with their web
browsers can use the Ontolingua Server right away. The constrained interface afforded
through HTML has actually had positive effects on our interface design — it is much
cleaner and more streamlined than it might otherwise have been. Useful context-
sensitive hypertext documentation is accessible by any user through the same web inter-
face. Our custom HTTP server was easily extended to handle other network protocols
such as the Network GFP. The modular state and session organization was easily ex-
tended to support several other network services, that are not described here (but are also
available through http://www-ksl.stanford.edu).
Evaluating the impact that the Ontolingua Server has had on specific projects is rather
difficult. We have not yet engaged in any formal study and the logging information that
we have kept has been limited. This is partly by design and partly due to the nature of the
- 16 -
system. We want users to feel confident about the privacy of their data and interactions
with the server. This is especially important for industrial users. It is also not yet clear
what sorts of information would be useful to log. Most web servers maintain a complete
log of all URLs that are requested from them. This allows them to determine usage pat-
terns such as how often specific documents are examined. In the Ontolingua Server,
however, things are not so simple. The URLs that go in and out of the Ontolingua Server
encode each request with an identifier that is unique to the command, user, and session.
A record of these identifiers would be useless (like recording hash keys for hash tables
that have subsequently been cleared). Furthermore, the pages that users access do not
come from any fixed set of files on a server. Users create, modify, and delete new ob-
jects while they work. In this effectively infinite space of objects, there is relatively little
overlap between users. Thus, recording the objects that were visited might be of little
interest. Although it might be interesting to record command executions, the Ontolingua
Server supports over 500 distinct commands, and the current command architecture
makes it difficult to draw any coherent picture of user activity from this sort of log. An
important next step is to determine meaningful instrumentation that will help us evaluate
the impact that the editor has on collaborative activities.
Nonetheless, we do have a base level of instrumentation that allows us to draw some in-
ferences about the overall patterns of usage and activity.
The Ontolingua Server has been extremely reliable. Since its public announcement at the
start of February 1995, the server has been available 99.89% of the time. Including
scheduled downtime for hardware and software upgrades, the total downtime has been
typically less than one hour per month. A typical period of uninterrupted service is two
weeks, and multi-day sessions are common for our active users. This high level of reli-
ability is essential if we expect remote users to make use of our tools and services.
The Ontolingua Server has reached a wide audience with an acceptable level of continued
use. Although we believe that ontologies are becoming increasingly useful and important
for a number of purposes, the Ontolingua Server is still a research vehicle that is relevant
to a very narrow range of people. Thus, we should not expect usage levels to approach
that of very general purpose web sites such as Lycos. Furthermore, announcements of
the Ontolingua Server have only been made to fairly focused mailing lists of researchers
interested in Ontolingua, Shareable Reusable Knowledge Bases, and Qualitative Rea-
soning. Nonetheless, as Figure 6 indicates, the number of registered users has grown
steadily and currently exceeds 1000.
0
50
100
150
200
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May
New Users
Figure 6: The number of new users registering each month from January 1995
through May 1996 indicates strong and continuing interest.
Clearly, the number of users does not tell the full story. Figure 7 shows the distribution
of users according to the total number of requests they have made. As we would expect,
the largest group of users are the ones that have simply surfed by, executed a small num-
- 17 -
ber of requests, and moved on. Examining 50 pages or so requires some investment of
time and energy. These users are clearly evaluating the system and exploring some of its
capabilities. This level of activity would also be consistent with colleagues or superiors
looking at an ontology author’s work. Executing 51-500 requests is sufficient to con-
struct sample ontologies and do student level representation exercises. These users are
developing a strong sense for the system and its capabilities. Finally, there are the users
who have issued thousands of requests. These are our serious users, many of whom are
doing substantial ontology development. The shape of this graph has remained fairly sta-
ble over time.
452
203
230
136
103
31
24
46
12
8
8
1
10
100
1000
1 — 10 11—20 21—50 51—100 101—250 251—500 501-1000 1001-5000 5001-10000 10001-
15000
15001-
100000
Number of Requests per User in Group
Number of Users
Figure 7: Users are grouped by the number of requests they make.
Figure 8 shows the distribution of requests by top-level Internet domain. This graph un-
derestimates the amount of European use, because it does not include figures from the
mirror site that was established in Madrid in November, 1995. At that point, many of the
European users switched to the mirror site to benefit from improved bandwidth. Ap-
proximately 20 percent of the 734,000 requests logged came from KSL users. While the
overwhelming majority of requests have been issued by U.S. educational users, there
have been a substantial number issued by U.S. commercial users (COM) and active
groups have been established in Europe, Great Britain, and Japan.
AU
BE
BG
BR CA
CAMIS
CH
CL
COM
CZ DE
DK EDU
ES
FI FR
GOV
HK IE
IL
IN IT JP
KR MIL
MK MX
MY NET NL
NO NZ
ORG
PT SE
SG
SI TW UK
UKP
US
VA
YU
ZA UNK
MISC KSL
1
10
100
1,000
10,000
100,000
1,000,000
Figure 8: Number of requests by Internet domain.4
The usage patterns are consistent with our expectations and with those generally found in
the software industry. Only a small percent of the people who try the Ontolingua Server
4The domain marked “Unk” accounts for all requests logged from anonymous connections. We log the requests ac-
cording to the domain of the user’s email address, not the current connection location.
- 18 -
end up using it on a regular basis. The rest try it and move on, although some of these
return later when they need the capabilities of an Ontolingua Server.
Evaluating the work done with the Ontolingua Server and its impact on collaboration is
difficult. It is clear, however, that users are constructing substantial ontologies. The
subject matter of the user contributed ontologies is varied. The more mature ontologies
include metadata for genome database integration, satellite image metadata, enterprise
integration, products and product catalogs, oscilloscopes, semiconductors, robotics, solid
modeling, drugs, medical terminology, the IEEE standard 1175 for tool interconnections,
and many others. Some of the larger ontologies, such as the one for medical terminology,
which contains over two thousand definitions, have been imported from existing projects.
Others, such as the IEEE 1175 ontology, which contains over one hundred and forty defi-
nitions, have been constructed entirely through interactions with the Ontolingua Server.
In addition to ontology construction efforts, the Ontolingua Server is also being used in
projects to provide run-time access to ontologies. The T-Helper medical application is an
outpatient computer-based record system for patients with human immunodeficiency vi-
rus (HIV). In order to determine if patients are eligible to participate in clinical trials, it
uses an ontology of drug types and specific drugs. It queries the Ontolingua Server to
help determine if drug-related eligibility criteria are met (Gennari et al. 1995). The
SHADE project is addressing many information system interoperability issues. The On-
tolingua Server has been used to define several large ontologies for satellite image
metadata (e.g., for the Federal Geospatial Metadata Standard, the Terramar satellite im-
age database). Client-side tools are being developed to view the metadata and define
mapping relations between concepts in them. These client-side tools extract the concept
definitions from the ontologies stored on the Server.
The level of use that the Ontolingua Server has experienced indicates that the system is
filling an important niche and that we are meeting our goal of reaching a wide audience
and providing it with reliable useful tools for building and using ontologies.
5. CONCLUSION
We have described an implemented architecture for distributed collaborative ontology
development and use that exploits the world wide web protocols to provide access to a
growing user community.
We presented an inclusion model for ontologies that enables users to assemble new on-
tologies rapidly from existing ones in a repository. This model makes a clean separation
between its simple formal semantics and the input/output properties of the system that
uses it. The formal model handles simple inclusion, polymorphic refinement, restric-
tions, and circular inclusion dependencies. The input/output model yields succinct read-
able external representations and is transparent to users.
We described our web-based ontology editing environment (Rice et al. 1996) that is inte-
grated with the Ontolingua Server and that incorporates this inclusion model. In addition
to providing individual users with a rich many-featured editing environment, this server
also supports collaboration between distributed groups of users, and provides access to a
growing repository of ontologies. The Ontolingua Server also provides a vital publishing
medium for ontologies because hypertext pointers can reliably point to any document in
the publicly accessible library of ontologies.
Finally, we presented empirical evidence that our approach to disseminating and provid-
ing tools to promulgate the use of ontologies is effective. Our tools and the infrastructure
that supports them have been extremely reliable (with a 99.9% uptime). The infrastruc-
ture scales well and currently supports several hundred users without performance prob-
lems. Users have been able to construct substantial ontologies with the web-based editor
- 19 -
including ontologies with many hundreds of definitions. Several of these construction
efforts have been collaborative with users distributed world-wide. The server architec-
ture also supports programmatic queries from remote software agents that interrogate the
server about the definitions of terms in ontologies and possibly modify them.
Constructing ontologies is a difficult, time-consuming process. The tools that we have
been developing help to amortize this effort across many users and multiply the benefits
across many uses.
The Ontolingua Server is available for public use through
http://ontolingua.stanford.edu/
6. ACKNOWLEDGMENTS
This research was supported by a grant from ARPA and NASA Ames Research Center
(NAG 2-581), NASA Ames Research Center under contract NCC2-5337, and through
CommerceNet under contract CN-1094 (TRP #F33615-94-4413).
We would also like to acknowledge the valuable contributions of Wanda Pratt, Rupert
Brauch, and the users of Ontolingua Server.
7. BIBLIOGRAPHY
Fikes, R., M. Cutkosky, T. Gruber, and J. van Baalen. (1991). Knowledge Sharing Tech-
nology Project Overview. KSL 91-71. Stanford University, Knowledge Systems Labora-
tory.
Genesereth, M. R. (1990). The Epikit Manual. Epistemics, Inc. Palo Alto, CA.
Genesereth, M. R. and R. E. Fikes. (1992). Knowledge Interchange Format, Version 3.0
Reference Manual. Logic-92-1. Computer Science Department, Stanford University.
Gennari, J. H., D. E. Oliver, W. Pratt, J. Rice, and M. A. Musen. (1995). A Web-Based
Architecture for a Medical Vocabulary Server. In
Nineteenth Annual Symposium on
Computer Applications in Medical Care
. New Orleans, LA.
Gruber, T. R. (1992). Ontolingua: A mechanism to Support Portable Ontologies. KSL
91-66. Stanford University, Knowledge Systems Laboratory.
Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specifications.
Knowledge Acquisition
5 (2): 199-220.
Karp, P. D., K. Myers, and T. Gruber. (1995). The Generic Frame Protocol. In
14th I
n-
ternational Joint Conference on Artificial Intelligence
. Montreal, Canada.
Keller, A. M. (1996). Smart Catalogs and Virtual Catalogs. In
Readings in Electronic
Commerce
, ed. Ravi Kalakota and Andrew Whinston: Addison-Wesley.
MacGregor, R. (1990). LOOM Users Manual. ISI/WP-22. USC/Information Sciences
Institute.
Mitchell, T. M., J. Allen, P. Chalasani, J. Cheng, O. Etzioni, M. Ringuette, and J. C.
Schlimmer. (1989). Theo: A Framework for Self-Improving Systems: National Science
Foundation, Digital Equipment Corporation.
Mowbray, T. J. and R. Zahavi. (1995).
The ESSENTIAL CORBA: System Integration
Using Distributed Objects.
: John Wiley and Object Management Group.
Rice, J., A. Farquhar, P. Piernot, and T. Gruber. (1996). Using the Web Instead of a Win-
dow System. In
Conference on Human Factors in Computing Systems (CHI96)
:103-110.
Vancouver, CA: Addison Wesley.
