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: May 27, 2016
REVISED:
NAME: Redefining Subfield $4 to Encompass URIs for Relationships in the MARC 21 Authority and Bibliographic Formats
SOURCE: British Library in consultation with the PCC Task Group on URIs in MARC
SUMMARY: This paper discusses the redefinition of subfield $4 (Relator code) in the Address field (371), See From Tracing fields (400, 410, 411, 430, 448, 450, 451, 455, 462, 480, 481, 482 and 485), See Also From Tracing fields (500, 510, 511, 530, 548, 550, 551, 555, 562, 580, 581, 582 585) and $4 (Relationship code) in Heading Linking Entry fields (700, 710, 711, 730, 748, 750, 751, 755, 762, 780, 781, 782, 785, 788) in the MARC Authority Format. It also discusses the redefinition of $4 (Relator code) in Heading fields (100, 110, 111), Subject Added Entry fields (600, 610, 611, 630, 650, 651, 654, 662), Added Entry Fields (700, 710, 711, 720, 751) and $4 (Relationship code) in Linking Entry fields (760, 762, 765, 767, 770, 772, 773, 774, 775, 776, 777, 780, 785, 786, 787) in the MARC 21 Bibliographic Format.
KEYWORDS: Relator code (AD, BD); Relationship code (AD, BD); Subfield $4 (AD, BD); Relator term (AD, BD) ; Subfield $e (AD, BD); Subfield $j (AD, BD); Relationship information (AD, BD); Subfield $i (AD, BD); Authority record control number or standard number (AD, BD); Subfield $0 (AD, BD); Heading Fields (BD); Fields X00, X10, X11 (BD); Field 371 (AD); Address (AD); See From Tracing Fields (AD); Fields 4XX (AD); See Also From Tracing Fields (AD); Fields 5XX (AD); Heading Linking Entry Fields (AD); Fields 7XX (AD); Subject Access Fields (BD); Fields 6XX (BD); Added Entry Fields (BD); Fields 70X-75X (BD); Linking Entry Fields (BD); Fields 76X-78X (BD); URIs
RELATED: 2010-DP02 ; 2016-DP04
STATUS/COMMENTS:
05/27/16 – Made available to the MARC community for discussion.
06/25/16 – Results of MARC Advisory Committee discussion: Concerns were raised over combining two types of data within a single subfield: that is, a code or a URI representing that code within subfield $4. However, it was acknowledged that this approach to recording URIs for relationships was preferable to any of the other alternatives outlined by the paper. It was also agreed that there was no longer a need to maintain the distinction between relator codes and relationship codes in the MARC formats. If URIs are recorded in subfield $4, these may or may not be associated with a MARC code. Therefore, where $4 is currently labeled “Relator code”, it would be appropriate for this to be made less prescriptive by relabeling it “Relationship code” in the future. Likewise, the accompanying definition should be changed, replacing the term “MARC code” with a phrase which references the broader concept of designations in coded form. Those $4 subfields currently labeled “Relator code” could still reference the MARC Code List for Relators as an example of designations in coded form.
The Library of Congress did not agree with the approach of the paper, stating that there is a need for an across-the-board solution for recording URIs for ANY data element in MARC, subfield or field, not an ad hoc solution for one element, such as the one on the table. Given that need, and in order to avoid future confusion, it was recommended that BL and the PCC URI Task Group, in communication with NDMSO, refocus and rework their paper toward a more comprehensive approach to incorporating URIs throughout the MARC Formats.
The paper may return as another discussion paper.
MARC enables relationships to be expressed within and between MARC records. It provides different ways of encoding information about types of relationship. MARC supports the expression of relationships as human readable terms and as coded values. For many of these terms and codes it is possible to record a URI (Uniform Resource Identifier). At present URIs may be recorded for some of the fields in which subfields $e and $j (both labelled as ‘Relator term’), subfield $i (Relationship information) and subfield $4 (labelled as either ‘Relator code’ or ‘Relationship code’) are defined. At present this can only be done using subfield $0 (labelled as ‘Authority record control number or standard number’, ‘Authority record control number’ or ‘Record control number’). However, the present definition of subfield $0 makes no distinction between URIs for the objects of relationships (things) and the relationships themselves. This creates the potential for ambiguity in cases where it is possible to record URIs for both objects of relationships and the relationships themselves in the same subfield string. Consequently, it is desirable to code the URIs for objects distinctly from those for relationships. This paper therefore recommends that the scope of subfield $4 is redefined to allow the recording of URIs for relationships as distinct from subfield $0 which would then be reserved to record URIs for objects.
For many of the relationships which can be recorded in the MARC Authority and Bibliographic formats it is possible to record URIs which support linked data applications. These URIs are available from sources including the Library of Congress’s Linked Data Service and the RDA Registry. It is also possible to record URIs for many of the objects to which these relationships apply. For example, URIs are available from the Virtual International Authority File (VIAF) for names associated with bibliographic entities and for bibliographic works and expressions themselves.
Subfield $0 is defined in many of the MARC fields where it is possible to record relationships and the objects of those relationships. It is defined in fields 5XX (See Also From Tracings) and 700, 710, 711, 730, 748, 750, 751, 755, 762, 780, 781, 782, 785 (Heading Linking Entries) in the Authority format and fields 100, 110, 111 (Headings Fields), 600, 610, 611, 630, 650, 651, 651, 654 (Subject Access Fields) and 700, 710, 711, 730 (Added Entry Fields) in the Bibliographic format. Its scope in both the Authority and Bibliographic formats is as follows:
$0 - Authority record control number or standard number
Subfield $0 contains the system control number of the related authority record, or a standard identifier such as an International Standard Name Identifier (ISNI). The control number or identifier is preceded by the appropriate MARC Organization code (for a related authority record) or the Standard Identifier source code (for a standard identifier scheme), enclosed in parentheses. See MARC Code List for Organizations for a listing of organization codes and Standard Identifier Source Codes for code systems for standard identifiers. Subfield $0 is repeatable for different control numbers or identifiers.
URIs represent one category of the standard identifiers which may be recorded in subfield $0. Because $0 is repeatable in the fields where it is defined, this makes it possible to record multiple URIs as part of a single subfield string. However, the subfield $0 definition does not presently make any distinction between different subcategories of URI. As a result, URIs for relationships and objects of those relationships may be open to misidentification by humans and machines if both types are recorded in the same subfield string.
MARC Discussion Paper 2016-DP04 suggests that subfield sequencing might be used as a means to indicate the portion of a field to which a URI applies. The following example demonstrates how the URI for a relationship might be appended to an equivalent human readable term for that relationship:
700 1# $i Paraphrase of (work): $0 (uri) http://rdaregistry.info/Elements/w/P10186 $a Tippett, Michael, $d 1905-1998.$t Mask of time.
However, in its response to the aforementioned discussion paper, the PCC Task Group on URIs in MARC stated that it “discourages use of subfield sequencing as a mechanism because it complicates programmatic conversion of the data.” In the same response, the Task Group “recommends that $0 be used for URIs that represent THINGs and a different subfield be used to represent RELATIONSHIPS.”
There are several existing subfields other than $0 which might be used to record relationship URIs. For example, both the Authority and Bibliographic formats define subfield $u (Uniform Resource Identifier). In the Authority format this subfield occurs in field 371 (Address), amongst the 36X-38X fields which deal with the characteristics of headings, the 67X (Note Fields) and 8XX (Other Variable Fields). In the Bibliographic format it occurs in field 031 (Musical Incipits Information), amongst the 5XX (Note Fields) and the 8XX (Holdings, Location Alternate Graphics, Etc. Fields). However, for the most part, the scope of $u is confined to recording URIs which provide access to electronic items. The only exceptions are fields 883 (Machine-generated Metadata Provenance) and 884 (Description Conversion Information) in both formats where $u records a URI which identifies the process used for a data conversion.
Besides the issue of scope, there is one of coverage to consider if subfield $u were used for recording relationship URIs. The Authority format does not presently define subfield $u in any of the fields where it is possible to record relationship information. It would therefore be possible to add subfield $u to the 4XX, 5XX (Tracings and References) and 7XX (Heading Linking Entry) fields in order to carry URIs for relationships. However, in the Bibliographic format subfield $u is already defined to carry information other than URIs in the majority of fields where it is possible to record relationships. In the X00, X10 and X11 (Heading Fields) it is used to record affiliations. In the majority of 76X-78X (Linking Entry Fields) it is used to record standard technical report numbers.
Subfield $o (Other Resource Identifier) might also be used to record URIs for relationships. It is currently defined in the Bibliographic format 76X-78X fields. However, the scope of $o in these cases is confined to recording identifiers for physical items. Apart from its scope, the available coverage of subfield $o is also limited with regard to those fields where relationships are recorded. Subfield $o is already defined to record arranged statements for music in the X30 (Uniform Titles), and also amongst the 6XX (Subject Access Fields) and 70X-75X (Added Entry Fields) in the Bibliographic format. In the Authority format $o is also already defined to record arranged statements for music in fields X00 (Personal Names), X10 (Corporate Names) and X30 (Uniform Titles).
Other approaches to recording URIs for relationships could involve the definition of a new subfield $1 or a new field modelled on field 880 (Alternate Graphic Representation). However, MARC Discussion Paper 2010-DP02 notes that these options have already been considered and rejected by the MARC Advisory Committee:
“Previous discussions have suggested defining a new subfield $1 (the only subfield available across MARC fields and formats) for controlled value URIs, but there is no easy way to link them to the subfield(s) to which they pertain. Therefore one would have to rely on subfield sequencing to identify which subfield they relate to. Extensive rules would need to be written to specify subfield sequencing. The automated systems libraries use would need to be able to retain and understand the importance of subfield sequencing. The other suggestion, using a field similar to field 880, which links to another field to identify the related data element, is a cumbersome technique that requires special computer processing.”
The aforementioned options to record URIs for relationships distinctly from URIs for the objects of those relationships are all shown to have drawbacks in terms of their reliance on sophisticated processing, specific scope and available coverage. In terms of available coverage, it could be argued that subfield $4 has the benefit of already being defined in all of the fields where it is possible to record relationships in the MARC Authority and Bibliographic formats. When labelled “Relator code” subfield $4 is used to record a code which is available from the MARC Code List For Relators; when labelled “Relationship code” a code needs to be assigned from elsewhere. Beyond this overall division, the scope of those fields labelled “Relator code” and “Relationship code” varies across the formats according to the different information which they relate. However, the following are given as representative examples:
$4 – Relator code (371 Address - Authority format)
MARC code that specifies the relationship between the address and the entity described in the record. More than one relator code may be used if there is more than one relationship. Code from: MARC Code List for Relators.$4 - Relationship code (4XX, 5XX See From Tracings and See Also From Tracings - Authority format)
Contains in coded form the designation of a relationship of the entity in a 4XX or 5XX field to the 1XX entity in the record. See subfield $i for further information on relationship designators.$4 - Relator code (X00, X10, X11 Headings - Bibliographic Format)
MARC code that specifies the relationship between a name and a work. More than one relator code may be used if the person has more than one function. Code from: MARC Code List for Relators. The code is given after the name portion in name/title fields.$4 - Relationship code (76X-78X Linking Entries - Bibliographic Format)
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.
In cases where subfield $4 is currently labelled “Relator code” it could be amended throughout the formats as follows in order to support the recording of relationship URIs:
$4 - Relator code <or relator URI>
The subject and predicate of the first sentence for each associated definition could be amended as follows:
“<MARC code or URI that specifies the relationship between>…”
In cases where subfield $4 is currently labelled “Relationship code” this could be amended throughout the formats as follows in order to support the recording of relationship URIs:
$4 – Relationship code <or relationship URI>
The subject and predicate of the first sentence for each associated definition in the Authority format could be amended as follows:
“<Code or URI that specifies the relationship from>…”
The subject and predicate of the first sentence for each associated definition in the Bibliographic format could be amended as follows:
“<Code or URI that specifies the relationship between>…”
The following sentence could be added to the end of each definition of subfield $4 throughout the formats:
“<Subfield $4 is to be used for recording URIs which represent predicates in RDF triple statements.>”
If the scope of subfield $4 were to be broadened in the way which is described above, then issues of compatibility might arise between legacy coded data and URIs. The presence of URIs in $4 may affect subfield validation and indexing in library systems. In order to avoid these problems, local configurations would have to ensure that any $4 subfields containing the prefix (uri) or “http” are excluded from record validation and indexing processes. Alternatively, the codes currently recorded in $4 could be converted to their corresponding URIs so that legacy data does not have to be supported indefinitely.
The following examples demonstrate the usage of subfield $4 as a means to record relationship URIs as opposed to object URIs which are coded in $0. The subfield sequencing set out below follows a consistent pattern in which the relationship URI is appended to the relationship term or coded value and the object URI is appended to the object name. However, the ways in which systems order these subfields may differ. Each URI is prefixed ‘uri’ to reflect the practice currently prescribed in $0. However, this practice is the subject of a separate MARC Discussion Paper (2016-DP18).
Example 1 (Bibliographic Format) :
The following example models the recording of an LC Linked Data Service URI for a name (person) and a MARC relator URI for the name (editor) in field 700 (Added Entry Personal Name) which relates to the bibliographic entity recorded in field 245 (Title Statement).
245 00 $a Religion, learning and science in the 'Abbasid period / $c edited by M. J. L. Young.
700 1# $aYoung, M. J. L., $0 (uri) http://id.loc.gov/authorities/names/n80145489 $e editor $4 (uri) http://id.loc.gov/vocabulary/relators/edt
Example 2 (Bibliographic Format) :
The following example models the recording of an RDA Registry URI for a bibliographic entity relationship (absorbed by (work)) and a VIAF URI for the bibliographic entity (work) in field 785 (Succeeding Entry) which relates to the bibliographic entity recorded in field 245.
245 00 $a Melody maker.
785 14 $i Absorbed by (work): $4 (uri) http://rdaregistry.info/Elements/w/P10145 $t NME. New musical express $0 (uri) http://viaf.org/viaf/180802179
Example 3 (Authority Format) :
The following example models the recording of an RDA Registry URI for a personal relationship (founder) and an LC Linked Data Service URI for the name (person) in field 500 (See Also From Tracing – Personal Name) which relates to the name recorded in field 110 (Heading – Corporate Name).
110 2# $a I.M. Pei Associates
500 1#$w r $i founder $4 (uri) http://rdaregistry.info/Elements/a/P50029 $a Pei, I. M. $d1917- $0 (uri) http://id.loc.gov/authorities/names/n79065003
Example 4 (Authority Format) :
The following example models the recording of an RDA Registry URI for a bibliographic entity relationship (based on (work)) and a VIAF URI for the bibliographic entity (work) in field 500 (See Also From Tracing – Personal Name) which relates to the name recorded in field 100 (Heading – Personal Name).
100 1#$a Stoppard, Tom.$t Rosencrantz and Guildenstern are dead
500 1#$w r $i Based on (work) : $4 (uri) http://rdaregistry.info/Elements/w/P10190 $a Shakespeare, William, $d 1564-1616 $t Hamlet $0 (uri) http://viaf.org/viaf/315386437
Example 5 (Bibliographic Format) :
The following example models the recording of an LC Linked Data Service URI for a name (person) and a MARC relator URI for the name (author) in field 100 (Personal Name) which relates to the bibliographic entity recorded in field 245 (Title Statement). A coded value (aut) is recorded in the first iteration of subfield $4 as opposed to a human readable term in subfield $e. A URI for the coded value is recorded in a second iteration of subfield $4.
100 1# $a Dicks, Terrance $0 (uri) http://id.loc.gov/authorities/names/n78057783 $4 aut $4 (uri) http://id.loc.gov/vocabulary/relators/aut
245 10 $a Doctor Who and the planet of evil / $c Terrance Dicks.
The URIs in the MARC records have the potential to support the transformation of data into BIBFRAME.
5.1. Does subfield $4 offer the best available option for consistently recording URIs for relationships across the MARC Authority and Bibliographic formats?
5.2. Are the requirements of coded data in subfield $4 such that using the same subfield to record URIs would be problematic?
5.3. If subfield $4 cannot be used as a means of recording URIs for relationships, then what alternatives exist, given that $0, $1 and field 880 have all been previously rejected?
5.4. If subfield $4 can be used as a means of recording URIs for relationships is it still necessary that a distinction is made between Relator codes and Relationship codes in the subfield label?
HOME >> MARC Development >> Discussion Paper List
| The Library of Congress >> Especially
for Librarians and Archivists >> Standards ( 08/30/2016 ) |
Legal | External Link Disclaimer | Contact Us |