From: ted.dunning@gmail.com   
      
   Your summary was reasonably good, but I would add another observation   
   that there are very, very few real-world examples of projects that use   
   knowledge-bases on an ongoing basis.  I know that I can't think of a   
   single example that really uses one.   
      
   For example, for many years (and possibly ongoing), a major bank based   
   their fraud detection system on a collection of rules that were   
   evaluated and then the many, many rule outputs were weighted   
   statistically to determine whether there was an instance of fraud.   
   This wasn't so much of a knowledge-base as a collection of simple   
   feature extractors.  It may have been envisioned as a knowledge base in   
   the beginning, but the ultimate result was nothing like a KB.   
      
   Another major fraud detection system works with much simpler feature   
   detectors weighted by a trained model and then the output is processed   
   using a set of business rules.  These rules include constraints on how   
   often a customer can be called about possible fraud and what methods   
   the contacts should use and under what condition and types of   
   transactions might be refused or require further ID (you can't ask for   
   a driver's license on a web transaction, for instance).  This rule set   
   might generously be called a knowledge base, but it really is just a   
   pretty traditional kind of business logic layer.   
      
   In another example, I was involved in evaluating a call center   
   situation where the call center employees were supposed to be   
   supporting a large number of client banks who were using the processing   
   services of the call center owner.  They had a knowledge base that   
   contained their operating documentation and problem resolution plans.   
   This knowledge base was supported by a team of 7 knowledge engineers   
   who worked full-time on maintaining the state of the system.   
      
   Unfortunately, the content changed so quickly that by the time the   
   knowledge engineers managed to update the knowledge base with one, the   
   content had changed sufficiently to make the system useless.  We   
   installed a decent text retrieval system (updated several times per   
   day) and demonstrated massive savings as well as increased   
   effectiveness.  The customer canned the "knowledge base" effort and   
   team.   
      
   So perhaps it would be correct to say that databases are something   
   people find useful while knowledge-bases are not.  My experience is not   
   universal, but I would suspect that knowledge engineering is just not a   
   task that is easy enough to do.  The result is that any benefits are   
   either completely obscured by lack of currency or over-whelmed by the   
   cost of maintaining the system.   
      
   The only (partial) counter-example that I can think of is the meta-data   
   about music that is maintained by companies like Muze or AMG.  These   
   folk encode the title, artist and track names for CD's and they write   
   bios, reviews and liner notes that you will find on systems like iTunes   
   or Musicmatch.  This is the exception that proves the rule, however,   
   over time, the "knowledge" in the system has been encoded more and more   
   in plain english rather than as conceptual links.   
      
   [ comp.ai is moderated.  To submit, just post and be patient, or if ]   
   [ that fails mail your article to , and ]   
   [ ask your news administrator to fix the problems with your system. ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)