What do you mean, you don't have metadata experience?

(This has been in my drafts for a while. I finally decided to publish it. Maybe one of these days I'll publish all the other drafts I have sitting around.)

A few weeks ago, a cataloger who thought she might soon be unemployed emailed one of the listservs I subscribe to. One of the things she wrote really caught my attention: “The few cataloging jobs that I saw required metadata experience, which I don’t have…”

I could say who wrote this and when it was written, and the post can be found in this particular listserv’s archives, but since I don’t know if this person would be ok with her name also being in a blog post, I’m not including it here. The important thing is simply that she wrote this, and that this is not the first time this has come up.

Offlist, I emailed her about this statement, saying that, actually, she does have metadata experience. MARC is a metadata standard. In fact, it’s a very complicated and unintuitive metadata standard – lots of fields and subfields. The average person, looking at a list of MARC fields, would probably not be able to immediately equate, say, “245” with “Title statement,” and yet for many catalogers who regularly use MARC it actually becomes more comfortable to see fields and subfields rather than plain English labels.

If you know MARC, you have metadata experience. You may not have experience with Dublin Core or EAD or ONIX or XML or whatever else, but you do have metadata experience, and you can apply what you have learned from MARC to learning another metadata standard. (This, of course, takes an employer who is willing to train you or give you the time to get trained - which is a valid worry, what with all the employers who seem to want new employees who can be put to work with little or no training.)

Not everyone writes or talks about MARC and metadata as if they are two completely separate things, but it has still somehow been embedded in some people’s brains that they are separate things. On listservs and in blogs, I have read complaints from people that catalogers aren’t very good at recognizing transferable skills. The mental separation of “metadata” and “MARC” is, I feel, one of the main reasons why this is so, and it cripples catalogers and makes them afraid. Skilled catalogers don’t think they are qualified to be metadata librarians (or whatever else they are called). They think that what they do is becoming obsolete.

I do believe that, one day, catalogers will probably be using something other than MARC. However, I don’t live in fear of my future and my career(*)…because I believe there will always be a place for someone who can create and edit metadata. I can learn a new metadata scheme if I need to. After all, I learned MARC.
.
.
.
If you'd like to know more about MARC's place in the metadata world, check out "A Visualization of the Metadata Universe." Actually, this shows you the place of 105 metadata standards - it's awesome and kind of pretty.
 
 
* - I do worry that, one day, there won't be any jobs for people like me in libraries. I could work for a corporation if necessary, and almost ended up at one during the course of my post-grad school job search, but I'd prefer to work for a library. With all the outsourcing that's going on, however, that may not always be possible.

Something cool - Amazon to MARC and IMDb to MARC

The Amazon to MARC converter takes information from Amazon.com book records and turns it into MARC. I don't see myself using the MARC records this produces, because the records would take so much cleanup that it might actually be easier to start from scratch, but I still think it's pretty cool. Plus, some aspects could be useful for my work: I could copy and paste summary information from here and avoid (I'm pretty sure) having to hunt down quotation marks and apostrophes that Connexion doesn't like, and I could potentially use this as a starting place for call numbers and subject headings.

The IMDb to MARC converter (prototype) takes information from IMDb and turns it into MARC records. I think this converter's output is actually even more helpful than the Amazon to MARC converter's - video recording MARC records take a lot of work, because of all the name access points and various notes. This would take care of some of that work, although there'd still be a lot of fixing and fiddling to do. I love the "verify names" feature (also present in the Amazon to MARC converter). I could see this tool being especially popular with libraries that, in order to save time, have a policy of basing video recording cataloging on container information - this would probably help them save even more time. Again, as with the Amazon to MARC converter, I probably wouldn't use the MARC records produced by the IMDb to MARC converter, but there are still certain things I could copy and paste into the records I end up using in Connexion.

UPDATE: The Amazon to MARC converter doesn't just do book records - I just had it generate a record for a DVD, VHS, and CD. The "classify" information seems to be drawn from OCLC - too bad, I was hoping it could help Tracy and Trudy in those cases where they have trouble finding OCLC records that match the Contemporary World Music records they're assigning call numbers to.

More webinar fun

I started viewing the Library of Congress's webcasts for librarians after Yvonne emailed me to let me know about Life Beyond MARC. I watched that one - I was relieved to see that it did not advocate abandoning MARC, as I have always felt that MARC isn't nearly as useless as some people say it is, it just isn't utilized very well by most integrated library systems. I see and code so much information in our library's bibliographic records that is never used in our OPAC - not for limiting, searching, or even necessarily for keyword searching (this last one was a surprise to me, since I had just sort of assumed that everything in a variable field was keyword searchable - I've learned quite a bit by talking to Tracy). I find this frustrating, but I continue to code and check "useless" information in the hope and expectation that our ILS (or whatever ILS we may use in the future) will start using this information.

After watching that webcast, I watched Cataloging Principles and RDA. It sounded nice, but it still strikes me as odd that the updated cataloging principles were developed and released after work on RDA had already begun. Indeed, RDA is supposedly almost ready for use (I say "supposedly" because I am one of the catalogers who believes RDA still needs a lot of work). Shouldn't you establish principles and then use those to inform the development of rules?

Well, there are still plenty of Library of Congress webcasts to view/listen to, so I think I'll continue working through the list. Although the webcasts come with visuals, I've found that they're still fairly comprehensible, even if all I'm doing is listening to the audio as I catalog.

A way to search individual MARC fields

I just found out something incredibly awesome from someone on the AUTOCAT listserv and thought I'd write a quick post about it before I forgot.

For a long while now, I've wished that there were a way to search for information in particular MARC fields. For instance, say I want to find something by a particular publisher. This isn't the best example, but maybe I'm looking for something published by "Harcourt." It's possible to do a Title search, Author search, Subject search, etc., but it's not possible to do a publisher search - except, it turns out that there sort of it, if you know what you're doing.

If you didn't know what you were doing and wanted to search for books published by Harcourt, you'd probably try a Keyword and "Words or Phrase" search for "Harcourt." At the time of this post, you would retrieve 2,111 results. Lots of them are published by Harcourt, but some of them aren't.

If you did know what you were doing (and you were using a Sirsi catalog, which is what DSL uses), you would still do a Keyword and "Words or Phrase" search. However, instead of searching for "Harcourt," you would try:

Harcourt {260}

You would retrieve 2,057 results - as I said, this isn't the best example, but even with this example you can see that the search became more specific. The results will more accurately reflect what you wanted to retrieve.

The numbers in the curly brackets are a field (I think Sirsi calls them tags in their documentation) value. In MARC, the 260 field includes publication and distribution information (it can also include a few other things, but, in our case, it usually doesn't). By using the curly brackets, you are limiting the search to a particular field.

As a cataloger, I find this to be nifty news, and I think I need to figure out how to get the news out to the other librarians at DSL. Unfortunately, as a cataloger I also understand that the number of people who will be able to make use of this search is very limited. Even when told about this search, most people still wouldn't be able to use it right off the bat. First, you'd have to know which field you wanted to search - I don't think many of the librarians at DSL besides myself know even the most basic MARC fields (but you can try looking them up here), since they tend to deal with the more people-friendly side of things. Our users certainly won't know the fields. Second, for some fields, it helps to know how cataloging rules work. For instance, the rules allow for publishers' names to get abbreviated. You might see "John Wiley & Sons" in our catalog, but you might also see "J. Wiley," or (I think) even just "Wiley."

Still, it's exciting news. I tried to do a genre (field 655) search using this method, and it didn't work out, but I'm going to see if I can figure out how to fix that. I'll probably have to talk to Tracy, who might have to talk to the Sirsi people...