Home > aacr2, marc, RDA > Replacing MARC

Replacing MARC

Recently conversation erupted on RDA-L that was initiated with a question about a subjective statement in a MARC Bibliographic tag 300 field (specifically the subfield b). Basically someone had input “illustrations (some coloured, all beautiful), maps ;”  in said subfield. The subjective bit is the “all beautiful” and the question was regarding if RDA allowed for subjective comments such as this within the MARC record. A side discussion arose regarding the spelling of color/colour. Much back and forth occurred and you can read about it yourself on RDA-L, OCLC-Cat, AutoCat, etc.

Jonathan Rochkind of Bibliographic Wilderness made a statement that no one else seemed to focus on. He said:

Which is why in an ideal world, if we care about whether the illustrations are colored or not (and I suspect the time is LONG gone when our patrons or we actually DO), there would be a data element in the record which marked, in a machine interpretable way, whether there are illustrations (checkmark HERE), and whether they are colored/coloured (checkmark THERE). Which could then be translated to the appropriate spelling or even language for the given audience.  [more to read in the original post]

Exactly! The data element should be in a machine interpretable way! The programming should be able to output as we required. This is what Karen Coyle and others have been saying for some time now. The majority of cataloging should be data entry-like.

WHAT????  I am saying the basics should be basic data entry. It will still require knowledge to input the data as well as determining call numbers, subject headings, etc. But the basics should be check here, type an arabic number there, etc – you know, like filling out a form online.  This would be part of parsing out all the data into different fields or subfields or data areas or whatever-you-wish-to-call-it.

Why do this? It promotes consistency. It promotes easier sharing. It promotes tons of options for searching the data.

One of the reasons for RDA is to separate AACR2 from MARC Bibliographic. It is said to move ahead in the semantic web world, we need to separate the rules from the format or input mode. Yes, we do. AACR2 and MARC were ‘married’ in the 1970s. It is time for the D-I-V-O-R-C-E. I do wish we’d moved away from MARC first before killing AACR2 or, ideally, done it at the same time. Yes, I think we’d still have tons of issues and discussion and perhaps arguments but trying to force RDA into MARC Bibliographic is like trying to play baseball with a badminton racket.

Advertisements
Categories: aacr2, marc, RDA Tags: , ,
  1. March 8, 2011 at 7:43 am

    I’m not a cataloguer (should that be cataloger?) by any means, but am interested in catalogues and resource discovery so can not nod my head hard enough.

    HTML uses US English for its markup. This is essential, browsers can understand/interpret font-color, they do not understand font-colour. End users never see the attribute (just the coloured text) but using an English word helps web developers and lowers the learning curve.

    I think this provides a good example of where we need to be. We need a flag/string/word/attribute to define coloured illustrations, that word can be one which is meaningful to cataloguers, but there should be no assumption that the same word will be displayed on screen (because of dialect, audience – eg children – or language).

    Surely the whole point of structured data is to make it work for you. To filter, refine, restrict etc. Using various terms to mean the same thing makes this near impossible.

    I’m sure this has already been discussed endlessly already (and I note kc’s comment in the mailing list thread referred to mentioning a vocabulary) so apologies if I have poorly reinvented a much reinvented wheel.

    • March 8, 2011 at 8:30 am

      Excellent points Chris! I agree! We also need to divorce the display from the input format. That is, why should I know what kind of punctuation to place after various elements in MARC Bibliographic subfields? Why should I worry about color/colour in the input form? I should be able to check a box and display as I desire or rather, as my patrons would find most useful. We do this to an extent now but parsing out the data as kc and others advocate would aid this a great deal.
      There are a few initiatives such as open metadata registry (http://metadataregistry.org) and VIAF (http://viaf.org) that address standardization and cross referencing of languages and variations within language.
      I think it is becoming more and more glaringly apparent to people, especially as RDA ramps up. Or maybe I just live in hope.

  2. March 8, 2011 at 8:42 am

    There’s a PCC Task Force in place that’s starting work on divorcing MARC from the use of ISBD punctuation. It’s not truly AACR2 that’s the issue, it’s that ISBD punctuation is serving 2 masters at the same time (display AND encoding elements) and has become embedded/intertwined with MARC in the process.

    See: http://www.loc.gov/catdir/pcc/ISBD-TaskForce.html

    Replacing those ISBD punctuation with actual MARC codes (subfields, etc.) will be an important first step towards making the data within MARC more parse-able and ultimately usable and accessible. It will greatly increase our ability to perform maintenance by batch and crosswalk our data (which we don’t want to lose) into other formats for easier sharing.

    That said, MARC is past it’s prime and we need to move on. It was brilliant for when and why it was created: for sharing bibliographic information about monographic textual materials back in the 1960s. The problem isn’t MARC, it’s that we’ve continued to use MARC and shoehorn into it other formats for which it was never intended to be used. We’ve been pounding pegs into holes that they don’t quite fit in, and then trying to plug the holes left around the edges. It’s not pretty.

    There are several barriers to leaving MARC behind, most notably that it will be EXPENSIVE (and yes, I meant to type that in all caps). But, as a profession, we’re going to have to bite the bullet if we’re going to truly embrace linked data and the semantic web and all it can do for us and our users.

    • March 8, 2011 at 9:30 am

      Absolutely! And you’re right it is going to be very expensive, especially if we cannot determine a way to get the majority of information parsed out easily (I do not think we’ll be able to get a perfect extraction). And you’re right, MARC was brilliant in its day. In fact, I’d say MARC was brilliant up until maybe the late 1980s, early 1990s then it began to date rather quickly. We will have to gain the support of traditional ILS (or automation systems or LMS or whatever you wish to call them) as they have been programming to MARC since day 1 and have yet to stop and even make a nice little WYSIWYG for cataloging modules (or at least I haven’t seen one).

  3. March 8, 2011 at 8:55 am

    Well UKMARC had the punctuation thing working well a looooong time ago 🙂

    I agree, though, there is so much potential to let the systems do the work wrt display/language or phrasing. And yes Shana couldn’t be more right. We need to bite the bullet.

    I’ve seen an argument made that it was too much to change encoding scheme + cataloguing content rules at once so a(n arbitrary?) decision was taken to start with content rules (RDA) in the hope this would force the issue of encoding scheme (MARC). I see more and more instances where this is happening so hopefully it will keep snowballing until something happens.

    • March 8, 2011 at 9:35 am

      Awesome on UKMARC! I didn’t realize that, what other great things are you “hiding”?
      I’ve seen this same argument but isn’t it like pulling a bandage off? You can peal it off slowly and prolong the pain or you can yank it off quickly and have a quick burst of pain. Either way, it will be painful. Either way, it will be expensive.

  4. Deanna
    March 9, 2011 at 4:13 pm

    You’ve made an excellent point. If we did this as more of a data entry thing, consistency should improve considerably. There are some out there that will certainly screw it up some, but overall, there should be a leap forward in consistency. I’d also like to see some sort of “suggesting” with subject headings, just like happens when you search Google. You start typing in “Man-woman re” and the box underneath lists valid subject headings that start with that string. To make it even better, certain things would cause a pop-up that says “You dolt, that’s a genre heading so use 655 instead of 650!” or “Fool! Geographic locations go in 651. Now fix that tag or else face the flogging of your life.”

    • March 9, 2011 at 6:18 pm

      As much as I enjoy a good flogging (no, not really) … I think it should have a text tag stating “Genre” or “Geographic Subject Heading” rather than 655 or 651. Further I think the text tags should be customizable – both from the cataloging module perspective AND the public view perspective. Why can’t we? Why should I have to know what a 651 is? How long do we have to suffer? Then again, we are able to ‘lord’ our extensive MARC knowledge over others – tell the truth non-catalogers, you’re jealous of our ‘secret’ language, aren’t you?

      • Deanna
        March 9, 2011 at 6:47 pm

        You are right, the text tag is all we really need when it comes down to it. But I still think flogging for those who put incorrect data in a tag is a good idea, at least for those who do it more than once every 100 records.

      • March 9, 2011 at 8:05 pm

        *sigh* when did cataloging get so violent?

  1. March 17, 2011 at 4:15 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: