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
