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 20, 2013
REVISED:
NAME: Recording RDA Relationship Designators in the MARC 21 Bibliographic and Authority Formats
SOURCE: Canadian Committee on MARC (CCM)
SUMMARY: This paper presents options for recording RDA relationship designators in the Bibliographic and Authority formats to ensure that user-friendly versions of the designators will be available for public display.
KEYWORDS: Relationship designators (BD, AD); Constrained relationships; Unconstrained relationships; RDA Appendix I; RDA Appendix J; RDA Appendix K; RDA; Resource Description and Access
RELATED: 2009-DP01/2; 2013-DP04
STATUS/COMMENTS:
12/20/13 – Made available to the MARC community for discussion.
01/25/14 – Results of MARC Advisory Committee discussion: The Committee preferred option 1, mentioned in section 4.1, which would not require a change to the format. Local guidelines or best practices developed by local institutions or co-operative programs would advise to not display the parenthetical qualifiers to the public. In light of the possibility of using URIs to record relationship designators, the committee preferred to defer further examination of the changes discussed in section 4.2.
Appropriate mechanisms for recording the RDA relationship designators found in RDA Appendices I (Relationships between a Resource and Persons, Families and Corporate Bodies associated with the Resource), J (Relationships between Works, Expressions, Manifestations and Items) and K (Relationships between Persons, Families and Corporate Bodies), have previously been discussed in the RDA MARC Working Group's Discussion Paper 2009-DP01/2 and in Discussion Paper 2013-DP04 presented by the Canadian Committee on MARC. The outcomes from the January 2013 meetings requested a follow up paper to explore finding a place for user-friendly labels for relationship types as well as for codes designating the relationships precisely. The discussion was also to be broadened to include relationship designators from all relevant RDA appendices and all relevant MARC 21 fields in both Bibliographic and Authority formats.
As relationship information is an important part of navigation in the catalog, enabling users to find the resources they seek, it is desirable to find a mechanism that enables a user-friendly method of displaying the text of the relationship designator, while at the same time accommodating sufficiently precise information on the relationship to enable intelligent machine-processing in current and future information systems.
Recording a relationship involves identifying the two entities being related (the first being referred to as the “domain” (i.e. used in) of the relationship, the second as the “range” (i.e. expected value) of the relationship) and specifying the precise nature of relationship between them. In RDA, relationship designators are used to identify the precise nature of each relationship. The lists of relationship designators are open and are added to whenever a demonstrated need is expressed. They are of three types, reflecting the three broad categories of relationships that can be recorded.
The terms in RDA Appendix I designate those relationships which have a resource as the domain and a Person, Family, or Corporate Body (FRBR group 2 entities) as the range. The recommended coding of these designators in MARC 21 is to code them in subfield $e (Relator term) of Bibliographic fields 100, 110, 700, 710 and in subfield $j (Relator term) of Bibliographic fields 111, 711. The text in these subfields is normally considered suitable for public display “as is” and is displayed directly to end-users. Presently in RDA only four relationship designators exist in pairs (Work vs Expression):
choreographer choreographer (expression) composer composer (expression) interviewee interviewee (expression) interviewer interviewer (expression)
Codes for relationships can also be recorded in subfield $4 (Relator code) in the same fields; in this case, it is generally expected that the interface will substitute a display constant for the code for the purpose of public display. Recently the MARC relator codes were expanded to include equivalents for RDA Appendix I relationships which did not have codes, with the exception that the expression-level versions of the four relationships listed above were not assigned specific codes. A process is being established to keep the lists in sync.
The terms in RDA Appendix J designate the relationships between a Work, Expression, Manifestation, or Item (FRBR group 1 entities) and a related resource. Many relationships in Appendix J exist at several levels, some of these occur quite frequently. The issue of user-friendly display is most urgent with these relationships. Some examples are given below.
Both Work and Expression:
based on (work) based on (expression)
Both Manifestation and Item:
reproduction of (manifestation) reproduction of (item)
In the MARC 21 Bibliographic format these relationships are currently recorded in several fields. In the case that the relationship is to a Work or Expression, the current practice in the Bibliographic format is to record an authorized access point representing the Work or Expression by using either a name-title construction in fields 700, 710, 711 or a preferred title in field 730, accompanied by a display text for the relationship in subfield $i. Such relationships can also be recorded in the Authority format in fields 500, 510, 511, 530, accompanied by a display text for the relationship in subfield $i.
When the relationship is to a Manifestation or Item, the current practice is generally to record a structured description representing the related Manifestation or Item in a linking entry field (760-787) in the Bibliographic format. The relationship designator is either expressed by the field (or field+indicator combination) or by including a display text for the relationship in subfield $i.
The terms in RDA Appendix K designate relationships among Persons, Families, and Corporate Bodies (FRBR group 2 entities). These relationships are recorded in the MARC 21 Authority format using fields 500, 510, and 511 accompanied by a display text for the relationship in subfield $i. Because of the existing granularity of MARC 21, the precise entities which are the domains and ranges of these relationships is always clear: fields x10 and x11 refer to a Corporate Body; fields x00 combined with indicator 1=3 refer to a Family; and fields x00 with other indicator values refer to a Person. As a result no further action is needed to improve the coding for these relationships and they are not discussed in the remainder of this paper.
As defined originally in FRBR, the relationships among Works, Expressions, Manifestations and Items found in RDA Appendix J, specify the particular WEMI entity that should serve as the domain and as the range of the relationship. As declared in the FRBR namespace in the Open Metadata Registry (OMR), these relationships are termed “constrained” relationships because of this restriction. In RDA Appendix J the use of parenthetical qualifiers to indicate the type of related entity echoes this constraint. Declaring a namespace that does not include any restriction on the type of entity that can be used as the domain or range for each relationship means defining an “unconstrained” namespace. The draft RDA namespace in the OMR includes a set of unconstrained relationships; at its November 2012 meeting the JSC agreed to develop the unconstrained namespace, at its recent November 2013 meeting the JSC considered recommendations to resolve the remaining issues.
A MARC 21 record used in an ordinary un-FRBRized catalog reflects the “resource”, an entity also reflected by an ISBD description. The resource is not merely any one of WEMI, nor is it a superclass of WEMI; however, the combination of attributes of WEMI do describe the bibliographic object which is the resource. Although RDA does not define the term “resource” in exactly the same way as ISBD, in common understanding, each resource includes aspects of WEMI and catalogers use this understanding when cataloging with RDA. Expressing this understanding formally through namespace declaration was elusive until recently. At the IFLA WLIC conference in August 2013 the relevant groups (IFLA Namespaces Task Group, ISBD Linked Data Working Group, FRBR Review Group) approved a paper prepared by Gordon Dunsire entitled: Resource and Work, Expression, Manifestation, Item. The recommendation of that paper was to define in both the ISBD and the FRBR namespaces in the OMR a series of 4 reciprocal relationships to provide the semantic link between the ISBD entity Resource on the one hand, and the FRBR WEMI entities on the other. These relationships are termed “has aspect/is aspect of” and can be concatenated with constrained FRBR relationships to link a resource description to a relationship that specifies the WEMI entity of its domain and/or range.
Although this work is at present done in an IFLA context, the equivalent would hold in an RDA context, permitting the linking of constrained relationships to the resource described in a MARC 21 record. The caveat is that information that is not recorded cannot be extracted by this method.
There are two general routes to consider for recording RDA relationship designators in MARC 21 records.
RDA makes clear in the examples of displays of relationship information in chapters 24-28 that the parenthetical qualifier specifying the WEMI entity which is the range of the relationship is not intended to be displayed to end-users. Thus, a best practice or policy statement for a library RDA profile could specify that only the basic designator text from Appendices I or J is to be recorded in the relevant designator term subfield. This would ensure appropriate public display of the relationships at a level of granularity which is considered relevant for the end-user.
The advantage of this option is that it requires no change in MARC 21 nor in existing systems while still providing user-friendly labels for relationship types. The relationship types can still be mapped to the unconstrained RDA relationship namespaces.
The disadvantage of this option is that the WEMI aspect of the resource taking part in the relationship is not recorded for those relationships which share display labels at different levels. The relationships cannot then be automatically mapped to the constrained RDA relationship namespaces during a migration to a FRBRized catalog. In some cases, this information can be recovered using other aspects of the coding, but not in all cases. However, the cataloger is generally aware of this information at the time of cataloging and could provide it, were there a coding mechanism available for it.
While RDA is presently implemented with existing encoding schemes and generally in un-FRBRized catalogs, preparations are underway for a new bibliographic framework and decisions taken regarding current MARC 21 encoding could prepare for this transition. This option separates display of relationship information for end-users from machine-actionable information, still recording data that could be used to improve FRBRization.
The recommended practice would be to record the unqualified designators in any subfield intended for public display ($i in 760-787, 700-730; $e in 100, 110, 700, 710; $j in 111, 711). In addition, coded information would be recorded in additional subfields indicating the precise entity involved in the relationship. This practice could be restricted to the cases where the unqualified relationship is ambiguous. The interpretation of this data in an un-FRBRized catalog would be possible through a concatenation of relationships. The specific constrained relationship would be concatenated with the “has aspect/is aspect of” relationship which holds between the resource and the WEMI entities.
This issue has little impact with regards to RDA Appendix I designators. In RDA these designators are grouped to reflect the domain of the relationship, which is WEMI, and in any case, only the four relationships listed in section 2.1. involve work-level and expression-level distinctions within the same basic display label.
The advantage of this approach is that information known to the cataloger that will be useful in our future environment is recorded.
The disadvantage of this approach is that additional coding is required of the cataloger, particularly for some frequently occurring relationships found in RDA Appendix J.
Accommodating the coding for Appendix I relationship designators could easily be accomplished by defining specific codes for all relationships and using existing subfield $4 (Relationship code) in fields 700-711 in the Bibliographic format. Subfield $4 is defined to record the “code that specifies the relationship between a name and a work” [by “work” this definition refers to the resource described in the record, not the FRBR entity Work]. It would be necessary to define a code whenever a relationship designator is added to RDA Appendix I.
Bibliographic fields 700, 710, 711 and 730 can be used to record the authorized access point of the range of some Group 1 to Group 1 relationships. Similarly, authority fields 500, 510, 511 and 530 could also be used for the authorized access point of related ranges. There are few available subfields remaining in fields 700-730 in the Bibliographic format and 500-530 in the Authority format. Subfield $7, often used for coded information, is undefined in the 1xx and 7xx blocks in the Bibliographic format (it was recently defined for 8xx only) as well as in the 5xx block in the Authority format. Subfield $7 could be defined either to accommodate MARC 21 codes for RDA Appendix J relationships or as a code for type of related entity.
Possible approaches for accommodating the coding for Appendix J relationship designators in 760-787 fields are given in 4.2.3.1 to 4.2.3.3.
4.2.3.1. Expand the use of 760-787 subfield $4 (Relationship code)
In the 760-787 linking entry fields existing subfield $4 (Relationship code) is defined as:
“Designation in coded form of a relationship between the resource described in the 76X-78X field and the resource described in the 1XX/245 of the record.”Expanding the use of subfield $4 would be possible of if MARC 21 relationship codes were developed corresponding to the relationships in RDA Appendix J.
4.2.3.2. Define a new subfield in 760-787, subfield $j
Another option for the 760-787 linking entry fields would be to define subfield $j (unused except in field 786 which is not used for RDA relationships) for the code representing the Appendix J relationship designators. This will also require definition of codes by the Library of Congress.
4.2.3.3 Redefine 760-787 subfield $7, position 0
Subfield $7 position 0 is currently defined as “type of main entry heading.” If it was agreed by MAC, this position could be redefined as “type of related heading” to provide a place to encode the level of the related WEMI entity.
In BIBFRAME these relationships are handled as follows. The illustrations shown below use the RDF turtle notation. (See Introduction to Turtle used in MAC Papers.)
In the BIBFRAME vocabulary the relationships between cataloging resources and between cataloging resources and names (commonly called roles or relators) such as those in Appendices J and I respectively are accommodated by sets of properties with the "escape" to designate any relationship not specifically provided. This provides flexibility and encourages efficiency in expressing the relationships via URIs for the descriptions of the related resources where possible.
For the cataloging resource relationships the set goes from the most general, relatedResource, to the general (which are essentially the high level relationship categories in the RDA Appendix J (e.g., equivalent, accompanies, precedes, etc.) to a number of specific relationships (series, translation, dataSource, supplement, etc.). The latter includes the specific supersedes and precedes sub relationships used by the ISSN system. Not all of the 300+ and their reciprocals are expressed as properties. All of the included properties efficiently link directly to the URI of the description of the related resource. If a more specific relationship is needed, then the relationship can be expressed in URI or literal form, and the link to the description of the related resource can be specified via the Related class.
work1 a bf:Work;
bf:accompanies <work2 URI>.
work1 a bf:Work
bf:accompanies relationship1.
relationship1 a bf:Related;
bf:relationship "augmented by catalogue";
bf:identifier <work2 URI>.
The relationships between cataloging resources and names as RDA list in Appendix J and the one aligned with it in MARC that also provides codes are similarly expressed as properties with a very general property relatedAgent and three general properties, agent, creator, and contributor, with additional relationships expressed in literal or URI form as above.
work1 a bf:Work;
bf:contributor <URI for illustrator's name>.
work1 a bf:Work
bf:contributor relationship1.
relationship1 a bf:Related;
bf:relationshipID id.loc.gov/vocabulary/relators/ill;
bf:identifier <URI for illustrator's name>.
The relationships between names as exemplified in RDA Appendix K are not currently accommodated in MADSRDF except for the hierarchical relationship hasCorporateParentAuthority.
6.1. Which approach for recording both the specific RDA relationship designators and a user-friendly presentation of those designators is preferred?
6.2. Is it useful to encode the information about the constrained relationship behind the user-friendly display of the relationship designator even in un-FRBRized databases?
6.3. Assuming a positive answer to question 5.2, i.e. it is preferred to record both the information about the constrained relationship, and the user-friendly display of the relationship designator, in current MARC21 for un-FRBRized catalogs:
6.3.1. Is the use of 700-711 subfield $4 the best placement for Appendix I relationship designators?
6.3.2. Are there concerns about using the existing subfield 76X-78X $4 for to-be-established codes for the Appendix J relationship designators?
6.3.3. Are there concerns about using a new subfield 76X-78X $j for to-be-established codes for the Appendix J relationship designators?
6.3.4. Are there concerns about re-defining 76X-78X $7/0 from "type of main entry heading" to "type of related entity" and defining new values? Should the existing values be deprecated, i.e. is anyone using them?
6.3.5. Assuming 700-730 $4 is used for to-be-established codes for the Appendix J relationship designators, and assuming that code list does not include the parentheticals, are there concerns about defining bibliographic 700-730 subfield $7, position 0, for type of related entity
6.4. Does the potential for use of URIs to point to registries of vocabularies suggest a better option?
6.5. Are there concerns about enabling both approaches 4.1 and 4.2 within MARC21?
6.6. If subfield $7 is defined in bibliographic 700-730 and authority 500-530 should it be defined to carry codes for Appendix J relationship designators, or should it be defined positionally as elsewhere, to identify only the level of the related Group 1 WEMI entity?
HOME >> MARC Development >> Discussion Paper List
| The Library of Congress >> Especially
for Librarians and Archivists >> Standards ( 03/06/2014 ) |
Legal | External Link Disclaimer | Contact Us |