Hi Steve,

Thanks for a full reply.

We actually do combine date within enterprises, including from their ILS
and subscription Sources (article databases), and internal repositories.
"Of course" we claim we do it well - and I think we do. A library
background will enable you to face almost any shape of data with aplomb,
if not equanimity.

Data from varied sources is varied in structure, type of content and
level of detail, as you say. It *is* possible to combine it, but it
works best when there is some sort of "commonality" across the sources.
Fortunately most people when searching provide that focus, so the
theoretical problem is very rarely a practical one - and this business
is all about practical solutions. We do actually have a fair number of
the enterprise search engine vendors as partners where we act as a
selective harvesting capability for them and convert the syntax and
semantics of the harvested records into a uniformity they can easily
ingest and work their indexing magic on.

Fence sitting has a long and honourable tradition (both in the UK and
the US), and we 'back both horses' ourselves by being in both the
federated search and content integration space. Thus involved in both
the just-in-case harvesting, and the just-in-time fed searching.

Final thought is that almost everybody we have dealt with is a "special
case" - most of them in the nicest possibly way - so, even for systems
like ours, customization is the order of the day. But that's what
computers allow us to do - adapt to users.

Peter  

> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf
Of
> Steve Oberg
> Sent: Friday, July 11, 2008 12:15 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Enterprise Search and library collection
> [SEC=UNCLASSIFIED]
> 
> 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