Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Hi Karen and all, The V/FRBR project (which I left behind a year ago when I left IU for UNC) originally intended to do more than mockups and actually create a working cataloging system, but we ended up not having the development resources to pull that off in the 3-year IMLS-funded project (that ended September 2011). Someone else is welcome to do so, of course! The project after I left did release some basic RDF data (downloadable only, not available in real time via anything like SPARQL); it's at http://www.dlib.indiana.edu/projects/vfrbr/data/rdf/index.shtml. I haven't had the time to examine the final RDF in detail, so I'm not sure to what degree they were in the end able to build on RDA and FRBR defined properties/classes in the Open Metadata Registry vs. using locally-defined properties and classes. But there should be a decent amount of info in the RDF on that page and the OWL ontology and other docs linked from there. Jenn Jenn Riley Head, Carolina Digital Library and Archives The University of North Carolina at Chapel Hill http://cdla.unc.edu/ http://www.lib.unc.edu/users/jlriley jennri...@unc.edu (919) 843-5910 On 11/13/11 8:35 PM, Karen Coyle li...@kcoyle.net wrote: Jenn, these mock ups of input pages are great! Is there any chance of hooking them up to an application that would allow folks to play with RDA data? If so, could the data be connected to the registered RDA elements? [1] kc [1] http://metadataregistry.org/rdabrowse.htm Quoting Riley, Jenn jlri...@email.unc.edu: On 11/9/11 11:33 AM, Karen Coyle li...@kcoyle.net wrote: p.s. We really need to mock up a couple of potential new input views so that people can see beyond MARC Here's one set of mockups, some with screencasts talking through them: http://www.dlib.indiana.edu/projects/vfrbr/projectDoc/metadata/cataloging To ol/index.shtml. Jenn Jenn Riley Head, Carolina Digital Library and Archives The University of North Carolina at Chapel Hill http://cdla.unc.edu/ http://www.lib.unc.edu/users/jlriley jennri...@unc.edu (919) 843-5910 -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Jenn, these mock ups of input pages are great! Is there any chance of hooking them up to an application that would allow folks to play with RDA data? If so, could the data be connected to the registered RDA elements? [1] kc [1] http://metadataregistry.org/rdabrowse.htm Quoting Riley, Jenn jlri...@email.unc.edu: On 11/9/11 11:33 AM, Karen Coyle li...@kcoyle.net wrote: p.s. We really need to mock up a couple of potential new input views so that people can see beyond MARC Here's one set of mockups, some with screencasts talking through them: http://www.dlib.indiana.edu/projects/vfrbr/projectDoc/metadata/catalogingTo ol/index.shtml. Jenn Jenn Riley Head, Carolina Digital Library and Archives The University of North Carolina at Chapel Hill http://cdla.unc.edu/ http://www.lib.unc.edu/users/jlriley jennri...@unc.edu (919) 843-5910 -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On 11/9/11 11:33 AM, Karen Coyle li...@kcoyle.net wrote: p.s. We really need to mock up a couple of potential new input views so that people can see beyond MARC Here's one set of mockups, some with screencasts talking through them: http://www.dlib.indiana.edu/projects/vfrbr/projectDoc/metadata/catalogingTo ol/index.shtml. Jenn Jenn Riley Head, Carolina Digital Library and Archives The University of North Carolina at Chapel Hill http://cdla.unc.edu/ http://www.lib.unc.edu/users/jlriley jennri...@unc.edu (919) 843-5910
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
-Original Message- From: J. McRee Elrod [mailto:m...@slc.bc.ca] Sent: November 9, 2011 11:42 AM To: Brenndorfer, Thomas Cc: RDA-L@listserv.lac-bac.gc.ca Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Thomas said: An artist responsible for the artistic content of the work would always form part of the authorized access point for the work. In terms of exhibition catalogues, the artist would be main entry if reproductions exceed text, but he text author (curator) would be main entry if text exceeds reproductions. I assume this is true for RDA as it is for AACR2. Our art library clients will not accept that. From their point of few, the amount of text is irrelevant. Perhaps this is something to be taken up in a special genre manual? One difference in RDA is that if the artist is secondary to the author of the text, the artist is still considered a creator of the work, even though the writer of the text is given prominence in the authorized access point for the work. In MARC, there is only the awkward split between 100 and 700 fields, with optional added relationship designators, to distinguish roles and relationships. Dumping the artist in a 700 field, amongst other names which are connected to the expression or manifestation, is one thing that makes MARC less amenable to the type of display and relationship structures used in many data systems. In RDA, there can be several creators or other persons associated with the work specifically designated as such. Only one creator can be used in the formation of an authorized access point (barring the alternative in RDA 6.27.1.3 which allows for all creators to be included as part of the authorized access point for the work). But RDA is written around the idea that the authorized access point for a work (aka main entry) is only one of many ways to identify a work, and so a switch in thinking is required in moving from worrying about the right main entry (and creating implicit, seemingly arbitrary, or hard to discern relationships) to thinking of the right kind of relationships to make in a thorough and exacting way first, with the main entry decision as a follow-up only, so as to maintain compatibility in those systems that rely heavily on the main entry. Basically RDA separates out the process of establishing relationships from the process of creating an authorized access point for the work. Future displays may be able to make use of that distinction and the information in RDA records to prioritize certain elements, such as the designator artist, to suit the needs of users more precisely. Thomas Brenndorfer Guelph Public Library
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
-Original Message- What $e term would be used after a 111? We do many law symposia. author It is considered the creator of the work, just like a person may be. So the correct relator term is author. --- There is also this from RDA I.1: If the element used to record the relationship (e.g., creator) is considered sufficient for the purposes of the agency creating the data, do not use a relationship designator to indicate the specific nature of the relationship. -- John Hostage Authorities and Database Integrity Librarian Langdell Hall Harvard Law School Library Cambridge, MA 02138 host...@law.harvard.edu +(1)(617) 495-3974 (voice) +(1)(617) 496-4409 (fax) http://www.law.harvard.edu/library/
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
-Original Message- What $e term would be used after a 111? We do many law symposia. author It is considered the creator of the work, just like a person may be. So the correct relator term is author. Forgive me if I am mistaken, but $e is not used for relators in 111 or 711. Christopher D. Cook NOAA Central Library
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
$j is used in 111 and 711 for the relator code ($e is used for subordinate unit). Thomas Brenndorfer Guelph Public Library From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Christopher D. Cook Sent: November 10, 2011 10:44 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement -Original Message- What $e term would be used after a 111? We do many law symposia. author It is considered the creator of the work, just like a person may be. So the correct relator term is author. Forgive me if I am mistaken, but $e is not used for relators in 111 or 711. Christopher D. Cook NOAA Central Library
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Well for 111 and 711 you would encode the relater term in $j. But the relator term/relationship designator certainly can be used with conference access points. 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, 10 Nov 2011, Christopher D. Cook wrote: -Original Message- What $e term would be used after a 111? We do many law symposia. author It is considered the creator of the work, just like a person may be. So the correct relator term is author. Forgive me if I am mistaken, but $e is not used for relators in 111 or 711. Christopher D. Cook NOAA Central Library
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On 08/11/2011 22:15, Jonathan Rochkind wrote: snip Kind of off topic, but curious why you don't think relator codes are the right thing to do. If we're listing 3 or 5 or 10 people or entities 'responsible' for an artistic work, why wouldn't we want to be able to say the nature/role of each entities responsibility? Or, if we do, but relator codes are a poor device for this, why? /snip I answered this in another posting that can be found here http://catalogingmatters.blogspot.com/2011/03/re-question-about-rda-title.html While I have nothing against the relator codes *in theory* I think there are serious practical barriers. Entering the relator codes entails additional work for catalogers and some will not be so simple, but more important, there is the serious problem of legacy data. If catalogers had been adding the relator codes all along, that would be one thing, but the decision was made back then not to add them. We must admit that those records will not be updated. Therefore, when looking at the situation from the *patron's point of view*, they will still--always--have to check and recheck every single citation generated from a library catalog because there may be editors, compilers and others who must be cited as such. I see this leading to tremendous confusion and anger. Remember, these are the same people who are not supposed to be able to understand abbreviations such as p. and et al. (except in citations, of course!). I don't think it is wise to promise more than we can deliver. -- James Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On 08/11/2011 22:21, J. McRee Elrod wrote: snip See Chicago Manual of Style 14th ed. 16.35-38. Up to three authors may be given, but only the first is given in inverted order. Sounds like a main entry to me. One has to choose one to invert. Beyond three, only the first is given. (Entry under first of more than three is closer to RDA than AACR2, but like AACR2 in substituting et al. for additional authors.) Am I the only one old enough to remember more than one author at the top of the unit card? But *one* was first. /snip Well, I beg to differ since I don't see that mere inversion of the name that happens to be first on an item to be the equivalent to the selection of a main entry. Everyone on this list is fully aware that the rules for a single main entry are terribly complex. The same thing happens when you have four, five, or more names. Certainly, *in a bibliographic citation* a single one of all the authors has to come first, but not in a computerized catalog where displays are (or can be) much more fluid. Articles can get wild, e.g. http://www.sciencemag.org/content/291/5507/1304.short. Who wants to trace all of them?! Yet, in the bibliographic citation entry for this item, it would be the first three to seven authors, with the first one inverted. Who can maintain that the first person here is equivalent to a *single main entry*? In the future, I would predict that monographs (whatever form they become) could very possibly approach this level of complexity. In any case, there is no reason why Johnson should be treated subordinately to Masters, except to maintain our old practice of a single main entry. Many bibliographic databases do just fine without the concept of a single main entry. Look at Amazon with three authors http://www.amazon.com/Masters-Johnson-Sex-Human-Loving/dp/0316501603/ref=sr_1_1?ie=UTF8qid=1320790524sr=8-1. If you look at the cover in the Look Inside (I can't see the t.p.), Masters is first, but in the citation Kolodny is first. In the CIP, Masters retains main entry. Dublin Core also avoids a single main entry. Why continue this practice when there are three equal authors or more? In a card or printed catalog, I freely agree that matters are quite different but in a database, matters are completely different. If we could get rid of those complex rules, cataloging would become simplified a bit and access would remain the same if not improved. Still, I realize that I cannot convince you of this, so we can agree to disagree. Yet, wouldn't it be great to at least allow the possibility of something like this? In ISO2709, allowing for such a possibility would be terribly difficult, but as I tried to show in XML, it is almost child's play. -- James Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Then you make relator terms (or codes, equally) to be excluded from matching and sorting, surely? The MARc mapping systems I'm familiar with (chiefly Horizon) make that not exactly simple, but straightforward -- so long as the person controlling the mapping bothers to listen to people who know what's meant! Hal Cain Melb ourne, Australia hegc...@gmail.com On Tue, 8 Nov 2011 13:48:56 -0800, J. McRee Elrod m...@slc.bc.ca wrote: Jonathan asked: Kind of off topic, but curious why you don't think relator codes are the right thing to do. Whatever Jim's objections, I can tell you why our clients wish them removed: 1) They may create separate hitlists for the same person. 2) If one hitlist, the relation of the person to the first title listed may differ from other titles in the hitlist. 3) Although a greater problem with $i before $a, they may complicate searching. 4) They create problems (see 1 2) for print products such as acquisitions lists and subject bibliographies. 5) They do not include all the complexities expressed in 245/$c. 6) Some of the terms in the RDA list are long and cumbersome, taking up too much display space. 7) They represent a departure from legacy records; patrons will not understand why some entries have them and some don't. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
This is a good example where familiarity with what RDA is actually saying would help sort things out. As Karen Coyle points out, in RDA artists are creators associated with the work: illustrators are contributors associated with the expression. A different expression of a work may have a different illustrator, but it would still be the same work (and therefore, under AACR2 have the same main entry, or under RDA, have the same authorized access point for the work (creator+preferred title of work)). An artist responsible for the artistic content of the work would always form part of the authorized access point for the work. In RDA, what happens first is that a relationship is established-- artist created work-- and then, as a secondary step, an authorized access point is created as a means to identify the work. In RDA, authorized access points (which contain all the baggage of the main entry concept) are but one way of identifying that thing we call the work. In future catalog scenarios, the authorized access point as a tool for identification may not be needed, but the relationship between artist and work would persist. The problem in MARC is that much of this has to be inferred from the layout of elements. Even if the relationship designators are a difficult fit in MARC cataloging, they do offer a list and categorization of the types of choices made in assigning responsibility in catalog records. As in the case of the artist vs illustrator, the distinction between a creator of a work and an illustrator of an expression is presented in much more formal and precise way in RDA. It is that precision (which carries forward the same amount of intellectual work in traditional cataloging-- it's not really more work) that makes the RDA element set more amenable to modern encoding and data management methods. Thomas Brenndorfer Guelph Public Library From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle [li...@kcoyle.net] Sent: November-09-11 12:54 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Quoting J. McRee Elrod m...@slc.bc.ca: Karen Coyle said: As for creators as main entries, to me, indicating the role of creators and agents of all types allows you to make sensible choices on output rather than having the catalog make one decision for all situations. It's just a matter of giving more weight to, say, an author over an illustrator ... Hang on there. All our art libraries want exhibition catalogues with main entry under artist. Usually the illustrations are more of the content than the text, so AACR2 would agree. But there is a grey area of divergence between rule and preference. That role is designated as artist not illustrator. And in RDA artist is the creator of the Work, illustrator is related to the Expression. RDA definition of illustrator: A person, family, or corporate body contributing to an expression of a work by supplementing the primary content with drawings, diagrams, photographs, etc. If we define our roles carefully, one can make choices based on context and user preference. If we define them poorly, we lose that choice. Someone may do a catalog of illustrators, and want those to be primary for that purpose. Cataloguer judgement is still required. The cataloger needs to determine if a named person is an artist or an illustrator, but cannot determine which is of primary interest to any given user. That's what proper identification is about -- it's not about taking away the user's ability to make choices. And, yes, there will always be grey areas, which is where cataloger judgment comes in. But if we focus on the grey areas we will be missing a lot of slam-dunks. (I suppose that's a mixed metaphor.) kc __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__ -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
I just don't understand why the creators of RDA feel that it's necessary to make original catalogers do *more* instead of less when nearly all of us are supposed to get more done with fewer catalogers. Possibly because many of the creators of RDA don't actually do a lot of filling out of cataloging records. To many, what we do when we populate records is just typing. Their focus is more on the use of the records and other aspects of what might be characterized as the intellectual part of the work. Unfortunately, in many cases, local administrators share this view, so adding tasks that may be mischaracterized as detail work doesn't enter into thoughts and requirements as to output. Mike Tribby Senior Cataloger Quality Books Inc. The Best of America's Independent Presses mailto:mike.tri...@quality-books.com -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Billie Hackney Sent: Wednesday, November 09, 2011 9:56 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement But it *is* more work. Adding relator terms took a lot of extra time while I was doing original cataloging in RDA. I know we've been through the argument a number of times before, but I just don't understand why the creators of RDA feel that it's necessary to make original catalogers do *more* instead of less when nearly all of us are supposed to get more done with fewer catalogers. Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca 11/9/2011 7:49 AM It is that precision (which carries forward the same amount of intellectual work in traditional cataloging-- it's not really more work) that makes the RDA element set more amenable to modern encoding and data management methods. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.454 / Virus Database: 271.1.1/4005 - Release Date: 11/08/11 19:34:00
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Quoting Billie Hackney bhack...@getty.edu: But it *is* more work. Adding relator terms took a lot of extra time while I was doing original cataloging in RDA. I know we've been through the argument a number of times before, but I just don't understand why the creators of RDA feel that it's necessary to make original catalogers do *more* instead of less when nearly all of us are supposed to get more done with fewer catalogers. I can't imagine how calling someone artist can be more work. It *is* more work if you have to look up a role code in order to put it into a MARC subfield, but it's only *different* work if you have: artist: [person name] illustrator: [person name] composer: [person name] conductor: [person name] rather than 100 or 700, which only tells that you're coding a name for a person, and then requires you to qualify it with a less-than-intuitive code. It must be a rare piece that doesn't tell you what role a person plays. That piece probably takes as much to catalog today, because you have to determine if the named person is worth including in the record. If the role is right there before you, using it isn't more work if we finally get beyond MARC coding and stupid input interfaces that make people look up codes. kc p.s. We really need to mock up a couple of potential new input views so that people can see beyond MARC Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca 11/9/2011 7:49 AM It is that precision (which carries forward the same amount of intellectual work in traditional cataloging-- it's not really more work) that makes the RDA element set more amenable to modern encoding and data management methods. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
If we finally get beyond MARC coding and stupid input interfaces that make people look up codes. Sounds great. How do we get beyond those stupid input interfaces? And an observation: sometimes stupid is, if not solely in the eye of the beholder, at least subject to differing perceptions or degrees of stupidity. Mike Tribby Senior Cataloger Quality Books Inc. The Best of America's Independent Presses mailto:mike.tri...@quality-books.com -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: Wednesday, November 09, 2011 10:34 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Quoting Billie Hackney bhack...@getty.edu: But it *is* more work. Adding relator terms took a lot of extra time while I was doing original cataloging in RDA. I know we've been through the argument a number of times before, but I just don't understand why the creators of RDA feel that it's necessary to make original catalogers do *more* instead of less when nearly all of us are supposed to get more done with fewer catalogers. I can't imagine how calling someone artist can be more work. It *is* more work if you have to look up a role code in order to put it into a MARC subfield, but it's only *different* work if you have: artist: [person name] illustrator: [person name] composer: [person name] conductor: [person name] rather than 100 or 700, which only tells that you're coding a name for a person, and then requires you to qualify it with a less-than-intuitive code. It must be a rare piece that doesn't tell you what role a person plays. That piece probably takes as much to catalog today, because you have to determine if the named person is worth including in the record. If the role is right there before you, using it isn't more work if we finally get beyond MARC coding and stupid input interfaces that make people look up codes. kc p.s. We really need to mock up a couple of potential new input views so that people can see beyond MARC Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca 11/9/2011 7:49 AM It is that precision (which carries forward the same amount of intellectual work in traditional cataloging-- it's not really more work) that makes the RDA element set more amenable to modern encoding and data management methods. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.454 / Virus Database: 271.1.1/4005 - Release Date: 11/08/11 19:34:00
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Hi, Karen: I didn't realize I was mistaken about the amount of work I do for original cataloging of materials about art, where there are curators, editors and essayists, galleries that are host institutions as well as publishers, artists who also wrote some or all of the text, and all this often without a title page and in a foreign language. Thank you for enlightening me. Billie Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu Karen Coyle li...@kcoyle.net 11/9/2011 8:33 AM Quoting Billie Hackney bhack...@getty.edu: But it *is* more work. Adding relator terms took a lot of extra time while I was doing original cataloging in RDA. I know we've been through the argument a number of times before, but I just don't understand why the creators of RDA feel that it's necessary to make original catalogers do *more* instead of less when nearly all of us are supposed to get more done with fewer catalogers. I can't imagine how calling someone artist can be more work. It *is* more work if you have to look up a role code in order to put it into a MARC subfield, but it's only *different* work if you have: artist: [person name] illustrator: [person name] composer: [person name] conductor: [person name] rather than 100 or 700, which only tells that you're coding a name for a person, and then requires you to qualify it with a less-than-intuitive code. It must be a rare piece that doesn't tell you what role a person plays. That piece probably takes as much to catalog today, because you have to determine if the named person is worth including in the record. If the role is right there before you, using it isn't more work if we finally get beyond MARC coding and stupid input interfaces that make people look up codes. kc p.s. We really need to mock up a couple of potential new input views so that people can see beyond MARC Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca 11/9/2011 7:49 AM It is that precision (which carries forward the same amount of intellectual work in traditional cataloging-- it's not really more work) that makes the RDA element set more amenable to modern encoding and data management methods. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Jim said: Well, I beg to differ since I don't see that mere inversion of the name that happens to be first on an item to be the equivalent to the selection of a main entry. That's where it files in a single entry list. How more main can it get? Certainly, *in a bibliographic citation* a single one of all the authors has to come first, but not in a computerized catalog where displays are (or can be) much more fluid. Not only must one be first for citations, but also for subject and added entries. Yet, in the bibliographic citation entry for this item, it would be the first three to seven authors, with the first one inverted. Who can maintain that the first person here is equivalent to a *single main entry*? I can. It doesn't matter whether the additional two (Chicago Manual) or six names are before or after the title. That is simply a matter of display. The listing, citation, or entry is under the inverted author. In any case, there is no reason why Johnson should be treated subordinately to Masters ... except to assign a Cutter, create a single entry listing, citation, or subject and added entries. If Karen's idea of designating one as more important to come first (as UTLAS once did with 6XX), I don't see how one 100 being prime is superior to 100 and 700s. What is gained? Dublin Core also avoids a single main entry. Which means we can crosswalk from MARC to DC very cheaply for clients, but going back is impossible. There are other formats we supply to clients by crosswalk for which the same is true. We should not sacrifice granularity in the master record without very careful consideration. Why continue this practice when there are three equal authors or more? To repeat yet again, in order to Cutter, print acquisition lists, print subject bibliographies, print book catalogues and cards (there are still a few), agree with scholarly citations, create subject and added entries, among other reasons. The absence of a main entry (by any name) creates more work than it saves. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Thomas said: An artist responsible for the artistic content of the work would always form part of the authorized access point for the work. In terms of exhibition catalogues, the artist would be main entry if reproductions exceed text, but he text author (curator) would be main entry if text exceeds reproductions. I assume this is true for RDA as it is for AACR2. Our art library clients will not accept that. From their point of few, the amount of text is irrelevant. Perhaps this is something to be taken up in a special genre manual? I did finally persuade Lucia Rather to instruct LC cataloguers to do a 246 for distinctive subtitle, when the artist's name was title proper, and could be mistaken for a statement of responsibility at head of title. Art librarians are not as well organized as music ones, and less adept at making their needs known. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
I apologize for being testy. It's just that anything that catalogers themselves say about the difficulties they've experiences with RDA seem to be passed over and ignored during all of this theoretical discussion on why RDA is so wonderful. Being told that assigning relator terms is easy when it's not is rather frustrating. Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Quoting Billie Hackney bhack...@getty.edu: I apologize for being testy. Accepted. We all get frustrated. It's just that anything that catalogers themselves say about the difficulties they've experiences with RDA seem to be passed over and ignored during all of this theoretical discussion on why RDA is so wonderful. Being told that assigning relator terms is easy when it's not is rather frustrating. Assigning relator terms in MARC is not easy. That's the point. But the intellectual work of determining the role is, I believe, the same in AACR2 and RDA. So what it comes down to is how hard it is to convey that in the record. I think the MARC coding of this is awkward and interfaces don't make it easier. I doubt if any cataloger includes a name in a record without some idea of the role the person plays. However, if there is a need to include miscellaneous persons, there is no reason why such a relationship should not be allowed (that's up to the JSC). Note, however, that you will still, as Thomas B has stated, be using the FRBR entities that require you to separate out work, expression and manifestation roles, so some thinking about what the role is becomes (a perhaps painful) part of the process. I think that MARC is getting in the way of our ability to think about this different. kc Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
It strikes me that perhaps two slightly different questions of work required by relators are being conflated in this discussion... which may why it is generating more heat than light. One is the work of encoding relators, the other the work of determining how contributors are related to works, which (pace Coyle) is not always easy to do unequivocally-particularly if we are talking about cataloging all materials and not just recently-published, textual monographs. Cataloger time invested in the encoding of relators can likely be minimized by better interfaces and encoding schemes; whereas I cannot see how cataloger time invested in determining what kind of contributor a given entity is going to be reduced through any improvements to encoding schemas or interfaces. In other words, the question, or at least one question would be: is, or should relationship designation be a core RDA element? What are the tradeoffs between having consistent, rich metadata, and making sure catalogers are investing their time effectively? I did not participate in the RDA test, but from my reading of RDA chapter 18 and the LC RDA testing documents, it seems like it isn't. (But I could be wrong-I'm far from an RDA expert.) --b Benjamin Abrahamse Cataloging Coordinator Acquisitions, Metadata and Enterprise Systems MIT Libraries 617-253-7137 From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@listserv.lac-bac.gc.ca] On Behalf Of Billie Hackney Sent: Wednesday, November 09, 2011 11:50 AM To: RDA-L@listserv.lac-bac.gc.ca Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Hi, Karen: I didn't realize I was mistaken about the amount of work I do for original cataloging of materials about art, where there are curators, editors and essayists, galleries that are host institutions as well as publishers, artists who also wrote some or all of the text, and all this often without a title page and in a foreign language. Thank you for enlightening me. Billie Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu Karen Coyle li...@kcoyle.net 11/9/2011 8:33 AM Quoting Billie Hackney bhack...@getty.edu: But it *is* more work. Adding relator terms took a lot of extra time while I was doing original cataloging in RDA. I know we've been through the argument a number of times before, but I just don't understand why the creators of RDA feel that it's necessary to make original catalogers do *more* instead of less when nearly all of us are supposed to get more done with fewer catalogers. I can't imagine how calling someone artist can be more work. It *is* more work if you have to look up a role code in order to put it into a MARC subfield, but it's only *different* work if you have: artist: [person name] illustrator: [person name] composer: [person name] conductor: [person name] rather than 100 or 700, which only tells that you're coding a name for a person, and then requires you to qualify it with a less-than-intuitive code. It must be a rare piece that doesn't tell you what role a person plays. That piece probably takes as much to catalog today, because you have to determine if the named person is worth including in the record. If the role is right there before you, using it isn't more work if we finally get beyond MARC coding and stupid input interfaces that make people look up codes. kc p.s. We really need to mock up a couple of potential new input views so that people can see beyond MARC Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca 11/9/2011 7:49 AM It is that precision (which carries forward the same amount of intellectual work in traditional cataloging-- it's not really more work) that makes the RDA element set more amenable to modern encoding and data management methods. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Billie, I think part of Karen's point is that the intellectual analysis and decision-making is mostly the same whether you are determining which name to put in the 1XX and which in the 7XXs or assigning relationship designators. Compared with that intellectual process, the actual keying of the designators is rather modest. I would hope that no one undervalues that intellectual work -- at least they shouldn't. And I would hope that one of the functions of RDA is to provide a more robust set of ways in which you can record the conclusions you draw from that intellectual work and convey the information to the users of your records. John Attig Authority Control Librarian Penn State University jx...@psu.edu On 11/9/2011 12:09 PM, Billie Hackney wrote: I apologize for being testy. It's just that anything that catalogers themselves say about the difficulties they've experiences with RDA seem to be passed over and ignored during all of this theoretical discussion on why RDA is so wonderful. Being told that assigning relator terms is easy when it's not is rather frustrating. Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Karen, The intellectual work of determining the specific role(s) a person or corporate body has in relation to a work/expression/manifestation (RDA) is more difficult/complicated than the intellectual work of determining that a person or corporate body has *a* role in relation to a resource (AACR2). Roles may not be precisely defined. A person or body may have multiple roles. Catalogers using AACR2 are accustomed to applying their judgment to the yes/no question of whether a person or body has a role that calls for an access point-- to define precisely the role or roles that person or body plays requires additional intellectual effort. And, in my experience, especially for corporate bodies, it can be time-consuming to ferret out precisely what the role(s) are. I don't think this increase in intellectual effort is dependent on the use of a particular coding scheme or interface. It is inherent in the work. And yes, the need for specifying roles in RDA does appear to be a result of attempting to catalog in terms of FRBR entities. Sara Sara Shatford Layne Principal Cataloger UCLA Library Cataloging Metadata Center sla...@library.ucla.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: Wednesday, November 09, 2011 9:18 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Quoting Billie Hackney bhack...@getty.edu: I apologize for being testy. Accepted. We all get frustrated. It's just that anything that catalogers themselves say about the difficulties they've experiences with RDA seem to be passed over and ignored during all of this theoretical discussion on why RDA is so wonderful. Being told that assigning relator terms is easy when it's not is rather frustrating. Assigning relator terms in MARC is not easy. That's the point. But the intellectual work of determining the role is, I believe, the same in AACR2 and RDA. So what it comes down to is how hard it is to convey that in the record. I think the MARC coding of this is awkward and interfaces don't make it easier. I doubt if any cataloger includes a name in a record without some idea of the role the person plays. However, if there is a need to include miscellaneous persons, there is no reason why such a relationship should not be allowed (that's up to the JSC). Note, however, that you will still, as Thomas B has stated, be using the FRBR entities that require you to separate out work, expression and manifestation roles, so some thinking about what the role is becomes (a perhaps painful) part of the process. I think that MARC is getting in the way of our ability to think about this different. kc Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Benjamin said: It strikes me that perhaps two slightly different questions of work required by relators are being conflated in this discussion... One is the work of encoding relators, the other the work of determining how contributors are related to works ... There is also the situation in which one person or group has more than one relationship to the work, e.g., composer and performer, author and illustrator, director and actor, writer and producer, etc. Is the name given two, three, or more times with different relators; or is the relator subfield to be repeating, in this proposed new coding scheme? If repeating, in what order? __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
I've been assigning relator terms for years under AACR2 in my cataloging so I guess I'm just used to it-yes, it takes a little extra time, but I think the benefits to our users of spelling out the relationship of the person/corporate body/family to the resource far outweigh the extra thought and entry time. I personally (and yes, I am a practicing cataloger) find the extra time and effort to be negligible. N.B. I'm glad the relationship indicators are getting renewed emphasis under RDA, but this isn't a new issue with RDA. Relationship indicators were allowed under AACR2 and previous codes (see AACR2 21.0D) and have been widely and fairly consistently used during all that time in many cataloging communities, including the rare materials cataloging community, in spite of LC's decision at implementation of AACR2 not to use them in most cases. Bob Robert L. Maxwell Special Collections and Ancient Languages Catalog Librarian Genre/Form Authorities Librarian 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued--Eliza R. Snow, 1842. From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Billie Hackney Sent: Wednesday, November 09, 2011 10:53 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Determining that there is a contributor and providing a fast access point is much easier and quicker than figuring out all of the ways that a person or organization contributed, looking up the terms in the poorly presented and designed list in the RDA toolkit, and then typing them all in. When we were doing original cataloging in RDA here, it was definitely the element of the work that took up most of the group's time -- it wasn't just me. Perhaps it is just a difficulty associated with original cataloging of the type of materials we do here, and all of the other testers didn't experience the same difficulty that we did? Everyone else found assigning multiple relator terms easy? Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edumailto:bhack...@getty.edu John Attig jx...@psu.edumailto:jx...@psu.edu 11/9/2011 9:42 AM Billie, I think part of Karen's point is that the intellectual analysis and decision-making is mostly the same whether you are determining which name to put in the 1XX and which in the 7XXs or assigning relationship designators. Compared with that intellectual process, the actual keying of the designators is rather modest. I would hope that no one undervalues that intellectual work -- at least they shouldn't. And I would hope that one of the functions of RDA is to provide a more robust set of ways in which you can record the conclusions you draw from that intellectual work and convey the information to the users of your records. John Attig Authority Control Librarian Penn State University jx...@psu.edumailto:jx...@psu.edu On 11/9/2011 12:09 PM, Billie Hackney wrote: I apologize for being testy. It's just that anything that catalogers themselves say about the difficulties they've experiences with RDA seem to be passed over and ignored during all of this theoretical discussion on why RDA is so wonderful. Being told that assigning relator terms is easy when it's not is rather frustrating. Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edumailto:bhack...@getty.edu
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
I've presided over the creation of more than 2400 RDA records for sheet maps over the last 13 months at the University of Chicago Library. Relationship designators have given us more problems than any other aspect of RDA, and (like the book catalogers here) we stopped using them a couple of months after the test period ended. LC, I notice, did not use them even during the test period. The problems are: [1] As others have pointed out, it's often just not very clear what the creators did. You've got to pretend to know more than you do. This is probably never a very good idea in cataloging work. [2] The official relationship designators do not fit the actual functions of map production very well. There is a particular problem with corporate creators, who are often publishers. But publisher is not one of the official relationship designators, and issuing body doesn't really seem like the right term for corporate publishers. [3] It's common in cartographic materials for the source of the data to be a different person or body from the mapmaker. We pushed the envelope a bit and started using source of data as a relationship designator. I completely agree with those who find the relationship designators so problematic as to doubt their value. Chris Winters Christopher Winters Bibliographer for Anthropology, Geography, and Maps University of Chiago Library From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Robert Maxwell [robert_maxw...@byu.edu] Sent: Wednesday, November 09, 2011 12:03 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement I’ve been assigning relator terms for years under AACR2 in my cataloging so I guess I’m just used to it—yes, it takes a little extra time, but I think the benefits to our users of spelling out the relationship of the person/corporate body/family to the resource far outweigh the extra thought and entry time. I personally (and yes, I am a practicing cataloger) find the extra time and effort to be negligible. N.B. I’m glad the relationship indicators are getting renewed emphasis under RDA, but this isn’t a new issue with RDA. Relationship indicators were allowed under AACR2 and previous codes (see AACR2 21.0D) and have been widely and fairly consistently used during all that time in many cataloging communities, including the rare materials cataloging community, in spite of LC’s decision at implementation of AACR2 not to use them in most cases. Bob Robert L. Maxwell Special Collections and Ancient Languages Catalog Librarian Genre/Form Authorities Librarian 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued--Eliza R. Snow, 1842. From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Billie Hackney Sent: Wednesday, November 09, 2011 10:53 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Determining that there is a contributor and providing a fast access point is much easier and quicker than figuring out all of the ways that a person or organization contributed, looking up the terms in the poorly presented and designed list in the RDA toolkit, and then typing them all in. When we were doing original cataloging in RDA here, it was definitely the element of the work that took up most of the group's time -- it wasn't just me. Perhaps it is just a difficulty associated with original cataloging of the type of materials we do here, and all of the other testers didn't experience the same difficulty that we did? Everyone else found assigning multiple relator terms easy? Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edumailto:bhack...@getty.edu John Attig jx...@psu.edumailto:jx...@psu.edu 11/9/2011 9:42 AM Billie, I think part of Karen's point is that the intellectual analysis and decision-making is mostly the same whether you are determining which name to put in the 1XX and which in the 7XXs or assigning relationship designators. Compared with that intellectual process, the actual keying of the designators is rather modest. I would hope that no one undervalues that intellectual work -- at least they shouldn't. And I would hope that one of the functions of RDA is to provide a more robust set of ways in which you can record the conclusions you draw from that intellectual work and convey the information to the users of your records. John Attig Authority Control Librarian Penn State University jx...@psu.edumailto:jx...@psu.edu On 11/9/2011
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
I have mixed feelings about this discussion. We are heavy users of relator terms (we don't use the codes). This is partially because many of the items we catalogue, such as art works andmanuscripts, are unpublished and do not have statements of responsibility.If we didn't add relator terms to the headings, users would be reduced to scouring through the many notes on our records to figure out what is the relationship between the item and all the names that appear under the"Associated Names" label.I'm not sure that adding relator terms for items where the responsibilities are clearly spelled out in a statement of responsibility (e.g. by X; edited by Y; compiled by Z), or do not differ all that much except in degree (editor versus compiler) would be as useful. Adding relator termsdoes require additional time, both for the cataloger and for those in charge of cataloging (new catalogers have to be trained in the use of relator terms,policies have to be set on the sources we use andhow specific to be;if terms do not exist, we have to submit them to the relevant source.) We do this as an act of faith that someday, somehow, systems will be able to handle this data in a meaningful way, and use it in ways that will promote discovery and access. Some of the complications weencounter when supplying relator terms:Our system (Voyager 8) doesn't have a good way of handling multiple roles, which occur very frequently in our collections:Composer and librettist Printer and publisherAuthor and illustrator (or artist) Author, annotator,former owner, and donor Binder and former owner (well, you get the picture) Degree of specificity: We have a large graphic arts collection, sowe prefer more specific terms, such as "painter/engraver/illustrator/illuminator/etc." as opposed to the generic term "artist". We would actually use etcher, lithographer or woodcutter if the item described warrants it. We probably wouldn't care as much about differentiating between author/editor/compiler/prefacer (?) of a textual work. But in a world of shared cataloging andpooled records, shouldn't we all be operating at the same level of specificity? Coding of source of relator term:It is currently not possible in MARC to indicate the source of a relator term. We use relator terms from the MARC list, from AAT, from the RBMS vocabularies and from "local" sources. It would be nice to be able to specify the source. All these difficulties notwithstanding, we are committed to continue applying these terms. RDA's focus on relator terms is welcomed by us, if it leads to systems being able to utilize them better. But I'm not sure that relator terms will be as useful for other collections, even after the systems are in place. Liz O'Keefe Elizabeth O'KeefeDirector of Collection Information SystemsThe Morgan Library Museum225 Madison AvenueNew York, NY 10016-3405TEL: 212 590-0380FAX: 212-768-5680NET: eoke...@themorgan.org Visit CORSAIR, the Library’s comprehensive collections catalog, now onthe web athttp://corsair.themorgan.org Elizabeth O'Keefe 11/9/2011 12:27 PM Billie Hackney bhack...@getty.edu 11/9/2011 12:53 PM Determining thatthere is a contributorand providing a fastaccess point is much easier and quickerthanfiguring out all of the ways thataperson or organizationcontributed, looking up the terms in thepoorly presented and designed list in the RDA toolkit, and then typing them all in. When we were doing original cataloging in RDA here, it was definitely the element of the work that took up most ofthe group'stime -- it wasn't just me. Perhaps it is just a difficulty associated with original cataloging of the type of materials we do here, and all of the other testersdidn't experience the same difficulty that we did? Everyone else found assigning multiple relator termseasy? Billie HackneySenior Monograph CatalogerGetty Research Institute1200 Getty Center Drive, Suite 1100Los Angeles, CA 90049-1688(310) 440-7616bhack...@getty.edu John Attig jx...@psu.edu 11/9/2011 9:42 AM Billie, I think part of Karen's point is that the intellectual analysis and decision-making is mostly the same whether you are determining which name to put in the 1XX and which in the 7XXs or assigning relationship designators. Compared with that intellectual process, the actual keying of the designators is rather modest.I would hope that no one undervalues that intellectual work -- at least they shouldn't. And I would hope that one of the functions of RDA is to provide a more robust set of ways in which you can record the conclusions you draw from that intellectual work and convey the information to the users of your records. John Attig Authority Control Librarian Penn State University jx...@psu.eduOn 11/9/2011 12:09 PM, Billie Hackney wrote: I apologize for being testy. It's just thatanything thatcatalogers themselves say about the difficulties they've experiences with RDAseem to bepassed over and ignored during all of this
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
I almost changed the subject line, but this still *seems* to concern the bibliographic framework, or perhaps not. Of course, relator codes require more work than not assigning them. That is a simple fact that no one can dispute. The question is: are they worth it? This is not the sort of question that can be answered with a simple Yes, I think so or No, I don't think so. Different aspects must be considered first. The first fact that must be accepted is that the old records will not be upgraded and this has consequences for everything else. First, will the relator codes be indexed for searching, i.e. will people be able to limit their searches to editors or compilers or contestee or process contact? I certainly hope not since the results will be unpredictable. Therefore, if the codes are not there for searching, what are they there for? There seems to be only one answer: for display. Another aspect must be to see matters from the public's viewpoint. That viewpoint certainly should never be ignored. Since the old records will never be upgraded to add relator codes, they will see records with relator codes and records without relator codes all mixed together in every single search they do. What will be the correct way for a non-expert to approach them? Therefore, they will see, in every search, in one record, made post-RDA, there will be a relator code for a specific role, but in another record, pre-RDA, there will not be a relator code for exactly that same role. What then, is the purpose of the relator code? How can we keep them from being confused? How should people approach our records then, and how do we inform people what they should and shouldn't believe concerning the relator codes? What are the best ways to use them and what are poor ways? And remember, these will be exactly the same people who can't be expected to know what p. or ill. mean! Naturally, another important aspect of the matter is the amount of work and the effects on productivity. When an experienced cataloger says that it has a noticeable effect on productivity, that statement should simply be accepted. It is in the nature of things that there will be easy items in English, just as we still get new editions of The old man and the sea and with very little work, we can count it as an original catalog record in our statistics. But there are other materials that are not in English, strange items with unclear roles that demand time. These kinds of strange roles can only get stranger with online materials. It seems that there will be serious consequences both to catalogers and the public. This is normal when you decide to add new parts to the basic functions to the catalog. The only way to answer these considerations is to do at least some amount of research and find out if the consequences are worth the effort. Otherwise, we dive into the effort armed only with suppositions based on limited knowledge and personal beliefs. Of course, in a regular business environment this sort of research would have been done at a very early stage, not at the very end. -- James Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Quoting Layne, Sara sla...@library.ucla.edu: Roles may not be precisely defined. A person or body may have multiple roles. Catalogers using AACR2 are accustomed to applying their judgment to the yes/no question of whether a person or body has a role that calls for an access point-- to define precisely the role or roles that person or body plays requires additional intellectual effort. If we truly move into an entity-relationship model for our data, the option of adding access points without the relationship will go away. The relationship is what connects the Group2 entity with the Group1 entity. There will be no other way to code it. (I'm thinking of doing a short pen-cast on this point since it is important; will post here if I do.) Essentially, the E-R model requires you to say: [this Work] [has author] [Person123] [this Expression] [has illustrator] [Person789] It's not a 100 field with a role code added to it; the thing we think of as the role code *is* the actual connector, and the statement cannot be made without it. This isn't rocket science, and it's a fairly common practice in metadata, where the data elements tell you what the role is, e.g. for resourceABC: author = Person123 editor = Person789 publisher = Corp876 MARC doesn't do this because MARC does not use active voice data elements. Instead it is a markup of a textual format and its data elements reference the placement of the text over the meaning (although in some cases they coincide). Main entry is a relationship between a string and a record, it is not a statement of how that person relates to the work being described. That said, there is no reason why RDA cannot have a set of generic roles when determining the exact role is not worth while. Because of its adherence to FRBR, that would need to be a small set of roles, such as: Work:Creator Expression:Contributor Manifestation:Producer [or whatever JSC decides] so you could say: [this Work] [has creator] [Person123] and you haven't said if the creator is a writer, a composer or an artist. That is similar to what we have today in MARC, where a 1xx without a role requires the user to fill in the blank. We don't tell users that Beethoven is a composer, or that John Updike is a writer. Again, if our future bibliographic framework is an E-R model, roles as we think of them today are not optional. In MARC they are, but MARC is not an E-R model. If this doesn't work for catalogers, then one has to go back and re-think everything from FRBR through RDA. kc And, in my experience, especially for corporate bodies, it can be time-consuming to ferret out precisely what the role(s) are. I don't think this increase in intellectual effort is dependent on the use of a particular coding scheme or interface. It is inherent in the work. And yes, the need for specifying roles in RDA does appear to be a result of attempting to catalog in terms of FRBR entities. Sara Sara Shatford Layne Principal Cataloger UCLA Library Cataloging Metadata Center sla...@library.ucla.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: Wednesday, November 09, 2011 9:18 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Quoting Billie Hackney bhack...@getty.edu: I apologize for being testy. Accepted. We all get frustrated. It's just that anything that catalogers themselves say about the difficulties they've experiences with RDA seem to be passed over and ignored during all of this theoretical discussion on why RDA is so wonderful. Being told that assigning relator terms is easy when it's not is rather frustrating. Assigning relator terms in MARC is not easy. That's the point. But the intellectual work of determining the role is, I believe, the same in AACR2 and RDA. So what it comes down to is how hard it is to convey that in the record. I think the MARC coding of this is awkward and interfaces don't make it easier. I doubt if any cataloger includes a name in a record without some idea of the role the person plays. However, if there is a need to include miscellaneous persons, there is no reason why such a relationship should not be allowed (that's up to the JSC). Note, however, that you will still, as Thomas B has stated, be using the FRBR entities that require you to separate out work, expression and manifestation roles, so some thinking about what the role is becomes (a perhaps painful) part of the process. I think that MARC is getting in the way of our ability to think about this different. kc Billie Hackney Senior Monograph Cataloger Getty Research Institute 1200 Getty Center Drive, Suite 1100 Los Angeles, CA 90049-1688 (310) 440-7616 bhack...@getty.edu -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Several comments here: First, the JSC recognizes that the list of official designators is incomplete, and that the ones relevant to cartographic resources are probably inadequate. This was also recognized in the report of the US RDA Test Coordinating Committee. The JSC very much wants proposals for additional designators, and the cartographic resources community is definitely one they would like to hear from. Second, there are some relationships that are part of the RDA element structure that do not have designators. Publisher is one of these. This is an element in RDA and (therefore?) does not have a designator in Appendix I. Because an access point for this element cannot be identified by MARC 21 tagging, I have argued to the JSC that the only way to identify that an access point represents a publisher is to use the MARC 21 relator term publisher in subfield $e. This is certainly valid MARC and I would argue that it is valid RDA. [I have also recommended that these element-level relationships be included as explicit designators in the RDA role element set in the Open Metadata Registry. In the long run, this may be more important that how we fudge this in MARC.] John Attig ALA Representative to the JSC jx...@psu.edu On 11/9/2011 1:49 PM, Christopher Winters wrote: I've presided over the creation of more than 2400 RDA records for sheet maps over the last 13 months at the University of Chicago Library. Relationship designators have given us more problems than any other aspect of RDA, and (like the book catalogers here) we stopped using them a couple of months after the test period ended. LC, I notice, did not use them even during the test period. The problems are: [1] As others have pointed out, it's often just not very clear what the creators did. You've got to pretend to know more than you do. This is probably never a very good idea in cataloging work. [2] The official relationship designators do not fit the actual functions of map production very well. There is a particular problem with corporate creators, who are often publishers. But publisher is not one of the official relationship designators, and issuing body doesn't really seem like the right term for corporate publishers. [3] It's common in cartographic materials for the source of the data to be a different person or body from the mapmaker. We pushed the envelope a bit and started using source of data as a relationship designator. I completely agree with those who find the relationship designators so problematic as to doubt their value. Chris Winters Christopher Winters Bibliographer for Anthropology, Geography, and Maps University of Chiago Library *From:* Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Robert Maxwell [robert_maxw...@byu.edu] *Sent:* Wednesday, November 09, 2011 12:03 PM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement I’ve been assigning relator terms for years under AACR2 in my cataloging so I guess I’m just used to it—yes, it takes a little extra time, but I think the benefits to our users of spelling out the relationship of the person/corporate body/family to the resource far outweigh the extra thought and entry time. I personally (and yes, I am a practicing cataloger) find the extra time and effort to be negligible. N.B. I’m glad the relationship indicators are getting renewed emphasis under RDA, but this isn’t a new issue with RDA. Relationship indicators were allowed under AACR2 and previous codes (see AACR2 21.0D) and have been widely and fairly consistently used during all that time in many cataloging communities, including the rare materials cataloging community, in spite of LC’s decision at implementation of AACR2 not to use them in most cases. Bob Robert L. Maxwell Special Collections and Ancient Languages Catalog Librarian Genre/Form Authorities Librarian 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued--Eliza R. Snow, 1842. *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Billie Hackney *Sent:* Wednesday, November 09, 2011 10:53 AM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Determining that there is a contributor and providing a fast access point is much easier and quicker than figuring out all of the ways that a person or organization contributed, looking up the terms in the poorly presented and designed list in the RDA toolkit, and then typing them all in. When we were doing original cataloging
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Quoting John Attig jx...@psu.edu: On 11/9/2011 2:43 PM, Karen Coyle wrote: If we truly move into an entity-relationship model for our data, . . . You could equally have same if we truly move into a linked-data model for our data. My understanding is that an indispensable piece of any linked data specification is the predicate -- which is the relationship designator turned into a verb. Yes, I think that for this discussion this is true. There are differences, like: E-R doesn't require the use of identifiers, but LD does. FRBR defines an E-R model, which is kind of a precursor to linked data, and at this date, linked data is the direction folks are going in. On the other hand, you don't have to use the most specific relationship designator available. I suspect that many will be satisfied with creator and contributor and avoid being more specific. Because there are well-defined hierarchies, this difference in granularity shouldn't be an obstacle to interoperability. I agree. The RDA definition of contributor is: A person, family, or corporate body contributing to the realization of a work through an expression. Contributors include editors, translators, arrangers of music, performers, etc. (from the registry, not the toolkit text) So use of this term depends entirely on its acceptance as part of the RDA standard, and the development of best practices as we go forward. There are many levels of granularity, such as: 1. Contributor 1.1 Composer (Expression) 1.11 Composer of Music for Silent Film (Expression) 1.11 Composer of Music for Sound Film (Expression) I don't know if RDA gives any advice about moving up and down the granularity tree when assigning roles, but presumably few data producers are expected to provide the lowest level of detail. Note that in the registry[1] the hierarchy of roles is coded although it isn't easily visible (we need a good visualization, to say the least) but every Composer (Expression) is a Contributor, and by inference so are the ones marked 1.11, so it should be correct to use Contributor for all of these. Communities should be able to provide the level of granularity that they find useful, and others can treat the data with less (but not more) granularity if they so wish. kc [1] http://metadataregistry.org/schemaprop/list/schema_id/4.html John -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Quoting John Attig jx...@psu.edu: Second, there are some relationships that are part of the RDA element structure that do not have designators. Publisher is one of these. This is an element in RDA and (therefore?) does not have a designator in Appendix I. I noticed this a while back. I assumed it was intentional because publisher is represented with a transcribed text, not a Group2 entity. you could actually have both, with the RDA Manifestation element being for the transcribed text, and an Expression - to - Group2 relationship if someone wants to treat the publisher as a corporate body (presumably with an authority record). It would be nice to have both options. kc Because an access point for this element cannot be identified by MARC 21 tagging, I have argued to the JSC that the only way to identify that an access point represents a publisher is to use the MARC 21 relator term publisher in subfield $e. This is certainly valid MARC and I would argue that it is valid RDA. [I have also recommended that these element-level relationships be included as explicit designators in the RDA role element set in the Open Metadata Registry. In the long run, this may be more important that how we fudge this in MARC.] John Attig ALA Representative to the JSC jx...@psu.edu On 11/9/2011 1:49 PM, Christopher Winters wrote: I've presided over the creation of more than 2400 RDA records for sheet maps over the last 13 months at the University of Chicago Library. Relationship designators have given us more problems than any other aspect of RDA, and (like the book catalogers here) we stopped using them a couple of months after the test period ended. LC, I notice, did not use them even during the test period. The problems are: [1] As others have pointed out, it's often just not very clear what the creators did. You've got to pretend to know more than you do. This is probably never a very good idea in cataloging work. [2] The official relationship designators do not fit the actual functions of map production very well. There is a particular problem with corporate creators, who are often publishers. But publisher is not one of the official relationship designators, and issuing body doesn't really seem like the right term for corporate publishers. [3] It's common in cartographic materials for the source of the data to be a different person or body from the mapmaker. We pushed the envelope a bit and started using source of data as a relationship designator. I completely agree with those who find the relationship designators so problematic as to doubt their value. Chris Winters Christopher Winters Bibliographer for Anthropology, Geography, and Maps University of Chiago Library *From:* Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Robert Maxwell [robert_maxw...@byu.edu] *Sent:* Wednesday, November 09, 2011 12:03 PM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement I’ve been assigning relator terms for years under AACR2 in my cataloging so I guess I’m just used to it—yes, it takes a little extra time, but I think the benefits to our users of spelling out the relationship of the person/corporate body/family to the resource far outweigh the extra thought and entry time. I personally (and yes, I am a practicing cataloger) find the extra time and effort to be negligible. N.B. I’m glad the relationship indicators are getting renewed emphasis under RDA, but this isn’t a new issue with RDA. Relationship indicators were allowed under AACR2 and previous codes (see AACR2 21.0D) and have been widely and fairly consistently used during all that time in many cataloging communities, including the rare materials cataloging community, in spite of LC’s decision at implementation of AACR2 not to use them in most cases. Bob Robert L. Maxwell Special Collections and Ancient Languages Catalog Librarian Genre/Form Authorities Librarian 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued--Eliza R. Snow, 1842. *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Billie Hackney *Sent:* Wednesday, November 09, 2011 10:53 AM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Determining that there is a contributor and providing a fast access point is much easier and quicker than figuring out all of the ways that a person or organization contributed, looking up the terms in the poorly presented
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On 11/9/2011 3:59 PM, Karen Coyle wrote: Quoting John Attig jx...@psu.edu: Second, there are some relationships that are part of the RDA element structure that do not have designators. Publisher is one of these. This is an element in RDA and (therefore?) does not have a designator in Appendix I. I noticed this a while back. I assumed it was intentional because publisher is represented with a transcribed text, not a Group2 entity. you could actually have both, with the RDA Manifestation element being for the transcribed text, and an Expression - to - Group2 relationship if someone wants to treat the publisher as a corporate body (presumably with an authority record). It would be nice to have both options. Actually, the publisher relationship is an element in Chapter 21, Persons, Families and Corporate Bodies Associated with a Manifestation. Other relationships in that chapter are Producer of an Unpublished Resource, Distributor, Manufacturer. These are relationships which can be recorded as either identifiers or authorized access points; they are quite distinct from the Publisher's Name [etc.] elements in Chapter 2. Although there are cases in which RDA (and FRBR) treats an element as only a descriptive element or only a relationship, in this case, RDA supports both. And I agree that we need both options more generally in RDA. John Attig Authority Control Librarian Penn State University jx...@psu.edu
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Christopher Winters said: I've presided over the creation of more than 2400 RDA records for sheet maps over the last 13 months at the University of Chicago Library. Relationship designators have given us more problems than any other aspect of RDA, and (like the book catalogers here) we stopped using them ... This real life experience very much accords with our internal experiments. We have come up with a simplified relator term list* in one alphabetic order, in case we *have* to use them, but we hope not. Some RDA terms are too long for conventient display. While relator terms are fairly problem free for a simple printed book, simple printed books are a small minority of what SLC catalogues (records for most of those are available from the national cataloguing agencies). We catalogue law reform commission reports for law firm libraries. A report which contains official recommendations of the commission is entered under the commission. A report which is informational only is entered under personal author or title. What would be the relator term(s) used for that 110 and 710? Different or the same? Issuing body for both? Usually the commission is also the publisher. What $e term would be used after a 111? We do many law symposia. It seems to me many theorists lack the practical experience of Billie and Christopher. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__ abridger actor addressee animator appellant appellee architect artist author [bookseller] cartographer [cinematographer] [Use for 'director of photography'] choreographer commentator composer [Also use for all RDA relator phrases beginning 'composer'] conductor court governed [Assign and export as 'court'] compiler [conference - use issuer] dancer dedicatee defendant degree granting institution [Assign and export as 'institution'] [depicted] designer [director] [Usedfor 'film director', 'radio director', 'television director'] director of photography [Assign and export as 'cinematographer'] draftsman enacting jurisdiction [assign and export as 'jurisdiction'] editor engraver etcher film director [Assign and export as 'director'] film producer [Assign and export as 'producer'] filmmaker honouree host host institution [Assign and export as 'host'] illustrator [institution] [Use for 'degree granting institution'] instrumentalist interviewee interviewer inventor [issuer] [Use for 'issuing body'] issuing body [assign and export as 'issuer'] judge [jurisdiction] [Use for 'enacting jurisdiction' and 'jurisdiction governed'] jurisdiction governed [Assign and export as 'jurisdiction] landscape architect [Assign and export as 'landscaper'] [landscaper] ]Use for 'landscape architect] librettist lyricist moderator narrator panelist performer photographer plaintiff praeses printer printmaker [producer] [Use for 'film producer', 'radio producer', 'television producer'] production company programmer [publisher] puppeteer radio director [Assign and export as 'director'] radio producer [Assign and export as 'producer'] respondent screenwriter sculptor singer speaker [sponsor] ]Use for 'sponsoring body'] sponsoring body [Assign and export as 'sponsor'] storyteller teacher television director [Assign and export as 'director'] television producer [Assign and export as 'producer'] transcriber translator [writer - use 'author']
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Reading the discussions about codes for designators and WEMI levels, made me remember for early U.S. court materials the so-called editors or compilers were considered creators, not contributors. Not all definitions we think are simple, are so. An original cataloger has to know a subject to know correct proper Group status for an access point or designation of a true role. Is there a discovery system or catalog now that can display as facets the various roles in works and expressions that a person/entity may have? If I did an entity search, something like John D. Smythe: Creator (65), Contributor (68) or John D. Smythe: Creator: author (65), painter (45), Contributor: compiler (43), illustrator (21), composer (4) would display? Pam Deemer Assistant Law Librarian, Acquisitions and Cataloging Services Emory University Hugh F. MacMillan Law Library 1301 Clifton Road Atlanta, GA 30322-2780 (404)-727-0850 lib...@emory.edu This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments).
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
What $e term would be used after a 111? We do many law symposia. author It is considered the creator of the work, just like a person may be. So the correct relator term is author. From RDA Appendix I: author A person, family, or corporate body responsible for creating a work that is primarily textual in content, regardless of media type (e.g., printed text, spoken word, electronic text, tactile text) or genre (e.g., poems, novels, screenplays, blogs). Use also for persons, etc., creating a new work by paraphrasing, rewriting, or adapting works by another creator such that the modification has substantially changed the nature and content of the original or changed the medium of expression. ** * 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 * **
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Some additional observations on relationship designators... IMDb.com uses job type as a way of defining relationships between persons and content. So for Clint Eastwood, his filmography is organized by his relationship to films: http://www.imdb.com/name/nm142/ There is a catchall job type miscellaneous crew, but even the listings under that job type have added details about his role. There is a two-tier structure in RDA for relationships-- relationship elements and more specific relationship designators (which in turn can be further fine-tuned). For a Work, there are two elements: Creator, and, Other Person (Family, Corporate Body) Associated with a Work (including religious and legal works). For an Expression, there is one element: Contributor. For an Manifestation, there are five elements: Producer of an Unpublished Resource, Publisher, Distributor, Manufacturer, Other Person (Family, Corporate Body) Associated with a Manifestation For an Item, there are three elements: Owner, Custodian, Other Person (Family, Corporate Body) Associated with an Item Separating out relationships to the Work from the other entities overlaps with decisions about the main entry, or, in RDA, decision about authorized or variant access points for the work. The intellectual work in making those decisions is largely the same. The degree of granularity for the nature of relationship should be up to the community involved. I would think that the respective domain expertises would find efficient and accurate designators that serve endusers effectively, to whatever level of granularity is appropriate. Depending on the resource, I do find relator codes can result in a better distribution of effort-- a record for a movie with 25 added entries is easier to understand when the relator code is connected to the name. The alternative of scanning piles of text in notes to understand the relationship is less efficient, depending on how the record is used and who is using it. The RDA example records at http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_(Bibliographic)_revised.pdf indicate how different encoding methods can handle relationships. In the MARC encoding methods on page 7, multiple roles to different Group 1 entities can be concatenated: 100 1# $a Porter, Kalan, $e composer, $e singer 700 1# $a Sokyrka, Theresa, $e singer In an RDA element set version, the relationships can be spelled out differently, and offer greater clarity as to the nature of the roles and why one name can be a main entry and the other cannot: Work: Work manifested: Porter, Kalan. 219 days. Creator: Porter, Kalan Relationship designator: composer Expression: Contributor: Porter, Kalan Relationship designator: singer Contributor: Sokyrka, Theresa Relationship designator: singer The degree to which encoding is made efficient is up to the encoding scheme and the interface. As an example, LibraryThing uses relatively efficient drop-down menus to help people enter designators between related works: http://www.librarything.com/wiki/index.php/HelpThing:Work/Relationships#Relationships_and_Examples Thomas Brenndorfer Guelph Public Library
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Please take me off the list. I am not involved in this area of work anymore. Regards Nirmala Nirmala Gounder ALIANZA, RLIANZA| Team Leader Technical Services | Bay of Plenty Polytechnic Library | Private Bag 12001, Tauranga 3143 | P: 07 544 0190 ext 6768 | F: 07 544 2386 | nirmala.goun...@boppoly.ac.nz | www.boppoly.ac.nz -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Adam L. Schiff Sent: Thursday, 10 November 2011 11:37 a.m. To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement What $e term would be used after a 111? We do many law symposia. author It is considered the creator of the work, just like a person may be. So the correct relator term is author. From RDA Appendix I: author A person, family, or corporate body responsible for creating a work that is primarily textual in content, regardless of media type (e.g., printed text, spoken word, electronic text, tactile text) or genre (e.g., poems, novels, screenplays, blogs). Use also for persons, etc., creating a new work by paraphrasing, rewriting, or adapting works by another creator such that the modification has substantially changed the nature and content of the original or changed the medium of expression. ** * 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 * ** Private and Confidential This electronic mail message and any files transmitted with it are intended solely for the use of the addressee(s) and may contain information that is confidential or privileged. If you receive this message and you are not the intended addressee (or responsible for the delivery of the message to the intended addressee) please notify the author immediately, disregard the contents of this message and delete the message from your system. Please note that we accept no responsibility for viruses or any other malicious code in this email or any included attachments.
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Adam answered: What $e term would be used after a 111? We do many law symposia. author I remember a French cataloguer at IFLA snippily telling me that corporate bodies do not write books, people do. The papers in symposia are written by individual lawyers, and delivered at the symposia. The symposia has no hand in their creation. The record for a law commission report written by one person with no official recommendations, and that person as 100, would have 710 $eauthor? A law commission report with official recommendations written by a task force, entered under the commission, would have 110 $eauthor? The commision had no hand in their creation; they just adopted them. The relator term author in all three cases would not be true. I think we will use issuer (short for issuingn body) if we must use relator terms. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On Wed, 9 Nov 2011, J. McRee Elrod wrote: Adam answered: What $e term would be used after a 111? We do many law symposia. author I remember a French cataloguer at IFLA snippily telling me that corporate bodies do not write books, people do. The papers in symposia are written by individual lawyers, and delivered at the symposia. The symposia has no hand in their creation. True, as far as it goes. But in both AACR2 and RDA symposia can be main entries/creators of works. Symposia, like other corporate bodies, have long been considered capable of authorship by our rules. RDA 19.2.1.1.1 Corporate Bodies Considered to Be Creators Corporate bodies are considered to be creators when they are responsible for originating, issuing, or causing to be issued, works that fall into one or more of the following categories: a) works of an administrative nature dealing with any of the following aspects of the body itself: i) its internal policies, procedures, finances, and/or operations or ii) its officers, staff, and/or membership (e.g., directories) or iii) its resources (e.g., catalogues, inventories) b) works that record the collective thought of the body (e.g., reports of commissions, committees; official statements of position on external policies, standards) c) works that report the collective activity of i) a conference (e.g., proceedings, collected papers) or ii) an expedition (e.g., results of exploration, investigation) or iii) an event (e.g., an exhibition, fair, festival) falling within the definition of a corporate body (see 18.1.2) provided that the conference, expedition, or event is named in the resource being described d) works that result from the collective activity of a performing group as a whole where the responsibility of the group goes beyond that of mere performance, execution, etc. e) cartographic works originating with a corporate body other than a body that is merely responsible for their publication or distribution. f) legal works of the following types: i) laws of a political jurisdiction ii) decrees of a head of state, chief executive, or ruling executive body iii) bills and drafts of legislation iv) administrative regulations, etc. v) constitutions, charters, etc. vi) court rules vii) treaties, international agreements, etc. viii) charges to juries, indictments, court proceedings, and court decisions. While it's true that a conference itself doesn't write the text of its proceedings, it's treated as a collective creator. When you go to the relationship designators for creators, the appropriate one for a conference is author, no matter that you don't like the term when used for corproate bodies and the fact that it implies actual writing by an individual. Since the definition in RDA applies, the correct designator is author. A person, family, or corporate body responsible for creating a work that is primarily textual in content, regardless of media type (e.g., printed text, spoken word, electronic text, tactile text) or genre (e.g., poems, novels, screenplays, blogs). Under rule 19.2.1.1.1 a conference is responsible for creating a work consisting of its proceedings. If the proceedings are textual, the appropriate designator is author. One could always propose a more specific designator to use for the specific situation of a conference as creator of a work. Any suggestions for that? ** * 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 * **
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On Tue, Nov 8, 2011 at 7:01 AM, Hal Cain wrote: snip However, once I began to see how competent systems handled MARC, it became plain that what they were doing was basically to create a matrix and populate it with the tag values, the indicator values, and the subfield data prefixed by the subfield code. Then the indexing routines read the matrix (not the raw MARC ISO2709 data) and distributed the data into the appropriate areas of the system's internal table structure. From those tables, I was able, when required, to obtain what I wanted by direct query on the appropriate part of the database. When it was necessary to export a single MARC record, a group of them, or indeed the whole database, the system had routines which reversed the process (and, last of all, counted the number of characters in order to fill in the record length element of the MARC leader). This was extremely burdensome to programmers who came to the game in the 1990s and had no background in early data processing, chiefly of text rather than numbers, but in its time it was pure genius. Nowadays it's a very special niche, and the foreignness to programmers and designers of the processes involved probably plays a part in keeping us from having really good cataloguing modules and public catalogues; and I can understand the frustration entailed for those who expect to interrogate a database directly. Bear in mind, though, that using a modern cataloguing module (Horizon is the one I'm most familiar with), I can search for a record on a remote system, e.g. the LC catalog, through Z39.50, and have the record on my screen, in editable form, in a second or two, indistinguishable from a record in the local database. The system's internal routines download the record in MARC format (ISO 2709, hated by Jim) and build the matrix which feeds the screen display. /snip This is really a nice description of the problems of ISO2709, Hal. Thanks a lot. I would like to clarify one point however: do I hate ISO2709 format? I can answer that honestly: no. It served its purpose well for the environment it was born into. That environment changed however, and we need to face up to that. If our modern systems (i.e. modern web browsers) worked with the ISO2709 format, i.e. the files that the machine actually receives, then I would be all for it. Yet, this is not the reality of the situation. Browsers work with a variety of formats, but they work with XML, which gives us some options. Browsers do not work with ISO2709, and I don't believe they ever will. Therefore, the only systems that can work with ISO2709 records (which is how libraries exchange their cataloging information) are other catalogs, and that automatically restrains us from participating in the wider information universe. As a result, in my own opinion, hanging on to ISO2709 borders on the irrational since we automatically limit the utility of our records, thereby limiting ourselves. MARCXML has many limitations that I won't discuss here, but *at least* it is in XML which *can* be used in the new environment. It is much more flexible than ISO2709. For instance, I have mentioned before that I believe we should get away from a *single* main entry--that while a single main entry made sense in the card catalog, it makes no sense in a computerized catalog. Others disagree, but no matter what, I think it is vital that we should have that kind of flexibility. Getting rid of a *single* main entry would be the equivalent of DC's creator and contributor where creator is repeatable, thereby creating multiple main entries. It turns out this is much more difficult than merely making 1xx repeatable, since you also have to allow it in the 6xx, 7xx and 8xx, for books *by* Masters and Johnson, for books *about the books* written by Masters and Johnson, for analytical and series treatments as well. You could do this without too much difficulty in XML, even in MARCXML, but in ISO2709, it would be a relative nightmare because you would have to rework the entire structure, from the directory on down. (This is why the MARCXML principle of roundtripability--what a word!--needs to be dropped. Otherwise, we remain trapped in the ISO2709 format anyway!) Anyway, while it may be possible to rework ISO2709 to such an extent, would it be worthwhile to do it on such an old format? This is just one example of the relative inflexibility of ISO2709, but there are many more. Still, I don't hate ISO2709. It served its purpose admirably, but it's like the horse and buggy. I'm sure nobody hated horses and buggies after the automobile came out, but eventually, if it turned out that Dad and Grandpa refused to get a car when everybody else had one and the advantages were plain for all to see, Junior very possibly would have wound up hating the horse and buggy he was forced to use. -- James L. Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
08.11.2011 07:01, Hal Cain: However, once I began to see how competent systems handled MARC, it became plain that what they were doing was basically to create a matrix and populate it with the tag values, the indicator values, and the subfield data prefixed by the subfield code. This is only one possible way. There are other ways; I programmed one that is not decidedly MARC specific but handles MARC/ISO anyway. It is scriptable, not hard- wired to do just this job and nothing else. The ISO7209 structure (later renamed Z39.2) was an incredibly fussy concoction that presumedly allowed for some efficiency in the days of magnetic tape based processing. (To know in advance, inside the program, how long a field would be, was an advantage then.) Today, fussing around like that is ridiculous, it would be full well possible and economical to use something like the MarcEdit external structure: =LDR 01234cam a22002771a 45e0 =001 438554701 =008 100412s1975n\\\eng\d =020 \\$a0913896039 =050 \0$aPN3377.5.S3 =082 00$a808.3876 =090 \\$aQ2'Fdg-150 =100 1\$aDe Camp , Lyon Sprague =245 00$aScience fiction handbook /$cL. Sprague de Camp and Catherine Crook de Camp =250 \\$aRevised ed. =260 \\$aPhiladelphia :$bOwlswick Press,$c1975 =300 \\$aVIII, 220 S. ; 8 =500 \\$aLiteraturverz. S. 203 - 212 =650 \0$aScience fiction Authorship =650 \0$aScience fiction History and criticism =700 12$aDe Camp , Catherine Crook =700 12$aCamp, Catherine Crook de It can be editied as a simple text file, sent by e-mail or ftp, or magnetic tape. It can use UTF-8 or any other encodings. For those few systems that still can ingest only ISO data, there's MarcEdit to convert it back and forth. It is therefore beside the point to talk about ISO2709 when discussing whether MARC must die or not. From a programmer's POV, this matter can be considered closed. MARC has other flaws that are much more serious and not all of them solvable algorithmically. Maybe the problem is that there's no universal bibliographic database that isn't MARC-based? There certainly are such databases. One of them is Pica, widely used in Europe, and now owned by OCLC. Another one is the system programmed by myself, also widely used. Both can handle MARC, in whichever ways it comes. But internally, they go their own ways. If needed, they deliver MARC records or whatever, via web services or as simple files. B.Eversberg
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
I'm posting this to the BIBFRAME list as well since it seemed relevant... To me, the original main entry concept could more usefully be thought about in a larger context of for any field that is repeatable in a set of bibliographic description fields, is it useful to be able to designate one such fields as primary for purposes of selection for display, categorization (where a particular application requires one to select one box to characterize a resource) or other functionalities? If so, should the designation be stored with the field, or separately from it? Other MARC approaches that serve that function include choice of format (which one goes in Leader byte 6, which one gets reflected in an 006, when a resource has characteristics of two formats?). For fields like subject, I believe there was a convention that the most important subject (the one upon which the primary classification number was based) had the first position in the record. Since many modern systems permit or even force re-ordering tags in numerical order, that positional value can and often is easily lost. Many of us stopped lamenting this a long time ago, but was it valuable? What I don't think is valuable, is having to pick one author of a work with multiple authors and designate that person as the main one, based on the almost arbitrary factor of position of the name on the title page, (which is often alphabetical), and ending up deeming this person Creator and relegating the other author(s) to Contributor status. (Nor do I think that dichotomy is particularly useful.) Laura Laura Akerman Technology and Metadata Librarian Room 128, Robert W. Woodruff Library Emory University, Atlanta, Ga. 30322 (404) 727-6888 lib...@emory.edu -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod Sent: Tuesday, November 08, 2011 11:24 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Jim said: Getting rid of a *single* main entry would be the equivalent of DC's creator and contributor where creator is repeatable, thereby creating multiple main entries. How would you produce single entry bibliographies? How would scholars cite in footnotes? How would cataloguers construct subject and added entries for works? Libraries are part of a larger bibliographic universe, and should adhere to its standards and practices, which would include returning to compiler main entry. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__ This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments).
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
For fields like subject, I believe there was a convention that the most important subject (the one upon which the primary classification number was based) had the first position in the record. Since many modern systems permit or even force re-ordering tags in numerical order, that positional value can and often is easily lost. Many of us stopped lamenting this a long time ago, but was it valuable? Yes. Mike Tribby Senior Cataloger Quality Books Inc. The Best of America's Independent Presses mailto:mike.tri...@quality-books.com
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
And it is still the rule if you are following the LCSH conventions as specified in its rulebook, the Subject Headings Manual. The first subject heading is also tied closely to the classification number assigned. 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 Tue, 8 Nov 2011, Mike Tribby wrote: For fields like subject, I believe there was a convention that the most important subject (the one upon which the primary classification number was based) had the first position in the record. Since many modern systems permit or even force re-ordering tags in numerical order, that positional value can and often is easily lost. Many of us stopped lamenting this a long time ago, but was it valuable? Yes. Mike Tribby Senior Cataloger Quality Books Inc. The Best of America's Independent Presses mailto:mike.tri...@quality-books.com
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Laura Akerman said: What I don't think is valuable, is having to pick one author of a work with multiple authors and designate that person as the main one ... As I asked Jim, how would you construct at 600$a$t subject or 700$a$t added entry for a manifestation, if there were no main entry? How would a scholar construct a footnote citation? How would you list it in a single entry bibliography? It seems to me main entry (by any other term) is a vital concept in the bibliographic universe. For fields like subject, I believe there was a convention that the most important subject (the one upon which the primary classification Ynumber was based) had the first position in the record. Since many modern systems permit or even force re-ordering tags in numerical order, that positional value can and often is easily lost. Many of us stopped lamenting this a long time ago, but was it valuable? Agreed. We do try to make the first 650 (as opposed to the first 6XX) agree with the class number. But I suspect 6XX order is as unimportant as note order to patrons. There was a way of coding in UTLAS to bring a particular 6XX first, one of many features lost with its demise. There was no wayy of coding to bring a particular 5XX first. For note order, we use more exact coding than most, e.g., 501 DVD special features, 503 (which we refuse to give up) for Originally issued ..., 508 for all non cast credits, 511 for cast credets, DVD in 300 rather than 538, 588 for source (e.g., IMDb). It's much less labour intensive than arranging a bunch of 5XXs. (DVDs tend to have more notes than many library resources.) As mentioned in my list of requirements for a replacement coding scheme, it should arrange data in optimum display order, without a lot of manipulation at data entry, or complicated OPAC programming. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On 08/11/2011 17:23, J. McRee Elrod wrote: snip Jim said: Getting rid of a *single* main entry would be the equivalent of DC's creator andcontributor wherecreator is repeatable, thereby creating multiple main entries. How would you produce single entry bibliographies? How would scholars cite in footnotes? How would cataloguers construct subject and added entries for works? Libraries are part of a larger bibliographic universe, and should adhere to its standards and practices, which would include returning to compiler main entry. /snip Could you point me in the direction of a bibliographic citation format that demands someone choosing a *single* main entry? I have worked a lot with them and have never found anything resembling a single main entry. While the practices vary, the main rule is, copy the authors in the order they appear on the title page. Some stop at a maximum of four, none more than seven. Some want the forms of names as spelled out on the item, others say to abbreviate first and middle names. These formats mostly want people to differentiate between authors and others, e.g. editors, compilers, and translators, by putting in (ed.) or mentioning translations. Here is the Chicago format http://writing.wisc.edu/Handbook/DocChi_WC_book.html. Another nice page is from Ursinus http://myrin.ursinus.edu/help/resrch_guides/cit_style_mla.htm. Here is a guide for the Harvard rules http://libweb.anglia.ac.uk/referencing/harvard.htm For books with two, three or four authors of equal status the names should all be included in the order they appear in the document. Use an *and* to link the last two multiple authors. These rules, and others, actually use et al.! I admit that these considerations would provide a reason to go back to the practice of adding relator codes (which I do *not* think is the right thing to do, by the way). Now, as far as cataloging items for subject or added entries for works with two or more main entries, it can be done in XML quite easily, but more difficult with ISO2709. With XML, for a subject entry for Masters and Johnson (two main entries), you could have (an abbreviated MARCXML record. I think catalogers can follow): record 100 aSmith, John/ad1960-/d /100 245 aThe book by Masters and Johnson/a bsome thought/b cby John Smith/c /245 260 aNew York/a bRandom/b c2011/c /260 subjectUniformTitle 100 aMasters, William Howell/a d1915-2001/d /100 100 aJohnson, Virginia/a d1925-/d /100 240 aHuman Sexual Response///a /240 /subjectUniformTitle /record The same could be done with an analytic or series, just replacing subjectUniformTitle with analyticUniformTitle or seriesUniformTitle. How this could be done in ISO2709, I do not know, but I won't say that it cannot be done because somebody may figure out a way, but I can't imagine why anyone should want to. XML can do it right now and it could be utilized by browsers the world over--right now. Once we get away from ISO2709, there will be all kinds of novel bibliographic structures that can be implemented. ISO2709 leads catalogers to think in certain ways about how information in structures. There is no need for that any longer. -- James Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Kind of off topic, but curious why you don't think relator codes are the right thing to do. If we're listing 3 or 5 or 10 people or entities 'responsible' for an artistic work, why wouldn't we want to be able to say the nature/role of each entities responsibility? Or, if we do, but relator codes are a poor device for this, why? On 11/8/2011 3:25 PM, James Weinheimer wrote: On 08/11/2011 17:23, J. McRee Elrod wrote: snip Jim said: Getting rid of a *single* main entry would be the equivalent of DC's creator andcontributor wherecreator is repeatable, thereby creating multiple main entries. How would you produce single entry bibliographies? How would scholars cite in footnotes? How would cataloguers construct subject and added entries for works? Libraries are part of a larger bibliographic universe, and should adhere to its standards and practices, which would include returning to compiler main entry. /snip Could you point me in the direction of a bibliographic citation format that demands someone choosing a *single* main entry? I have worked a lot with them and have never found anything resembling a single main entry. While the practices vary, the main rule is, copy the authors in the order they appear on the title page. Some stop at a maximum of four, none more than seven. Some want the forms of names as spelled out on the item, others say to abbreviate first and middle names. These formats mostly want people to differentiate between authors and others, e.g. editors, compilers, and translators, by putting in (ed.) or mentioning translations. Here is the Chicago format http://writing.wisc.edu/Handbook/DocChi_WC_book.html. Another nice page is from Ursinus http://myrin.ursinus.edu/help/resrch_guides/cit_style_mla.htm. Here is a guide for the Harvard rules http://libweb.anglia.ac.uk/referencing/harvard.htm For books with two, three or four authors of equal status the names should all be included in the order they appear in the document. Use an *and* to link the last two multiple authors. These rules, and others, actually use et al.! I admit that these considerations would provide a reason to go back to the practice of adding relator codes (which I do *not* think is the right thing to do, by the way). Now, as far as cataloging items for subject or added entries for works with two or more main entries, it can be done in XML quite easily, but more difficult with ISO2709. With XML, for a subject entry for Masters and Johnson (two main entries), you could have (an abbreviated MARCXML record. I think catalogers can follow): record 100 aSmith, John/ad1960-/d /100 245 aThe book by Masters and Johnson/a bsome thought/b cby John Smith/c /245 260 aNew York/a bRandom/b c2011/c /260 subjectUniformTitle 100 aMasters, William Howell/a d1915-2001/d /100 100 aJohnson, Virginia/a d1925-/d /100 240 aHuman Sexual Response/a /240 /subjectUniformTitle /record The same could be done with an analytic or series, just replacing subjectUniformTitle with analyticUniformTitle or seriesUniformTitle. How this could be done in ISO2709, I do not know, but I won't say that it cannot be done because somebody may figure out a way, but I can't imagine why anyone should want to. XML can do it right now and it could be utilized by browsers the world over--right now. Once we get away from ISO2709, there will be all kinds of novel bibliographic structures that can be implemented. ISO2709 leads catalogers to think in certain ways about how information in structures. There is no need for that any longer. -- James weinheimerweinheimer.ji...@gmail.com mailto:weinheimer.ji...@gmail.com First Thus:http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules:http://sites.google.com/site/opencatalogingrules/
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Jim said: Could you point me in the direction of a bibliographic citation format that demands someone choosing a *single* main entry? See Chicago Manual of Style 14th ed. 16.35-38. Up to three authors may be given, but only the first is given in inverted order. Sounds like a main entry to me. One has to choose one to invert. Beyond three, only the first is given. (Entry under first of more than three is closer to RDA than AACR2, but like AACR2 in substituting et al. for additional authors.) Am I the only one old enough to remember more than one author at the top of the unit card? But *one* was first. Now, as far as cataloging items for subject or added entries for works with two or more main entries ... One still has to be first. I don't see the advantage of having more than one with one first, as opposed to having one. See the statement of responsibility if you want all. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Someone pointed out to me that I should clarify my last remark, talking about the separating of people into Creator and Contributor I was thinking about what happens when mapping MARC to the Dublin Core Creator or Contributor elements, which are loosely defined - not to the RDA concepts which have a different and more distinct definition: Creator - A person, family, or corporate body responsible for the creation of a work. Contributor - A person, family or corporate body contributing to the realization of a work through an expression. Contributors include editors, translators, arrangers of music, performers, etc. Is there any way to determine the RDA distinctions within the current MARC21? Without the use of relators, I can't see how... Laura -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Akerman, Laura Sent: Tuesday, November 08, 2011 2:00 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement I'm posting this to the BIBFRAME list as well since it seemed relevant... To me, the original main entry concept could more usefully be thought about in a larger context of for any field that is repeatable in a set of bibliographic description fields, is it useful to be able to designate one such fields as primary for purposes of selection for display, categorization (where a particular application requires one to select one box to characterize a resource) or other functionalities? If so, should the designation be stored with the field, or separately from it? Other MARC approaches that serve that function include choice of format (which one goes in Leader byte 6, which one gets reflected in an 006, when a resource has characteristics of two formats?). For fields like subject, I believe there was a convention that the most important subject (the one upon which the primary classification number was based) had the first position in the record. Since many modern systems permit or even force re-ordering tags in numerical order, that positional value can and often is easily lost. Many of us stopped lamenting this a long time ago, but was it valuable? What I don't think is valuable, is having to pick one author of a work with multiple authors and designate that person as the main one, based on the almost arbitrary factor of position of the name on the title page, (which is often alphabetical), and ending up deeming this person Creator and relegating the other author(s) to Contributor status. (Nor do I think that dichotomy is particularly useful.) Laura Laura Akerman Technology and Metadata Librarian Room 128, Robert W. Woodruff Library Emory University, Atlanta, Ga. 30322 (404) 727-6888 lib...@emory.edumailto:lib...@emory.edu -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA]mailto:[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod Sent: Tuesday, November 08, 2011 11:24 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CAmailto:RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Jim said: Getting rid of a *single* main entry would be the equivalent of DC's creator and contributor where creator is repeatable, thereby creating multiple main entries. How would you produce single entry bibliographies? How would scholars cite in footnotes? How would cataloguers construct subject and added entries for works? Libraries are part of a larger bibliographic universe, and should adhere to its standards and practices, which would include returning to compiler main entry. __ __ J. McRee (Mac) Elrod (m...@slc.bc.camailto:m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__ This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments).
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Jonathan asked: Kind of off topic, but curious why you don't think relator codes are the right thing to do. Whatever Jim's objections, I can tell you why our clients wish them removed: 1) They may create separate hitlists for the same person. 2) If one hitlist, the relation of the person to the first title listed may differ from other titles in the hitlist. 3) Although a greater problem with $i before $a, they may complicate searching. 4) They create problems (see 1 2) for print products such as acquisitions lists and subject bibliographies. 5) They do not include all the complexities expressed in 245/$c. 6) Some of the terms in the RDA list are long and cumbersome, taking up too much display space. 7) They represent a departure from legacy records; patrons will not understand why some entries have them and some don't. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Yep, I understand those issues that you've mentioned before. They are all (with the possible exception of #7) cases of software being broken. If you have to mangle data to meet the expectations of broken software, well, then you have to. But it doesn't mean the data is broken. You are certainly free to strip out any data that your broken software is unable to handle appropriately, but I don't think it's an argument for those elements to not be in the data in the first place. Well, #5 is different too. It's obviously not possible for a coded vocabulary to ever express everything possible by freely entered human language text. But that's not an argument against using coded vocabularies to supplement transcribed or freely entered text either. If it were, that argument would apply to just about any of our coded values or fixed fields, and we'd have no coded or fixed fields at all, all we'd have is transcribed or free text entered. But this is surely a boring argument we've had before. On 11/8/2011 4:48 PM, J. McRee Elrod wrote: Jonathan asked: Kind of off topic, but curious why you don't think relator codes are the right thing to do. Whatever Jim's objections, I can tell you why our clients wish them removed: 1) They may create separate hitlists for the same person. 2) If one hitlist, the relation of the person to the first title listed may differ from other titles in the hitlist. 3) Although a greater problem with $i before $a, they may complicate searching. 4) They create problems (see 1 2) for print products such as acquisitions lists and subject bibliographies. 5) They do not include all the complexities expressed in 245/$c. 6) Some of the terms in the RDA list are long and cumbersome, taking up too much display space. 7) They represent a departure from legacy records; patrons will not understand why some entries have them and some don't. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Laura Akerman posted; Creator - A person, family, or corporate body responsible for the creation = of a work. 100/110/111 (you forgot conference). Family coding will change with RDA. Contributor - A person, family or corporate body contributing to the realiz= ation of a work through an expression. Contributors include editors, trans= lators, arrangers of music, performers, etc. 700/710/711, if you add joint authors beyond the first to your list above. Beyond that, I so not see the need for the distinction. Of course 245/$c, 508, 511, etc. express these relationships in the words of the item. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Quoting Akerman, Laura lib...@emory.edu: To me, the original main entry concept could more usefully be thought about in a larger context of for any field that is repeatable in a set of bibliographic description fields, is it useful to be able to designate one such fields as primary for purposes of selection for display, categorization I have to say that I really like this idea. I've been thinking of how we might employ primary secondary and everything else in subject analysis. I know that the first subject heading is supposed to be primary, but I also know that the order gets lost in many cases. Primary and not-primary could also be applied to facets: the resource is mainly about, say, England, but some of the action takes place in France and Italy. It seems it would be useful for the user to know the weight of the assigned subjects or facets. In my mind these look like tag clouds, with the most important ones being larger and bolder. As for creators as main entries, to me, indicating the role of creators and agents of all types allows you to make sensible choices on output rather than having the catalog make one decision for all situations. It's just a matter of giving more weight to, say, an author over an illustrator for the purposes of some brief displays. I also think that you could have more than one algorithm for selection of displays. Surely some citation function would place an author in the primary position but would place an editor as a mention after the title, while others place them both as entry points. Or a book on 20th century film directors would want its bibliography with the directors as its main entry, while other citations would logically go under title. I think the questions about how you would manage 6xx or 7xx with $t is a bit of a red herring -- you've got a primary display entry selected, so it's no different from having a main entry for those functions. kc (where a particular application requires one to select one box to characterize a resource) or other functionalities? If so, should the designation be stored with the field, or separately from it? Other MARC approaches that serve that function include choice of format (which one goes in Leader byte 6, which one gets reflected in an 006, when a resource has characteristics of two formats?). For fields like subject, I believe there was a convention that the most important subject (the one upon which the primary classification number was based) had the first position in the record. Since many modern systems permit or even force re-ordering tags in numerical order, that positional value can and often is easily lost. Many of us stopped lamenting this a long time ago, but was it valuable? What I don't think is valuable, is having to pick one author of a work with multiple authors and designate that person as the main one, based on the almost arbitrary factor of position of the name on the title page, (which is often alphabetical), and ending up deeming this person Creator and relegating the other author(s) to Contributor status. (Nor do I think that dichotomy is particularly useful.) Laura Laura Akerman Technology and Metadata Librarian Room 128, Robert W. Woodruff Library Emory University, Atlanta, Ga. 30322 (404) 727-6888 lib...@emory.edu -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod Sent: Tuesday, November 08, 2011 11:24 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement Jim said: Getting rid of a *single* main entry would be the equivalent of DC's creator and contributor where creator is repeatable, thereby creating multiple main entries. How would you produce single entry bibliographies? How would scholars cite in footnotes? How would cataloguers construct subject and added entries for works? Libraries are part of a larger bibliographic universe, and should adhere to its standards and practices, which would include returning to compiler main entry. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__ This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments). -- Karen Coyle
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Karen Coyle said: As for creators as main entries, to me, indicating the role of creators and agents of all types allows you to make sensible choices on output rather than having the catalog make one decision for all situations. It's just a matter of giving more weight to, say, an author over an illustrator ... Hang on there. All our art libraries want exhibition catalogues with main entry under artist. Usually the illustrations are more of the content than the text, so AACR2 would agree. But there is a grey area of divergence between rule and preference. Cataloguer judgement is still required. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Quoting J. McRee Elrod m...@slc.bc.ca: Karen Coyle said: As for creators as main entries, to me, indicating the role of creators and agents of all types allows you to make sensible choices on output rather than having the catalog make one decision for all situations. It's just a matter of giving more weight to, say, an author over an illustrator ... Hang on there. All our art libraries want exhibition catalogues with main entry under artist. Usually the illustrations are more of the content than the text, so AACR2 would agree. But there is a grey area of divergence between rule and preference. That role is designated as artist not illustrator. And in RDA artist is the creator of the Work, illustrator is related to the Expression. RDA definition of illustrator: A person, family, or corporate body contributing to an expression of a work by supplementing the primary content with drawings, diagrams, photographs, etc. If we define our roles carefully, one can make choices based on context and user preference. If we define them poorly, we lose that choice. Someone may do a catalog of illustrators, and want those to be primary for that purpose. Cataloguer judgement is still required. The cataloger needs to determine if a named person is an artist or an illustrator, but cannot determine which is of primary interest to any given user. That's what proper identification is about -- it's not about taking away the user's ability to make choices. And, yes, there will always be grey areas, which is where cataloger judgment comes in. But if we focus on the grey areas we will be missing a lot of slam-dunks. (I suppose that's a mixed metaphor.) kc __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__ -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On Mon, Nov 7, 2011 at 8:00 AM, Bernhard Eversberg wrote: snip Jim, ISO2709 is a nuisance, agreed. And I dislike it no less than you do because I'm a real programmer and know what it feels like. But don't let's get carried away and rush to premature conclusions with inappropriate metaphors. Rather, consider this: Would you tear down your house and rebuild it from the ground up if the old wallpaper gives you the creeps? For that's what ISO2709 is: mere wallpaper. Easily replaced or painted over. Nothing serious, nothing that affects any qualities of the building. /snip I wish that were true. ISO2709 is the standard way libraries exchange their records, and this means that anybody who wants library information must work with ISO2709. ISO2709 was designed to make catalog cards, and that is what it still does today, only the cards are not printed on card stock, they are printed on the computer screen. Certainly, they can be searched in ways different from a card catalog, but this is because of the mere fact that they reside in the computer--not because the format is any more amenable to searching. Today, most web developers I know do not want to copy and reformat and maintain duplicates of records that are on different systems. They want much more to interoperate with them, and they can do this through various APIs. For instance, I can add a Google Books API that will search--in the background--Google Books in all kinds of ways and return one record, or multiple records. It does not give me the entire Google metadata record, nor do I want it. (as ISO2709 does--by definition) I want to work with the Google metadata *on the fly* so that I do not have the responsibility to keep the record current, reformat it and have to do all kinds of additional work. Keeping the record current is Google's responsibility--not mine and I shouldn't have to do it. With ISO2709, it is designed to transfer a complete catalog record from one catalog into another catalog. It is not designed for interactivity. Here is a practical example. At LC, they have lots of sets of records where you can interact with them http://memory.loc.gov/ammem/oamh/oai_request.html. So, I could have a local catalog on e.g. dance, and I could search behind the scenes--if I set the machine correctly--the records for LC's dance instruction manuals. I can display these records as I wish because they are in XML. I would not have to download all records in ISO2709, convert them in MARCEdit, put them into my own database, where the URLs and other information may change in the future, since potentially it is a ton of work to maintain records for materials on the web. Another example is the Worldcat Search API http://www.worldcat.org/affiliate/tools?atype=wcapi. There is no mention of ISO2709 there. Plus, I implemented the Worldcat Citations API when I was at AUR: http://www.oclc.org/developer/documentation/worldcat-search-api/formatted-citations and an example: http://www.galileo.aur.it/cgi-bin/koha/opac-detail.pl?bib=24135. In the right-hand column, you will see Get a Citation. When you click it, you will see citation formats (in XML, not ISO2709) taken on the fly from Worldcat and reformatted by the system I created. This is a simple example and matters could become much more complex, if someone desired. The fact is, most developers want to work with APIs in these kinds of ways instead of having to download, convert (mostly an extremely difficult job to come out with anything coherent), upload into your own system, and then maintain those records. That is horribly inefficient, and unnecessary, today. Why don't more developers work with library metadata? To me, the answer is absolutely obvious. We are not making APIs that developers want to work with, and one reason is that we keep maintaining that if somebody wants our information bad enough, it is easy to work with ISO2709 records by downloading, reformatting, etc. but that is wrong. Working with APIs is what is easy and if you use ISO2709 you absolutely cannot do that. Developers don't want--or need--to jump through all of those hoops when they don't have to, and they prefer to work with other systems. So they don't use our records and prefer, e.g. Amazon, which has all kinds of APIs. Unfortunate. But perhaps it is something that the Bibliographic Framework will address and our metadata will be more usable in the information universe. -- James L. Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Jim, my point is, in nuce: Yes, MARC is horrible, but ISO is not the reason. You wrote: I wish that were true. ISO2709 is the standard way libraries exchange their records, and this means that anybody who wants library information must work with ISO2709. ISO2709 was designed to make catalog cards, No, even worse: MARC itself was designed for that as its primary function. ISO, for all its vices, does not enforce that kind of restriction. With ISO2709, it is designed to transfer a complete catalog record from one catalog into another catalog. Yes, but Web services on any MARC based catalog need not suffer from that, Web services can be constructed without paying any attention to the ISO structure. I said that much in my post. It is regrettable that up until now we still have not many useful web services as part of library OPACs. But the reason for this is certainly not ISO2709. Can someone with more MARC insight than me please confirm this so we can finally put this matter to rest? B.Eversberg
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On Mon, Nov 7, 2011 at 10:21 AM, Bernhard Eversberg wrote: snip Jim, my point is, in nuce: Yes, MARC is horrible, but ISO is not the reason. You wrote: With ISO2709, it is designed to transfer a complete catalog record from one catalog into another catalog. Yes, but Web services on any MARC based catalog need not suffer from that, Web services can be constructed without paying any attention to the ISO structure. I said that much in my post. It is regrettable that up until now we still have not many useful web services as part of library OPACs. But the reason for this is certainly not ISO2709. /snip Have you ever seen or heard of a web service based on ISO2709? What then will be the purpose of ISO2709 except one: to transfer a catalog record from one library catalog to another? But this now appears to be the second aspect of MARC, which is what most of the discussion is about, not about ISO2709 itself, but the coding, e.g. 100b 300c and so on. In one sense, this is much less of a problem because we are talking about mere computer codes, and those codes can display however someone wants them to display. So, when developers say that they don't like MARCXML, this is a lot of what they are talking about since they want and expect the coding to say title and date of publication and they don't want to look up what 245a or 300c means. (There are also the codes that must be dug out of the fixed fields such as the type of dates and dates in the 008, the language code, etc. but that is yet another matter) Of course, we run into the problem of library jargon here, since 245a is not title but title proper and not only that, it includes the alternative title plus it includes individual titles when an item lacks a collective title. There may be some more nuances as well. Therefore, 245a implies separate access to a lot of other types of titles. Non-cataloger developers cannot be expected to know or understand any of this. So, if the format codes it title, that is misleading, while coding it as titleProper, developers will just think it's a weird name for a title. This is complicated and at the moment I don't know how it can be solved. Perhaps our traditional library distinctions will disappear in the new environment, but I hope not. -- James L. Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
07.11.2011 10:55, Jim Weinheimer: With ISO2709, it is designed to transfer a complete catalog record from one catalog into another catalog. Yes, but Web services on any MARC based catalog need not suffer from that, Web services can be constructed without paying any attention to the ISO structure. I said that much in my post. It is regrettable that up until now we still have not many useful web services as part of library OPACs. But the reason for this is certainly not ISO2709. Have you ever seen or heard of a web service based on ISO2709? No, but there is, logically, no need to deal with ISO in order to construct web services. Any technical needs can be eliminated and should have been long ago. What then will be the purpose of ISO2709 except one: to transfer a catalog record from one library catalog to another? I know of no other purpose. But be that as it may, my point is that even for this function, it is no longer technically necessary. For all intents and purposes, MARC may live on forever without the need to deal with ISO2709. It is technically obsolete, but we need not care. Can anyone please prove me fundamentally wrong, or confirm what I say? B.E.
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On Mon, Nov 7, 2011 at 11:05 AM, Bernhard Eversberg wrote: snip But be that as it may, my point is that even for this function, it is no longer technically necessary. For all intents and purposes, MARC may live on forever without the need to deal with ISO2709. It is technically obsolete, but we need not care. Perhaps it will live on as one developer described, when last week at lunch we were discussing the old days of the ISO2709 format for AGRIN3 data that he (and I and everybody) had to work with before we all changed it to XML. He mentioned that he keeps the specifications in a drawer of his desk as a momento mori. Once in awhile he takes them out just to gaze upon and to remind himself of other realities! -- James L. Weinheimer weinheimer.ji...@gmail.com First Thus: http://catalogingmatters.blogspot.com/ Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Bernhard said: I know of no other purpose. But be that as it may, my point is that even for this function, it is no longer technically necessary. For all intents and purposes, MARC may live on forever without the need to deal with ISO2709. It is technically obsolete, but we need not care. I would agree with Bernhard. SLC sends MARC records to about 50 clients, including twelve electronic publishers and aggregators, using a variety of mean: loading records to their server, having them download from our server, sending as a single .mrc file, and sending as individual named files (often the e-ISBN). Our programmer never *heard* of ISO2709. Just once we were asked about it by a Chinese client, and had to look it up to see what they were talking about. We began in 1979 using UTLASMARC, switched 1990 to USMARC, and 1999 to MARC21, but still keeping a couple of features* we like from UTLASMARC. We've never even looked at ISO2709. Is it the basis of Z39.50? The variations we discover in Z39.50 searching are, I assume, features of individual systems, e.g., not all access keys defined by all systems, and the same key is defined differently; in some catalogues the title search is exact, and in some it is keyword, returning a raft of irrelevant hits. Searching is I assume outside ISO2709, since there is *no* standardization in that area. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__ *Our favourite UTLASMARC retained feature is the single 090 per library, far easier than MARC21's one 852 per item. For example: 090 0 $aAB/1234.5/C678/2011$bLibrary$ccopies$dvolumes $ebar code or accession number$fsublocation$rnotes. There are other less used subfields. Our print programs produce the correct number of labels and cards based on the 090, e.g., $c1-2$d1-2 produces four labels. The / produces a line break on a label or card. If one wants a forward slash in the print product, e.g. a split year, one keys \. This 090 is translated into multiple 852s on export for those which wish them. Several Canadian library clients still use UTLASMARC 090. All this without aid of any ISO so far as we know.
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
On Mon, 7 Nov 2011 11:05:14 +0100, Bernhard Eversberg e...@biblio.tu-bs.de wrote: 07.11.2011 10:55, Jim Weinheimer: What then will be the purpose of ISO2709 except one: to transfer a catalog record from one library catalog to another? I know of no other purpose. But be that as it may, my point is that even for this function, it is no longer technically necessary. For all intents and purposes, MARC may live on forever without the need to deal with ISO2709. It is technically obsolete, but we need not care. Can anyone please prove me fundamentally wrong, or confirm what I say? According to my small experiences in the years before I used modern library systems, when I was trying to extract data from MARC files (e.g. to carry out authority control in systems that didn't have authority modules, before proceeding to print catalogue cards), raw MARC data in communications format was a beast, and I wasn't nearly programmer enough to write routines to deconstruct it! However, once I began to see how competent systems handled MARC, it became plain that what they were doing was basically to create a matrix and populate it with the tag values, the indicator values, and the subfield data prefixed by the subfield code. Then the indexing routines read the matrix (not the raw MARC ISO2709 data) and distributed the data into the appropriate areas of the system's internal table structure. From those tables, I was able, when required, to obtain what I wanted by direct query on the appropriate part of the database. When it was necessary to export a single MARC record, a group of them, or indeed the whole database, the system had routines which reversed the process (and, last of all, counted the number of characters in order to fill in the record length element of the MARC leader). This was extremely burdensome to programmers who came to the game in the 1990s and had no background in early data processing, chiefly of text rather than numbers, but in its time it was pure genius. Nowadays it's a very special niche, and the foreignness to programmers and designers of the processes involved probably plays a part in keeping us from having really good cataloguing modules and public catalogues; and I can understand the frustration entailed for those who expect to interrogate a database directly. Bear in mind, though, that using a modern cataloguing module (Horizon is the one I'm most familiar with), I can search for a record on a remote system, e.g. the LC catalog, through Z39.50, and have the record on my screen, in editable form, in a second or two, indistinguishable from a record in the local database. The system's internal routines download the record in MARC format (ISO 2709, hated by Jim) and build the matrix which feeds the screen display. The success of these operations depends on the consistency of the records available. The complexities arise from the complexities in the data we work with, the consistency of our markup (recorded in MARC tags and subfields, a number of which are very specific and don't occur very often, but are applied to specific purposes when they occur, e.g. 254) and sometimes the inconsistency, as when we don't distinguish parallel tiles or alternative titles from other title elements. Those inconsistencies are not so much caused by MARC, certainly not by MARC in ISO2709 format; they result from the belief that specific codes for those elements cannot be created because the coding structure is already full; which is only half true. Now, if what you want is a data storage which can be queried and reprocessed directly, without going through conversions to and from ISO2709, that's something to discuss in its own right; but the tools to translate data between ISO2709 and tabular form do exist, and they operate on the fly within their own systems. For working outside a library system, MarcEdit is one commonly used; for querying specific bibliographic elements it's far from simple. But even Voyager, the ILS providing LC's catalog, supports searches within specific MARC fields and subfields of the LC bibliographic database. Maybe the problem is that there's no universal bibliographic database that isn't MARC-based? And therefore one has to deal with MARC with its inconsistencies and idiosyncracies? I have no solution to that problem; the weight of our history is a considerable obstacle when it comes to trying to do something different. Hal Cain, who acknowledges his knowledge is incomplete and liable to correction Melbourne, Australia hegc...@gmail.com
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
[It appears that my recent message was empty when sent. I apoligize. What I attempted to send follows] On Mon, 7 Nov 2011 11:05:14 +0100, Bernhard Eversberg e...@biblio.tu-bs.de wrote: 07.11.2011 10:55, Jim Weinheimer: What then will be the purpose of ISO2709 except one: to transfer a catalog record from one library catalog to another? I know of no other purpose. But be that as it may, my point is that even for this function, it is no longer technically necessary. For all intents and purposes, MARC may live on forever without the need to deal with ISO2709. It is technically obsolete, but we need not care. Can anyone please prove me fundamentally wrong, or confirm what I say? According to my small experiences in the years before I used modern library systems, when I was trying to extract data from MARC files (e.g. to carry out authority control in systems that didn't have authority modules, before proceeding to print catalogue cards), raw MARC data in communications format was a beast, and I wasn't nearly programmer enough to write routines to deconstruct it! However, once I began to see how competent systems handled MARC, it became plain that what they were doing was basically to create a matrix and populate it with the tag values, the indicator values, and the subfield data prefixed by the subfield code. Then the indexing routines read the matrix (not the raw MARC ISO2709 data) and distributed the data into the appropriate areas of the system's internal table structure. From those tables, I was able, when required, to obtain what I wanted by direct query on the appropriate part of the database. When it was necessary to export a single MARC record, a group of them, or indeed the whole database, the system had routines which reversed the process (and, last of all, counted the number of characters in order to fill in the record length element of the MARC leader). This was extremely burdensome to programmers who came to the game in the 1990s and had no background in early data processing, chiefly of text rather than numbers, but in its time it was pure genius. Nowadays it's a very special niche, and the foreignness to programmers and designers of the processes involved probably plays a part in keeping us from having really good cataloguing modules and public catalogues; and I can understand the frustration entailed for those who expect to interrogate a database directly. Bear in mind, though, that using a modern cataloguing module (Horizon is the one I'm most familiar with), I can search for a record on a remote system, e.g. the LC catalog, through Z39.50, and have the record on my screen, in editable form, in a second or two, indistinguishable from a record in the local database. The system's internal routines download the record in MARC format (ISO 2709, hated by Jim) and build the matrix which feeds the screen display. The success of these operations depends on the consistency of the records available. The complexities arise from the complexities in the data we work with, the consistency of our markup (recorded in MARC tags and subfields, a number of which are very specific and don't occur very often, but are applied to specific purposes when they occur, e.g. 254) and sometimes the inconsistency, as when we don't distinguish parallel tiles or alternative titles from other title elements. Those inconsistencies are not so much caused by MARC, certainly not by MARC in ISO2709 format; they result from the belief that specific codes for those elements cannot be created because the coding structure is already full; which is only half true. Now, if what you want is a data storage which can be queried and reprocessed directly, without going through conversions to and from ISO2709, that's something to discuss in its own right; but the tools to translate data between ISO2709 and tabular form do exist, and they operate on the fly within their own systems. For working outside a library system, MarcEdit is one commonly used; for querying specific bibliographic elements it's far from simple. But even Voyager, the ILS providing LC's catalog, supports searches within specific MARC fields and subfields of the LC bibliographic database. Maybe the problem is that there's no universal bibliographic database that isn't MARC-based? And therefore one has to deal with MARC with its inconsistencies and idiosyncracies? I have no solution to that problem; the weight of our history is a considerable obstacle when it comes to trying to do something different. Hal Cain, who acknowledges his knowledge is incomplete and liable to correction Melbourne, Australia hegc...@gmail.com
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
04.11.2011 21:12, James Weinheimer: Concerning A Bibliographic Framework for the Digital Age http://www.loc.gov/marc/transition/news/framework-103111.html Also, in deference to Bernhard and his statement snip (ISO2709, BTW, is *not* among the flaws and issues. It is a very marginal issue of a purely internal nature and is in no way related to MARC as a content standard. ... /snip I must disagree 100%. Maintaining that ISO2709 is not a problem is like saying that the water in the local stream is fine. While you can't drink it immediately, all you have to do is take a few buckets of that water, let them sit for 5 or 6 hours to settle, then skim off what's on top. Boil the water you skimmed off for 10 minutes or so and then throw in a couple of chlorine tablets at the end. Shake it all up and voila! You can drink it. Therefore, the water is safe to drink! Jim, ISO2709 is a nuisance, agreed. And I dislike it no less than you do because I'm a real programmer and know what it feels like. But don't let's get carried away and rush to premature conclusions with inappropriate metaphors. Rather, consider this: Would you tear down your house and rebuild it from the ground up if the old wallpaper gives you the creeps? For that's what ISO2709 is: mere wallpaper. Easily replaced or painted over. Nothing serious, nothing that affects any qualities of the building. And in all those many OPACs that have a MARC display option: Does one of them show ISO data? Whether or not this option is anything an OPAC should have, this observation easily falsifies the hypothesis that MARC should be dumped or even sneered at because of ISO. And data communication, ISO's real and only intention, can be carried out just as well with MarcEdit's external text based format, with no end-user noticing any change. And while we are at this: What about the triplestore format LC has used to make their authority data available for download, esp. the LCNAF stuff with RDF/XML wallpapering: http://id.loc.gov/authorities/names.html Would that be a promising alternative to MARC (ISO or not)? B.Eversberg
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
After the new master plan had been publicized, I've had exchanges with various people about it. Mac referred to parts of this. Enthusiasm seems to be buildung up only very slowly, if at all... A plan of this caliber ought to make a real splash in the community. This is not just any old paper but a highly important one of potentially far-reaching ramifications and a high impact on the quality of the stuff we are working with, and thus the quality of our work, from now on into an indefinite future. We all expect this quality to improve, of course. Is this expectation justified by the Framework? For one thing: that plan puts all eggs into one basket in committing itself to Web standards like XML and RDF when, far and wide, there is no large-scale bibliographic database that serves real-life library work while being based on those. Correct me if I'm wrong. What with Linked Data and RDF, those are offsprings of the Semantic Web movement. In that arena, it is taken for granted that everything comes for free. Content standards that are not openly available will meet zero acceptance, may they use RDF or not. Of course, as was discussed yesterday, the maintenance of an open standard takes a long-term commitment. And for the data itself, what is OCLC's view on the matter of liberal access via triplestores? Now XML and RDF are not brand-new, and there certainly have been lots of attempts to employ them in a grand way, even some at very prestigeous places. Where are the success stories and the smoothly running new-age engines based on the results? I'm asking this not for the first time, but up until now got no answers in the forums. Certainly, library systems need to be able to export and import XML and RDF structures, side by side with many others. With the appropriate tools and interfaces, library catalogs need never show anybody, except those working on their upkeep, what their data looks like internally or how they communicate among each other. Even today, not every library system uses MARC internally. They just all of them are able to swallow it and spew it out. (No mean feat, I think, even today. Even something like VuFind takes in MARC and nothing else.) RDF triples in huge depositories called triplestores are static copies, they need to be frequently refreshed. Is that realistic? Will it really be useful and attractive for end-users if every library rig up their own triplestores - or should OCLC do that for all of them? Even now, OCLC could already be doing a *much* better job of letting end-users access structured data in many useful ways, XML structured and otherwise, out of the live database, not a stale copy. So: RDF is welcome as an addition, a special export product, but not suitable for internal purposes and much too clumsy for bulk communication. (JSON seems to be gaining ground now) Secondly, there is no need for there to be one and *only* one exchange standard. If some community needs some peculiar different format XYZ, there may be tools that take in MARC and serve up XYZ. On a per record or result set basis, web services can do that nicely, with no one caring what the original was looking like. If we create more and flexible standards for web services, these might solve or support most of the requirements our catalogs of the future are expected to fulfil for end-users and exchange, even with MARC inside. Web services are flexible, easily extended and modified, with no need to tinker with internal or communication structures. And the plan itself says that MARC21 should be retained as an exchange format for as long as necessary. So why not first create an alternative format, test it up and down any number of years, improve it or add yet another better design, and so on. And creating and enhancing web services standards all the while, as the *primary means* of access to library data from any outside agents. This can begin right now and it has begun in many places, so one should look at ways to coordinate and standardize some of this work. Eventually, let the market decide, let the better concept win or let it take over step by step as it gains acceptance. MARC may or may not fade away in the process, sine ira et studio. Anyway, two years to achieve credible progress, in this field? How's that defined, BTW, how will it be determined? And what does it mean to Demonstrate credible progress? Which of the many aspects of format features and uses will that include? (About involvement of NISO, there's another thread in this forum) And thirdly, data input and editing may use any modern techniques available today, hiding all the ghastly stuff involved with MARC under layers and subwindows of pulldowns and radio buttons and plain language labeled input fields. No playground for RDF and XML here. Ask the vendors why they don't provide that. But don't forget to evaluate the economy of a new catalogers' interface - and what it means to have different ones on sytems A, B and C - in comparison with the
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Quoting Bernhard Eversberg e...@biblio.tu-bs.de: Oh I forget: RDA's trouble with MARC was what led to this plan in the first place. Well, that is not MARC's fault but the one of the particular setup that was used for the test. It did not use capabilities and provisions that are in fact there in MARC, like the use of identifiers for authority headings, and record linking for multi-part resources; the part-whole relationship wasn't considered at all. Bernhard, I just want to comment here on this one point - It is possible to put URIs into MARC fields using the $0, but there are MARC fields that are not 1-to-1 with the thing you need to identify. In other words, the granularity of MARC is not the same as the granularity of identified entities. There were discussions of embedding the $0 after the identified portion, but again it might not be clear which preceding subfields were represented by the identifier in $0. So in fact MARC isn't able to accurately to create the needed association between identifiers and subfields. I tried to find the discussion in the MARC development documentation but it didn't jump out at me. Perhaps someone else remembers when that discussion took place. kc The test, in short, was a much too timid and superficial exercise to base any overall judgement about RDA in MARC on. Or had the test, to begin with, been designed so as to be able to then say, See how inadequate MARC is!? MARC does have its flaws, I'm really no fan of it as it is now, let alone the curent practice, and I have written up and published a long list of flaws. With some, I don't know why they haven't long since been solved. They may, however, be cured without sacrificing the economy of MARC, without dismissing the entire concept and logic before something demonstrably more economical and logical has been found and proven. Briefly: We can set up our entire enterprise so that, internally, we have the full benefit of an economical format that fits all our numerous and highly diverse management purposes which are of no interest to end-users. Externally, no one needs to be confronted with our internal format, but there can be an increasing variety of options to choose from, all derived from the same internal format. (ISO2709, BTW, is *not* among the flaws and issues. It is a very marginal issue of a purely internal nature and is in no way related to MARC as a content standard. MARC can perfectly well work without ISO, no one needs to bother with it except the few systems that are still unable to ingest anything else, and they can use MarcEdit to get what they want. Abandoning ISO in favor of the external format MarcEdit uses, you get rid of the character field length limit as well.) Have a good weekend! B.Eversberg. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Offlist reactions to the LC Bibliographic Framework statement
Concerning A Bibliographic Framework for the Digital Age http://www.loc.gov/marc/transition/news/framework-103111.html Well, I take a slightly different position from my esteemed colleagues. The transition from our outdated format will have to come sooner or later, and the sooner we do it, the sooner we can actually enter the larger world of metadata, be it for better or for the worse. Format considerations themselves are, I think, not the real issue for catalogers. To me, the issues are similar to those back at the end of the 19th century, when libraries wanted to share copies of their catalog cards, but the sizes of the cards were different in each library. This had to be dealt with first. Therefore, it became a duel to the death to get the size of *your own* library's cards as the accepted standard, otherwise you would be forced to recatalog everything on the other sized cards. At Princeton University, their cards were larger than was ultimately accepted, so they tried cutting down the cards and writing what was cut off wherever they could. (I never found one of those, but I would have loved it!) That didn't work out so well, so they had to use other solutions. Still, after all of that fighting, all that everyone had agreed upon was a *blank* card. Then came the real fight, about what information should be written on the card, and where each bit of information should go. That took a long time to agree upon, with ISBD solving part of it. Deciding on a common format is similar to deciding on the standard-sized card back then. While this is a very important step, it is nevertheless necessary to point out that everyone will be agreeing on an *empty* format. What will fill up that format is what cataloging should focus on. To be honest, what interests me much more than this: 245 10 $a. is what actually goes into that 245 field, how to enter the title itself in a standardized way so that others can find and understand the record. Whether the format is: 245 10 $a or marc:datafield tag=245 ind1=1 ind2=0marc:subfield code=a /marc:subfield /marc:datafield or isbd:titleProper /isbd:titleProper I don't really care very much. Most of this must be determined by technicians. Catalogs have their needs and these must be kept in mind, but some of their needs are very probably outdated now. One format may be more accurate, one may have indicators for alphabetical browsing (which almost nobody does anymore), and of course, some formats will be ignored by developers because they are too much of a pain to work with. In my opinion, we need to make our formats as amenable to developers as possible, because then they may be willing to include us rather than exclude us. Once everyone moves to XML-type formats, there will automatically be the flexibility for various groups to add their own name spaces, e.g. I can imagine something like: record isbd:titleproper/isbd:titleproper onix:dateofIissue/onix:dateofIissue aacr2:dateofPublication/aacr2:dateofPublication myLibrary:subjectmyLibrary:subject /record In this way, different communities could add their own metadata, while still being able to cooperate. I think a lot of communities, and individual libraries, will like this possibility. All in all, I think something like this should have been done a long time ago, as a first step before considering RDA. Once the format is dealt with in some way, (just as the standard-sized card so long ago) then changes in cataloging rules may make more sense--or they may not. Also, in deference to Bernhard and his statement snip (ISO2709, BTW, is *not* among the flaws and issues. It is a very marginal issue of a purely internal nature and is in no way related to MARC as a content standard. MARC can perfectly well work without ISO, no one needs to bother with it except the few systems that are still unable to ingest anything else, and they can use MarcEdit to get what they want. Abandoning ISO in favor of the external format MarcEdit uses, you get rid of the character field length limit as well.) /snip I must disagree 100%. Maintaining that ISO2709 is not a problem is like saying that the water in the local stream is fine. While you can't drink it immediately, all you have to do is take a few buckets of that water, let them sit for 5 or 6 hours to settle, then skim off what's on top. Boil the water you skimmed off for 10 minutes or so and then throw in a couple of chlorine tablets at the end. Shake it all up and voila! You can drink it. Therefore, the water is safe to drink! We can't expect people to do that when there are all kinds of other, more friendly methods out there that will let you do what you want without jumping through hoops. I want to be able to drink water directly out of the tap! How in the world can we hope to change our format if we don't see the problems with a format that is over 40 years old and everybody has to work with *before* they can
[RDA-L] Offlist reactions to the LC Bibliographic Framework statement
http://www.loc.gov/marc/transition/news/framework-103111.html Reading LC's statement (see URL above) on plans for future bibliographic control, led to some interesting offlist correspondence. I've received permission from the authors, Michael Gorman, Hal Cain, and Bernhard Eversberg, to post their comments. Bernhard plans to expand on his comments and post them on RDA-l, so most of his comments are removed from the version posted here. I think American Libraries editors should approach Bernhard for an op ed piece, similar to Michael's earlier one on RDA. I said: Looking at these links, I see very little in the way of actual proposals, just lots of generalities. Am I missing something? Hal Cain wrote: I haven't studied the statement closely. At a hasty reading, there didn't seem to be much that required serious attention. I doubt LC has many remaining staff in the data management area who are competent to contribute to creating a new medium of recording and exchanging bibliographic data. I suspect Rebecca Guenther's retirement was strategic: I don't want to be mixed up in this mess! but I could of course be wrong. I have no contacts remaining inside LC, since Tony Franks has opted to go away in search of peace. That leaves the enterprise prey to consultants. Alternatively it may be outsourced to OCLC. I wonder where they think they'll get grants? The likely outcome, as I see it, is that there will be an outline scheme, with a rudimentary crosswalk to MARC 21 (OCLC are good at that kind of thing, and will have to be on the inside anyway because LC cataloguing couldn't survive without OCLC) but there will be no consensus about its value and usefulness, by NLM and NAL. I remain totally bemused by the blind pursuit of two conflicting goals: more simplicity (BIBCO standard record schemes) vs. complexity (RDA detail and the structure of the code). Michael, I'm a fan of your Concise AACR2 code. I wish RDA had been written (if it was truly needed, of which I'm still not completely convinced) in that style, with application manuals for particular types of resources. [snip] Michael Gorman wrote: This begins with a gaseous piece of nonsense: [MARC is] based on forty-year-old techniques for data management and is out of step with programming styles of today, and gets worse. They want to change for change's sake but have no idea what to do. What we can be assured of is that the result will be worse and the slide toward bibliographic chaos accelerated. MARC is a framework standard that defines bibliographic elements precisely. RDA and metadata (faux) standards such as the Dublin Core (a pathetically inadequate subset of MARC) will ensure that the content standards will be worse than before, so perhaps they deserve a less precise framework standard . Bernhard Eversberg said in response to Michael's comments above: A harsh verdict, and it doesn't come from just somebody. This view needs to get out in the open. It borders on an emperor's new clothes situation. Michael Gorman added: I thought I should expand a little on my testy reply of yesterday (though I meant every word of it). MARC consists of sequential denominators of elements of access points and bibliographic descriptions (plus some too-little used codes). Those denominators identify a wide range of real world bibliographic conditions precisely (i.e., a particular combination of tag and code will specify exactly what that condition is and, by implication, what it is not) but does not dictate how that condition is expressed (hence the reason why the term MARC cataloguing is a nonsense--the cataloguing defines what goes into MARC, not the nature of MARC--the framework that contains and defines the data). That being so, we should ask: 1. Will the replacement for MARC have (a) the same level of precision, (b) more precision, or (c) less? And why? 2. MARC is defined by numeric tags and alphabetic codes, what is t o replace them? Why? 3. My understanding is that vendors have based the programming for their library systems on MARC. How are they to migrate from MARC to non-MARC. If the answer to 1., above, is a, the transition would be easy but what's the point? If it is b or c, the transition would require a massive effort that would not, I would have thought, be cost beneficial. English speakers call dried plums prunes. If it is decreed that, as of January 1st, we call them ghiwibels and ghiwibel means 'prune' we have gained nothing but suffered inconvenience. If ghiwibel means either 'dried fruit' or 'fruit with a stone in it,' we have lost definition (the language being poorer) and suffered inconvenience. __ __ J. McRee (Mac) Elrod (m...@slc.bc.ca) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__