Re: Multiple ontologies

• Mail folder: Interlingua Mail
• Next message: sowa@watson.ibm.com: "ANSI IRDS Working Paper"
• Previous message: Gio Wiederhold: "Re: Multiple ontologies"
• In-reply-to: Gio Wiederhold: "Re: Multiple ontologies"

Message-id: <9110141507.AA08218@venera.isi.edu>
To: Gio Wiederhold <gio@earth.stanford.edu>
Cc: Marianne Siroker <siroker@eclipse.stanford.edu>, NECHES@isi.edu,
        SRKB@isi.edu, INTERLINGUA@isi.edu, KR-ADVISORY@isi.edu,
        GINSBERG@t.stanford.edu, SKPEREZ@mcimail.com
Reply-To: ramesh@isi.edu
Subject: Re: Multiple ontologies 
In-reply-to: Your message of Sat, 12 Oct 91 21:17:52 -0700.
             <CMM.0.90.2.687327472.gio@earth.Stanford.EDU> 
Date: Mon, 14 Oct 91 08:07:02 PDT
From: Ramesh Patil <ramesh@isi.edu>

> Mini-note:
> I'd hope that the application-level module, using lower-level modules with
> distinct ontologoes, does NOT have to peer into those modules to induce their
> ontologies, rather that the modules does reasoning only about the
> externally accessible description.
> Gio

Gio, I completely agree with you.  The right way to understand the
multiple ontology issue is to consider it in context of
communication between different modules.  From this viewpoint, the
critical question is that of interface language of communication. 
If the two modules share a common language (set of terms in the
ontology) for making requests and receiving answers (in programming
terms, for providing inputs and outputs) then they can cooperate. 
How the ontologies of the two systems differ beyond the common terms
used in the interface does not bear on the effectiveness of
communication.  Thus, the two modules (or their designers) are free
to extend their internal ontologies independently.  For example, a
cardiologiest may have a great many terms for describing conjestive
heart failure (different sub-types, their pathologies etc),
specialists in other areas will not.  But so long as they both
understnad the term "conjestive heart failure" the cardiologist can
provide his diagnosis and recommendations.

This is similar to (but not the same) as the multiple representation
approach successfully taken in MACSYMA project.  Each subsystem in
MACSYMA had its own internal representaion and could communicate
with other subsystems using a shared set of operators and
representations.  Within the subsystem modules themselves had their
own even more specialized representations and communicated with
other modules in the subsystem using subsystems internal
representation.  I envison, that a similar hierarchy of ontologies
to develop within a large hetrogenious knowledge based system.  To
be effective, each subsystem of the overall system will share a
common ontology (which is adequate for its task level).  For
effective problem-solving each submodule will be free to adapt for
its internal use an ontology which may extend or replace the common
ontology, so long as it can map back to the common ontology for
communication with external systems.

I would argue that what you hoped for in your note, is in fact a
necessacity if we are to build large and extensible systems.  It is
essential for modularity, and therefore for scalability.
 - Ramesh