No public Twitter messages.

Facebook
RSS

Future of MARC

Oct - 4 - 2007
Nicole C. Engard

I feel like I should duck after hitting submit on this post – I might be opening up the flood gates – but here it goes!

My friend (and colleague) Chris Schwartz has written about the future of MARC (and probably will have many more posts on this topic).

When it is mentioned, MARC usually gets a bad rap. It’s often viewed as worn out legacy metadata better suited for card catalogs with an antiquated late 1960′s data structure that mystifies computer programmers when they first encounter it.

Personally, I wasn’t mystified when I first saw MARC – it all made perfect sense ;) What doesn’t make sense to me are the silly ISBD punctuation rules – these are what’s really being carried over from the card catalog days.

My opinion on the matter? Well, I don’t think MARC can go anywhere. It’s at the center of nearly every library system – and I’m not sure that’s a bad thing. The way that MARC breaks up our data into parts makes it much more searchable. By breaking things down into pieces you have access to very detailed levels of data.

Now, you might be saying – who in the world needs that level of accuracy? Well, there are many researchers out there who want to find the edition that was published by publisher X in town Y and by having a schema that allows access on that level we make it easier for them (now the fact that our systems don’t offer that functionality is a whole other issue – but the point is that it is possible).

It is this level of detail that has me pushing for our library to use MARCXML for our digital collections – it just makes the most sense for our very specialized collection and patrons. I want to be able to provide searchabilty down to the tiniest level if the user wants it. My only complaint about MARCXML (if you want me to get techie on you) is that every field is titled “datafield” and the attributes are were you get the MARC fields.

<datafield tag=”245″ ind1=”1″ ind2=”0″>
  <subfield code=”a”>A. Janse over Karl Barth /</subfield>
  <subfield code=”c”>samensteller: J. L. Struik.</subfield>
</datafield>

Why not have it like this:

<m245 ind1=”1″ ind2=”0″>
  <a>A. Janse over Karl Barth /</a>
  <c>samensteller: J. L. Struik.</c>
</m245>

Which probably has some validation issues – but you get the idea.

I didn’t mean for this to turn into an evaluation of MARCXML, so I’ll leave the XML discussion at that for now.

The way I see it, MARC does what it needs to do – it’s the rules surrounding our cataloging (AACR2 & ISBD) that are holding us back – and for that reason (and the one I mentioned earlier about it being central to our systems) I don’t think MARC is going anywhere soon.

Technorati Tags: , , ,

3 Responses so far.

  1. Kevin Clarke says:

    Hi Nicole,

    Interesting… it sounds like you’re saying if we fix the content standard(s) we would want to put the new data back into MARC (now better organized than it was in its original MARC form)?

    Two questions… Would you say the fixed fields should be continued to be used or just the variable length ones? Also, you don’t think our new content standard(s) would need any more depth than field/subfield? Thanks.

  2. Nicole says:

    Fixed fields hold a wealth of info – but it’s almost never used (not that I’ve seen). I’d like to see that data put into a more readable format – if you can call MARC readable – or I’d like to see it at least used in it’s current form – other wise throw it away – it’s a waste of our time.

    Our new standard had indicators as well as field & subfield. By putting in 246 14 Gate to Women’s Country. I’ve just told the system that this is an added entry and that it’s the cover title – what other fields/levels of fields would you recommend?

    It’s also important to note, that this all depends on the catalogers that be throwing their pickiness out the window – no more abbreviate this, but only when it’s here, and transcribe this but only when it’s there, and remember that darn period, oh no wait it’s a semi-colon — it’s all nonsense!!! It’s not necessary now that we’re not using cards anymore – in fact the system can be programmed to put a colon after field 300 subfield a when it displays!

    Lastly, I’m not saying that MARC is perfect – just that it’s central to all of our systems – and it would be very very expensive for most libraries to migrate their data to a new format – so, unless there’s a magic free migration tool to this new amazing format we’re all going to use – then I think we’re going to have MARC for a while.

  3. Kevin S. Clarke says:

    I agree we’ll be using MARC for awhile (I think the shift away from it has started though — mostly because we’ve started looking at really reorganizing the data in MARC). I was wondering, though, more about the expression of relationships between parts of the record. I know this is done to some extent in linking fields in MARC. I just wonder if there aren’t better ways (richer relationships which could be brought out given a different markup standard in which to put them).

    As for other levels, one possible place would be dates. I assume we’d want to have dates in a standard format and consistently handled across our new data structures. There is a lot of information about dates in MARC that is sort of encoded in the data itself ([19uu] or 1943? — indicating ranges, certainty, etc.) Would dates move into a field so that subfields could be used to indicate additional information? If so, how do the dates get related to other aspects of the record (it’s currently in subfields to indicate a relationship with data in other subfields in the same field)?

    Using MARC in such a different manner though would be just as hard on our current systems. It’s not the MARC that is central to our current systems. If there really is a separation between MARC and our content standards, then MARC is just the transmission format (and input/export modules are pretty easy to swap out). It’s the data in MARC (the content standard) that keeps us using MARC in my opinion; if we swapped out the content standard(s) — the tough part — swapping out the MARC piece would be relatively easy, I think.

    Not sure if this is coherent or not. My mind is thinking about the packing I should be doing for my flight out tomorrow morning to Access 2007. :-)


Bookmarks for July

Today I found the following resources and bookmarked them on ...

Bookmarks for July

Today I found the following resources and bookmarked them on ...

Bookmarks for July

Today I found the following resources and bookmarked them on ...

Bookmarks for June

Today I found the following resources and bookmarked them on ...

Bookmarks for June

Today I found the following resources and bookmarked them on ...