Key questions on Common Upper Ontology
Paul, Larry, Irene, et al.,
The discussion about ontology creates a lot of confusion, partly because "ontology" is very seldom defined, and when it is, the definitions are so vague (e.g. "specification of a conceptualization") that they mean practically nothing.
Since the applications we are currently considering are related to computing, I suggest that we replace every occurrence of the word "ontology" in these discussions with the term "program specification" or just "program spec".
To illustrate this exercise, I performed that transformation on Irene's comment:
I am referring to the second question: "Can we achieve cross-domain semantic interoperability without a common upper program spec?" My understanding of Tim Berners-Lee position is that he believes that semantic interoperability can be achieved without a common upper program spec. In fact, this point is an essential part of his vision of the semantic web. The subway map picture http://www.w3.org/2003/Talks/1023-iswc-tbl/slide10-0.html is one example of Tim's explaining how it would work and why the semantic web does not require such program specs. The attempts to develop common upper program specs have been active for many years, probably nearly twenty now, with so far no success. In some ways Tim's ideas can be seen as a response to this lack of success.
Let's start with the phrase "common upper program spec." I would interpret that as a specification of those data elements that are common to some fairly large set of programs. There are many such things in existence, such as the IEEE floating-point specs and various standards for times, dates, currency, etc. There are also various things called APIs (Application Program Interfaces), which are also a kind of common upper program spec. So such things do exist, and they are very useful.
Irene then suggested that we look at Tim BL's subway map. It's a good illustration, and I suggest that anyone reading up to this point take a look at it before continuing.
The circles, which I assume represent "subway stations", are good places to look for a standard upper program spec: Addressbook, Event, Bank, Calendar, Flights. Some of these things have been standardized -- mostly by playing the game of follow the leader. Sabre was the first airline flight reservation system in the 1960s, and it established the ground rules for everybody else in the industry.
The Bank station, has not been quite as successful, because there are so many that no clear leaders have emerged. There have been some agreements on interbank data transfers, but no two banks truly have interoperable software. Whenever two banks merge, they never merge their databases. Instead, what they do is either keep both databases running forever, or they kill all the accounts in one and reopen new accounts in the other.
And the Event station should have one of those digging signs saying that it is permanently under construction -- because there are so many different kinds of events, that nobody has been able to define a common program spec for all of them.
Following is the transformation of part of Paul's statement:
It might be evidence that notions of a standard program spec and an
upper program spec both have specific hidden flaws. The alternative is to
suggest that one cannot engineer human social discourse.
The flaws are not hidden: they are just the usual result of having too many cooks in the same kitchen. Any single cook can create a great meal, but any two of them will either fight or spoil the broth. But since people like variety, you don't want to get rid of all but one cook -- you just want them to work on different days, in different restaurants, or at least in different kitchens -- i.e., they work well, but they don't interoperate well.
To continue that analogy, the French chefs have a great motto:
Il faut honorer le menu.
That means if it's on the menu, you'd better be prepared to serve it as advertised. In other words, don't pull a Gates and trample the standards.
Summary: It is possible to get common upper program specs for well understood things, such as floating-point numbers, times, and dates. But watch out for bigger, more complex things like events and the full range of transactions that take place in a large organization such as a bank (or any other business).
John Sowa