Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!rutgers!umn-d-ub!cs.umn.edu!sctc.com!endrizzi From: endrizzi@sctc.com (Michael Endrizzi ) Newsgroups: comp.databases Subject: Re: >Fault-tolerant Information Recall Message-ID: <1990Apr13.185717.10004@sctc.com> Date: 13 Apr 90 18:57:17 GMT References: <1990Apr3.200220.9513@sctc.com> Distribution: comp.databases Organization: Secure Computing Technology Corporation Lines: 55 hargrove@bee.corp.sgi.com (Mark Hargrove) writes: >As a matter of fact, yes, I would (and do) find such a spelling checker >useful. That doesn't imply that that I wouldn't find one that made >suggestions useful as well. Well ok, but you slipped out of my trap. If you were using a spelling checker that only located errors, wouldn't it be nice to have it also suggest alternatives? Currently databases only allow you to search for "perfect" information. Wouldn't it be nice to have it also suggest alternatives if the data and/or query was imperfect?? Not revolutionary, just nice. >Maybe I missed something earlier. Just what the heck *is* your model >anyway? Are you offering a extension to a query language (like SQL) >that will return "matches" that are "close" in the same sense that a >spelling checker suggests "close" words? Or are you offering a extension >that would return "Palo Alto", when I searched on CITY_NAME="Menlo Park"? Bango!!! I think you've got it. *Our* model is fault tolerant in the syntatic sense, not semantic. Semantics are a TOUGH problem and current solutions to semantic interpretations are skimpy and require much manual interpretation and classification. *Our* model has no mandatory extensions to the SQL. The only parameters to adjust are the ones that relax or restrict the strictness of the search process (how close is "close" when performing comparisions). The user does not have to format search strings like in regexp(). >I'm sorry, but I guess I'm too dumb to understand what this means. How >do you decide *which* records to retrieve? What is your approximation >function? I simply don't believe you can define a general function which >will do "approximate" matching, UNLESS YOU'RE ONLY WORRYING ABOUT SPELLING >DIFFERENCES. Is this all your "system" does? If so, it's still a step >forward in retrieval problems, but not particularly revolutionary. Don't feel bad. Took me a while to understand defintions of recall, precision and retrieval rates too. Like I said all along, only syntatic matches. I never said it was revolutionary. What is impressive about it is how accurate the search process is and that we can search on complex SQL like SELECT WHERE (car="Krysler") and (make="Reeeliant") or (car="Tayoto") and (make="Comry") JOIN.... INTERESECT... SUBTRACT... etc... THanks again for answering... Dreez