________________________________________ From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of James Weinheimer [weinheimer.ji...@gmail.com] Sent: August-07-11 6:08 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Completeness of records
On 06/08/2011 19:00, Brenndorfer, Thomas wrote: <snip> But it's not true FRBR, and it doesn't do translations well, and so it requires extra effort to answer patron queries about titles in our small language collections. And part of the problem with translations stems from removing fields like 240 for display purposes when that destroys the only mechanism left to relate those resources. It's that tangling of display and user task functionality in fields that causes so much grief. That's why those aspects of catalog design need to be separated. Fortunately, FRBR absolutely does NOT depend upon those antiquated methods, such as collocation by uniform titles, to specify relationships. As the FRBR report (http://archive.ifla.org/VII/s13/frbr/frbr2.htm#5) indicates, the current methods of creating relationships in catalog records are haphazard. </snip> >FRBR does need the uniform title in some form, that is, some bit of data >that brings the different records together. There's a difference when data is controlled by identifiers or control numbers vs text strings. I've gone through several library and library systems, and currently I am able to do a lot of authority updating and maintenance based upon control numbers that I couldn't do before with earlier, less capable systems. However, once I move closer to cleaning up the bibliographic records I have to switch to more manual operations, manual checking, crude global updates methods and deduping algorithms, etc. (such as all that annoying checking of changed headings in name-title forms, and with added subject subdivisions). It's like the last mile in broadband connectivity. Fast fibre optic everywhere except when one gets closer to home where antiquated technology slows things done. It would be wonderful if everything works perfectly *right now* but it emphatically does not work as simply as you suggest. It's only when data is modelled out thoroughly and correctly that we can start talking about new functionality. An example is the Item-level functionality in the latest library systems I've worked with. Holdings displays can be finetuned based upon user location and item availability attributes. This saves the user time by showing the user holdings with priority ranking based upon library branch location and item availability. This "functional requirement" based upon "user tasks" is done first by data modelling (quite likely, based upon the database fields involved, by asking for instance: what entities do I need (item, branch, workstation), what attributes do I need (item availability status), and what relationships do I need). And this is popular, and would be emphasized on any RFP for a system. It would be wonderful if the functionality could be extended more deeply, showing the user for example, related works that are actually available in the library based upon the relationship clustering inherent in FRBR. We see something similar with the integration of the NoveList readers' advisory service in the catalog. The linking is done by manifestation identifier (ISBN), but this is crude, because different manifestations (U.S., Canada, UK publishers), and different expressions (e-book, audiobook) can be missed. We see similar issues with the new ebook interfaces with the various new ebook services we're promoting. The ebook services are not that great for searching-- as the collection gets larger, the weaker the tool becomes. The MARC records having the highest quality data, but the catalog records are missing the item-level attributes found only in the ebook service interface. In addition, changes to manifestation level details such as DRM changes and format changes (MP3 vs WMA) are better handled in the ebook service. The bulk of the staff time nowadays in helping people with e-books goes to manifestation selection details with the all different confusing formats, and well as assistance with the system requirements of the different intermediary devices. The more explicit and better arranged the data, the easier it is on staff and endusers. But even outside of all the new technology like e-books, library users can still be very insistent on specific aspects that relate to the different FRBR bibliographic levels. Last week, a library user I dealt with was absolutely insistent on getting a book-on-tape version of a title (our collection is dwindling and being replaced by books-on-CD, e-audiobooks, and Playaways). But there's no harm in promoting the other formats-- the library is there to help in getting people set up with the different formats. I recall the library user who absolutely wanted Seamus Heaney's translation of Beowulf and not any other translation. Unfortunately, our ephemeral paperback collection is not given the full cataloging treatment, and after wasting the patron's time, it turned out we didn't have an available copy. Good data input up front saves everyone time down the road. Some library users don't really care about the format details for what they're after. Other library users are very particular, and can be quite canny in figuring things out, and be quite vocal about system functionality. And other library users are quite pleased when they discover new things while searching for something else-- such as different formats, and different expressions (we recently got in some wonderful new Shakespeare play expressions and adaptations, based upon different vocabulary levels, graphic novel versions, side-by-side renderings with modern English, etc.). Staff are always requesting that "at-a-glance" kind of functionality in the catalog, rather than having to examine each record in detail. The more element-based the data is, and the more tabular it is, and the more groupings and relationships are shown clearly (and we have a quasi-FRBR-like breakdown already in the title browse index), the happier everyone is. And with most popular items checked out at any point in time, such as DVDs and bestsellers (there's lots of great stuff not in e-book format), the catalog is the ONLY mechanism endusers have to find, identify, select and obtain what they want, so the more functionality based upon cleanly delineated data, the better. Even with e-books, holds are often still necessary, and that can only be done in a discovery layer of some sort. Thomas Brenndorfer Guelph Public Library
