Lingua franca

So, as I said a few days ago, I have been out of the library game for awhile. But I have a persistent question regarding MARC and BIBFRAME. Maybe it’s been answered already, and if so, some kind person needs to point me to the answer so I can lay my feelings to rest on the matter.

Here’s my question: BIBFRAME is in English. Does this bother people? Did it once bother a lot of people and it's now all fixed up and has a resolution?

I know that English has become sort of the lingua franca (haha) of the digital world, but I’ve always seen the strength in MARC as its language independence. I may not speak German, and the German across from me doesn’t speak English, but we both know what a 300 field is. BIBFRAME is, I’ve heard, being experimented with by the Deutsche Nationalbibliothek. Are they using a translated version that has a crosswalk to English? Or is it just English and they have to learn it? How do they feel about this? How do other countries’ library folks feel about this English-centric model? I’m so curious, and I haven’t really had time to dig very deep into this question of mine in search of answers, but it seems absolutely of vital importance if this is supposed to be a framework on which we rest all of our future cataloging. Which is why I assume that someone smarter than me has figured this out already. I just don't know what they did about it, and would like to.

What my reference librarian found this morning

So this morning I come walking into the library, coffee in one hand, prepared to walk right back to my desk and commence the wonderful and magical work of fixing something in the ILS. The reference librarian on duty (and in fact, the head reference librarian) yells at me. Yes, she yelled. Yes, I went over and said "Ma'am, we are in a LIBRARY." We both laugh.
Anyway, she directs my attention to this subject heading, and asks "what the heck is this? It's just a number. And there's a whole bunch of them."

651 $7 $a7.150.$2gtt

Yeah. There it was. The dreaded $2gtt marking on that 651. "Gemeenschappelijke Trefwoordenthe-saurus (GTT)" (Joint Subject Headings Thesaurus). In other words: the Dutch.

I'll admit it: I badmouth the GTT like nobody's business. Mostly because I find it to be horrible. What kind of subject heading is "History"? I know that you catalogers out there are with me. It's ridiculous. This is the Dutch National System, not Jan's World of Paperbacks. Surely they can do better? I mean, this is the country that built the dykes, that produced the Dutch Masters, held England and Spain at bay while they built one of the greatest international corporations in the world. Subject headings should be a breeze, am I right?
Anyway, this was a new one, but I wasn't surprised. A number for a subject heading? Why not? Why not just move on to pictograms, GTT?

But really, I am just poking fun at what is really a system that is not designed to be the LCSH. Yes, I made a joke of it to the reference librarian, but at least now when she sees something like that, she will know from whence it came. If you, gentle reader, are interested in knowing more about the GTT, which is really just an index of very general terms and not like the LCSH in either form or function, there's a good article here.

Semantic Web BlahdeBlah

Reading about how libraries need to embrace the Semantic Web. Here's my note in the margins to myself:

"Isn't there a larger problem with metadata for the Semantic Web (or XML, or MARC) that all these tags are still *text*, and therefore subject to misspellings, misunderstandings, and the vagaries of the human mind? The problem that we have with databases and their inability to catch inconsistencies is also a problem for any XML or Semantic Web entity. You can call a cat a cat or a feline or a kat or a kitty, and no one can nay-say your tag. But your tag will not necessarily fall in with other tags which may be the same *thing*, but not the same *word.*"

I'm interested in how we resolve this problem. It's a problem that catalogers have obviously been wrestling with since time out of mind, but now we have an infinitely larger population of data-inputters, with infinitely less training in the importance of standardization and uniformity of metadata. Are we forced to just give up and let things be kind of crappy? I don't know that the answer is just "more programming."

The Best (Worst?) Meeting Ever

I just came back from a meeting about how to implement PREMIS in our institutional repository. We've been working on how to implement PREMIS for months. The result of this meeting was: we don't need PREMIS.

So was this the best or worst meeting in history?

The case for "best meeting":
We came to the conclusion that while PREMIS is probably very good for some things, in this case it wouldn't be capturing anything that we aren't already capturing in some other way. Thus, we don't need to add work for ourselves just for the sake of a standard. Verdict: SUPER productive meeting where we didn't make unnecessary work.

The case for "worst meeting":
We started out the meeting not using PREMIS, and we ended the same meeting, 1.5 hours later, still not using PREMIS. It took us 90 minutes to decide that we should keep doing what we're doing. Verdict: Ridiculous that we took that long to hash this out.

Catalogers are not the enemy

One of my colleagues was at ALA, and sat in on a session sponsored by LITA called "There's no catalog like no catalog," or something like that. She said that she was in a minority by being a cataloger at this session, but that it was the attitude of the presenters that made her the most uncomfortable. She said that catalogers were portrayed as being inflexible, reactionary, and backward-thinking. She also said that she wanted to stand up and say "the real problem is that the library systems we use have never caught up to what catalogers actually need to do their jobs." That made me laugh. True.

But here's the thing: my colleague wasn't witnessing some small, misguided group of people who think of catalogers as Luddites and reactionaries. She was witnessing a microcosm of the thought of most of the information technology people out there today. I feel bad for all the catalogers when I hear talk like this (so I guess, really, I just feel bad for myself). Catalogers aren't backwards, they just want to create metadata for their objects, like anyone who has an object that they want other people to see. We use MARC for that. And let's face it, there isn't another metadata format out there that can rival the completeness of MARC. Most of the new metadata standards are still working out problems that this standard figured out 20 years ago.

I don't like the idea that we should throw the baby out with the bathwater. MARC is not the greatest, I realize that. Neither is AACRII, or LCSH. But they're not terrible, either. Speaking strictly from metadata schemas, MARC is still pretty awesome. It still does things that DC has never even dreamed of (and which we've been trying to squeeze into qualified DC with mixed results).

The need to create metadata is not going to go away just because someone decides that catalogers are obsolete. I don't know how some people think that we will get our information about information in the future, but one great example of the need for metadata comes from images. An image doesn't actually tell you anything about itself without you looking at it. So how do you search a database of images? You search the metadata that was created by someone who cared about creating metadata--ie, someone from the family of catalogers. You can call them something else if you want; data analysts or metadata-creation experts or whatever, but it's the same thing.

Anyway. This is my soapbox. I sigh a lot when I think about how abused catalogers have become at the hands of the techies. It's not like catalogers have created the downfall of civilization or the corruption of technology. In fact, we often wish that the search-mechanism creators would find a way to use the information we give them more profitably. Does that make us reactionary?

"The Really Obvious Stuff"

The other day, I'm sitting in a conference call, and we're talking about the creation of metadata for our big metadata project. And someone says "well, of course we won't be putting brackets around the supplied titles."
This stopped me in my note-taking tracks. We're not--what? What ELSE aren't we doing and why am I just now getting this sinking feeling in my stomach?
So I kind of keep quiet and ask my boss later, thinking that I'm just a silly new person who didn't realize that we're not doing this stuff according to AACRII. My boss comes back with "what??"
Hm. A conundrum. How did we get almost 8 months into this project without anyone knowing that we're not creating metadata according to AACRII rules?**
Well, very easily, in fact. It says quite explicitly in our metadata rules for the project that we're creating content by the DACS (Describing Archives: A Content Standard), and not by AACRII. Now, this makes perfect sense, because DACS is written with an eye towards machine-readable rules, and AACRII is written for cards. So things like brackets around supplied titles are fine when you're putting it on a card, but a database can't figure out that you didn't mean to include a bracket in the title, and will sort its indexes accordingly.
What this also means, though, as I found out in the meeting, is that we're not using abbreviations, or acronyms, except in cases of, and I quote "you know, the really obvious stuff."

I'm laughing right now, just typing it out again. "really obvious stuff"? Seriously, that's our rule? Is "cm" obvious? Is "Mr." obvious? What about "NJ", or "misc."? Man, I just laughed and laughed about this rule. And then I put my head down on my desk and cried.

I'm finding, more and more, that I'm banging my head against a brick wall just trying to explain to people that there is more to cataloging than just putting some random words down to describe an object. In fact, I also had a person say "how hard can it be to do subject analysis?" Holy Jesus, apparently a lot harder than you thought.





**While we are eight months in, we're just starting to create metadata, so this was actually a very opportune time to have this particular revelation.

Future trends, past traditions

The new paper put out by Richard Gartner this month in the JISC is....well, it's not saying anything that we don't already know. I've noticed that much of academic writing is just common sense stuff put down into words. If I could ever figure out how to do that, I would be a great and accomplished academic writer.
Anyway.
The paper is interesting; you can find it here (warning:pdf).
Basically, to use a metaphor (simile?), metadata schemas are like the parts of a car (simile!). METS is the frame, MODS is the engine, DC is the transmission, MIX is the mirrors....this simile is breaking down, a little, but you get the point. Gartner's idea is that once we figure out a way to bolt all the pieces together in a systemized way, we'll have a car and then everyone will be driving. So, once we finally, as a library community, decide to systematize all these different schemas and link them together and decide upon common access points, we'll have something akin to MARC and AACRII, where all the records can transfer to any library system, and everyone uses the same rules, and we can trade records and federate searches and everyone will eat ice cream every day and there will be puppies at every computer terminal.

The thing is, he's not that far from reality. I figure it really is just a matter of time before we come up with a standard for digital object description that uses pieces of MODS, or DC, or PREMIS, all within a METS wrapper. I mean, we're there NOW, we just haven't codified it yet. Who doesn't use those metadata schemas? It's the most organic kind of creation, without rules, yet we all follow a kind of Pirates' Code where we try to take into account all the traditions of library cataloging, use LCSH when possible, etc. (Also, if we could call this new code that will someday be created the Pirate Librarians' Code, I would be cool with that). There is a ton of tradition behind new metadata creation.

RDA is certainly our first step towards a system of creating metadata content that is standardized, and will work with both paper and digital, and is not based on the idea of catalog cards. At least I hope that they ditch all those crazy rules that only come from the idea of having a finite amount of space to write. I'm sure they will, the RDA group seems pretty smart. Much like AACRII and MARC, though, someone is probably going to have to come along and write one of those books like "Cataloging with AACRII and MARC21", because the RDA people will not want to tie their content standard to anything concrete, and all the librarians will just be sitting there wondering how in the hell they translate their rules from physical to metadata to digital. And I imagine that in five years, my reference shelf will have a copy of RDA, and a copy of "Cataloging with RDA and MARC" and a copy of "Cataloging with RDA and MODS" or something.

Ooh, maybe I can write one. Then I will be a Great and Accomplished Academic Writer.

Where the MARC meets the XML

TEI (Text Encoding Initiative) is not new. At all. It was born in 1987, although wasn't put into XML format until this century, I believe. Mostly, English nerds love it. It allows them to find patterns in literature that's been encoded, and differences across editions and versions. It warms their nerdy little hearts, and at the same time allows for the writing of more literary criticism than ever before possible. This also fuels the academic cataloging departments, of course, so I'm not complaining. Much.

Anyway, for this big project we're working on, we're taking scholars and having them do TEI markup on printed works and handwritten manuscripts of all kinds, and then everything will be searchable by keyword and etc etc. I think that tomorrow I'm going to write about TEI, and put in links and things, because I think that not enough librarians know a lot about TEI. But today, I'm going to talk about the relationship of TEI to MARC.

Yes. They have a relationship.

I noticed it right away while we were talking about the capabilities of TEI. The thing about it is--if encoded correctly, there's no need for a cataloging record. The TEI will have captured title, author, format, genre, extant, publisher information, year published, translators, as well as chapter and section titles. The search mechanisms then pull that information out directly from the digital document.
The caveat of course is that the document has to be digital. But think about it--you could easily have a catalog that pulls not only MARC records, but also TEI document information, and have both types of things in one catalog. There's not even really a need for a search portal--you could write a fairly simple program to pull information out of a TEI document and automatically generate a MARC record with it, and then import that record into your catalog. You could even do an 856 and link the whole thing together, and you could do it all with minimal effort on the part of the cataloger.

If there were other librarians at my desk with me right now, they'd all be screaming about subject headings, and yeah, this model doesn't do a thing for subject headings, but we don't create subject headings for manuscripts, anyway, really. It's too hard. And for printed books--subject analysis is a heck of a lot less of a time commitment than doing an entire record from scratch.

And when I think about it, MODS and EAD are the same way. Terry Reese at Oregon State has written a conversion program for EAD to MARC21, and I know that MarcEdit is the perfect platform for such things...but it's also not terribly intuitive all the time, and it only deals with EAD. We're fast approaching a time when having programs for conversion of other XML formats will be really, really useful...Why hasn't a little program been written yet? It's times like these that I wish I were a programmer. Unfortunately for me (but fortunately for humanity), I am not.

I just feel like we've given up on MARC, as a profession, when in reality, it's still pretty useful for parsing information and making it searchable. And these other metadata schemas all still take the same stuff out of the original and put it into machine-readable format...why not use the structures we have in place (like our ILSes) and put them to work?

Creating meaning

I've been reading up on RDA, FRBR, and metadata more generally over the past week (I have such a cool job). Anyway, as I was reading, and reading, and reading, I saw some things that grabbed my attention.

A lot of people who talk about RDA (and FRBR) talk about how these new concepts and new shifts in understanding are going to help us create meaning for our users. Instead of cataloging in a vaccuum, treating each piece as separate islands, we're going to be creating the connections between ideas and users and creators.

Now, shift over to TWO weeks ago, when I was trying to learn about our new big metadata project. I was talking to the project manager, and we were discussing how our group would assign subject headings and geographical placenames. The more we talked, the more I realized that the focus of this project does not lend itself to "traditional" ideas about assigning metadata.

In my other job as a cataloger, I might catalog a book about Nabokov, and then a book about English Victorians. These two things will have no relation to one another, and my job is not to try to find a connection (although in this particular example, what a great challenge!).

The thing is, in this metadata project, that is EXACTLY what they need. They need this map to be applicable to this book, or this book to remind a user about that manuscript. We're actively trying to create meaning for the user. Now, this is easy for us in this case, because everything pulled for the project is swirling around a central research topic. So it's not as if we're going to be using the entire LCSH in order to do this project. Instead, we're using just a small, interrelated fraction of that. So when I tell the other catalogers that we need to keep connections in mind, they totally get it, and its easy.

RDA and FRBR have a great ideal in place, and I love it, but I think that RDA is missing something really central in their thought processes. Even if you use machines to pull a lot of this data, and we use publisher information, and we stop caring about grammar and punctuation, it is still a ridiculously high expectation to put on catalogers to "create meaning" for the entire scope of human knowledge. I think its daunting for us to be doing this for researchers in a relatively narrow application, because we're never going to understand what those researchers really want. Maybe its time for librarians to adopt the archival perspective: We can't know what the user wants, so we give them the best we can give and they just have to figure out the rest. In that light, the ideals don't look quite so daunting.

RDA, FRBR, and other acronyms

I am SO GLAD that Karen Coyle gave her talk at Code4Lib on RDA. I myself have been asked to do a powerpoint presentation on RDA/FRBR for the cataloging department, and the points she’s raising are insanely useful (although also scary). She makes a good stab at talking about weaknesses and strengths of RDA without coming down on one side or the other.

Of course, in this blog, I don’t really feel like being unbiased. I will be for the powerpoint presentation, but not here! One of the useful things about being a nobody.
The thing that really gets me (and I commented on the FRBR blog about this), is that the RDA creators seem to be getting farther and farther away from what they said they would be doing, and that may force librarians to dislike RDA.

Some of the professed goals of RDA:

1. Create a more streamlined standard.
800 pages later, I’m questioning that one.

2. Hold true to the FRBR ideal.
They don’t use the attributes in FRBR to describe things in RDA. Why, I don’t know.

3. Make things easier for the user to find what they need, in the context of all knowledge.
RDA doesn’t address subject headings. And no one has ever heard of FRAD except the people on the RDA/FRBR/FRAD groups. And FRAD doesn’t do anything, anyway. It’s conceptual, just like FRBR.

4. Make the focus the content of the record, not the display of the record.
This is all well and good, but telling a cataloger not to standardize their records is like asking a fish not to swim. We’re trained this way! Taking the display rules out won’t automatically make us stop thinking about it.

5. Create a standard that archives, libraries, museums, and creators of digital materials can use.
No one except librarians is talking about RDA. I don’t see a lot of discussion (well, ANY discussion) from archivists or curators about RDA. Is this one of those “it’ll be for their own good” kind of initiatives? I think we all know how well MARC for archives turned out.

Episode IV: A new hope

I've been trying to find some information on what kind of workflows are out there for metadata creation. Let me tell you, it is harder than you think. But I did stumble across a new piece of software that will hopefully be coming out soon: Rutger Libraries' Workflow Management System (inventive title, no?). Code4Lib did an article about it awhile ago, so it's not like super-new news, but I've noticed that not everyone and their mom reads Code4Lib. No offense to the C4L guys--you all seem quite awesome.

Anyway Grace Agnew and Yang Yu wrote an article about it, and it's pretty interesting stuff. WMS is really just like Archon or Archivists Toolkit, except that it's for anyone that's creating metadata, not just archives. I like that aspect very much, since here at our instiution, most of the digitization projects are actually hybrid projects that use staff from archives, the library, and the digital people. I imagine it's probably at least a little more user-friendly than the archives software, mostly because of who created it. Archivists can be....not so user-centered sometimes. Again, no offense (I'm offending lots of people today!).

LCSH v. techies

There's a big digital project in the works here at The New Job. They're digitizing something like 400 works or pieces, and then some of us in the cataloging department are charged with creating the metadata. Not from scratch or anything, of course--the works are originally out of the archives here, so there's some basic metadata available. I've been meeting with people about this project a lot in the past few days, since I am the Metadata Librarian.

And I finally think I have a grasp on what it means to the be the Metadata Librarian. My job is to make sure that the catalogers don't feel like they're selling their souls, and that the digital people don't feel like they're being nickel and dimed by the catalogers. Case in point: LCSH.

This new digital project is going to be pretty cool--two institutions working together to create a federated search portal that other libraries/archives will be able to use, as well, in the future, all under one umbrella. It's not the most groundbreaking piece of technology I've seen, but still. It's neat that they're doing it.

They did a pilot metadata creation thing a few weeks back, as I understand it. One cataloger told me that they were given 6 days (really four, since two of the days were a weekend) to create metadata on 35 records. No big deal, right? Wrong. Apparently the metadata includes LCSH. And let's not forget, all the catalogers here have their "real" jobs, where they do all the other cataloging that needs to be done.
So the catalogers are all in a tizzy because they think (perhaps rightly) that the digitization people just don't get how long it takes to do subject analysis, not to mention filling in the other blanks in the metadata record. Oh, and did I mention that the catalogers didn't have anything to look at while they cataloged? The digitization people didn't think that the catalogers needed to see any of the pieces in order to catalog. How does subject analysis get done when all you have is a title?

Now, on the other side of this, the digitization people (this includes the project manager), think that the catalogers are exaggerating how long it takes to do things, and that their time table is going to get screwed up if the catalogers keep insisting on needing more things and more time. I think that the digitization folks believed that the metadata and digitization would be done concurrently, or even that the metadata could be done BEFORE the items were digitized. This is of course possible...but only if, as one cataloger said to me "we go upstairs with a notepad and catalog it by hand in front of the original."

I've already come up with several solutions in my head for this, and I think this is why they hired me. I like creating compromise. But that's not the "biggest" problem.
The biggest problem is that the digitization folks have now started messing with the LCSH field. They have started asking for non-LCSH terms to be used in that field. The catalogers are horrified, of course. I'm kind of horrified, too, but not because LCSH is so inviolate. More because the non-LCSH term they want is not a "subject" at all. It's a type of material. But I think I have an answer for that, too, if I can phrase it correctly. Then everybody wins. We have a meeting today; we'll see how it goes. Considering that I'm totally new, they might not even want me to speak at all. :)

Metadata Standards

I don't think of myself as a complete novice when it comes to metadata schemas. But I've never really taken the time to make a concerted effort to learn about them, either. I take them as they come. MaRC, EAD, Dublin Core--all of these I learned through practice, not a class.
However, I am taking a class right now! On metadata of all things! And while sometimes it's boring, many times it's....enlightening? Edifying? Anyway, it's pretty cool.
Something I've learned: even though I've always thought MaRC and EAD were the same thing, they actually aren't. MaRC is "discovery" metadata and EAD is "structural" metadata. Although they both facilitate use (which is why I thought they did the same thing), they come from different places. MaRC is for helping users search, and EAD is for...well, helping users search. But searching different aspects of the collection, not the subject of the collection itself.
I also learned about PREMIS (administrative metadata for preservation), and rights management metadata (also administrative). Having actual, bonified metadata standards is pretty cool.
When I was in grad school (lo these many 3 years ago), there really weren't any metadata "standards" per se. People were trying to pretend that there were standards, but no one was using them. Archivists weren't comfortable enough with digital anything, and librarians were still too invested in paper. My "digital archives" professor felt like she was banging her head against the wall when it came to getting archivists to start preserving digital materials. She would always, at every conference, stand up and tell archivists to start preserving their own born-digital records, in order to get experience in preserving other peoples' born-digital records, but I think that people thought she was just crazy. And she kind of was, but in a really great way.
Because now, not that far along in the future, people really ARE starting to preserve born-digital things, and to use the metadata standards that OCLC and ISO were creating back then. I used to feel kind of awash in fake-standards, but now, I feel very good about the tools that are out there, waiting to be used for creating records for born-digital items.
I even heard the term "digital archaeologist" yesterday. Yes, a person who used the preservation metadata to figure out what the digital object was, and try to bring it back to its former glory. This is particularly useful, these days, for things like 5-inch floppy disks and 8-bit files. At any rate, I love it. When are archaeology departments going to start offering digital classes? Get out your brushes!

Learning Metadata

I've been going through "the literature", as the kids say nowadays, on metadata creation. Reading snippets of books published 3-4 years ago, reading blogs, reading articles, reading powerpoint presentations, watching webcasts (tangentially, have you noticed how many ways there are to disseminate information these days? whew!).
A question has been put to me "describe how cataloging departments can balance traditional cataloging functions with emerging technologies." Ok, that's not a question, really, but you get the idea.
And the answer is---I'm not sure. I actually think the question has a lot more to do with the idea of a "traditional" cataloging function than it does the emerging technologies. Traditional implies "old", doesn't it? Maybe "quaint". Something that's been around the block a few times, at least. But I don't think that, at core, cataloging functions are changing at all. And I certainly don't think it's about striking a balance. Because technologies are just tools.
I know that many catalogers (and computer scientists) think that the technology IS the function. MaRC is what we do in cataloging! EAD is what we do in archives now! But that's just not true. In reality, we SERVE. That's what we do.
As I've said before, I can be what many catalogers would call "lax" about the AACRII. The only reason I am, though, is because I don't see how it benefits users, in all cases. If a user needs to see something in order to understand the work better, then I give it to them, in any way I can. This can lead to bending or breaking of the rules, but so be it. I'm not a cataloging slave (that's reserved for my student-workers).
When we were in graduate school, I remember the students in the cataloging course that needed to know the exact right way to catalog everything. My cataloging professor told them over and over that the "rules" are not really rules at all; that there exist many different ways to catalog any given work/manifestation/item.
I think that the question I've been posed could benefit from this advice. Why do I need to balance my duties with technology? Don't I use my technologies to do my duties? Isn't that the point? I think maybe the question was designed to make me think about how cataloging is changing. And it is, I know it is. But I think that all these "monster" changes that are taking place are just semantics. If I start using Dspace instead of Horizon, the only thing that has changed is that I'm now focused on making electronic resources available rather than paper resources. And my goal is the same--give the user everything I possibly can to help them get their information. The balancing act is how do I serve, not how do I remember to put a colon after the title statement.

Metadata for Manuscripts

There are lots of different kinds of metadata out there for library and archival materials. Some might say, too many kinds. There are different metadata schemes for every kind of material. There is Dublin Core, METS, MODS, even Marc for XML. All these metadatas are trying to solve an age-old problem with archival materials: they're too unique to have a standard applied to them. Books are easy; they all have title pages and authors and they're all wrapped up in neat packages that lend themselves to cataloging. Archival material, on the other hand, can be anything--and usually are. Paintings, bills of sale, letters, buttons, book manuscripts, musical instruments. The list goes on and on. And, especially with paper things like letters and bills, there is the problem of having so much paper on your hands that you cannot simply describe every single piece of paper as a single entity. So we group things, and then we catalog the groups. More or less. It's an inexact science.
At least, it was until the standards started getting made. Dublin Core and METS and MODS are all designed to help archivists catalog the things that are uncatalog-able. And now there's a new(ish) metadata standard: PREMIS.
PREMIS stands for something fancy, but at core, it is preservation metadata. Yes, now archivists can code not only information about the creator and the date and the content of a piece of paper, but also the physical condition, history of the physical condition, and any repairs that have been made to the paper.
Are we getting over-metadata'ed? Do we really need metadata, encoded into XML, that tells us if something is fragile and old? Can't we go to the paper itself and see what condition its in? Or this strictly for statistical purposes?
I've made myself a copy of the PREMIS manual--all 283 pages of it. So, we'll see what this is supposed to do/be. It can't be for the users of the material (which is generally who I consider metadata to be for), so it's not something that should be displayed to the user, probably. And a lot of archives don't even have the time to go through and process basic information, let alone preservation data. Maybe this is one of those things that is reserved strictly for libraries where everything is already processed and they have lots of extra time on their hands to go through and put in fuller, more complete information on each and every collection. Good on them, I say.