 |
 |
> I don't care a whole lot whether I use this indexer, that indexer, or > the other indexer as long as I can make sure I have an SRU, OpenURL, > Z39.50, etc. interface to the index. This will always allow me to > swap out the an older indexer for a new one as they become available. I am so behind in e-mail that I might be treading on ground that is worn out on this, but I would add to Eric's list that I don't care about the indexer if: * the indexer has an open and configurable relevancy weighting algorithm * the indexer allows control of how the data is normalized * the indexer uses pluggable parsers * the indexer supports very fast retrieval then, on the preferred side: * the indexer allows the index process to effectively leverage commodity hardware * the indexer creates an index that can be combined with others It is on this last point that I think lucene is so compelling, though it fares well on all of these. One of our most common comments when we do surveys of our user community is "don't show me what you can't deliver NOW". A world class indexer opens the door for scoping at the collection level, there doesn't have to be one solution for IR and it would be a very unhealthy ecosystem without variance, but I suspect it would be easier to convince a company like Elsevier that I want a lucene index for licensed content than almost any other technology offering. So a definite "yes" to SRU, OpenURL, Z39.50, and the rest, but I wonder if sustaining a lucene index is a good idea regardless of what the main building blocks for a library's preferred IR layer turn out to be. Library standards don't tend to delve into the architecture of indexing anyway, but this is really where a lot of what can be delivered gets defined. art