OLAC Metadata Set

This document specifies the metadata set used by the Open Language Archives Community [OLAC] for the interchange of metadata within the framework of the Open Archives Initiative [OAI]. This document is superseded by the OLAC Metadata standard: http://www.language-archives.org/OLAC/metadata.html

Adds scheme attribute (see sections 1 and 2). The lang attribute on <olac> is renamed to langs. Following [DC-Q], adds alternative as a possible refinement for Title so that the original title can be distinguished from translations. Type.data is renamed as Type.linguistic. These changes are reflected in version 0.4 of the OLAC metadata schema which is being released at the same time. (Another significant change to the schema is that the use of capitalization in element names now conforms to the usage in the examples in this document.) Significant addition to discussion of Coverage. Numerous minor editorial revisions.

A Contributor may be a person, an organization, or a service. Contributor is closely related to Creator. The difference has to do with degree of responsibility for the content. The Contributor designation is used for those entities whose role in the creation of the resource is not great enough to merit recognition as a primary source of the intellectual content. This element may be used to identify institutions that sponsored or funded the work. It may be used to identify individuals who played a secondary role in the development of the resource. As a rule of thumb, Creator is used when the contribution is such that it would be cited in the "author" field of a bibliographic entry, and Contributor is used otherwise.

Recommended best practice is to identify the entity by means of a name and to give the name in a form that is ready for sorting within an index. For the names of persons, this means that the name should be given in inverted order with the surname first. For the names of organizations, this means that any initial article should be omitted. When a resource has more than one contributor, use a separate Contributor element for each one.

The refine attribute is optionally used to specify the role (such as transcriber, sponsor, and so on) played by the named entity in the creation of the resource. The role is expressed by means of a controlled vocabulary; see [OLAC-Role] for the definition of the vocabulary.

Also lang and scheme (see section 2).

A generic contributor:

<contributor>Smith, John L.</contributor>

A funding agency:

<contributor refine="sponsor">National Science
    Foundation</contributor>

The person who performed a role for which there is not a suitable code:

<contributor>Smith, John L. (format conversion)</contributor>

Coverage will typically include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity). [DCMES1.1]

Recommended best practice is to select a value from a controlled vocabulary that is identified in the scheme attribute (for example, the Thesaurus of Geographic Names [TGN]). Where appropriate, named places or time periods should be used in preference to numeric identifiers such as sets of coordinates or date ranges.

In the OLAC context, service providers already have a database that maps languages to the countries in which they are spoken [OLAC-Language]. Coverage should not be used to duplicate this information; rather service providers will support searches concerning languages spoken in a given country by referring to the language database. Coverage should be used geographically only when the language involved has a wide distribution and the resource focuses on its use in a particular region or geopolitical jurisdiction, or conversely, when the resource deals with a region that encompasses multiple languages.

A resource about English in India:

<subject.language code="en"/>
<coverage>India</coverage>

A resource about languages spoken on Guadalcanal:

<coverage scheme="TGN">Guadalcanal (island)</coverage>

A resource about language use in the 19th century:

<coverage>19th century</coverage>

A Creator may be a person, an organization, or a service. Creator is closely related to Contributor. In determining whether an entity is a Creator (as opposed to a Contributor), use the same criteria that are followed for deciding that an entity should be listed in the "author" slot of a bibliographic reference as a primary source of the intellectual content. Entities that do not merit that level of recognition should be treated as Contributors.

Recommended best practice is to identify a Creator by means of a name and to give the name in a form that is ready for sorting within an index. For the names of persons, this means that the name should be given in inverted order with the surname first. For the names of organizations, this means that any initial article should be omitted. When a resource has more than one creator, use a separate Creator element for each one.

The refine attribute is optionally used to specify the role (such as author, editor, translator, and so on) played by the named entity in the creation of the resource. The role is expressed by means of a controlled vocabulary; see [OLAC-Role] for the definition of the vocabulary.

Also lang and scheme (see section 2).

A personal author:

<creator>Bloomfield, Leonard</creator>

An institutional author:

<creator>Linguistic Society of America</creator>

An editor:

<creator refine="editor">Sapir, Edward</creator>

Recommended best practice is to use a coded value (see below) when possible, since that guarantees that a service provider can do a straight alphanumeric sort to put collections of metadata descriptions in correct chronological order. The element content may always be used to express date-related values or comments that cannot be fitted into the encoding standard.

The code attribute is used to hold a standardized encoding of a date. Following [DCMES1.1], OLAC uses the YYYY-MM-DD format as defined in [W3CDTF]. When a month or day value is less than 10, use a leading 0 to maintain a two-digit length. The encoded value may be for the year alone, for the year and month, or for an exact date. A range of years is also a valid value for this attribute; in this case both years must be four-digit values and the earliest year should come first. Thus, the encoded value may match one of the four following patterns: YYYY, YYYY-MM, YYYY-MM-DD, or YYYY-YYYY.

The refine attribute is optionally used to refine the meaning of the date using values from a controlled vocabulary (for instance, date of creation versus date of issue versus date of modification, and so on). The vocabulary for refinements to Date is defined in [DC-Q].

A Date with no refinement will be assumed to be the date of issue (i.e. publication). A single resource should not have more than one instance of each date refinement. In selecting a single date to associate with a resource, a service provider will select the most recent of date created, issued, or modified.

Also lang and scheme (see section 2).

A typical year of publication:

<date code="1992"/>

A resource modified on October 16, 1996:

<date refine="modified" code="1996-10-16"/>

A resource from approximately 1950:

<date code="1950">circa 1950</date>

Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content, or a free-text account of the content. [DCMES1.1]

No formatting conventions are defined within the text of Description. Service providers may format the entire Description as a single paragraph, collapsing adjacent white space characters into a single space.

When there is a URL for a document that describes the resource, use a separate Description element to encode just that URL. A Description that begins with "http:" will be interpreted by service providers as consisting solely of a URL and will be presented as a link in user interfaces. Service providers are not obliged to search other Description text for the occurrence of URLs.

A prose description of a resource:

<description>The CALLHOME Japanese corpus of telephone speech consists
    of 120 unscripted telephone conversations between native speakers
    of Japanese. All calls, which lasted up to 30 minutes, originated
    in North America and were placed to locations overseas (typically
    Japan). Most participants called family members or close friends.
    This corpus contains speech data files ONLY, along with the
    minimal amount of documentation needed to describe the contents
    and format of the speech files and the software packages needed to
    uncompress the speech data. </description>

A reference to an existing on-line description:

<description>http://www.ldc.upenn.edu/Catalog/LDC96S37.html
</description>

Typically, Format may include the media-type or dimensions of the resource. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource. Examples of dimensions include size and duration. [DCMES1.1]

The code attribute should be used to make a precise identification of the format using a controlled vocabulary. This is especially important for digital resources since service providers may use this information to match data resources with the software tools that are appropriate for manipulating them. See [OLAC-Format] for the definition of the vocabulary.

The element content may be left empty, but it would typically be used to add further details about the format of the resource, such as the sampling rate for digital recordings, the size of computer files, the number of pages and dimensions of a book, the appearance of a physical object, and so on.

Also lang and scheme (see section 2).

For a digitally encoded dictionary:

<format code="text/xml">5,237 entries in a 1.2M XML
    file.</format>

For a digitally recorded text:

<format code="audio/wav">Duration: 153 seconds. Size: 3.3M.
    Sampling: 1 channel, 22 KHz, 8 bits.</format>

This element is used in the description of executable programs to identify the kind of CPU that is needed to run them.

The code attribute is used to make a precise identification of the required CPU using a controlled vocabulary. See [OLAC-CPU] for the definition of the vocabulary.

The element content is typically left empty, but it can be used to add further details about the hardware required for running the resource. These could go beyond CPU details to include memory, disk, and so on.

Also lang and scheme (see section 2).

Software that runs on a Power PC:

<format.cpu code="ppc"/>

Software that runs on the Intel family of processors but needs at least 64 megabytes of memory:

<format.cpu code="x86">At least 64M memory</format.cpu>

For a resource that is a digitally encoded text, Format.encoding names the encoded character set it uses. For a resource that is a font, Format.encoding names an encoded character set that it is able to render. For a resource that is a software application, Format.encoding names an encoded character set that it can read as input or write as output. Service providers will use this information to match data files with the software tools that can be applied to them.

The code attribute should be used to identify the character set using a controlled vocabulary. See [OLAC-Encoding] for the definition of the vocabulary.

Recommended best practice is to specify the encoding via the code attribute while leaving the element content empty. Use the element content only when the controlled vocabulary does not offer an appropriate code, or when further explanation about a custom encoding is needed.

Also lang and scheme (see section 2).

For a resource that is a text file including markup, Format.markup identifies the markup system it uses, such as the SGML DTD, the XML Schema, the set of Standard Format markers, and the like. For a resource that is a stylesheet or a software application, Format.markup names a markup scheme that it can read as input or write as output. Service providers will use this information to match data files with the software tools that can be applied to them.

Recommended best practice is to identify the markup scheme by a URI giving an OAI identifier for the markup scheme as a resource in an OLAC archive. Thus, if the DTD, Schema, or markup documentation is not already archived in an OLAC repository, the depositor of a marked-up resource should also deposit the documentation for the markup scheme.

A resource identified in Format.markup should not also be listed with the requires refinement of Relation.

This element is used in the description of executable programs to identify the operating system environment that is needed to run them. If the resource is a data file in a format that is typically associated with a particular operating system, use Format only (since cross-platform readers are always a possibility).

Recommended best practice is to specify the operating system via the code attribute. See [OLAC-OS] for the definition of the controlled vocabulary used for this purpose.

The element content would typically be left empty, but it can be used to add further details about the specific operating system version that is required, or about other system software components that are required.

Also lang and scheme (see section 2).

Software that runs under OS/2:

<format.os code="OS2"/>

Software that runs only under Windows NT 4.0 or higher:

<format.os code="MSWindows">NT 4.0 or higher</format.os>

Identifies a programming language used by software that is distributed in source code form.

Recommended best practice is to specify the programming language via the code attribute. See [OLAC-Sourcecode] for the definition of the controlled vocabulary used for this purpose.

The element content would typically be left empty, but it can be used to add further details about the particular version or dialect that was used.

Also lang and scheme (see section 2).

Source code that is written in C++:

<format.sourcecode code="C"/>

Source code that is written in Java using the version 1.2 library:

<format.sourcecode code="Java">Version 1.2 library</format.sourcecode>

Recommended best practice is to identify the resource by means of a string or number conforming to a globally-known formal identification system. Example formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL)), the Digital Object Identifier (DOI), and the International Standard Book Number (ISBN). [DCMES1.1]

In the case of a resource that is not electronically encoded, but is housed in a conventional archive, Identifier may be used to give a local shelf or box number, or whatever scheme is used to locate a resource within the collection.

Identifiers that begin with "http:" will be interpreted by service providers as URLs and be presented as links in user interfaces. Note that Identifier is to be used only for a URL that retrieves the actual resource; use Description for a URL that retrieves just a description of the resource.

Do not specify the "oai:" identifier for the resource itself as a value of Identifier, since it is already given in <identifier> in the <header> of the <record>s returned by the OAI protocol.

A Uniform Resource Locator for retrieval of an electronically encoded resource:

<identifier>http://arxiv.org/abs/cs.CL/0010033</identifier>

A local identifier for retrieval within a physical collection:

<identifier>Shelf 12, Box 7</identifier>

Language is used for a language the resource is in, as opposed to the language it describes (see Subject.language). It is related to the audience for the work in that it identifies a language that the creator of the resource assumes that its eventual user will understand. When a resource is in more than one language, use a separate Language element for each language.

For a work of literature or other monolingual document aimed at the speakers of a particular language, use Language to identify that language. For a sound recording, use Language for the language being spoken in the recording. For a grammatical description, for instance, use Language for the language the grammar is written in; use Subject.language for the language whose grammar is being described. For an annotated text, use Language for the language in which the annotations are made; use Subject.language for the language of the base text that is being annotated. For a dictionary, use Language for the language in which the definitions are written; use Subject.language for the language whose words are being defined.

The code attribute should be used to make a precise identification of the language using a controlled vocabulary. See [OLAC-Language] for the definition of the vocabulary.

Recommended best practice is to specify the language via the code attribute while leaving the element content empty. Use the element content only when the controlled vocabulary does not offer an appropriate code, or when further specification is needed, such as to name a specific dialect or to give an alternate name that differs from the default name given by the controlled vocabulary.

Service providers should use the code attribute to support searches by language, and may use the element content in searches by keyword. They also may supply the default language name in keyword searching when the element content is missing.

Also lang and scheme (see section 2).

A resource in English about the Sikaiana language:

<language code="en"/>
<subject.language code="x-sil-SKY"/>

A Yemba-French dictionary, where the alternate name Dschang is preferred.

<language code="fr"/>
<subject.language code="x-sil-BAN">Dschang</subject.language>

The American Heritage Dictionary, which is both in and about American English:

<language code="en"/>
<subject.language code="en"/>
<coverage>United States</coverage>

A resource about a language for which the controlled vocabulary does not yet provide a code:

<subject.language>Ancient Sumerian</subject.language>

Examples of a Publisher include a person, an organization, or a service. Typically, the name of a Publisher should be used to indicate the entity. [DCMES1.1]

Recommended best practice is to identify a Publisher by means of a name and to give the name in a form that is ready for sorting within an index. For the names of persons, this means that the name should be given in inverted order with the surname first. For the names of organizations, this means that any initial article should be omitted. When a resource has more than one publisher, use a separate Publisher element for each one.

A typical publisher:

<publisher>Oxford University Press</publisher>

The URL for a publisher:

<publisher>http://www.oup.com/</publisher>

This element is used to document relationships between resources, for instance, part-whole relationships, version relationships, dependency relationships, and so on. When the related resource is also in a participating archive, the reference to the related resource should be by means of an "oai:" identifier. A Relation that begins with "oai:" should be presented by service providers as an active link that retrieves the metadata for that resource.

For a required markup definition (like a DTD or Schema) use Format.markup rather than Relation. When the required software or hardware can be inferred from the Format of the resource, do not also use Relation for this purpose.

When the present resource is a derived work, the source resource is typically indicated by Source. However, there are two cases in which refinements of Relation are used for derived works. The isVersionOf refinement is used when the present resource is a new version or edition with added intellectual content that has been developed by the same creators. When the new version is nothing more than a rendition in a new format, then the isForrmatOf refinement is used.

The refine attribute should be used to clarify the nature of the relationship using values from a controlled vocabulary (for instance, isReplacedBy, requires, hasPart, isPartOf, and so on). The vocabulary for refinements to Relation is defined in [DC-Q].

Also lang and scheme (see section 2).

A link to a required font:

<relation refine="requires">oai:sil:software/ipafont</relation>

Links to the component pieces of a collected work:

<relation refine="hasPart">oai:somearchive:holding126</relation>
<relation refine="hasPart">oai:somearchive:holding127</relation>
<relation refine="hasPart">oai:somearchive:holding128</relation>
<relation refine="hasPart">oai:somearchive:holding129</relation>
<relation refine="hasPart">oai:somearchive:holding130</relation>

A chapter that was published in a book (that does not have an archived metadata record):

<relation refine="isPartOf">In Joel Sherzer and Greg Urban (eds.),
    Native South American discourse , 237-306. Berlin: Mouton.
    </relation>

Typically, a Rights element will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource. [DCMES1.1]

Recommended best practice is to use the code attribute to make a summary statement about rights using a controlled vocabulary. If the coded value adequately documents the rights management issues, leave the element content empty. Otherwise, use the content to add the relevant details. See [OLAC-Rights] for the definition of the vocabulary.

Also lang and scheme (see section 2).

The present resource may be derived from the Source resource in whole or in part. [DCMES1.1] When the Source resource is also available in an on-line archive, recommended best practice is to reference it by means of an "oai:" identifier. In this case service providers should presented the Source as an active link that retrieves the metadata for that resource.

In the legal parlance of intellectual property rights, a "derivative work" is one that is based on one or more preexisting works. This includes cases in which a work may be recast, transformed, or adapted in any way, such as by translation, abridgement, dramatization, recording, transcription, or digital encoding. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship is also a derivative work [Copyright].

This legal definition elucidates the sense of "derived" that is intended in the Dublin Core definition of Source. Note, however, that this overlaps with Relation, since the isFormatOf and isVersionOf refinements both refer to derivative works in the technical sense.

Recommended best practice for OLAC is to reserve the use of Source for cases when the present resource has a substantially different Type or Creator or Title than the Source resource. When the difference from the original work is only a difference of Date or Format or Publisher or Identifier or edition designator in the Title, then use Relation to encode the relationship to the original work.

Source for a digital encoding of a manuscript in a participating archive:

<source>oai:somearchive:holding1023</source>

Source for data extracted from a published source:

<source>Kwara'ae flora vocabulary extracted from Guide to the
        Forests of the British Solomon Islands, by T. C. Whitmore.
        Oxford University Press, 1966.</source>

Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource. [DCMES1.1]

Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme. The scheme attribute is used to identify the scheme.

A Library of Congress subject heading:

<subject scheme="LCSH">African languages</subject>

See Language for a complete discussion (with examples) of using the Language and Subject.language elements.

As with the Language element, a code attribute is used to identify the language precisely.

Also lang and scheme (see section 2).

Typically, a Title will be a name by which the resource is formally known. [DCMES1.1]

A translation of the title can be supplied in a second Title element. Use the lang attribute to identify the language of these elements.

The refine attribute may optionally be used for a single refinement supported by [DC-Q]. The value alternative indicates a form of the title that is used as a substitute or alternative to the formal title of the resource. This qualifier can include abbreviated titles as well as translations. Recommended best practice is that only one instance of Title, namely the original title, be unqualified.

Also lang and scheme (see section 2).

A typical title:

<title>A Dictionary of the Nggela Language</title>

A vernacular title with translation:

<title lang="x-sil-LLU">Na tala 'uria na idulaa diana</title>
<title refine="alternative" lang="en">The road to good reading</title>

Type includes terms describing general categories, functions, genres, or aggregation levels for content. To describe the physical or digital manifestation of the resource, use the Format element. [DCMES1.1]

Recommended best practice is to use the code attribute to identify the type using the Dublin Core Types controlled vocabulary [DC-Type]. The element content is typically left empty. Use the element content only when the controlled vocabulary does not offer an appropriate type, or when further specification is needed.

Also lang and scheme (see section 2).

The resource is a video recording:

<type code="Image"/>

This element is used with resources that are software applications to classify what they are used for.

Recommended best practice is to use the code attribute to identify the functionality using a controlled vocabulary. See [OLAC-Functionality] for the definition of the vocabulary. Use the element content only when the controlled vocabulary does not offer an appropriate code, or when further explanation about the functionality is needed.

Also lang and scheme (see section 2).

For a resource that is information in or about a language, Type.linguistic identifies what kind of information it is from a linguistic standpoint. For a resource that is a software tool, Type.linguistic identifies what kind of information it processes. Service providers may use this information to match data files with software tools that might be applied to them.

Recommended best practice is to the code attribute to identify the linguistic data type using a controlled vocabulary. See [OLAC-Linguistic-Type] for the definition of the vocabulary. The vocabulary uses a two-level coding system. There are four primary types —transcription, annotation, description, and lexicon— each of which have a number of subtypes. Use the element content only when the controlled vocabulary does not offer an appropriate code, or when further explanation about the data type is needed.

Also lang and scheme (see section 2).

The resource describes the grammar of a language:

<type.linguistic code="description/grammar"/>

The resource includes the orthographic transcription of text:

<type.linguistic code="transcription/orthographic"/>