The Library of Congress >> Especially
for Librarians and Archivists >> StandardsThe Library of Congress >> Especially
for Librarians and Archivists >> Standards
HOME >> MARC Development >> Discussion Paper List
DATE: December 14, 2007
REVISED:
NAME: Encoding RDA, Resource Description and Access data in MARC 21
SOURCE: Joint Steering Committee for Development of RDA (JSC)
SUMMARY: This paper discusses the issues related to encoding RDA using MARC 21. JSC is presenting these issues for consideration and direction regarding what changes may be required to MARC 21 Bibliographic and Authority formats to encode RDA data.
Three appendices are included with the discussion paper:
KEYWORDS: RDA (BD) (AD); Resource Description and Access (BD) (AD)
RELATED:
STATUS/COMMENTS:
12/14/2007 - Made available to the MARC 21 community for discussion.
02/14/2008 - Results of the MARC Advisory Committee discussion
At the 2007 Midwinter MARBI meeting, MARBI discussed the report "RDA and MARC 21". This report was intended as an "early alert" to areas that might require the attention of the MARC community. Significant effort has been expended over the last year on content development as well as on the articulation of the framework and scope for the development of RDA. With the first release of RDA scheduled for early 2009 and an anticipated implementation date of late 2009, this discussion paper raises a number of issues that may signal change for MARC 21.
While RDA will support all three of the database structure scenarios described in RDA database implementation scenarios [PDF Document; 54.44 K], a scenario 2 implementation (linked bibliographic and authority records) is assumed for the initial release of RDA in 2009. The JSC, therefore, recommends that a scenario 2 database structure frames the discussion of the issues and potential changes to MARC 21 outlined below.
The primary objective of this paper is to reach agreement on which changes to MARC 21 MARBI considers desirable and feasible for the implementation of RDA in 2009.
The JSC encourages MARBI to review the following key background documents which have been used in developing this discussion paper:
Scope of RDA
RDA provides a set of guidelines and instructions on formulating data reflecting entity attributes and relationships to support the FRBR user tasks (find, identify, select, and obtain) and FRAD user tasks (find, identify, contextualize, and justify) for resource discovery. RDA is aligned to the FRBR and FRAD conceptual models and strives for the provision of consistent metadata across all types of resources. RDA also functions as a metadata element set, similar to the Dublin Core Metadata Element Set. In addition, the data created using RDA is designed to function within a wide range of database structures (from "flat file" databases through to relational/object oriented databases).
At its October 2007 meeting, the JSC agreed to a restructuring of RDA (www.collectionscanada.ca/jsc/rda-new-org.html) that further emphasizes the alignment of RDA to FRBR and FRAD and more clearly supports a relational/object-oriented database structure.
Note: The references to RDA instructions in this paper and in the mapping do not reflect the new RDA structure. Unless otherwise noted, the RDA instruction numbers given below reflect the December 2005 draft (chapters 2,4,5), March 2007 draft (chapter 3, Addendum to chapter 4), and June 2007 draft (chapters 6, 7). Instructions flagged with "Editor's draft" are not available on the JSC Web site.
Three new elements are defined in RDA to replace AACR2's general material designation. The RDA elements (media type, carrier type, and content type) categorize resources differently than MARC 21.
With the support of LC's Network Development and MARC Standards Office, work is underway to review the RDA/ONIX framework against MARC 21 data. Following completion of this work, MARBI will be asked to consider what changes might be required to the bibliographic format.
An element in RDA has been defined to signal mode of issuance. The RDA element Mode of issuance contains the following terms:
MARC 21 Leader/07 (Bibliographic level) contains values for Serial (code s) and Integrating resource (code i), the value for Monograph (code m), covers both single units and multipart monographs. It is acknowledged that Leader 07 is used extensively in processing bibliographic records and is used to determine which 008 field corresponds to the resource. In addition, because the RDA element comprises a controlled list, the issues raised at 3.1 above are relevant to the discussion of Mode of issuance.
Options
An element in RDA has been defined to indicate the script used to express the language content of the resource. Inclusion of Script as an element will allow users to select a resource that they can read. The script is not always obvious from the language, for example, Sanskrit, Kashmiri, Mongolian, and Inuktitut are among the languages that can be written in more than one script. The draft RDA instruction is provided below:
Although field 008 character position 33 is used to indicate the script of the title for continuing resources and field 008 character positions 35-37 and field 041 identify the language of the resource, MARC 21 does not provide coded data for scripts.
Options
RDA has defined separate elements for production, publication and distribution; each element has separate sub-elements for "place of publication", "publisher's name", and "date of publication".
Note that production statements in RDA include statements relating to the inscription, fabrication, construction, and/or manufacture (printing, duplicating, casting, etc.) of a resource. Producer in MARC 21 is strictly associated with film-making.
MARC 21 field 260 currently uses the same subfields for publication and distribution data (260 $a, $b and $c). Subfield $b may be qualified to provide an indication of function (i.e., [distributor]). MARBI may wish to consider if there is a need to distinguish between publication and distribution data through MARC 21 content designation.
Options
RDA contains a separate element for copyright date. In MARC 21, the copyright date is recorded in field 260, subfield $c (date of publication, distribution, etc.) preceded by the lower case c, or for sound recordings, or lower case p. (In RDA, copyright and phonogram symbols will be recorded.) MARBI may wish to consider whether there is a need to have specific content designation for the copyright date.
Options
The RDA element for numbering of serials includes separate element sub-types for:
This will support total flexibility with regard to what is displayed and how the element sub-types are displayed (i.e., formatted or unformatted).
These RDA element sub-types can be mapped to MARC 21 field 362, subfield $a. While it is acknowledged that the benefit of defining separate content designation is questionable, the option is provided below for MARBI's consideration.
Options
The mapping has highlighted a number of elements for which a clean mapping is not possible due to the different levels of granularity in RDA and MARC 21. Appendix 2 [PDF Document; 39.38 K] identifies a significant number of instances in RDA where an element can be recorded using unstructured data; this unstructured data maps only to the MARC 21 field 500 (General note) or field 300, subfield $b (Other physical details).
See RDA 3.6, 3.7, 3.8, 3.9, 3.11, 3.12, 3.15, 3.17, 3.18, 3.20 in the Appendix 2 [PDF Document; 39.38 K] mapping for examples.
Question for discussion
Generally, a label can be generated from the RDA name and definition of the element and, therefore, the explicit label does not have to be carried as part of the data. When such data is encoded in MARC 21, the formats provide for display constants using a range of techniques (a display constant indicator, subfield $i, subfield $z or the name of the content designator itself, e.g., $x ISSN) to generate the appropriate label.
There are instances when labels for RDA elements may not be supported by MARC 21.
RDA includes the following dissertation information: academic degree, granting instutition or faculty and year degree granted.
Because the RDA element name carries the label (i.e., the word "Thesis" is not included in the data to be recorded), a display constant indicator may need to be defined in field 502 to ensure that RDA data is meaningful when encoded in MARC 21. Although the MARC 21 field name could generate the appropriate label, field 502 carries a range of information related to theses and consequently, it may not be appropriate to generate the display constant in all cases.
Options
Because the RDA element names carry labels (i.e., the words, "Performers", "Narrators", and "Presenters", are not included in the data to be recorded), display constant indicators may need to be defined in field 511 (Participant or Performer Note) to ensure that RDA data is meaningful when encoded in MARC 21.
Options
Because the RDA element name carries the label (i.e., the word "Scale" is not included in the data to be recorded), a display constant indicator may need to be defined in field 255 (Cartographic Mathematical Data) and field 507 (Scale Note for Graphic Material) to ensure that RDA data is meaningful when encoded in MARC 21.
Options
Because the RDA element name carries the label and is not included in the data to be recorded, a display constant indicator may need to be defined in field 538 (Systems Details Note) to ensure that RDA data is meaningful when encoded in MARC 21.
Options
In order to identify records created following RDA, JSC requests that the following values be defined:
The value for RDA would identify records described using RDA.
The value for RDA/ISBD would identify records that satisfy the ISBD punctuation guidelines (as provided in an RDA appendix).
The document RDA database implementation scenarios [PDF Document; 54.44 K] describes three scenarios for RDA implementation. Most institutions planning for the transition from AACR2 to RDA will have a database structure that conforms to scenario 2 or 3, or a combination thereof.
Scenario 2 describes a linked bibliographic and authority record database structure. Access points in the bibliographic record are linked to controlled headings in the authority file. Copy specific information is held in linked holdings and/or item records.
Scenario 3 describes a flat structure. Access points stored in the bibliographic record are not linked to the authority file. Copy specific data are held in the bibliographic record.
Scenario 1 describes a relational/object-oriented database structure that is consistent with the FRBR model. In scenario 1, data elements reflect FRBR primary entities: works, expressions, manifestations, and items. Data elements used for access point control are stored in authority records. Relationships between the primary FRBR entities are reflected through links. Scenario 1 cannot be supported by MARC 21 as currently defined.
MARBI previously discussed accommodating FRBR in MARC 21 in a report entitled Using MARC 21 with FRBR: Record Configurations [PDF Document; 235.67 K]. This report presented two models for accommodating work/expression records. For the purpose of this discussion paper, the focus should be on what changes would be required to fully support a scenario 2 implementation.
Question for discussion
In RDA, chapters 6 covers relationships between FRBR Group 2 and Group 1 entities and chapter 7 covers relationships between FRBR Group 1 entities. The mapping of RDA relationships to MARC 21 have identified a number of issues. Note that JSC has not yet reviewed constituency responses to RDA chapter 7. The mappings for chapter 7 in Appendix 1 provided with this discussion paper should be considered as provisional.
JSC is developing a controlled list of types of relationships to designate relationships between FRBR Group 1 entities (e.g., work-to-work, expression-to-expression). This list will be shared with MARBI when it is available.
Question for discussion
RDA chapter 6 defines the relationships between the resource described and persons, families, corporate bodies associated with the resource (e.g., creators, contributors, publishers, custodians). In order to comply with RDF-DCMI syntax requirements, designations of role and relationship will be treated as sub-elements in RDA chapters 6 and 7. It is assumed that the role or relationship at the element level will be identified explicitly as part of the encoding syntax, and, therefore, no additional role designation is required. This means that RDA elements with role implicit (e.g., creator, contributor) will not also have a role designation in RDA. In addition, different designations must be given if a similar role exists at two levels (e.g., compiler as creator and as contributor).
Because the existing MARC 21 relator term list does not make the hierarchical relationships between roles explicit, using this list for role information in RDA data would increase the complexity of mapping RDA to an RDF-DCMI-compliant syntax. JSC is developing a separate list to be included in an RDA appendix. When this list is available, MARBI will be asked to consider what changes may be required to the MARC relator codes.
Question for discussion
RDA chapter 7 specifies a number of techniques for recording relationships. One of these techniques is using identifiers to record relationships. MARBI Proposal 2007-6/1, approved by MARBI at the June 2007 meeting, specifies the option to use subfield $0 to record the authority record control number in access points in the bibliographic record. MARC 21 already supports the use of subfield $w in linking fields to identify a related bibliographic record.
Question for discussion
Appendix 2 [PDF Document; 39.38 K] provides a mapping of RDA elements in chapter 3 (Carrier) for which there are controlled lists of values to the corresponding field in MARC 21, and lists the values defined in both RDA and MARC 21. The terms provided in RDA are derived from a number of sources: MARC 21 code lists; AACR2 lists and examples for physical description data, lists and examples for type and form of carrier in 5JSC/Chair/6/Chair follow-up GMD/SMD Working Group: Proposal for Content and Carrier Terms in RDA, ONIX code lists and other sources such as the ALA Glossary of Library and Information Science and Cataloging Cultural Objects.
One of the outcomes of the RDA/DCMI Data Model meeting was agreement that RDA and DCMI should work together to disclose RDA value vocabularies using RDF/RDFS/SKOS. After RDA value vocabularies have been registered, if data encoded in MARC 21 is being exported or exposed as RDA data in an RDF-compliant schema, only those values that match RDA values could be identified using the URI for the RDA vocabulary encoding scheme. Any non-aligned values would have to be encoded simply as "plain" values with no vocabulary encoding scheme identified, unless the MARC 21 values were registered as a value vocabulary (in which case the URI for the MARC 21 value vocabulary would be used).
Question for discussion
3.12.1 JSC has agreed that an appendix for "data about data" would be developed for the first release of RDA. As expressed by the Editor at the April 2007 JSC meeting, "...these would be "free-floaters" and could be added to any element, in a similar way to DC refinements." (April 2007 JSC meeting minutes, 156.4.2)
The appendix for "data about data" has yet to be developed as the JSC has not identified all instances of "data about data". Because "data about data" pertains to the element, accommodation in MARC 21 would be required at the field level.
3.12.2 RDA 1.6 provides instructions to transcribe an element as it appears following guidelines for capitalization, numerals, etc. Alternatives have been included to provide some flexibility by allowing elements to be transcribed according to in-house manuals/published style manuals or by accepting the element as derived from a digital source using an automated scanning, downloading or copying process. MARBI may wish to consider whether there is a need to distinguish different approaches to recording data.
3.12.3 RDA has elements that are recorded using terms for an English language context, e.g., publisher not identified. It may be useful to identify such elements through MARC 21 coding. This could facilitate the reuse of records internationally by enabling terms recorded for one language context to be replaced by terms for a different language context.
It has been widely acknowledged that the convention of using square brackets to identify supplied data or corrected data is not understood by users. The number of instances where square brackets have been previously called for is reduced in RDA. There are two different situations when a convention may be needed to indicate supplied data: (1) identifying when an entire element or sub-element has been supplied; (2) identifying when only a portion of the data within an element or sub-element has been supplied. For the second situation, square brackets will continue to be used.
JSC requests that MARBI consider defining coding (e.g., control characters) to identify when an entire element or sub-element has been supplied. Such coding would eliminate the need to use square brackets to identify supplied entire elements or sub-elements.
RDA has been designed to establish a clear separation between the presentation and recording of data. Guidelines for presenting RDA content in MARC 21 and ISBD displays (including punctuation) will be given in an appendix.
It is assumed that MARC 21 documentation will continue to provide guidance on punctuation and that those input conventions would be considered as an "add on" to the instructions in RDA for recording the data for the element.
All of the element names and instruction numbers referred to in this section are those used in the Editor's drafts of RDA sections 2, 3, 4 and 9. The drafts for constituency review are scheduled for release in December 2007. As these sections have not yet been reviewed by the RDA constituencies, this part of the discussion paper serves as an early alert to the MARC community: both the instruction numbers and the scope of these elements may change. Appendix 3 contains a list of proposed RDA elements. A mapping to MARC 21 has not yet been done.
RDA reflects attributes and relationships as defined by the Functional Requirement for Authority Data (FRAD) in support of four user tasks: find, identify, contextualize, and justify.
In the RDA chapters that cover identifying attributes for person, family, corporate body, work, and expression, certain elements can be recorded either as part of the access point representing the entity or as separate identifying elements.
In RDA, the preferred access point is constructed using the name and/or title plus additional identifying attributes, as appropriate. These additions correspond to FRAD attributes of a person, corporate body, etc. For personal names, elements considered as additions are: Title or other designation associated with the person, Date associated with the name, Fuller form of name. The question arises as to whether these RDA elements need to be separately designated from their use as part of an access point.
As with bibliographic data, there are a number of elements for which a clean mapping is not possible due to the different levels of granularity in RDA and MARC 21.
For example, MARC 21 has defined 100 subfield $d as "dates associated with a name". RDA defines specific elements for date information:
In addition, the alignment with FRAD has introduced a number of new elements which have not been formerly included in authority data formulated according to AACR:
Examples include:
A decision will be required regarding the need to define specific content designation or whether such elements can be recorded in unstructured notes (e.g., field 667 Nonpublic General Note, field 678 Biographical or Historical Data Note, field 680 Public or General Note) in MARC 21.
RDA element Content type (RDA 4.2) is also used as an attribute of expressions (RDA 6.11). RDA values for Content type could be recorded in subfield $h (medium) when they are used as additions to an access point representing an expression. There would still be a need for content designation to accommodate Content type as an element independent of its use as an addition to an access point.
Technique (RDA 6.15), defined as an attribute of an expression, is the method used to create a graphic image (e.g., engraving) or to realize motion in a projected image (e.g., animation, live action). There is no place in the MARC 21 authority format to record this data.
HOME >> MARC Development >> Discussion Paper List
| The Library of Congress >> Especially
for Librarians and Archivists >> Standards ( 09/01/2011 ) |
Legal | External Link Disclaimer | Contact Us |