Just a correction about the copyright date in RDA (2.11) - it is a "core
element" only if neither the date of publication nor the date of
distribution is identified. A note on copyright date is covered in 2.20.10.
At 2.11.1.1, the scope of a copyright date in RDA is "a date associated
with a claim of protection under copyright or a similar regime. Copyright
date includes phonogram dates (i.e., dates associated with claims of
protection for sound recordings)."
This is completely separate from a publication date, distribution date,
manufacture date.
The use of a copyright date as a best guess for any of those other dates
(particularly publication date) is from practice, not from RDA. When a
publication date is not identified in the resource, RDA says (2.8.6.6) to
"supply the date or approximate date of publication" and, when that is not
possible, to use the standard phrase 'date of publication not identified'.
- Barbara Tillett, JSC Chair
Joint Steering Committee for Development of RDA
On Thu, Jan 31, 2013 at 12:58 PM, Benjamin A Abrahamse <babra...@mit.edu>wrote:
> I'm curious if people who oppose the use of "t" (pub date/copyright date)
> instead of "s" (pub date only) in the fixed fields are having problems
> getting their systems to parse the data correctly or if it just looks funny
> (redundant) to them because, like all of us, their frame of reference is
> AACR2, which treats (or ignores) copyright statements based on their
> relationship to publication date. The MARC definition is pretty
> unambiguous that when 008/byte 06 is set to "t", 008/bytes 07-10 represent
> publication date and 008/bytes 11-14 represent copyright date, and I should
> think any MARC-compliant ILS would be aware of that and index it
> appropriately.
>
> Certainly it is a good question whether the date fixed field is the best
> place to recording copyright dates in a "machine actionable" way; but that
> is really an issue of how the MARC format is designed and implemented.
>
> Under AACR2 copyright date was only recorded when it differed from
> publication date, or when publication date was unavailable. That is, its
> function under AACR2 was to assist in the identification of the piece.
> Under RDA, copyright is treated as a separate data element ("date
> associated with a claim of protection under copyright or a similar regime",
> RDA 2.11), one that is not necessarily related to date of
> publication/distribution/manufacture. That is, it is metadata that informs
> users about what rights have been asserted over a document, and not just
> metadata that assists in identifying it.
>
> To be sure, when date of publication/manufacture/distribution cannot be
> found, it continues to function as a "reasonable facsimile" for publication
> date. Hence the lengthy commentary in the LC/PCC PS to 2.8.6.6. So when
> we have only a copyright date we can copy that date and put it in brackets
> (as supplied data) in the 264:x1:$c.
>
> But the statement of rights, if I understand RDA correctly, should always
> be recorded (it is designated a "core element") if it is available on the
> source(s) of information.
>
> I think the way RDA presents this is unfortunate and bound to lead to or
> perpetuate the confusion that surrounds copyright vs publication date. Its
> placement in the instructions directly adjacent to instructions for
> recording publication information, suggests that copyright is more or less
> the same as publication date, as it was under AACR2. Moreover I think they
> should have called this element "copyright statement" not "copyright date",
> as the latter leads to confusion (if the element is copyright date why
> include the © character? what about other "similar regimes" such as legal
> deposit, etc.?)
>
> Nevertheless the practice of recording copyright data separately--even
> when it is the same as publication date--makes logical sense even though it
> looks funny and perhaps excessive to catalogers (and probably some members
> of the public as well). It is really, I might suggest, an element that
> supports the "obtain" function, broadly speaking (as copyright, or other
> assertions of rights by creators, etc., may determine what someone can do
> with the material, and the conditions under which agencies may make
> material available to the public) more than the "find" and "identify"
> functions.
>
> 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 Greta de Groat
> Sent: Wednesday, January 30, 2013 1:41 PM
> To: RDA-L@listserv.lac-bac.gc.ca
> Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
>
> Good point, Nancy, i didn't remember that the phonogram date was also in
> that field, which you wouldn't be able to distinguish from a copyright date
> without the symbol or words to that effect.
>
> greta
>
> ----- Original Message -----
> From: "Nancy Lorimer" <nlori...@stanford.edu>
> To: "Resource Description and Access / Resource Description and Access" <
> RDA-L@LISTSERV.LAC-BAC.GC.CA>
> Cc: "Greta de Groat" <gdegr...@stanford.edu>
> Sent: Wednesday, January 30, 2013 9:50:06 AM
> Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
>
> I will add one thing to Greta's very clear explanation.
>
> While the field explicitly states that this is a copyright date, it does
> not state what type of copyright date is being recorded. There are two
> types of copyright date--copyright for text (the (c) date) and the
> phonogram copyright date (the (p) date), which is the copyright for
> recorded sound. Again, these are two different things, and both may appear
> on the same item (and be different). I remember vaguely that when the field
> was first being created, there was some talk of separating the symbol and
> the date, but in the end they were left together in one field.
>
> Nancy
>
> On 1/30/2013 9:40 AM, Greta de Groat wrote:
> > Since i see that a Stanford record is being cited in this discussion,
> > i would like to offer a little in the way of explanation. Steven is
> > right, the initial RDA test instructions for pieces which lacked a
> > date of publication were to record the copyright date if it appeared
> > on the piece, and to use it to infer the date of publication.
> > Therefore, you would get the date of publication bracketed and also
> > the copyright date recorded, even if they were the same. We contacted
> > LC and were told that the Date Type coding for this would indeed be t,
> > and the same date would be recorded in Dates 1 and 2
> >
> > The LC-PCC-PS was recently updated to indicate that the requirement was
> to infer the date of publication from the copyright date and bracket it,
> but it no longer says to record the copyright date. Therefore, following
> this practice, one would have a bracketed date in the 264 1, but not record
> a 264 3 with the copyright date. In this case, Date Type would be s and
> there would be no date recorded in Date 2.
> >
> > However, some of us are continuing the original practice because we
> believe it to be clearer and more useful. It is also not incorrect, it's
> just that LC is not mandating it any more.
> >
> > One reason is that a bracketed date in the 264 1 is ambiguous. It can
> mean "i have a copyright date that i'm not recording but i'm inferring the
> pub date from it" or it can mean "i don't have a date anywhere on this and
> i'm just guessing based on internal or external evidence or the fact that
> it just came in the door and looks new". We think recording the copyright
> date is much more useful for copy cataloging, as one can confirm that the
> copyright date actually appears on the piece, rather than looking at the
> record and not knowing whether to look for a date or not. It seems logical
> and helpful to record a date that actually appears.
> >
> > The other reason is that the copyright date is an explicit legal
> statement. In these digital days when copyright questions are coming up
> all of the time, i would think that an explicit copyright date would be
> something that we'd want to record (even if things are technically
> copyrighted without it.
> >
> > I was very surprised at the LC-PCC-PS change, as i had thought the
> original policy quite sensible. It is not redundant, as publication date
> and copyright date are two different things. We're not needing to save
> space on cards any more. And i have no insight into why we continue to use
> the copyright symbol since, as has been pointed out, the field tagging
> makes the fact that it's a copyright date explicit. I don't remember that
> ever being discussed, but it is a good point (though programmers should be
> able to take the date out of the Date2 field if it has been correctly
> coded).
> >
> > Greta de Groat
> > Stanford University Libraries
> >
> > ----- Original Message -----
> > From: "SEVIM MCCUTCHEON"<lmccu...@kent.edu>
> > To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> > Sent: Wednesday, January 30, 2013 8:29:20 AM
> > Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
> >
> > I think perhaps despite the discussion, a question remains on coding in
> OCLC: If you're using 264s, and the date of publication and the date of
> copyright are the same, which is the proper code in the Date Type, s or t?
> >
> > Sevim McCutcheon
> > Catalog Librarian, Asst. Prof.
> > Kent State University Libraries
> > 330-672-1703
> > lmccu...@kent.edu
> >
> >
> > -----Original Message-----
> > From: Resource Description and Access / Resource Description and
> > Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of FOGLER,
> > PATRICIA A GS-11 USAF AETC AUL/LTSC
> > Sent: Monday, January 28, 2013 1:12 PM
> > To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> > Subject: [RDA-L] RDA dtst t + a 260/264 muse on training question
> >
> > I'll apologize in advance for the length of this.
> >
> > I'm trying to work up some RDA training for my copy cataloging staff and
> am working through a number of DLC RDA records that we are downloading.
> >
> > For the past year, we've had RDA records routed to our Non-DLC cataloger
> as we wait for RDA to "settle". Given that the numbers of RDA records are
> increasing& we're rapidly approaching April, I need to get some basic
> local guidelines set& move these back to our LC copy catalogers. I'm
> having particular issues with aspects of the publication area.
> >
> > My current question: I'm repeatedly seeing in the 008 dtst "t" used to
> indicate a publication and copyright date.
> >
> > While it is technically correct that both dates are given in this
> record, in the past we've mainly seen and used "t" in the dtst field when
> those dates differ, even by a year. What I'm seeing now is this sort of
> transcription (an "older" record still using 260):
> > 260 Stanford, California : |b Stanford University Press, |c [2012],
> ©2012.
> >
> > Trying to make sense out of this coding I viewed this record in LC's
> catalog& they have used 008 dtst s with:
> > 264 _1 |a Stanford, California : |b Stanford University Press, |c
> > [2012]
> >
> > [title in question is Competitive strategies for the 21st century :
> > theory, history, and practice]
> > OCLC770694281
> > LC 2011052146
> >
> > The 008 dtst coding of the record in LC's database (as opposed to the
> record we downloaded from OCLC which apparently has been edited separately)
> looks "more" correct to me.
> >
> > 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?
> >
> > This raises the larger question: for those working up training for your
> copy catalogers, at what point do you tell your people to leave copy as is,
> even if that isn't what you would personally prefer?
> >
> > To the average library user, both transcriptions give essentially the
> same information.
> > At this point, given the variety of 260/264
> interpretations/transcriptions, I'm seriously debating telling my copy
> catalogers "If the 008/260 in the LC copy record adequately conveys the
> book in hand& is essentially correct, leave it."
> >
> > While I appreciate cataloger discretion when I am creating a record or
> editing existing copy, I'm finding it exceedingly difficult to create these
> local copycat editing guidelines for the plethora of interpretations we're
> seeing.
> >
> > Impatiently waiting for RDA postings from ALA Midwinter to be posted.
> >
> > //SIGNED//
> > Patricia Fogler
> > Chief, Cataloging Section (AUL/LTSC)
> > Muir S. Fairchild Research Information Center
> > DSN 493-2135 Comm (334) 953-2135
> >
> >
>
>
> --
> Nancy Lorimer
> Head, Music Technical Services
> Stanford Music Library
> nlori...@stanford.edu
> 650-725-8819
>
--
Dr. Barbara B. Tillett, Ph.D.
Chair, Joint Steering Committee for Development of RDA
