2. ILS
Acquisitions
Serials check-in
Circulation
The ILS Today
Goal 1: Inventory (really??)
IR
Hosted ?
Locally generated?
Special Collections
Finding guides &
lists
Others…
Journal A-Z List
Hosted?
Locally generated?
Usually just “e”
Databases A-Z List
Hosted?
Locally generated?
+
3. Goal 2: Discovery (sort of)
Cataloging /Classification
The OPAC
The ILS Today
+
“Discovery Tools”
More $
Federated Search
More $
OpenURL Link Resolver
More $
Subject Guides
More $
Search boxes embedded in library websites
Numerous vendor platforms
Open Web Other…
4. Characteristics
Local “siloed” DB
Lack of interoperability (with campus
accounting systems, other vendor products, etc.)
Static catalog - works better for “owned” vs.
“accessed”
Labor intensive
Duplication of effort in multiple interfaces
The ILS Today
9. Master Record Changes:
Libraries worldwide that own item: 1746
Local Record Changes: ?
Local Records updated after master records changed??
Current Library Acquisitions & Cataloging Model
20. 2% start search at library website
89% start search at web
From 2005 OCLC Study: "Perceptions of Libraries and Information Resources“
www.oclc.org/reports/2005perceptions.htm
Many of us are familiar with the origins of the ILS. Essentially, it was an automated version of the card catalog, a system developed in the 19th century to meet 2 primary objectives:
1. to list what the library has
2. to assist in finding and evaluating resources
Most patrons and library staff still expect an ILS to achieve these two goals. Within an ILS, acquisitions modules, serials check-in, and circulation functions all provide various types of inventory information. But we simultaneously maintain various “inventories” each of which have varying degrees of currency and accuracy and each of which are based on different types of metadata.
Cataloging processes and OPAC interfaces have traditionally served as the means for discovery. But again, our OPACs are clearly failing us in this area.
Clearly, we have had to add on and supplement the ILS because it is not performing with the full array of functionality that we need.
These systems, which essentially haven’t changed in structure or presentation for decades, have certain characteristics that are becoming obsolete in the era of electronic resources. First of all, the ILS is essentially a local, siloed database. It does not communicate easily with other systems. Also, because it is local, it requires a large amount of data manipulation to populate the database with a combination of local records, shared catalog records, and vendor records, which are becoming increasingly difficult to keep accurate over time. In the print era, the catalog cards (and later the opac displays that looked just like catalog cards), represented all the titles owned by a library. Today, because of acquisition of resources with access rather than ownership models, our collections and the data presented in these records are much more fluid and do not conform to the container in which we are expected to put them.
Next few slides have screen shots of the procedures manual for the Cornell Library Technical Services department. I don’t want to pick on them – in fact, these contain extremely useful information and the fact that they put them on the web so others can benefit is outstanding.
But they do provide a perfect illustration of the hoops we have to jump through to try to keep our ILSs in order. Elaborate, time consuming procedures are created to try to track resources that are purchased and present them to the public in a uniform way. On this slide, note especially the statement “correctness of data is critical for batchmatch matching.” So what happens if it’s not correct?
List of cataloging procedures.
What this model leads to is a mind-boggling duplication of effort – multiple libraries hold exactly the same book. Someone adds a record to OCLC. Some libraries add slightly different records that describe the same book. Others come in and make changes to the master records (OCLC). There is innumerable manual exporting/importing/manipulating of records. Once you pull in a record, it may be changed in OCLC and you have no way of knowing it unless you stumble upon it. Some libraries outsource part of this work – yet in the end we still often have to do a lot of local work. All this work being done, yet our catalogs are less and less accurate. And this represents just *one* of our inventory systems to track.
To more effectively describe and manage our resources, we need a system that operates on a network level and supports sharing of common information, similar to the back-end of an openURL link resolver. In this example of a JSTOR collection that’s included in our SFX knowledge base, we activated it at the package level in a few simple steps that took about 10 minutes to achieve. As titles are added to the collection, our holdings are automatically updated. To reflect these same holdings in our OPAC, the procedure is much more complicated and time consuming. What I want is an ILS acquisitions module that works like a OpenURL link resolver.
I’d like to talk very briefly about discovery as it relates to our existing ILS frameworks.
So we’re expending all this effort to what end? For our end users, we are not even meeting the minimum expectation – that we provide an accurate listing of what our patrons can get from our library. Add to that the changing expectations of our users today in terms of discovery. Beyond identifying and locating the libraries’ materials, Google and Amazon have taught them to expect intuitive interfaces, seamless linking, user-generated content, and personalized features. We can provide some of this functionality by expending large sums for “discovery tools” to translate our old OPACs into something more recognizable to today’s users. But these also require additional complex machinations to achieve accuracy. And they still amount to a silo – a prettier version of a local card catalog.
So let’s briefly discuss user expectations. An OCLC presentation in 2007 at Symposium on the Future of ILS included an interesting slide outlining the ‘library paradigm shift”.
I would like to highlight the last bullet point – “From ‘you go to the library’ to ‘the library comes to you.’” What implication does this have for our ILSs? If we are going to go to the user, how can we do that using an interoperable, siloed system?
Here’s an example of the library asking the patron to come to us to find the information they need by using a traditional ILS portal, in this case, a Voyager system.
Theree are 10,000 results for the keyword search “library history”.
There are no facets, so to limit, you have to do another search or click on “post limit”. What regular user would know what “post limit” even means?
Many results seem totally unrelated to the search – the top result is “Botanical medicine for women’s health”
Here’s a traditional ILS display. It literally looks like a catalog card. There are no links out to reviews, no book covers, no way to personalize the data – all things which people today would expect.
Here’s a Discovery Tool catalog display. Looks nicer. Results are more relevant. Incorporates other options, facets, links out via openurl link resolver. Has book jackets. Definitely an improvement over traditional opac. Perhaps a true NextGeneration library system should include this type of functionality, rather than requiring us to purchase additional products.
Although this does have a nice interface and better functionality than an ILS, we must keep in mind that this is a list only of what is currently available in the library, and possibly not a comprehensive one, depending on from what sources the metadata has been pulled.
Evidence would suggest that most patrons, and especially those in Academic Libraries, don’t want to limit their research to just what the library owns. Rather than going to the library on its terms, they want the library to come to them (Sabaratnum). Data gathered by ARL over a 16 year period shows a drop in circulation transactions and a dramatic increase in interlibrary loan requests(ARL 2007).
As mentioned previously, most library users have already discovered the most effective discovery tools out there. Google, Amazon, and Worldcat.org, to name a few, are much more comprehensive and effective discovery tools than any ILS today.
Some librarians say that Google is not a replacement for the catalog because one does not retrieve quality search results from the web. Data collected by JSTOR would contradict that. In fact, the number of inbound links from Google has increased steadily since 2001 and for several years has been dramatically higher than inbound links from “known linking partners” such as link resolvers and ILS systems. Clearly, users are finding quality information from web searches.
The 2005 OCLC perceptions study presented this remarkable statistic.
This Google Book search for “Library History” demonstrates the reasons users prefer the Web to the Catalog. The display is simpler and more straightforward. It offers previews and in some cases full versions. The relevancy worked better.
And when you open up a result, among the many options to you is the option “Find it in a Library.”
As in WorldCat.org there are localization options built in.
This slide shows our integration into Google Scholar.
As libraries, we have more issues to address than we have time and money to spend on them, so we have to figure out our priorities.
Should our priority be to purchase or construct interfaces to compete with Google? Should it be to keep re-creating cataloging rules? Should it be to continue to “teach” our users the “right way” to search in our catalogs to find the best information?
I would propose that we should:
Focus on getting our inventories more accurate
Find alternatives to our inefficient and unsustainable cataloging practices
Encourage all of our vendors to embrace interoperability
Educate our patrons on ways to identify licensed and owned library resources from the open web, rather than trying to teach them elaborate search strategies in our dysfunctional catalogs. We need to go where they are.
We need to focus energy on integrating our resource discovery into a webscale environment.
(This and the next 5 slides encompass the Google books entry on this book.)