J. McRee Elrod wrote:
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.
My suggestion 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 display, 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.