Wednesday, November 23, 2005
Center of Excellence Proposal
à
ONTAC stands for Ontology and Taxonomy Coordinating Working Group
It is a working group of
Semantic Interoperability Community of Practice (SICoP)
Discussion Subject: Re: [ontac-forum] Sowa's Collection of Modules
Communication form John Sowa to the ONTAC working group
Jim,
Your concern is justified, if all we could produce was a collection of unrelated modules:
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?
But what we have today is a problem of N-squared communication paths among N large systems.
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:
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.
2. Both A and B have many other communication links among themselves and with their other customers, suppliers, employees, and agencies of various governments.
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.
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.
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.
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.
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.
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.
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.
Basic point: Interoperability among systems depends primarily on the channels for information flow, which are always highly specialized for particular kinds of tasks:
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.
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.
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.
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.
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.
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.
John Sowa