I will keep this just to make sure I am not going crazy
I have been reading RDA and I am now in chapter 6 and while it is supposed
to be very logical, I don't understands why the composition of preferred
entries for librettos comes after their construction as variant entries to
operas, etc.
It is not clear to me why we can't combine choosing elements and
constructing elements in part of RDA instead of splitting them.
On Wed, Mar 16, 2011 at 12:47 PM, Brenndorfer, Thomas <
tbrenndor...@library.guelph.on.ca> 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
>
--
Gene Fieg
Cataloger/Serials Librarian
Claremont School of Theology
gf...@cst.edu
