what does "portable" mean with respect to ontology?
Tom Gruber <Gruber@Sumex-AIM.Stanford.edu>
Message-id: <2923154172-9934290@KSL-Mac-69>
Date: Tue, 18 Aug 92 12:16:12 PDT
From: Tom Gruber <Gruber@Sumex-AIM.Stanford.edu>
To: Shared KB working group <srkb@isi.edu>
Subject: what does "portable" mean with respect to ontology?
[Excerpt of email exchange with Riichiro Mizoguchi <miz@ei.sanken.osaka-u.ac.jp>
Remailed with permission.]
--- Excerpt from Riichiro MIZOGUCHI (Thu, 13 Aug 92 21:04:29 +0900) ---
> I think the term "portable" is somewhat misleading. When I first knew
> Ontolingua supports portable ontology, I thought it 'understands'
> ontology and hence it can port it to another system and combine
> knowledge written in different ontologies into a unified
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> knowledge. But the reality is that understanding of Ontoliunga-written
> ontology is left to human interpretation. Every program is portable
> when someone codes the language translator. Whatever language one
> use to write his/her ontology, it becomes portable when the language
> translator is available(C to Lisp, vice versa, et al.).
> Am I correct in summarizing your point as that let's use the same
> language to write ontology in declarative form?
You've hit upon the central issue of knowledge sharing at the content
level. But I'm note sure that I have communicated my intent with the
use of "portable". Yes, the idea is to share a common language for
ontologies. But that language is portable in a different sense than a
program being portable across Unix platforms. Ontolingua is not a
representation system. True, with KIF and the frame ontology terms,
it can be viewed as a language. With translators into LOOM, Epikit,
Algernon, CycL, etc., it is portable _to_ representation systems,
where all of the assertions and queries actually happen. What
Ontolingua "understands" are the concepts common to object-centered
representation systems, such as subclass, instance, and slot
constraints. It offers a "common language" for saying these things,
but is flexible about the "represented system" into which this language
is translated. That's the sense of "portable" that I meant.
Ontolingua does not know how to merge or transform ontologies -- how
could it? Only a program that understands the _content_ of those
ontologies could do that task, and assuming that a program has such
knowledge begs the question. Now, we are working on translators from
representaion systems (e.g., LOOM) into Ontolingua. That will allows
us to transform statements about subclass relationships, domains, etc.
>From a LOOM ontology into any system that Ontolingua supports. The
_content_ of those ontologies will remain opaque to our translators;
only the logical meaning of the sentences and the use of
frame-ontology terms will be understood by the translators.
> As you pointed out in one of the recent emails, many systems in which
> meaning of ontologies are embedded in procedures, I think this is a
> usual case, are difficult to treat. In Schank's CD theory, for example,
> the set of eleven primitive verbs are a good example. They are
> recognized as a sophisticated ontology for NL understanding.
> Unfortunately, however, its meaning is embedded in huge amount of
> procedures in his MARGIE system. But, it is clearly understood by many
> researchers, since the meaning is written in NL. In this case NL serves
> as a representation language. Although human can reuse the eleven
> verbs, computer cannot. I hope the future ontology be written in a
> declarative form.
I agree that procedural attachment is a source of meaning in many of
today's ontologies. We are confronting that problem directly with the
strategy of the knowledge sharing effort. The concept of shareable or
portable ontology is related to the idea of the knowledge level as a
specification of what agents know; the specification is independent of
the symbol-level encoding. The hypothesis underlying the KSE's
strategy is that it is possible to share and reuse knowledge written
in declarative form. This hypothesis can be false; it could be that
the only way to share knowledge bases or provide interoperation among
knowledge-based programs is to share programs. If that turns out to
be the case, then we should all start writing our programs in the same
language on the same giant ontology.
As for natural language, again you are right. Please notice that
ontologies contain BOTH formal axioms and documention strings. The
strings are vital to understanding. The axioms play a complementary
role: they are clearer when the domain of interest can be described
completely and formally (e.g., sets, sequences, functions) and in the
other cases they provide _partiail_ constraints on meaning that can be
verified by mechanical inference (in principle, and with the normal
caveats about completeness/tractability tradeoffs).
The interesting thing about the bibliography ontology that I sent out
is that it is simple enough to highlight the boundary between what is
formalized and what is left as primitive (described mainly in natural
language). While we say that an author is an agent and has a name
that is a string, we don't say what a agent is (except that it is the
generalization of person and organization). That is a boundary of the
ontological commitment of the bibliography tools and databases.