Jim, (01)
Your concern is justified, if all we could produce
was a collection of unrelated modules: (02)
> Regarding John Sowa's suggestion of a collection
> of modules, I question if it is possible to achieve
> semantic interoperability with this approach, since
> we will certainly have n-squared modules? (03)
But what we have today is a problem of N-squared
communication paths among N *large* systems. (04)
A few days ago, Rick Murphy made a point, which I strongly
endorsed: focus on the information flow along those paths.
That change of focus has several implications: (05)
1. When two systems A and B communicate, they always
communicate about some subset of services on which
they need to interoperate. For example, system A may
be Amazon.com's purchasing system, while B might be
some book publisher's sales system. (06)
2. Both A and B have many other communication links among
themselves and with their other customers, suppliers,
employees, and agencies of various governments. (07)
3. The ontology of the communication flow between A and B
is a tiny subset of the entire ontologies of everything
involved in both businesses. It's not practical or
necessary to align the entire ontology of either company
with the other. (08)
4. Since Amazon has such a large share of the market for books,
they have the power to dictate an ontology for the kinds of
products they buy and the formats of how the transactions
are performed. Company B, therefore, tells some database
administrator to align some aspect of B's database to the
categories and formats of A's purchasing system. (09)
5. That task-oriented alignment, however, has a minimal effect
on the overall ontology of Company B. Since Amazon is so
large, it forces other suppliers to make similar alignments.
Eventually, Amazon's ontology and formats become one of
many de facto standards for electronic commerce. (010)
That's part of the modularity issue: It's task oriented,
bottom up, and focused on information flow. Many such modules
have evolved over the years. They're not going away, and they
will be used indefinitely. (011)
Another part of the modularity issue is top down and focused on
the details of internal processing, not on external information.
This is where a detailed specification is used, either in procedural
code or declarative axioms. But the internal details that are
significant parts of a company's ontology are mostly irrelevant
to the information flow along communication lines. (012)
What passes along communication lines are primarily names of
entities classified in categories. For example, _War and Peace_
is the title of a book, ten copies of which must be shipped from
Company B to Amazon for a given price on a given date. Axioms
about time and the differences between situation calculus and
pi calculus for reasoning about time are not relevant to this
transaction. They may be very relevant to programs running
in System A or System B, but it's irrelevant whether A and B
use the same or different axioms at each end of the channel. (013)
In an earlier note, Paul Prueitt made the point that vocabularies
are more important than logic. For external information flow, I
would agree that vocabularies are extremely important, but I would
also insist that the formal specification, either in programs or
in logic, is extremely important for the *internals* of A and B. (014)
Basic point: Interoperability among systems depends primarily on the
channels for information flow, which are always highly specialized
for particular kinds of tasks: (015)
1. The information systems of any large company may interoperate
on a daily basis with thousands of other systems around the world.
It is unrealistic to require a global alignment of the full
ontologies of all the categories and axioms of all those systems. (016)
2. Any particular system may have many channels that are dedicated
to many different tasks, each of which involves only a small
subset of the total ontology of the system. (017)
3. Most of the axioms that specify the internal computation and/or
reasoning that takes place inside a system are *not* relevant
to the information flow along any particular channel. (018)
4. Task-oriented alignments of the vocabularies of symbols that
pass along any channel are essential, but only a *minimal* subset
of the complete definitions of those symbols need to be aligned. (019)
Two banks, for example, may have very different kinds of programs
specified by very different ontologies for processing checks. But
when a transfer for X dollars occurs, they only need to agree on
the axiom that $X is deducted from one account and added to another
account. (020)
As another example, the format of a date is critical, but it's
irrelevant whether any system that uses the date applies the axioms
of situation calculus or pi calculus or whether it uses a 3-D or
a 4-D ontology for space and time. Different systems could use
different axioms internally. (021)
John Sowa (022)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (023)
|