Integrated Access Council
March 21, 2005
SML Room 409
Present: Katie Bauer, Matthew Beacom, Meg Bellinger, Carol DeNatale, Ann Green, Katherine Haskins, Julie Linden, Fred Martz, Kim Parker, Bobbie Pilette, Kalee Sprague, David Stern, Joan Swanekamp, Rich Szary
Absent: Dale Askey, Dan Chudnov, Kenny Marone, Jack Meyers, Tom Saul, Frank Turner
Guest: Audrey Novak
1. MetaLib Demo and Discussion – Audrey Novak
The MetaLib Implementation Committee members are Kalee Sprague, Katie Bauer, Dale Askey and Audrey Novak. Audrey said that they have been testing the usability of MetaLib and that after receiving feedback from various demos they are making significant changes to the initial implementation. Audrey asked that we note that she was going to be compressing into ˝ an hour a usual 1-1/2 hour presentation.
The MetaLib implementation currently has 2 capabilities: a list of databases and a federated search tool. With the purchase of two additional items they will add 2 more capabilities with the MetaLib X-server (communicates via XML with external applications such as the uPortal) and MetaIndex (allows the harvest of OAI records).
First Audrey demonstrated QuickStart, which offers three predefined sets of resources: Yale Catalogs, Area Library Catalogs, and General Article Searches. She then illustrated a search using the two-element keyword entry box.
Audrey discussed common problems with federated searching. 1. Results are only as good as the targets that you are searching – databases have to be available and they will deliver inconsistent results at different rates. 2. In the results of a search you can see the full record and what databases and holdings there are. With the search that she demonstrated, she reviewed the problems of confusing and incomplete result sets, problems common to all federated searching tools.
Audrey pointed out the alphabetical list of databases, the ability to set up personal sets of databases, and the ability to access databases by category types. There are three types of data access: a) search and display, where results from multiple resources are presented through the MetaLib interface; b) search and link, where the search is executed from MetaLib but the results must be viewed in the native interface; and c) click to search, where both searching and viewing must be performed outside of MetaLib.
MetaLib uses a central knowledge base available through Exlibris. This is updated once a month. The number of databases included in the knowledge base will increase over time. If there is a choice of the same resource from 2 different vendors, the selector must decide which works best with a federated search. All of the large databases are present in the knowledge base. The small vendors aren’t yet. Audrey then demonstrated the Multi-Database Search and discussed the ability to search by subject categories.
Kalee said that a survey in the UK found that users prefer to see results database by database. Users were more satisfied combining results after individual database searches, than they were with federated searches that combined all results from the start.
Audrey showed the different ways of accessing the databases by ‘search and display’ or ‘search and link’ or ‘click through.’ They are exploring the best way to show these access categories to users. They also are working on the subject categories and how to incorporate subcategories into the single category list. Selectors are helping refine these category lists. There is also a limit to the number of databases under each category. They recommend 8-10.
Kim asked how far away we are from going live. Audrey said it will probably be another month or more until it is rolled out.
2. Last Months minutes
Ann asked if there were any comments or corrections to the minutes from last month’s meeting. There were none so they will be posted to the web.
3. Cross-collection Access, Federated Searching, Metadata Harvesting –Fred
Fred asked if everyone had received the 5-page handout (posted on the IAC web site). He said the last page is the key to the diagrams. He said this was an effort to try and put the MetaLib experience in the context of what we have now and to talk about alternatives and future directions.
The first diagram is basically our current library front door approach. The search is one database at a time but not across resources. There are a number of front doors, e.g. for Medical and Divinity. The shortcoming is that you find things best if you know what you are looking for. It is not a higher level of integrated searching. Diagram 2 is a platform-specific model. It has the limitation of being specific to a particular application such as Luna Insight. The problem is that for each cross search you can only search collections on that platform. A significant advantage is that you can retrieve both metadata and content and view material (e.g. images) from different collections in the same workspace.
Diagram 3 shows a mature MetaLib federated search example with add on features. MetaLib goes to external and some local resources (Orbis, Morris). It can’t go to most local resources because they don’t have the proper gateways. The solution is the MetaIndex product – an OAI metadata harvester. It can go to others after appropriate configuration. All local databases could be OAI-enabled and searched.
The X-server takes records retrieved and exports them in XML format for use externally, in the uPortal or Sakai, for example. This diagram includes SFX on the right as another tool. It is not a portal or federated search; it is primarily a service that allows lateral linking between resources. David asked if this could be used as a searching tool. Fred answered that this is not the case right now. David said there are a couple of examples that we could easily try. All of the services in this model are operating at a metadata level only. MetaLib never retrieves image or full text. The upper left of the diagram shows examples of external access that are available now: OCLC Worldcat, and Google. We are exporting records to OCLC and having them harvested by Google.
Diagram 4 is primarily focused on OAI harvesting. All Yale databases are OAI-enabled. All arrows are pointing upward to harvesters. In the interest of legibility, only some of the possible arrows are included in the diagram. The harvesters in the aggregator row are collecting information for the service providers (portals). External resources are still accessed through MetaLib federated searching. David said if someone uses Google and does a search they will not find Yale’s electronic resources. Fred said that’s where it gets into rights issues. Kim said the key is to get people to go farther than Google. Fred explained that there are three types of service provider represented: a metadata discovery service, a specialized discipline-specific service, and a service that provides both metadata and content. We can achieve the solution of harvesting content if we have the rights to it from a multitude of platforms.
David asked why all arrows don’t point into the MetaIndex so that you could search all. Fred said that MetaIndex could search all resources combined either directly or through the general aggregator. David asked wouldn’t we want people to go through MetaLib instead of Google. Ann asked whether the X-server could resolve some of the result set problems Audrey had been talking about. Fred said it doesn’t do any additional processing – only gathering. Ann asked if we cache the results could we solve some of the problems? Fred replied we can’t demonstrate this yet because we don’t have the X-server yet. There is a post processing issue – not only can a harvester support a service provider; it can also refine search results. Harvesting can solve some of the federated searching problems Audrey showed because a harvester is constructing a local set of metadata records instead of doing a broadcast search.
Meg asked Fred to talk about the purpose of the diagrams. Fred answered that the intent is to create a picture of what we have now and describe directions where we want to move next. The ultimate objective is to set priorities and define efforts over the next couple of years. Rich asked if the policy question is looking at making Yale resources OAI compliant to get items into MetaLib. Fred said yes, the strategy is to begin configuring specific resources (for example StatCat and the Finding Aids) to be OAI compliant. Ann asked if there is a move to harvest complex metadata. For example, how much of Finding Aids EAD metadata is harvested? Fred said the specifications for OAI include richer metadata formats, so we can include extensive metadata if we wish. Kim said Finding Aids would be a good one to experiment with. Ann said when we come up with a metadata core we don’t want to cut ourselves short. Meg asked how does this inform the work of the Metadata Committee. Joan said that Fred should come to a meeting to present to the committee [which he did the very next day].