By Wickes, Abigail Moffat
Information Outlook , Vol. 17, No. 1
In May 2012 I received my master's degree in library science, and like most of my classmates I was a bit unnerved by the uncertain prospects for employment. During my somewhat frantic job search, I came across a posting from a large legal research company that needed someone to conduct a data analysis and develop a description and taxonomy of a collection of nearly 2,000 software applications. Although the word librarian appeared nowhere in the job description or requirements, the hiring manager had recognized that the position required skill sets that overlap with those of MLS and MIS graduates, so he had sent the posting to my school's job listserv.
When the task of creating order out of these software applications became my responsibility, I was excited to apply my skills to a collection that had never been touched by librarians (I'm the first librarian in my office). To provide some context for the project, these software applications had been developed and individually customized for about 1,200 clients to use when conducting legal research. The applications had been created over a period of approximately 10 years by a rotating team of programming interns, and not everyone (or, in some cases, anyone) on the current team had been present when a given application was created or last modified.
This rotating team was also responsible for the limited amount of metadata associated with the applications. Although the metadata generally were helpful in terms of determining which information was valuable to the team, they had been created over a long period of time by many individuals (none of whom had been trained in information management) and thus were not always standardized or up to date. They also had been created from the perspective of "back-end users"--Web designers, developers, and programmers. As a result, a certain level of technical expertise and familiarity was required for comprehension.
Another complexity inherent in the project is that software applications are created, deleted and modified on a daily basis. The collection as a whole is mutable, so the data associated with it have to be specific enough to answer detailed questions but coarse-grained enough to stay accurate without needing constant maintenance.
Using Cataloging Theory
In assessing the scope of the project, I soon identified two pressing needs: (1) a need for more detailed information about the applications for both front- and back-end users, and (2) a need to recognize prevalent similarities and develop a taxonomy based on these identified groupings. Once these two priorities were established, it became clear that I could approach the project using skills I had learned while completing my library degree. I had taken as many cataloging classes as possible during library school, and through this coursework I had become familiar with a recurring theme: although the specific practices of cataloging are often changing, the theory behind them will hold up even as the items, methods, and tools with which we catalog evolve. For example, Dublin Core is a metadata scheme that draws from the theory and process of bibliographic cataloging but offers a distilled version of description that can be applied more swiftly to a variety of entities (Understanding Metadata 2004).
With this thought in mind, I decided to approach the challenge of cataloging the software applications by thinking of them in terms of cataloging theory, specifically Functional Requirements for Bibliographic Records (FRBR). When I learned about FRBR during my first semester of library school, it was one of many acronyms I dutifully copied into my notebook without completely comprehending its meaning or significance. As I completed more coursework, FRBR's usefulness and adaptability became much clearer to me.
FRBR is a conceptual model that is helpful to consider when thinking about organizing and describing items in a way that is consistent and will enable users to find what they need. …