LANL Research Library

Repository Team

**Metadata Mapping Principles and Practices**

Revision History

<goldsmith@lanl.gov> 20060105 First Draft

<fknudson@lanl.gov> 20060109 Minor edits and additions\
<isholtkamp@lanl.gov> 20060126 Began adding MARC Tag/Subfield Mapping
Details Table\
<isholtkamp@lanl.gov> 20060130 Added (NR) and (R) notation to
Tag/Subfield Mapping Details Table; revised to include
Field/Definition/Instructions/Notes/Reason

<isholtkamp@lanl.gov> 20060202 Revised selected tags and added 887 tag

<isholtkamp@lanl.gov> 20060203 Added National Level Requirements for
each tag in the Mapping Details Table

<isholtkamp@lanl.gov> 20060206 Began adding Dataset specific mapping
instructions

<isholtkamp@lanl.gov> 20060207 020,022,030 changed instructions to red
awaiting feedback from Herbert

<isholtkamp@lanl.gov> 20060208 Updated 041 and 546 tags to include
information about normalization in dataset language keys for matching
purposes

<isholtkamp@lanl.gov> 20060216 Added 5^th^ bullet under General
Principles (and rationales)

<isholtkamp@lanl.gov> 20060308 Deleted 3, 10, and 17g under General
mapping conventions section; added "!!!" (ending bangs) to 16 under
General mapping conventions

<isholtkamp@lanl.gov> 20060308 Added section dated 2006-03-08 Vendor
Neutral Mapping Summary of Principles and Priorities

<isholtkamp@lanl.gov> 20060309 Additional instructions in 363 ; deleted
655 instructions for LANL Genre (not built)

<isholtkamp@lanl.gov> 20060320 Added the word "consistent" to the Team's
Prime Directive\
<isholtkamp@lanl.gov> 20060320 Changed all URLs to hyperlinked text

<isholtkamp@lanl.gov> 20060403 Added #6 to Vendor Neutral Mapping
section

<isholtkamp@lanl.gov> 20060406 -- Added General Mapping Conventions #8;
removed 856 OpenURL from Record enhancement list to General Mapping
Conventions #17; revised #9 to include 887 tags

<isholtkamp@lanl.gov> 20060417 -- Added General Mapping Convention #18\
<isholtkamp@lanl.gov> 20060804 -- Added section called "What Downstream
Applications Can Expect to See in MARCXML"

**Document description**

Detail the principles, philosophies, and specific practices used in
mapping raw (*aka vendor*) metadata records to a normalized format for
storage in the LANL Research Library's Repository (aDORe).

**Philosophy**

In the process of ingesting data from various sources into the
repository, it is desirable to convert each unique metadata format to a
normalized format. With all data available in one vender-neutral format,
storage, search, retrieval, interchange, and downstream use are
simplified.

**The Team's Prime Directive**

Push datasets into the repository in a consistent, usable, sustainable
manner.

**Goal**

The goal of mapping Vendor (Raw) data to a Vendor-neutral format is to
store disparate vendor metadata for *uniform transformation, storage,*
and *exchange [while retaining the granularity of the original
data]{.underline}*.

**Storage format**

MARCXML will be used as a container and MARC as a profile, with tags and
fields used as closely as possible within the standard, with the idea
that any library system should be able to load these vendor neutral
records into a reasonable representation of bibliographic metadata.

**Vendor Neutral Mapping -- Summary of Principles and Priorities**

**Principles of Use**

1.  Standards-based practices will be used everywhere possible and
    practical

2.  Whenever possible, the granularity of original vendor data shall be
    maintained

    a.  This is testable via roundtripability via xsl stylesheet
        transformations

3.  Limited data massage/enhancement will occur

    a.  Enhancements shall be limited to adding standards-based data
        (ISO language, openUrl), as practical

    b.  Rationale \-- We are mapping data, not cataloging or
        interpreting it

4.  Data will be mapped to the most specific available tag/field

5.  Data will not be duplicated unless required

6.  There are "no fatal errors" -- all vendor datasets must validate
    against their respective DTD or schema. As necessary, any foreign
    characters that do not validate against a file's DTD or schema will
    be changed to their hexadecimal equivalent.

**General Principles *(and rationales)***

-   No principles are set in stone, unable to be revised or amended

    -   *It is impossible to foresee every eventuality*

-   Standards-based practices will be used everywhere possible and
    practical

    -   *Maintainability*

    -   *Documentation*

    -   *No need to reinvent the wheel*

    -   *Ease of communication and interchange*

-   Within reasonable limits and practical considerations,
    vendor-neutral data records shall be returnable (via standard xslt)
    to original vendor format (*roundtripability)*

    -   *Ensures that data is not lost*

    -   *Provides simple self-checking data conversion verification*

    -   *In mapping all vendor data to the vendor-neutral format, we
        avoid having to return to the original record for additional
        bits of information that were originally thought unnecessary*

    -   *Elegance/Simplicity of design*

-   Limited data massage (aka clean-up)

    -   *We are mapping data, not cataloging or interpreting it*

    -   *Limited enhancement to **add** standards-based data (e.g. ISO
        language, openUrl) is pursued when practical*

-   In general, data granularity will be preserved and data are mapped
    to the most specific tag/field available

**Normalized Metadata Standard**

The format selected for storing raw metadata records is
[MARCXML](http://www.loc.gov/standards/marcxml/)

MARCXML is a standard "container" for holding Marc21 (ISO 2709; ANSI
Z39.2) formatted data, with sets of codes and content designators
defined for encoding machine-readable records. Formats are defined for
five types of data: bibliographic, holdings, authority, classification,
and community information. Details about codes and content designators
are available in *[The MARC 21 Formats: Background and Principles
(Revised November 1996)](http://www.loc.gov/marc/96principl.html).*

Although originally dismissed as too monograph-oriented, possibly too
rigid, and potentially too unwieldy for stylesheet transformations which
must maintain the granularity of data elements from different vendors,
the MARCXML standard eventually was chosen for reasons including

-   its relative maturity in the xml standards world,

-   its familiarity in the library community, and

-   its self-defined extensibility \-- which provides surprising
    flexibility.

In addition, numerous tools for working with and validating MARCXML
records currently exist, with support throughout the library community.

In adopting this standard, the Repository Team's goal is to use MARCXML
as a container and MARC as a \"profile\" to store disparate vendor
metadata for uniform transformation, storage, and exchange while
retaining the granularity of the original data. MARC tags and fields are
used as closely as possible within the standard, with the idea that any
library system should be able to automatically load these vendor neutral
records into a "reasonable" representation of bibliographic metadata.
However since we are dealing with individual records as concepts \--
rather than discrete physical cataloging items \-- some blurring may
occur and a few non-standard practices will be used.

**General mapping conventions**

1.  Individual records (e.g. citations) are stored in separate
    marc:record elements.

2.  Linked records (e.g. article with its cited individual bibliography
    items) are mapped to individual marc:records that are stored in a
    marc:collection element.

3.  Locally defined tags (X9X, 9XX will not be used. Our goal is to
    supply mapped data in which the intent of the tag can be determined
    without local reference.

4.  The MARC 877 tag (Non-MARC Information Field) will be used for
    vendor metadata that does not fit into defined-MARC tags. 887 tags
    may also contain vendor administrative data that is not defined in
    MARC (e.g. metadata record copyright and terms of use).

5.  Every MARC record will have a 245 field. In cases in which no title
    is supplied (e.g. ISI Citation records), a system-supplied
    title-phrase will be supplied.

6.  Since most records will have multiple authors and we are not
    cataloging/assigning main entry responsibility, all authors will be
    mapped to 7xx tags.

7.  All topical subjects will be mapped to standard subject tag 650
    (ind1 = 0; ind2 = 7). A subfield 2 will be supplied for each
    providing the context of the subject (e.g. vendor record's xpath or
    tag) for roundtripability.

8.  Other 6XX tags are permitted as needed (e.g. 600, 610, 630 for
    "reviewed works" in ISI datasets). A subfield 2 will be supplied for
    each providing the context of the subject (e.g. vendor record's
    xpath or tag) for roundtripability.

9.  Whenever permitted/needed, subfield 2 will be used to supply context
    information about the specific data contained in the tag (e.g. its
    origin in the vendor metadata record). Currently: \$2 is used with
    024, 041, 072, 084, 6XX, and 887 tags.

10. The following tags are never repeatable: 245, 260, 300.

11. All records will have a unique identifier in the 001 and 035 tag.

12. In the interest of linking/roundtripability, subfield code 8 may be
    used with any tag (with a linking counter) to tie related
    datafields.

13. To provide greater granularity for host item information and
    citation metadata, the Repository Team has become an early adopter
    to a proposed addition to the MARC standard (see *[Proposal
    no:2003-03](http://www.loc.gov/marc/marbi/2003/2003-03.html),
    Definition of Data Elements for Article Level Description*).

> a\. 363 (if 363 is present, then 300 is not present)
>
> b\. 773\$q
>
> 13\. When decisions for detailed formatting are required, AACR2 will
> be used as a point of reference.
>
> 14\. Any system-generated placeholders (e.g. titles, conference
> titles, author institutions, journal titles) will be enclosed in
> square brackets, with a leading and trailing string of "!!!" to
> designate that they can be ignored for purposes of downstream display,
> openUrl generation, etc. (e.g. \[!!!ISI Cited Reference!!!\] in a
> 245\$a)
>
> 15\. Record enhancement:
>
> a\. A MARC Leader will be built using standard rules
>
> b\. Tag 008 will be built using standard rules
>
> c\. Tag 040\$a will be built to indicate the original source of
> records
>
> d\. Tag 041 will be created using ISO 639.2 -- [*Codes for the
> Representation of Names of
> Languages*](http://www.loc.gov/standards/iso639-2/langcodes.html)
> mapped from vendor language terms
>
> e\. Original vendor language terms are mapped to tag 546\$a. Where
> vendor data includes both the full form of a language and a language
> code, the granularity of the data will be preserved as provided by the
> vendor. (Discussion 2006-02-01, if required, then language code comes
> first separate from language "full form" by a space.). A separate
> language key is created for each vendor dataset. Language keys contain
> only the languages that appear in vendor dataset documentation and are
> normalized to UPPERCASE with embedded punctuation stripped for
> matching purposes. Data in 546\$a is output in the original case
> provided in the dataset
>
> f\. 710, 711, 363 and 773 tags may have \$8 with matching numbers to
> pair information together. For example, conference sponsor (710 tag)
> and the conference (711 tag) are paired together by adding \$8 with an
> identical number to both fields.
>
> 16\. Controlled vocabularies are used where needed to normalize
> terminology across datasets. A list is maintained in the [RTF Team
> Wiki](http://stbrl.lanl.gov/pmwiki/pmwiki.php/Lww/RepositoryTaskForce)
> (see: [*Controlled
> Vocabulary*](http://stbrl.lanl.gov/pmwiki/pmwiki.php/Lww/ControlledVocabulary)).
>
> 17\. 856 tags for OpenURLs are not built at the time the MARCXML
> record is created.
> [Stylesheets](http://barracuda.lanl.gov:8080/RTFTools/stylesheets/)
> are available for use by downstream applications to generate the
> OpenURL dynamically.
>
> 18\. Where vendor tags exist without values (tag is empty), tags are
> still mapped for roundtripablility. Result will be a MARC tag/subfield
> that contains no data.
>
> **What Downstream Applications Can Expect to See in MARCXML\
> \[Note: Information in this section is subject to change as more
> datasets are added to the Repository.\]\
> **

1.  **Data normalization:\
    \
    All data (field content) is preserved in the form in which it
    appears in vendor records.\
    \
    This means that vendor field content is preserved in the form in
    which it is provided by the vendor (including all inconsistencies,
    errors, etc.). Transformation of vendor records from their original
    format to vendor-neutral MARCXML preserves the exact forms of data
    in vendor records.\
    \
    Remember, repository ingestion and transformation to vendor neutral
    MARCXML does not correct or interpret vendor data. The process
    involves mapping NOT cataloging.\
    \
    **

2.  **Record enhancements:\
    \
    These are kept to a bare minimum.\
    \
    Language (041 tags): Vendor language information (when present) is
    preserved in the form in which it is provided in original records.
    Language keys are created for each vendor dataset and full forms of
    languages are mapped to ISO 3-digit language codes. The original
    vendor language fields are mapped and retained in 546 tags at the
    same level of granularity provided. Languages that match full-forms
    in ISO 639.2 are also encoded in 041 tags and the first language is
    also mapped to 008/bytes 35-37.\
    \
    Note: No attempt is made to "interpret" vendor languages if they are
    not an exact match to full-form equivalents in ISO 639.2. Be aware
    that there are lots of vendor language tags that contain typos and
    invalid phrases, and therefore, 041 and 008/35-37 values in
    ISO-639.2 form were not assigned.\
    \
    Publication year (008/bytes 7-10): Because publication dates in
    260\$c and 773\$d appear in many forms (they are variable data),
    year portions have also been mapped as YYYY data in MARC 008/7-10.
    008/7-10 can be used by downstream applications to limit
    searches/results by publication year.\
    \
    Dataset identification (040\$a): These codes are for repository
    dataset identification, but can also be used to restrict end user
    access to an entire dataset (e.g. ECD is only accessible to LANL and
    Sandia users).\
    \
    For the ISI dataset, which encompasses the SciSearch, Social
    SciSearch, and Arts & Humanities databases, additional
    administrative information to restrict access licensed subscribers
    is found in 887\$a tags that begin with the label \[Adminmetadata :
    dc:accessRights\].\
    **

3.  **Character encoding & entities (USER BEWARE!):\
    \
    In order to validate records as MARCXML, the validation process
    requires that the following characters/symbols be "entitized":
    ampersand (&), apostrophe ('), double quote ("), less than (\<), and
    greater than (\>). These are considered special XML entities.\
    \
    Vendor datasets contain additional special characters and or
    entities and their documentation is incomplete as to the
    standards/methodology used to indicate special characters and/or
    character entities.\
    \
    Downstream applications need to be aware that this is a BIG problem
    that will impact both display and indexing in any MARC tag that may
    contain language diacritics, Greek characters, mathematical and
    physical notation.\
    \
    Inspec dataset: This dataset currently uses Unicode values for all
    special characters that could be identified, but this will not
    necessarily be the case in future versions of the Repository.\
    \
    LANL Technical Reports By IAM: This dataset uses a mixture of HTML 4
    encoding for special characters, but does not consistently apply
    this encoding to the 5 special XML entities: ampersand (&),
    apostrophe ('), double quote ("), less than (\<), and greater than
    (\>).\
    \
    ECD: Uses its own methodology for encoding, but the documented
    methodology is not consistently applied or fully documented.\
    \
    EIX: Uses its own methodology for encoding. The level of consistency
    to which it has been applied is unknown at this time.\
    \
    BIOSIS: Uses its own methodology for encoding. The level of
    consistency to which it has been applied is unknown at this time.\
    \
    ISI (SciSearch, Social SciSearch, A&H, and Pro): These datasets do
    not use any special characters other than ampersand (&), apostrophe
    ('), double quote ("), less than (\<), and greater than (\>).\
    \
    **

4.  **Some MARCXML tag/subfields may be empty.\
    \
    Reason: Because the vendor tag label in the original vendor record
    was present but blank or empty.**

5.  **Some MARCXML tag/subfields may contain data that begins with \[!!!
    and ends with !!!\]\
    \
    When a specific MARC tag/subfield is required (e.g. mandatory) and
    the vendor does not provide data that can be mapped to it,
    placeholder information is added.\
    \
    The beginning notation and ending notation is a "clue" to downstream
    applications that this is placeholder information. Downstream
    applications need to decide whether to display and index this data.\
    \
    Tags where this placeholder information may occur are: 245\$a
    (Title), 773\$t (Host Item Entry -- Title), and 711\$a (Conference
    Name)\
    \
    **

6.  **Field pairing using \$8:\
    \
    Field pairing using \$8 exists when tags in MARCXML records contain
    the same data but it is formatted differently (e.g. a 773 tag and
    its corresponding 363 tag) or when there is a "relationship" between
    tags (e.g. 711 (Conference name) and 710 w/\$e=Sponsor where the
    value in the 710 tag represents the conference sponsor). Pairs are
    identified by the use of a computer-generated value in the \$8 of
    each of the tags comprising a pair.\
    \
    \$8 as a tag pairing mechanism is used for:\
    773 and 363\
    711 and 710 with \$e=Sponsor\
    \
    Field pairing may impact how downstream applications choose to
    display and/or index this data.**

7.  **Names (Personal):\
    \
    These are preserved in the form and order in which they are provided
    by the vendor.\
    \
    Personal names may appear in mixed case, ALL CAPS, inverted order
    (last name first) with or without a comma to separate the surname
    from the first name and/or initials., direct order (initials and/or
    given name followed by last name), with or without generational
    qualifiers (e.g. Jr., Sr., II, III, IV).\
    \
    Initials and abbreviations may or may not be followed by a period.
    Spaces may or may not appear between initials.\
    \
    Roles (e.g. Author, Editor, etc.) are included in a normalized form
    only when the role is clearly defined in the original vendor data
    (700\$e)**. **(See: [Controlled
    Vocabulary](http://stbrl.lanl.gov/pmwiki/pmwiki.php/Lww/ControlledVocabulary)).**

> **Name affiliations are appended to personal names (700\$u) only when
> clearly defined in the original vendor data.\
> \
> Email addresses are appended to personal names (700\$g) only when
> clearly associated with a given name in the original vendor data. When
> no clear association is provided, email addresses are mapped to 887\$a
> with \$2 containing the xpath back to the original vendor field (e.g.
> BIOSIS -- Au List Email).\
> \
> **

8.  **Corporate or Institutional Names:\
    \
    These are preserved in the form and order in which they are provided
    by the vendor.\
    \
    They may appear in mixed case, ALL CAPS and may also include
    abbreviations (e.g. Dept, Geol, Sch, etc.). Abbreviations may or may
    not end in a period and may or may not be consistently applied in a
    given dataset. Some institutional names may be in acronym form
    only.\
    \
    Institutional names may or may not include address/location
    information and there is no predictable pattern for a given
    institution and its subordinate units.\
    \
    **

9.  **Conferences\
    \
    Vendor conference data elements are mapped to the closest USMARC
    tag/subfield. Vendor records do not make the distinction between a
    conference "name" and a conference "title". In order to build a
    meaningful conference entry (711 tag) conference titles have by
    necessity been mapped to the conference name subfield, 711\$a.
    Vendor conference titles may be in a full form or an abbreviated
    form.\
    \
    In cases where the vendor provides a full and an abbreviated form of
    the conference name/title, the full form is mapped to 711\$a and the
    abbreviated form is mapped to 711\$t so that no vendor data is lost.
    Downstream applications need to be aware of the implications of this
    for indexing and display.\
    \
    Where vendors provide multiple forms of conference dates, one of the
    forms is mapped to 711\$d and all others are mapped to 887\$a with
    \$2 containing the xpath back to the original vendor tag.\
    \
    Conference location is mapped to 711\$c.\
    **

10. **Subjects and keywords:\
    \
    All topical subjects are mapped to 650\$a (Ind1 = 0; Ind2 = 7).
    650\$2 contains the context of the subject (e.g. vendor record's
    xpath or tag) for roundtripability.\
    \
    Downstream applications should use the 650\$2 data to display
    different types of subjects in separate groups or to index them
    separately (e.g. controlled vs uncontrolled terms).\
    \
    Other 6XX tags are permitted as needed (e.g. 600, 610, 630 for
    "reviewed works" in ISI datasets). \$2 is supplied for each
    providing the context of the subject (e.g. vendor record's xpath or
    tag).**

> **\
> **

11. **Abstract information:\
    \
    Abstracts are mapped to 520\$a. Any "notes" provided by vendor
    qualifying the type of abstract are mapped to 520\$b.\
    \
    **

12. **Bibliography notes & Number of citations:\
    \
    If a vendor supplies information indicating the number of citations
    in the bibliography of the item described by the bibliographic
    record, the number of citations are mapped to 504\$b. 504\$b may
    contain the value "0" (indicating that there are NO bibliographic
    citations (i.e. no bibliography or bibliographical references).\
    \
    504\$a IS NOT added unless the vendor provides specific information
    to be mapped to this tag/subfield.\
    \
    The resulting 504 tags are not USMARC compliant if they lack 504\$a,
    but are adequate for Repository purposes.\
    \
    The presence of the 504 tag may be used by downstream applications
    to limit results to items that have bibliographical references
    provided that the value in 504\$b is greater than (\>) 0 (zero). In
    cases where 504\$b is not present, but 504\$a IS present, then the
    presence of 504\$a indicates in a very general sense that the item
    contains bibliographical references (an exact number not
    identified).\
    \
    **

13. **Bibliographic citations:\
    \
    Bibliographic citations appear in two major forms.\
    \
    For ISI datasets (ISI and PRO) these appear as entirely separate
    records in the repository which we refer to as "mini-MARCs". These
    records are provided by the vendor with distinctly parsed
    bibliographic elements (e.g. author, title (if not present, we
    provide a placeholder see #5), source, pub date, etc.)\
    \
    For the LANL Technical Reports dataset created by IAM, the citations
    are not parsable into distinct bibliographic elements as separate
    "mini-MARC" records. Each of these appears as a separate 887\$a tag
    (as just text strings) with \$2 containing the xpath back to the
    original vendor data element.\
    \
    Downstream applications will need to consider how to arrange and
    display these citations (as a bibliography) and other possible uses
    of this data (e.g. citation counts).\
    \
    **

14. **ISSNs mostly appear in 773\$x (as part of the Host item Entry)
    because they are associated with the Source level data (the
    source/journal where an article or paper can be found). When source
    level information (a 773 tag IS NOT present), then the ISSN may
    appear in 022\$a.\
    \
    All ISSNs provided in vendor data are assumed to be valid and
    therefore tagged as such. No attempt is made to interpret whether
    these are indeed valid or invalid ISSNs.\
    \
    Not all article level records with 773 tags contain an ISSN. If the
    vendor data does not specifically include ISSN then the resulting
    MARCXML 773 tag will not include 773\$x. This means that not all
    articles in a given journal can be consistently identified by using
    this type of standard identifying number. This may be especially
    true for records in early years of a given dataset when this type of
    metadata was not assigned or not included in vendor records.\
    \
    In cases where the vendor provides both ISSN and eISSN data, each is
    mapped to a separate occurrence of 773\$x (for article level
    records) or a separate occurrence of 022\$a (for serial level
    records).\
    \
    ISSN formatting is always in the form ####-####.\
    \
    **

15. **eISSNs mostly appear in 773\$x (as part of the Host item Entry)
    because they are associated with the Source level data (the
    source/journal where an article or paper can be found. When source
    level information (a 773 tag IS NOT present), then the eISSN may
    appear in 022\$a.\
    \
    eISSNs (when specifically identified as such by the vendor) will be
    qualified with "(electronic)" (e.g. 1573-1804 (electronic))\
    \
    eISSN formatting is always in the form ####-####.\
    \
    **

16. **CODENs mostly appear in 773\$y (as part of the Host item Entry)
    because they are associated with the Source level data (the
    source/journal where an article or paper can be found. When source
    level information (a 773 tag IS NOT present), then the CODEN may
    appear in 030\$a.\
    \
    All CODENs provided in vendor data are assumed to be valid and
    therefore tagged as such. No attempt is made to interpret whether
    these are indeed valid or invalid CODENs.\
    \
    CODENs may appear a 5-digit OR 6-digit values. 5-digit CODENs lack
    the last check-digit. No attempt is made to "normalize" 5-digit
    CODENs to 6-digit values. This inconsistency in CODENs may affect
    source matching especially if ISSNs or eISSNs are not present.\
    \
    Not all article level records with 773 tags contain a CODEN. If the
    vendor data does not specifically include a CODEN then the resulting
    MARCXML 773 tag will not include 773\$y. This means that not all
    articles in a given journal can be consistently identified by using
    this type of standard identifying number. This may be especially
    true for records in early years of a given dataset when this type of
    metadata was not assigned or not included in vendor records.\
    \
    **

17. **ISBNs can appear in 773\$z (as part of the Host item Entry)
    because they are associated with the Source level data (the
    source/book/monograph where an article, paper, or chapter can be
    found). When source level information (a 773 tag IS NOT present),
    then the ISBN may appear in 020\$a.\
    \
    Multiple ISBNs may appear in a given record.\
    \
    All ISBNs provided in vendor data are assumed to be valid and
    therefore tagged as such. No attempt is made to interpret whether
    these are indeed valid or invalid ISBNs.\
    \
    Not all article or book/monograph level records with 773 tags
    contain an ISBN. If the vendor data does not specifically include an
    ISBN, then the resulting MARCXML 773 tag will not include 773\$z.
    This means that not all articles, papers, chapters in a
    monograph/book can be consistently identified by using this type of
    standard identifying number. This may be especially true for records
    in early years of a given dataset when this type of metadata was not
    assigned or not included in vendor records.\
    \
    ISBN formatting varies. ISBNs should normally be 10-digits in length
    and can include 3 embedded hyphens or spaces. 9-digit ISBNs are
    sometimes present and have not been evaluated to determine if they
    lack the last digit (the check-digit) or contain typos.\
    \
    For matching purposes, ISBNs should be normalized to a 10-digit
    string omitting the embedded hyphens or spaces. Beginning on January
    1, 2007, all 10-digit ISBNs will no longer be assigned. ISBNs will
    be expressed as a 13 digit number by appending a 978 prefix to the
    9-digit core and recalculating a new check digit. A 979 prefix will
    be used when all 978 prefixes are assigned. This will effectively
    double the number of ISBNs available. These 13 digit numbers are
    also properly referred to as Bookland EANs. Downstream applications
    need to decide if 10-digit ISBNs will also be re-expressed as
    13-digit numbers. (See: [Get Ready for the New
    ISBN](http://www.niso.org/standards/resources/ISBN.html), [ISBN
    Standard
    Revision](http://www.isbn-international.org/en/revision.html), and
    [ISBN Users' Manual (5^th^ International
    ed.)](http://www.isbn-international.org/en/download/2005 ISBN Users' Manual International Edition.pdf))\
    \
    **

18. **Other standard identifying numbers:\
    \
    Technical report numbers are mapped to 088\$a.\
    \
    SICIs (when supplied by the vendors) are mapped to 024\$a with
    Ind1=4. For more information on SICI standard, see [ANSI/NISO
    Z39.56-199t
    (R2002)](http://www.niso.org/standards/standard_detail.cfm?std_id=530),
    Serial Item and Contribution Identifier (SICI).\
    \
    Stock numbers and other types of "order" numbers are mapped to
    037\$a.\
    \
    DOIs (when supplied by the vendors) are mapped to 024\$a with Ind1=7
    and Ind2=blank. \$2 contains the xpath back to the original vendor
    tag.\
    \
    All other identifying numbers that cannot be identified as a
    specific type are mapped to 024\$a with Ind1=7 and Ind2=blank. \$2
    contains the xpath back to the original vendor tag.\
    \
    **

19. **Patent information:\
    \
    Where possible, patent information is mapped to 013 subfields.\
    \
    Patent numbers are mapped to 013\$a\
    Patent country: 013\$b\
    Patent number qualifier: 013\$c (controlled terminology (e.g. Patent
    or Patent application) to differentiate types of patent numbers).\
    Patent date: 013\$d (preserved in vendor format NOT YYYYMMDD pattern
    expected in USMARC).\
    \
    Patent assignee(s) may be individuals or institutions so they are
    mapped to 720\$a (undifferentiated names) with \$e = Patent
    assignee\
    \
    **

20. **Classification numbers:\
    \
    Classification numbers from a scheme other than LC, DDC, UDC, NLM,
    NAL, GPO are mapped to 084\$a. 084\$2 contains the xpath which
    identifies the original vendor field that contains this data.\
    \
    Classification numbers may or may not be accompanied by textual
    equivalents that define the meaning of the number (e.g.
    classification numbers in INS (Inspec) have textual equivalents as
    part of this data element but classification numbers in EIS
    (Engineering Index) do not).\
    \
    Patent classification numbers are mapped to 084\$a. 084\$2 contains
    the xpath which identifies the original vendor field that contains
    this data.\
    \
    **

21. **Subject category codes:\
    \
    Numeric or alpha-numeric strings that are defined by the vendor as
    being of a subject code nature are mapped to 072\$a and \$2 contains
    the xpath which identifies the original vendor field that contains
    this data.\
    \
    In cases where the vendor only supplies a "code" and no "textual
    equivalent", downstream applications may need to augment access to
    the codes through the use of a table mapping or online documentation
    that relates each specific code to its textual equivalent or
    definition.\
    \
    **

22. **Vendor-supplied URLs:\
    \
    Vendor-supplied URLs are mapped to 856\$u with a default value of
    856\$y=Item URL unless the vendor provides an indication that a
    given URL is for something else (e.g. Publisher URL, related URL,
    etc.). (See: [Controlled
    Vocabulary](http://stbrl.lanl.gov/pmwiki/pmwiki.php/Lww/ControlledVocabulary)).\
    \
    No attempt is made to verify the accuracy or reliability of
    vendor-supplied URLs.\
    \
    **

23. **Document types:\
    \
    Document types vary considerably from dataset to dataset. Original
    vendor terminology has been preserved. No attempt has been made to
    map vendor terms to a "generic" terms (as is currently the case in
    SearchPlus). Downstream applications may want to consider additional
    mapping to generic terms as a means of limiting search results to a
    finite list of terms.**