Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
intertwingle [2008-11-15 17:56] – 81.188.78.24 | intertwingle [2009-12-14 10:20] (current) – nik | ||
---|---|---|---|
Line 5: | Line 5: | ||
====vast volumes of email==== | ====vast volumes of email==== | ||
- | May 18th | + | May 18th (1998) |
Submitted by Jamie Zawinski to Miscellaneous. | Submitted by Jamie Zawinski to Miscellaneous. | ||
- | " | + | " |
In the following, I outline a potential project to make it easier to deal with a massive volume of personal messages: excavating, traversing, relating, reporting, annotating. | In the following, I outline a potential project to make it easier to deal with a massive volume of personal messages: excavating, traversing, relating, reporting, annotating. | ||
Line 114: | Line 114: | ||
The basic components of this system are: | The basic components of this system are: | ||
- | ====1. parser.==== | + | ===1. parser.=== |
The module which reads the existing message store (directories of BSD mbox files, or news spool directories, | The module which reads the existing message store (directories of BSD mbox files, or news spool directories, | ||
Line 199: | Line 199: | ||
- | ==== 2. database.==== | + | === 2. database.=== |
The module which stores the output of the parser on disk in some quickly-retrievable format. It needs to have both relational and full-text-indexing properties; many of the searches we want to do could be accomplished with a database that was nothing but a glorified set of hash tables; but body searches need to be done in some more clever way. (Perhaps simply putting every word in a hash table would be sufficient, but I doubt it.) And more to the point, the text searches have to take advantage of the tagging of the data, so that, for example, constraining a search to be in the subject and not the body actually makes the search go faster instead of slower. | The module which stores the output of the parser on disk in some quickly-retrievable format. It needs to have both relational and full-text-indexing properties; many of the searches we want to do could be accomplished with a database that was nothing but a glorified set of hash tables; but body searches need to be done in some more clever way. (Perhaps simply putting every word in a hash table would be sufficient, but I doubt it.) And more to the point, the text searches have to take advantage of the tagging of the data, so that, for example, constraining a search to be in the subject and not the body actually makes the search go faster instead of slower. | ||
Line 207: | Line 207: | ||
It seems clear that RDF would be the way go go here. | It seems clear that RDF would be the way go go here. | ||
- | ====3. query tool.==== | + | ===3. query tool.=== |
All of the web search engines force the user to type in boolean expressions. Sometimes that's ok, but we should do something better, that lets the user construct expressions with a GUI. | All of the web search engines force the user to type in boolean expressions. Sometimes that's ok, but we should do something better, that lets the user construct expressions with a GUI. | ||
Line 213: | Line 213: | ||
Drawing on the notion that searches are really set operations, perhaps one aspect of the search tool could be drag-and-drop: | Drawing on the notion that searches are really set operations, perhaps one aspect of the search tool could be drag-and-drop: | ||
- | ==== 4. presentation tools.==== | + | === 4. presentation tools.=== |
There are objects, sets of objects, and presentation tools. There is a presentation tool for each kind of object; and one for each kind of object set. | There are objects, sets of objects, and presentation tools. There is a presentation tool for each kind of object; and one for each kind of object set. |