Category Archives: Metadata

– data driving a process
– uses of metadata

Metadata, Operations, Technology

The Ebook MARC Record Working Group

Introduction

The Ebook MARC Record Working Group has been an enjoyable, interesting, and especially productive Collections Services collaboration with the numbers to prove it. The working group formed in early 2023 to plan and prioritize a series of projects to improve DUL’s ebook MARC record policies, workflows, lifecycle management, and documentation.

The Duke libraries jointly hold over 3.29 million ebooks in their collections, and managing ebook records is a workflow that depends on multiple departments within Collections Services. This includes ebooks acquired monographically (via GOBI, international publishers, and other suppliers) by Monograph Acquisitions, ebook packages acquired by E-Resources & Serials Acquisitions, the oversight of bibliographic record quality and several specific local record projects by Resource Description, and the batch loading and systematic processing of ebook records by Metadata & Discovery Strategy. Because ebook workflows are so collaborative by nature, bringing colleagues from each of these departments together into regular meetings made communicating and creating a shared understanding of workflows, handover, and issues much more manageable and successful.

Ebook Working Group Members

  • Leeda Adkins (Metadata & Discovery Strategy)
  • Heather Baker (Metadata & Discovery Strategy)
  • Stephen Conrad (Monograph Acquisitions)
  • Alaina Deane (Electronic Resources & Serials Acquisitions)
  • Jessica Janecki (Resource Description) – Co-convener
  • Xiaoyan Song (Electronic Resources & Serials Acquisitions)
  • Abby Wickes (Electronic Resources & Serials Acquisitions) – Co-convener

Ebook Working Group Advisors

  • Virginia Martin (Electronic Resources & Serials Acquisitions)
  • Jacquie Samples (Metadata & Discovery Strategy)
  • Natalie Sommerville (Resource Description)

Setting the stage

When the working group formed in early 2023, DUL was several months away from the exciting announcement that we would implement Alma in summer 2024. We were still using Aleph and the Ex Libris 360 knowledgebase with 360 MARC services for ebook access management, with the expectation of one day implementing FOLIO. The working group was charged with mediating a number of ongoing issues among these systems and the vendors and publishers supplying ebook records with various contexts and caveats. The library relied on the 360 knowledgebase and 360 MARC as often as possible, but this was not always a viable approach. Some vendors would not partner with Ex Libris, or the metadata was unacceptably slow to be added to the 360 services (especially for current content.)

Because of these limitations, some ebook records were managed locally in Aleph by intention or necessity. Additionally, Aleph contained many legacy ebook records that were redundant or inaccurate. There was very little institutional knowledge or documentation of these local records, or whether the ebooks had eventually become available in the 360 systems. Since Aleph is a legacy system that was not designed for e-resources, it could be difficult to uncover these ebook records proactively without knowing what to look for. This led to problems with duplication or stale, outdated, and inaccurate information in older local records. The working group would often only become aware of a batch of local ebook records if a patron found an ebook catalog result with a broken link or other incorrect information that was a barrier to access.

Getting to work

Charged to investigate an array of known issues from the group’s advisors, the working group began assessing where to start:

  • Document, at a comprehensive level, Duke University Libraries Collections Services workflows, for eBook MARC record workflows that intersect with all aspects of the lifecycle (transforming, loading, auditing) of all eBook records from any source. Documentation should be accessible to all library staff.
  • Codify policy of acceptability for eBook records supplied by Ex Libris and other vendors, articulating clearly what is an acceptable level of completeness, what local changes to records are in scope, and circumstances under which DULCS will not load title-level records.
  • Assess and investigate feasibility of migrating legacy and on-going loads of vendor-supplied records to 360 MARC.
  • Determine timeline for making eBooks available through local loads, including developing a policy regarding acceptable lag time for availability of 360 MARC records.
  • Identify issues that are tangential but outside the scope of the Team and make brief recommendations as to who/how they might be addressed.

After reviewing this list and some of the ongoing problems known to each department, the group prioritized documenting workflows, codifying a policy for managing local ebook record access when 360 MARC was not an available option, and systematically identifying and cleaning up local ebook records in Aleph with the goal of transitioning as many as possible to 360 MARC and clearly documenting ebook records that could only be managed locally.

Accomplishments

To make progress on these three goals, the working group met approximately every other week to identify records for cleanup, identify workflows for documentation, and consider nuances for a local load policy. These regular meetings had the additional benefit of leading to a broader shared understanding of each department’s role in the ebook workflow, including the opportunity to learn about minor problems in one department that could surface for other departments, such as unexpected delays with 360 MARC loading that might lead to patron confusion on AskTech. Routine communication also made highly complex, interdependent problems much easier to tackle. The working group’s policy is available for review in Box, the documentation progress is available in the Collections Services wiki, and the group’s ebook record cleanup project work resulted in the removal of almost 250,000 duplicate or error-ridden local records, as well as the addition of over 33,000 records that were never available in the catalog. (Please note, this includes ebooks as well as primary source material from several Gale databases the working group was also asked to review.)

Alma and future projects

The ebook record cleanup was a major benefit when implementing Alma in July 2024, since so many older local records were removed from Aleph and did not migrate old problems into the new system. The established communication and broader understanding of issues was also an asset during the early months of Alma when the library experienced some growing pains with e-resource linking in the Books & Media catalog and while setting up and establishing new workflows, such as GOBI import profiles. Although the working group will revisit the local record policy in light of inevitable workflow changes in a new system, we are optimistic that much of the core philosophy of managing local records will still be applicable. Now that the library has been working with Alma for a few months, the working group is taking advantage of enhanced functionality for some additional project work. Creating sets and running jobs is an extremely helpful and powerful tool that the group is already considering for a project to identify and review certain sets of local records that migrated from Aleph, and creating local collections will be a much more robust way to manage local records than tracking them in a spreadsheet. Alma will present innumerable learning opportunities for everyone at the library, but the Ebook Working Group is here for it.

Metadata, Operations, Technology

Alma July Update

Remember the late-May post about sunsetting the system that runs the back end of the catalog and multiple discovery portals at Duke? That post concluded with a promise to provide late-July reflections from members of the  Collections Services division on work that led up to sunsetting our previous system, Aleph, and launching our new system, Alma.

Screenshot of the Alma ILS with an arrow pointing to the total number of bibliographic records.

Well, July passed in a flurry of go-live activity. This activity happened on the heels of much work  leading up to flipping the “on” switch for Alma on the morning of July 10, 2024. By noon that day, Duke University Libraries was once again open for business with a new system. Collection Services staff were already busy at work in Alma by that time and have been busy this month ensuring that access to electronic resources continues to work reliably, advising on data syncing between Alma and the Books & Media catalog, populating the system with budgets for ordering library materials, updating catalog records singly and in batch, and scanning items into system process types that allow for granular tracking and routing— among many other things! The unifying feature of all this work is that it took and will continue to take teamwork across the whole Collections Services division. Stay tuned for the next Alma post that will close the loop on the late-May post and present staff reflections on work time during the period between Aleph and Alma, what was most rewarding (and most) challenging immediately before and right after go-live, and what we hope we learn about Alma during the first six months with the system.

Metadata, Operations

Aleph Sunsets

Screenshot of the catalog record for "Blue Window"

The library catalog, article finders, online journal and database tools, bento search results, library accounts—these tools all provide a way for library users to discover and obtain the constellation of resources available to them at Duke and beyond. But did you know that these tools also provide a window into a complex system that underpins selection, purchase, description, maintenance, and circulation of library resources?

Screenshots of the record for "Blue Window" in Aleph and AlmaFor twenty years, the libraries at Duke University have used Ex Libris’s Aleph integrated library system to manage library resources in a variety of formats and languages across the acquisitions, description, inventory, and delivery lifecycles. This requires the system to store, interpret, correlate, ingest, and output a variety of data types. Aleph has helped the libraries at Duke successfully steward existing resources and acquire upwards of 1 million new resources since 2004, including a proliferation of eBooks, eJournals, databases and streaming media. On July 10th, we will be sunsetting Aleph and implementing Ex Libris’s Alma system. Alma builds on the functionality and data models of an integrated library system and incorporates these into a library services platform that streamlines and aligns processes for selecting, acquiring, describing and delivering print and electronic resources. Much planning, careful data mapping and cleanup, and lots of collaboration among subject matter experts from across the libraries at Duke has brought us to the cusp of going live with Alma. Stay tuned for a follow-up post in the later part of July in which members of the Duke University Libraries Collections Services division will reflect on the work that led up to go-live and talk about the early days of working in Alma.

Metadata, Projects, Technology

The MADS and LSC Workflow Partnership

What is the MADS partnership and how did it start?

Kristina Thomas

MADS, which stands for Metadata and Discovery Strategy, is a department that works in Collection Services in Smith, Bay 10. I work in the LSC  (Library Service Center) as a Senior Library Assistant, where I’ve been for a little over a year. In the LSC, which is off campus, it can be a bit difficult to work with librarians a lot. We’re an offsite storage facility and we don’t see many of them. Dracine Hodges, who is the Associate University Librarian for Collections Services, and Jacquie Samples, who is the MADS department head, developed the idea of the workflow partnership. They worked with the LSC manager, Marvin Tillman, and the Associate University Librarian and Director of Financial and Facility Services, Jameca Dupree, to begin a workflow partnership that would help both the LSC and the MADS department.

As an employee at the LSC, I go over to Smith once a week. I work closely with the MADS team, particularly Jacquie Samples and Heather Baker, on record cleanup, checking records in CaiaSoft and Alma research/implementation. It’s good for our departments to work together because, over at the LSC, we do have a lot of experience in CaiaSoft. It’s also helpful for me because I’ve learned a lot about Aleph and Alma, the new software that DUL is migrating to. A full migration occurs in the summer of 2024. I have also been Alma certified and take notes/knowledge learned about Alma to my LSC coworkers. It’s been a mutually beneficial partnership as we continue to do record cleanup and transition to Alma.

How has MADS helped you become better in your position?

I’ve certainly become more knowledgeable during my time in MADS. I’m not accustomed to working in Aleph Cataloging and I had no knowledge concerning Alma. It was good to be on this team that directly works in Alma. It has helped to keep me on track as we continue the transition. I’ve also learned about several jobs that are completed by the MADS team in software that I didn’t have much experience in, so I’m getting to learn something else that is newer territory. I’ve also worked on record cleanup, assigned remote storage IDs and looked at collection codes, all in Aleph Cataloging. During my time here, I’ve also become more comfortable working with people outside of the LSC in CaiaSoft and I’ve really accepted my role and become more confident in explaining the software and being able to confidently answer questions. Being offsite in the LSC made me feel a bit distant from the other libraries, so constantly corresponding with these librarians has been extremely beneficial for me. I’ve also learned a lot about Alma. I feel more prepared for the migration than I would’ve had this workflow partnership never happened.

What were your challenges and what did you feel most confident about going into this workflow partnership?

I would say that I felt confident about everything that I have worked on in the LSC. This includes all our CaiaSoft functions. I had already met Jacquie and we had an informative conversation, so I felt comfortable because I use CaiaSoft every day. I felt comfortable being able to answer CaiaSoft questions or check items in CaiaSoft and look for item reports. I also felt comfortable in Aleph Circulation as these are both software that are used daily in the LSC.

My biggest challenge was that I don’t work on the same jobs that the MADS team works on. I also didn’t have the same knowledge. They work with Metadata. MARC fields and the terminology are different, so I felt a bit out of the loop. They are, of course, also very knowledgeable in Alma and I was really starting out so I didn’t feel as if I could contribute very much. I now believe that it has become mutually beneficial because I’m learning that our workflow connects both of our software and examines the relationship between them. We can both answer each other’s questions. They were also extremely nice when it came to pacing and stopping to explain things or answer any questions that I may have.

What have you enjoyed the most about this workflow partnership?

For me, it’s a great learning experience. I’ve learned a lot about other software that I’ve become more accustomed to using. I’ve been able to learn a lot about what they do in Metadata. I’ve gotten to work on the other side of Aleph that I never worked in before. As a librarian, it’s good to have knowledge of software, even if you don’t constantly use it. I’m confident that this knowledge will be beneficial as I move forward in my career. I also believe that it has helped me with professional communication skills. As for the LSC, it can be a challenge to uphold communication with other librarians at Duke. We don’t come into contact with them that often so coming to Smith has strengthened that communication and it broadens my interests as well.

What do you hope to achieve going forward?

I hope to learn as much as I possibly can. I’d like to be a well-rounded librarian. It’s important to take the time to work with other groups of people and learn their perspectives. I hope to continue working with the MADS group as well as other groups and librarians around Duke, and even outside of Duke. It’s been a great learning and networking experience. It will help me continue to grow and learn as a librarian. I also hope that my interest and knowledge continue to broaden, and more workflow opportunities are available for me in the future.

As for this MADS group, I hope to continue working with them, even after the implementation of Alma. I hope to be able to continue communicating with them and that this partnership opens up more opportunities here at Duke where I get to work with more people.

Collections, Metadata, Spotlight

A Day in the Life: Mandy Hurt

Four serial items in various languages, including serials, periodicals and microfilm reels.

I’m the Serials Description Librarian and Coordinator in the Resource Description department of Collection Services. As one of only two serials catalogers working in the Duke University Libraries, and the only one as of now qualified to make CONSER level original cataloging records, I catalog serials across formats (print, electronic and microform) in English and a number of other languages of which I have at least a bibliographer’s knowledge. I volunteer with CONSER to catalog electronic serial titles for the Directory of Open Access Journals (DOAJ) and spend a quarter of my time cataloging rare print serials for the David M. Rubenstein Rare Book & Manuscript Library. For the Rubenstein Library, I’ve worked on such diverse materials as the Lisa Unger Baskin Collection, the Southern Poverty Law Center Intelligence Project collection and even cataloged Civil War General Orders, containing very important information like where new latrines were to be dug the next day.

What this all actually means is that I don’t have a typical working day. While all of my work relates to serials cataloging in some way, the content of the serials I work on spans a wide spectrum of subjects created throughout written history. As I don’t want to bore you with the minutiae of my work, and there is a lot of minutiae I could bore you with, I thought today I’d focus on my work with a particularly interesting collection, the Edwin & Terry Murray Comic Book Collection, part of the Rubenstein library’s holdings, which I’ve been working on for over six years now.

While the collection is primarily comprised of Marvel and DC comics you’re almost certainly familiar with, it also includes titles from the companies that predate Marvel and DC. (Their origin stories? Sorry, comic book joke.) There are also plenty of titles from smaller independent publishing houses and comics for much younger readers like those published for Walt Disney. Cataloging these materials takes quite a bit of online research involving not only official websites like Marvel and DC’s but also sites like Comic Vine, a labor of love undertaken by comic book fans and collectors.

Why does this work require so much research? Because comic books were originally ephemera, never intended to be collected and preserved. In the past, in part because they were discredited as acceptable reading material for young people by psychiatrist and anti-violent imagery zealot Fredric Wertham and his ilk, the comic books that were catalogued had brief records at best, listing little more than the title, publisher, place of publication and, if very lucky, the dates of publication. Volume numbering was often omitted or merely noted to exist (‘also has volume numbering’, etc.) and the records often had no acknowledgement of preceding or succeeding titles.

Three colorful issues of the "Captain Marvel" comic serialsComic book publishing has always been a commercial venture, so if a title fails to sell well, it’s cancelled posthaste. But fear not, intrepid comic book readers! The cancelled character may well be revived even decades later with different writers and artists and, perhaps, a different publisher. In the case of the early Captain Marvel titles pictured, the earliest dates from 1968 and the latest from 1975. These titles were published as separate runs with only the titular character and publishing house, in this case, in common. While it might seem unimportant to omit the volume numbering when you have a title that has 55 numbers published over 12 years, with all issues having the same volume number, that volume number serves as a clue to researchers that perhaps an earlier or later related title exists.

In addition to fleshing out the cataloging records for this collection by adding subject headings for the fictitious characters as well the genre (Arthurian romances, anyone?), we’ve made a conscious effort to credit the writers and artists who produced them, often creating Name Authority records for them for the very first time.

So, you can see why all of the research associated with my role is important and why I see myself as a sort of literary Indiana Jones some days. (Thankfully my fear of snakes is less of an issue than it is for Indy!) Of course, these adventures take place alongside my more general workflow, though calling even that work general isn’t exactly accurate since I’m never certain what language, subject and/or format I will see next. The life of a serialist is never boring, at least to a serialist!

[Blog note: check out this post from 2020 on the Edwin and Terry Murray Collection for even more comic goodness!]

Community, Metadata, Projects, Spotlight, Technology

A Year in MADS: Heather Baker

Heather Baker

In August, Heather Baker, Metadata Associate at Duke University Libraries (DUL), celebrates her one-year anniversary as a full-time member of the Metadata & Discovery Strategy (MADS) team in Collections Services. Before the pandemic, Heather worked as a practicum student, volunteer, and intern on the MADS team, and she now contributes as an official Duke employee. We asked Heather to share some of her experiences with us from her first year.

In what areas did you feel most successful this year?

I think I succeeded in becoming an integral part of the MADS team and taking on tasks so that my fellow team members could focus on time-sensitive projects. Fortunately, MADS has been incredibly supportive and offered their time and expertise whenever I have needed it.

If I had to pick one project that was the most gratifying, it would be a cleanup project that I completed of close to 1.5 million records. While it seemed daunting at the outset, I successfully tackled it and recently checked it off my to-do list. The project involved reviewing and updating internal notes on item records, and it gave me an interesting glimpse into the library’s history. Many notes offered a timeline of a book, for example, “this book was lost in 1977 but has been found.” Some notes were so old that it was difficult tracking down anyone who might remember what those notes meant. One of my favorite notes said, “mysteriously appeared on shelf.” That’s a mystery that will likely never be solved. Overall, I was able to make these records a little bit cleaner, which is always rewarding. I also enjoyed a few book hunts through the stacks—many records had conflicting data, and an item that displayed as “lost” to patrons was actually on the shelves. Those items are now back in the circulating collection.

What did you find most challenging?

What is so interesting about MADS is that we don’t concentrate on only one process or project. There is always something new to do, and it might be completely different from what I worked on last. My challenge has been reminding myself that I will continually be presented with unfamiliar tasks and that it’s okay to feel like a beginner even after I’ve been here for a year.

What areas did you focus the most energy on?

My focus has been on data cleanup when I’m not working on routine tasks. I enjoy the meticulousness of record cleanup, and it feels good to know that I’m improving the discovery layer with each record I touch. And data cleanup has been a great way for me to learn a variety of Aleph and Aleph Reporting Center (ARC) services. It’s fun to narrow down what I’m trying to accomplish, figure out the logic of how to do it, and then find a way to execute using Aleph and ARC. I’m not always successful the first (or second, or third) time, but I enjoy the trial and error, and I have a great support system in MADS with many decades of combined expertise.

Did anything surprise you about Duke, Collections Services, or your team?

I’m surprised at how the novelty of coming to work every day has not worn off, and I think part of the reason is because I haven’t met anyone in Collections Services who appears to not like their job. In my experience it’s rare for an organization to have staff who all seem to genuinely enjoy what they do, and it makes for a great atmosphere to work in every day.

What have you most enjoyed about working in MADS?

What I’ve found most challenging has also been what I’ve most enjoyed. The new experiences that I have weekly, if not daily, make for an exciting list of projects, and as a team we enjoy figuring out solutions to new problems. It has also been great completing some less urgent projects that the team had not been able to get to in the past. The small but mighty MADS team gets the job done!

Another thing that I love about MADS is that there is never a shortage of book recommendations. My to-read list has grown considerably since I started. And chances are that someone on the team has read whatever I’m reading, so there’s always someone to discuss it with.

What do you hope to achieve in the coming year?

I’m looking forward to helping in any way I can with the Alma migration. It’s exciting to make such a major change and have everyone learning a new system at the same time. I’d also like to focus on bringing the Collections Services Documentation Portal up to the standards of Duke’s latest Web Accessibility Guidelines. Thanks to a fantastic DUL Libraries Summer Camp session on writing alternative text and helpful Duke staff, I feel ready to do what I can to improve the quality of our Collections Services resources.

 

Metadata, Operations, Technology

CIP at DUL: Taking one for the Team

A Cataloging in Publication record (CIP record) is a bibliographic record that the Library of Congress provides to publishers. It is included on the verso of the title page of the book, facilitating the processing of the book by libraries and book dealers. The Library of Congress also distributes these records weekly, in machine readable form, to large libraries, bibliographic services, and book vendors around the world.

Publishers submit applications to the Library of Congress (LoC), and the LoC creates the CIP records for the books, which are then sent back to the publisher. This is a service offered to publishers at no other cost than sending a complimentary copy of the books summited for CIP to the LoC. Only U.S. publishers are eligible to participate in the CIP Program. To qualify for the program, every publisher must have a list of at least three titles by three different authors, and these titles must have been acquired by a minimum of 1,000 U.S. libraries.

The program was established in 1971. A year later the LoC partnered with the National Library of Medicine (NLM) to provide CIPs. Through the years, other 32 United States libraries have joined the CIP Partnership Program of the LoC.  Duke University Libraries (DUL) joined in 2008 and agreed to provide the CIPs for the books published by Duke University Press (DUP). In most cases, the partner library catalogs the books published by its own institution. For many years the CIP Program focused only on print publications. From October 2011, the program broadened its scope to include titles published in electronic and print format simultaneously. All partners libraries are NACO and BIBCO members, thus guaranteeing the quality of the cataloging.

When Duke joined the CIP Partnership Program in 2008, the Library of Congress provided a Windows based Text Capture and Electronic Conversion (TCEC) application called On the Marc. This software was developed by Library of Congress’ staff to produce MARC21 records from electronic data. The   manuscript files submitted by publishers provide the source of the electronic data for the CIP records. On the Marc was configured specifically for use with the OCLC Connexion cataloging client.  After the cataloger completed a preliminary record using On the MARC, the record was sent to the OCLC Connexion client, where the cataloger completed the full cataloging of the ECIP. Afterwards, the record (or records) were uploaded to a Duke University server directory as an OCLC Connexion “Local Save” file and harvested by the LoC.

In May 2019 the LoC CIP Program launched a new, more user-friendly, customer service application, the PrePublication Book Link (PPBL).

Dark-mode screenshot of PPBL sidebar

Things work slightly different in PPBL.  The publisher, in our case DUP, submits the CIPs applications that are then picked up by one of the two, at the moment, cataloguers at DUL in charge of creating the CIP records. In the PPBL app, “My Group’s CIP” includes all active CIP applications of the institution, and “My CIP” includes all active CIP applications picked up by each individual cataloger.

Table of CIP application from an institution

The information included in the CIP application is the Library of Congress Control number (LCCN), title, status, priority (This will be used to indicate the CIP is a RUSH request by the publisher this field, 1-Critical.), subject, assignment group, assigned to, print month and year and date it was created.

CIP application form screenshot

The CIP Program requires that a single galley file in PDF be attached to the CIP Request in PrePub Book Link.

Dropdown menu with "full cataloging" marked with red arrowPPBL MARC editor screenshot

Once the cataloger accepts the CIP application, she changes the status to full cataloging and proceeds to open the MARC Editor in a new browser tab, where some editing is available (e.g.  adding the 505 table of contents).

MARC record downloaded to computerRecord import dialog box

After that, the record is downloaded to the computer and, from there, imported to OCLC to complete the cataloging.

Export of file settings in ConnexionRemoval of fields in export in Connexion

Once the bib record is completed following the Program for Cooperative Cataloging (PCC) guidelines, we export it to a file created specifically for that record using the LCCN, and delete the MARC field tags 001, 003, and 049.

Back in the PPBL, we upload the record using the Partner Cataloger MARC Upload feature and ingest the record in the catalogue VOYAGER of the LoC. If all works well, a success message will be displayed. At this point, we are ready for the final steps in the process: adding the Call number to the PPBL and sending that information to Dewey, the next assignment group, by changing the status from “full cataloging” to “Dewey”. By clicking “save” once the status has been changed to Dewey, the CIP is automatically deleted from the side of the PPBL that we have access to.

There are significant differences in workflow between On the Marc and PPBL:

Flowchart of On the Marc and PPBL workflows

In On the Marc the cataloger sent the bib record directly to OCLC. Once they were ready, she saved them on a specific file to be harvested by LoC.  By contrast, in the PPBL application, the records are downloaded to the computer and imported to OCLC; once they are completed, they are again downloaded to the computer, and uploaded by the cataloger, one by one, to the PPBL and to the VOYAGER catalog.

As far as editing is concerned, the PPBL app constitutes an improvement but there remains quite a bit of editing to be done in fields like the 505.

TOC content input screenTOC generation confirmation screen

For example, the software allows us to remove common words like “chapter” but we still have to remove and edit the text. In addition, some diacritics don’t translate well and the order of the title / author sometimes needs to be flipped manually, like in the example below.

Diacritic mark that needs to be fixedFixed diacritic example

The improvements from On the Marc to PPBL may seem unexciting. It is hard to imagine many of you bewildered by the specifics of the changes outlined above.

Questions about the usefulness of this enterprise may remain. After all, what is the point of what seems a rather convoluted process of information sharing. The answer is simple: to provide, through the coordination efforts of the Library of Congress, a public good in an efficient, decentralized fashion. Each record we upload to CIP is a high quality contribution to the rest of library world. Jointly, we cooperate, helping each other and staying true to the mission of organizing the dissemination of knowledge as presses are ready to share it with world.

Metadata, Operations, Projects

Introducing the Bindery and Monograph Maintenance (BAMM) Section, Resource Description Department

When the new fiscal year started on July 1, two departments in Technical Services reorganized, and a new section was created within Resource Description. The section known as Shelf Preparation folded, with most related workflows moving to Monograph Acquisitions. (Follow this blog for more news on these changes soon!)

Corrina Carter and Lesley Looper (Team Lead) remain in the Resource Description Department, in the newly formed Bindery and Monograph Maintenance Section. Our new section name is descriptive of our broad work, but is a mouthful to say, so you can call us BAMM for short! (Think Emeril Lagasse or Bamm-Bamm Rubble.) You can email our new section at lib-bmms@win.duke.edu, or individually, as usual.

What BAMM will be doing:

Bindery: creating bindery and preservation boxing shipments, coordinating bound volumes (including monographs, serials, music scores, and items with digi-covers) to circulation points and the Library Service Center, overseeing the annual bindery budget, working with Continuing Resource Acquisitions on periodicals binding, and serving as in-house consultants for care and handling consultations and referrals to Conservation.

Monograph maintenance: cataloging queue maintenance, ALEPH reporting, declaring monographs missing, lost, withdrawn, or reinstated, updating locations and call numbers, resolving AskTech tickets, cataloging documentation review, and special projects (including outsourcing coordination and metadata projects).

Student assistants will also be an integral part of our section, helping us move materials through the section and department workflows, and on to DUL circulation points and the Library Service Center.

Corrina CarterCorrina has been working at Duke since 1988! She started in the Medical Center, and transferred to the Surgical Private Diagnostic Clinic (later called the Private Diagnostic Clinics) in 1990.  Corrina joined Duke Libraries in 1994, spending all of that time working with the Bindery, with several changes, location moves, and position upgrades along the way! One of Corrina’s favorite Duke memories is attending the DUL staff appreciation lunches (especially at the Searle Center), and getting to use work time to attend them. (Way back when, those lunches included humorous plays put on by library staff!)

Lesley LooperLesley has worked at Duke since 2001 (all of it in Duke Libraries), first in Receipts Management (starting as Library Assistant and later as Section Head) within the Acquisitions Department, and then in the  Cataloging Department (now called Resource Description). Later, she joined Shelf Preparation Section, before becoming part of the BAMM team. One of Lesley’s favorite Duke memories is attending the Rolling Stones concert in Wallace Wade Stadium in October 2005, and running into several DUL colleagues there. Lesley still enjoys visiting Wallace Wade Stadium for Duke football home games.

Activism, Metadata, Operations

Metadata for Everyone: Inclusive Description at the Duke University Libraries

Duke University Libraries Technical Services Division’s (DULTS) Resource Description Department has recently composed and adopted a Statement on Inclusive Description, which begins:

The Resource Description Department of Duke University Libraries Technical Services acknowledges that the creation and management of metadata are not neutral activities.  We further acknowledge that the framework of national and international standards in which we work has served to uphold white supremacy, marginalization of sexual orientations and gender identities, and colonialism, among other forms of oppression. While we will continue to work within the parameters of national and international standards and organizations, we pledge as creators and managers to make metadata more inclusive …

The metadata that describes the millions of resources Duke University Libraries makes available to users dates back to the early 20th century, and as society has changed, so have cataloging practices. In 2020, we have perspectives on inclusion and representation that perhaps our predecessors did not have in previous decades. Our Statement on Inclusive Description is our pledge to do better, not just as we move forward but as we look at some of our old metadata and think of ways to improve it.

Limitations of Cataloging Standards

Most academic and public libraries in the United States—and in many other countries—use Library of Congress Subject Headings (LCSH) as their main thesaurus to provide subject access to works in their collections. Medical libraries, by contrast, typically use Medical Subject Headings—MeSH–or a combination of MeSH and LCSH. Library of Congress Subject Headings are what most Duke University Libraries catalog users are accustomed to seeing, with familiar patterns like these:

    • Salvador (Brazil)—Social life and customs—19th century.
    • Art, Japanese–Edo period, 1600-1868—Exhibitions.
    • X-Men (Fictitious characters)—Comic books, strips, etc.—Periodicals.

Library of Congress Subject Headings are not, however, always ideal, and can present some obstacles when trying to catalog inclusively. There is often a presumption of whiteness and maleness in LCSH; its default is frequently “straight, white, cis-gendered male,” and anyone that doesn’t fit into those categories can be seen as exceptional. For example, the LCSH “Chemists” is used for works about chemists of all genders and for works limited to male chemists; a work about female chemists gets the LCSH “Women chemists.” (There is no heading “Male chemists.”) Similarly, the assumption seems to be that “American literature” is written by straight white male authors: if a work is about any other subset of Americans as authors, the headings must be modified: “American literature—Women authors” or “Gay men’s writings, American,” for example.

Library of Congress Subject Headings also include some vocabulary that may be considered outdated, inaccurate, or offensive. You may have heard about the political controversy that arose when the Library of Congress considered a proposal to change the heading “Illegal aliens” to “Undocumented immigrants.” The change was blocked, and “Illegal aliens” remains the authorized LCSH even though many find it offensive. There are other terms in LCSH, again often dealing with marginalized groups, that some find questionable, such as “Problem children” and “Eskimos.” There is a process to propose changes and additions to LCSH, but it is extremely involved, can take a very long time, and can be blocked by external factors, lack of consensus on what a better term would be, and diminished staffing at the Library of Congress.

Finally, there are some areas in which Library of Congress Subject Headings just aren’t very good, such as terminology for LGBTQ people and culture. The default LCSH heading for anyone or anything non-straight is “Sexual minorities,” a term which may technically be accurate, but which certainly isn’t in common usage and also presents LGBTQ folks as an anthropological Other. Meanwhile, the term “Female impersonators” for the entertainers we all know and love as “Drag queens” is, if we’re being generous, quaintly outdated. And LCSH just doesn’t get specific at all for LGBTQ cultures and subcultures, making it difficult to provide appropriate access for works about them.

Making Library of Congress Subject Headings Work for Us

So, if Library of Congress Subject Headings are problematic, why do we continue to use them? Well, for most subjects, LCSH is pretty good. For many disciplines, it is extremely good. More importantly, it’s an internationally used standard. Most cataloging in the English-speaking world and beyond is done cooperatively—that is, libraries contribute bibliographic description for works they acquire to the WorldCat database, so when another library gets the same book (or DVD or anything else), they can just use the record that’s already in WorldCat rather than creating their own. It makes everything go faster: trying to catalog every monograph, periodical, map, streaming video, and e-book we receive from scratch to our own exacting standards would be an impossible task. Terms in LCSH are the international standard, and libraries have agreed to use it as our common language when describing what works are about and then sharing description of those works.

Fortunately, that doesn’t mean we are limited to out-of-the-box LCSH. There are several ways we provide enhanced access to our resources by bending LCSH or by using other vocabularies altogether. In addition to actively participating in the process of proposing additions and changes to LCSH mentioned above, Duke University Libraries staff also provide more inclusive description in other ways. Perhaps most obvious to the user is our public catalog, which we share and develop with our colleagues in the Triangle Research Libraries Network (Duke, North Carolina Central University, North Carolina State University, and UNC-Chapel Hill).  DUL staff are able to customize what displays to the public, so even if the underlying metadata is standard LCSH, we can choose to make alternative terms both visible and searchable. For example, instead of the standard LCSH heading “Poor,” which reduces people to a financial status, we have chosen to display “Poor people.” Even though “Illegal aliens” remains in our behind-the-scenes metadata, library user see “Undocumented immigrants” when viewing the catalog. Continuing to use standard LCSH allows us to accept bibliographic records from other libraries without having to make manual changes to them locally, but our Search TRLN public catalog empowers us to display alternative terms our users say they prefer, or that we know through analyzing data, that they are more likely to search for.

Screenshot fo LCSH terms from the staff view.
Screenshot of LCSH terms from the staff view.
Screenshot of LCSH terms from the public view.
Screenshot of LCSH terms from the public view.

In DULTS, when we create original cataloging records, or when we enhance shared records in WorldCat, we also work intentionally to make sure our description is inclusive and accurate, especially for works by and about members of marginalized groups. For example, as we describe the Edwin & Terry Murray Comic Book Collection with our colleagues in Rubenstein Library Technical Services, we make sure to provide specific subject access to works about women, African Americans, people with disabilities, LGBTQ people, and other non-“cis white straight male” characters. “Superheroes” may be the default Library of Congress Subject Heading for caped crusaders, but we make sure users are able to go beyond Superman and Batman by adding more descriptive subject headings like “African American superheroes” and “Women detectives” so characters like Storm, Luke Cage, and Jessica Jones aren’t lost in the shuffle.

We have also begun exploring specialized thesauri to supplement Library of Congress Subject Headings when LCSH just isn’t specific enough to accurately describe a work’s contents. One controlled vocabulary we’ve begun using is Homosaurus, which calls itself “an international LGBTQ linked data vocabulary.” We’re able to enhance access to works by and about LGBTQ folks by using specialized terms from Homosaurus that LCSH just isn’t able to convey, such as “Bigender people,” “LGBTQ sports clubs,” “Transgender people of color,” and—yes—“Drag queens.”

Screenshot from our catalog showing a combination of LCSH and Homosaurus terms.
Screenshot from our catalog showing a combination of LCSH and Homosaurus terms.

Making our cataloging more inclusive takes time, but we think it’s worth it. We also realize it’s a marathon, not a sprint. Until the majority of other libraries that contribute cataloging to shared databases like WorldCat start taking similar approaches, not all of our resources will be cataloged as thoroughly and thoughtfully as we might like. But the principles we lay out in our Statement on Inclusive Description are a start. As we incorporate these tenets in newly created descriptive metadata going forward, we will also explore ways to enhance and improve our old records en masse in hopes of someday providing better, fairer description of all the millions of resources Duke University Libraries make accessible to our users. It’s a huge job, but we are committed to making it happen. It’s the right thing to do.

Linked Data, Metadata

A Linked Data Primer

Unless you’ve been actively ignoring what’s going on in the world of Technical Services, you’ve certainly heard about linked data at this point. You’ve heard of BIBFRAME, you’ve heard that it’s coming, you’ve heard that it will change the library landscape, and you may have even taken a workshop on writing some triples. But what actually is linked data?

First, some brief (I promise) historical context on linked data. In 1989, Tim Berners-Lee had the idea of combining hypertext with existing internet transmission technology, essentially inventing the World Wide Web. Once HTML was developed shortly after, websites were able to embed links to other sites inside of them, linking documents together. The technologies have gotten a bit more sophisticated since then, but essentially this is still how most people use the Internet: they put an address into their browser, and then click the links to move between pages.

In 2006, Tim Berners-Lee began to work on what it would look like if our data on the Internet were linked together like our documents were. If your data references information about the state of North Carolina, instead of storing it you could link to an authoritative source that contains data about North Carolina, most likely much more data than you would have stored. He laid out some principles for best practices, but conceptually, that’s it — instead of storing data about things, store links to authoritative sources of data about those things.

An Evolving Model

Understanding what linked data is not can be a good place to start when trying to understand what it is. To help with this, I want to look at the layers of standards we use to catalog materials. Some definitions:

Conceptual model: An abstract way of looking at the entities of the bibliographic universe. It has no direct effect on the records we create, but instead it informs the content standards we create.

Content Standard: A set of rules that dictates what data we record and the manner in which they are recorded. A content standard answers the questions of what the entities, attributes and relationships are; what is recorded and what is transcribed; and what is mandatory or optional.

Data structure: The digital format that serves as a carrier for data. Follow the rules of the content standard to fill out the data structure.

The Old Model

 

 

 

 

 

 

This is the basis of our modern cataloging structure. For our data structure, we have good ol’ MARC. Created in the 1960s and adopted in the 1970s, its original purpose was to do two things: transmit catalog cards between libraries and facilitate the printing of those cards. MARC was able to be searched by ‘experts,’ but we’re talking about the 70s here. People who used computers to do this kind of work were, by definition, experts. We’ve repurposed MARC to do all sorts of things, from tracking our orders to creating exports for our discovery layer. Around the same time as MARC, we had AACR, the Anglo American Cataloging Rules, created to standardize how libraries created catalogs and catalog records. MARC was our data structure, and AACR was our content standard. MARC says we have a 245 field, with two single-digit indicators and different subfields. AACR says this is what a title proper is, this is where you find it on a book, and this is where to put the information into these different subfields of the MARC 245.

MARC and AACR work well together because they were designed with a unifying product in mind: a printed catalog card. Saving space was paramount — how much can we fit onto a 3×5 card before it’s too busy and unusable? As we’ve moved away from the print card catalog, we’ve started to adapt our models as well.

The Current Model

We’re still on MARC, but the rest have changed. To begin with, we see the introduction of a conceptual model, Functional Requirements for Bibliographic Records (FRBR). We don’t use FRBR to catalog per se, but it informed the development and understanding of our new content standard, Resource Description and Access (RDA). RDA updated how the entities, attributes, and relationships were defined and identified, and provided mappings to MARC.

MARC and RDA don’t really work all that well together. MARC is a very flat record structure. It takes all of the data and shoves it into one record, while RDA is all about splitting different levels of description. Romeo and Juliet, the work, is written by William Shakespeare, regardless of the publication date of the manifestation.

The Proposed Model

And that brings us to finally mentioning linked data. The model that we expect to be coming will update FRBR with the newly released Library Reference Model (LRM) with some mostly minor changes, and replace MARC with BIBFRAME, a data structure that is stored in a linked data format built for bibliographic data.

This has all been a very roundabout way of saying that moving linked data doesn’t really change RDA at all. All of those cataloging skills of identifying different types of titles (RDA has around 20 types of title), assigning subject headings, and figuring out if the book you’re looking at is the same as the record you’re looking at don’t really change. Eventually the changes made from FRBR to the LRM will inform some updates to future versions of RDA, but that has nothing to do with BIBFRAME or linked data. The changes only flow down.

Semantic Technologies

Linked data is a combination of several technologies that work together to help execute Tim Berners-Lee’s vision of a semantic web. Let’s start with graph databases. In a traditional relational database, like Microsoft Access, data are stored in tables and linked together by having the primary key of one record in Table A appear as a foreign key in a record in Table B. In a graph database, data are stored as nodes and edges, where every data point is a node and the connections between them is an edge.

Graph databases are where we start to see the concept of a triple play out. They’re great for when relationships are complex and not uniform.

Next we have ontologies. An ontology is a naming and definition of the categories, properties, and relations between the entities, data, and concepts that make up one domain of knowledge (taken from Wikipedia). Let’s look at an example.

Say I wanted to make one ontology to describe a single volume monograph, or book, and one to describe a piece of two-dimensional visual art. Here are two small ontologies I might design:

 

Now, let’s say I want to create an ontology for comic books. I don’t need to start from scratch, I can use existing elements in my new ontology and only create new elements when they don’t already exist. I can include a prefix to show which ontology a certain element is defined in.

BIBFRAME is an ontology. It lays out what the entities and attributes are and how they are all allowed to connect to each other. It’s replacing the MARC layer of our existing technology.

The next technology that goes into linked data is the triplestore. A triplestore is a type of graph database designed to store RDF triples. It is a piece of software that enables all of the normal database functionality you’d expect, like complex searching and fast retrieval. That’s all most of us need to know, which is very fortunate because understanding how they work on a deeper level is some pretty heavy duty PhD level computer science.

All of this brings us to our last piece, RDF, or Resource Description Framework. RDF is a metadata model that stores data in triples. As a model, it’s fairly bare bones. Every piece of data is either a class or a property, and triples follow the pattern of ‘class’ ‘property’ ‘class.’ Here’s a very basic example:

Our two classes are the name of the hotel and the address, and the property is the relationship between them. I made up an ‘omni’ ontology to help illustrate how you might model this.

In reality, things get a little more complex:

Here, I’ve split out the different elements of the address into its individual parts and grouped them all onto an empty node that represents the whole of the address. I’ve called it ‘OWPHAddress.’

And then things get even more complex:

Here, I’ve broken it out a few different ways. First, I’ve replaced the hotel name and address nodes with URIs. In RDF, every node is either a URI or a literal, which is an actual string that represents the value. The URI is just a string that uniquely identifies the entity, just like the 001 of a bib record does. I’ve also replaced the literals for city and state with URI out to Geonames, a triplestore that exists on the Internet and manages geographic data.

What does this let us do? This is just how I modeled an address of a hotel. If there is a restaurant inside of that hotel, I could attach it to that same address node, meaning I don’t need to duplicate the data anywhere. If you translate this to describing bibliographic resources, then multiply by a few million to scale up to our collection, you have a dataset of hundreds of millions of triples that represent all of the items Duke owns.

Conclusion
Linked data is a very technical concept, which can make it difficult to accurately talk about, both within our community and with other communities. I didn’t really go into the question of why we want to move to linked data, because I think that discussion relies on understanding what it actually is. I hope this helps as a bit of a primer for what is going on under the hood for linked data, and please feel free to get in touch if you have any questions or thoughts you want to share.