rda-l  

Re: [RDA-L] Time and effort

Brenndorfer, Thomas
Thu, 02 Sep 2010 08:05:02 -0700

> -----Original Message-----
> From: Resource Description and Access / Resource Description and Access
> [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Mike Tribby
> Sent: September 2, 2010 10:32 AM
> To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> Subject: Re: [RDA-L] Time and effort


> At one point long ago RDA was going to be a less structured overview of new
> rules which would then be formulated along FRBR lines and defined by the
> communities that do the cataloging for the various formats. Then RDA
> dribbled over into defining how descriptive cataloging should be composed.
> I think Karen Coyle's recent comment about separating RDA as data model
> from RDA as cataloging rules gets to the pith of the issue. RDA as data
> model is an obvious improvement. RDA as cataloging rules is not, though
> it's probably not the end of the cataloging world as we know it. IMNSHO, of
> course.
>


I don't think that reflects the history of RDA, which is captured in many 
documents at http://www.rda-jsc.org/docs.html. It began as AACR3, with the 
objectives of incorporating content/carrier distinctions and better collocation 
for varying formats, authority record rules, and FRBR terminology. Access 
points were then reworked as types of relationships. Finally, in 2007, the full 
FRBR model was followed, with an organization into entities, attributes and 
relationships.

Many AACR2 conventions about transcribing and recording information were 
carried forward, and I've seen a lot of criticism about that. RDA development 
was then linked to the Dublin Core Metadata Initiative, which is the source of 
the RDA element set in the RDA Toolkit.

The three implementation scenarios for RDA 
(http://www.rda-jsc.org/docs/5editor2rev.pdf) capture the scope of what RDA is 
intended for-- a standard that bridges multiple scenarios. I would say it's 
suitable for the MARC and card catalog scenarios, but more needs to be done for 
the ultimate goal-- the relational/object oriented model. In that final 
scenario, I can see where further refinement of the metadata organization would 
be beneficial. But that would still all appear as a formalized, theoretical 
construction to any typical end user. I think we still need that foundation to 
design effective user interfaces (where effective doesn't mean lowest common 
denominator, i.e. whatever "intuitive" and "less structured" means in the 
context of reading books-- a learned and highly structured skill).

Thomas Brenndorfer
Guelph Public Library