It's called voting with your feet. Staff (and many customers of the same software) have had opportunities to work with many kinds of interfaces, including many choices still available within the existing software, including the public version of the catalog.
Staff prefer the tabular result screen for very specific reasons. In the past, staff would scan headings or brief displays and then opt to display a full version of the record. If they're looking for specific sets of records with similar data they would have to spend more time formulating limits for searches and then rebuild the search result each time. If the relevant data was found near the bottom of the record, that would mean staff would have to scroll or scan more data to find the relevant bit. With a tabular search result, every column heading is clickable and the list can be sorted. The range of elements on display cover the majority of fields of interest for staff, and it's just more efficient to work that way. Some elements are variable fields; some are generated off of fixed fields. If anything, staff want more fields to display and more options to customize the display. More recently we've added the feature to convert those tables into tabular displays of all connected item records or all connected authority records. This means that staff are starting to see the benefits of pivoting around key data bits that are freed of rigid displays. There's nothing wrong with having a default public display of data elements. However, having an unlabelled data element like "Edition statement" always in the same spot is not necessarily beneficial. If users have the option they would tend to want to organize tabular displays to suit their regular work requirements and adjust them for specific tasks. It shouldn't matter if Edition statement is in the middle of the table or at the end -- it has its meaning and its purpose for the FRBR user tasks. The way to get that flexibility is to have semantic clarity and consistency with all the data elements, and that means recognizing the limits in AACR2/MARC that were dealt with in RDA. Thomas Brenndorfer Guelph Public Library ________________________________________ From: Resource Description and Access / Resource Description and Access [[email protected]] On Behalf Of Kathleen Lamantia [[email protected]] Sent: June-07-12 1:23 PM To: [email protected] Subject: Re: [RDA-L] Bibliographic records vs. catalogue building "...EMPHATICALLY it is not the preferred format that staff want to work in. Rather staff love the tabular format, where elements are arranged in rows and columns -- fantastic for sorting, fantastic for quickly discerning the nature of the result set." Whose staff? Under what conditions? In one sense, <I> am staff, and I most definitively do NOT prefer tabular format. Is there empirical data to support this contention? Studies, surveys? Kathleen F. Lamantia, MLIS Technical Services Librarian Stark County District Library 715 Market Avenue North Canton, OH 44702 330-458-2723 [email protected] Inspiring Ideas ∙ Enriching Lives ∙ Creating Community -----Original Message----- From: Brenndorfer, Thomas [mailto:[email protected]] Sent: Thursday, June 07, 2012 1:00 PM To: [email protected] Subject: Re: [RDA-L] Bibliographic records vs. catalogue building "How that data is searched is a matter of the ILS, not AACR2 or MARC." The last point is profoundly wrong. Traditional cataloging still assumes a structure dependent on headings to gather related "editions" if you like. The worst mistake is building all kinds of conditional or implicit rules in the layout of fields and having that dominate the logic of what ILS systems can do. FRBR and RDA are explicit as to what the data elements are -- ISBD is one possible resulting display, but EMPHATICALLY it is not the preferred format that staff want to work in. Rather staff love the tabular format, where elements are arranged in rows and columns -- fantastic for sorting, fantastic for quickly discerning the nature of the result set. The main problems arise because of the gummed up displayed forced by ISBD, with sloppy punctuation intruding, or distinctions lost because systems can't filter on both MARC subfields and punctuation. What's has caused poor system design is the inane bridging across different fields (1XX+24X vs 700 name-title) or working with semantically different data elements within a field or even a single subfield!! Thomas Brenndorfer Guelph Public Library ________________________________________ From: Resource Description and Access / Resource Description and Access [[email protected]] On Behalf Of J. McRee Elrod [[email protected]] Sent: June-07-12 11:54 AM To: [email protected] Subject: Re: [RDA-L] Bibliographic records vs. catalogue building Heidrun said: >Correct me if I've misunderstood how Anglo-American catalogs work. I've >just tried it out in your own catalog: Typing in, e.g. "lew tolstoi war >peace" in "keyword" doesn't give me even one edition, let alone all of >them ... This has nothing to do with AACR2 cataloguing, but with ILS search software, which is why we should be developing advanced search capability, not fooling around with catalogue rules and a replacement coding scheme. AACR2 has us describe an edition by transcribing bibliographic data elements as chosen by, and in the order of, the ISBD, adding to that notes, classification, and access points. MARC has us code that information, and add fixed codes (some redundant with present search possibilities). How that data is searched is a matter of the ILS, not AACR2 or MARC. With the end of the card catalogue, too many of us abandoned catalogue construction to computer people, and limited ourselves to under utilized bibliographic record creation __ __ J. McRee (Mac) Elrod ([email protected]) {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/ ___} |__ \__________________________________________________________
