home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8762 < prev    next >
Encoding:
Text File  |  1993-01-02  |  2.9 KB  |  63 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!noc.near.net!mv!jlc!john
  3. From: john@jlc.mv.com (John Leslie)
  4. Subject: Content-Based Retrieval
  5. Message-ID: <1993Jan02.163830.8973@jlc.mv.com>
  6. Organization: John Leslie Consulting, Milford NH
  7. References: <18774@mindlink.bc.ca> <1993Jan1.021012.24215@news.arc.nasa.gov> <1993Jan1.182624.2993@uunet!tellab5!odgate>
  8. Date: Sat, 02 Jan 1993 16:38:30 GMT
  9. Lines: 52
  10.  
  11. mike@uunet!tellab5!odgate (Mike J. Kelly) writes:
  12. >
  13. > As far as I know, no one has yet integrated content-based retrieval (CBR)
  14. > with BLOBs and large text fields, which is what you really want...
  15. >
  16. > It might be interesting to the vendors who are reading this group if we
  17. > were to start a thread on what a CBR-BLOB capability would look like.
  18.  
  19.    I second the motion.  Of course, right at the start we have a problem.
  20. CBR-BLOB is an oxymoron.  A Binary Large OBject does not *have* contents
  21. interpretable by the database engine -- interpretation, by definition, is
  22. up to the application code.
  23.  
  24.    Nonetheless, it is clear that people *are* going to store ASCII text
  25. in BLOBs.  There are straightforward things we can do with arbitrary
  26. ASCII text; and we could design the engine to degrade gracefully if it's
  27. asked to do these to non-ASCII BLOBs.
  28.  
  29. > The way I conceive it, at its simplest, it would involve a new type of index
  30. > ("create text index"?) which would set up a varchar or BLOB column to be
  31. > retrieved via CBR operators, along with some new CBR operators (at least
  32. > contains, and probably more sophisticated stuff than that.)
  33.  
  34.    Text-indexing a BLOB should create a (variable-length) index capable
  35. of being searched more efficiently to yield a large subset of the answers
  36. to possible inquiries under the CBR expression parser.  Whether the BLOB
  37. itself needs to be accessed to determine the final retrieval list seems
  38. to me an implementation detail.
  39.  
  40.    Open Question:  In a client-server environment, is it acceptable for
  41. the server to pass the *entire* CBR index to a client in order to perform
  42. the CBR operation?
  43.  
  44.    The generally accepted operators are "contains" / "does not contain"
  45. and "starts with" / "ends with".  I would think we should add multiple-
  46. operand cases for "and" / "or" / "precedes" and "follows".  For long
  47. text, usually there is a "within" <N> "words" / "lines" (etc.) clause
  48. for multiple-operand searches.
  49.  
  50.    Open Question:  What is a reasonable limit to number of operands and
  51. nesting depth?
  52.  
  53.    In practice, other fields are created to save disambiguating information
  54. which is not easily generated from the text.  At user-level, we will need
  55. expressions which cover multiple fields of the same record.
  56.  
  57.    Food for Thought:  As text gets larger, formatting becomes more and
  58. more important.  Can we remotely hope for a definition of "rich text"
  59. which clearly-enough distinguishes formatting information so that the
  60. database engine can ignore it in generating the CBR index?
  61.  
  62. John Leslie <john@jlc.mv.com>
  63.