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 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.
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" To: "Resource Description and Access / Resource Description and Access" Cc: "Greta de Groat" 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: > Si
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
Freta said: > >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 i= >t no longer says to record the copyright date. Therefore, following this p= >ractice, one would have a bracketed date in the 264 1, but not record a 264= > 3 with the copyright date. Field 264 3 $a$b$c is manufacturer. Copyright date is 264 4 $c. We find the same date twice (264 1 and 264 4, Date 2 and Date 2) to be redundant and confusing, so are please with the policy decision to omit 264 4 $c if the same year as 264 1 $c, and to omit Date 2 if the same as Date one, and code "s". __ __ 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
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" To: "Resource Description and Access / Resource Description and Access" Cc: "Greta de Groat" 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" > 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 Descript
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" To: "Greta de Groat" , "Resource Description and Access / Resource Description and Access" 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.
[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] 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" 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 havi
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. 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" 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
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 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
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 To: RDA-L 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-ba
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
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 To: RDA-L 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) --- 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, butgiven that, in MARC, 264 #4 $cmeans copyright date, whyshould 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 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 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? Be
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 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
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 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 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) 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
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
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 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
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
Patricia posted: >260 Stanford, California : |b Stanford University Press, |c [2012], ©2012 We would change to 264 1, remove the copyright date, and not do a 264 4, since the two dates are the same. We would code 008/06 "s" in this case. If the two dates differ, we would add the copyright date in 264 4, and code 008/06 "t". karen Snow responded: >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. The problem is redundancy in display for patrons, with no addional benefit in searching. Year searches are normally based on 008/07-10 and/or 008/11-14. If the two years are the same, nothing has been added to assist access. __ __ 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
Not at all a stupid question. To me, it's getting down to the different needs of databases and copy cataloging procedures. I understand the need to differentiate when you are extrapolating the publication year from the copyright date (given absence of a pub. year). But in real world copy cataloging with diminishing numbers of people to check copy, MY question comes down to: given the same year for both copyright and publication, how important it is to differentiate these pieces of data and edit copy to reflect that difference. The majority of records with "DLC" in a the 040 (which I realize a number of agencies have weighed in on) I'm seeing actually appear to be ignoring copyright when it duplicates the pub year, hence my question for what to do when it is noted so meticulously. I have most often seen this format of late when I have a book that lists both publication year & the copyright date separately on the same page & they are both 2012: 264 _1 New York : |b The Penguin Press, |c 2012. Copyright as not core is ignored. I'm also seeing 260 __ New York : |b The Penguin Press, |c 2012, c2012. With a dtst s & a single 2012. And then again there is the form that sparked my original question. 260 Stanford, California : |b Stanford University Press, |c [2012], ©2012. With the dtst t and 2012 twice in the dates 008. 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!) I had assumed we would not be editing 260s to 264 in copy cat work. In original work we are indeed using 264s per the current PCC guidelines. Perhaps since this question is really looking more at local process in copy cataloging than at precise original cataloging rules, it would be more appropriately put to AUTOCAT. //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 Joan Wang Sent: Monday, January 28, 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 So what is the purpose of AACR2 rule requiring a difference between copyright and publication dates? Is it a stupid question? Thanks, Joan Wang Illinois Heartland Library System On Mon, Jan 28, 2013 at 1:57 PM, Snow, Karen wrote: 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) -- Zhonghong (Joan) Wang, Ph.D. Cataloger -- CMC Illinois Heartland Library System (Edwardsville Office) 6725 Goshen Road Edwardsville, IL 62025 618.656.3216x409 618.656.9401Fax smime.p7s Description: S/MIME cryptographic signature
Re: [RDA-L] RDA dtst t + a 260/264 muse on training question
So what is the purpose of AACR2 rule requiring a difference between copyright and publication dates? Is it a stupid question? Thanks, Joan Wang Illinois Heartland Library System On Mon, Jan 28, 2013 at 1:57 PM, Snow, Karen wrote: > 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) > -- Zhonghong (Joan) Wang, Ph.D. Cataloger -- CMC Illinois Heartland Library System (Edwardsville Office) 6725 Goshen Road Edwardsville, IL 62025 618.656.3216x409 618.656.9401Fax
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
According to PCC guidelines on 264 field, all new original RDA records use 264 field. My reading on Library of Congress Policy, transcribe copyright date if there is one on piece. Supply an probable date if there is no publication date. Hopefully it help. Thanks, Joan Wang Illinois Heartland Library System On Mon, Jan 28, 2013 at 12:12 PM, FOGLER, PATRICIA A GS-11 USAF AETC AUL/LTSC wrote: > 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 > > > -- Zhonghong (Joan) Wang, Ph.D. Cataloger -- CMC Illinois Heartland Library System (Edwardsville Office) 6725 Goshen Road Edwardsville, IL 62025 618.656.3216x409 618.656.9401Fax