ontolog-forum
[Top] [All Lists]

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

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Jim Rhyne" <jrr@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 4 Jan 2010 08:10:17 -0800
Message-id: <011901ca8d58$69e25700$3da70500$@com>
Hi John,
I'm happy also. But, IMHO, 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.
In software, we have not yet succeeded in eliminating this threat. The two
approaches most commonly used are: central control of design and analysis,
and extensive testing. The first of these is also a testing regimen, but
done on design rather than implementation.
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?
Thanks, Jim    (01)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Wednesday, December 30, 2009 8:06 AM
To: [ontolog-forum]
Subject: [ontolog-forum] Theoretical issues and practical applications    (02)

Chris and Len,    (03)

I'm happy to hear people discussing concrete issues that have
actually impinged on practical applications.  I changed the
subject line from the more cryptic "blogic iswc".    (04)

CP>> I assume it is a relatively un-contentious point that most
 >> business system building practitioners would be surprised to hear
 >> that (logical) intractability is anything other than a theoretical
 >> problem when building systems.    (05)

That is indeed true.  Every major programming language is capable of
expressing undecidable and intractable algorithms, and *nobody* is
asking for less expressive languages.    (06)

LY> ... but as a practitioner would like to add that even long periods
 > of not recognizing the term or the theoretical problem does not
 > always make it not a genuine category of problem.    (07)

That is also true.  Many practitioners have learned the hard way that
many of their projects have been failures.  However, the reasons for
their failures have ranged all over the lot:  poor human factors,
bad economics, poor choice of algorithms, incompetent implementers,
or just stupid ideas.  Theoretical issues have occasionally been
a cause of failure, but the causes are usually more mundane.    (08)

LY> But sooner or later engineering does come to a point where the
 > problem must be dealt with.  And when it does - the entire body
 > of practical acumen can become an obstacle to further progress.    (09)

I agree.  Practitioners rarely understand the theoretical issues,
and theoreticians rarely understand practical applications.  As a
result, we get knee-jerk slogans like "Expressive languages are
undecidable."  But that slogan is extremely misleading:    (010)

  1. Computational complexity is a property of *algorithms*,
     and *not* a property of problems or languages.    (011)

  2. Any given problem can be solved by many different kinds
     of algorithms of varying levels of complexity.    (012)

  3. Some problems, such as the traveling salesman problem, cannot
     be solved exactly by any tractable algorithm.  But many such
     problems can be solved to any desired degree of approximation
     by very efficient algorithms.    (013)

  4. Restricting the expressive power of a language *never* improves
     the efficiency of any computation.  The only thing it does is
     to make certain kinds of problems and algorithms impossible to
     express.    (014)

  5. Finally, *increasing* the expressive power of a language
     (e.g., by moving from integers to real numbers) can often
     allow intractable algorithms to be replaced by highly
     efficient algorithms.    (015)

We can't assume that every practitioner understands all these
fine points, and we can't assume that every theoretician will
understand the problems and issues of practical applications.    (016)

Therefore, we need a balanced collaboration of practitioners and
theoreticians to develop good paradigms and practices.  We need
a "cookbook" written by the chefs, so that novices have a guide
for preparing a decent meal.  In a hurry, we also need frozen
dinners that anyone can pop into the microwave.    (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)

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