Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
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
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
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.eduwrote: 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
[RDA-L] TR: [RDA-L] RDA dtst t + a 260/264 muse on training question
Benjamin A Abrahamse 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. I oppose the use of t instead of s in the 008/06 because it is not consistent with the principle already applied for code p. As a music cataloguer, I'm used to see recordings that are recorded in the same year that they are released. Because two different types of dates are involved, code p (Date of distribution/release/issue and production/recording session) could theoretically be applicable but the MARC documentation explicitly says that code p is used only when the two dates are different. Dates of recording are important to music users and under both AACR2 and RDA, they are given in the record (field 518 and/or 033) even if they are identical to another date already recorded, such as a publication date or a copyright date. Yet, it was felt that recording the date only once in field 008 was sufficient and that code s should be used in these situations. I fail to see why copyright dates should be treated differently than dates of recording as far as MARC coding is concerned. This difference is annoying because music cataloguers (and video cataloguer too) will have to remember different practices depending on the types of dates encountered. This is the type of useless distinctions that I was hoping RDA would reduce if not eliminate, not increase. 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 -Message d'origine- De : Resource Description and Access / Resource Description and Access [mailto:RDA-L@listserv.lac-bac.gc.ca] De la part de Benjamin A Abrahamse Envoyé : 31 janvier 2013 12:59 À : RDA-L@listserv.lac-bac.gc.ca Objet : Re: [RDA-L] RDA dtst t + a 260/264 muse on training question 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
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
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 fieldhttp://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.CAmailto: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.camailto: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.edumailto: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.CAmailto: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
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
Regardless of Berne convention and laws, don't confuse the surrogate for the item described. I don't think I copyright statement on the _cataloging record_ but refering to the copyright of the item described ever played any legal role in establishing copyright on the item described, even in cases where copyright statements on items themselves have legal import. I can say yes, I often have to write code to strip out the irrelevant parts of MARC records, including c or copyright symbols when I just want an integer date. And it is odd for RDA to be continuing this practice. But perhaps just another compromise to the legacy. At any rate, it's not a very significant challenge, compared to all the challenges MARC data gives to software, and all of the challenges still there or newly introduced with RDA MARC data too. Don't spend a lot of time on it on software's behalf, there are other priorities for software, it's not a big deal. On 1/30/2013 11:20 AM, Jdchronicler wrote: Although the copyright symbol is necessary for a copyright statement, members of this list from nations that have signed the Berne Convention For The Protection of Literary and Artistic Works should know that copyright statements are no longer necessary. Under the Berne Convention, all published materials are automatically copyrighted including the e-mails on this list. Yet some members of this list may work in nations that have not signed the Berne Convention. For them, copyright statements may still be necessary. I do wonder why they should be considered necessary on RDA cataloging records. Linda Frankel MLIS Student at San Jose State University -Original Message- From: Meehan, Thomas t.mee...@ucl.ac.uk To: RDA-L RDA-L@LISTSERV.LAC-BAC.GC.CA Sent: Wed, Jan 30, 2013 2:07 am Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question 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 mailto:t.mee...@ucl.ac.uk *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA 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 mailto: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
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
When you are entering both a publication date and a copyright day in either 260 or two 264 fields, and you are coding the publication date in Date1 and the copyright date in the 008 Date2, Date Type must be 't' because: http://www.loc.gov/marc/bibliographic/bd008a.html t - Publication date and copyright date Date of publication/release/production/execution is present in 008/07-10 and a copyright notice date or phonogram copyright notice date is present in 008/11-14. In other words, if the date in Date 2 is a copyright date, then Date Type is coded 't' to *say* that the date in Date2 is a copyright date. Deborah - - - - - - - - Deborah Fritz TMQ, Inc. debo...@marcofquality.com www.marcofquality.com -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of MCCUTCHEON, SEVIM Sent: Wednesday, January 30, 2013 11:29 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA 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
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 MCCUTCHEONlmccu...@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
[RDA-L] thanks -- RE: [RDA-L] RDA dtst t + a 260/264 muse on training question
I very much appreciate your detailed reply. I want to hasten to clarify that I wasn’t trying to point out any institution as doing anything wrong or nonstandard. Merely citing an example (of a record that looked to be done by the rules but rules that were confusing me). Getting the blow-by-blow as it were of the decisions how they evolved, helps enormously for those of us who are coming to this later, with smaller departments trying to make sense out of the variously clearly well-cataloged but different, RDA records. //SIGNED// Patricia Fogler Chief, Cataloging Section (AUL/LTSC) Muir S. Fairchild Research Information Center DSN 493-2135 Comm (334) 953-2135 -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 11:41 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question 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. smime.p7s Description: S/MIME cryptographic signature
Re: [RDA-L] thanks -- RE: [RDA-L] RDA dtst t + a 260/264 muse on training question
Oh, no offense taken--i just noticed that it was a Stanford University Press book so i figured it was one of our CIP contributions. And it was probably done under the original test policy. And, i should point out, that not everyone at Stanford is necessarily following the same policy--our local policy is that going beyond the LC-PCC-PS and providing extra information is cataloger's judgement. So different catalogers may make different judgements. Since i catalog mostly videos and video games, which almost never have publication dates it's my judgement to use the copyright date as well (ok, i'll acknowledge that there is a copyright date controversy regarding video copyright dates, but that is applicable only in a minority of the cases that i see--i don't do that many mainstream commercial videos). greta - Original Message - From: PATRICIA A GS-11 USAF AETC AUL FOGLER/LTSC patricia.fog...@us.af.mil To: Greta de Groat gdegr...@stanford.edu, Resource Description and Access / Resource Description and Access RDA-L@LISTSERV.LAC-BAC.GC.CA Sent: Wednesday, January 30, 2013 9:53:13 AM Subject: thanks -- RE: [RDA-L] RDA dtst t + a 260/264 muse on training question I very much appreciate your detailed reply. I want to hasten to clarify that I wasn’t trying to point out any institution as doing anything wrong or nonstandard. Merely citing an example (of a record that looked to be done by the rules but rules that were confusing me). Getting the blow-by-blow as it were of the decisions how they evolved, helps enormously for those of us who are coming to this later, with smaller departments trying to make sense out of the variously clearly well-cataloged but different, RDA records. //SIGNED// Patricia Fogler Chief, Cataloging Section (AUL/LTSC) Muir S. Fairchild Research Information Center DSN 493-2135 Comm (334) 953-2135 -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 11:41 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA dtst t + a 260/264 muse on training question 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.
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 MCCUTCHEONlmccu...@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
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)
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 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)
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
Patricia Fogler asked : How useful/necessary/correct is it to code this dtst to other than s have duplicate dates in the 008 date area? The Canadian Committee on MARC felt exactly the same way when Proposal 2011-02, which included examples of duplicate dates in the 008 field, was discussed by MARBI in June 2011. This practice is also inconsistent with what the MARC documentation instructs to do when using code p (this code is used only if the date of recording, production, etc., is different than the date recorded as Date 1). According to the minutes of the June 2011 MARBI meeting (http://www.loc.gov/marc/marbi/minutes/an-11.html), Margaret Stewart (LAC) relayed the comment from the Canadian Committee on MARC that code t should only be used when publication date and copyright date are different. Rebecca Guenther (LC) agreed that that was the major question and stated that the examples in the proposal were written to include the date, whether or not publication date and copyright date are different. Gary Strawn (ALCTS) asked Sally McCallum (LC) and Rebecca Guenther (LC) to take LAC's comment into consideration and make editorial changes to the documentation where appropriate. It is not clear for me from the minutes if there was agreement to follow up on Gary Strawn's suggestion but if there was, it would be great if the documentation was edited to restrict code t to cases where the copyright date is different than the publication date. 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 -Message d'origine- De : Resource Description and Access / Resource Description and Access [mailto:RDA-L@listserv.lac-bac.gc.ca] De la part de FOGLER, PATRICIA A GS-11 USAF AETC AUL/LTSC Envoyé : 28 janvier 2013 13:12 À : RDA-L@listserv.lac-bac.gc.ca Objet : [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
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
Patricia asked:
Do we advise copy catalogers to edit to 264 or let all variations pass if
essentially correct for when they were cataloged (as best they can tell!)
We will instruct that 264 4 be deleted if the $c is the same as 264
1, that date type be s, and only date 1 be coded, whether 264 1 has
$c in brackets or not.
I had assumed we would not be editing 260s to 264 in copy cat work.
We will instruct that 260 be edited to to 264 in derived RDA records.
Both of these we will do for the sake of consistency in our own
database, and to simplify product and export programming.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
I have found this 264 _1 with 264 _4 coding to be a major time consumer when using RDA. For my local system, I must now copy what I put in 264 _4, e.g. ©2010 into 264 _1, delete the former, and then download. I fail to see what the repetition of what I put into these two MARC fields accomplishes for users, and it wastes time. Buzz Haughton 1861 Pebblewood Dr Sacramento CA 95833 USA (916) 468-9027 bongob...@gmail.com
