SUO: Update on Negotiation Instead of Legislation
Mark, Bill, et al.,
I didn't reply to your notes last week for two reasons: (1) I was
traveling and it was inconvenient to get much time to write notes;
and (2) I wanted to wait until I had updated my slides with some
new material that would explain how the VivoMind system does
structural mapping. Following is the URL for the updated version:
http://www.jfsowa.com/talks/negotiat.htm
Mark Estes wrote:
ME> Are differences between claims *systems make* perceived (e.g.,
> by the system? its creators? its users? or some combination thereof)
> as a starting point for negotiation?
I have changed the slides to avoid the implication that computers
"make claims". The point I wanted to emphasize in those slides is
that the main focus of negotiation is some particular task or domain
on which agreement by humans is required, but for which the computer
can make an important contribution by finding structural matches.
Those matches can then form the foundation for automating the
translations between different ontologies.
Bill Andersen wrote:
BA> ... a question has been bothering me about your characterization of
> the "negotiation" vs "legislation" approach to IS integration. From
> what I've been able to gather from the discussion and your writings
> you've referenced in the posts, the idea is that only "small
> adjustments" need to be made to some kinds of naïve inter-system
> mappings when they prove inadaquate, the claim here being that this
> is somehow a different task (I mean formally here) than the one of
> mapping each system to a subsuming ontology.
I used the word "local" rather than "small". My point is that when
two or more systems interoperate on some task, the only thing that
is relevant are their localized reactions to task-specific requests.
Mapping any or all of them to some "subsuming" or global ontology
that covers more ground than the specific task requires is irrelevant
to the problem of making them interoperable on the task at hand.
BA> Considering the problem abstractly, the task is to make the
> semantics of the two (n) systems compatible over some relevant subset
> of functionality. For me, this means that the relevant terms (logical
> database structure, function names, etc) "mean" the "same" thing from
> the perspectives of the member systems. The real action here is to
> arrive at some reasonable meaning for the words "mean" and "same" in
> the above (thus the scare quotes), even prior to a discussion on how
> one might procedurally compute meaning and sameness.
My preferred definition of meaning is Peirce's maxim of pragmatism:
Consider what effects that might conceivably have practical bearings
you conceive the objects of your conception to have. Then, your
conception of those effects is the whole of your conception of the
object. (CP 5.438)
When applied to what computer systems do, this maxim implies that
the total meaning that can be attributed to what a computer system
does depends on the "effects that might conceivably have practical
bearings". In other words, the meaning depends on what kinds of
outputs it generates for any particular sequence of inputs; i.e.,
for the purpose of interoperability, the only relevant axioms are
the ones that relate the system's input conditions to its output
conditions on some particular task or domain of tasks.
Any axioms about its internal states or its upper-level ontology may be
important for the system's designer, but they are at most a peripheral
interest and sometimes a major distraction to the person who wants to
use the system to perform some service.
BA> It seems also inescapable that the meanings of "mean" and "same"
> will have to do exclusively with formal properties of axioms (stated
> or not) constraining the interpretation of the terms manifest by the
> participating systems.
I don't disagree with this point. But I would ask another question:
from what point of view are you deciding which axioms are relevant?
That question reminds me of Harlan Mills' comparison of an operating
system to a cow. Any programmer can probably think of many different
ways of designing a better operating system, just as a cattle breeder
might think of ways of improving the next generation of cows. But if
you are a user who wants to get a job done, you just look at the input
and output conditions. For a cow, that means that you put hay and water
into the front end, get milk out of the middle, and fertilizer out the
back end.
From the point of view of the designer or programmer who implements a
computer system, the axioms that define its input and output conditions
are the starting point, from which one might determine other axioms
that constrain the internal states used to derive the required outputs
from any given inputs.
But from the point of view of a system integrator who is combining
multiple systems into a network, the immediately relevant axioms are
the input and output conditions. The axioms about internal states
are as irrelevant as the internal axioms that define a cow.
BA> So, the question is: How is it that a process of negotiation arrives
> at the relevant computation over these formal properties, where a
> mapping to a third, well understood standard ontology cannot arrive at
> the relevant computation over these properties?
If you are a system integrator, the only ontology that is relevant to
your needs is one that relates the outputs of one system to the inputs
of another for the scope of the given domain of tasks.
I won't deny that large ontologies such as Cyc or what SUMO is intended
to become aren't useful. However, I would not want to adopt any of them
as a standard. Instead, I would like to use them as resources, which
are best taken in small doses. If and when OpenCyc becomes available,
I would like to see a project that would tear it apart into smalller
reusable modules that could be mixed and matched with modules taken from
other projects, such as SUMO or IMPS or many other sources.
I believe that approach is quite compatible with the way that you used
Cyc as a resource from which you extracted a small subset that was
suitable for your particular problem domain. In fact, I frequently cite
your paper as an example of how a large ontology should be used:
Peterson, Brian J., William A. Andersen, & Joshua Engel (1998)
"Knowledge bus: generating application-focused databases from large
ontologies," Proc. 5th KRDB Workshop, Seattle, WA.
For a copy of that paper see the conference web site:
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-10/
John Sowa