Re: [CODE4LIB] Enterprise Search and library collection [SEC=UNCLASSIFIED]

[Peter Noerr]

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:[EMAIL PROTECTED] On Behalf
Of
> Steve Oberg
> Sent: Friday, July 11, 2008 12:15 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> 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 

Re: [CODE4LIB] Enterprise Search and library collection

[Genny Engel]

I did not have stellar results experimenting with a similar approach to
Eric's.  The crawler we use is from Thunderstone, and it does a fine job
of indexing web content with very nice relevancy ranking and "did you
mean" spell-check.  What I found when trying to let it loose against
multiple servers is, when it hits our OPAC, it sees several different
formats per record and ends up more than triple-indexing each title.  It
does have a lot of flexibility in the indexing options, though, so I
could try it again and set it to ignore URL patterns that refer to the
MARC display, etc.  Still, the total cost to index a couple million
pages (which would be needed in order to include all the records in the
OPAC plus the website pages plus the Syndetics added content) is a bit
of a steep one-time outlay.  I'm sure there's some other way to go about
this with Thunderstone's TEXIS rather than using their Webinator
product, but then you have a substantially higher development effort, I
think.  

Thunderstone now makes a faceted search (they call it parametric
search).  They also make search appliances at different capacity levels.
 Pricing is really pretty reasonable for what you get.
http://www.thunderstone.com/texis/site/pages/Products.html
 
 
 
Genny Engel
Internet Librarian
Sonoma County Library
[EMAIL PROTECTED]
707 545-0831 x581
www.sonomalibrary.org
 


>>> [EMAIL PROTECTED] 07/11/08 07:36AM >>>
> In short, I think a Google Appliance is an expensive but viable
option.
Relative to other commercial products in the space, the GA or G-mini
is
actually very inexpensive.  Another option to add to Eric's list is
the
All Access Connector which adds MuseGlobal's fed search technology to
the Google appliance.  Of course, it also add $40K or more to the
total
price.
http://wire.jstirnaman.com/2008/05/23/federated-search-for-google-search-appliance/


Jason
-- 

Jason Stirnaman
Digital Projects Librarian/School of Medicine Support
A.R. Dykes Library, University of Kansas Medical Center
[EMAIL PROTECTED] 
913-588-7319


>>> On 7/10/2008 at 10:25 PM, in message
<[EMAIL PROTECTED]>, Eric Lease Morgan
<[EMAIL PROTECTED]> wrote:
> At the risk of interpreting the original question incorrectly, we  
> have had decent success using the Google Search Appliance to  
> facilitate search across the enterprise (university):
> 
>* Buy the Appliance.
>* Feed it one or more URLs.
>* Wait for it to crawl.
>* Customize the user interface.
>* Allow people to use it.
> 
> While we haven't done so, it would not be too difficult to implement


> a sort of federated search within the Appliance's interface. This  
> could be done in a number of ways:
> 
>1. Acquire bibliographic data and
>   feed to directly to the Appliance
>   via the (poorly) documented SQL
>   interface.
> 
>2. Acquire bibliographic data, save
>   it as HTML files, and allow the
>   Appliance to crawl the HTML.
> 
>3. License access to bibliographic
>   making sure it is accessible through
>   some sort of API, and write a Google
>   OneBox module that queries the data,
>   and returns results as a part of a
>   normal Google Appliance search.
> 
> The larger Google Appliance costs about $30,000 but you purchase it,


> not license it. No annual fees. That will buy you the ability to  
> index 500,000 documents. When it comes to a bibliographic database  
> (such as a subject index or a library catalog) that is not really  
> very much.
> 
> We here at Notre Dame did implement Option #3, but it queries the  
> local LDAP sever to return names and addresses of people, not  
> bibliographic citations. [1, 2] I did write a OneBox module to query


> our catalog, but we haven't implemented it, yet. It will probably  
> appear as a part of the library's Search This Site functionality.
> 
> In short, I think a Google Appliance is an expensive but viable
option.
> 
> [1] Search for a name (ex: Hesburgh) at http://search.nd.edu/ 
> [2] OneBox source code - http://tinyurl.com/6ktxot 

Re: [CODE4LIB] Enterprise Search and library collection [SEC=UNCLASSIFIED]

[Steve Oberg]

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

Re: [CODE4LIB] Enterprise Search and library collection

[Jason Stirnaman]

> In short, I think a Google Appliance is an expensive but viable
option.
Relative to other commercial products in the space, the GA or G-mini is
actually very inexpensive.  Another option to add to Eric's list is the
All Access Connector which adds MuseGlobal's fed search technology to
the Google appliance.  Of course, it also add $40K or more to the total
price.
http://wire.jstirnaman.com/2008/05/23/federated-search-for-google-search-appliance/

Jason
-- 

Jason Stirnaman
Digital Projects Librarian/School of Medicine Support
A.R. Dykes Library, University of Kansas Medical Center
[EMAIL PROTECTED]
913-588-7319


>>> On 7/10/2008 at 10:25 PM, in message
<[EMAIL PROTECTED]>, Eric Lease Morgan
<[EMAIL PROTECTED]> wrote:
> At the risk of interpreting the original question incorrectly, we  
> have had decent success using the Google Search Appliance to  
> facilitate search across the enterprise (university):
> 
>* Buy the Appliance.
>* Feed it one or more URLs.
>* Wait for it to crawl.
>* Customize the user interface.
>* Allow people to use it.
> 
> While we haven't done so, it would not be too difficult to implement 

> a sort of federated search within the Appliance's interface. This  
> could be done in a number of ways:
> 
>1. Acquire bibliographic data and
>   feed to directly to the Appliance
>   via the (poorly) documented SQL
>   interface.
> 
>2. Acquire bibliographic data, save
>   it as HTML files, and allow the
>   Appliance to crawl the HTML.
> 
>3. License access to bibliographic
>   making sure it is accessible through
>   some sort of API, and write a Google
>   OneBox module that queries the data,
>   and returns results as a part of a
>   normal Google Appliance search.
> 
> The larger Google Appliance costs about $30,000 but you purchase it, 

> not license it. No annual fees. That will buy you the ability to  
> index 500,000 documents. When it comes to a bibliographic database  
> (such as a subject index or a library catalog) that is not really  
> very much.
> 
> We here at Notre Dame did implement Option #3, but it queries the  
> local LDAP sever to return names and addresses of people, not  
> bibliographic citations. [1, 2] I did write a OneBox module to query 

> our catalog, but we haven't implemented it, yet. It will probably  
> appear as a part of the library's Search This Site functionality.
> 
> In short, I think a Google Appliance is an expensive but viable
option.
> 
> [1] Search for a name (ex: Hesburgh) at http://search.nd.edu/ 
> [2] OneBox source code - http://tinyurl.com/6ktxot

Re: [CODE4LIB] Enterprise Search and library collection

[Eric Lease Morgan]

At the risk of interpreting the original question incorrectly, we  
have had decent success using the Google Search Appliance to  
facilitate search across the enterprise (university):


  * Buy the Appliance.
  * Feed it one or more URLs.
  * Wait for it to crawl.
  * Customize the user interface.
  * Allow people to use it.

While we haven't done so, it would not be too difficult to implement  
a sort of federated search within the Appliance's interface. This  
could be done in a number of ways:


  1. Acquire bibliographic data and
 feed to directly to the Appliance
 via the (poorly) documented SQL
 interface.

  2. Acquire bibliographic data, save
 it as HTML files, and allow the
 Appliance to crawl the HTML.

  3. License access to bibliographic
 making sure it is accessible through
 some sort of API, and write a Google
 OneBox module that queries the data,
 and returns results as a part of a
 normal Google Appliance search.

The larger Google Appliance costs about $30,000 but you purchase it,  
not license it. No annual fees. That will buy you the ability to  
index 500,000 documents. When it comes to a bibliographic database  
(such as a subject index or a library catalog) that is not really  
very much.


We here at Notre Dame did implement Option #3, but it queries the  
local LDAP sever to return names and addresses of people, not  
bibliographic citations. [1, 2] I did write a OneBox module to query  
our catalog, but we haven't implemented it, yet. It will probably  
appear as a part of the library's Search This Site functionality.


In short, I think a Google Appliance is an expensive but viable option.

[1] Search for a name (ex: Hesburgh) at http://search.nd.edu/
[2] OneBox source code - http://tinyurl.com/6ktxot

--
Eric Lease Morgan
Hesburgh Libraries, University of Notre Dame

Re: [CODE4LIB] Enterprise Search and library collection [SEC=UNCLASSIFIED]

[Dyer, Renata]

Hi Peter,
Thanks for your input.

As far as my organisation goes we have not made any commitments yet. At
this stage we are just investigating what would be a better option for
us.
Coming form  the library background I thought it would be beneficial for
library to embed (read: market) our products and services into internal
resources via enterprise search. That may or may not be a good way to go
about it. I know that some librarians would rather have their own
federated search available on library pages that only covers aggregator
databases plus maybe a catalogue thus making that search separate to
whatever else organisation may want to cover with any other searches.

That is why I wanted to get feedback from other libraries to see if
anyone went down this road - why did they do it and is it working for
them.

Besides making this choice it would also be good to know how easy it
would be to  implement and/or utilise either a live search or a search
engine. As you said, it is obvious Steve and his team put a lots of work
in this.  Build vs. buy usually evolves around do you have sufficient
resources or not. 

It would be good to hear from other libraries even if it's only to share
what kind of search they utilise, why and are they happy with it.

Regards
Renata Dyer 

-Original Message-
From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf Of
Peter Noerr
Sent: Friday, 11 July 2008 11:09 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Enterprise Search and library collection
[SEC=UNCLASSIFIED]

Hi Steve and Renata,

First the declaration of interest: I am the CTO of a federated search
system company. However I am not trying to suggest you should use our
(or any) federated search system (so I will, coyly, not attach a
signature to this email).

I am interested in your comments on either or both of two questions:

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?

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?

Peter Noerr

> -Original Message-
> From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf
Of
> Steve Oberg
> Sent: Thursday, July 10, 2008 8:21 AM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Enterprise Search and library collection 
> [SEC=UNCLASSIFIED]
> 
> Renata and others,
> 
> After posting my original reply I realized how dumb it was to respond 
> but say, sorry, can't tell you more.  As an aside, this is one of the 
> things that irritates me the most about working in a for profit 
> environment:
> the
> control exerted by MPOW over just about anything. But hey, this is the

> job situation I've consciously chosen so, I guess I shouldn't 
> complain.
> 
> Although I can't name names and go into detail about our 
> implementation, I have "anonymized" screenshots of various aspects of 
> it and posted details about it at
> http://familymanlibrarian.com/2007/01/21/more-on-turning-the-catalog-
> inside-out/
> Keep in mind that my involvement has been focused on the catalog side.
> A
> lot of the behind-the-scenes work also dealt with matching subject 
> terms in catalog records to the much simpler taxonomy chosen for our 
> website.
> You
> can imagine that it can be quite complicated to set up a good rule set

> for matching LCSH or MeSH terms effectively to a more generic set of 
> taxonomy terms and have those be meaningful to end users. We are 
> continually evaluating and tweaking this setup.
> 
> As far as other general details, this implementation involved a lot of

> people, in fact a team of about 15, some more directly and exclusively

> and others peripherally.  In terms of maintenance, day to day 
> maintenance is handled by about three FTE.  Our library catalog data 
> is refreshed
once
> a
> day, as is the citation database to which I referred in the previous 
> email, and content from our web content management environment.  A few

> other repositories are updated weekly because their content isn't as 
> volatile.
> The whole planning and implementation process took a year and is still

> really working through implementation issues. For example we recently 
> upgraded the version of our enterprise search tool to a newer version 
> and this was a major change requiring a lot of resources and it took a

> lot more time to do than expected.
> 
> I hope this additional information is helpful.
> 
> Stev

Re: [CODE4LIB] Enterprise Search and library collection [SEC=UNCLASSIFIED]

[Peter Noerr]

Hi Steve and Renata,

First the declaration of interest: I am the CTO of a federated search
system company. However I am not trying to suggest you should use our
(or any) federated search system (so I will, coyly, not attach a
signature to this email).

I am interested in your comments on either or both of two questions:

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?

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?

Peter Noerr

> -Original Message-
> From: Code for Libraries [mailto:[EMAIL PROTECTED] On Behalf
Of
> Steve Oberg
> Sent: Thursday, July 10, 2008 8:21 AM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Enterprise Search and library collection
> [SEC=UNCLASSIFIED]
> 
> Renata and others,
> 
> After posting my original reply I realized how dumb it was to respond
> but
> say, sorry, can't tell you more.  As an aside, this is one of the
> things
> that irritates me the most about working in a for profit environment:
> the
> control exerted by MPOW over just about anything. But hey, this is the
> job
> situation I've consciously chosen so, I guess I shouldn't complain.
> 
> Although I can't name names and go into detail about our
> implementation, I
> have "anonymized" screenshots of various aspects of it and posted
> details
> about it at
> http://familymanlibrarian.com/2007/01/21/more-on-turning-the-catalog-
> inside-out/
> Keep in mind that my involvement has been focused on the catalog side.
> A
> lot of the behind-the-scenes work also dealt with matching subject
> terms in
> catalog records to the much simpler taxonomy chosen for our website.
> You
> can imagine that it can be quite complicated to set up a good rule set
> for
> matching LCSH or MeSH terms effectively to a more generic set of
> taxonomy
> terms and have those be meaningful to end users. We are continually
> evaluating and tweaking this setup.
> 
> As far as other general details, this implementation involved a lot of
> people, in fact a team of about 15, some more directly and exclusively
> and
> others peripherally.  In terms of maintenance, day to day maintenance
> is
> handled by about three FTE.  Our library catalog data is refreshed
once
> a
> day, as is the citation database to which I referred in the previous
> email,
> and content from our web content management environment.  A few other
> repositories are updated weekly because their content isn't as
> volatile.
> The whole planning and implementation process took a year and is still
> really working through implementation issues. For example we recently
> upgraded the version of our enterprise search tool to a newer version
> and
> this was a major change requiring a lot of resources and it took a lot
> more
> time to do than expected.
> 
> I hope this additional information is helpful.
> 
> Steve
> 
> On Tue, Jul 8, 2008 at 1:11 AM, Dyer, Renata
> <[EMAIL PROTECTED]>
> wrote:
> 
> > Our organisation is looking into getting an enterprise search and I
> was
> > wondering how many libraries out there have incorporated library
> > collection into a 'federated' search that would retrieve a whole
lot:
> > a library collection items, external sources (websites, databases),
> > internal documents (available on share drives and/or records
> systems),
> > maybe even records from other internal applications, etc.?
> >
> >
> > I would like to hear about your experience and what is good or bad
> about
> > it.
> >
> > Please reply on or offline whichever more convenient.
> >
> > I'll collate answers.
> >
> > Thanks,
> >
> > Renata Dyer
> > Systems Librarian
> > Information Services
> > The Treasury
> > Langton Crescent, Parkes ACT 2600 Australia
> > (p) 02 6263 2736
> > (f) 02 6263 2738
> > (e) [EMAIL PROTECTED]
> >
> > <https://adot.sirsidynix.net.au/uhtbin/cgisirsi/ruzseo2h7g/0/0/49>
> >
> >
> >
> **
> > Please Note: The information contained in this e-mail message
> > and any attached files may be confidential information and
> > may also be the subject of legal professional privilege.  If you are
> > not the intended recipient, any use, disclosure or copying of this
> > e-mail is unauthorised.  If you have received this e-mail by error
> > please notify the sender immediately by reply e-mail and delete all
> > copies of this transmission together with any attachments.
> >
> **
> >

Re: [CODE4LIB] Enterprise Search and library collection [SEC=UNCLASSIFIED]

[Steve Oberg]

Renata and others,

After posting my original reply I realized how dumb it was to respond but
say, sorry, can't tell you more.  As an aside, this is one of the things
that irritates me the most about working in a for profit environment: the
control exerted by MPOW over just about anything. But hey, this is the job
situation I've consciously chosen so, I guess I shouldn't complain.

Although I can't name names and go into detail about our implementation, I
have "anonymized" screenshots of various aspects of it and posted details
about it at
http://familymanlibrarian.com/2007/01/21/more-on-turning-the-catalog-inside-out/
Keep in mind that my involvement has been focused on the catalog side.  A
lot of the behind-the-scenes work also dealt with matching subject terms in
catalog records to the much simpler taxonomy chosen for our website.  You
can imagine that it can be quite complicated to set up a good rule set for
matching LCSH or MeSH terms effectively to a more generic set of taxonomy
terms and have those be meaningful to end users. We are continually
evaluating and tweaking this setup.

As far as other general details, this implementation involved a lot of
people, in fact a team of about 15, some more directly and exclusively and
others peripherally.  In terms of maintenance, day to day maintenance is
handled by about three FTE.  Our library catalog data is refreshed once a
day, as is the citation database to which I referred in the previous email,
and content from our web content management environment.  A few other
repositories are updated weekly because their content isn't as volatile.
The whole planning and implementation process took a year and is still
really working through implementation issues. For example we recently
upgraded the version of our enterprise search tool to a newer version and
this was a major change requiring a lot of resources and it took a lot more
time to do than expected.

I hope this additional information is helpful.

Steve

On Tue, Jul 8, 2008 at 1:11 AM, Dyer, Renata <[EMAIL PROTECTED]>
wrote:

> Our organisation is looking into getting an enterprise search and I was
> wondering how many libraries out there have incorporated library
> collection into a 'federated' search that would retrieve a whole lot:
> a library collection items, external sources (websites, databases),
> internal documents (available on share drives and/or records systems),
> maybe even records from other internal applications, etc.?
>
>
> I would like to hear about your experience and what is good or bad about
> it.
>
> Please reply on or offline whichever more convenient.
>
> I'll collate answers.
>
> Thanks,
>
> Renata Dyer
> Systems Librarian
> Information Services
> The Treasury
> Langton Crescent, Parkes ACT 2600 Australia
> (p) 02 6263 2736
> (f) 02 6263 2738
> (e) [EMAIL PROTECTED]
>
> 
>
>
> **
> Please Note: The information contained in this e-mail message
> and any attached files may be confidential information and
> may also be the subject of legal professional privilege.  If you are
> not the intended recipient, any use, disclosure or copying of this
> e-mail is unauthorised.  If you have received this e-mail by error
> please notify the sender immediately by reply e-mail and delete all
> copies of this transmission together with any attachments.
> **
>

Re: [CODE4LIB] Enterprise Search and library collection [SEC=UNCLASSIFIED]

[Steve Oberg]

Renata,

My library has done exactly this and we are in the second year of our
implementation.  We are using an enterprise search product and incorporating
several disparate data repositories including a very large citation
database, our library catalog, a fileshare, and some other things
(basically, everything you name).  It works but it is quite complicated and
therefore, at times, fragile.  In addition to incorporating several
different repositories, we also use this enterprise search tool to power
dynamic content throughout the site (e.g. list of journals for subject x,
browse by subject, etc.).  I'm purposely not giving specific details of the
tool(s) we use because I'm not allowed to share this information outside of
the company where I work.

Steve

On Tue, Jul 8, 2008 at 9:14 AM, Jason Stirnaman <[EMAIL PROTECTED]> wrote:

> Renata,
>
> We haven't implemented anything yet, but we did recently issue an RFI
> for exactly this and evaluated the vendors who responded.  Our biggest
> challenge is still getting sufficient institutional buy-in.  So, we will
> likely be conducting small, focused pilots with two different vendors.
> I would be happy to share our RFI and some of our evaluation results
> with you off list.
>
> Jason
> --
>
> Jason Stirnaman
> Digital Projects Librarian/School of Medicine Support
> A.R. Dykes Library, University of Kansas Medical Center
> [EMAIL PROTECTED]
> 913-588-7319
>
>
> >>> On 7/8/2008 at 1:11 AM, in message
> <[EMAIL PROTECTED]>,
> "Dyer,
> Renata" <[EMAIL PROTECTED]> wrote:
> > Our organisation is looking into getting an enterprise search and I
> was
> > wondering how many libraries out there have incorporated library
> > collection into a 'federated' search that would retrieve a whole
> lot:
> > a library collection items, external sources (websites, databases),
> > internal documents (available on share drives and/or records
> systems),
> > maybe even records from other internal applications, etc.?
> >
> >
> > I would like to hear about your experience and what is good or bad
> about
> > it.
> >
> > Please reply on or offline whichever more convenient.
> >
> > I'll collate answers.
> >
> > Thanks,
> >
> > Renata Dyer
> > Systems Librarian
> > Information Services
> > The Treasury
> > Langton Crescent, Parkes ACT 2600 Australia
> > (p) 02 6263 2736
> > (f) 02 6263 2738
> > (e) [EMAIL PROTECTED]
> >
> > 
> >
> >
> >
> **
> > Please Note: The information contained in this e-mail message
> > and any attached files may be confidential information and
> > may also be the subject of legal professional privilege.  If you are
> > not the intended recipient, any use, disclosure or copying of this
> > e-mail is unauthorised.  If you have received this e-mail by error
> > please notify the sender immediately by reply e-mail and delete all
> > copies of this transmission together with any attachments.
> >
> **
>

Re: [CODE4LIB] Enterprise Search and library collection [SEC=UNCLASSIFIED]

[Jason Stirnaman]

Renata,

We haven't implemented anything yet, but we did recently issue an RFI
for exactly this and evaluated the vendors who responded.  Our biggest
challenge is still getting sufficient institutional buy-in.  So, we will
likely be conducting small, focused pilots with two different vendors. 
I would be happy to share our RFI and some of our evaluation results
with you off list.

Jason
-- 

Jason Stirnaman
Digital Projects Librarian/School of Medicine Support
A.R. Dykes Library, University of Kansas Medical Center
[EMAIL PROTECTED]
913-588-7319


>>> On 7/8/2008 at 1:11 AM, in message
<[EMAIL PROTECTED]>,
"Dyer,
Renata" <[EMAIL PROTECTED]> wrote:
> Our organisation is looking into getting an enterprise search and I
was
> wondering how many libraries out there have incorporated library
> collection into a 'federated' search that would retrieve a whole
lot:
> a library collection items, external sources (websites, databases),
> internal documents (available on share drives and/or records
systems),
> maybe even records from other internal applications, etc.?
> 
>  
> I would like to hear about your experience and what is good or bad
about
> it.
>  
> Please reply on or offline whichever more convenient.
>  
> I'll collate answers.
>  
> Thanks,
>  
> Renata Dyer
> Systems Librarian
> Information Services
> The Treasury 
> Langton Crescent, Parkes ACT 2600 Australia
> (p) 02 6263 2736
> (f) 02 6263 2738
> (e) [EMAIL PROTECTED] 
> 
>  
> 
> 
>
**
> Please Note: The information contained in this e-mail message 
> and any attached files may be confidential information and 
> may also be the subject of legal professional privilege.  If you are
> not the intended recipient, any use, disclosure or copying of this
> e-mail is unauthorised.  If you have received this e-mail by error
> please notify the sender immediately by reply e-mail and delete all
> copies of this transmission together with any attachments.
>
**

[CODE4LIB] Enterprise Search and library collection [SEC=UNCLASSIFIED]

[Dyer, Renata]

Our organisation is looking into getting an enterprise search and I was
wondering how many libraries out there have incorporated library
collection into a 'federated' search that would retrieve a whole lot:
a library collection items, external sources (websites, databases),
internal documents (available on share drives and/or records systems),
maybe even records from other internal applications, etc.?

 
I would like to hear about your experience and what is good or bad about
it.
 
Please reply on or offline whichever more convenient.
 
I'll collate answers.
 
Thanks,
 
Renata Dyer
Systems Librarian
Information Services
The Treasury 
Langton Crescent, Parkes ACT 2600 Australia
(p) 02 6263 2736
(f) 02 6263 2738
(e) [EMAIL PROTECTED]

 


**
Please Note: The information contained in this e-mail message 
and any attached files may be confidential information and 
may also be the subject of legal professional privilege.  If you are
not the intended recipient, any use, disclosure or copying of this
e-mail is unauthorised.  If you have received this e-mail by error
please notify the sender immediately by reply e-mail and delete all
copies of this transmission together with any attachments.
**