> -----Original Message----- > From: Resource Description and Access / Resource Description and Access > [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Weinheimer Jim > Sent: March 18, 2011 1:25 PM > To: RDA-L@LISTSERV.LAC-BAC.GC.CA > Subject: Re: [RDA-L] "Business case" for RDA changes (was: RDA "draft") > > Mac wrote: > <snip> > But this could have been accomplished by an AACR2 revision page, and > treaties make up a very small part of the collections of most > libraries. > </snip> > > Mac is right and this idea of course, goes beyond treaties to include > RDA. While we can all agree that some rules can and should be changed, > it does not add up to a *business case* to justify junking our old > rules and spending our quickly diminishing budgets for an entirely new > set of rules that everybody must be retrained in, especially when the > final product will be practically the same as what we make now. >
To evaluate the business case for individual elements you need an element set in the first place. That's what RDA introduces-- the element set for bibliographic data, mostly built out of what's in AACR2. RDA is AACR2 data transposed into an element set. You need to do that before you can do element-level business cases. Most of the rule changes discussed (treaties, collective titles, books in the Bible, and so on) are for headings. Concatenated elements in a heading have a "business case" in the sense we need to construct headings to file correctly for collocation. But the business case for each element can't be reduced to just its form and placement in headings. Otherwise, we're left saying things like "We need this element because it files here" in situations where people are doing searches other than browse searching, and seeing displays that are enriched beyond the strings of text in catalog records. RDA doesn't "junk" old rules-- it applies labels and categorizations to our data that represents our articulation of what that data means beyond its role in constructing headings. When I first encountered FRBR in 1997, there was certainly training required on the vocabulary, but not really on the reality behind those concepts. Those were actually easy to grasp because there were problems with AACR2 and MARC that were obvious in a way but hard to articulate before FRBR. There were problems in the way AACR2 and MARC worked in the various systems and OPACs I have experienced-- why was collocation, especially with name-titles and 240 titles, so messed up in different indexes? why were there full authority records for some name-titles and not others? why were related works and linked headings so difficult to work with? why were so many MARC fields underutilized? why did we continue to use AACR2 terms like "entries" when clearly there was so much more going on in automated displays? why were there semantically confusing overlaps (like 440) to keep track of? what display value was there for indicator values like 700 x2 for "contains work"? why couldn't these relationships be extended to other headings? why were the rules for added entries for compilations with multiple people responsible so convoluted and clearly written for card catalog constraints that didn't exist anymore? why was authority data so rarely displayed in systems when there was very useful data there? why did I have to worry about missing the abbreviation for a place-name covered in tables for abbreviations when there didn't seem to be any point to abbreviations in modern systems and OPACs? why couldn't I link parts of records to each other, such as 5XX notes that annotated other fields, and separate from 5xx fields that looked like important elements on their own? why was some data in headings only there to be break conflicts when that data could be so useful on its own? ... and on ... and on ... and on. The reason AACR2 and MARC had problems wasn't because of the underlying data, but in the fact we were NOT looking at the "final product" for that data. Articulating our data in the form of an element set allows us to talk about new products and business cases. That's the practical first step to take. Thomas Brenndorfer Guelph Public Library
