I think you have a good point. If the instruction were worded, "2.11.1 Basic instructions on recording copyright *statements*" it would make perfect sense to include the © just like we include "by" in a statement of responsibility. But it's worded "... copyright dates" which implies that that data element should exclusively be a date.
As to whether this makes it less "machine actionable" I cannot say, though I would point out for whatever it's worth that the "Dublin Core library metadata action profile" lists copyright as a refinement of the element, "date", which would suggest for DC at least (which, whatever else it is, is closer to "machine actionable data" than our MARC records) the © symbol is not considered part of the data. (See: http://dublincore.org/documents/library-application-profile/index.shtml#DateCopyrighted) Benjamin Abrahamse Cataloging Coordinator Acquisitions, Metadata and Enterprise Systems MIT Libraries 617-253-7137 -----Original Message----- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@listserv.lac-bac.gc.ca] On Behalf Of Beth Guay Sent: Tuesday, January 29, 2013 2:23 PM To: RDA-L@listserv.lac-bac.gc.ca Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question I'm hung up on the RDA instruction for recording a copyright date as a symbol or spelled out element conjoined to a text string otherwise known as a date. It seems to me, that here we have an excellent effort to carry our data from MARC to linked data format through use of a newly defined 264 field, and rather than entering data (the date) into the area (264 second indicator 4 $c) that contains data defined as copyright date, we enter a symbol plus a date, or a spelled out word plus a date. What we are transcribing is not a date but a symbol plus a date. Is it a string or a thing? http://metadataregistry.org/schemaprop/show/id/5.html Is ©2002 machine actionable? Shouldn't it be up to the content display system to supply the symbol or spelled out element -- © or copyright or ℗ or phonogram? Have there been any successful efforts that anyone is aware of which is a system that serves up labeled data elements from a complex combination of elements in the leader 008 field byte 06 DtSt, byte 07-10 Date 1 and byte 11-14 Date 2? Beth ----------------------------- Beth Guay Continuing and Electronic Resources Cataloger Metadata Services Department 2200 McKeldin Library, University of Maryland College Park, Maryland 20742 (301) 405-9339 fax (301) 314-9971 bag...@umd.edu -----Original Message----- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Snow, Karen Sent: Monday, January 28, 2013 2:58 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question Patricia Folger wrote: "The former coding in OCLC looks like "overkill" -- How useful/necessary/correct is it to code this dtst to other than s & have duplicate dates in the 008 date area?" I'm not sure I understand the problem here. Publication dates and copyright dates are not the same, even if they share the same year. They are discreet data elements. That is why 264_1 $c and 264_4 $c were created in the first place, to better distinguish the dates and make them more machine-actionable. Warm regards, Karen Snow, Ph.D. Assistant Professor Graduate School of Library & Information Science Dominican University 7900 West Division Street River Forest, IL 60305 ks...@dom.edu 708-524-6077 (office) 708-524-6657 (fax)
