Date: Fri, 27 Oct 2000 15:46:12 -0400
| From: | Paul Fernhout |
|
pdfernhout@kurtz-fernhout.com Reply-To: unrev-II@egroups.com Organization: Kurtz-Fernhout Software |
| To: | unrev-II@egroups.com |
| Subject: |
Rod- In regard to: An example would be if your email system automatically categorizes emails for you based on content and word frequency. (IBM's doing some cutting edge work on this by the way.) Every once in a while you might review some of the categorizations and correct them. For example, the system might put all your email from this mailing list under UnrevII but you might want some but not all of it to also be categorized under "Knowledge Management". The "error" here is a miscategorization base on your wishes, which you may not have made clear to the system, or which the system algorithms may not be quite able to handle 100%. Another example might be that you realize there are two Doug Engelbart's sending you email but they are categorized together -- you go in to the system and review all the correspondence and split them apart (perhaps using tools that help you differentiate based on email address) and then build a way to always keep them separate. Or likewise, you get email both from an "Rod Welch" and "Welchco" and you decide you want them categorized together. Another issue might be merging two knowledgebases, you might need to review concepts which don't match up and decide which are similar or different (assuming the system was 99% accurate but there were thousands of concepts). I've seen these sorts of things with database in a textual sense when importing data. This isn't the same situation, but often when importing data you may need to review it and modify it slightly first (fix up spellings or missing entries) to import it into a database. Probably the best example I can think of is that you run some badly written piece of code (or code with assumptions or prerequisites your system does not adhere to) and it adds bad or incomplete data to your database. You then add some good data you don't want to loose, so rollback isn't easy. You might then need to go in by hand and find and fix the bad data based on an understanding of the code and what it did wrong. That wouldn't be easy to automate. Finally -- your database suffers physical (disk) corruption but you want to save what you can. A person might go in and see what is salvageable and direct various tools to recover parts of the data. Obviously, to the extent any of these situations become common, one might develop specific tools and procedures to make these easier to do, or performed more automatically with a minimum of understanding needed of the system architecture. Most of these "error" situations revolve around automatic procedures which only worked partially to begin with (where 99.99% success may still leave work to do), or changing needs or perceptions not planned for originally might require restructuring to how things are stored and careful attention paid to prevent loss or misplacement of data. It's analogous to work on a car. I can put gas in the tank, put air in the tires, change the wiper blades, and maybe notice that soemthing sounds wrong, but for some major repair (replacing a failed alternator) or preventive maintainence (replacing the brakes), the mechanic has the tools and experience to do the job faster with more surety than I could. That's not to say a lot of people don't work on their own cars -- just that there is still a demand for mechanics. It isn't cost effective or practical with current technology to make cars that run for a thousand years without any maintainence -- although some of today's cars can go 100K+ miles without a tune up. Of course, with a mechanic, there isn't as big a privacy issue as letting a DBA poke around your confidential database...
Kurtz-Fernhout Software
Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com
|