 |
 |
Peter, Use an search engine and create an aggregated database/index of all the > material from the organization, or use a federated search system to > search the repositories/catalogs/databases/etc. in real time? Did you > consider both? And why the choice you made? I was not involved in the initial planning. I came in sort of halfway through and had to make a lot of the initial planning decisions work. (Even while I disagreed with some of those decisions.) Again, my perspective relates mostly to use of catalog data. However, I would add that we did in fact have a federated search tool when I came but quickly discarded it because it couldn't do the more limited functionality we were hoping for it to accomplish (present best options to users for where to search among our databases and collections according to subject), let alone aggregate or search across disparate data repositories. Personally I find it very difficult to believe that a federated search such as what you provide at MuseGlobal can do this sort of enterprise combination of data well. The data is not well structured (except for catalog data) and includes an extreme range of completeness and little commonality. What is interesting to note, however, is that on the one hand, a vendor such as yourself may claim that you can do this sort of stuff well (I'm not saying you said that, just that you might say that). On the other hand I find it interesting to note that the enterprise search tool vendor we have, coming from a completely different market and perspective, would readily claim they can do "all that library stuff" -- that they do in fact offer true federated search. Which in my personal opinion isn't true at all. But ideally I would answer your question in this way. I think there should be a combination of the two approaches, that this would be more practical and workable than just one or the other. How's that for sitting on the fence :-) > Build vs. Buy? It obviously has taken Steve and his colleagues a lot of > hard work to produce a nice looking system (except for all those big > black bits on the screen!) and it obviously takes maintenance (it is > 'fragile') Do you think it was/is worth it and if so why? My answer is, it is too soon to tell. There are many reasons why our implementation is probably unique (and I don't mean to imply that it is better than someone else's, just that I doubt it could readily be replicated elsewhere). We have a number of very different requirements and use cases than what some other library settings might have. We have a large number of constraints on the IT side. We have had to do a lot of custom stuff as a result. This is probably why it is fragile, more than because of deficiencies in any one piece such as the search tool itself. But we are still, in my view, only at the very early stages of assessing the whole package's value for our users. And we have very particular, demanding users. In sum, we have had to buy AND build and so it isn't, again, a question of one versus the other. Steve