SUO: *Date 17 Jan 2002
¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤
In future contributions to the SUO list I would like
to focus my attention on some problems that I see in
the way of accomplishing our goals, as stated in the
Scope & Purpose document, or implicit to enabling it.
From my point of view, these obstacles and problems typically present
themselves under the headings of "formal/technical problems" to be
solved or else as "threats to construct validity" that prevent us
from even stating the problem in a well-posed way. I am trying
to put together an organized list of the main problems I see,
but I will just pick one off the top of the deck for now.
I do not believe that either one of our present starter documents
address these problems in a sufficiently direct and effective way,
and so I do not forsee having much to say about either one of them,
per se, but since these problems do affect the general foundations
that are currently being taken for granted by one or the other or
both of these proposals, I believe that dealing with these issues
will be critical to our success, whichever way we choose to go.
Problem. Getting a grip on the relation between abstract and concrete.
That's just the way it came to mind this time around, so don't hold me to that
description. But we run into this problem all the time in our discussions here,
so I'm sure that you're all familiar with it under one name or another. You could
also view it as a problem of proper organization in the capsules, modules, theories,
or whatever you want to call the various and sundry conceptions of subontologies.
Part of the problem is to come up with a good name, as a "module" in mathematics
is a very specific thing -- like a vector space, only over a "ring" rather than
a "field" -- and so trying to use it outside of informal contexts is going to
cause a communication block eventually. There may even be a pertinent sort
of relation between the two kinds of modules, but I can't sort it out yet.
The main thing seems to be this. You want to be able to use all of the various chunks
of abstract knowledge, gems of wisdom and malleable metals of multi-purpose materials
that have been mined from the raw matrices and extracted from the raw ores of their
onetime concrete applications, and long ago given a quasi-autonomous status as
this or that "abstract object", like all of the various arithmetics, algebras,
categories, geometries, graphs, groups, fields, logics, manifolds, modules,
rings, spaces, topologies, or whatever, that form the common stock of the
formal artisan's workshop. To cast them all in the same mold, even if
forcing the matter just a bit here and there, we could think of all
of these articles as "maps", "reticles", "scopes", "templates", or
instruments of that nature, that we use to view the more concrete
domains, scapes, scenes, skies, seas, and territories that form
the foci of our less abstracted applications and enterprises.
The organization of a candidate "ontology utility system" (OUS)
ought to recognize and to support this sort of "factorization"
of the abstract forms from the concrete matters of a complete
project workup, without sundering the "necessary connections"
and the "synthetic unifications" of the two different aspects.
These features of a working formal science are already well-established in
the working practices of any such discipline that is still leading a robust
life today, and we cannot ignore the fact that potential users of ontology
apps in these domains will expect a viable standard, at the very minimum,
to recognize, to respect, and to facilitate them.
One of the chief obstacles that I see to progress on this front
is a stubborn confusion that keeps arising about the way that
abstract things and concerte things need to articulate with
each other. This confusion mainifests itself in several
different ways:
Confusing the map with the territory. Or, another way of saying
it might be: Unreflectively projecting the map on the territory.
We want to be able to look through the reticle to the spacescape,
to use the map to orient ourselves to and guide ourselves through
the space in question, but not to identify them, and thus be able
to put aside one map and pick up another when a changes of focus,
scope, or view is due.
Now, I know that everybody thinks that they understand this problem, but
I think that there are just some things that would not keep happening if
everybody really did, so I have come to accept the fact that some of the
ways that this problem arises can be extremely subtle and even deceptive.
For instance, many of the times when some people start to re-invent the wheel
in some special domain, as if they feel that they have to develop the requisite
formal subject all over again in their tailor-made case, it is because they have
identified that formal subject -- say, some piece of logic, mathematics, or physics,
which is really more flexible than any of its fixed applications -- with just a few
of its more frequently applied bindings to concrete domains. In effect, they make
the mistake of identifying the generic formal subject with its specific concrete
uses, as if to imagine that the old wheel is stuck in the mud of the landscape
where it is currently being used the most, and so they fail to take advantage
of its true adaptability. Much futility and wasted energy comes of this.
A good ontology design should support the reuse
of concepts that are already known to be useful.
Jon Awbrey
¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤
IEEE Standard Upper Ontology
¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤
Scope & Purpose
Scope of Proposed Project:
The Scope describes what is being done,
including the technical boundaries of the project.
This standard will specify an upper ontology that will
enable computers to utilize it for applications such as
data interoperability, information search and retrieval,
automated inferencing, and natural language processing.
An ontology is similar to a dictionary or glossary, but
with greater detail and structure that enables computers
to process its content. An ontology consists of a set of
concepts, axioms, and relationships that describe a domain
of interest. An upper ontology is limited to concepts that
are meta, generic, abstract, and philosophical, and therefore
are general enough to address (at a high level) a broad range
of domain areas. Concepts specific to given domains will not be
included; however, this standard will provide a structure and a
set of general concepts upon which domain ontologies (e.g. medical,
financial, engineering, etc.) could be constructed.
Purpose of Proposed Project:
A. Automated Reasoning
The standard will be suitable for automated logical inference
to support knowledge-based reasoning applications.
B. Inter-Operability
The standard will provide a basis for achieving Inter-Operability
among various software and database applications.
1. Application developers can define new data elements
in terms of a common ontology, and thereby gain some
degree of interoperability with other conformant systems.
2. Applications based on domain-specific ontologies that are compliant
with this standard will be able to interoperate (to some degree) by
virtue of the shared common terms and definitions.
3. The SUO will play the role of a neutral interchange format whereby
owners of existing applications will be able to map existing data
elements just once to a common ontology. This provides a degree
of interoperability with other applications whose representations
conform to SUO. This entails the SUO being able to be mapped to
more restricted forms such as XML, database schema, or object
oriented schema.
C. Application Areas
1. E-commerce applications from different domains
that need to interoperate at both the data and
semantic levels.
2. Educational applications in which students learn concepts
and relationships directly from, or expressed in terms of,
a common ontology. This will also enable a standard record
of learning to be kept.
3. Natural language understanding tasks in which a knowledge-based
reasoning system uses the ontology to disambiguate among likely
interpretations of natural language statements.
¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤