Cart
[Home] [By Thread] [By Date] [Recent Entries]
Ok. If you have a schema, you have the description of the paths although combinatorial explosion can still occur, but since all you are doing is using it to create a GUI, that's fine. It spits out a path(s) based on your selections. You want the document indices. Indexing the documents is a different job and, although I'm no expert, indexing XML documents for optimized searching is still a dark art. Hopefully given XQuery and Extreme Markup and XML 2005, we'll see more papers soon. Given all the work being done with XML databases, that's a certainty. So the problem remains indexing the text nodes and if you are really ambitious, the contents of the notations (eg, index a photo by its contents). Work on that last bit is getting a lot of attention these days because otherwise, systems such as are going into transportation, ports, hospitals, etc, aren't as useful. We do that here (Video Analyst). DeRose makes me humble. He is much smarter than me and a much better skater. He is also quite generous with his knowledge given proper respect. Anyone that can make heads hurt on this list deserves it. His papers on these topics from the late 80s are seminal. len From: Robert Koberg [mailto:rob@k...] Bullard, Claude L (Len) wrote: > Loading all of that from all of the docs is like searching > all of the available tables to get that info. Doable but > not for the faint of resources. Add full-text to that and it > becomes a job for Google farms. How well would Google > work if they weren't cacheing the web? I guess this is my point. If you indexed your tables with Lucene and searched on *that* index you would use much less resources and it would be much faster. But I was talking about XML, which if search required bringing everything into DOMs, it would be much slower and much more resource intensive than a RDB. As for Steve DeRose's stuff -- my brain hurts from reading it...
|
