[Top] [All Lists]

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

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: sowa@xxxxxxxxxxx
Date: Thu, 7 Jan 2010 12:19:19 -0500 (EST)
Message-id: <d36a9b0d5f025608f18ed53f97e4dd34.squirrel@xxxxxxxxxxxxxxxxxxxx>


I strongly agree  with your points.  I'd add a few more comments and qualifications, but I'm traveling now and short on time.



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

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