Re: Yes but

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