=Paper=
{{Paper
|id=Vol-18/paper-11
|storemode=property
|title=A Framework for Understanding and Classifying Ontology Applications
|pdfUrl=https://ceur-ws.org/Vol-18/11-uschold.pdf
|volume=Vol-18
}}
==A Framework for Understanding and Classifying Ontology Applications==
https://ceur-ws.org/Vol-18/11-uschold.pdf
A Framework for Understanding and Classifying
Ontology Applications
Mike Uschold Robert Jasper
The Boeing Company The Boeing Company
P.O. Box 3707,m/s 7L-40 P.O. Box 3707,m/s 7L-40
Seattle, WA USA Seattle, WA USA
98124-2207 98124-2207
michael.f.uschold@boeing.com robert.j.jasper@boeing.com
1 Introduction
Abstract Until recently, there had been a dearth of ontology appli-
cations reported by the AI ontology community. This has
In1 this paper, we draw attention to common goals begun to change; in the past year or two, there have been
and supporting technologies of several relatively a flurry of papers reporting attempts and some successes at
distinct communities to facilitate closer cooper- applying ontologies — especially in the area of search and
ation and faster progress. The common thread retrieval of information repositories, for example, [8]. And
is the need for sharing the meaning of terms in yet, outside the AI ontology community, industry has been
a given domain, which is a central role of on- regularly using ontologies successfully (even though they
tologies. The different communities include on- may not call them ontologies).
tology research groups, software developers and There is a common thread that binds these different
standards organizations. Using a broad definition communities: the need to overcome barriers created by dis-
of ‘ontology’, we show that much of the work be- parate vocabularies, approaches, representations, and tools
ing done by those communities may be viewed as in their respective contexts. There is a need to share mean-
practical applications of ontologies. ing of terms in a given domain. Achieving a shared un-
To achieve this, we present a framework for un- derstanding is accomplished by agreeing on an appropriate
derstanding and classifying ontology applications. way to conceptualize the domain, and then to make it ex-
We identify three main categories of ontology ap- plicit in some language. The result, an ontology, can be
plications: 1) neutral authoring, 2) common ac- applied in a wide variety of contexts for various purposes.
cess to information, and 3) indexing for search. In These groups strive to overcome the barriers noted in
each category, we identify specific ontology ap- the previous paragraph; ironically, the same underlying is-
plication scenarios. For each, we indicate their in- sues also create barriers to closer cooperation between on-
tended purpose, the role of the ontology, the sup- tology research groups, software developers and standards
porting technologies and who the principal actors organizations who are addressing similar problems. This
are and what they do. We illuminate the similari- paper aims to lower these barriers by identifying and high-
ties and differences between scenarios. lighting the commonality among these communities, and
pointing out important differences. We do this by provid-
The copyright of this paper belongs to the papers authors. Permission to ing a framework for understanding and classifying ontol-
copy without fee all or part of this material is granted provided that the ogy applications. In creating this framework, we propose
copies are not made or distributed for direct commercial advantage.
a common nomenclature, that we hope will enable work-
Proceedings of the IJCAI-99 workshop on
ers in the different communities to overcome terminolog-
Ontologies and Problem-Solving Methods (KRR5)
ical confusion. We do not try to reconcile the differences
Stockholm, Sweden, August 2, 1999
between the communities; we instead highlight the com-
(V.R. Benjamins, B. Chandrasekaran, A. Gomez-Perez, N. Guarino, M.
Uschold, eds.)
monality between these groups through the use of a single
framework.
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-18/
1 The order of authors was determined by a coin flip. Another important goal of this work is to lay the foun-
M.F. Uschold, R.J. Jasper 11-1
dation for identifying and expressing guidelines for how to Each scenario is illustrated with a simple diagram.
use ontologies to achieve specific benefits. Many of the scenarios have important variations, that we
also call attention to. The scenarios and variations are il-
1.1 Terminology & Acronyms lustrated with examples from the diverse communities.
For the purposes of this paper, we take a ‘lowest common To achieve our goal of enabling scenarios to be easily
denominator’ view of the notion of an ontology. We do not compared, we present each in a uniform way using consis-
aim to define it, instead we adopt the following characteri- tent terminology. Each scenario is characterized by the fol-
zation, quoted from [15] (our emphasis): lowing, which give rise to the key dimensions of our frame-
work:
“An ontology may take a variety of forms, but 1. intended purpose or benefits
necessarily it will include a vocabulary of terms,
and some specification of their meaning. This in- 2. the role of the ontology
cludes definitions and an indication of how con-
3. the actors required to implement the scenario
cepts are inter-related which collectively impose
a structure on the domain and constrain the pos- 4. supporting technologies
sible interpretations of terms.”
5. the maturity level
As noted below, the degree to which meaning is spec- Two additional distinctions that play an important role
ified varies greatly. This broad interpretation helps to in some scenarios, are:
show how both the goals and the technologies developed
to achieve them are similar across the different commu- • how meaning of terms is represented (e.g., informal or
nities. For example, common goals include reuse and in- formal)
teroperability. Common technologies include special pur-
• sharing vs exchange (e.g., pass by reference or pass
pose modeling languages (e.g., Ontolingua [2], EXPRESS
by value)
[11, 10] and IDL) and translation tools. Thus, we can eas-
ily view a number of standardization efforts (e.g., STEP, In the remainder of this section, we describe the key di-
OMG2 ) as practical applications of ontologies. mensions and dinstinctions which form the basis for our
framework. In § 3 we present the ontology application sce-
Application: refers to the application that makes use of or narios.
benefits from the ontology (possibly indirectly).
2.1 Framework Dimensions
OMG: Object Management Group
2.1.1 Purpose and Benefits
CORBA: Common Object Request Broker Architecture
Fundamentally, ontologies are used to improve communi-
STEP: STandard for the Exchange of Product model data; cation between either humans or computers. Broadly, these
an informal name for the ISO-10303 family of stan- may be grouped into the following three areas: to assist
dards in communication between human agents, to achieve inter-
operability, or to improve the process and/or quality of en-
EXPRESS: an object-flavored language for specifying in-
gineering software systems. The following is adapted from
formation models, originally developed as part of the
[15].
STEP standard.
Communication between people. Here, an unambiguous
2 Overview of the Framework but informal ontology may be sufficient.
The main part of the framework consists of a set of ontol- Inter-Operability among computer systems achieved by
ogy application scenarios. By this we mean, a particular translating between different modeling methods,
situation or context in which an ontology is applied in a paradigms, languages and software tools; here, the on-
particular way to achieve one or more specific benefits. We tology is used as an interchange format.
identify three main categories of ontology applications: 1)
neutral authoring, 2) common access to information, and Systems Engineering Benefits: In particular,
3) indexing for search. For each category, we identify one Re-Usability: the ontology is the basis for a formal en-
or more specific application scenarios. For example, in the coding of the important entities, attributes, processes
neutral authoring category, there are two scenarios, one for and their inter-relationships in the domain of interest.
authoring an ontology, and the other for authoring opera- This formal representation may be (or become so by
tional data. automatic translation) a re-usable and/or shared com-
2 See www.omg.org ponent in a software system.
M.F. Uschold, R.J. Jasper 11-2
Search: an ontology may be used as meta-data serving as development process, to write ontologies at level L1 .
an index into a repository of information. The information at L2 is used to author information at
L1 .
Reliability: A formal representation also makes possible
the automation of consistency checking resulting in Importantly, the same information can play different
more reliable software. roles at different times depending on the context. For ex-
ample, a schema in EXPRESS plays the role of an ontol-
Specification: the ontology can assist the process of iden- ogy from the viewpoint of an end-user application. From
tifying requirements and defining a specification for the viewpoint of an application development tool (e.g., an
an IT system (knowledge based, or otherwise). EXPRESS compiler), the same information plays the role
Maintenance: use of ontologies in system development, of operational data.
or as part of an end application, can render mainte- To avoid this kind of potential confusion in this paper,
nance easier in a number of ways. Systems which are we focus on end-user applications where information plays
built using explicit ontologies serve to improve docu- the role of operational data (L0 ). With this assumption, the
mentation of the software which reduces maintenance following are examples of information typical at each level:
costs. Maintenance is also an important benefit if an L0 operational data (e.g., a particular part, a process de-
ontology is used as a neutral authoring language with scription)
multiple target languages - it only has to be maintained
in one place. L1 an ontology (e.g., AP203, PIF)
Knowledge Acquisition: speed and reliability may be in- L2 an ontology representation language (e.g., EXPRESS,
creased by using an existing ontology as the start- Ontolingua)
ing point and basis for guiding knowledge acquisition
To share or exchange information at Ln requires refer-
when building knowledge-based systems.
ence to a model at Ln+1 . For example, sharing Ontolin-
gua ontologies (at L1 ) requires development tools that can
2.1.2 Role of the Ontology
parse the syntax of Ontolingua (at L2 ). Another good ex-
Ontology application scenarios vary in how the ontology ample arises in the context of the STEP family of standards.
itself is used. This is further complicated by the fact that in STEP defines a standard for exchange of schema instances
a given scenario, it is frequently possible to think of more via clear text encoding (ISO-10303-21, 1994) which is at
than one ontology being involved. For example, when On- level L0 . Exchange at this level requires a schema at L1
tolingua is used, (1) the frame ontology is used as a ba- written in EXPRESS [11, 10] which is at level L1 . Similar
sis for expressing (2) the domain ontology. An ontology analogies exist for object sharing and exchange standards
application scenario needs to be clear about which ontol- (e.g., OMG).
ogy is being used and how. To facilitate this, we introduce Information at the same level can represented using
three roles that information can play in one of our scenar- more than one syntax (e.g., an ontology in Ontolingua ver-
ios. These can also be thought of as information levels. sus Loom). It is also possible that you can use the same
syntax to represent information at different levels. For ex-
L0 : Operational Data a role that information plays ample, a class definition at L1 and an instance definition
whereby the information is consumed and produced at L0 may both be expressed in the syntax of Ontolingua.
by applications during runtime. Information at L0 is This is because some primitives of Ontolingua (e.g., define-
written using terms from a vocabulary defined at L1 . instance) can be used as part of an L1 language.
In addition to the syntax, terms may require map-
L1 : Ontology a role that information plays, whereby the
ping within or between levels. For example the term
information specifies terms and definitions for impor-
define-class in Ontolingua may be mapped to the
tant concepts in some domain. An ontology typically
term defconcept in Loom.
is used in the development processes to create appli-
cations.3 Information at L1 provides a vocabulary for
2.1.3 Actors
the language used to author information at L0 .
Each scenario involves a set of actors. Each actor repre-
L2 : Ontology Representation Language a role that infor- sents a role that a person or application may play. A person
mation plays whereby the information is used by on- or application may play more than one role in a scenario.
tology authors or application developers, during the Actors may play either a primary or a secondary role in a
3 Some applications may actually “discover” information at this level scenario. The follow list describes the actors:
during operation of the application. This requires some intelligence on the
part of the application to “learn” the ontology prior to actual interpretation Ontology Author: (OA) the role of the author of an ontol-
of the information at L1 . ogy. This role is usually played by a person.
M.F. Uschold, R.J. Jasper 11-3
(Operational) Data Author: (DA) the role of the author of ontology itself) is directly related to restricting the possi-
operational data in the language which uses and/or is ble interpretations which serves the primary purpose of re-
defined in terms of the vocabulary of the ontology. ducing ambiguity. The greater the amount of meaning, the
more fewer the possible interpretations and the less the am-
Application Developer: (AD) the role of the developer of biguity. Formality (an attributed of the ontology represen-
the Application. tation language) can vary from natural language to formal
logic. We identify four notional points along a continuum
Application User: (AU) the role of the user of the Appli- of formality:
cation.
highly informal: expressed loosely in natural language
Knowledge Worker: (KW) the role of the person who e.g., many glossaries fit into this category;
makes use of the knowledge.
structured-informal: expressed in a restricted and struc-
2.1.4 Supporting Technologies tured form of natural language, greatly increasing
clarity by reducing ambiguity,
A great variety of technologies exist that can support ontol- e.g., the text version of the ‘Enterprise Ontology’ [14]
ogy applications. These include, but are not limited to: and the glossary of workflow terms produced by the
Workflow Management Coalition [9];
• Ontology representation languages-(e.g., UML, Ex-
press, Ontolingua, XML) semi-formal: expressed in an artificial formally defined
language; e.g., the Ontolingua version of the Enter-
• Knowledge interchange languages: (e.g., KIF, PIF[7], prise Ontology4;
CDIF)
rigorously formal: meticulously defined terms with for-
• Translation tools: (e.g., Ontolingua translators, CDIF- mal semantics, theorems and proofs of such properties
tools, StepTools, ... (lots!)) as soundness and completeness.
e.g., TOVE [4].
• Distributed Objects: (e.g., CORBA, COM) Using a formal language may reduce ambiguity, but
only if there are sufficient axioms – otherwise it may be
2.1.5 Maturity Level as or more ambiguous than a detailed carefully crafted set
We indicate the degree to which applications and the sup- of definitions in natural language.
porting technologies using a given scenario are mature. At For human communication purposes, informal specifi-
one extreme a scenario may be an untested idea, a specifica- cation of meaning may be preferred. Low ambiguity is also
tion for a class of potential applications. Systems that are important for humans using ontologies to aid in the devel-
already implemented very from tiny scale demonstrations opment of systems. So formal definitions may be helpful
of feasibility in a research environment to fielded applica- along with informal ones as accompanying documentation.
tions in a commercial environment. If the ontology is intended to be automatically processed,
then ontologies rich in meaning (hi-fat ontologies) present
2.2 Other Important Distinctions a more challenging task but promise greater rewards. In
the short term, lower-fat ontologies (less rich in meaning)
2.2.1 Representation of Meaning are easier to apply in working systems. An excellent ex-
How meaning in an ontology is represented varies greatly, ample of this is the multiplicity of uses of ontologies as an
and turns out to be an important factor in the success of ap- index into an information repository, both in industry (e.g.,
plying ontologies. The simplest ontologies, in this regard, Yahoo!) and research. This contrasts with the very chal-
consist of a simple taxonomy of terms. The only meaning is lenging task taken on by the PIF project, which is much
supplied by a single relation which defines the taxonomy. further from maturing into commercial tools.
The relation is usually the specialization relationship, but
2.2.2 Sharing vs Exchange
often it is a conglomeration of various relationships such
as part-of, or similar-subject-matter. Close inspection of Depending on the purpose of the ontology, and the specific
the implicit taxonoomy of Yahoo! reveals that there is no needs of the application, different architectures will be ap-
consistent specific meaning of the relationship. At the other propriate for accessing information resources. We distin-
extreme, are rigorously formal and carefully axiomatized guish between exchange and sharing using examples from
ontologies such as TOVE [4] and PIF [7]. the STEP collection of standards (ISO-10303, 1994). Sim-
The meaning captured in an ontology varies both in the ilar distinctions can be made in other environments.
amount being represented and the degree of formality of the 4 Available from ”http://www.aiai.ed.ac.uk/ ent-
representation. The amount of meaning (an attribute of the prise/enterprise/ontology.html”
M.F. Uschold, R.J. Jasper 11-4
Sharing: multiple agents (computer or human) reference a different form to be used in multiple target systems. The
a common piece of information. The information typ- benefits of this approach include decreased cost of reuse
ically resides outside any of the applications sharing and portability of knowledge across applications, improved
the information. Less common is sharing of a single application maintainability and long term knowledge reten-
application’s internal data via references that external tion (e.g., via reduced disruption from changes in vendor
applications can use. e.g., STEP’s Standard Data Ac- formats).
cess Interface (SDAI) (ISO-10303-22, 1997) The scenarios in this category differ from each other in
a number of ways. First, the authored artifact may be an
Exchange: multiple applications exchange by passing the ontology, or operational data. Second, the process of con-
data by value (i.e., copying the data) between them. verting the artifact to a different form varies. It may be
E.g., STEP’s clear text encoding standard (ISO- direct language to language translation, manual or auto-
10303-21, 1994). mated, in which case the translation process may exploit
both the syntax and/or semantics of represented concepts.
3 Ontology Application Scenarios Alternatively, the conversion may best be viewed as design,
This section describes scenarios for applying ontologies to whereby the ontology is used by the developer as a require-
achieve one or more purposes. These scenarios are ab- ments specification for the target applications. This does
stractions of specific applications of ontologies taken from not result in a different explicit representation of the on-
industry or research. These scenarios are analogous to tology, but rather the ontology is implicit in the applica-
Ivor Jacobson’s use cases [5]. Each scenario includes an tion. In this case, there is no direct language to language
overview, which identifies the intended purpose of the on- translation. An example of this is the use of the ontolo-
tology, the role of the ontology, who the important actors gies in the KADS methodology for developing knowledge
are, and the supporting technologies. Each is illustrated based systems. Another example is software developed by
with a diagram, and includes a concrete example, which Specware[17, 18].
typifies technologies or standards that people might use in
the scenario. Where appropriate, we identify a number of 4.1 Authoring Ontologies
alternate variations of the main scenario. Finally, we assess OA
the maturity level of each scenario.
We categorize the scenarios into the following three ar- convert Ontology convert
eas:
AU
Application Application
Neutral Authoring: an information artifact is authored in 1 N
a single language, and is converted into a different
form for use in multiple target systems. Benefits Figure 1: Authoring Ontologies
of this approach include knowledge reuse, improved
maintainability and long term knowledge retention.
Common Access to Information: information is re- 4.1.1 Overview
quired by one or more persons or computer applica- The motivation behind authoring neutral ontologies is de-
tions, but is expressed using unfamiliar vocabulary, or creased cost of reuse and increased maintainability of
in an inaccessible format. The ontology helps render knowledge. To accomplish this, the actors develop an on-
the information intelligible by providing a shared tology, which they can convert into multiple operational
understanding of the terms, or by mapping between target systems. Supporting technologies include unidirec-
sets of terms. Benefits of this approach include tional ontology translators and software development pro-
inter-operability, and more effective use and reuse of cesses (e.g., KADS). The principle actors are the ontology
knowledge resources. author and application user.
Indexing: an ontology is used as a mechanism for index- In this scenario, the ontology author creates an ontology,
ing information artifacts. The chief benefit of this ap- which they convert into an operational target system (e.g.,
proach is faster access to important information re- a knowledge base). Application users then interact with an
sources, which leads to more effective use and reuse operational system to perform their desired tasks.
of knowledge resources.
4.1.2 Examples
4 Scenarios: Neutral Authoring 1. An ontology author creates an ontology (e.g., for tita-
The basic idea of these scenarios is to author an artifact in nium alloys) in an ontology authoring language (e.g., On-
a single language, and to have that artifact converted into tolingua). An application developer translates the ontology
M.F. Uschold, R.J. Jasper 11-5
into Loom syntax (possibly assisted by automatic transla- DA
tion tools). An application developer directly imports this uses
translated ontology into Loom and it becomes part of the authors
Ontology
end application, which may contain additional information Operational
translate Data translate
in its knowledge base. An application user interacts with
the final system to answer questions about titanium alloys.
AU
This ontology can be reused if another application devel-
oper wishes to make use of it in another language, e.g.,
Application
1 ... Application
N
Prolog. In that case, they will have to translate the ontology
into Prolog and proceed as per the Loom example. Note Figure 2: Authoring Operational Data
that in this authoring scenario, only one-way translation is
required. This contrasts with the case described in the next The main differences are the role the ontology plays in the
section, where two way translation is required when an on- scenario, and who the primary actors are.
tology is used as an interchange format.
This example illustrates how to achieve knowledge 4.2.1 Overview
reuse by virtue of the fact that an ontology authored in a
single language can be used in multiple applications. The motivation behind authoring neutral operational data
2. An ontology author creates an ontology using the is improved maintainability and transportability of opera-
conceptual modeling language (CML) from the KADS tional data. To accomplish this, an ontology author (sec-
methodology. The application developer uses this ontology ondary actor) develops an ontology which defines the neu-
as part of the requirements specification when developing tral format used by the primary actor to author the opera-
the target KBS (e.g., for diagnosing faults). An application tional data. Tools can then translate this into operational
user then interacts with the KBS to solve their tasks. data used by an application. Supporting technologies in-
In this example, maintainability is improved because clude unidirectional translators.
there is an explicit representation of the ontology that the In this scenario, a data author creates operational data
software is based on. Reuse is achieved if the ontology is based on a pre-existing ontology, tools translate these oper-
used for different applications in the same domain. ational data into an operational target system using a unidi-
3. Automated software synthesis into multiple target rectional translator. Application users then interact with the
languages (e.g., using Specware [17, 18]) is a generaliza- system to perform analysis or query the operational data.
tion of the neutral authoring language scenario. Applica- The ontology is originally constructed from careful
tion developers play a key role in both development of the analysis of the domain of the intended class of target sys-
ontology and problem statement specification. Typically, tems, e.g., by identifying and integrating the implicit on-
the developers semi-automatically refine the specification tologies for the applications.
and ontology into an operational target application.
4.2.2 Examples
4.1.3 Variations
An operational data author uses an ontology (e.g., for work-
A variation on example 2 above, is when the original intent flow systems) to describe a workflow model. Tools trans-
is to build only one application. late the description into operation data of various target
systems. Application users perform analysis (e.g., critical
4.1.4 Maturity path) using the translated operational data.
Totally automated translation of ontologies into operational As another example, the Frame Ontology plays the role
targets has been difficult and typically relies on translation of ontology for a class of object-oriented representation
of idiomatic expressions [2]. For case studies and analysis systems (Loom, Classic, etc.). The engineering math on-
of some of these problems see [1, 13, 16]. This requires that tology [3] is a set of sentences written using that ontology.
the ontology author apply the idioms for automatic trans- Once converted to the appropriate format, this set of sen-
lation. Semi-automated software synthesis shows some tences plays the role of operational data for the target ap-
promise, but it has not been a primary focus of the ontology plications (e.g., Loom). Note that in this example, we are
community. viewing Loom as a system development tool, not an end
user application.
This example illustrates the importance of distinguish-
4.2 Authoring Operational Data
ing the different roles of the information used in these sce-
Neutral authoring of operational data is similar in struc- narios, and how the same information artifact may play
ture to neutral ontology authoring. The focus is on author- more than one role. It enables us to show the commonality
ing and translating operational data rather than an ontology. of apparently very different scenarios.
M.F. Uschold, R.J. Jasper 11-6
4.2.3 Variations ontology. In the former case, the information is made in-
telligible via translators, and in the latter case, via ontology
It may be that only one application and one translator will
mapping rules. Finally, access to the information may be
be used at a time. This arises if the motivation is to reduce
via sharing or exchange.
risk from changing vendor offerings. If a company main-
tains their models (i.e. operational data) in a single repre-
sentation, then when a new vendor format is introduced, it 5.1 Human Communication
may be easier and more reliable to develop a new translator
to convert the neutrally authored artifact to the new format KW, KW
OA
(which might be thousands of lines of code), than to con-
Ontology
vert the artifact itself directly, (which may be hundreds of
thousands of lines). An example of a commercial applica- KW,
tion using this approach is described in [12]. OA
In the case where point-to-point translators are built, in-
stead of going through an interchange format, the ontology
may play an important role in specifying the translator that
is created manually. If the ontologies are formal with rich Figure 3: Human Communication
axiomitizations, then there scope for partially automating
the construction of the translators and/or in maintaining
them when there are changes in eithre language. This is
5.1.1 Overview
analogous to the use of ontologies in the KADS methodol-
ogy, where it plays the role of specifying requirements for A major benefit of ontology development is to promote
software. common understanding among knowledge workers. To ac-
complish this, the authors develop a common shared on-
4.2.4 Maturity tology, which other knowledge workers reference in their
Same remarks apply here as for previous section. Com- work. Non-computational skills such as library classifica-
mon practice in industry is to build point-to-point transla- tion are valuable in building such ontologies, which com-
tors when the need arises. This may turn out to be more monly take the form of glossaries. Supporting technologies
cost effective, depending on the environment. include ontology editors and browsers. The principle actors
are the ontology authors and knowledge workers. The in-
4.2.5 Closing Remarks formation being shared is an ontology.
In this scenario, the ontology authors create an ontology
Insofar as a single ontology may be converted and used which knowledge workers reference in their work.
in many different applications, this is one important way
to achieve knowledge reuse. If various systems are based
on the same ontology, then this facilitates inter-operation 5.1.2 Examples
between the systems, should that be required. However,
A glossary of terms to enable different working groups,
it does not involve sharing or exchange of knowledge be-
who may have different jargon, to understand each
tween systems. This brings us to the next category.
other– (e.g., the workflow management coalition reference
document[9]). Producing glossaries, and providing com-
5 Scenarios: Common Access to Informa- mon access for humans to important knowledge assets is a
tion key focus of the Knowledge Management community. Fi-
The basic idea of this approach is to use ontologies to en- nally, although not in the form of an explicit glossary, the
able multiple target applications (or humans) to have access framework in this paper embodies an informal ontology for
to heterogeneous sources of information which is other- ontology applications which serves the purpose of enhanc-
wise unintelligible. Benefits of this approach include inter- ing communication between humans who use different ter-
operability, and knowledge reuse. minology.
The scenarios in this category differ in a number of
ways. First, the direct consumers of the information may 5.1.3 Variations
be humans or computer applications. Second, the informa-
tion artifact may play the role of an ontology, or operational It may be that the ontology is not the main item of interest,
data; the latter may be non-computational (e.g., product but it enables knowledge workers to better understand doc-
data) or computational (e.g., services). Another important uments written using unfamiliar terminology. For example,
distinction is whether the target applications agree on the this paper can also be used to make it easier to understand
same shared ontology or whether each has its own local papers from the different communities being discussed.
M.F. Uschold, R.J. Jasper 11-7
5.1.4 Maturity 5.2.2 Examples
Informal methods exist for creating informal ontologies. A team of ontology authors created the Process Interchange
Library classification skills, which have a long history are Format (PIF). The idea is to make a library of process mod-
very appropriate. There may be various tools which offer els that are expressed in various application-specific for-
automated assistence in creating these ontologies, however, mats available to each of the applications. Currently, they
we are not aware of them. are working on two formats, (IDEF3 and ILOG). This is
ongoing research.
EcoCyc [6]is a commercial product that uses a shared
5.2 Data Access via Shared Ontology ontology to make possible access to various heterogeneous
databases in the field of molecular biology. The ontology is
OA a conceptual schema that is an integration of the conceptual
Ontology
schemas for each of the separate databases.
specifies specifies
conforms to 5.2.3 Variations
Operational
OA
Application 1 T1 Tn Application n
Data
Ontology
generated
AD generated
from
T2 from conforms to
builds
translators
reader Operational writer Application
Application 2 Application 1
writer Data reader N
This scenario indicates how an ontology can be used as an In this variation translation between formats is achieved by
interchange format, to enable common access to operational readers and writers which reside in the applications and may
data. be automatically generated
Figure 4: Data Access via Shared Ontology Figure 5: Data Access via Shared Ontology: variation
Figure 4 depicts the natural way to view the situation
when there is an explicit linear format that the application
5.2.1 Overview uses for saving and loading operational data. The trans-
lators are logically separate from the applications and can
The motivation behind data access via a shared ontology is operate independently. A variation of this is the case where
reducing the cost of multiple applications having common there is no such format; instead the internal data structures
access to data. This may in turn, facilitate inter-operability. of the application are used directly by readers and writers
This is accomplished through developers agreeing on a internal to the application. So there is no explicit language
shared ontology, which defines a common language for ex- to language translation per se, but the readers and writers
changing or sharing operational data. Supporting technolo- provide the analogue of two-way translation to/from the
gies include translators, parser generators and printers. The neutral format (see figure 5).
principle actors are ontology authors and application devel- For example, an ontology author creates a shared on-
opers. tology for (e.g., for geometric data) in an ontology repre-
In this scenario, an ontology author creates an ontology, sentation language (e.g., EXPRESS). Application develop-
which different application developers agree to use. This ers use parser and printer generators to generate code in
defines an interchange format for which two-way trans- the language du jour (e.g., using the commercial product,
lation is required between it and the application formats. StepTools). This provides applications with an API that can
Each pair of translators, for a given application, in effect, be used to read and write data that applications exchange.
defines an application interface that can be used to read and However, there are no guarantees that the data conforms to
write data. Often the translators are manually created, in all the axioms in the Express schema. Maintaining such
other cases, explicit readers and writers can be automati- consistency is left to the application developers and users.
cally created using parser generators and printers (see vari- Another variation data access via a shared ontology is
ation below). Inter-operation between the multiple applica- exemplified by the EcoCyc example above. Instead of
tions is made possible by allowing them to access the same many applications using their own formats, and translating
information. from one to the other using the ontology as an interchange
M.F. Uschold, R.J. Jasper 11-8
format, there is just one application (i.e. database) which OA OA
uses a single format as specified by the ontology. In this
case, there is a one-off translation of the operational data
(in this case databases) from the pre-existing formats to the Ontology 2 Ontology 1
new format. In both this example and the PIF example, Mapping
there is a very similar process in creating the ontology in
the first place. The [possibly implicit] ontologies of several generated generated
from generates from
languages used to express information in the same domain
are combined into a single neutral format. reader writer
mediator
There are still other variations. Typically, applications Application 2
writer reader
Application 1
make use of the ontology during the development process
by incorporating code generated from the ontology in the
Figure 6: Data Access via Mapped Ontologies
application. One variation is to have the application make
use of the ontology at runtime (sometimes known as late shared ontology; instead, mapping rules are used to define
binding) rather than development time (i.e., early binding).
what a term in one ontology means in another ontology.
Another variation involves applications interchanging
A mediator uses these rules at runtime so that applications
data via a shared data store. An example is STEP’s SDAI can access each other’s data. This approach has the ad-
interface. A related variation is to only have a single ap-
vantage of not requiring the application developers to ex-
plication that reads and writes to data store for purpose of
plicitly agree on a shared ontology. Supporting technolo-
persistence and ease of maintenance.
gies include parser generators, printers, and mediators. The
principle actors are ontology authors and application devel-
5.2.4 Maturity
opers.
In some contexts, (e.g., product data using EXPRESS) ap- In this scenario, each application wishing to exchange
proaches to data access via a shared ontology are relatively data has it’s own local ontology. Application developers
mature. Commercial success exists where application de- cooperate to create a shared mapping that relates terms in
velopers can agree on shared ontologies. Achieving agree- different ontologies. This mapping is used to generate a
ment across a wide variety of applications or industries has mediator, which maps operational data expressed in the ter-
been difficult. However, in other contexts, (e.g., PIF) the minology of one ontology into operational data expressed
technology is a long way from being mature. the other ontology.
A number of factors may influence the apparent gulf
in maturity between the STEP community and the ex- 5.3.2 Example
plicit language to language translation approach (e.g., PIF).
A developer of an application (e.g., electrical power sup-
Some of the apparent success may be due to shear differ-
pliers) wants to share data with another application (e.g.,
ences in the amount of effort applied. Each vendor support-
schematic viewer). Each application has its own ontology
ing STEP formats devotes a significant amount of effort to
created in EXPRESS. The developers agree on a mapping
obtain compliance. Furthermore, the effort is spread over
(e.g., represented in EXPRESS-X), which relates terms in
each of the vendors. This means dozens or hundreds of
the power supply application with electrical schematics.
person-years of effort, as compared to just a few person-
The mapping is used to generate a mediator that maps those
years devoted to the PIF research project.
portions of the electrical power supply data into schematic
It must also be pointed out that compliance with the
data.
STEP standard does not imply complete and error-free
movement of data between vendor applications. Many
5.3.3 Variations
problems still remain.
The representations being used by the PIF community Variations for data exchange via a mapped ontology are the
contain are further from the implementation, and therefore same as for a shared ontology. Another use of mapped on-
require more manual effort to implement. In contrast, EX- tologies is to define views. One ontology represents a view
PRESS is closer to the implementation and therefore, much of data that can be mapped to a larger ontology. This is
of the manual effort is reduced at the expense of flexibility analogous to use of database views.
in implementation.
5.4 Shared Services
5.3 Data Access via Mapped Ontologies
5.4.1 Overview
5.3.1 Overview
The motivation behind shared services is neutrality (i.e.,
The motivation behind this scenario is the same as the last language, machine, operating system, location). Develop-
one. The key difference is that here, there is no explicit ers achieve this by agreeing on a shared ontology, which
M.F. Uschold, R.J. Jasper 11-9
OA AD 6.1.1 Overview
AD
The motivation behind concept-based search is location of
generated Ontology generated artifacts (e.g., documents) in some repository. Knowledge
from from workers accomplish this by using an ontology that a search
engine applies as an index into the repository. Support-
Client API API Server ing technologies include ontology browsers and search en-
gines. The principle actors are ontology authors and knowl-
edge workers.
Figure 7: Shared Services In this scenario, an ontology author creates an ontology
that different knowledge workers use to identify concepts
defines interfaces in multiple target languages. This is very in which they are interested. The search engine uses these
similar to data access via shared ontologies, except for the concepts to locate desired artifacts from a repository.5
focus of what is being shared. Supporting technologies in-
clude interface generators and marshaling routines. The 6.1.2 Example
principle actors are ontology authors and application de-
velopers. An ontology author creates an ontology (typically a sim-
In this scenario, an ontology author creates an ontology, ple taxonomy with relations between terms). A knowledge
which different application developers agree to use. Parser worker selects terms from the ontology based on concepts
generators and printers are used to generate application in- they are searching for in the ontology. A specialized search
terface definitions that each application uses to read and engine uses these terms to locate relevant documents in a
write data. repository.
6.1.3 Variations
5.4.2 Example
Variations mainly deal with whether artifacts in the repos-
An ontology author uses a language such as IDL or UML
itory are tagged and the semantic richness of the ontology.
to create an ontology for objects in a domain of discourse
A richer ontology can be used to make minor inferences to
(e.g., product data management). The ontology is used to
improve search capability.
generate interface code for the client and server (e.g., us-
ing CORBA). Client applications can then interface with
services on the server regardless of location, operating sys- 6.1.4 Maturity
tem, or location. Many commercial Internet portals are beginning to explore
use of concepts described in this scenario. Several research
5.4.3 Maturity projects, more closely aligned to this idea, are being ex-
plored.
The standards and machinery supporting this approach are
relatively mature. Success depends primarily on agreement
7 Discussion and Future Work
on an ontology with enough semantic richness to satisfy the
requirements of the client and server. We have presented a framework for understanding ontol-
ogy applications, and used it to highlight the many similar-
ities between work being done in different areas. We in-
6 Scenarios: Indexing
tend to disseminate this framework to the STEP, OMG and
6.1 Concept Based Search information integration communities. We hope to increase
the repertoire of tools and methods to the wider community
for achieving their goals. It is important to emphasize that
Ontology an application may integrate more than one of the scenar-
ios presented. We hope that by bringing these all together
Information in one place, workers may be inspired to creatively com-
bine them to make more useful applications.
This is on going work and there is much more to be
KW
done. This includes:
Search
Engine 5 We have chosen to draw the figure from the KW’s perspective, for
whom the fact that the search engine is an ontology based application is
irrelevant. It is equally valid to introduce an application developer actor
Figure 8: Concept-Based Search who uses the ontology and to view the knowledge worker as an application
user.
M.F. Uschold, R.J. Jasper 11-10
7.1 More Details 7.5 Recommend Future Research
Many interesting variations exist for each of the above sce- In performing this analysis, we hope to provide a thorough
narios, which we have not mentioned. In addition, some of review of the state of the art of ontology application. With
the ones that we have mentioned are important enough to a populated framework, and a better understanding of the
warrant their separate diagrams, examples, and discussion. maturity of various approaches, and the various tradeoffs,
There is much more to be said about the maturity of each we hope that this will naturally suggest fruitful areas for
of these approaches. further research.
We are particularly interested in illuminating why some
of the same approaches seem to have great limitations in
some contexts, and yet are seeing commercial success in Acknowledgements
other contexts. For example, PIF versus EXPRESS as ap- Peter Clark, Florence Tissot, Deborah McGuinness,
plications of the Data Access via Shared Ontology sce- Richard Fikes, Doug Lenat, and Fritz Lehman provided
nario. helpful feedback during discussions on earlier versions of
this paper.
7.2 Alternate Technologies and Tradeoffs
For each of the areas where ontologies may be applied,
References
we would like to have an explicit account of under what
circumstances any given approach is likely to work. We [1] W. Grosso, J. Gennari, R. Fergeson, and M. Musen.
would also like to identify alternate technologies, which When knowledge models collide (how it hap-
can accomplish the same goals, as well as their tradeoffs. pens and what to do). In Proceedings of
For example, the use of ontologies as interchange formats the Eleventh Workshop on Knowledge Acquisi-
is an unproven technology for sharing complex operational tion, Modeling and Management. Track: Shareable
data. The alternative is to build point to point translators. and reusable components for knowledge systems,
There are a whole host of unexplored issues. Banff, Alberta, Canada, April 1998. See URL:
Eventually, this can then be turned into guidelines for ksi.cpsc.ucalgary.ca/KAW/KAW98/KAW98Proc.
potential ontology application developers, who can be html.
guided to what approach to use under their specific circum-
stances. [2] T. Gruber. A translation approach to portable ontol-
ogy specifications. Knowledge Acquisition, 5(2):199–
7.3 More areas 220, 1993.
The following areas have not been explored sufficiently, if
at all. They need to be brought into the framework. [3] T. Gruber and G. Olsen. An ontology for engineer-
ing mathematics. In Proc. of the Fourth International
• Ontologies used for indexing, is becoming a field of its Conference on Principles of Knowledge Representa-
own with major commercial use (e.g., Yahoo!) as well tion and Reasoning. Morgan Kauffman, 1994. Also
as a plethora of research papers published recently. It available as Stanford Knowledge Systems Laboratory
would probably be useful to have a separate frame- technical report KSL-94-18.
work for this area alone.
[4] M. Gruninger and M.S. Fox. The logic of enterprise
• The role of large scale general purpose ontologies modelling. In J. Brown and D. O’Sullivan, editors,
such as Cyc. Reengineering the Enterprise, pages 83–98. Chap-
• The role of natural language ontologies, such as Word- man and Hall, 1995.
Net.
[5] I. Jacobson, M. Christerson, P. Jonsson, and Gunnar
• The domain modeling community within software en- Overgaard. Object-Oriented Software Engineering: A
gineering. Use Case Driven Approach. Addison-Wesley, Wok-
ingham, England, 1992.
• Information Integration e.g., heterogeneous databases,
data warehouses. [6] P.D. Karp, M. Riley, S.M. Paley, and
A. Pelligrini-Toole. Ecocyc: encyclopedia
7.4 Populate the Framework
of e.coli genes and metabolism. Nucleic
We would like to list a wide variety of actual systems re- Acids Res., 24:32–40, 1996. See URL: eco-
ported in research and industry and classify them using this cyc.panbio.com/ pkarp/mimbd/94/abstracts/pkarp.
framework. html.
M.F. Uschold, R.J. Jasper 11-11
[7] J. Lee, G. Yost, and PIF Working Group. The pif
process interchange format and framework. Techni-
cal Report 180, MIT Center for Coordination Science,
1995.
[8] D. McGuinness. Ontological issues for knowledge-
enhanced search. In N. Guarino, editor, Formal
Ontology in Information Systems, pages 302–316,
Trento, Italy, June 1998.
[9] Workflow Management Coalition Members. Glos-
sary - a workflow management coalition specification.
Technical report, The Workflow Management Coali-
tion, 1994.
[10] International Standards Organization. The EXPRESS
Language Reference Manual. 1994. Reference No:
ISO 10303-11:1994(E).
[11] D. Schenck and P. Wilson. Information Modeling the
EXPRESS Way. Oxford University Press, 1994.
[12] M. Uschold and M. Gruninger. Ontologies: Princi-
ples, methods and applications. Knowledge Engineer-
ing Review, 11(2), 1996. Also available as AIAI-TR-
191 from AIAI, The University of Edinburgh.
[13] M. Uschold, M. Healy, K. Willamson, P. Clark, and
S Woods. Ontology reuse and application. In N. Guar-
ino, editor, Formal Ontology in Information Systems,
pages 179–192, Trento, Italy, June 1998.
[14] M. Uschold, M. King, S. Moralee, and Y. Zorgios.
The enterprise ontology. Knowledge Engineering
Review, 13(1), 1998. Also available as AIAI-TR-195
from AIAI, The University of Edinburgh. This ontol-
ogy was developed as part of the Enterprise Project,
see http://www.aiai.ed.ac.uk/∼entprise/enterprise/
for further information.
[15] M. (editor) Uschold. Knowledge level modelling:
Concepts and terminology. Knowledge Engineering
Review, 13(1), 1998. Also available as AIAI-TR-196
from AIAI, The University of Edinburgh.
[16] A. Valente, T. Russ, R. MacGregor, and W. Swartout.
Building and (re)using an ontology of air campaign
planning. IEEE Intelligent Systems, 14(1):27–36, Jan-
uary/February 1999.
[17] R. Waldinger, Y.V. Srinivas, A. Goldberg, and R. Jul-
lig. Specware Language Manual, 1996.
[18] K. Williamson, M. Healy, and R. Jasper. Formally
specifying engineering design rationale. Techni-
cal Report ISSTECH-97-011, Applied Research and
Technology, The Boeing Company, 1997.
M.F. Uschold, R.J. Jasper 11-12