I agree with Jenny: I would love to know the reasoning behind this. As for 
machine actionable: although I’m no great programmer, I do know that anyone 
building something using the copyright date would have to insert at least one 
line of code to strip out the copyright symbol. However, depending on the 
situation this element could contain any of the following four options for a 
book with copyright date 2002 (2.11.1.3):

©2002
copyright 2002
℗2002
phonogram 2002
There are other cases of this in AACR2/RDA (a good example is the 300$c which 
includes the units- which can vary- and the quantities in one piece of text) 
but the copyright date seems more alarming as it was added anew in RDA.

Thanks,

Tom
(further ramblings on the 300 
field<http://www.aurochs.org/aurlog/2012/07/10/how-big-is-my-book-mashcat-session/>)

---

Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London WC1E 6BT

t.mee...@ucl.ac.uk

From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Jenny Wright
Sent: 30 January 2013 09:30
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question


I too have wondered about this - an instruction to record copyright date is 
fine, but given that, in MARC, 264 #4 $c means copyright date, why should we 
need to insert the © symbol before it?

Jenny Wright

Development Manager

Bibliographic Data Services Ltd.

-----Original Message-----
From: Resource Description and Access / Resource Description and Access 
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Benjamin A Abrahamse
Sent: 29 January 2013 20:25
To: RDA-L@LISTSERV.LAC-BAC.GC.CA<mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA>
Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question

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<mailto: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<mailto: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<mailto: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<mailto:ks...@dom.edu>

708-524-6077 (office)

708-524-6657 (fax)

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Reply via email to