Re: Yes but

I did some analysis of the MARC format at one point. You can see a bit on futurelib:
   http://futurelib.pbwiki.com/Data%20and%20Studies
If nothing else, the data shows how much redundancy there is -- redundancy and inconsistency. I also have there the whole MARC format in a tab delimited format. It's easy to sort and re-sort and get an idea of what's in the format, and easier to see it (at least for me) in a database format.

kc

-----Original Message-----
>From: "Diane I. Hillmann" <dih1_at_CORNELL.EDU>
>Sent: May 11, 2007 4:52 PM
>To: NGC4LIB_at_listserv.nd.edu
>Subject: Re: [NGC4LIB] Yes but
>
>Karen, Jonathan, et al.:
>
>Yes, it's true: when we look closely at how AACR2 and MARC21 work
>together, we see a history of expediency and kludges, all intended to
>help us keep doing what we're doing with the least possible
>disruption.  To a great extent, we knew what we were doing (had no
>other choice, really), but the edifice we created is looking
>seriously creaky.
>
>What would be nice  at this stage would be a careful categorization
>and analysis of what purpose each field/subfield in MARC actually
>serves.  Is it there to support some descriptive or relationship
>need? Is it administrative in nature (about the metadata, not about
>the resource described?)  To me the need for this is obvious as we
>consider the implications of new agreement between RDA and DCMI, and
>how we would move forward from that point.
>
>The fact is, we need an upgrade path for MARC21.
>
>Diane
>
>>Well said, Jonathan. If you look at any of the "crosswalks" that
>>have been done between RDA and MARC, you can see that they are only
>>including the fields from 100-899. Essentially it has been decided
>>that everything in the 00x and 0xx range is not part of the
>>cataloging rules - so what are they part of_. And there are many
>>fields in the range 100-899 that have no equivalent in RDA and
>>perhaps should NOT have one. I really do feel that we've got
>>multiple competing standards - well, maybe "competing" isn't the
>>right way to say it. We definitely have multiple standards that are
>>applied to create our catalog records, and I'm not at all sure that
>>they work as well together as they should. We have AACR2, we have
>>ISBD, we have ISO 2709 (MARC record format), we have MARC21. Note
>>that we also have multiple standards creation points - JSC, LoC,
>>NISO. This, too, seems to be problematic to me because there isn't a
>>clear division of responsibilities between them.
>>
>>kc
>>
>>-----Original Message-----
>>>From: Jonathan Rochkind <rochkind_at_JHU.EDU>
>>>Sent: May 10, 2007 4:35 PM
>>>To: NGC4LIB_at_listserv.nd.edu
>>>Subject: Re: [NGC4LIB] Yes but
>>>
>>>The first step to getting out of MARC is removing any _guidance_ from
>>>MARC, and removing any _data model_ from MARC. MARC ought to be an
>>>encoding format. If MARC really _was_ just an encoding format, than it
>>>would be easy to use other encoding formats too.
>>>
>>>But in fact, significant portions of our mostly implicit data model
>>>(and subsequent 'element vocabulary', in what I believe is the language
>>>of DCAM) are really in MARC. Significant portions of our value
>>>vocabularies (what is the mini-controlled vocabularly for this field)
>>>are in MARC, significant portions of our content guidance (how do you
>>>choose this value) is not in fact in AACR2, but in MARC. We need to put
>>>all that stuff where it goes. Once we've done that, then MARC is just
>>>another encoding format, and we can much more easily switch to a
>>>different encoding format, and use multiple encoding formats
>>>simultaneously.
>>>
>>>If the DCMI/RDA thing goes like many of us hope it will, it will be a
>>>significant step in that direction, just by helping us to be clear about
>>>what RDA is, what our element vocabularies and guidance are. But it will
>>>still leave a lot undone too, in large part becuase of the things that
>>>RDA doesn't even cover, that are just left to MARC when they ought not
>>>to be!
>>>
>>>Jonathan
>>>
>>>K.G. Schneider wrote:
>>>>>  The MARC issue seems a lot more relevant than the issue of 'proprietary
>>>>>  and outdated' software? Our ILS uses an Oracle db to store the
>>>>>  information, and can provide an xml interface to the data - surely it's
>>>>>  the data formats that are the issue here. Although the data is 'held' in
>>>>>  the system - to a large extent the system does a lot of work to extract
>>>>>  the relevant information from the MARC records (which we've insisted on)
>>>>>
>>>>>  Owen
>>>>>
>>>>>  Owen Stephens
>>>>>  E-Strategy Co-ordinator
>>>>>
>>>>
>>>>  Yes, I almost didn't add a comment about our software, though that comes
>>>>  into play. It interested me that the RDA-DC agreement that Karen Coyle
>>  >> wrote about went unmentioned because de-MARCing MARC seems to be pivotal
>>>>  to serious change.
>>>>
>>>>  K.G. Schneider
>>>>  kgs_at_bluehighways.com
>>>>
>>>>
>>>
>>>--
>>>Jonathan Rochkind
>>>Sr. Programmer/Analyst
>>>The Sheridan Libraries
>>>Johns Hopkins University
>>>410.516.8886
>>>rochkind (at) jhu.edu
>>
>>
>>Karen Coyle - on the Road
>>kcoyle_at_kcoyle.net
>>skype: kcoylenet


Karen Coyle - on the Road
kcoyle_at_kcoyle.net
skype: kcoylenet