Jim, I strongly agree with your points. I'd add a few more
comments and qualifications, but I'm traveling now and short on
time. John --------------------------------------------------------------------------
> 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> > > > -----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 > > Jim, > >
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. > >
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. > > The
first point I'd make is that one of the most pernicious > slogans
is the following: > > Tractability = Polynomial
time = Good. > > 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. >
> 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. > > 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. > > 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? > > 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: > > 1. The workshop had
only a single track, but the talks clustered > in three
disjoint mini-workshops: Prog. languages, DB, and AI. > > 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. > > 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). > > 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. > > Bottom line:
Focus on message processing, not on merging KBs. > >
John
_________________________________________________________________
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 (01)
|