Ontology firstname.lastname@example.org (Mark S. Fox)
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 8 Jun 1995 15:24:42 -0500
From: email@example.com (Mark S. Fox)
Subject: Ontology content
As head of a group of 7 people building ontologies for Enterprise Modelling
(e.g., activity, resource, organisation, cost, quality, agility, etc.), I
found the recent interchange quite interesting.
Though I am happy to hear that there is interest in content, I am concerned
when people say they would like to see "a lot of concept organisations"
even if they are easily browsed.
The world abounds with "concept organisations." Every manufacturing and
engineering corporation has "a lot of concept organisations" that are fully
documented. If you want to see the futility of this approach, check out
the Air Force's Integrated Computer Aided Manufacturing (ICAM) project's
[Martin, C., Nowlin, A., St. John, W., Smith, S., Ruegsegger, T., and
Small, A. Integrated Computer-aided Manufacturing (ICAM) Architecture Part
III/Volume VI: Composite Information Model of "Manufacture Product" (MFG1).
Technical Report AFWAL-TR-82-4063 Volume VI, Materials Laboratory, Air
Force Wright Aeronautical Laboratories, Air Force Systems Command,
Wright-Patterson Air Force Base, Ohio 45433, 1983.]
Politely stated, the above and its siblings are an unfathomable morass.
Even more narrowly focused efforts leave much to be desired because they
are poorly defined (i.e., imprecise, ambiguous):
[Scheer, A-W. Enterprise-Wide Data Modelling: Information Systems in
Industry. Springer-Verlag, 1989.]
With the wide spread adoption of object-oriented programming, we will be
drowning in concept organisations.
If a design goal of an ontology is that it be reusable, then there are (at
least) three things we should be concerned with: Clearly stating what an
ontology is good for, how it can be used and how it can be created. From
this perspective, it is not clear what value Ontology Engineering adds,
other than an incomprehensible name.
A fundamental error of Ontology Engineering research is the lack of a well
defined process. How do we actually construct ontologies? In our work,
ontologies are used to support enterprise decision making such as design,
planning and scheduling. We therefore begin the process by defining the
set of questions the ontology must be able to answer - we call this the
"competency" of the ontology. Without these questions, the engineering
task lacks focus, we would not know whether someone else's ontology is
appropriate nor whether our own is complete. Questions are iteratively
refined and become better understood as the terminology/taxonomy emerges.
A second important part of our process is to document the terminology as
precisely as possible. To this end we provide definitions of and
constraints on the terminology. In our work, we restrict ourselves to FOL.
We have found it sufficient for most of what we need to represent.
The bottom line, is that we need to focus equally on the ontology, how to
specify its relevance and the process with which it is derived. And the
ontology must be more than a set of objects, but include (more) formal
definitions, competency questions, etc.
Ontologies must not only be pretty to look at, but practical to use.
[For more info on our ontology engineering process see: Gruninger, M., and
Fox, M.S. (1995), "Methodology for the Design and Evaluation of
Ontologies", Workshop on Basic Ontological Issues in Knowledge Sharing,
IJCAI-95, Montreal. It can be retrieved via the web:
Mark S. Fox
Professor of Industrial Eng. tel: +1-416-978-6823
Department of Industrial Eng. fax: +1-416-971-2479
University of Toronto email: firstname.lastname@example.org
4 Taddle Creek Road http://www.ie.utoronto.ca/EIL/eil.html
Toronto, Ontario M5S 1A4 CANADA