TCC Archives Metadata Standards: DCAP Content Standard

Content Standards: Rules and Instructions for Entering Content Metadata in Qualified Dublin Core Fields

Preliminaries

The general coding of content will follow the RDA content standard, supplemented by specified controlled vocabularies and local/commonsense data-entry conventions.  Punctuation, where necessary, will conform to ISBD practice.

Instructions for metadata content entry infra for each Dublin Core element will be spelled out as paraphrases of the relevant RDA element rule.  For the most part, data entry will be simplified relative to the full range of options and alternatives available in the RDA rule.  The citation for the RDA rule or sub-rule will be provided in the event the cataloger wishes to consult the instructions in more detail.  In some cases, data entry will depart from RDA specifications for purposes of simplicity, intelligibility, patron-friendliness, etc.  These will be noted, as necessary, in each case.

The order of elements infra represents the order of display in both the Omeka CMS metadata editor template and the Omeka public display record.  It is also the order in which the entry of the content metadata should be done.  The arrangement of the elements follows the basic pattern of a MARC record.  Not all fields will be used for any given item or item-type.  For an indication of which fields are required, mandatory if necessary, optional, or not needed (relative to item type), see the “Is the field required?” line-entry in the accompanying Elements Tables.

Each item in the Heritage Collection belongs to one of approximately seven different general materials types: artifacts, ephemera, photographic materials, publications and textbooks, records and documents, sound recordings, and video recordings. Metadata content entry rules will sometimes differ depending on the type of item that is being described.  The dates of monographs, for example, are most often found on the title page or verso of the title page of the publication, and that date accordingly would be entered in the Date field.  A locally produced (and unpublished) video recording of an event, on the other hand, would lack a publication date and would be dated, therefore, with respect to the date of the event captured in the video.  Similarly, the title of a publication would be entered as the item’s title, while realia, which typically lack formal titles, would require the construction of an artificial title.  Where there are collection- or type-specific requirements within each element for the recording of metadata content for that element, the special instructions will be provided and identified by a material-type prefix, e.g., “For video recordings: [special instructions].”  This will be done for each element when necessary.

A total of 23 elements has been selected for the Heritage DC application profile.  The full suite of enhanced Dublin Core elements consists of 55 elements and can be found in its entirety in the Omeka CMS metadata editor. The remaining 32 elements are grouped together below the 23 selected elements.  The last element in the 23-element set is Dublin Core Source.  Any element field below Source is part of the enhanced Dublin Core element that is not being used in this application profile and can be safely ignored.  Any field in which no data is entered will not display on the front end display.  There is no need to delete the field in the metadata editor.  In data entry, therefore, the bottom 32 elements (following Source) will always remain empty.

Instructions for Entry of Content

Title [DC: Title]

If the item has a title, enter the title exactly as it appears on the item.  For books, take the title from the title page.  If the book lacks a title page, take the title from the cover, dustjacket, spine, or wherever else the statement of the title occurs on the item.  If the title has a subtitle, enter the subtitle following the main title and separate it from the main title with space-colon-space punctuation.  (Do this for any type of item with a subtitle.)  For video recordings, take the title from the actual title frames.  If the video lacks a title in the video display but has a title on its carrier or container, enter the title from either of those sources.  For sound recordings, take the title from the case/container or from carrier itself (tape, disc, LP label, etc.).  For photographic materials, artifacts (including realia), and ephemera, if the item has a name or title inscribed on or attached to it, enter that name or title exactly as it appears on the photograph/slide/etc.  If an item in any one of these three types does not have a title or name inscribed on or attached to it, then construct a name or title that either (a) best approximates the content of the item, or (b) describes the nature of the item or the general category to which the item belongs, and enclose the name or title in brackets.  With respect to the “general category” in (b) supra, use the most specific and precise term that best describes the item from the SAA Glossary of Archives and Records Terminology: http://www2.archivists.org/glossary. For any item type that altogether lacks a title, construct a title along the guidelines just specified and enclose it in brackets.

Principal sources:  RDA 2.3.1, 2.3.2; SAA Glossary of Archives and Records Terminology

Alternative Title [DC: Alternative]

This field is not likely to be used frequently except with monographs or other kinds of textual publications.  Occasionally, a monograph or other textual publication will have a title on the spine or cover/dustjacket that differs from the title on the title page.  If this is the case, then enter that other title, exactly as it appears on the item, in the field for Alternative title, and add an identifying prefix to the entry to explain the nature or source of the alternative title, e.g., Title on spine: “[spine title]”.   Do this as well for so-called “parallel” titles, i.e., titles in a second language on the title page.  Use the prefix Additional title on title page.  A similar situation may also occur with video recordings and sound recordings, though likely not as often.  Titles on a video recording’s container or carrier (disc, cassette, etc.) may differ from the title in the title frames; and likewise, on sound recordings, the title on the container may differ from the title on the carrier (CDs, LPs, cassette tapes, etc.).  In these cases, enter the non-primary title in the Alternative title field and identify with prefix accordingly, e.g., Title on container.  (For sound recordings, consider the title on the container (what the public sees) as the primary title.)

Principal sources: RDA 2.3.3, 2.3.4, 2.3.6

Creator [DC: Creator]

Enter the name of the person or corporate body that has the primary responsibility for the creation of the item and/or the intellectual content of the item.  Use the authorized form of the name, if one exists.  The authorized form can be found by searching the Library of Congress Name Authority File: http://authorities.loc.gov/cgi-bin/Pwebrecon.cgi?DB=local&PAGE=First

If there is access to OCLC Connexion, the “Personal Names” or “Corporate/Conference Names” indexes in the Authorities Search interface can also be used.  Enter the name in the Creator field exactly as it appears in the authority file.  Eliminate any MARC subfield indicators if present.  If no authorized form of the name exists, use the name that is most commonly used for the person or corporate body.  Enter the name using the same form as that of authorized names: for persons, surname first, followed by given name (and an initial or initials, if that is part of the most commonly used form of the name), i.e., “inverted” order; for corporate bodies, the name as it occurs (no “inversion”).

An entity should be considered as having “primary responsibility” when (a) it is the sole entity listed on the item, or (b) if listed with other entities who are acting collaboratively as creators, it is given prominence of place by being listed first, displayed with a larger font, and/or by some other means of emphasis.  If there are multiple creators and they are listed alphabetically without prominence accorded to any one of them, use the name of the first one listed as having primary responsibility and enter the others in the Contributor field.  If the item is a compilation of different works by different entities who are not acting collaboratively, enter in the Creator field the name of the entity responsible for creating the compilation.  For films or video recordings, treat the director, first, as having primary responsibility; if there is no (known) director, then treat the production company as having primary responsibility; if there is no (known) production company, then treat the most prominently listed individual producer as having primary responsibility; if there is no (known) producer, then treat the individual writer most prominently listed as having primary responsibility.  For sound recordings, enter the composer whose works are being played as having primary responsibility.  If the item consists of works by different composers, enter the name of the most prominently listed performing artist as having primary responsibility.  For photographic materials, enter the name of the photographer, or, if the name is not known, the entity or corporate body with which the photographer was likely associated.  For artifacts and ephemera (including realia), if there is no “author” or “artist” involved, properly speaking, enter the name of the manufacturer.

Use of relator terms (relationship designators):  All Creator field name entries should have a relator term that indicates the specific role being played by the indicated entity in the creation of the item.  The list of terms can be found in the LC MARC documentation site for relators: http://www.loc.gov/marc/relators/relaterm.html. Use the terms themselves (the textual strings) rather than the accompanying codes.  Separate the name from the relator term with a comma-space.  Select the most specific term that is appropriate.

Principal sources: RDA 9.1, 9.2, 11.1, 11.2, 6.27, 6.28; Library of Congress Authorities; Library of Congress MARC21 Code List for Relators

Contributor [DC: Contributor]

Enter in the Contributor field any entities (persons or corporate bodies) that are listed on or associated with the item that do not have primary responsibility but that are in some manner involved in the creation of the item.  Repeat the field as needed to record all contributors.  Follow the same protocols for data entry as those outlined for Creator supra.  For books and documents, contributors would include such entities as additional authors and illustrators; for films and video recordings, editors, cinematographers, writers, production designers, producers, etc.; for sound recordings, performing artists (if the Creator entry is the composer).  Use appropriate relator terms.

Principal sources: RDA 18.4, 19.3, 20.2; Library of Congress Authorities; Library of Congress MARC21 Code List for Relators

Publisher [DC: Publisher]

Not all items will be formally published.  Realia, artifacts, and photographs, for example, are not typically thought of as “published”; and some types of items normally published, such as video recordings, may be “singular” or “unique” items that have not been manufactured or reproduced (e.g., event-captures that are locally filmed and produced).  If the item is formally published, enter the data exactly as they appear on the item in the Publisher field.  If more than one publisher is listed, enter the publisher most prominently displayed and/or listed first.  There is no need to use an authorized form of the name.  In the MARC format, a place of publication is always supplied with the publisher information. The Dublin Core element set does not provide a way for separately recording the publisher location.  If the recording of the location of the publisher is deemed important, e.g., for purposes of distinguishing the publisher’s name from other publishers with the same name, or identifying further the name of publisher without any name recognition, or for any other reason, then add the location of the publisher to the Publisher field after the name of the publisher, separated from the name by a comma-space.  If more than one publisher location is listed on the item, select the one most prominently listed and/or associated with the “headquarters” or “home office” of the publisher.

Principal sources: RDA 2.8.4, 2.8.2

Date [DC: Date]

Enter in the Date field the date of publication of the published item, or, if the item is not formally published, either (a) the date of manufacture or creation, or (b) the date of distribution (if all other dates are missing or unknown).  If the only date on the item is a copyright date, treat the copyright date as the date of the item.  If a date, in any of the senses specified supra, is not found anywhere on the item, or if the date is not known by any other means, estimate a date and enter it in the Date field followed by a parenthetical qualifier explaining the nature of the date, e.g., 1979 (probable date), 2011 (estimated date), 1995 (conjectural date), etc.  Format the date entry according to the data standards specified in the W3C Date and Time Formats: http://www.w3.org/TR/NOTE-datetime. Make the date entry as specific as possible, given the information that is available.  At a minimum, enter the year or a probable year.

Principal sources: RDA 2.8.6, 2.9.6, 2.10.6, 7.11.3; W3C Date and Time Formats

Extent [DC: Extent]

Determine the physical dimensions, duration, page count, and/or file size of the item (as the case may be) and enter the number, with the appropriate unit-measure indicator, in the Extent field.  For books and documents and other kinds of textual materials, enter the total number of pages, followed by pages.  Enter each distinct sequence of pagination as it occurs in the item, separated by a comma-space.  Count as pages in a sequence only pages that are actually numbered.  For example, in a book with a preface and forward numbered i-xxxvii, a main-text numbered 3-347, and three or four unnumbered pages at the end, enter xxxviii, 347 pages.  If a textual item lacks numbered pages, count the pages and enter the number in brackets, or enter one volume (unpaged).  For video and sound recordings, enter the total duration in minutes and seconds, or, preferably, to the nearest minute (rounding up), followed by minutes or __ minutes, __ seconds.  For still images (photographs, slides, charts, cards, paintings, prints, etc.), enter the total number of distinct items, followed by the specific material unit name, and record the physical dimension (height and width) in centimeters (add these physical dimension data only if dealing with a single item or with a set of uniformly-sized items).  Example:  3 prints, 21 x 28 cm.  Take the specific material unit name for the item from the list provided in RDA 3.4.4.2.  For artifacts and realia, enter the number of distinct physical items, followed by the specific material unit name, and record the physical dimensions of the item in centimeters for height and width (and for depth, if three-dimensional).  Example: 1 statue, 48 x 25 x 22 cm.  Select the material unit names from the Getty Art and Architectural Thesaurus: http://www.getty.edu/research/tools/vocabularies/aat/.  Use a term with the appropriate specificity.

Principal sources: RDA 3.4.5, 3.4.4, 3.4.4.2, 3.5.3, 7.22; Getty Art and Architectural Thesaurus

Medium [DC: Medium]

Enter the type of material carrier for the item’s intellectual content in the Medium field by selecting from the controlled vocabulary list in RDA 3.3.1.3.  This list covers books and documents, video recordings, sound recordings, microfilm/fiche, still images, and computer files.  For artifacts and realia, select from the controlled vocabulary for “base materials” in RDA 3.6.1.3, and, where appropriate or necessary, add to that term a term from the “applied materials” controlled vocabulary in RDA 3.7.1.3.  Separate the two terms by a comma-space.

Principal sources: RDA 3.3.1.3, 3.6.1.3, 3.7.1.3

Type [DC: Type]

Enter in the Type field the term from the DCMI Type Vocabulary that most closely corresponds to the content or genre of the item: http://dublincore.org/documents/dcmi-type-vocabulary/#H7.

For books and documents, use Text; for film and video recordings, use MovingImage; for sound recordings, use Sound; for photographs, slides, etc., use Image or StillImage; for computer files, use Software; for realia and artifacts, use PhysicalObject.

Principal sources: DCMI Type Vocabulary

Digital Format [DC: Format]

Enter the name for the digital file format associated with the collection item.  Select the name from the list in the Internet Media Type thesaurus: http://www.iana.org/assignments/media-types/media-types.xhtml#audio.  This field should preserve the distinction between born digital objects and digitized objects.  The digital file format for a VHS video, for example, or for a paper copy of a textbook, should be the type of file resulting from the digitization of the original materials.  On the other hand, an already-electronic item, such as a Word or Excel computer file, should be coded for that specific type of (original) electronic file format.  Examples of codes we are likely to use:  ms-powerpoint, ms-excel, ms-word, zip, mp4, mpeg, jpeg, tiff, plain, richtext, etc.

Principal sources:  IANA Media Types

Table of Contents [DC: Table of Contents]

Enter a list of the subunits of an item if the item is so divided.  This field will be used most often with books and other textual documents that have a formal table of contents page.  Enter the data as it appears in the item, with the following exceptions:  (a) do not enter chapter numbers or section headings; (b) do not record pagination data; (c) omit mention of subunits such as acknowledgements and notes; (d) do not provide any end punctuation; (e) if the title of the subunit includes a subtitle, separate the title from the subtitle with a space-colon-space.  Record bibliography, sources, index, preface, introduction, etc., if any of them is present in the TOC.  If a subunit includes a named author (for example, Preface by Richard Miller), record the subunit title and the author’s name, separated by a space-forward slash (/)-space.  Separate each distinct subunit with a full enter line-break.

Principal sources: RDA 7.16, 25.1

Summary [DC: Abstract]

Use this field to enter a concise summary of the intellectual content of the resource.  Record the summary as a free-text description in standard-written English.  The entry should not exceed one paragraph in length.  By “intellectual content” is meant what the resource is about, e.g., the thesis or subject matter of a book, the topic of an address or speech, the plot of a motion picture, etc.  For sound recordings of performed music, describe the artist(s), performer(s), the name(s) of the composition(s) played, and perhaps the date and venue of the performance.  For photographs and other kinds of images, describe what the image is an image of, noting time, place, historical background, and other relevant details.  Do not use this field for resources that do not have intellectual content in the straightforward sense, e.g., certain kinds of realia.  Reserve the description of those kinds of resources for the Description field (infra). 

Principal sources:  RDA 7.10, 7.11, 7.15, 7.23, 7.24 (and chapter 7 passim)

Description [DC: Description]

Enter in this field any useful information about the item that is not related to its intellectual content, e.g., peculiarities of size and materials, other physical characteristics not noted elsewhere in the record, publication frequency, historical provenance, ownership, custodial history, use, idiosyncrasies of language, etc.  Use this field specifically to describe realia.

Principal sources: RDA 2.17, 2.18, 3.8-3.21

Language [DC: Language]

Record the language or languages of the resource, if applicable (this will apply primarily to texts and other printed materials, video recordings, and non-musical sound recordings).  Use the three letter ISO 639-2 code for the language: http://www.loc.gov/standards/iso639-2/php/code_list.php

Provide the natural-language string equivalent for the code in the Description field, e.g., In English.  Record as many languages as are present and/or relevant.

Principal sources: Library of Congress Standard ISO 636-2/Codes for the Representation of the Names of Languages, RDA 7.12

Subject [DC: Subject]

Use the Subject field to indicate what the resource is about, i.e., its subject matter, topic, areas of concern, etc.  Use as many terms as necessary to capture the resource’s subject content.  A general rule of thumb is to assign a separate heading for any subject content that is treated by or found in one-fifth or more of the resource’s content.  If a resource has more than one subject, assign as many subject terms as appropriate to cover all the subjects.  A single subject may sometimes require more than one subject term to adequately describe.  Subject terms should be the most specific terms that apply to the subject content of the resource.  If the resource is not “about” anything in the straightforward sense (it lacks intellectual content, for example, or is a type of realia, etc.), then use the Subject field to assign an appropriate genre term (a term which indicates what the resource is).  Use the most specific genre term that correctly applies to the resource.  Subject terms should be taken from the Library of Congress Subject Headings thesaurus: http://authorities.loc.gov/. This thesaurus can also be accessed through Classification Web (http://classificationweb.net/) or through the authorities index (“LCSH”) in the OCLC Connexion client.  The Connexion client interface provides a browse list for keyword input search terms and is, for that reason, the easiest way to find large numbers of relevant terms.  Subject terms in the LCSH thesaurus will often be sub-divided, that is, they will contain additional terms following the main term that narrow or render more specific the meaning, application, scope, etc., of the main term.  These subdivision terms may be topical, geographical, or chronological.  In the MARC21 format, subdivisions are coded in separate subfields.  Because we are working in Dublin Core, MARC syntax will not be used.  Instead, if LCSH subject terms are entered that include subdivisions, the main term should be separated syntactically from the subdivision with no space-double dash-no space punctuation.  Here are some examples:  Railroads (single subject term); Railroads—19^th century (chronological subdivision); Railroads—Pennsylvania (geographical subdivision); Railroads—Buildings and structures (topical subdivision).  Some subject terms may be subdivided more than once, e.g., a subject may include both a topical, geographical, and/or topical subdivision: Railroads—Pennsylvania—19^th century.  It is, of course, up to the cataloger to determine whether a resource should take a subject term that includes a subdivision and/or subdivisions.  Because of the complexity of subject-term construction in the LCSH thesaurus, however, care should be taken to use extensively subdivided subject terms only when absolutely necessary.  Many of these types of terms are not “pre-coordinated,” i.e., they are not constructed ahead of time by LC but must be put together by the cataloger according to detailed and often complex sets of rules, and only highly trained catalogers can be expected to construct them correctly.  Accordingly, for purposes of metadata subject entry in the Heritage collection, the cataloger should limit subject terms to those that are relatively uncomplicated (not subdivided or extensively subdivided), or, if extensively subdivided, to those subject strings whose construction has been pre-coordinated.  The other two subject thesauri that can be consulted—the Getty Art and Architecture Thesaurus and the Library of Congress Thesaurus for Graphic Materials—should be used primarily for genre terms.  The OCLC Connexion client authorities search also provides a genre index, although the terms in this index deal for the most part with audio and visual recordings and films.

Principal Sources:  Library of Congress Subject Headings, Getty Art and Architecture Thesaurus, Library of Congress Thesaurus for Graphic Materials

Spatial Coverage [DC: Spatial]

Enter in this field subject terms that describe the spatial topic of the resource’s content.  A spatial topic would include any of the following: the geographic location(s) discussed by or depicted in the resource; the jurisdiction(s) (country, state, city, etc.) under which the resource is relevant or applicable.  Do not use this element to record the place where the resource originated or its place of publication.  Use either the LC authorities (http://authorities.loc.gov/) or the Getty Thesaurus of Geographical Names (http://www.getty.edu/research/tools/vocabularies/tgn/index.html).

Follow the same kinds of rules and considerations here as apply to subject term construction and entry.

Principal Sources:  Library of Congress Geographic Authorities, Getty Thesaurus of Geographical Names

Temporal Coverage [DC: Temporal]

Enter in this field subject terms that describe the temporal topic of the resource’s content.  A temporal topic would include the time period covered by, discussed in, or represented by the resource’s intellectual content.  This might be a century, a decade, a year, a week or day, or a specific date or set of dates.  Do not use this element to record the time or date on which a resource was created, produced, or published.  For specific dates, use the WT3 Date and Time Format (http://www.w3.org/TR/NOTE-datetime); for time periods, generally use the Library of Congress Subject Headings (which includes chronological subject terms for centuries and for some decades and some specific years).

Principal Sources: Library of Congress Subject Heading, WT3 Date and Time Format

Is Part of [DC: isPartOf]

Use this field to indicate the whole to which a part belongs.  Sometimes, for example, it may be necessary or useful to catalog separately a whole and the parts making up the whole: a separate record for a group or collection or a single composite item, and separate records for the components of the collection or group or the parts of the composite item.  Think of, say, a collection of knick knacks (as opposed to just a random aggregation of them), or a group of letters united by a theme or set of themes (X’s correspondence with Y, e.g.).  This field is a way to “link” such resources together and is used complementarily with the hasPart element.  It will be the judgment of the Heritage curator and/or cataloger whether any particular resource should be analyzed in terms of parts and wholes.  In formal semantics, the “triple” or statement X is a part of Y is composed of a subject (X), a predicate (is part of) and an object (Y).  The things which belong to the class denoted by X are called the domain of X; the things which belong to the class denoted by Y are called the range of Y.  If the resource being cataloged is part of another resource (which has itself also been cataloged as a “whole”), then the range of the object in the record for the resource part should be specified by the (de-referencable) URL for the record of the “whole.”  (Dereferencing the link should take the user to the record for the whole.)

Principle Sources:  No formal rules or vocabularies.

Has Part [DC: hasPart]

Use this field to indicate the part that belongs to a particular whole.  For an explanation of use, application, semantics, etc., see the immediately preceding entry for Is Part Of.  This field will always be used in coordination with Is Part Of.  Each record of a “part” will have an Is Part Of field that references (and links to) the record for the whole; and each record of a whole will have one or more Has Part fields, each of which will reference (and link to) the record(s) for the part(s).

Principal Sources: No formal rules or vocabularies.

Relation [DC: Relation]

Both the Is Part of and Has Part elements referenced supra are refinements of the basic Dublin Core element Relation.  The generic Relation element is a general catch-all element that includes or can stand for or can be refined by any number of reciprocal relations in addition to Is Part of and Has Part, e.g., is version of/has version, is replaced by/replaces, required by/requires, is referenced by/references, is format of/has format, conforms to.  It is unlikely that relationships between resources in the Heritage collection will require description in terms of any of these additional enhancements; and because the enhancements of the Relation element are already available as separate elements in the Dublin Core metadata element set in the Omeka metadata editor, there is little or no reason to actually use the generic Relation element itself.  Accordingly, in the rare case where some relation other than part-whole should be described, use the appropriate refinement of the Relation element rather than the Relation element.  An explanation of these additional refinements can be found in the Dublin Core documentation:

http://dublincore.org/documents/usageguide/elements.shtml#relation

Principal Sources: Dublin Core Metadata Initiative: The Elements

Rights [DC: Rights]

Use this field to enter any information about any and all legal rights pertaining to the resource and/or digital reproduction of the resource.  This would include such things as the copyright, its status and date, the holder of the copyright, and the copyright holder’s contact information; physical ownership rights, if applicable; restrictions on the access to or use of the original item; and terms and conditions for the use of the digital reproductions, including information about copying, distribution, etc.  It is recommended that the Heritage Center draft a general statement regarding copyright, access, terms of use, copying, etc., and that this statement be contained in a free-standing webpage that can be linked to by a standard URL.  The URL for the statement page would then constitute the sole entry for the Rights element field.  The Rights field could also be repeated if additional information of a more specific nature (in the form of free-text) needed to be supplied for a particular resource.

Principal Sources: None

Identifier [DC: Identifier]

Record in the Identifier field a unique string or URL associated with the resource.  If the Omeka system automatically generates a URL for the record describing the resource and populates the Identifier field of the record with the URL, then this URL shall serve as the primary identifier for purposes of harvesting.  It will also be useful to generate a local filename identifier in a second field even if there is a system-generated URL identifier.  This can be done following the instructions in DACS 2.1.  The string shall consist of the concatenation of a local identifier, a repository code identifier, and a country identifier.  The local identifier shall consist of an abbreviation for the collection to which the item belongs + a standard sequence accession number.  The repository code identifier shall come from the Library of Congress list of institutional repository codes.  The country identifier shall come from the ISO 3166-2 (Codes for the representation of countries and their subdivisions).  A sample identifier would then look like this:  PT01-oktcc-US, where PT = the abbreviation for the collection (Publications and Textbooks), 01 = the accession number, oktcc = the LC repository code for Tulsa Community College, and US = the two-character ISO 3166-2 country code.

Principal Sources: Describing Archives: A Content Standard, Uniform Resource Identifier (http://www.ietf.org/rfc/rfc2396.txt), Library of Congress MARC Code List for Organizations (http://www.loc.gov/marc/organizations/orgshome.html), ISO 3166-2 (http://www.iso.org/iso/catalogue_detail?csnumber=63546).

Source [DC: Source]

Enter in the Source field information about a related resource from which the described resource is derived.  This field is typically used to indicate the original resource from which a digital resource has been derived.  Since most records in the Heritage collection will be descriptions of the original resources rather than their digital counterparts (except in cases of born-digital objects), this field will not normally be used.  The only exception will be in cases in which it is important to describe (for whatever reason) the digitized object per se rather than the original from which it is derived.