CC:DA/TF/FRAD/3
June 13, 2007
page 1 of 24
To: Cheri Folkner, Chair, Committee on Cataloging: Description and Access (CC:DA)
From: Manon Théroux, Chair, CC:DA Task Force to Review the Draft Functional Requirements for Authority Data (FRAD)
Subject: Report on Review of the Draft Functional Requirements for Authority Data (FRAD)
On April 20, 2007, the “Task Force to Review the Draft Functional Requirements for Authority Data (FRAD)” was charged with:
§ Preparing a review of the draft document, for transmittal to the chair of CC:DA by June 12, 2007, so that the CC:DA response could be sent to the appropriate IFLA contact person by July 15, 2007.
§ Preparing an appendix to the report to include issues that may impact rules in AACR2R and/or RDA, if any such issues were discovered during the review.
The FRAD draft, dated April 1, 2007, is available on the IFLA Cataloguing Section’s website: http://www.ifla.org/VII/d4/wg-franar.htm
Task force members included:
Everett Allgood
Sherman Clarke
Kathy Glennan
Robert L. Maxwell
Manon Théroux, Chair
Martha Yee
The task force’s report is organized as follows:
- General Comments on the FRAD Draft (p. 2-4)
- Specific Comments on the FRAD Draft (p. 5-23)
- Appendix: Impact of the FRAD Draft on AACR2R/RDA (p. 24)
I. GENERAL COMMENTS ON THE FRAD DRAFT
§ Title Change:
The task force generally supports the change in title from Functional Requirements for Authority Records (FRAR) to Functional Requirements for Authority Data (FRAD). One member noted the parallel with Diane Hillmann’s discussion of metadata control at the element level. However, the distinction between the two terms (“authority records” and “authority data”) is not clearly articulated in the draft. The “Introduction” instills confusion right from the start by stating that the first “term of reference” for the FRANAR group was “to define functional requirements of authority records” and then stating “this document fulfills” that term of reference (leaving the reader to wonder why the document is called FRAD rather than FRAR). Moreover, some instances of the old “authority record” terminology may still need to be revised to reflect the new title (see comments under “Introduction,” “1. Purpose,” “2. Scope,” etc.).
§ Earlier CC:DA Review of FRAR:
The task force was pleased to note that many of the suggestions for revision made by the CC:DA task force that reviewed the FRAR draft in 2005 have been incorporated into the FRAD draft. However, we were disheartened that the draft did not take advantage of more of the recommendations made by that initial task force. Incorporating some of them would improve the usability and readability of this document immensely (e.g., adding a glossary, using clear and direct language, broadening the scope of the document beyond the library sector, etc.). We have therefore repeated some of the earlier suggestions in this report.
§ Use of Entity-Relationship Model:
The task force questions the extent to which FRAD is truly following the entity-relationship model presented in FRBR. A bibliographic database founded on FRBR entity-relationship principles would contain work entity records, expression entity records, manifestation entity records, item entity records, person entity records, corporate body entity records, family entity records, concept entity records, object entity records, event entity records, etc. These would be linked to each other by different types of relationships. For example, a work entity record for “Romeo & Juliet” would be linked to a person entity record for “Shakespeare, William” through a “created by” relationship link. The name of the person would not be recorded in the work entity record. Therefore, there would be no need for an authority record showing the cataloger the form of the name he or she should use and no need for an authority record with variant name access points because either (under FRBR) these would be recorded as attributes within the person entity record, or (under FRAD) these would all be given their own “name” entity record and linked to the “person” entity record by a “known by” relationship link. In either case, a user would reach the person entity record via any recorded variant to the name. What we now call authority work would continue to be done — in order to create the “person” entity record we would need to do much the same work we now do to create a personal name authority record. But we would not be creating an authority record. FRAD would be a better document if it were conceived of as an extension of the concepts already outlined in FRBR and a working out of the details of how to create a person (etc.) entity record and what to include as its attributes, rather than putting so much in the context of current authority practices. We realize that was what IFLA assigned the Working Group to do in its terms of reference (“define functional requirements of authority records”) but it seems that in a true entity-relationship database environment, we would not have any authority records at all. That said, however, many task force members have a hard time conceptualizing a work entity record that doesn’t contain any information about the author/creator. The relationship link between the work and person entity records would have to be very strong for this model to work. Moreover, it would be essential to have the work entity record display in a meaningful way in a set of search results containing other work entity records. We assume that a properly designed system would be able to display, within the list of search results, those entities that are related to each work entity record, thereby allowing the user to more easily select the desired work entity. We also assume that such a system would permit easy navigation between related entities. We recommend that FRAD be conceptualized more rigorously, that the use of the FRBR entity relationship model be explained more clearly, and that concerns about display, navigation, and the strength of the relationships between entities (especially the name/title relationships that are so useful for unambiguously identifying work entities), be addressed more explicitly.
§ Library-Centrism:
The task force recommends broadening the scope of the document beyond the library sector. The insistence on restricting the scope of this report to the library community seems to deny the reality of today’s globally connected and networked world. The 2005 CC:DA FRAR task force pointed out that IFLA’s own name would appear to condone a broader scope (i.e., International Federation of Library Associations and Institutions). This, coupled with the fact that numerous other cultural institutions such as museums and archives have the same need for authority data and authority control as libraries, provides a strong argument for making this document as accessible as possible to multiple communities. To say nothing of the need for authority control and consistency within the massive electronic databases represented by the Internet.
§ Preferring Different Forms in Different Contexts:
The task force recommends that FRAD more fully explore the idea of allowing different forms (representing different languages, scripts, sources, etc.) for a particular entity to be preferred in different contexts, depending on user needs and preferences. We recognize that complex software might be required to bring this idea to its full fruition. We also recognize that certain vocabularies might present difficulties. For example, users of visual resources might prefer the Getty’s Union List of Artist Names (ULAN) as a source rather than the LC/NAF, but ULAN doesn’t really embrace the concept of a single “heading” in the way that LC/NAF does; rather it identifies “preferred names,” “display names,” “display biographies,” “labels,” etc.:
http://www.getty.edu/research/conducting_research/vocabularies/ulan/about.html
The “preferred name” is typically in inverted form, with last name first, and is the name appropriate for use in alphabetical lists. The “display name” is the preferred name in natural order, to be used in wall labels and other displays. A “display biography” comprises the artist’s nationality, role, and dates; one of the display biographies can be designated as “preferred.” The “label” form is a combination of preferred name plus preferred display biography and serves as an easily legible heading to identify the artist for end-users. How would the ULAN data elements be expressed in the FRAD model?
§ Motherwell, Robert = LC/NAF established heading
§ Motherwell, Robert = ULAN preferred name
§ Robert Motherwell = ULAN display name
§ (painter, printmaker, and author, 1915-1991) = ULAN preferred display biography
§ Motherwell, Robert (American painter, printmaker, and author, 1915-1991) =
ULAN label
§ Language/Style:
The task force found many of the sentences to be long and filled with casual asides and verbose phraseology, requiring constant re-reading. This problem could easily be remedied via a strong editor or technical writer.
§ Use of Examples:
The task force recommends specifying explicitly that the examples used in FRAD have been drawn from multiple sources and represent standards associated with different countries, institutions, rules, etc. We also appreciate the use of detailed examples in section 5 and wonder if adding some generic examples in section 3 (near figures 1 & 2) might be helpful.
§ Glossary:
In its 2005 review of FRAR, the CC:DA task force emphasized the need for a glossary; we reiterate that sentiment in our review of FRAD. A glossary would be significantly more useful than having various specialized definitions buried within the text itself. We realize that FRBR does not have a glossary and that FRAD considers itself a parallel, or perhaps pendant, publication to FRBR. However, FRBR is written much more clearly (and conceptualized much more thoroughly) than FRAD. Any document that uses common terms in the very specific ways that this document does requires a glossary.
II. SPECIFIC COMMENTS ON THE FRAD DRAFT
Table of Contents
§ Duplicate pagination: Both the t.p. and the first page of the “Contents” section are numbered “i”.
§ Unconventional pagination: The odd-numbered pages appear on the verso of the leaves; the standard convention would be to have them appear on the recto.
§ Inconsistent use of punctuation: The periods at the end of 3.3. and 5.3.3. should be deleted (and the same correction made within the body of the text on p. 3 and p. 35).
§ Inconsistent use of spacing: 5.3, 5.4, and 7.4 all need an extra space inserted after the number (and the same correction made within the body of the text on p. 31, p. 42, and p. 61).
§ Inconsistent use of grammatical number: In section 5, each of the relationship “types” listed are plural with two exceptions: 5.4.1 and 5.4.3. Was that intentional or a typo? There are multiple examples of these relationship types in each of these sections, so it would seem they should be plural (and the same correction made within the body of the text on p. 43 and p. 45).
Introduction
§ 2nd paragraph, 1st line:
The phrase “terms of reference” is somewhat opaque; are these “goals”? a three-part charge? something else?
§ Terms of reference #1 and #2:
Change “authority records” to “authority data” to fit with the new title? Or is the language straight from the FRANAR charge and thus not considered flexible?
§ Term of reference #1:
Shouldn’t the phrase “Functional requirements of bibliographic records” be “Functional requirements for bibliographic records”?
§ Term of reference #2:
The bullet is a run-on sentence (and needs to be stated more clearly).
§ Penultimate paragraph, 1st line: The title Functional Requirements for Authority Records should be changed to Functional Requirements for Authority Data
1. Purpose
§ p. 1, General comment: Some found sections 1 and 2 (“Purpose” and “Scope”) difficult to understand and filled with multiple terms seemingly intended to mean the same thing. (This of course is particularly ironic within a document addressing authority control). Nowhere is there a clear, concise statement introducing the title term “Authority Data.” The task force suggests that a much clearer first paragraph under “Purpose” would read something along these lines:
A catalogue is a set of organized data describing the information content managed by an institution. Authority data represents the controlled access points institutions use to collocate works by a specific person or corporate body, or the various editions of a title. Controlled access points include authorized forms and variant forms assembled by cataloguers to identify an entity. For the purposes of this study, only name and title entities are addressed; however, subject terms within catalogues are among the other entities commonly subjected to authority control. Authority control, which means both the identification of entities represented by controlled access points and the ongoing management of them, is integral to the functioning of a catalogue. Authority control is beneficial to cataloguers able to identify and distinguish between the controlled access points within a catalogue. More importantly, authority control benefits end users able to search any controlled form of an author’s name or of a title to retrieve these resources within catalogues.
§ p. 1, 1st paragraph: The use of “author” and “works by …” is unnecessarily restrictive here. Users aren’t interested simply in works “by” a person or body, but also works associated with them for various other reasons (that’s why we have relator terms!).
§ p. 1, 2nd paragraph: Use of “analytical” and “analysis” in one sentence is redundant.
2. Scope
§ p. 1-2, General comment: The 2005 CC:DA FRAR task force provided specific language to clarify the “Scope” section of this document. While it appears some of that language may have been incorporated, the CC:DA replacement text seems far clearer than the current 2007 draft text. Scope could start as follows (note that it seems not possible to use the word “entity” at this point because it is specific to FRAR and FRBR):
For the purposes of this study, an authority record is defined as the aggregate of information about a person, family, corporate body or work whose name is used as a controlled access point for bibliographic citations or records in a catalogue or bibliographic file. Conventionally authority data are structured in accordance with guidelines and specifications such as those set out in IFLA’s Guidelines for Authority Records and References (GARR). The authority record normally contains the authorised form for the controlled access point as established by the cataloging agency, as well as variant forms and related forms also used as controlled access points. The authority record will also normally include information identifying the rules under which the controlled access points were established, the resources consulted and the cataloguing agency responsible for establishing the controlled access point. For the purposes of this study, however, there are no a priori assumptions made about the physical structure of authority data, nor are there any assumptions made as to whether the data are stored in an authority file that is separate from the catalogue or bibliographic file per se, or fully integrated with it. At a high level … [Note: Underlined terms above were then intended to be included in the proposed Glossary.]