This document defines the format used by the Open Language Archives Community
[OLAC] for the interchange of metadata within the framework of the
Open Archives Initiative [OAI]. The metadata set is based on the
complete set of Dublin Core metadata terms [DCMT], but the format
allows for the use of extensions to express community-specific qualifiers.

This revision of the standard incorporates the upgrade
from version 1.0 to version 1.1 of the OLAC
metadata schema. The primary change in that upgrade
involves the upgrade of the [OLAC-Language]
vocabulary from "x-" style codes to ISO 639 codes.

Table of contents

1. Introduction

This document defines the metadata format used by the
Open Language Archives Community [OLAC] to
describe language resources and to provide associated services.
OLAC uses an XML format to interchange language-resource metadata within the
framework of the Open Archives Initiative [OAI].

Section 2 of this document describes the set of
metadata elements and qualifiers used in resource
description. Section 3 goes on to describe the XML format used to
represent metadata. Section 4 describes how OLAC extensions
are used. Section 5 describes how a third-party extension is formally
defined, while section 6 describes how an extension is documented.

2. The metadata set

The OLAC metadata set is based on the Dublin Core (DC) metadata set and uses
all fifteen elements defined in that standard. (The
rationale for following DC is discussed in the OLAC white paper
[OLAC-WP].) To provide greater precision in resource description,
OLAC follows the DC recommendation for qualifying elements by means of
element refinements or encoding schemes. The
authoritative definition of all DC elements, refinements, and schemes is found
in [DCMT].

The present document specifies only the formal (syntactic)
requirements on OLAC metadata description. It does not provide a complete set of advice
about what the metadata elements, refinements, and schemes mean or about how they should be used.
Such advice is supplied in an OLAC informational note [OLAC-Usage].

The qualifiers recommended by DC are applicable across a wide range of resources. However, the language resource
community has a number of resource description requirements that
are not met by these general standards. In order to meet these
needs, members of OLAC have developed community-specific
qualifiers, and the community at large has adopted some of them (following
[OLAC-Process]) as recommended best practice for language
resource description. These recommended qualifiers are listed in
[OLAC-Extensions] and the manner of using them in resource
description is documented below in Using OLAC extensions.

3. The metadata format

The XML implementation of OLAC metadata follows the
"Guidelines for implementing Dublin Core in XML" [DCXML]. The
OLAC metadata schema is an application profile [HP2000] that
incorporates the elements from the two metadata schemas (Simple DC and Qualified
DC) developed by the DC Architecture Working Group for implementing qualified DC [DC-Schemas]. The OLAC metadata schema and the schemas for all OLAC extensions use the following Dublin Core schemas:

The container for an OLAC metadata record is the element <olac>, which is defined in a namespace called "http://www.language-archives.org/OLAC/1.1/". In the sample record that follows, the namespace prefix olac is used, and the DC namespace is declared to be the default so that the metadata element tags need not be prefixed. For instance, the following is a valid OLAC metadata record:

When OLAC metadata is stored in a static repository
[OLAC-Repositories] then namespace declarations can be
removed from the individual OLAC records and put on the
root element. Accordingly, the above record can be simplified as
follows:

In addition to these core DC metadata elements, a record may use DC qualifiers
following the guidelines given in [DCXML].
A qualified element may specify a refinement
(using an element defined in the
dcterms namespace) or an encoding scheme (using a scheme defined
in dcterms as the value of the xsi:type attribute), or
both. The dcterms
namespace must be declared as follows: xmlns:dcterms="http://purl.org/dc/terms/".
For instance, the following element represents a creation date
encoded in the W3C date and time format:

The xsi:type attribute is a directive that is built into the
XML Schema standard [XMLS]. It functions to override the
definition of the current element by the type definition named in its
value. In this example, dcterms:W3C-DTF resolves to
the definition for a complex type named W3C-DTF in the XML schema
that defines the dcterms namespace.

Any element may also use the xml:lang
attribute to indicate the language of the element
content. Though the [XML-Lang] specification
permits a wider range of values for this attribute, it is recommended for purposes of interoperation in the
OLAC context that only identifiers that conform to the [OLAC-Language] specification be used.
The vocabulary of recommended language identifiers consists of all active codes for individual languages
from any part of ISO 639; see the code tables at the
[ISO639-3] web site. For instance, the following represents a
title in the Lau language of Solomon Islands
(identified by its ISO 639-3 code) and its
translation into English (identified by its ISO 639-1 code):

By using multiple instances of the metadata elements
tagged for different languages, data providers may
offer a metadata record in multiple languages. If no
xml:lang attribute is given, a service provider
may infer that the language of the element content is
English.

4. Using OLAC extensions

The xsi:type mechanism
has access to the full power of XML Schema, and may be used
for a variety of purposes other than narrowing the meaning
of the element, or restricting element content
(as done for DC qualifiers). It may do both simultaneously, and
it may also define additional attributes, which
may in turn be restricted by patterns or enumerations.

OLAC extensions use a convention of defining an olac:code attribute
to hold restricted element values. This leaves the element content to be
used for an unrestricted comment. When code and content are used together,
the content provides an escape hatch for expressing a more precise resource
description than is possible with the restricted code value alone. The
olac:code attribute is also defined to be optional, which provides a
migration path for adding precision to legacy data that is not originally
qualified. For instance, the following are three steps in the migration of
describing a resource about the Dschang language of Cameroon:

All metadata extensions that have been adopted by OLAC
as recommended best practice are defined in the olac
namespace schema. See [OLAC-Extensions] for the complete list of
the recommended extensions and links to their full documentation.

Some OLAC extensions use vocabularies
defined in OLAC recommendations, while others (e.g.
the language codes) use externally-defined vocabularies that
are not controlled by OLAC and are not subject to the OLAC process. In such cases, the document describing the
OLAC extension does not define the vocabulary, but simply
refers to the external definition.

Once an extension has been adopted as an OLAC recommendation,
subsequent changes must be carefully controlled. Redefining a code value
to mean something different would cause problems for all existing metadata records
that employ the existing code value. To widen the meaning of a code is safe since the code would still be correct in all existing uses. However, when the
interpretation of a code is narrowed or shifted, there will be existing uses of the code that are no longer valid. Thus, the existing code
should be retired and a new code adopted to replace it. (If it is not possible to meet
this requirement, then the old version of the vocabulary must retain its adopted status while
the new version is assigned candidate status for a period of review and testing.)

5. Defining a third-party extension

An OLAC metadata record may use extensions from other namespaces.
This makes it possible for subcommunities within OLAC to develop and
share metadata extensions that are specific to a common special interest.
By using xsi:type, it is possible to extend the OLAC
application profile without modifying the OLAC schema.

For instance, suppose that a given subcommunity required greater
precision in identifying the roles of contributors than is possible with
the OLAC Role vocabulary [OLAC-Role], and thus defined a
specialized vocabulary that included (among others) the term
commentator. This specialized vocabulary and code value could
be represented as follows in a metadata element:

This schema contains four top-level elements: (1) a directive to
import the schema for DC elements (which is needed since the complexType
extends a type defined in that schema); (2) an annotation providing summary
documentation for the extension; (3) a complexType declaration for
the overriding element definition which defines a namespace:code attribute
with values taken from the specialized vocabulary; and (4) a simpleType
declaration which defines the vocabulary itself. Refer to the XML Schema
specification [XMLS] and primer [XMLSP] for documentation
on how to define types in XML.

The extension schema is associated with a target
namespace (namely, http://www.example.org/) and stored in a
specific location on the developer's web site (e.g.,
http://www.example.org/example.xsd). Now an OLAC metadata
record using the desired metadata element can be created as follows:

Developers of third-party extensions should note that standard OLAC
service providers harvest five things from each metadata element:
the tag name, the element content, the value of the
xml:lang attribute, the value of the
xsi:type attribute, and the value of the olac:code attribute.
Third-party extensions may define attributes to hold coded values
(e.g. example:code), to be exploited by specialized
subcommunity service providers.
However, a third-party extension cannot use the
olac:code attribute, and any new attributes
defined by a third-party extension are not validated or used by standard OLAC services.

In order to be listed on the OLAC website [OLAC-Third-Party], a third-party extension
must be germane to the mission of OLAC, and it
must represent a new perspective on resource description.
The latter condition prevents extensions which simply
rename all the terms in an existing vocabulary, or which
copy an existing vocabulary with minor modifications or additions.
Note that, when the purpose of a third-party extension is to
augment an existing OLAC extension by adding more vocabulary items,
the third-party extension must only provide the new terms,
to avoid proliferating copies of OLAC terms.

6. Documenting an extension

Each extension should be accompanied with human-readable documentation
that provides the semantics for the vocabulary.
Additionally, the schema defining an extension should provide summary
documentation as shown below.

This documentation should be placed after
the import statement(s) and before the type declarations; see the example above in Defining a third-party
extension.
The <olac-extension> element should be embedded in
<xs:appinfo> within
<xs:annotation>). The <olac-extension>
element is defined
in:

The short name by which the extension
is accessed. This name includes a
namespace prefix and should be the same as the name of the
<complexType> that defines the
extension.

longName

The full name of the extension
for use as a title in documentation.

versionDate

The
date of the latest version of the extension. The date should be modified
only when the extension definition changes in such a way as to alter the
set of element instances that would be accepted as valid. The version date
should not be modified when only documentation has changed. Use the W3C
date format, e.g. 2002-11-30 (for 30 November 2002).

description

A summary description of what the extension is
used for.

appliesTo

The content names a Dublin Core element with which
the extension may be used. This element is repeated if the extension
applies to more than one element.

documentation

The URI for a complete document that defines and exemplifies the extension. If the extension involves a controlled vocabulary, the document should also enumerate and define the terms of the vocabulary.