Re: [RDA-L] More granulalrity if imprint year coding?
Hal Cain wrote: snip Quoting Deborah Fritz debo...@marcofquality.com: I think that what John actually said was and *not just* with regard to the 260 field, my emphasis added, i.e., plans are afoot for adding granularity to the 260 *and* other fields. Which is certainly good news-for however long we are going to continue to use MARC for RDA. Which for some will be a long time, I think, seeing how many smaller libraries I know that have little or no prospect of getting funding for replacing their existing MARC systems. On the other hand, some will need specialist help to rejig their MARC mapping to accomodate RDA records, but that will come rather cheaper than system replacement. It would be a service to us all to be able to incorporate new MARC subfielding (such as in 260) in one operation. /snip I agree with Hal on this: any changes will take an awful long time to percolate through the system. The purpose of my original post on this topic was to point out the difficulties of everyone agreeing that this particular item I am looking at is the same as this other particular item I am looking at. In other words, I was trying to point out the real difficulty of determining what is a manifestation. It is only a matter of *definition*, and different bibliographic universes will define their equivalent of a manifestation in different ways, and not only that, each individual cataloger/metadata creator who works within a separate bibliographic universe--all of whom may be highly experienced and knowledgeable--will also interpret things in their own ways. I cannot imagine that another bibliographic universe (e.g. publishers, rare book dealers, etc.) will change everything they do simply because our bibliographic universe changes our definition of what is a manifestation. After all, we wouldn't change for them. If something that should be one of the simplest aspects of cataloging turns out to be so difficult to reconcile in practice (This is--or is not--a copy of that), then how in the world does that leave us with any hope at all to reach agreement on expression and work, which I don't think anyone maintains are simpler in any way at all? Finally, our records can no longer be considered separately from other records in different bibliographic universes out there, and they *will* (not must) interoperate all together somehow! Understand my despair? So, my concern is not so much that we need additional subfields (although Jonathan is absolutely right about systems needing them), because additional subfields necessarily increase complexity. Greater complexity should be avoided because it takes more time to do and catalogers need to be trained to input information consistently, otherwise we get hash. Just adding a bunch of subfields that are misused serves no purpose. Nevertheless, in certain *rare* cases however, adding subfields may actually *simplify* cataloger's work and in my experience, 260$c may be an example of one of those cases. Or maybe not. I think it should be considered, but practical considerations (i.e. simplification) need to take precedence. James Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome via Pietro Roselli, 4 00153 Rome, Italy voice- 011 39 06 58330919 ext. 258 fax-011 39 06 58330992 First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] More granulalrity if imprint year coding?
Yes to what James says. In addition to for the cataloger, for software. It isn't reasonable to expect that software can take a bunch of different dates stuffed into a $c and figure out which is which -- and what's the point of recording multiple dates if not for software to do something with them to serve the user? I think the RDA folks should take another run at MARBI and try to get more subfields. Yes, we're running out of subfields in Marc. But data recorded without sufficient granularity to reliably and unambiguously pull it out again by machine processing... might as well not be recorded. On 11/24/2010 1:44 PM, Weinheimer Jim wrote: J. McRee Elrod wrote: snip James Weinheimer suggested on Autocat: I believe the basic problem lies in the 260 $c - Date of publication, distribution, etc. We are simply putting far too much information in this [sub]field ... Subfield code 260$d is available for copyright year as opposed to publication year. But whether separate subfield coding would be an advantage to patrons depends of how it is applied in RDA. /snip My suggestions for adding more subfields for additional types of dates is not for the purpose of the patrons at all, but I was thinking of the needs of the (gasp!) cataloger, for the purpose of making cataloging easier. Let me explain: There are just too many types of dates attached to a resource: date of creation, date of issue, date of publication, date of update, date of research, date of the list can go on and on, especially as we address the multiplicity of web resources. In my own experience, figuring out which date(s) to add and which date(s) to ignore, in addition to learning or teaching the intricacies of it all has been a real pain, and ultimately it hasn't worked very well. Added onto this the expectation that everyone will decide matters in the same way(!) is, in my opinion, completely unrealistic. For example, one thing I have seen many times in relatively simple book cataloging--from LC copy, too--is mistaking the printing date for the publication date, but there are many more problems than this, as the apparently simple example on Autocat showed. What will happen when it really gets tough? Looking around for a sustainable solution, it occurred to me that the problem is that we are shoehorning too much into the single date $c. I am sure we can all point to major problems today, and especially as we include the records of other bibliographic agencies into the mix (at least I hope we get some help somewhere!), most probably with all kinds of different practices, it is clear that maintaining the current situation which doesn't work very well is unsustainable. There needs to be a change, and if nothing else, there will be eventually when all of our records are put through the metadata mash-up blender in Google Books, as I personally have no doubt will happen sooner or later. Concerning displays, that can be handled in different ways. It could be handled much as the 6xx xyzv subfields are displayed, i.e. without any differentiation. If people are really concerned, perhaps an onmouseover event could be employed that would display an explanation of each date subfield, but that is overkill, I think. Finally, my own opinion on an item that arrives today with a 2011 copyright on it: assuming that the item was actually manufactured in 2010 is unwarranted. It could have been created in 2005 or 1930 for all I know. The 2010 date is the date of accession, and/or the date of cataloging. That is useful information, too. James L. Weinheimer j.weinhei...@aur.edu Director of Library and Information Services The American University of Rome Rome, Italy First Thus: http://catalogingmatters.blogspot.com/
Re: [RDA-L] More granulalrity if imprint year coding?
On 11/24/2010 3:42 PM, Jonathan Rochkind wrote: I think the RDA folks should take another run at MARBI and try to get more subfields. Yes, we're running out of subfields in Marc. But data recorded without sufficient granularity to reliably and unambiguously pull it out again by machine processing... might as well not be recorded. I believe that there are plans to do this -- and not just with regard to the 260 field. On the other hand, at some point, we have to recognize that encoding RDA data in MARC 21 is both self-defeating and masochistic! John Attig Authority Control Librarian Penn State University jx...@psu.edu
Re: [RDA-L] More granulalrity if imprint year coding?
On Wed, Nov 24, 2010 at 2:57 PM, Jonathan Rochkind rochk...@jhu.edu wrote: On 11/24/2010 3:51 PM, John Attig wrote: I believe that there are plans to do this -- and not just with regard to the 260 field. Why not with the 260? It would be nice to have access to multiple dates and be able to tell which was which. Legacy data? -- Mark K. Ehlert Minitex Coordinator University of Minnesota Bibliographic Technical 15 Andersen Library Services (BATS) Unit 222 21st Avenue South Phone: 612-624-0805 Minneapolis, MN 55455-0439 http://www.minitex.umn.edu/
Re: [RDA-L] More granulalrity if imprint year coding?
I think that what John actually said was and *not just* with regard to the 260 field, my emphasis added, i.e., plans are afoot for adding granularity to the 260 *and* other fields. Which is certainly good newsfor however long we are going to continue to use MARC for RDA. Deborah -- Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.com Voice/Fax: (321) 676-1904 -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Mark Ehlert Sent: Wednesday, November 24, 2010 4:17 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] More granulalrity if imprint year coding? On Wed, Nov 24, 2010 at 2:57 PM, Jonathan Rochkind rochk...@jhu.edu wrote: On 11/24/2010 3:51 PM, John Attig wrote: I believe that there are plans to do this -- and not just with regard to the 260 field. Why not with the 260? It would be nice to have access to multiple dates and be able to tell which was which. Legacy data? -- Mark K. Ehlert Minitex Coordinator University of Minnesota Bibliographic Technical 15 Andersen Library Services (BATS) Unit 222 21st Avenue South Phone: 612-624-0805 Minneapolis, MN 55455-0439 http://www.minitex.umn.edu/ __ Information from ESET NOD32 Antivirus, version of virus signature database 5646 (20101124) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: [RDA-L] More granulalrity if imprint year coding?
Quoting Deborah Fritz debo...@marcofquality.com: I think that what John actually said was and *not just* with regard to the 260 field, my emphasis added, i.e., plans are afoot for adding granularity to the 260 *and* other fields. Which is certainly good newsfor however long we are going to continue to use MARC for RDA. Which for some will be a long time, I think, seeing how many smaller libraries I know that have little or no prospect of getting funding for replacing their existing MARC systems. On the other hand, some will need specialist help to rejig their MARC mapping to accomodate RDA records, but that will come rather cheaper than system replacement. It would be a service to us all to be able to incorporate new MARC subfielding (such as in 260) in one operation. As for legacy data, I don't think that really matters; but if it does, I think routines could be devised to handle most of this -- Terry Reese's MarcEdit program comes to mind. Hal Cain Melbourne, Australia hec...@dml.vic.edu.au This message was sent using IMP, the Internet Messaging Program.
Re: [RDA-L] More granulalrity if imprint year coding?
Tried to send this to John directly instead of more traffic on the list, but his email server bounced my message back. So sending to the list, because I wanted to say sorry for misunderstanding, glad to hear it. On 11/24/2010 3:51 PM, John Attig wrote: On 11/24/2010 3:42 PM, Jonathan Rochkind wrote: I think the RDA folks should take another run at MARBI and try to get more subfields. Yes, we're running out of subfields in Marc. But data recorded without sufficient granularity to reliably and unambiguously pull it out again by machine processing... might as well not be recorded. I believe that there are plans to do this -- and not just with regard to the 260 field. On the other hand, at some point, we have to recognize that encoding RDA data in MARC 21 is both self-defeating and masochistic! John Attig Authority Control Librarian Penn State University jx...@psu.edu
