2. We use III as our ILS and Catalog
◦ Since we are a system university, we share our
catalog with 2 other campuses and our Law School
Those two other campuses have separate
instances of Summon
The Law School does not use Summon
3. Our Collections budget is a little over $9 M
Student enrollment is estimated at over
40,000
4. Over several years UH tried multiple federated
search tools
Metafind
LibraryFind
ResearchPro
Encore
5. MetaFind
Federated Search Tool from III
Extremely clunky and difficult for the user
Difficult to configure resources
LibraryFind
Open Source Federated Search tool developed by
Oregon State University Libraries
We had to hire OSU as a consultant to help us set up
the tool
Also very difficult for the user to interface with
6. ResearchPro
◦ MetaFind was reincarnated as ResearchPro
◦ Limited to searching 30 databases at a time
Encore
◦ At the same time we also used Encore, which is
more of a Next Gen catalog
◦ The search tool integrated with Research Pro but
you were limited to searching 5-6 databases at a
time
7. Research Discovery System Committee
formed consisting of
◦ Head of Cataloging
◦ Head of ILS
◦ Head of Web Services
◦ Liaison Librarian
8. We were looking for a product that would
search across all platforms:
Databases
Articles
Catalog
We looked at:
◦ Encore
◦ Summon
◦ EDS
9. UH chose Summon
◦ Superior coverage of most of our databases
◦ Almost ready to use out of the box
◦ Less time spent by Web Services department to get
the product running
10.
11.
12. Very little back end configuration
Worked with 95% of our subscribed content
right out of the box
Did not show a preference for specific vendor
content
Content results list is customizable
13. We have added our local content to our
Summon instance from our Digital Library.
◦ If the user searches, for example, The Republic of
Texas, our Special Collections papers are retrieved
and the full text of this content is displayed
14. Getting our instance of Summon set up was
relatively simple
All of the challenges are post implementation
◦ Keeping Summon in synch with the catalog is very
difficult, especially in the shared instance
◦ Dataload management procedures had to change to
accommodate Summon
15. We used to be able to delete records as
needed, but now there is a 24 hour lag time
There is also a cap on how many records can
be updated or deleted – 10K per day
Had to move away from sharing electronic
resource records
18. This spring a usability team looked at
transaction log data:
◦ We looked at Known Item Author Title searches
◦ Compared the searches between our catalog and
OneSearch
◦ OneSearch returned more results “above the fold”
than the catalog did
19. Adding content from the Texas Digital
Library’s ETD’s and other Institutional
Repositories
Legacy system content
Notas del editor
We use III as our ILS and CatalogSince we are a system university, we share our catalog with 2 other campuses and our Law SchoolThose two other campuses have separate instances of SummonThe Law School does not use Summon
Our Collections budget is a little over $9 MStudent enrollment is estimated at over 40,000, which is an approximate increase of about 9,000 students from last year
Over several years UH tried multiple federated search toolsMetafindLibraryFindResearchProEncore
Metafind is an old iteration of III federated search tool. Our users found it extremely cumbersome and difficult to use. Our Web services staff found it very difficult to configure. We had to devote quite a bit of staff time to getting it operationalLibrary find was the next product we implemented. It is an open source product developed by Oregon State University Libraries. We had to hire OSU libraries as consultants in order to configure the product. The users had a very hard time navigating with this product and is wasn’t used very much.
Research pro, which is MetaFind with some enhancements is III federated search tool. The drawback is that it is limited to 30 databases and we have almost 300. Again it was clunky and cumbersome to our users. Also, for it to work properly, we had to give the vendors the Research Pro IP. A number of vendors would not add it because the IP was not owned by the University of HoustonWe next switched to Encore, another III product, as a next Gen catalog. The search tool integrated somewhat with Research pro, but was also limited in the number of databases it searched, about 5 or 6 at a time. It was too limited for our users. A committee decided that Next Gen Catalogs did not really meet the needs of our users. We felt that going with another catalog interface did not give us any added value of just the catalog itself.The main reason we didn’t continue with Encore is that it didn’t address the users needs and their research interests. What we really needed was a tool that gave us searching capabilities across more of our databases and journals
So, We formed a committee which included the head of cataloging, head of ils, head of web services and a liaison librarian to look at the various discovery platforms available on the market around early 2009.
We were looking for a product that would search across all platforms:DatabasesArticlesCatalogWhat was available was Ebsco’s EDS, Summon, and Encore.We decided to give another look to Encore’s future enhancement plans to determine whether or not it would meet our needs with future updates.The notion of a next gen catalog wasn’t well received by the liaisons and the head of ils due to is current limitations, so Encore was stricken from the list. We really needed another way to get at our online content.At the time, Summon was a vastly supperior product to Ebsco’s EDS. EDS at the time, wouldn’t work well with any other content other than Ebsco’s and we have a rich selection of databases across multiple platforms. At the time we selected Summon, they covered about 95% of our existing content and we felt that it would be a superior product. We would have had to additional devote staff time to configuring multiple databases if we went with EDS. Summon provided most of the content already configured.We went live with our Summon instance with the start of Fall semester 2010
UH chose SummonSuperior coverage of most of our databasesAlmost ready to use out of the boxLess time spent by Web Services department to get the product running
So, we branded our Summon instance as OneSearch
and placed it front and center on our Web page. If the user types something into the search box, they are immediately taken to our summon instance. If they prefer to search another section, such as our Ejournals, specific databases or the catalog, they have click another tab. Transaction log data shows that there is some tab jumping but not as much as you would think.
Advantages to choosing Summon,There was very little backend configuration for our Web Services department to do, the only configuration was the mapping, which was achieved in relatively very little time. The head of cataloging was able to do this in just a few weeks95% of our content was immediately availableWe were able to arrange which resources were retrieved in a way that made sense to our users. In other words, we were able to push journal vendors to the top and database vendors farther down the list.
Getting our instance of Summon set up was relatively simpleWe have faced some challenges post implementation, but those have mostly centered around the maintenance of the data.Keeping Summon in synch with our catalog, especially since it is a shared catalog with 2 other UH system libraries and the law school ahs been challenging.How we have managed our data loads, our internal database maintenance procedures, and record deletion all factored into our day to day maintenance and we had to rewrite some procedures
We used to be able to delete records as we needed to, such as with content changes within NetLibrary or Books 24x7, or with URL changes and monthly updates. Since Summon has a cap on how many records can be altered at a time, 10K per day, our catalog can quickly get out of synch. We have had to modify our workflow in order to accommodate this limitation. I have recently been told that this record cap is more of an issue with our ILS interface than an actual problem with Summon. However, because of this record cap, the fact that we share the catalog, it has been quite constraining with the workflow we use.We had to move away from sharing electronic resources records, not necessarily because of Summon but because of the workflow change that had to occur. It was faster for the record loads to occur if we did not share.We had to alter the way we coded the records with location codes so that we could extract the titles specific to UH main. We also had to clean up any location code errors very quickly in order to ensure that our users go the most relevant coverage. All of that being said, during the first year of implementation, we had to do three complete reloads of our catalog. Each load took about 6 weeks. Given the synching issues we encountered, the data maintenance became cumbersome. During our second year, we have only had to reload the catalog once, which is an improvement. The reason for this reload was partially related to Summon and partially related to our modification of internal processes
In spite of the challenges, was it worth it for us? The short answer is an emphatic YES
AS you can see from this graph, we have had a huge increase in our ARL stats.Our ARL stats for 2008/20092010/2011722,0691,006,219Our overall journal stats showed an almost 40% increase in usage from before we implement summon to our current usageThe biggest change that our Liaison librarians had to incorporate into their teaching models was to teach only Summon rather than specific journal platforms or databases. University of Houston has a robust teaching model with undergraduate instruction. Because of this de-emphasis on teaching specific platforms, some resource content, such as with JSTOR and Project Muse showed a decrease in statistics. Also, the branding of specific platforms, such as ScienceDirect or SpringerLink as the go to place for content has decreased.Specifically, our Nature usage doubled from the time we implemented summon and our Sage journals rose 230% Clearly summon is uncovering content that was previously hidden. People are not having to hunt for content across multiple platforms
We looked at known item author title searches and compared OneSearch to the Catalog to determine which tool gave our users faster access to physical materials within the main library. The transaction log data was limited to print materials only.We found that we had better results in finding print materials within the first screen presented with OneSearch than with the catalog.
Future issues with our implementationWe would like to explore adding additional content to our Summon instance that is local and pertinant to the state of texas as a whole, such as the institutional repositories from UT, and Texas A&M. Also, we would like to think about adding content from our local Museum of Fine Arts, Houston. We have embarked on a project to include the University of Houstons ETD’s into the Texas Digital Library and would like to see this content included within Summon. Additionally, some vendor platforms that are legacy type systems don’t really play well with summon, such as LexisNexis content. We would like to see these types of systems adapt to making their content more discoverable.
