The Library of Congress >> Especially
for Librarians and Archivists >> StandardsThe Library of Congress >> Especially
for Librarians and Archivists >> Standards
HOME >> MARC Development >> Proposals List
DATE: December 13, 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 proposal recommends 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 ; 2016-DP17
STATUS/COMMENTS:
12/13/16 – Made available to the MARC community for discussion.
01/21/17 – Results of MARC Advisory Committee discussion: Approved as submitted.
03/21/17 - Results of MARC Steering Group review - Agreed with the MAC decision.
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. However, 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’). The definition of subfield $0 limits its use to the recording of URIs for the objects of relationships (things), rather than the relationships themselves. 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 be reserved to record URIs for objects.
In a context where URIs are recorded in subfield $4, these may or may not be associated with a MARC code. Therefore, this paper also recommends that, where $4 is currently labelled ‘Relator code’, it would be appropriate for this to be made less prescriptive by relabeling it ‘Relationship code’. 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 labelled ‘Relator code’ could still reference the MARC Code List for Relators as an example of designations in coded form.
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. In the latter case, the parenthetical (uri) is redundant and should not be included if the identifier is given in the form of a web retrieval protocol, e.g. HTTP URI, which is self-identifying.
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.
Subfield $0 is to be used for recording URIs which represent objects in RDF triple statements.
URIs represent one category of the standard identifiers which may be recorded in subfield $0. However, the current definition of $0 only allows URIs for objects to be recorded in this subfield. 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 relationship URI applies. The following example, originating from that paper, demonstrates how the URI for a relationship might be recorded in subfield $0 and appended to an equivalent human readable term for that relationship:
700 1# $i Paraphrase of (work): $0 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 states 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 URLs 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.”
In preference to defining subfield $1 or a new field modelled on the 880, MARC Discussion Paper 2010-DP02 suggests the following:
“A convention could be used to indicate that they are URIs rather than literal values. It is suggested that angle brackets be used around the URI, which is a standard way to reference URIs. Instead or in addition, a mark such as the exclamation point could be used before the URI.”
The following example, originating from that paper, demonstrates how the URI for a relationship might be embedded within a subfield which carries the relationship itself:
110 2# $a University of Texas. $b Dept. of Anthropology. $0<http://lccn.loc.gov/n86041077> $4spn <http://id.loc.gov/vocabulary/relators/spn>
However, the definition of subfield $0 specifies that parenthesized data “should not be included if the identifier is given in the form of a web retrieval protocol, e.g. HTTP URI.” This specification arises from MARC Discussion Paper 2016-DP18 in which the PCC Task Group on URIs in MARC describes the need for excluding parenthesized data from subfield $0 as follows:
“Dereferenceable HTTP URIs embedded in MARC 21 records as identifiers have proven useful in disambiguating identities, maintaining authority data, and transforming MARC 21 data to various linked data formats. This transformation, however, requires the removal of the parenthetical (uri) in order to make the URI actionable in applications according to corresponding protocols.”
The Task Group considers that the requirement for URIs to be dereferenceable extends beyond $0 to encompass any other subfields in which it may be desirable to record URIs, including those for relationships. Besides parentheses, using other characters to indicate the presence of URIs is equally problematic from the perspective of dereferenceability.
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 dereferenceability, 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 “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>…”
In cases where subfield $4 is currently labelled “Relator code”, this label and its accompanying definition are limited in scope, whereas the label “Relationship code” and its accompanying definition are not. The former are confined to recording MARC relator codes, whereas the latter permit the recording of relationship codes from any source. If the scope of subfield $4 were broadened to encompass the recording of URIs for relationships as well as codes, then, according to its current label and definitions, only URIs associated with MARC codes could be recorded under “Relator code”. Therefore, in order to render these instances of subfield $4 capable of carrying a URI whether or not they are related to a MARC code, it would be desirable to amend the code and accompanying definition as follows:
$4 -
Relator<Relationship> code <or relationship URI>
The subject and predicate of the first sentence for each associated definition could be amended as follows:
“<
MARC codeCode or URI that specifies the relationship between>…”
The subject of the second sentence for each associated definition could be amended as follows:
“<More than one
relator coderelationship code or URI may be used>…”
The subject of the third sentence for each associated definition could be amended as follows:
“<
Code fromA source of relationship codes is: MARC Code List for Relators.>
The following sentence could be added to the end of each definition of subfield $4 throughout the formats in order to specify that this subfield is used only to record relationship and not other types of URI:
“<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 carried out in library systems. In order to avoid these problems, local configurations would have to ensure that any $4 subfields containing “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 presence of “http” at the beginning of any $4 subfield containing a URI should mean that it is readily distinguishable from legacy coded data.
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. Dereferenceable URIs provide look up functionality. This means that sort order is unnecessary as a means of determining which element within the string relates to which URI.
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 http://id.loc.gov/authorities/names/n80145489 $e editor $4 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 http://rdaregistry.info/Elements/w/P10145 $t NME. New musical express $0 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 http://rdaregistry.info/Elements/a/P50029 $a Pei, I. M. $d1917- $0 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 http://rdaregistry.info/Elements/w/P10190 $a Shakespeare, William, $d 1564-1616 $t Hamlet $0 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 http://id.loc.gov/authorities/names/n78057783 $4 aut $4 http://id.loc.gov/vocabulary/relators/aut
245 10 $a Doctor Who and the planet of evil / $c Terrance Dicks.
Example 6 (Bibliographic Format):
The following example models the recording of an LC Linked Data Service URI for a name (person) and MARC relator URIs for the name (author and artist) in field 100 (Personal Name) which relate to the bibliographic entity recorded in field 245 (Title Statement).
100 1# $a Crilley, Mark. $0 http://id.loc.gov/authorities/names/no99010204 $e author, $4 http://id.loc.gov/vocabulary/relators/aut $e artist $4 http://id.loc.gov/vocabulary/relators/art
245 10 $a Brody’s ghost : $b the collected edition / $c written and illustrated by Mark Crilley.
The URIs in the MARC records have the potential to support the transformation of data into BIBFRAME.
In the MARC 21 Bibliographic and Authority Formats:
5.1. Expand the scope of subfield $4 to encompass the recording of dereferenceable URIs representing relationships, as described in Section 2.1. above.
5.2. Expand the scope of subfield $4 where it is labelled and defined ‘Relator code’ to permit the recording of both relationship URIs associated and not associated with MARC codes, as described in Section 2.1. above.
HOME >> MARC Development >> Proposals List
| The Library of Congress >> Especially for Librarians and Archivists >> Standards ( 03/21/2017 ) |
Legal | External Link Disclaimer | Contact Us |