> -----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: August 6, 2011 11:05 AM
> To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> Subject: Re: [RDA-L] Completeness of records
>
> James said:
>
> >The simple fact is: it is very difficult to claim on the one hand that
> >the tasks users need to be able to do are defined by FRBR, i.e. find,
> >identify, etc. *works, expressions, manifestation, and items* and they
> >say that the uniform titles are not needed. FRBR is absolutely based
> on
> >the uniform title to bring everything together.
>
> But smaller libraries don't *have* expressions in other languages to
> "bring together* with the English or French version they have.  I
> wonder how many larger libraries have multple translations for very
> many works?  We are creating an elaborage structure for a minority of
> library holdings, in a minority of libraries.
>


Even for small libraries, the number of different expressions is growing 
because of the explosion in different formats, such as e-books. Our Polaris 
system has a quasi-FRBR breakdown of different formats under each title in 
browse lists, and that feature has grown so much that nearly every screen now 
has some titles that are broken down by expression.

Where timely service is good customer service, this kind of functionality is 
essential for busy libraries, and that is why that function is popular.

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. The 
report points to problems resulting from simple concatenation or appending of 
elements creating implicit relationships, layering in of elements, and using 
notes instead of machine-friendly mechanisms when the data is explicit.

It's only by stating up front what we want to say about the logic in our data 
that we can escape those straitjackets that FRBR identifies. It's only by 
building upon the logical levels so identified that we can create and move to 
mechanisms that satisfy the needs of library users. We shouldn't confuse a 
convention (a 240) that's so tied to display and card catalog functionality 
with the underlying logic represented by that data-- logic if properly encoded 
could be as flexible as we want, and is now quite capable of being achieved 
because of the improvements in technology and relevant technical standards.

That's far better than chopping up records, destroying underlying logic, 
haphazard shoehorning into quirky systems, saying we don't need functionality 
because it messes up the display in one particular application or is not used 
today because the library system of today is lacking tomorrow's features.

Thomas Brenndorfer
Guelph Public Library

Reply via email to