|
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)
|