Thank you so much; this is very clear and helpful. I think your response
also crystallizes the problem many have with RDA. That is to say, your
explanation is at the level of the model and is of very little use to
someone who is in the process of describing a resource. The information
is there, but is not easily findable by the user. RDA seems somewhat like
most user's manuals, which are generally constructed from the point of
view of what the designer thinks the system should do and not from that of
the user who wants to do something, frequently something quite different.
As I have watched the development of RDA over the last decade or more, it
seems to me that we have watched what was intended as a replacement for
AACR2 become a tool designed to facilitate the interchange of
bibliographical data between different types of platforms by being more
granular and systematic (among other things) in the way data are recorded.
This is a laudable task, even necessary, if libraries are to remain useful
to their community of users. This new task, however, is not what a
cataloging code is designed to do. What RDA may yet end up being is
satisfactory neither to practicing catalogers nor to the systems thinkers
who need to keep our work from being isolated and outdated.
Conceptually, RDA brings many exciting developments or potential
developments to catalogers, such as better ability to identify versions of
works and better abilities to link resources. It would be nice to see a
cataloging code that is understands and uses the RDA framework, but I am
not sure we are there yet.
Larry
--
Laurence S. Creider
Special Collections Librarian
New Mexico State University
Las Cruces, NM 88003
Work: 575-646-7227
Fax: 575-646-7477
lcrei...@lib.nmsu.edu
On Wed, 16 Mar 2011, Brenndorfer, Thomas wrote:
> _______________________________________
> From: Resource Description and Access / Resource Description and Access
> [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod
> [m...@slc.bc.ca]
> Sent: March-16-11 11:51 AM
> To: RDA-L@LISTSERV.LAC-BAC.GC.CA
> Subject: Re: [RDA-L] RDA "draft"
>
> > > If there is a mnemonic feature to RDA numbering, I've not figured it
> > out.
> There is a mnemonic structure to RDA, as well as repeating patterns that
> are very useful to grasp. The logic flows from an entity-relationship
> analysis which should make cataloging data more intelligible to database
> builders. We look at each "thing" -- each entity -- and then we look at
> how they connect together.
>
> The overall structure for all the sections in RDA is:
> 1) entities, which are divided into groups of elements organized by the
> primary user task (identify, select, obtain-- where applicable)
> 2) relationships between those entities
>
> Each group of entities has a General Guidelines chapter, and there is a
> mnemonic structure beginning each section:
> x.0 - Scope
> x.1 - Terminology
> x.2 - Functional Objectives and Principles
> x.3 - Core Elements
> x.4 - Language and Script
> followed by conventions and elements that are common to all the entities
> in the particular section
>
> Each entity follows a pattern where groups of elements are organized by
> user task:
>
> Manifestation& Item
> - elements used to Identify the entity
> - elements used to Select the entity
> - elements used to Obtain the entity
>
> Work& Expression
> - elements used to Identify the entity
> - elements used to Select the entity
>
> Person, Family, Corporate Body
> - elements used to Identify the entity
>
> Place
> - elements used to Identify the entity
>
> For elements used to identify, there are guidelines at the end of each
> respective chapter on how to contruct authorized access points to
> represent those entities. This is quite a change from AACR2, where the
> comparable rules are primarily for constructing "headings". In RDA, the
> individual elements of each entity are reviewed first, and only as a
> secondary step is the construction of headings ("authorized access
> points") brought up.
>
> "Authorized access point" is the common name for headings, and main
> entry strings for works and expressions, which are treated as special
> constructions to represent the entity. "Identifiers" (control numbers,
> URIs, and so) are the other method of representing entities.
>
> So for the task of "identifying" there are three very important
> distinctions that are used in the organization of the respective
> chapters:
> 1) individual elements that help users identify an entity
> 2) identifiers such as control numbers
> 3) authorized access points
>
> This is a useful separation to understand, since it reflects the
> different ways in which we can represent an entity. It doesn't have to
> be an authorized access point (a "heading"). It can be an identifier
> (which works better for machine processing). Or it can be a cluster of
> elements for the Entity grouped together and displayed on the screen as
> such.
>
> For relationships between entities, a similar mnemonic structure occurs
> for the General Guidelines chapter for each set of relationships:
>
> x.0 - Scope
> x.1 - Terminology
> x.2 - Functional Objectives and Principles
> x.3 - Core Elements
> x.4 - Recording Relationships (the conventions used to represent
> entities in the relationship elements)
>
> followed by additional conventions and elements that are common to all
> the relationships in the particular section, including
> x.5 - covers Relationship Designators, which are listed in full in the
> Appendices
>
> All relationships follow a basic pattern:
>
> Element for relationship + Convention used to represent Entity +
> Optional Relationship Designator
>
> Example for relationship between Work and Person entities:
> Element -- creator
> Value -- Hemingway, Ernest, 1899-1961 [convention used is "authorized
> access point"]
> Designator -- author
>
> Example for relationship between Work and Work entities:
> Element -- related work
> Value -- Curriculum report (Reston, Va.) [convention used is "authorized
> access point"]
> Designator -- absorbed
>
> Example for relationship between Person and Corporate Body entities
> [Corporate Body is "Miles Davis Quartet"]:
> Element -- related person
> Value -- Davis, Miles [convention used is "authorized access point"]
> Designator -- founder
>
> All RDA relationships follow this basic pattern. These relationships are
> mapped into MARC fields in numerous ways, because MARC uses a large
> variety of conventions to record relationships. RDA, by comparison, and
> once the pattern is understood, uses a very straightforward,
> predictable, and often mnemonic structure.
>
> Thomas Brenndorfer
> Guelph Public Library
>
