According to LC's training material, a date such as "not after 2013" would be coded as follows: 008/06: q 008/07-10: uuuu 008/11-14: 2013 I assume that in the case of a "not before date", code "uuuu" would appear in positions 11-14 instead. Daniel Paradis Bibliothécaire Direction du traitement documentaire des collections patrimoniales Bibliothèque et Archives nationales du Québec 2275, rue Holt Montréal (Québec) H2G 3H1 Téléphone : 514 873-1101, poste 3721 Télécopieur : 514 873-7296 daniel.para...@banq.qc.ca http://www.banq.qc.ca <http://www.banq.qc.ca/> Avis de confidentialité Ce courriel est une communication confidentielle et l'information qu'il contient est réservée à l'usage exclusif du destinataire. Si vous n'êtes pas le destinataire visé, vous n'avez aucun droit d'utiliser cette information, de la copier, de la distribuer ou de la diffuser. Si cette communication vous a été transmise par erreur, veuillez la détruire et nous en aviser immédiatement par courriel.
________________________________ De: Resource Description and Access / Resource Description and Access de la part de Robert Maxwell Date: jeu. 2013-06-13 21:09 À: RDA-L@listserv.lac-bac.gc.ca Objet : Re: [RDA-L] 264 All are entity functions required? Julie, In addition to what Adam said, in current practice we are required to include subfields $a, $b, and $c in 264 _1 even if we've included "core if" elements later on, so your first example should read: 264 #1 $a Syracuse, New York : $b [publisher not identified], $c [date of publication not identified] 264 #4 $c ©2009 But as Adam noted, it's better to try to supply a date (as in your second example, which is fine). And actually, if you think about it, we probably never need to record "date of publication not identified" for a published item even if we have no evidence whatsoever about the date of publication, because we do know one thing: it was published before it got to us for cataloging, so you can always record, if nothing else, ... $c [not after June 13, 2013] (I know, I know, there's the case where a publisher claims to have published something in 2014 and we receive it in 2013, proving that things sometimes get "published" after we get them, but let's deal with that problem only if the publisher has explicitly put a future publication date on the piece-this has been extensively discussed before in this forum, I believe.) Actually, I now have a question for the collective wisdom of the list. How do you code the MARC fixed date fields if you have a "not before" or a "not after" date of publication? I don't see any explanation of this situation in the documentation for 008/06 - 008/14. I could possibly see using "q" and the date + 9999 for a "not before" date, but what about a "not after" date? Bob Robert L. Maxwell Head, Special Collections and Formats Catalog Dept. 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 "We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued"--Eliza R. Snow, 1842. From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Julie Moore Sent: Thursday, June 13, 2013 6:27 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] 264 All are entity functions required? If all that you have is the copyright date, then it should look like this, right? 264 #1 $a Syracuse, New York : $b [publisher not identified] 264 #4 $c ©2009 Is it OK or incorrect to add the copyright date in the 264 bracketed as an inferred date? So it would look like this: 264 #1 $a Syracuse, New York : $b [publisher not identified], $c [2009] 264 #4 $c ©2009 Thanks for your guidance! Best wishes, Julie On Thu, Jun 13, 2013 at 5:08 PM, Adam L. Schiff <asch...@u.washington.edu> wrote: I think many catalogers feel that since the copyright date is present on the resource, they should record it even if they've given an inferred publication date in 264 _1 $c. And some libraries have made it a local core element. If it is present, I always record it. Adam Schiff ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Adam L. Schiff Principal Cataloger University of Washington Libraries Box 352900 Seattle, WA 98195-2900 (206) 543-8409 (206) 685-8782 fax asch...@u.washington.edu http://faculty.washington.edu/~aschiff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Thu, 13 Jun 2013, Julie Moore wrote: Follow up question ... why is it that I see the majority of RDA records with multiple 264s having the 264 _1 (publication) and 264 _4? Is this because the only date they have is a copyright date ... so they put the publisher info in the 264 _1 $a and $b and sometimes $c [copyright date -- so thus, and inferred publication date?] ... and then they are putting the copyright date in the 264 _4? Thanks, Julie Moore On Thu, Jun 13, 2013 at 2:39 PM, Adam L. Schiff <asch...@u.washington.edu>wrote: Distribution would only be a core element if the publication element was not identified. Manufacture would only be core element if neither the publication nor the distribution element was identified. You COULD provide everything you know but if you have publication place, publisher, and date of publication, nothing else is required. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^**^^^^^^^^ Adam L. Schiff Principal Cataloger University of Washington Libraries Box 352900 Seattle, WA 98195-2900 (206) 543-8409 (206) 685-8782 fax asch...@u.washington.edu http://faculty.washington.edu/**~aschiff<http://faculty.washington.edu/~aschiff> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~~~~~~~~ On Thu, 13 Jun 2013, Julie Moore wrote: (My apologies for the cross-posting) Dear All, In trying to move beyond the inexplicable inconsistent "period" issue ... Now we have with the 264 the possibilities of: 2nd indicator entity functions of: 0 = Production 1 = Publication 2 = Distribution 3 = Manufacture Statements 4 = Copyright notice date Are we required to provide all if we have all? If not, which ones are required? I have noticed that in most cases, there is only a 1 (Publication) and a 4 (copyright date). I would be grateful for some clarification on this. Best wishes, Julie Moore -- Julie Renee Moore Head of Cataloging California State University, Fresno julie.renee.mo...@gmail.com 559-278-5813 ?Those who bring sunshine to the lives of others cannot keep it from themselves.?... James Matthew Barrie -- Julie Renee Moore Head of Cataloging California State University, Fresno julie.renee.mo...@gmail.com 559-278-5813 ?Those who bring sunshine to the lives of others cannot keep it from themselves.?... James Matthew Barrie -- Julie Renee Moore Head of Cataloging California State University, Fresno julie.renee.mo...@gmail.com 559-278-5813 "Those who bring sunshine to the lives of others cannot keep it from themselves." ... James Matthew Barrie
