[Top] [All Lists]

Re: [ontolog-forum] Theoretical issues and practical applications

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Tue, 05 Jan 2010 09:41:51 -0500
Message-id: <4B434FAF.4090602@xxxxxxxxxxx>
Dear Matthew and Ian,    (01)

I agree with your positions.  There is no conflict between them and
what I wrote in the note to Jim Rhyne with later extensions in my
replies to David and Rob.    (02)

As a reminder, following is Jim's question:    (03)

JR> Where is the research on central control of design and analysis
 > for logical systems? Where is the work on testing large collections
 > of knowledge and on determining the testing requirements for
 > merging two or more knowledge bases?    (04)

I responded with a comparison of a research conference in 1980 with
the research conferences today:    (05)

JFS> The topics covered and the level of the discussion was almost
 > indistinguishable from the typical proceedings in ontology
 > conferences today.  If anything, many of the recent conferences
 > have degenerated to RDF & OWL hacking that is at about the same
 > level of sophistication as typical SQL hacking.
 > To answer your question about when we can expect to merge
 > independent knowledge bases, I suspect that the answer is never.    (06)

Note the words 'independent' and 'merge'.  That is very different
from the following approach, which I strongly endorse:    (07)

MW> What I have seen over the last 40 years is that computer
 > applications are developed to meet specific needs, eventually
 > enough are built so that there is a cluster of applications
 > that overlap in scope in a way that makes interoperation
 > important. Doing this with interfaces is expensive, and
 > there are problems with inconsistencies between the systems.    (08)

I agree.  To use the banking example, each of the two banks had
independently developed clusters of applications that had evolved
over a long period of intimate interoperation.    (09)

MW> Eventually someone sees an opportunity to build a bigger
 > application that covers a larger area, and the process starts
 > again. The result of this process after several rounds is
 > large applications like SAP.    (010)

I agree with that as well.  But note that this is an *extension*
to the previous cluster within a single organization, such as
a bank.  It does not address the problem of how to "merge" two
independently developed clusters.    (011)

MW> The key difference to your example is that you are looking
 > at applications that do the same sort of thing, whereas the
 > sort of integration I am talking about is between systems that
 > do different things.    (012)

Yes.  The two banks before the merger competed with each other
in performing similar kinds of services.  The also cooperated
with each other by passing messages on paper and later by
electronic means.  The internal methods that the banks used
to process messages were irrelevant to the communication.    (013)

But the following procedure is followed in *every* bank merger
and in mergers of other kinds of businesses:    (014)

JFS> When two banks merge, they never merge their databases.
 > Either they keep both DBs operating independently, or they close
 > the accounts from one DB and open new accounts in the other.    (015)

If they keep both DBs operating, they would eventually create
a larger cluster that incorporates both.  The other alternative
is to ignore the policies and practices of one of the clusters
and transfer the funds to the other.    (016)

IB> There is one large integration project I know of where they
 > originally claimed they had just under 400 applications --
 > a few did the same thing, some were completely specialised,
 > most overlapped to greater or lesser degrees. On closer inspection,
 > there were actually more like 2000 software items under their
 > control -- the vast majority of these were interfaces between
 > the applications (usually home-made or developed by one of the
 > usual suspect system houses). The cost of maintaining the
 > interfaces turned out to be higher than the maintenance cost
 > of the legacy apps -- one tweak to an application could have
 > a significant knock-on effect on several interfaces.  The
 > system architecture diagrams for that project looked like
 > bowl of spaghetti.    (017)

That is an excellent example.  That project had a very serious
problem in maintaining "interfaces".  But the term I was using
is "messages".  CORBA and SOAP illustrate the differences between
them:    (018)

  1. CORBA was an attempt to support *interfaces* between multiple
     object-oriented languages and systems.  In theory, a program
     in one O-O language, such as Java could invoke the methods of
     objects in another O-O language such as C++, and the CORBA
     system would do all the necessary conversions between the two.    (019)

     In practice, supporting the conversions was a nightmare.
     Each system made assumptions about the objects and methods
     of the other, including their names and the functions they
     performed.  Preserving complete compatibility meant that
     all conversions between every release and update to every
     *pair* of language and compiler had to be updated.  Nobody
     ever implemented all possible combinations, and those that
     tried to maintain even a subset of combinations over an
     extended period of time faced an N^2 combinatorial explosion.
     (And N was very large, because each version of each C++
     compiler from each vendor had to be treated as a separate
     language.)    (020)

  2. SOAP was a vastly simpler approach that never exposed the
     interfaces of any program.  Instead, it was a system for
     defining message formats, which independently developed
     systems would interpret by their own choice of languages
     and tools.  Since all messages were in plain text (ASCII
     or the UNICODE superset), no conversions were performed
     by the SOAP system, and any program of any system could
     be written in any language and be updated independently
     of any other program.    (021)

IB> That particular project looks likely to go down an SOA approach.
 > Common services will be specified where possible, and service
 > wrappers developed for each of the legacy apps. This means only
 > 400 wrappers need be developed to replace the current stock of 1500
 > or so point-to-point interfaces. To do this requires top-down
 > governance of services and data standards.    (022)

They're doing exactly what I recommended:  focus on the messages,
and define an ontology for the message formats and content.    (023)

Any internal formats, interfaces, or definitions that do not
affect the message content never need to be exposed to other
systems.    (024)

John    (025)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (026)

<Prev in Thread] Current Thread [Next in Thread>