I read Karen Coyle's FRBR, before and after recently and I was really enamored with how often, and to what degree, the author asks us to consider users and their needs. And the point she returns to over and over again is that librarians design standards and systems without including the user in the design process. Instead, we ask users to make use of systems we design without their input. Coyle writes in the introduction:
"...making any general statement about the structure or data elements needed to describe all resources for all users of a library catalog is going to be difficult if not impossible. And yet this is what we do on a routine basis: we create records that treat all resource types the same, and for only one definition of 'user.' We also ignore or downplay many of the characteristics that are important for users (xiii)Coyle's quote led me to consider the why of metadata creation and this is where I landed: catalog records serve two distinct purposes.
Purpose the first: inventory control--
Libraries need to have some back-end inventory control system to manage the material in their collection. It is helpful to know, at any given moment, which items in your physical collection are on the shelves and which items are not. And it's also helpful to know where (or, I suppose, with whom) the items that are not on the shelves have gone. Finally, it's useful libraries to be able to tie purchase or subscription information to the items on the physical or virtual shelves.
Metadata elements required for the purposes of inventory control of any given physical or virtual item are fairly small and might vary depending on the library and the material type of the item.
Purpose the second: discovery of resources--
Users search our catalogs to find material in our collection. Sometimes the user knows what they want and sometimes they don't. The elements we record in our records govern how users can find the material we describe. While our systems have evolved to the point that we can keyword search entire records or drill down through results sets using facets, we are generally able to query metadata that describes our collections the basis of title, author, or subject.
Okay, yeah. So what?
I think that we conflate these two purposes more often than not. And that in doing so, we do the user a significant disservice.
Metadata reuse seems to be underlying goal of any attempt to implement standardization in catalogs. And the underlying goal of metadata reuse seems to be a reduction in the cost of cataloging. Putting metadata we purchase from vendors aside, if we put our records into a shared bibliographic utility, other libraries can download them and original cataloging of an item happens only once.
But user needs are contextual and what users require when discovering resources can vary depending on any number of factors. Reuse of metadata without human intervention is fine if what you require is a placeholder for inventory control, but what happens on the 'discovery of resources side' when the record you download doesn't have the data elements your user group needs?
This is not an argument against a shared bibliographic utility or against the reuse of metadata created by other libraries. This is also not an argument in favor of every library should catalog every item in their collection from scratch. Original cataloging on that large of a scale is financially unsustainable and, for much of any given collection, a waste of time.
Where do we go from here?
On a micro-level, we should identify and document the ways in which downloaded records can be enhanced to help users discovery our library's holdings. Chances are, you have a written procedure that your copy catalogers use when making local edits to downloaded records. Have the data elements that your copy catalogers edit been identified by users as significant for access? If not, have you at least run your document past one of your public services colleagues?
On a macro-level, we need to incorporate end users in the development phase of our cataloging and library technology standards. We should identify user tasks based on the actual needs of users. And we should get feedback from our user communities on the models we build before devoting significant resources to implementing them. By doing this, we save our precious time and build infrastructure that better serves the needs of users.
Stay positive,
Erin
Works cited:
Coyle, Karen. FRBR, before and after. Chicago: ALA Editions, 2016. Print.
No comments:
Post a Comment