Method for building OntologiesMike Uschold <firstname.lastname@example.org>
From: Mike Uschold <email@example.com>
Date: Wed, 23 Nov 94 14:27:27 GMT
Subject: Method for building Ontologies
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com
Regarding Martin King's note included in my previosu posting, the upshot with
respect to building ontologies, is to proceed middle-out rather than top-down
or bottom-up. We are applying these ideas with some success in a current
effort to construct an `Enterprise Ontology'. The method we are using is
1. Ignore meta-ontology (MO) at outset, and do high(ish) level breadth
first identification and definition of main concepts.
2. Remove redundancy wherever possible.
3. Critically review high level natural language ontology; if not ok, go
to step 2.
4. Devise a meta-ontology, using natural langauge ontology as an implicit
5. Code high level definitions in MO terms (i.e. the formal language for
representing the ontology -- e.g. KIF).
6. Go next level of detail for each work area.
STEP 1 proceeds as follows: Do high(ish) level breadth first
identification of main concepts by brainstorming. These are then
divided up into what we call work areas corresponding to naturally
arising sub-groupings of concepts (e.g. marketing, activities, time).
All major concepts are carefully defined in natural language being as
precise as possible. Each area is worked on independently at first.
Within each, note which concepts are likely to be imported/exported
from/to other other work areas. E.g.
RESOURCE: something that is used or consumed during an ACTIVITY.
GO MIDDLE OUT: within each work area, we start with psychologically
`basic' concepts first, (See `On Categorization in Modelling' by Martin
King recently posted to this list) and then introducing higher and lower
level terms as required.
STEP 2: Identify concepts with similar and/or overlapping meaning.
Eliminate redundancy by merging similar terms and REUSING terms rather
than having several similar ones.
Where similar ones seem needed somehow, these are defined in terms of
one base level concept. e.g. we defining PURPOSE to be a desired STATE OF
AFFAIRS. We then define OBJECTIVE as a PURPOSE with a defined quantitate
measure. Things like MISSION, VISION, GOAL are also defined in terms of
STEPS 3&4: In our natural langauge definitions, we specifically chose to
use the word `something' where we might have used ENTITY, or OBJECT. We
have deferred a decision about what formal term to use for this until we
have a complete set of definitions for all the major concepts. The
definitions serves as requirements for the meta-ontology.
If we committed to a MO first, we felt there was a risk that
* it might limit our thinking in steps 1 and 2, and result in inadequate
or incomplete coverage of the concepts.
* and/or it might be wrong and we would have to re-do it anyway.
Currently, we are in the middle of this exercise, and are attempting to
notice important aspects of the method, rather than solely construct the
The middle-out approach is working well, but as this is not a CONTROLLED
experiment, it will only be possible to *estimate* what the pros/cons of
this approach are compared to a top-down or bottom-up approach.
We encourage others to also do this, and by comparing experiences, we
can come to a better understanding of building ontologies.
If you already have written up any notes, guidelines or your
experiences on how to build ontologies, please send them to me.
Also, please refer me to any papers on this topic that are available.
I'm already aware of Tom Gruber's guidelines which are useful as a
starting point, but they do not constutute an attempt to describe
anything approaching a methodology for building ontologies.
Mike Uschold, AI Applications Institute,
INTERNET: M.Uschold@ed.ac.uk The University of Edinburgh,
Tel: (031) 650 2732 80 South Bridge, Edinburgh EH1 1HN
Fax: 650-6513 Scotland