ISBD describes a display standard. It doesn't matter WHERE the data is in the underlying machine-readable record, it could display in its proper location to satisfy ISBD. The idea that the display has to be in MARC tag and subfield order is not only not sensible, it's not what we do today. We format our displays based on display instructions, we don't just toss all of MARC onto the screen as it has come in. So neither ISBD *nor* MARC are at fault here, it's our own inability to think clearly about data processing. The position of data in the underlying record should not be a barrier to us achieving the displays we desire.

kc

Quoting Laurence Creider <lcrei...@lib.nmsu.edu>:

Karen,

I disagree. The issue here is not MARC, but ISBD, followed by the question of the function of this data. Since the US library community seems to have adopted ISBD for its displays, then one needs to figure out the function of the element within that standard.

I think that Kathy is right about the need for redundancy here. If the same data string serves two different functions then you will need to specify those uses in whatever scheme is chosen in order to make it possible to extract the data in a meaningful way.

MARC certainly has its limitations, but I get awfully tired of people blaming it (and catalogers) for everything keeping us from metadata utopia. MARC was wonderful for its time, good even beyond its time, and now it shows its age and needs replacement. But there is no need for terms like "slavish" and questioning the professionalism of the profession.

--
Laurence S. Creider
Special Collections Librarian
New Mexico State University
Las Cruces, NM  88003
Work: 575-646-7227
Fax: 575-646-7477
lcrei...@lib.nmsu.edu

On Thu, 28 Apr 2011, Karen Coyle wrote:

Kathy, there is nothing in the 542 that says that any of the subfields is required -- one can use the 542 to only record the copyright date if desired. And there is no reason why RDA rules couldn't be used to fill in the 542 $g. The instruction says merely: "For items under copyright, the initial year of copyright." Note that there is a separate subfield for the exact copyright statement, because that can contain important information, e.g. who holds the copyright. But all of this information is optional.

I really don't see any reason why this could not be used for RDA. The decision about using a single field has nothing to do with requiring that the whole field be filled it -- that's there because there were options that would use more than one field given in the proposal.

To me this is all evidence of our slavishness to MARC. An input system could have 'fill-in' boxes for date of publication and copyright date and it shouldn't matter where they get stored in the underlying machine-readable record. But I think we'll end up with a redundant 2XX because people key directly into the MARC format, and thus a subfield in 542 is a long way from the 260. As information technology this is nonsense -- WHERE data is stored in the record should have no bearing; WHAT it means is what is important. So we create redunancy -- at a cost -- and then complain about our system vendors and what they find necessary to charge us for problems that we make for ourselves.

I would be greatly surprised to find any other community doing its data input this badly. And yet we call ourselves 'information professionals.'

kc

Quoting Kathy Glennan <kglen...@umd.edu>:

Karen, I think there's a difference in recording this data that may make the 2XX proposal make more sense than using 542 $g.

In a record creation context, the cataloger is simply recording a copyright date that appears on a resource, without trying to supply the rest of the elements required to determine copyright status. In an RDA context, the copyright date (when used) is essentially transcribed from the resource. To the best of my knowledge RDA does not provide any further instructions about recording any additional information about copyright including: copyright holder, copyright renewal date, copyright jurisdiction, etc.

When following RDA instructions, copyright date is not necessarily transcribed, since the cataloger has the option of using the copyright or phonogram symbol or spelling out the appropriate word. In any case, in an RDA record, the copyright/phonogram date does not stand alone -- it has some sort of qualifier in front of it. This is not the case in 542 $g. RDA also makes the distinction between copyright and phonogram dates (the latter being used for recorded sound); this distinction is not currently available in Field 542.

I see that the original MARBI Discussion Paper (2007-DP05) "suggests using a single field to contain all copyright information, even if repeating other data somewhere else in the record, because of the complications." I think that these distinctions in the purpose of recording the copyright date justify having this particular data repeated.


Kathy Glennan
Head, Special Resources Cataloging / Music Cataloger
University of Maryland
kglen...@umd.edu



-----Original Message-----
From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle
Sent: Thursday, April 28, 2011 3:42 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] RDA MARC coding question

I think I understand the reason why people want this in a 2XX (human habit and systems habits), but we added the 542 for copyright information in 2008, and it has a subfield for copyright date, as well as renewal date (for the cases in which one has that info), and other information relating to copyright status. Adding a 2XX field for copyright date just doesn't seem right. (although it is called 'date of copyright notice' -- but that is the sense of the subfield in the 542, IMO).

kc

Quoting "Adam L. Schiff" <asch...@u.washington.edu>:

And to further reiterate, they are different RDA elements because they
are in fact different things.  Copyright date is a legal date that
reflects the year in which an issue is registered for copyright
protection.  It is not the same thing as a publication date.
> In AACR2 we were conveniently allowed to substitute copyright date for
a publication date.  In RDA we have two separately defined elements,
and we must always record a publication date, an estimation/guess of
the publication date, or the phrase "[date of publication not
identified]". In RDA, if you've recorded a publications date or an
estimation/guess, then you are not required to record the copyright
date as well (although you may do so, and the LC Policy Statement for
the testing period said to always give it if it is on a resource).  In
RDA, copyright date is only a required element if the neither the date
of publication nor date of distribution is identified.
> Adam
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Adam L. Schiff
Principal Cataloger
University of Washington Libraries
Box 352900
Seattle, WA 98195-2900
(206) 543-8409
(206) 685-8782 fax
asch...@u.washington.edu
http://faculty.washington.edu/~aschiff
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > > On Thu, 28 Apr 2011, Kuhagen, Judith wrote:
> > Gene,
> > > As stated several times on various lists, the two dates are different
> RDA elements.  In your library if you have a Date of publication or
> in its absence a Date of distribution, you can ignore the Copyright
> date.
> > > Judy
> > > ________________________________________
> From: Resource Description and Access / Resource Description and
> Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Gene Fieg
> [gf...@cst.edu]
> Sent: Thursday, April 28, 2011 2:02 PM
> To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> Subject: Re: [RDA-L] RDA MARC coding question
> > > Just a question here.  What is the rationale in RDA for including
> both dates if they are the same?
> > > On Thu, Apr 28, 2011 at 8:22 AM, Kuhagen, Judith
> <j...@loc.gov<mailto:j...@loc.gov>> wrote:
> As Kathy noted, there will be a MARBI proposal about copyright date
> for the June 2011 ALA Annual Conference.  That topic and others
> related to the 260 field were presented as discussion paper topics at
> the January 2011 ALA Midwinter Meeting.  The other 260 topics will be
> covered by a MARBI proposal for June; it will include 008 information
> as well.
> > > Judy Kuhagen
> Policy and Standards Division
> Library of Congress
> Washington, D.C.
> ________________________________________
> From: Resource Description and Access / Resource Description and
> Access
> [RDA-L@LISTSERV.LAC-BAC.GC.CA<mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA>]
> On Behalf Of Kathy Glennan
> [kglen...@umd.edu<mailto:kglen...@umd.edu>]
> Sent: Wednesday, April 27, 2011 6:34 PM
> To: RDA-L@LISTSERV.LAC-BAC.GC.CA<mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA>
> Subject: Re: [RDA-L] RDA MARC coding question
> > > Expect to see a MARBI Proposal for ALA Annual in New Orleans that
> proposes specific subfields for copyright and phonogram dates.
> > > I would code the separate elements of publication date and copyright
> date in the fixed field as they appear in OCLC #670190952. MARC
> already enables us to separately encode publication date and
> copyright date in the fixed fields. Since these are separate
> elements, I can see no reason not to record both dates in the fixed
> fields, even if their character strings are identical.
> > > > > > > Kathy Glennan
> Head, Special Resources Cataloging / Music Cataloger University of
> Maryland kglen...@umd.edu<mailto:kglen...@umd.edu>
> > > > > > > -----Original Message-----
> From: Resource Description and Access / Resource Description and
> Access
> [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA<mailto:rd...@listserv.lac-bac.gc
> .CA>]
> On Behalf Of J. McRee Elrod
> Sent: Wednesday, April 27, 2011 2:32 PM
> To: RDA-L@LISTSERV.LAC-BAC.GC.CA<mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA>
> Subject: Re: [RDA-L] RDA MARC coding question
> > > Jay Shorten said on Autocat:
> > > > OCLC 670190952 (no LC number), has 260c 2010, (c)2010. Is it really
> > necessary to code this in the fixed fields as t 2010 2010? Wouldn't
> > s
> > 2010 be better?
> > > In RDA publication date is a core element, but copyright date is not.
> I expect to see more [2011], (c)2011 when the item has only copyright
> date.  A subfield code is needed for copyright date.
> > > I would code 008 s with a single date.
> > > > Also, shouldn't the 300 end in a period?
> > > Under RDA ISBD practice, only when a 490 follows. We are still using
> the ISBD fiction that the ending mark of punctuation
> *introduces* the next field.  As OPAC displays more and more
> deconstruct the ISBD display, it is time to abandon this fiction, and
> standardize ending punctuation of RDA elements and MARC fields.
> Field 246 needs one for example, to agree with 730/740, and to have
> a period on notes created by 246.
> > > > > > > __ __ J. McRee (Mac) Elrod > > (m...@slc.bc.ca<mailto:m...@slc.bc.ca>)
> {__  |   /     Special Libraries Cataloguing
> HTTP://www.slc.bc.ca/<http://www.slc.bc.ca/>
> ___} |__ \__________________________________________________________
> > > > > > > --
> Gene Fieg
> Cataloger/Serials Librarian
> Claremont School of Theology
> gf...@cst.edu<mailto:gf...@cst.edu>
> > --
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet









--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Reply via email to