DATE: May 7, 2001
REVISED:
NAME: Definition of Field 887 (Non-MARC Information Field) in the MARC 21 Bibliographic Format
SOURCE: Library of Congress; Cooperative Online Resource Catalog (CORC)
SUMMARY: This paper proposes the addition of field 887 for information that is not mappable to an existing MARC 21 field. The source of the information would be from some other metadata scheme. The field is modeled after field 886 (Foreign MARC Information Field).
KEYWORDS: Field 887 (BD); Non-MARC Information Field (BD)
RELATED:
STATUS/COMMENTS:
05/07/01 - Made available to the MARC 21 community for discussion.
06/17/01 - Results of the MARC Advisory Committee discussion - Approved.
A discussion paper will be prepared that explores the encoding of non-MARC characters
in the MARC 21 formats.
08/07/01 - Results of LC/NLC review - Approved.
PROPOSAL NO. 2001-11: Definition of field 887 in the MARC 21 Bibliographic Format
With the emergence of all types of metadata schemes for various purposes there has been a need to establish standard mappings between them. Many of these schemes are bibliographic in nature in that they may be used for resource description of some sort. To allow for interoperability between metadata schemes (for instance to expose data created among disparate types of applications), crosswalks have been established that map an element in one scheme to an element in another. LC's Network Development and MARC Standards Office has established or otherwise made available crosswalks between the following:
* MARC and Dublin Core
* MARC and ONIX
* MARC and Digital Geospatial Metadata
* MARC and GILS
It is often the case that elements in one scheme may not fit into an element in another scheme, requirements may be different, encoding conventions may be prescribed in various ways, granularity may vary, etc. Thus it is widely accepted that round-trip mapping is not possible. There are always some "leftovers" that may have meaning for one type of application while it may not be important enough in the other to have created a distinct element.
In order to retain information that may be provided in a record created using one metadata scheme and converted to another, it is proposed that a new field 887 be defined. This field could be modeled after field 886 (Foreign MARC Information Field), which has been used in a similar way for data coming from foreign MARC records for which there is no corresponding MARC field when they undergo conversion.
2.1. Field 886. Field 886 is defined as follows:
Indicators
First - Type of field
A value that indicates the type of foreign MARC field from which the data is converted.0 - Leader
1 - Variable control fields (002-009)
2 - Variable data fields (010-999)Second - Undefined
# - Undefined
Subfield Codes
$a - Tag of the foreign MARC field (NR)
$b - Content of the foreign MARC field (NR)
$2 - Source of data (NR)
$a-z - Foreign MARC subfield (R)
$0-9 - Foreign MARC subfield (R)
In field 886 subfield $a contains the tag and $b contains all data that would appear after the tag, including the indicator values and subfield tags as they were encoded. Example:
| 886 | 2# | $2ukmarc $a690 $b00 $a00030 $dGreat Britain $z11030 $abutterflies $z21030 $alife cycles |
It was considered whether a change to this field might be appropriate to accommodate non-MARC data from other metadata schemes, but the field expects the MARC structure defined by Z39.2 (Information Interchange Format). Thus, a new field is proposed.
2.2. New field 887. Field 887 could be defined as Non-MARC Information Field as follows:
Indicators: both blank
Subfield codes:
$a - Content of non-MARC field (NR)
Subfield $a contains the entire content of the non-MARC field including any tags or element names as encoded by the non-MARC field.$2 - Source of data (NR)
Subfield $2 contains the source of the data, either a schema or DTD reference.
It needs to be considered whether there is a need for an indication of the syntax used for the data (e.g. XML, HTML, etc.) or whether that is self-defining.
If incoming data contains non-MARC characters, they would need to be represented by characters in the MARC character set. Thus, any non-MARC character could be represented by its hex value, as was done for data with the spacing underscore or spacing tilde in URLS in field 856 before those characters were represented in the MARC character set.
2.3. Examples
2.3.1. DCMI example. Source metadata (XML-encoded, from _DCMI Box Encoding Scheme: specification of the spatial limits of a place, and methods for encoding this in a text string_:
<Box>
<eastlimit>0</eastlimit>
<westlimit>180</westlimit>
</Box>
There is no field where this data could currently be carried in MARC 21. It could be included in a new field 887 as follows:
| 887 | ## | $a<Box><eastlimit>0</eastlimit><westlimit>180</westlimit></Box>$2<schema or DTD reference> |
Note that the data in subfield $2 would include a reference to the specification or DTD. DCMI-Box is currently available at http://dublincore.org/documents/dcmi-box/.
2.3.2. ONIX example. ONIX International is the international standard for representing and communicating book industry product information in electronic form.
Source metadata (XML-encoded ONIX):
<TextPublicationDate>20000617</TextPublicationDate>
| 887 | ## | $a<TextPublicationDate>20000617</TextPublicationDate>$2<schema or DTD reference for ONIX> |
2.3.3. MARC 21 in XML. One could imagine a record using the MARC XML DTD to express MARC 21-defined metadata in that syntax. If the record included local extensions to the DTD, those could be carried in this field with an indication of the source through a DTD reference, since there would be no mapping to an appropriate field in MARC.
3. PROPOSED CHANGE
Indicators: both blank
$a - Content of non-MARC field (NR)
Subfield $a contains the entire content of the non-MARC data including any tags or element names as encoded in the non-MARC information.
$2 - Source of data (NR)
Subfield $2 contains the source of the data, either a schema or DTD reference.
Library of Congress