TL;DR: Technical Services work has changed a lot over the past 3 decades, but it’s still a vital part of libraries.

On Friday, October 3rd, I was honored to give the keynote address at the annual online meeting of NOTSL (Northern Ohio Technical Services Librarians). I was asked to talk about the changes I have seen through my years working in technical services and share some thoughts about where we are now, as well as where we might be going. My presentation was called Tectonic Shifts: The Changing Lanscape of Technical Services. I’ve worked in academic libraries in technical services positions pretty much continuously for 33 years, with 26 of those years as a librarian, so I’ve seen a few changes along the way. Apologies for the super long post. Several folks asked if they could see the recording of my webinar, but I’m not allowed to share it, so I’m recreating it here (I won’t do a repeat performance). Here’s what I covered:

Everything Is Becoming a Serial

Not literally of course. It’s more that everything is becoming a subscription.

Back 30 years ago or so, serials were serials and monographs were monographs and ne’er the twain would meet. Monographs were purchased one at a time, and libraries owned them forever. Once a monograph was cataloged, its description did not change. It was one and done, forever and always. Serials were a different matter. Monographic catalogers thought I was crazy for working with serials, because the titles changed, the publishers changed, the frequency changed, even the size could change. Cataloging serials was like trying to hit a moving target. You had to be both precise and willing to accept a level of ambiguity or changeability in the records you created and maintained. And serials acquisitions had a whole set of quirks and problems that differentiated it from monographic acquisitions, because you had to deal with ongoing subscriptions, missing issues, etc. as opposed to one-off orders.

When electronic serials came along, the ambiguity and complexity of working with serials was increased. License agreements added an entirely new dimension of complication to be sure. Also, with large electronic serials packages, serials catalogers had to become accustomed to batch loading, processing, and editing of records to deal with the volume of resources. With batch work, serials catalogers had to get used to an even higher level of changeability and impermanence in their records, because, while you should certainly have quality checks on your records, some of the process relies on faith that you have good records.

For years, we had a state of affairs where technical services work with monographs was relatively stable and predictable, while work with serials was more volatile. Then along came electronic book packages (and later online video packages), and suddenly, the cataloging of monographs wasn’t so stable. You could have publisher changes, changes to URLs, etc., and the ambiguity of batch processing was introduced. On the monographic acquisitions side, these folks now had to deal with large subscription packages and the tricky issues of licenses. So, the ambiguity and complexity…the trying to hit a moving target aspect…of serials work has now spread to work the monographs, thanks to the growth of electronic resources.

Physical Collections Are Shrinking

As more and more of our library budgets go to electronic collections, we are seeing a shrinking of physical collections. To illustrate this, I discussed the history of the current periodicals collection in ZSR during my time here. When I started at ZSR in 2002 the current periodicals took up the big study room on the 4th floor at the front of the building (the one with the piano). There were shelves and shelves of periodicals, comfy furniture at the edges of the room, and a full-time staff person (with student employee assistants) to manage the collection and assist patrons. But the collection began to shrink as titles were cancelled and publications moved to electronic versions, so when the full-time staff person retired, she was not replaced and the periodicals collection was moved to the Reference area (where the DVD cases are now). The collection was near the Reference desk, so patrons could be assisted and there was good lighting and nice furniture around. As the collection shrank and its usage dropped, it was eventually moved to the stacks on the 4th floor. Zero assistance, lighting on automatic switches, no immediate furniture to use. With the Covid pandemic, we saw the usage of the collection drop further, and more titles moved to electronic versions. Just this summer, we moved the current periodicals to the basement level of the Reynolds wing, which has creaking pipes, a weird smell and a very creepy vibe. When I go down there I know I’m not going to be axe-murdered, but I kinda feel like I met get axe-murdered. The use of this collection has dropped so much over the past 20+ years that we moved it from a nicely appointed study room to a basement dungeon and, as far as I know, we haven’t had any serious complaints.

However, that’s not to say that these materials are never used , they are just used in a different way. We have our bound periodicals over in Offsite Storage, and when patrons request a specific journal article, Ty retrieves the volume, scans the article, and gets it to the patron within 24 hours, usually much earlier. Patrons can also request an entire volume be sent over to the library to be used. This service is appreciated by our patrons, and shows that physical collections are still important to our users, even if they are accessed in different ways than they used to be.

Changes to the Workforce

Since we still have physical collections in our libraries, we need people to manage them. But, we just might need fewer people to manage them than we used to. I supervise Meg, who receives and invoices standing order volumes, oversees our material marking operations, oversees our binding operations, and manages the receipt of physical materials into our department, among other things. Her position consists of components taken from what was four different full time positions 20 or so years ago, but over time and through retirement attrition, these duties have been pooled into one position, because the volume of work on these parts of the physical collection have shrunk. While we may not need as many people to do this work, this work still needs to get done. I call it the long-tail of the physical collection. The thing is, it’s pretty complicated to be trained in and keep track of such a wide range of duties. So, while work on physical collections may require fewer workers, the people who do this work need to be nimble and able to juggle a number of tasks. And it’s not like we don’t have plenty of work to do in technical services as a whole, because the care and feeding of electronic resource collections has grown through the years.

I would argue that over my 30+ years in academic libraries I have seen technical services work become more complex, even as simpler tasks have fallen off. One way I see that playing out is with student workers at academic libraries. When I started working at ZSR, there was plenty of simple, rote kind of tasks for student employees to do: opening boxes, shelving periodicals, putting call number labels on books, etc., and more complicated work like searching book orders, and we had 8 or 9 student employees working 10 to 15 hours a week. We are now down to 3 students, who usually work between 6 and 10 hours per week. There’s less simple work, but the work that remains is often more complex and demanding.

One question since the pandemic is where this more complex, more computer dependent work will take place. Some libraries (like ours) have moved toward allowing for hybrid and even completely remote positions, because the work may be done entirely on a computer without touching physical materials.

Having people work remotely can create real impediments to a sense of community. That’s certainly the case for full-time remote workers, but can also be true with hybrid workers and even on-site workers. If most of a department works from home on a Friday, it can make the workplace feel like a ghost town. It’s important to find ways to stay in touch with remote workers and check in with them. One drawback to remote work is that it can cause certain in-building functions to fall more heavily on workers who are present at the library, such as some types of committee work.

Another impact of remote work is that it may affect the space needs of a technical services department. If you have several staff members who work remotely full time, you might reasonably ask why do you need to continue to have desk space for them? Even with hybrid workers, you might consider using shared spaces. I think it best to make your workspace as flexible as possible. If you have full-time remote employees and you re-allocate the office space they used to occupy, what happens when they retire or take a new job and are replaced? You might find you have a space crunch if the new employees want to work in the library some or all of the time. So, it’s best to not be too rigid about your office spaces, if you can.

Linked Data

One totally new thing that has arisen during my time working in technical services is linked data. When I began in libraries in 1992, our computer data existed in silos and did not connect to other sources. Now, thanks to highly structured data and the use of URIs, our data is connected, providing richer meanings and greater depth. When it works, it can seem something like magic. For example, Alma indicates when a name or subject heading is properly authorized. There is a small binoculars icon for fully authorized headings and a half-binoculars icon for partially authorized headings. This saves so much time of having to check a heading against the authority file to make sure it is properly formed and doesn’t have any typos.

That’s one case of linked data making cataloging and metadata work easier and there are others, but I would argue that the grander claims of early linked data advocates have a more mixed track record. The RDA cataloging code was created in large part to facilitate the ushering in of a new linked bibliographic data future, and it certainly has helped us make significant strides. But I’m old enough to remember when boosters of RDA promised that it would make cataloging easier to understand, and make cataloging more modular and therefore cheaper. I don’t think this is necessarily the case. Understanding RDA is reliant on understanding the FRBR (Functional Requirements for Bibliographic Records) model, which can be very philosophical and abstruse (and I say this as someone who served for four years on the CC:DA Committee, which develops ALA’s position on RDA). The FRBR model defines four types of bibliogrpahic entities, Works, Expressions, Manifestations, and Items. The Work entity is so abstract that having a name is not one of its attributes. No name. How are we supposed to define a thing that we can’t even give a name to? This is some deeply philosophical stuff and not exactly designed to make the process of cataloging easier to understand. I mean, look man, I’m just trying to catalog this copy of Pippi Longstocking, I’m not trying to have a philosophical discussion on the nature of reality and what a name is. I’m kidding, of course, but I am serious that RDA is not the simplest thing in the world to understand and it does take a high degree of training and effort to master it. I would argue that, despite early claims, RDA has not made cataloging significantly easier than cataloging using the old AACR2 code. That’s not to say that it’s a bad thing that we’ve moved to RDA, because it does allow for richer description and more structured metadata.

BIBFRAME

One method to structure the complexity of bibliographic metadata is the BIBFRAME data model. Way back in 2002, Roy Tennant published an article in “Library Journal” with the provocative title “MARC Must Die.” This article caused quite the stir in the field, as Tennant argued that the MARC format was too old and inflexible to capture the highly structured data that we needed to use to provide a true linked data environment. He said that we needed to use a highly structured format so our data could be better processed and understood by computers. Inspired by this article, the Library of Congress began the project to develop the BIBFRAME data model as a replacement for the MARC format.

Several libraries have adopted BIBFRAME, but it is nowhere near replacing MARC. In fact, there is an article by academic librarian Jeff Edmunds that is a counterpoint to Tennant’s article, called “BIBFRAME Must Die.” Edmunds points out that given the current low rate of adoption, BIBFRAME would be enormously expensive to implement because the vast majority of libraries would still have to do this work. With libraries staring down enormous budget cuts in the new age of austerity, it’s hard to imagine where new funding to pay for converting records would come from. And it would require not just libraries to move away from MARC and convert to BIBFRAME, you would need to have vendors, publishers, and OCLC all convert their records to BIBFRAME. Also, BIBFRAME has allowed libraries to use customized implementations, but everyone would have to get on the same page regarding an implementation in order to make a full transition to BIBFRAME. Furthermore, proponents of BIBFRAME have failed to make a strong use case for the value of the new format. MARC has made changes over the years to increase the structure of our metadata—such as adding content, media and carrier data in the 336, 337, and 338 fields, making the publication and distribution information in the 264 field more robust—such that it’s hard to make the case that the hyper-structured data of BIBFRAME is worth the effort to produce. Or, as Lauren C. likes to say, sometimes the juice ain’t worth the squeezin’.

I’ve had the thought than rather than put in an enormous amount of work and expense to migrate our data to BIBFRAME in order to make it easier for computers to understand it, maybe we would be better off to wait a few years until AI is better able to parse the less structured data we have in MARC. Rather than work to make our data better for computers, we should make computers better able to understand our data. Considering the long timeline we would be looking at for conversion to BIBFRAME (probably 10 to 15 years on the optimistic side), and considering the rapid development of AI applications, it might be best to bet on the AI horse.

Generative AI In Technical Services

Okay, now having said that, I have to admit, I am someone who is skeptical of using AI, in the sense of Generative AI, in technical services work. However, I also acknowledge and have accepted the fact (sort of) that AI is coming no matter what we do. As Michael Hanegan and Chris Rosser, authors of “Generative AI and Libraries: Claiming Our Place in the Center of a Shared Future,” have put it, AI is an arrival technology that breaks nearly all the rules. It is not an adoption technology that you can choose to use or not use. It’s going to be everywhere, whether we like it or not. I recently saw a presentation by Hanegan and Rosser. They gave an optimistic vision of our AI future, arguing that libraries are uniquely positioned to shape the use of AI. They compared librarians to a Japanese proverb about “The Strong One Under the Floor,” unseen people who support a house. They argued that we can help shape an AI future that remains human centered and values driven.

I am more skeptical myself and have to say, that much techno-optimism makes my eye twitch. They also rather blithely breezed past the numerous ethical concerns about AI use, including the copyright issues brought up by the existence of these large language models sucking up data from everywhere, including material under copyright, as well as AI’s gigantic power usage (I’ve heard that it’s about 4 times the rate of other computer work). So it’s incredibly dirty and bad for the environment.

And that’s not even getting into the well-known problems AI has with accuracy and even outright hallucinations. A friend of mine asked an AI chatbot to create a biography for him as a test. Now, Chuck has written one cookbook, which is fantastic, and it’s one more cookbook than I have ever written. But the AI-generated biography said that he had written 3 cookbooks and even made up names for them. It used to be with computers that it was Garbage In-Garbage Out. But with AI, we have self-generated garbage. In technical services work, where accuracy and attention to detail is vital to the work, it seems risky to rely on AI.

Now, it may be that I am completely off-base about this. Again, I think this is coming whether we like it or not. But I do think it would be best to use AI in controlled circumstances or as a better than nothing option. Say you have a book in Chinese that you need to catalog, but you don’t know Chinese and you don’t have anyone on staff who knows Chinese. You can’t even search for a copy cataloging record on OCLC, because you can’t decipher the characters. I think this might be a good place to use AI. Or in translating text in an unfamiliar language so you can figure out what a book is about. Taking a more adventurous approach, some librarians have reported successfully using AI to generate basic metadata, but have acknowledged that it needs to be checked by a human in order to look out for obvious mistakes. Heck, I was on a committee to develop a strategic plan ZSR and we ran our human-written draft through an AI to get formatting and writing suggestions. We still had to go over it and edit it to make sure it said what we wanted it to say. AI can save us some time in our work, but I don’t think we can trust it to work without a check. I think we need to be humble and cautious in our expectations of what AI can and cannot do for us.

In Allison Pugh’s book “The Last Human Job: The Work of Connecting in a Disconnected World,” she recounts the story of a developer who created an AI bot, a virtual nurse, to help lower-income patients with low-health literacy at Boston Medical Center with discharge procedures. 74 percent of the patients preferred getting the information from the AI bot rather than a person, because a real doctor or nurse would have most likely spend less time with them, because they would have to run off to some other pressing matter. With the AI bot, the patients could take their time and repeat information if they needed to. Even though this program was a success, the developer (who was given a pseudonym in the book) was cautious about making too much of it. Pugh writes: “While he thought it worked well to provide information about discharge to needy patients, he was careful to limit the program’s utility to those exact scenarios, and scornful about researchers who made broader claims. ‘I’ve seen over the years, demo after demo of researchers who claim, ‘Here’s this animated nurse that you can just talk to about your health,’” he said. “And that’s a recipe to start killing people, as far as I’m concerned.” Now, we’re not likely to get people killed if we use AI in technical services, but I do think it’s a good story to illustrate the need for restraint and humility in what we ask of AI.

Are technical services still needed?

So, with all I’ve seen through my 33 years in technical services, do I think we’re still needed? Well, as long as there are libraries, libraries have collections…resources…something that people can use. And if you have collections, you have to have people find new things for that collection, buy things for that collection, receive things for that collection, describe the things in your collection, maintain the things you have, weed out things you no longer need, etc. The types of things you’re buying, describing, and weeding may change, along with the details of how you do this work. But there will always be complexities and odd bits to this work, and libraries will need people to do it. That’s where we technical services workers come in. My job currently looks almost nothing like the job I started in 2002, but the management of collections and making them accessible and usable by our patrons remains a constant, because that’s what technical services work is at its heart.

Are technical services still needed? I’d say an enthusiastic, “Heck, yeah!”