Re: evaluation of logic as a representation for ontologies

• Mail folder: SRKB Mail
• Next message: sowa@watson.ibm.com: "Sharing ontologies and softwre"
• Previous message: Tom Gruber: "evaluation of logic as a representation for ontologies"
• In-reply-to: Tom Gruber: "evaluation of logic as a representation for ontologies"

Date:     Thu, 27 Aug 92 10:42:19 MET DST
From: Charles Petrie <petrie@informatik.uni-kl.de>
To: Tom Gruber <Gruber@sumex-aim.stanford.edu>
Cc: Shared KB working group <srkb@isi.edu>, huhns@mcc.com
Subject:  Re:  evaluation of logic as a representation for ontologies
Message-id: <9208271042.aa00608@inti.informatik.uni-kl.de>

Tom,
 The examples you address suggest that, as usual, the problem is less
with the adequacy of the modeling language, than with agreement on the
domain semantics: even with a smallish niche like bibliographies.  But
the problem is that no one is offering a bibliography service.

 Folks are just not likely to agree upon an ontology in the abstract.
They may use an Internet service and Ontolinqua may be a good way to
formally describe the service so that it can be ported from one
machine to another rather than just used as a remote server.  There is
a commitment to an ontology to the extent there is use of the service.

 None of this directly addresses the crucial problem of merging
software, which Bob Neches raised, again. But, it does address this
problem indirectly.

 Pick a university that has an expert systems class. Every year, say,
fifty student expert systems get built. Say, five of them are on
agricultural management. Over ten years, we get fifty expert systems
on various aspects farm management, perhaps in the same language.  Is
there any hope of combining these fifty into a network that comprises
a super farm management system? Rhetorical question.

 So the hope of Ontolinqua, perhaps, is that each expert system author
could, in principle, describe his ontological commitments in
Ontolinqua, thereby facilitating cross-system inferences. In such a
scenario, the best that can be hoped for is that Ontolinqua
descriptions would expose the conflicts between the definitions in the
existing systems. Such a partial solution is useful.  For example,
Ontolinqua might be a useful tool in integrating/federating enterprise
models. Has this been tried? (Could two IDEF users use Ontolinqua?)*

 Ontolinqua will provide a "complete" solution for future systems to
the extent that person 1 will use it to describe his/her current
system and person 2 will use that description to guide his/her
construction of the next system.  Apart from the obstacles of tool
properties (e.g., adequacy, ease-of-use), why would person 2 do so?
Not because he/she wants to avoid the bother of reconstructing the
ontology. Every programmer knows that it's easier to write the program
>From scratch than really understand what someone else has done.
Besides they can always do a better job.  And the new task is a little
different.  And...  For that matter, why should person 1 go to the
trouble?

 One possible reason is that the system from person 1 provides an
service S1. Person 2 wants service S2 to use S1, or part of it, as a
utility.**  Whatever the motivation for offering (Internet or local)
services, Ontolinqua might be a good way to describe services for
reuse.  However, such a scenario makes it clear that Ontolinqua alone
is not sufficient. There must be a way of advertising services and
making them available as severs.  Then there is a motivation, and a
way, to share ontologies.

Charles

* In the Enterprise Modeling conference in June at Hilton Head, the
"traditional" enterprise modeling people came to the startling
conclusion that the reason enterprise models were always "shelfware"
(much less integrated), was because they were not written to be used!
One of this subgroup's resolutions was to emphasize that enterprise
models should be built with some _use_ in mind. Models should be able
to make inferences from domain knowledge and answer questions. This
was a radical breakthrough for them.  I suggested that they look at
expert system technology, which was also a new thought.  On the other
hand, there was some evidence that users already found IDEF0 too
complex.  Sigh.

** Reuse of software is a different problem from that of coordinating
heterogeneous systems to accomplish a task, ala SHADE and PACT, in
which the systems need to agree to some extent upon the current state
of computation. But we need to think about the relationship between
the problems, especially with respect to design rationales.