Comments on: Future of MARC http://www.web2learning.net/archives/1251 Web 2.0 and programming tips from a library technology enthusiast, What I Learned Today... covers blogs, rss, wikis and more as they relate to libraries. Sun, 27 Jul 2008 00:31:01 +0000 http://wordpress.org/?v=2.6 By: Kevin S. Clarke http://www.web2learning.net/archives/1251#comment-62076 Kevin S. Clarke Tue, 09 Oct 2007 02:30:12 +0000 http://www.web2learning.net/archives/1251#comment-62076 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. :-) 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. :-)

]]> By: Nicole http://www.web2learning.net/archives/1251#comment-62018 Nicole Mon, 08 Oct 2007 20:20:29 +0000 http://www.web2learning.net/archives/1251#comment-62018 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. 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.

]]> By: Kevin Clarke http://www.web2learning.net/archives/1251#comment-62015 Kevin Clarke Mon, 08 Oct 2007 19:47:46 +0000 http://www.web2learning.net/archives/1251#comment-62015 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. 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.

]]>