Hi John,
I agree in general with your suggestion to focus on message passing instead
of integrating the information.
In today's thinking about event processing systems, there are message
transducers called mediators that have the job of transforming a request
from one knowledge domain into another. The cleverness of this solution lies
in the ability of a skilled analyst to create such a mediator without having
to alter the source of the message or the intended recipient.
Unfortunately, this solution is not workable in many cases. If the outgoing
message is missing some information that the recipient needs to act on the
message, the mediator may not be able to supply the information out of band.
Exhaustive/expensive testing is needed to verify that a mediator works
before it is placed into service.
Finally, the job of the analyst in this case is roughly equivalent to the
task of integrating corresponding fragments of the two knowledge bases.
Concept maps between the two KBs have to be developed in either case, and
these maps may be very complex. The intellectual analytic task, in my view,
is the same. The difference between using
equivalence/specialization/constraints to link two KBs and developing a
message transform is one of implementation design. The implementation
approach is going to be significant for the particular challenge.
I should have been clearer in my original note that I intended KB
integration to denote the task of figuring out how two KB's logically
overlap and potentially conflict, and not the task of physical or
operational integration.
Our recollections of history coincide very well. The development of the
RDBMS market did not quite happen as Codd expected, but in hindsight, the
development of this market is not surprising to me. The issues raised during
the late 70s and early 80s on the intersection of relational database query
languages, programming languages, and AI have not changed in the last 30
years, but until the technology development of the RDBMS began to provide
less value for the development $ in the last decade, there was no need to
try to open a new facet of the marketplace. Oracle, IBM and the other
players had all of the business they could handle.
BTW, the ongoing struggle between the database folks and the programming
language folks is very much alive and well 30 years later. The database
people, looking for ease of development, better reuse of data, and better
performance continue to push into the programming language space. The
programming language people continue to try to develop database technology
according to their vision (RDF stores being one of the recent instances of
this). <rant> It continues to amaze me that in three decades, these groups
have not seen the value of working together.</rant> (01)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Monday, January 04, 2010 7:56 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Theoretical issues and practical applications (02)
Jim, (03)
Those are very good questions. As a general comment, I would say
that there is no one-size-fits-all solution. And *every* simple
slogan should be considered highly suspect. (04)
JR> ... this discussion has yet to grapple with the practical
> problems arising from the notion that the web will allow us
> to integrate lots of knowledge bases to achieve a larger scope
> of understanding than would result from any single project.
> The intractability of formal reasoning poses a real threat
> for this situation. (05)
The first point I'd make is that one of the most pernicious
slogans is the following: (06)
Tractability = Polynomial time = Good. (07)
When you're talking about billions of data items, any polynomial
with an exponent greater than 1 is a disaster. A billion squared
is a quintillion. And if you could process each data item in
one microsecond, a quintillion microseconds is greater than
the age of the universe. (08)
For the web, you need logarithmic, linear, or at worst (N log N)
algorithms. That's for the data. But if you can extract some
subset of the data by those kinds of algorithms, then you can
take more time for the items of interest. (09)
As an example, Experian -- one of the three major credit bureaus
that evaluates everybody's credit rating -- uses Prolog. In fact,
they use Prolog so heavily that they bought Prologia, the company
that was founded by Alain Colmerauer, who implemented the first
Prolog interpreter. They keep their algorithms secret, but I
would guess that they process the raw data in linear time and
extract smaller numbers of items of interest for more detailed
processing by more complex reasoning methods. (010)
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? (011)
I'm sure that you remember the work on database schemas from the
'70s and '80s. In 1980, there was a workshop that brought together
three groups: programming language researchers, database researchers,
and AI researchers. Among the participants were Ted Codd, Pat Hayes,
Jaime Carbonell, Ray Reiter, and quite a few others including me.
From the dusty copy of the proceedings in my basement, I would
draw two sobering observations: (012)
1. The workshop had only a single track, but the talks clustered
in three disjoint mini-workshops: Prog. languages, DB, and AI. (013)
2. 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. (014)
To answer your question about when we can expect to merge independent
knowledge bases, I suspect that the answer is never. 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. But banks have been interoperating
successfully since the Italian Renaissance by passing messages
(either paper or electronic). (015)
People also interoperate by passing messages. Except for the
rather rare Vulcan mind-melds, they never merge their knowledge
bases. I doubt that computerized KBs will be merged any more
easily than banks or people. (016)
Bottom line: Focus on message processing, not on merging KBs. (017)
John (018)
_________________________________________________________________
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 (019)
_________________________________________________________________
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 (020)
|