My Name Is Shana Mcdanold. I Am Currently Head of the Metadata Services Unit at Georgetown

Shana:

My name is Shana McDanold. I am currently head of the metadata services unit at Georgetown University, and they asked me to speak from the perspective of a trainer. And you’re going to hear a bit of repeats of bits and pieces of all this, because what they learn in school obviously then impacts what you do when you get them in the real world, because training is for people that are already in the real world, continuing education, that sort of activity.

So, my perspective is, first and foremost, as a practitioner. I’ve been cataloging for let’s not talk about how many years now. And I’ve cataloged everything under the sun. My primary expertise is in serials and anything and everything online, but I have also cataloged games, puppets. (That was my favorite. I got to carry around a puppet for a week.) But generally a lot of weird stuff is what’s ended up on my desk. And so I’ve always had to do a lot of thinking on my feet, and that has of course then impacted and fed into my perspectives as I’ve looked at what people need to know, and what they need in order to be able to do their jobs effectively.

I’m also a manager. I have, at the moment, nine direct reports. They are both from the very basic level, clerk level staff, all the way up to seasoned professionals, so it’s the full range. And I also serve as the metadata expert for the entire Georgetown Library community. So it’s not just my staff, I’m also managing the metadata for multiple different places. And I’ve also had interns in the past, we’ve had student workers, I do hiring. Fortunately I’ve never had to do firing, I’ve only had to do the hiring part, so that makes me happy.

And I’m also a trainer. I’ve been doing training almost as long as I’ve been a practitioner. I do training for ALCTS, I do training for CONSER, the PCC. I do formal training, I do training within the library on different systems. If they need someone to teach something, they end up coming and saying, “Hey, can you show everyone how to do this?” And I go, “Yes, as soon as I figure it out myself.”

So my presentation is largely anecdotal and based on my experience. There’s not really a study for what I do—and believe me, I did my literature research, and I did not find it. There’s not really a study of training, and the impact of training on your job, so I’m kind of going with my own theory at the moment. And really the thesis I came up with is based on my experience. And I did decide to go ahead and do a thesis, which I know sounds somewhat ridiculous, but it helped me to kind of frame my mindset as I was doing this. And what I came up with is that knowledge of the fundamentals assists catalogers (and like many, I’m using “cataloger” as the catch-all for anybody that deals with cataloging and metadata) and empowers them. And that’s the key word, that it empowers them. Flexibility—the ability for accepting and facilitating change, not just accepting it, but facilitating it and participating in it, as well as improving the quality of work. I’m not looking at the nitty-gritty. When I talk about fundamentals I’m talking about the broad concepts, the types of things that you are supposed to be learning in library school, because they’re the broad, overarching theories that impact everything.

I’m going to review a little bit for the fundamentals theories, and for anyone that this gives flashbacks to, I apologize. When someone comes into my unit applying for a job as a cataloger and claims they have experience, I expect them to know, at least in theory, who these people are. And I see a few people around the room that are confused. But this is what I mean by the fundamental theories. Rebecca Lewis listed them in her Practical Strategies for Cataloging Departments, which was my bible when I took on the job of head of metadata services at Georgetown. And it’s also been listed in a lot of other publications that discuss cataloging. These feed into everything. Almost anything and everything that we do you can trace back to somewhere in here. And that’s something that is very unique. When you talked about history, and the history of cataloging, this is really where you see it. And Panizzi—we’re talking 1700s. And the 91 Rules were really kind of the first real cataloging code. And you see that now carrying forward, and what he did pushed forward. You started seeing it in Jewett—Charles Coffin Jewett focused a lot on uniformity to facilitate access, sometimes at the expense of the user, which was probably one of the larger negatives to his theories. But his uniformity, the idea that you need to have some consistency.

You have Cutter, and I’m sure that most people in the room have at least heard of Cutter and his Rules for a Dictionary Catalog. His objectives were to identify, collocate, evaluate, and locate. Does that sound familiar? Who knows the FRBR user tasks? Do you see how it all kind of dovetails in, it all kind of follows each other? You know Lubetzky, and Lubetzky’s writings were used as the foundation for the Paris Principles in 1961. And the Paris Principles are what fed the creation of ISBD and AACR and AACR2. And a lot of what they’ve done with FRBR goes back to what Cutter and Lubetzky did, and reworked what they did, and took things in a slightly different direction. And then you have Ranganathan and his Five Laws, which is kind of the ultimate of why we do what we do, why there’s librarians. Everyone has to find what they’re looking for.

But there’s not just theories, there are other fundamentals. You have subject analysis. Subject analysis is this “aboutness.” And when people think subject analysis, they think, “Oh, that can’t be hard,” but actually it’s a lot more complicated than people realize. You have to be able to take it and recognize that just because the book is set in a particular place, it’s not about that place. So that concept of subject analysis, the “aboutness” of the work, is a fundamental concept that we have to understand, because it also feeds our users, and how things are connected, and how people are going to find what they’re looking for and what they didn’t know they were looking for.

You have classification, which serves not just as collocation, but also as an actual physical location device. We have call numbers for ebooks. There is no physical location for an ebook. (At least until the user sits and prints it out and sends it to us to be found so it can be put on the shelf. I kid you not.) But we’ve added them because classification serves multiple different purposes. And there’s a lot of back and forth about that, but because I had a fundamental understanding of what the goals of classification were, whether it was LC or DDC or Brown or Universal Decimal Classification, any of those sorts of classification schemes, it’s not just one purpose, it has multiple purposes. And you have to be able to look at that, and again that goes back to understanding and your ability to be flexible.

There’s also relational database structure and systems; not just learning one system, but learning in general how systems function, how everything is connected, and that everything is connected. And just because you’ve done something here, oh, that has a huge impact over here, you can’t do that. Knowing that when we create a new location for something because someone wants it and we’ve restructured—we’re in the process of setting up for our renovation of our special collections at Georgetown, which means a lot of our locations for them are going to be changing or adjusted. So as we’re looking at this, we have to think very long and hard about what we’re doing with those locations, and what they mean, because it affects all of the ability—it affects circulation, it affects cataloging, it affects displays, and how everything, just because you changed it in one table here, we now have eight other tables that we have to perpetuate that change in, and we have to create all the definitions for. So kind of a basic understanding of a system, and how the relational database works. And even with all these next gen systems, they’re still relational databases. They may be cloud-based, but they’re still relational databases. Everything feeds into everything else, and there’s relationships, and this interconnectedness, and you can’t do one thing without impacting someplace else.

And finally you have indexing. And this has a massive, massive impact on search results, and whether or not someone’s going to find something, and then also the authorized versus not authorized keywords versus controlled vocabularies. And all that relates to indexing. And if one more person tells me that keywords and controlled vocabularies cannot exist side by side, I might lose it. Because they serve different purposes. So you have to go back to, what are the fundamentals behind indexing? What are you trying to accomplish? And it feeds into everything that you do. Now, if you’ll notice—and most of those who know me know that I’m a big proponent of coding and learning computer languages and being able to do that. In Chicago we have a Python pre-conference for catalogers and other metadata people to get into coding, and I think it’s a great thing. But I see it as a tool, more than as a fundamental. I love coding, and things like that, and people like Terry Reese and MarcEdit who do coding, have made my life infinitely easier, but it is a tool. And it’s not going to do me any good—I can’t write a code if I don’t understand the system. If I don’t have a good understanding of how a relational database works, I can’t write code. I can’t write code if I don’t understand indexing, or if I don’t understand what the point of subject analysis is. I can’t write good code that’s actually going to do anything if I don’t have an understanding of the fundamentals.

So your fundamentals really feed into your ability to use your tools. They are our foundation. They tell us why we do what we do, and they tell us how we do what we do. And the “how we do our work,” the “how we do the subject analysis,” “how we fit all of the pieces together to make stuff findable,” but it’s also again back to that “why.” What is our ultimate goal? What do every single one of those fundamentals lead back to? We’re making stuff findable. That is the ultimate goal. And they all fit together in different ways to make that happen. So we have to be able to have a good understanding of those tools, and when I’m hiring people, I want people to know what those fundamental tools are so that they can then move forward. And all of this has now served as a foundation for FRBR, for RDA, for BIBFRAME, for MARC, for Dublin Core. You can see all of those organizational tools, all of that history, is all represented in all of these new fangled—you can even see it in linked data. Those relationships, and that connectedness, and the idea of a work, which is not new, to be honest. You can actually trace that all the way back to Jewett, and Panizzi’s 91 Rules. The concept of the work is in there. So if you have a good understanding, you’ll realize that it’s not actually new, we’re just doing it in a different way, because we have new tools available to us.

So I’m going to use a couple of examples, and the first example I’m going to use is cataloger’s judgment. This is getting a lot of airtime right now. Those of you that are on Autocat, I had to close my Autocat folder and back away slowly. I’m sure I’m not the only one. (I see one of my OCLC colleges here that probably gained a few more grey hairs. I’m really sorry.) But really what it comes down to is the cataloger’s judgment. And their judgment—because they didn’t have a good understanding of what those fundamentals—I really, honestly, when I looked at that, my first thought, when I’m reading that and as I’m working on this presentation going, “He doesn’t get it.” And I don’t know this person personally, and if you’re here, I’m sorry, but it’s fact. My response was, they don’t get it. They don’t understand the fundamentals of what we’re trying to accomplish. And because of that, there’s a disconnect between the decisions that they’re making, and the impact those decisions have on everything else. The impact those decisions have on the users. And your user base is not necessarily just your local user base. When you’re working in a shared utility, whether it be SkyRiver or OCLC, your user base is everybody else, not just you. But you also have to keep in mind your local needs, and those local needs are not easy to grasp. There is a lot of local information any time you start a new job. I don’t expect you to come work for me and to already know my library’s policies and procedures. I can teach you that. What I can’t teach you is how to make a decision. How to do the judgment calls. I cannot teach you that if you do not have a fundamental understanding of what we do and why we do it.This feeds into—you know, it’s not uniform, the “just tell me”. So this is why the cataloger’s judgment is really important, and you can see it—if you have a good understanding the decisions you’re going to be making about subject analysis, classification, description, how it’s all going to feed into the system and feed into the index in order to make things findable or not, and the impact it has on everything else, the impact it has when you’re looking, “do I do this option or this option?” Well, what is the information and who are you doing this for? And if you can answer those two options, you have your answer. But you can’t answer those questions if you don’t have an understanding of why we’re organizing these things. So it all goes back to those fundamentals.

Another example would be system migration. I’ve been through a ridiculous number of these in my career. We are now looking at possible system migration number four for me in an approximately ten year period. But what I found is that those fundamentals also assist me when I’m working on system migrations. It assists me with making prioritization decisions about where to focus my energies. It assists me in timeline construction: what do I need to do first and how do I need to do it? Because if I have an understanding of the system, and how that feeds into the indexes, and who’s using it for what, and what exactly I’m cataloging, and what our users are using, that’s going to help me figure out what I need to do first, and what are the critical pieces that I need to make sure work on day one. What are the things that, okay, if we don’t get this right the first day, it’s not the end of the world, we can figure it out, versus what are the, “Oh god, nobody can find anything?” Knowing how to make that decision has a big impact on your ability to stay sane when you’re migrating two million records. And it also impacts the Discovery Layer. How those changes that you’re going to be making behind the scenes with your system are going to impact material exposure. When I talk about system migration, it may not be the database behind the scene, that might be an OPAC to a Discovery Layer. When I was at the University of Pennsylvania before Georgetown, we migrated from the standard ILS Discovery Layer to the lovely faceted system that they had, and wow, that exposed some interesting data. And you started to see a little bit more about—and there’s a lot of people that didn’t understand why things were happening the way they were, but because I understood the fundamentals and how the system worked, I could go to circulation and say, “I know you really want this to happen, but I can’t make it happen, because we don’t have this piece of information, or this piece of information. I can’t isolate it. It’s there, but I can’t isolate it.” And I could explain how everything was fitting together, and why they were seeing what they were seeing. And this goes a long way, when you’re working with other people, to making things continue to move forward.

The last example I’m going to use is the example of the new cataloging code, the elephant in the room, in a way: RDA. I’ve been living with RDA, doing evaluations of RDA, since 2006, so for me, when 2013 implementation came around, I was like, “Really? It’s about time.” But I realize that the fundamentals don’t change. And so when I teach RDA, as a trainer I approach it from the, let’s look at the fundamentals. What are we trying to accomplish, and how are we working through that to accomplish that. How is this different from what it was before? And what people realize is that it’s really not that different. We’re approaching things in a new way, but we’re still doing the same pieces of our work. We’re still exercising the same fundamentals of organization. We’re just organizing it and going about it from a different direction. And you can see this in citation, and I use citations as examples a lot, because citations all have the same fundamental elements that you can also see outside of the bibliographic universe, but what we do impacts whether or not someone can match that citation to the information we have. So it’s kind of a good test case when you’re looking at things. Citations, where does this all fit together. So, why is this important? Well, because change is scary. Everybody knows this. But it’s less so if you can see how those fundamentals continue and how they are connected over time. You get a lot less worried about whether or not something is going to work if you can see how this is connected to this, and how, really, the fundamentals of what we’re doing with RDA is the same, we’re just approaching it differently and using different language, so that we can make our data do things that you never really could do before. Because we’re just approaching it differently and coding it differently and calling it different things so that it plays nicely in a larger world. But the fundamentals of the organization of that information that are used by libraries are used on the web. And we can take what we know and those fundamentals and translate it, and make it accessible in different ways, but only if you have those fundamentals. If you don’t have a fundamental understanding of how things are organized in the bibliographic universe, you will never be able to take your packet of data and effectively migrate it to continue to have things be accessible in the same way. You will be mired in that one structure, because you can’t see the flexibility that our data engages. So again, it’s back to how to support our users in all contexts, and flexibility. You have to have that flexibility. And the fundamentals feed into that. And I realize that this is—I don’t have data, necessarily, to back this up, but based on my decades of work, if you have the fundamentals, you can be taught, in a way. So you can take any job if you have that core, and figure out how to do the work that’s at hand. So. Questions? Disagreements?