Re: [RDA-L] Confusion between Field of activity and Profession or occupation
Quoting Karen Coyle li...@kcoyle.net: Quoting Myers, John F. mye...@union.edu: It was reported that these two elements emerged from FRAD. Unfortunately, I don't have a paper copy and, unlike FRBR, there does not appear to be a digital manifestation, so I'm not in a position to confirm the genesis. Perhaps those with access can draw on its guidance for clarification in this matter. I actually shelled out for a copy of FRAD (costs about $ a page). The two elements are indeed there as attributes of Person. BTW, if you read one of these languages, FRAD is available for free online. An English online version is not available. * ca ? Català ? Catalan * es ? Español ? Spanish * fr ? Français ? French * it ? Italiano ? Italian (also published in print by ICCU) * zh ? ?? ? Chinese http://www.ifla.org/publications/functional-requirements-for-authority-data I recall that when the final version of the FRAD report was issued, an online version was promised! When it comes to epithets for identification and differentiation, surely we don't want simply to take the most obvious? Someone who publishes, and is initially identified, as Rev. may in time become Bishop and eventually Cardinal. When it comes to academic degrees, I've observed people who start out as B.A. then advance to M.A. then to Ph.D. -- and the forms on title pages in successive printings may vary accordingly. One of the objections to including titles (such as Sir) in formulating names is that they're not always used, and a person's earlier works/editions may be issued before the title is conferred. I hope that part of the inquiry consequent on this RDA test process will be to review such headings and assemble guidance on what constitutes good practice. I hope! The Principle of Representation deserves some attention here! Not all possible MARC 21 fields are implemented in LC/NACO practice (e.g. data appropriate to 678 is usually entered in 670, if at all). The fact that different fields are provided for distinguishable data elements does not guarantee that they're appropriate in all contexts -- any more than it guarantees that they're never useful! It all depends on the context. A while ago I looked at some of the new fields in the context of enhancing in-house authority data for a special collection; though the data wouldn't (yet) be publicly accessible, it would be retrievable by an SQL search in the authority database and could thus support a special project or two. Hal Cain Melbourne, Victoria hec...@dml.vic.edu.au This message was sent using IMP, the Internet Messaging Program.
[RDA-L] Recording Relationships in MARC
Hi Folks, I'm in the midst of attempting some in-house RDA cataloging and could use a hand on relationships. Currently I am cataloging a book called Similes in the Nikayas : a classified index. The book is an extract from the Journal of the Pali Text Society for 1906-1907. I'd like to record the relationships to the Nikayas (that is, collections of texts making up the Sutta Pitaka) and the Journal of the Pali Text Society. Here's how I *think* I should go about it. I've created access points both the Sutta Pitaka and the Journal: 730 0# Tipiṭaka. ǂp Suttapiṭaka. 730 0# Journal of the Pali Text Society. Also, I have added two 500 notes: 500 ## Index to: Tipiṭaka. Suttapiṭaka. 500 ## Contained in: Journal of the Pali Text Society for 1906-1907. Does that make sense? Would that adequately express the relationships? Apologies if this is a daft question. I've been following the progression or RDA, working through the toolkit, and trying to keep up with listserv discussions. Regardless, I've found confirmed what I previously supposed, namely that cataloging according to RDA is a far different thing from reading about cataloging according to RDA. Many thanks for any assistance you can provide. Cheers. -- Christopher Case Content Management Librarian Milton S. Eisenhower Library Johns Hopkins University
Re: [RDA-L] Web catalog
As a smaller library, we use EOS.Web from EOS International. We have control over much of the setup, so I have gone into the MARC Bibliographic setup section and added all the possible new MARC tags and subfields while retaining all of the existing tags and fields. This way we are able to import a wide range of records. Technical Bulletin 258 outlines most of the changes brought about by RDA. Mike McReynolds Cataloging Librarian Shook, Hardy Bacon Kansas City On 12/2/2010 4:22 PM, Jeff Peckosh wrote: Do we need to have anything done with our web catalog to make it friendly with RDA tags or should we assume that it will work fine automatically? Also, do we know when the testing and everything will be finalized, and that we will start cataloging in accordance to RDA? Thanks for your help, Jeff Peckosh Public Library Cataloging Librarian
Re: [RDA-L] Recording Relationships in MARC
Geez, this looks like AACR2 to me. Looks ok. Make added entry for the journal and its exact issue number. On Tue, Dec 7, 2010 at 8:45 AM, Christopher Case cca...@gmail.com wrote: Hi Folks, I'm in the midst of attempting some in-house RDA cataloging and could use a hand on relationships. Currently I am cataloging a book called Similes in the Nikayas : a classified index. The book is an extract from the Journal of the Pali Text Society for 1906-1907. I'd like to record the relationships to the Nikayas (that is, collections of texts making up the Sutta Pitaka) and the Journal of the Pali Text Society. Here's how I *think* I should go about it. I've created access points both the Sutta Pitaka and the Journal: 730 0# Tipiṭaka. ǂp Suttapiṭaka. 730 0# Journal of the Pali Text Society. Also, I have added two 500 notes: 500 ## Index to: Tipiṭaka. Suttapiṭaka. 500 ## Contained in: Journal of the Pali Text Society for 1906-1907. Does that make sense? Would that adequately express the relationships? Apologies if this is a daft question. I've been following the progression or RDA, working through the toolkit, and trying to keep up with listserv discussions. Regardless, I've found confirmed what I previously supposed, namely that cataloging according to RDA is a far different thing from reading about cataloging according to RDA. Many thanks for any assistance you can provide. Cheers. -- Christopher Case Content Management Librarian Milton S. Eisenhower Library Johns Hopkins University -- Gene Fieg Cataloger/Serials Librarian Claremont School of Theology gf...@cst.edu
Re: [RDA-L] Recording Relationships in MARC
Yup, looks like AACR2 to me too. Is there a lesson to be drawn? ;-) ;-) ;-) Just a thought. John From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Gene Fieg Sent: Tuesday, December 07, 2010 11:54 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Recording Relationships in MARC Geez, this looks like AACR2 to me. Looks ok. Make added entry for the journal and its exact issue number. On Tue, Dec 7, 2010 at 8:45 AM, Christopher Case cca...@gmail.commailto:cca...@gmail.com wrote: Hi Folks, I'm in the midst of attempting some in-house RDA cataloging and could use a hand on relationships. Currently I am cataloging a book called Similes in the Nikayas : a classified index. The book is an extract from the Journal of the Pali Text Society for 1906-1907. I'd like to record the relationships to the Nikayas (that is, collections of texts making up the Sutta Pitaka) and the Journal of the Pali Text Society. Here's how I think I should go about it. I've created access points both the Sutta Pitaka and the Journal: 730 0# Tipiṭaka. ǂp Suttapiṭaka. 730 0# Journal of the Pali Text Society. Also, I have added two 500 notes: 500 ## Index to: Tipiṭaka. Suttapiṭaka. 500 ## Contained in: Journal of the Pali Text Society for 1906-1907. Does that make sense? Would that adequately express the relationships? Apologies if this is a daft question. I've been following the progression or RDA, working through the toolkit, and trying to keep up with listserv discussions. Regardless, I've found confirmed what I previously supposed, namely that cataloging according to RDA is a far different thing from reading about cataloging according to RDA. Many thanks for any assistance you can provide. Cheers. -- Christopher Case Content Management Librarian Milton S. Eisenhower Library Johns Hopkins University -- Gene Fieg Cataloger/Serials Librarian Claremont School of Theology gf...@cst.edumailto:gf...@cst.edu
Re: [RDA-L] Recording Relationships in MARC
Christopher Case posted:
730 0# Tipit=CC=A3aka. =C7=82p Suttapit=CC=A3aka.
730 0# Journal of the Pali Text Society.
500 ## Index to: Tipit=CC=A3aka. Suttapit=CC=A3aka.
500 ## Contained in: Journal of the Pali Text Society for 1906-1907.
This does not differ from AACR2.
Many would suggest 77X linking fields for both AACR2 and RDA records.
What you have done would work better for patrons in most of the ILS we
support.
We would add:
630 0# Tipit=CC=A3aka. =C7=82p Suttapit=CC=A3aka$vIndexes.
To the 2nd 730 we would add ,$n1906-1907
In the 2nd 500 we would say Orginally published in ... rather than
Contained in ..., assuming it has been physically removed and this
is not an analytic you are doing. Too bad we lost 503.
Another way of handling the journal would be:
490 1/830 0 $aJournal of the Pali Text Society ;$v1906-1907. That
would replace both the 500 and 730.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Recording Relationships in MARC
Thanks for the tips. I forgot to mention the 630 which I did in fact use. As
far as Contained in, I got that wording from Appendix J of RDA. I do feel
a bit uneasy about that wording though, as this is in fact a separate
publication, with a note on the front cover (what I used for the description
as it lacks t.p.) that it was extracted from the Journal.
I suppose RDA does give the option of a less structured form of note, so in
this test record, I may change that.
Thanks again!
On Tue, Dec 7, 2010 at 2:36 PM, J. McRee Elrod m...@slc.bc.ca wrote:
Christopher Case posted:
730 0# Tipit=CC=A3aka. =C7=82p Suttapit=CC=A3aka.
730 0# Journal of the Pali Text Society.
500 ## Index to: Tipit=CC=A3aka. Suttapit=CC=A3aka.
500 ## Contained in: Journal of the Pali Text Society for 1906-1907.
This does not differ from AACR2.
Many would suggest 77X linking fields for both AACR2 and RDA records.
What you have done would work better for patrons in most of the ILS we
support.
We would add:
630 0# Tipit=CC=A3aka. =C7=82p Suttapit=CC=A3aka$vIndexes.
To the 2nd 730 we would add ,$n1906-1907
In the 2nd 500 we would say Orginally published in ... rather than
Contained in ..., assuming it has been physically removed and this
is not an analytic you are doing. Too bad we lost 503.
Another way of handling the journal would be:
490 1/830 0 $aJournal of the Pali Text Society ;$v1906-1907. That
would replace both the 500 and 730.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Christopher Case
Content Management Librarian
Milton S. Eisenhower Library
Johns Hopkins University
Re: [RDA-L] Recording Relationships in MARC
Yes, those relationship designations will be a LOT easier for machine processing, they are a great idea. Compared to a note. I suppose that software could just strip out any trailing (work) prior to display. That _probably_ won't strip out anything it shoudln't. And also for that matter, strip out that trailing colon too, depending on the nature of the display. (Some displays may, for example, put it in a parenthetical suffix instead of a prefix). I thought RDA was done having us put punctuation for presentation in, and just letting the presentation software supply that? What's with the colon? But the biggest weirdness about this stuff isn't the trailing colon or the (work). It's that even though this is a value from a controlled vocabularly, it's placed in the $i free text field. Which also contains uncontrolled freetext. The software has no good way to know if an $i is from a controlled vocab (and which one), or if it's just free text. This matters because values from controlled vocab's, for instance, might be translated into other languages by the software, from a translation file. Just for example. I am somewhat dismayed that controlled RDA relation vocab is going into the $i -- and apparently the $4 is being abandoned? Previously for 700's for example, we had controlled vocab in $4, and free text in $i. This was great, although they weren't used all that much, when they were (music catalogers seem to record them somewhat frequently) Now we have them both mixed together in $i? This is a step backwards. On 12/7/2010 4:16 PM, Robert Maxwell wrote: As has been noted by others, the access points for these two works are the same in RDA as they are in AACR2. However, RDA does introduce relationship designators to link works to other works that I would use here instead of a separate note—no need to compose a note AND an added access point: 730 0# $i Index to (work): $a Tipiṭaka. ǂp Suttapiṭaka. 730 0# $i Contained in (work): $a Journal of the Pali Text Society. See RDA appendix J, which contains a list of standard relationship designators. Many of us are not happy with the addition of the parenthetical qualifier. The reason it is necessary is so that it is clear whether the thing we’re cataloging is related to a work, expression, manifestation, or item. This will be important when we attempt to take MARC records and split them into entity-relationship descriptions. Meanwhile many of us don’t feel it’s useful to display the “(work)” or “(expression)”, etc., in our public displays. If MARC coded the qualifier in a separate subfield we could suppress its display, but unfortunately it doesn’t at the moment. In any case, relationship designators is the route I would take rather than access points plus notes. Bob Robert L. Maxwell Head, Special Collections and Formats Catalog Dept. 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 *From:*Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] *On Behalf Of *Christopher Case *Sent:* Tuesday, December 07, 2010 9:46 AM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* [RDA-L] Recording Relationships in MARC Hi Folks, I'm in the midst of attempting some in-house RDA cataloging and could use a hand on relationships. Currently I am cataloging a book called Similes in the Nikayas : a classified index. The book is an extract from the Journal of the Pali Text Society for 1906-1907. I'd like to record the relationships to the Nikayas (that is, collections of texts making up the Sutta Pitaka) and the Journal of the Pali Text Society. Here's how I /think/ I should go about it. I've created access points both the Sutta Pitaka and the Journal: 730 0# Tipiṭaka. ǂp Suttapiṭaka. 730 0# Journal of the Pali Text Society. Also, I have added two 500 notes: 500 ## Index to: Tipiṭaka. Suttapiṭaka. 500 ## Contained in: Journal of the Pali Text Society for 1906-1907. Does that make sense? Would that adequately express the relationships? Apologies if this is a daft question. I've been following the progression or RDA, working through the toolkit, and trying to keep up with listserv discussions. Regardless, I've found confirmed what I previously supposed, namely that cataloging according to RDA is a far different thing from reading about cataloging according to RDA. Many thanks for any assistance you can provide. Cheers. -- Christopher Case Content Management Librarian Milton S. Eisenhower Library Johns Hopkins University
Re: [RDA-L] Recording Relationships in MARC
Here's what RDA says about contained in:
contained in (work) A larger work of which a part is a discrete component.
Reciprocal relationship: contains (work)
and the reciprocal definition:
contains (work) A work that is a discrete component of a larger work.
Reciprocal relationship: contained in (work)
Thinking about reprint is thinking about the manifestation, not the work.
Christopher originally said: Currently I am cataloging a book called Similes
in the Nikayas : a classified index. The book is an extract from the Journal
of the Pali Text Society for 1906-1907.
Similes is a discrete component of the larger work Journal of the Pali Text
Society, so at the work level, in my opinion, Contained in would be
appropriate.
This does demonstrate why those parenthetical qualifiers are important. The
relationship designators Contains and Contained in can be used at all four
levels, work, expression, manifestation, or item. It may well be that in this
particular situation contained in is not appropriate at the manifestation
level. I think that it is, however, at the work level.
Robert L. Maxwell
Head, Special Collections and Formats Catalog Dept.
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568
-Original Message-
From: Resource Description and Access / Resource Description and Access
[mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Adam L. Schiff
Sent: Tuesday, December 07, 2010 2:19 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Recording Relationships in MARC
I agree with Mac on this - contained in is not correct because you are
cataloging a reprint/extract. I think the note should be Reprinted from
... or Originally published in ... I disagree that 490/8XX is
appropriate. The resource you have is not a part of the journal and isn't
even the whole issue of the journal from what I understand.
^^
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 Tue, 7 Dec 2010, Christopher Case wrote:
Thanks for the tips. I forgot to mention the 630 which I did in fact use. As
far as Contained in, I got that
wording from Appendix J of RDA. I do feel a bit uneasy about that wording
though, as this is in fact a separate
publication, with a note on the front cover (what I used for the description
as it lacks t.p.) that it was extracted
from the Journal.
I suppose RDA does give the option of a less structured form of note, so in
this test record, I may change that.
Thanks again!
On Tue, Dec 7, 2010 at 2:36 PM, J. McRee Elrod m...@slc.bc.ca wrote:
Christopher Case posted:
730 0# Tipit=CC=A3aka. =C7=82p Suttapit=CC=A3aka.
730 0# Journal of the Pali Text Society.
500 ## Index to: Tipit=CC=A3aka. Suttapit=CC=A3aka.
500 ## Contained in: Journal of the Pali Text Society for 1906-1907.
This does not differ from AACR2.
Many would suggest 77X linking fields for both AACR2 and RDA records.
What you have done would work better for patrons in most of the ILS we
support.
We would add:
630 0# Tipit=CC=A3aka. =C7=82p Suttapit=CC=A3aka$vIndexes.
To the 2nd 730 we would add ,$n1906-1907
In the 2nd 500 we would say Orginally published in ... rather than
Contained in ..., assuming it has been physically removed and this
is not an analytic you are doing. Too bad we lost 503.
Another way of handling the journal would be:
490 1/830 0 $aJournal of the Pali Text Society ;$v1906-1907. That
would replace both the 500 and 730.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Christopher Case
Content Management Librarian
Milton S. Eisenhower Library
Johns Hopkins University
Re: [RDA-L] Recording Relationships in MARC
Jonathan Rochkind rochk...@jhu.edu wrote: And also for that matter, strip out that trailing colon too, depending on the nature of the display. (Some displays may, for example, put it in a parenthetical suffix instead of a prefix). I thought RDA was done having us put punctuation for presentation in, and just letting the presentation software supply that? What's with the colon? RDA says squat about how these things should be punctuated. The initial capital letter and the colon are LC conventions, likely to become de rigueur by sheer force of inertia if RDA is implemented. (See Bibliographic Linking Entries under LCPS 1.7.1.) I agree that keeping these terms pure is the better way to go unless catalog systems can't translated these into something more digestible (read: pretty) for the public displays. -- Mark K. Ehlert Minitex Coordinator University of Minnesota Bibliographic Technical 15 Andersen Library Services (BATS) Unit 222 21st Avenue South Phone: 612-624-0805 Minneapolis, MN 55455-0439 http://www.minitex.umn.edu/
Re: [RDA-L] Recording Relationships in MARC
I added the colons myself. RDA probably doesn’t prescribe them, though I haven’t searched thoroughly. I believe you are referring to the relationship between $4 (relator code) and $e (relator term). $e or $4 is used to show the relationship between a person/family/corporate body and a work/expression/manifestation/ or item. Subfield $i is new to MARC and it is intended to be used to show relationships between works, expressions, manifestations, and other works/expressions/manifestations/items. Both $e and $4 are controlled, in the sense that we are supposed to use terms from official lists; $i is also controlled in this same way, at least for RDA cataloging where we are directed to take the terms from a controlled list (I do see the MARC documentation allows for controlled and uncontrolled use of the subfield). Controlled or not, it’s certainly possible to put invalid values in any of these fields—nothing’s stopping me from putting an incorrect set of code letters in $4 or incorrect terms in $e (at least not in my local system—OCLC might have some way of ensuring correct codes), so I’m not sure I see how the addition of $i is any different. However, I believe you are correct, there isn’t a provision to use codes instead of $i, as there is to use $4 (code) instead of $e (term) if we want. Possibly that would be a desirable development. Bob Robert L. Maxwell Head, Special Collections and Formats Catalog Dept. 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 From: Jonathan Rochkind [mailto:rochk...@jhu.edu] Sent: Tuesday, December 07, 2010 2:23 PM To: Resource Description and Access / Resource Description and Access Cc: Robert Maxwell Subject: Re: [RDA-L] Recording Relationships in MARC Yes, those relationship designations will be a LOT easier for machine processing, they are a great idea. Compared to a note. I suppose that software could just strip out any trailing (work) prior to display. That _probably_ won't strip out anything it shoudln't. And also for that matter, strip out that trailing colon too, depending on the nature of the display. (Some displays may, for example, put it in a parenthetical suffix instead of a prefix). I thought RDA was done having us put punctuation for presentation in, and just letting the presentation software supply that? What's with the colon? But the biggest weirdness about this stuff isn't the trailing colon or the (work). It's that even though this is a value from a controlled vocabularly, it's placed in the $i free text field. Which also contains uncontrolled freetext. The software has no good way to know if an $i is from a controlled vocab (and which one), or if it's just free text. This matters because values from controlled vocab's, for instance, might be translated into other languages by the software, from a translation file. Just for example. I am somewhat dismayed that controlled RDA relation vocab is going into the $i -- and apparently the $4 is being abandoned? Previously for 700's for example, we had controlled vocab in $4, and free text in $i. This was great, although they weren't used all that much, when they were (music catalogers seem to record them somewhat frequently) Now we have them both mixed together in $i? This is a step backwards. On 12/7/2010 4:16 PM, Robert Maxwell wrote: As has been noted by others, the access points for these two works are the same in RDA as they are in AACR2. However, RDA does introduce relationship designators to link works to other works that I would use here instead of a separate note—no need to compose a note AND an added access point: 730 0# $i Index to (work): $a Tipiṭaka. ǂp Suttapiṭaka. 730 0# $i Contained in (work): $a Journal of the Pali Text Society. See RDA appendix J, which contains a list of standard relationship designators. Many of us are not happy with the addition of the parenthetical qualifier. The reason it is necessary is so that it is clear whether the thing we’re cataloging is related to a work, expression, manifestation, or item. This will be important when we attempt to take MARC records and split them into entity-relationship descriptions. Meanwhile many of us don’t feel it’s useful to display the “(work)” or “(expression)”, etc., in our public displays. If MARC coded the qualifier in a separate subfield we could suppress its display, but unfortunately it doesn’t at the moment. In any case, relationship designators is the route I would take rather than access points plus notes. Bob Robert L. Maxwell Head, Special Collections and Formats Catalog Dept. 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Christopher Case Sent: Tuesday, December 07, 2010 9:46 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CAmailto:RDA-L@LISTSERV.LAC-BAC.GC.CA
Re: [RDA-L] Recording Relationships in MARC
Thanks for straightening me out, Bob!
^^
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 Tue, 7 Dec 2010, Robert Maxwell wrote:
Here's what RDA says about contained in:
contained in (work) A larger work of which a part is a discrete component.
Reciprocal relationship: contains (work)
and the reciprocal definition:
contains (work) A work that is a discrete component of a larger work.
Reciprocal relationship: contained in (work)
Thinking about reprint is thinking about the manifestation, not the work. Christopher
originally said: Currently I am cataloging a book called Similes in the Nikayas : a
classified index. The book is an extract from the Journal of the Pali Text Society for
1906-1907.
Similes is a discrete component of the larger work Journal of the Pali Text Society,
so at the work level, in my opinion, Contained in would be appropriate.
This does demonstrate why those parenthetical qualifiers are important. The relationship designators
Contains and Contained in can be used at all four levels, work, expression,
manifestation, or item. It may well be that in this particular situation contained in is not
appropriate at the manifestation level. I think that it is, however, at the work level.
Robert L. Maxwell
Head, Special Collections and Formats Catalog Dept.
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568
-Original Message-
From: Resource Description and Access / Resource Description and Access
[mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Adam L. Schiff
Sent: Tuesday, December 07, 2010 2:19 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Recording Relationships in MARC
I agree with Mac on this - contained in is not correct because you are
cataloging a reprint/extract. I think the note should be Reprinted from
... or Originally published in ... I disagree that 490/8XX is
appropriate. The resource you have is not a part of the journal and isn't
even the whole issue of the journal from what I understand.
^^
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 Tue, 7 Dec 2010, Christopher Case wrote:
Thanks for the tips. I forgot to mention the 630 which I did in fact use. As far as
Contained in, I got that
wording from Appendix J of RDA. I do feel a bit uneasy about that wording
though, as this is in fact a separate
publication, with a note on the front cover (what I used for the description as
it lacks t.p.) that it was extracted
from the Journal.
I suppose RDA does give the option of a less structured form of note, so in
this test record, I may change that.
Thanks again!
On Tue, Dec 7, 2010 at 2:36 PM, J. McRee Elrod m...@slc.bc.ca wrote:
Christopher Case posted:
730 0# Tipit=CC=A3aka. =C7=82p Suttapit=CC=A3aka.
730 0# Journal of the Pali Text Society.
500 ## Index to: Tipit=CC=A3aka. Suttapit=CC=A3aka.
500 ## Contained in: Journal of the Pali Text Society for 1906-1907.
This does not differ from AACR2.
Many would suggest 77X linking fields for both AACR2 and RDA records.
What you have done would work better for patrons in most of the ILS we
support.
We would add:
630 0# Tipit=CC=A3aka. =C7=82p Suttapit=CC=A3aka$vIndexes.
To the 2nd 730 we would add ,$n1906-1907
In the 2nd 500 we would say Orginally published in ... rather than
Contained in ..., assuming it has been physically removed and this
is not an analytic you are doing. Too bad we lost 503.
Another way of handling the journal would be:
490 1/830 0 $aJournal of the Pali Text Society ;$v1906-1907. That
would replace both the 500 and 730.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Christopher Case
Content Management Librarian
Milton S. Eisenhower Library
Johns Hopkins University
Re: [RDA-L] Recording Relationships in MARC
Ah, I did get confused by all the subfields. Indeed there can be errant entry in any field, but recognizing the difference between _errant_ entry of a controlled value (which generally should be ignored and reported to catalogers as an error), and _uncontrolled_ free text entry --- is exactly an example of why it's neccesary to keep controlled data elements seperate from free text elements. But I got confused about the $i. Okay, $i is new, and while MARC allows combining free text and RDA controlled values in there, I'm unlikely to see anything but RDA controlled values (assuming RDA moves forward). Okay, could be worse. It doens't actually matter to me if the controlled value is from a human-readable list (like contained in (work)) or a shorthand series of numbers (like in $4). It's all the same to software, if it's an entry from a specific set of defined possibilities. So for instance, even contained in (work), could be changed at the point of display if it's something we think is confusing -- maybe we want to say part of instead, even though that's not the RDA term, because we think it will make more sense to our users, as per this discussion. If every $i is from the controlled RDA list, then software can make that change. But that's a reason NOT to just go entering free text in there (please!), because then software _can't_ do anything with it. Think of contained in (work) as just indicating that it represents a certain relationship defined by RDA. It happens to be represented in a way that will often be displayable to the user (to support legacy systems and their use of MARC), but if you want to display this particular relationship to the user using a different string, that should be done at the software level, not by freely entering your preferred string in the $i. Becuase if you do the latter, the software no longer has any idea which of the defined RDA relationships it represents. I guess my original issue is really with $e and $4. Am I right that RDA relator terms will in some cases go in an $e (when they relationship destination is to a Person rather than an WEM), and thus our $e values will contain a potpourri of both RDA controlled terms, and freely entered terms? THAT's the problem I was originally talking about, but I got confused about the $i, yes. On 12/7/2010 4:46 PM, Robert Maxwell wrote: I added the colons myself. RDA probably doesn’t prescribe them, though I haven’t searched thoroughly. I believe you are referring to the relationship between $4 (relator code) and $e (relator term). $e or $4 is used to show the relationship between a person/family/corporate body and a work/expression/manifestation/ or item. Subfield $i is new to MARC and it is intended to be used to show relationships between works, expressions, manifestations, and other works/expressions/manifestations/items. Both $e and $4 are controlled, in the sense that we are supposed to use terms from official lists; $i is also controlled in this same way, at least for RDA cataloging where we are directed to take the terms from a controlled list (I do see the MARC documentation allows for controlled and uncontrolled use of the subfield). Controlled or not, it’s certainly possible to put invalid values in any of these fields—nothing’s stopping me from putting an incorrect set of code letters in $4 or incorrect terms in $e (at least not in my local system—OCLC might have some way of ensuring correct codes), so I’m not sure I see how the addition of $i is any different. However, I believe you are correct, there isn’t a provision to use codes instead of $i, as there is to use $4 (code) instead of $e (term) if we want. Possibly that would be a desirable development. Bob Robert L. Maxwell Head, Special Collections and Formats Catalog Dept. 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 *From:*Jonathan Rochkind [mailto:rochk...@jhu.edu] *Sent:* Tuesday, December 07, 2010 2:23 PM *To:* Resource Description and Access / Resource Description and Access *Cc:* Robert Maxwell *Subject:* Re: [RDA-L] Recording Relationships in MARC Yes, those relationship designations will be a LOT easier for machine processing, they are a great idea. Compared to a note. I suppose that software could just strip out any trailing (work) prior to display. That _probably_ won't strip out anything it shoudln't. And also for that matter, strip out that trailing colon too, depending on the nature of the display. (Some displays may, for example, put it in a parenthetical suffix instead of a prefix). I thought RDA was done having us put punctuation for presentation in, and just letting the presentation software supply that? What's with the colon? But the biggest weirdness about this stuff isn't the trailing colon or the (work). It's that even though this is a value from a controlled vocabularly, it's placed in the $i free text field.
Re: [RDA-L] Recording Relationships in MARC
And I would still add a note. If we really want to be user-centered, we should compose notes that are easily comprehended by the user and not depend on relators which may or may not be understandable to the patron. Besides, in the old days, notes were used to justify entries. The by-product of that was composing a note that was not in jargon or mystic language. On Tue, Dec 7, 2010 at 1:59 PM, Jonathan Rochkind rochk...@jhu.edu wrote: Ah, I did get confused by all the subfields. Indeed there can be errant entry in any field, but recognizing the difference between _errant_ entry of a controlled value (which generally should be ignored and reported to catalogers as an error), and _uncontrolled_ free text entry --- is exactly an example of why it's neccesary to keep controlled data elements seperate from free text elements. But I got confused about the $i. Okay, $i is new, and while MARC allows combining free text and RDA controlled values in there, I'm unlikely to see anything but RDA controlled values (assuming RDA moves forward). Okay, could be worse. It doens't actually matter to me if the controlled value is from a human-readable list (like contained in (work)) or a shorthand series of numbers (like in $4). It's all the same to software, if it's an entry from a specific set of defined possibilities. So for instance, even contained in (work), could be changed at the point of display if it's something we think is confusing -- maybe we want to say part of instead, even though that's not the RDA term, because we think it will make more sense to our users, as per this discussion. If every $i is from the controlled RDA list, then software can make that change. But that's a reason NOT to just go entering free text in there (please!), because then software _can't_ do anything with it. Think of contained in (work) as just indicating that it represents a certain relationship defined by RDA. It happens to be represented in a way that will often be displayable to the user (to support legacy systems and their use of MARC), but if you want to display this particular relationship to the user using a different string, that should be done at the software level, not by freely entering your preferred string in the $i. Becuase if you do the latter, the software no longer has any idea which of the defined RDA relationships it represents. I guess my original issue is really with $e and $4. Am I right that RDA relator terms will in some cases go in an $e (when they relationship destination is to a Person rather than an WEM), and thus our $e values will contain a potpourri of both RDA controlled terms, and freely entered terms? THAT's the problem I was originally talking about, but I got confused about the $i, yes. On 12/7/2010 4:46 PM, Robert Maxwell wrote: I added the colons myself. RDA probably doesn’t prescribe them, though I haven’t searched thoroughly. I believe you are referring to the relationship between $4 (relator code) and $e (relator term). $e or $4 is used to show the relationship between a person/family/corporate body and a work/expression/manifestation/ or item. Subfield $i is new to MARC and it is intended to be used to show relationships between works, expressions, manifestations, and other works/expressions/manifestations/items. Both $e and $4 are controlled, in the sense that we are supposed to use terms from official lists; $i is also controlled in this same way, at least for RDA cataloging where we are directed to take the terms from a controlled list (I do see the MARC documentation allows for controlled and uncontrolled use of the subfield). Controlled or not, it’s certainly possible to put invalid values in any of these fields—nothing’s stopping me from putting an incorrect set of code letters in $4 or incorrect terms in $e (at least not in my local system—OCLC might have some way of ensuring correct codes), so I’m not sure I see how the addition of $i is any different. However, I believe you are correct, there isn’t a provision to use codes instead of $i, as there is to use $4 (code) instead of $e (term) if we want. Possibly that would be a desirable development. Bob Robert L. Maxwell Head, Special Collections and Formats Catalog Dept. 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 *From:* Jonathan Rochkind [mailto:rochk...@jhu.edu rochk...@jhu.edu] *Sent:* Tuesday, December 07, 2010 2:23 PM *To:* Resource Description and Access / Resource Description and Access *Cc:* Robert Maxwell *Subject:* Re: [RDA-L] Recording Relationships in MARC Yes, those relationship designations will be a LOT easier for machine processing, they are a great idea. Compared to a note. I suppose that software could just strip out any trailing (work) prior to display. That _probably_ won't strip out anything it shoudln't. And also for that matter, strip out that trailing
Re: [RDA-L] Recording Relationships in MARC
Yes, $e/$4 is still used in RDA encoded in MARC to show relationships between persons/familes/corporate bodies and works/expressions/manifestations/items. 1001 Jones, Raymond F. ǂq (Raymond Fisher), ǂd 1915-1994, ǂe author. 24510Planet of light : ǂb a science fiction novel / ǂc by Raymond F. Jones ; jacket and endpaper designs by Alex Schomburg. … 7001 ǂi Sequel to (Work): ǂa Jones, Raymond F. ǂq (Raymond Fisher), ǂd 1915-1994. ǂt Son of the stars. The $e in 100 shows the relationship of Jones to the work Planet of light (here uneasily represented in MARC bibliographic by the 245 field, which really is an element of the manifestation … RDA poured into MARC isn’t a perfect fit, new wine in old bottles so to speak); the $i in 700 shows the relationship of Planet of Light to Son of the stars. My understanding, though this is not explicit in RDA, is that $e values in RDA do not contain a potpourri of RDA values and uncontrolled terms. RDA does include a controlled list, but one cataloging community I am a part of (rare materials) was assured when RDA was under development that this controlled list is not a closed list. “Not closed” is not the same as “not controlled”, and I interpret this to mean that the situation is the same as it was under AACR2 21.0D, where we were instructed to take terms from “standard lists”. The standard list developed by the rare community is available separately, but has also been incorporated into the MARC list at http://www.loc.gov/marc/relators/, which is itself a “standard list”. The need to use terms or codes from standard lists is not explicit in RDA and should be. RDA 18.5 simply says: “If none of the terms listed in appendix I is appropriate or sufficiently specific, use a term designating the nature of the relationship as concisely as possible.” I agree with you that these fields should not be populated with uncontrolled terms. It would be good if RDA directed catalogers to standard lists such as the MARC list, to use when the terms in Appendix I are not appropriate or sufficiently specific. Bob Robert L. Maxwell Head, Special Collections and Formats Catalog Dept. 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 From: Jonathan Rochkind [mailto:rochk...@jhu.edu] Sent: Tuesday, December 07, 2010 3:00 PM To: Robert Maxwell Cc: Resource Description and Access / Resource Description and Access Subject: Re: [RDA-L] Recording Relationships in MARC Ah, I did get confused by all the subfields. Indeed there can be errant entry in any field, but recognizing the difference between _errant_ entry of a controlled value (which generally should be ignored and reported to catalogers as an error), and _uncontrolled_ free text entry --- is exactly an example of why it's neccesary to keep controlled data elements seperate from free text elements. But I got confused about the $i. Okay, $i is new, and while MARC allows combining free text and RDA controlled values in there, I'm unlikely to see anything but RDA controlled values (assuming RDA moves forward). Okay, could be worse. It doens't actually matter to me if the controlled value is from a human-readable list (like contained in (work)) or a shorthand series of numbers (like in $4). It's all the same to software, if it's an entry from a specific set of defined possibilities. So for instance, even contained in (work), could be changed at the point of display if it's something we think is confusing -- maybe we want to say part of instead, even though that's not the RDA term, because we think it will make more sense to our users, as per this discussion. If every $i is from the controlled RDA list, then software can make that change. But that's a reason NOT to just go entering free text in there (please!), because then software _can't_ do anything with it. Think of contained in (work) as just indicating that it represents a certain relationship defined by RDA. It happens to be represented in a way that will often be displayable to the user (to support legacy systems and their use of MARC), but if you want to display this particular relationship to the user using a different string, that should be done at the software level, not by freely entering your preferred string in the $i. Becuase if you do the latter, the software no longer has any idea which of the defined RDA relationships it represents. I guess my original issue is really with $e and $4. Am I right that RDA relator terms will in some cases go in an $e (when they relationship destination is to a Person rather than an WEM), and thus our $e values will contain a potpourri of both RDA controlled terms, and freely entered terms? THAT's the problem I was originally talking about, but I got confused about the $i, yes. On 12/7/2010 4:46 PM, Robert Maxwell wrote: I added the colons myself. RDA probably doesn’t prescribe them, though I haven’t searched thoroughly. I believe you are
Re: [RDA-L] Recording Relationships in MARC
Ideally, the software would convert from the controlled vocabulary to whatever language makes makes sense to the user -- which could be different in different systems -- translating to a different language is an obvious example. A free text note field can't be translated to another language, a choice from a controlled list can be. It doesn't really hurt anything to have a controlled element AND a note -- except taking expensive cataloger time. If you're only doing it because your system _won't_ display the controlled value in a reasonable way, it makes more sense to spend time/money fixing the system to do so, then it does expensive cataloger time entering a note as a workaround. Of course, the legacy systems most of us have are SO far from actually being able to meet our needs, that it is indeed unclear how to do with it. This is a definite problem. But trying to work around it with very expensive cataloger time is not sustainable -- and trying to custom fit your data to the idiosyncracies of your current interface only results in data that will need to be fixed later for a different interface, an even more expensive proposition. On 12/7/2010 5:12 PM, Gene Fieg wrote: And I would still add a note. If we really want to be user-centered, we should compose notes that are easily comprehended by the user and not depend on relators which may or may not be understandable to the patron. Besides, in the old days, notes were used to justify entries. The by-product of that was composing a note that was not in jargon or mystic language. On Tue, Dec 7, 2010 at 1:59 PM, Jonathan Rochkind rochk...@jhu.edu mailto:rochk...@jhu.edu wrote: Ah, I did get confused by all the subfields. Indeed there can be errant entry in any field, but recognizing the difference between _errant_ entry of a controlled value (which generally should be ignored and reported to catalogers as an error), and _uncontrolled_ free text entry --- is exactly an example of why it's neccesary to keep controlled data elements seperate from free text elements. But I got confused about the $i. Okay, $i is new, and while MARC allows combining free text and RDA controlled values in there, I'm unlikely to see anything but RDA controlled values (assuming RDA moves forward). Okay, could be worse. It doens't actually matter to me if the controlled value is from a human-readable list (like contained in (work)) or a shorthand series of numbers (like in $4). It's all the same to software, if it's an entry from a specific set of defined possibilities. So for instance, even contained in (work), could be changed at the point of display if it's something we think is confusing -- maybe we want to say part of instead, even though that's not the RDA term, because we think it will make more sense to our users, as per this discussion. If every $i is from the controlled RDA list, then software can make that change. But that's a reason NOT to just go entering free text in there (please!), because then software _can't_ do anything with it. Think of contained in (work) as just indicating that it represents a certain relationship defined by RDA. It happens to be represented in a way that will often be displayable to the user (to support legacy systems and their use of MARC), but if you want to display this particular relationship to the user using a different string, that should be done at the software level, not by freely entering your preferred string in the $i. Becuase if you do the latter, the software no longer has any idea which of the defined RDA relationships it represents. I guess my original issue is really with $e and $4. Am I right that RDA relator terms will in some cases go in an $e (when they relationship destination is to a Person rather than an WEM), and thus our $e values will contain a potpourri of both RDA controlled terms, and freely entered terms? THAT's the problem I was originally talking about, but I got confused about the $i, yes. On 12/7/2010 4:46 PM, Robert Maxwell wrote: I added the colons myself. RDA probably doesn’t prescribe them, though I haven’t searched thoroughly. I believe you are referring to the relationship between $4 (relator code) and $e (relator term). $e or $4 is used to show the relationship between a person/family/corporate body and a work/expression/manifestation/ or item. Subfield $i is new to MARC and it is intended to be used to show relationships between works, expressions, manifestations, and other works/expressions/manifestations/items. Both $e and $4 are controlled, in the sense that we are supposed to use terms from official lists; $i is also controlled in this same way, at least for RDA cataloging where we are directed to take the terms from a controlled list (I do
Re: [RDA-L] Recording Relationships in MARC
Robert Maxwell said:
in my opinion, Contained in would be appropriate.
Contained in would mislead the patron to think that the present
physiclly manifestation (removed, reprint, offprint, whatever), is
physically contained in a larger manifestation. That is not the case.
Theory should not get in the way of being truthful for patrons'
benefit. RDA would lead to many misleading wordings if adopted, the
worst perhaps being calling electronic resources computer, but this
is another example.
If using 490/830 for a portion of an issue, the $v should contain page
numbers as well as issue number and/or date. Sorry I did not know
those to give in my sample.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Recording Relationships in MARC
Robert Maxwell said:
730 0# $i Index to (work): $a TipitÌ£aka. Çp SuttapitÌ£aka.
We would find more helpful:
630 0# $a TipitÌ£aka. Çp SuttapitÌ£aka$vIndexes.
730 0# $i Contained in (work): $a Journal of the Pali Text Society.
But it is NOT contained in the Journal. Why would we lie to patrons?
It was originally published in the Journal.
One could be truthfully say:
730 0# $iOrginally published in: $a Journal of the Pali Text
Society,$n1905-1906, pages xxx-xxx.
All relationships can't be reduced to a set list of phrases.
We presently plan to delete $i's in added entries on export. They are
too misleading, and present OPACs aren't equipped to display them.
Yes, what I put in 730$i is free text. Better free text than a lie!
I don't *want* the computer to do anything with it but display it.
But 490/830 or 503/730 would work without expensive ILS upgrades.
Having it machince changed to Part of is also a lie, even if a more
easily understood lie. Is the game worth the candle?
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Recording Relationships in MARC
Quoting Maria Oldal old...@themorgan.org: RDA does not seem to allow relator terms to be used in authorized access points for works and expressions, e.g.: 7001 ǂi Sequel to (Work): ǂa Jones, Raymond F. ǂq (Raymond Fisher), ǂd 1915-1994, ǂe author. ǂt Son of the stars. At least, none of the examples given include a relator term in an author/title access point, although RDA encourages the use of relator terms with names used as access points. Is there a reason for this? As I see it, the terms in the 7XX access point are the name-title combination by which the work is specified: a formal citation form. If the personal name is not the (or the first) creator, it isn't used here -- a uniform title (AACR2 term! 730) is provided instead. In some catalogues they can be a hyperlink. An embedded relator $e or $4 would compromise such a link. Hal Cain Melbourne, Australia hec...@dml.vic.edu.au This message was sent using IMP, the Internet Messaging Program.
Re: [RDA-L] Recording Relationships in MARC
Mac's comment here points to the huge question of how the ILS will be able
to interpret metadata to users. As difficult as it has been to communicate
the WEMI concepts to librarians, I expect that it will become even more
challenging for a typical user to interpret a Contained in (work) note,
not understanding the conceptual aspect of FRBR structure as distinct from
the physical description to which they (and, to be sure, we) are accustomed.
Aaron
Aaron Smith
Cataloger, The Genealogy Center
Allen County Public Library
Fort Wayne, Ind.
aaronkaysm...@gmail.com
On Tue, Dec 7, 2010 at 6:19 PM, J. McRee Elrod m...@slc.bc.ca wrote:
Robert Maxwell said:
730 0# $i Index to (work): $a Tipiṭaka. ǂp Suttapiṭaka.
We would find more helpful:
630 0# $a Tipiṭaka. ǂp Suttapiṭaka$vIndexes.
730 0# $i Contained in (work): $a Journal of the Pali Text Society.
But it is NOT contained in the Journal. Why would we lie to patrons?
It was originally published in the Journal.
One could be truthfully say:
730 0# $iOrginally published in: $a Journal of the Pali Text
Society,$n1905-1906, pages xxx-xxx.
All relationships can't be reduced to a set list of phrases.
We presently plan to delete $i's in added entries on export. They are
too misleading, and present OPACs aren't equipped to display them.
Yes, what I put in 730$i is free text. Better free text than a lie!
I don't *want* the computer to do anything with it but display it.
But 490/830 or 503/730 would work without expensive ILS upgrades.
Having it machince changed to Part of is also a lie, even if a more
easily understood lie. Is the game worth the candle?
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Recording Relationships in MARC
Jonathan Rochdkind said:
,,, trying to custom fit your data to the idiosyncracies of your
current interface only results in data that will need to be fixed
later ...
What about describing your item using a controlled vocabulary which
doesn't accurately represent what is being catalogued?
With subject headings we can resort fo 2nd indicator 4 if need be.
7XX$i should not be more restrictive than 6XX.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Recording Relationships in MARC
I think Mac's comment But it is NOT contained in the Journal is useful because the important thing to ask is what it is. If it is a reprint of an extract, then we're dealing with related manifestations. If it is a work, then using 730 with contained in (work) is correct, but it's not the relationship that addresses the FRBR user tasks of find and understand from RDA Chapter 24 in this instance. A user should be able to find the relevant entity (in this case, a manifestation) that contains the same content, as well as understand the relationship between the two manifestation entities (RDA 24.2 Functional Objective and Principles, under General Guidelines on Recording Relatonships between Works, Expressions, Manifestations and Items). I think that the following RDA rules can help put the pieces of the puzzle together: Starting with the relationship designators we have this candidate: J.4.2 Equivalent Manifestation Relationships equivalent manifestation A manifestation embodying the same expression of a work. I think this captures the idea that the book in hand has an equivalent manifestation that contains the same content (although one still needs to address the problem that only a part of the original manifestation is being reprinted-- I'll get to that below). The FRBR manifestation entity inherits the entities above it, so we're on safe ground in using this method to capture the fact we're also interested in the identical work in both manifestations. There is a specific designator for equivalent manifestations reprint of (manifestation) which I think is the correct one to use (RDA J.4.2). RDA presents 4 ways of establishing relationships: 1. via identifier 2. via authorized access point 3. via structured description 4. via unstructured description In addition, relationship designators are used in methods 1, 2 and 3 but not with unstructured descriptions, which are essential free-form notes (RDA Chapter 24.5). Of interest in this section is the RDA rule If none of the terms listed in Appendix J is appropriate or sufficiently specific, use a term designating the nature of the relationship as concisely as possible. However, to keep it simple, I'll stick with the reprint of (manifestation) designator. There is an example for a reprint in 24.4.3-- the relationship designator is used with a structured description. One can look at how Reprint of (manifestation) is mapped in MARC. In the RDA to MARC Bibliographic Mapping tool in the RDA Toolkit, Reprint of (manifestation) can be mapped to identifiers or structured descriptions using either field 534 or field 775. It can also be mapped to an unstructured description using field 500. An authorized access point cannot be used with any manifestation relationship designator, so using 730 is wrong for related manifestations. Field 534 looks promising because it has examples that include relevant wording such as Originally published. However, there is no subfield to record serial part numbering, and there is only subfield p that perhaps could be used for a relationship designator. Field 775 on the other hand, because it's often used for serials, has a subfield (g) for numbering of issues as well as page numbering, and it also supports subfield i for relationship designators (and MARC21 has RDA examples already with relationship designators in subfield i in comparable situations, http://www.loc.gov/marc/bibliographic/bd76x78x.html). Field 775 is used in several situations, but the relevant one is likely Regular-print reprints When the serial being catalogued is a regular-print reprint, field 775 is used for the original entry. In RDA 775 $g is covered under RDA 24.6 Numbering of part. This is where series numbering of series authorized access points is handled, but it also covers numbered issues of serials in just these situations. In MARC Bibliographic to RDA Mapping, 775 $g maps to RDA 24.6. So, RDA allows a structured description and a controlled value relationship designator and a Numbering of Part element to be used to establish a relationship between equivalent manifestations that contain the same work: 775 08 $i reprint of (manifestation) $t Journal of the Pali Text Society $g 1906-1907, pages xx-xx Interestingly, since $g is covered by RDA 24.6 Numbering of part that means it's one of the few remaining elements to be covered by the abbreviation rules (RDA B.5.5.). However, the abbreviation for pages doesn't exist at all in RDA and so is still not allowed even here (although v. and pt. and bk. can be used in the Numbering of part element-- RDA B.7). Second indicator 8 overrides the display constant Other edition available and allows subfield i to stand, but MARC leaves open the possibility of converting the value in subfield i. MARC21 in http://www.loc.gov/marc/bibliographic/bd76x78x.html has examples for subfield i that show how relationship designators can be displayed, so this field could be
Re: [RDA-L] Recording Relationships in MARC
Quoting Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca: Starting with the relationship designators we have this candidate: J.4.2 Equivalent Manifestation Relationships equivalent manifestation A manifestation embodying the same expression of a work. I think this captures the idea that the book in hand has an equivalent manifestation that contains the same content (although one still needs to address the problem that only a part of the original manifestation is being reprinted-- I'll get to that below). The FRBR manifestation entity inherits the entities above it, so we're on safe ground in using this method to capture the fact we're also interested in the identical work in both manifestations. There is a specific designator for equivalent manifestations reprint of (manifestation) which I think is the correct one to use (RDA J.4.2). What about *simultaneous* manifestations? Many a book I've dealt with has been published simultaneously by different publishers, usually in different parts of the world, and with different title pages -- UK and US, but sometimes UK, US, Canada and Australia (I kid you not). By simultaneous I mean in the same year, as far as the information on the items in hand goes. In the case in hand, lacking further explicit information (which may be discoverable with a bit of hunting), I wonder whether this volume was published simultaneously with the material issued in the journal? I've handled such volumes in the past. Not an extract (even if the publisher calls it so) but a simultaneous publication. For contemporary cases of simultaneous publication as a serial issue and as a monograph, see titles published by Haworth Press which are simultaneous with numbers of their various of their serial titles. One can look at how Reprint of (manifestation) is mapped in MARC. In the RDA to MARC Bibliographic Mapping tool in the RDA Toolkit, Reprint of (manifestation) can be mapped to identifiers or structured descriptions using either field 534 or field 775. It can also be mapped to an unstructured description using field 500. An authorized access point cannot be used with any manifestation relationship designator, so using 730 is wrong for related manifestations. Subfield i is available in 730. Hal Cain, who may well have missed something Melbourne, Australia hec...@dml.vic.edu.au This message was sent using IMP, the Internet Messaging Program.
