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.

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.

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:

• Simple DC: http://dublincore.org/schemas/xmls/qdc/2006/01/06/dc.xsd

• Qualified DC: http://dublincore.org/schemas/xmls/qdc/2006/01/06/dcterms.xsd

The most recent version of the OLAC metadata schema (along with a sample record) can be found at:

• Schema: http://www.language-archives.org/OLAC/1.1/olac.xsd

• Example: http://www.language-archives.org/OLAC/1.1/olac.xml

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:

An example of an OLAC static repository is found at:

http://www.language-archives.org/OLAC/1.1/static-repository.xml

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.

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.)

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:

In order to do this, an organization representing that subcommunity (say, example.org) would define a new XML schema as follows:

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.

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:

http://www.language-archives.org/OLAC/1.1/olac-extension.xsd

The summary documentation includes six mandatory elements:

shortName

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.

The information contained in the summary documentation is extracted for display on the OLAC website in OLAC-Extensions or OLAC-Third-Party.