Posting to RDA-L
On 06/06/2011 23:31, Deborah Fritz wrote:
Actually, I think the proposal for a separate field for copyright date (Proposal No. 2011-03<http://www.loc.gov/marc/marbi/2011/2011-03.html> ), ties in with the proposal for distinguishing between RDA Production, Publication, Distribution and Manufacture Statements (Proposal No. 2011-02 <http://www.loc.gov/marc/marbi/2011/2011-02.html> )
It would not make much sense to keep the copyright date in 260$c (whether repeated or not) if we are going to stop using 260 entirely, and, instead, start using 264 (with indicators to clarify the type of statement contained in the field) or 264/266/267/268 –in records constructed following RDA conventions.
A new subfield is fine with me, but it doesn’t solve the problem. MARC has always been very weak on dates, in my own opinion. Most formats I have seen have many more options for dates.
Yet, even if we make a new subfield for copyright date, we have an entire database of millions of records with the old way. So, the situation is exactly the same as spelling out the cataloging abbreviations: catalogers pretend that it fixes a problem, while in reality it solves absolutely nothing for the patrons, who, because there will not be a retrospective conversion to type out the abbreviations in the existing records, will forever continue to see abbreviations in every single search result. So, I ask–if it doesn’t solve anything, why change?
So long as input is standardized, as we see with cataloging abbreviations, or with the various practices in the 260$c, much of this can be upgraded automatically, so long as it is consistently input. So, if we wanted to take a 260$c plus the digits following a “c” or copyright symbol, and place this value into a new subfield, that could probably be done, and would probably be all right. But, if it can be done automatically with what we have now, the question is: why wouldn’t that be enough? Why convert the records?
I think we need to consider why we need the additional fields and whom it is supposed to serve. The display seems OK as it is now, but if there is confusion, e.g. people don’t understand brackets and that is seen as a problem, the system could automatically display a description of what dates in brackets mean. Do the users need to be able to distinguish the dates for searching purposes? Do the librarians need it for collection management purposes? It may be worth the effort, or perhaps not–I don’t know.
These are the directions I wish we were heading: taking the records as they are right *now* and getting as much out of them as possible by using all the power of modern computing systems. I think we have barely broken the surface of what could be done with the records as they stand now.