DRAFT 1 -- The DC Kernel Application Profile -- 2007.08.07

This document defines the DC Kernel Application Profile (KAP), specifying its elements and requirements. The DC KAP is designed for providers that need to support the orderly management of their information objects, and wish to do so with minimal overhead in reading and processing metadata descriptions.

The document begins by listing kernel metadata requirements in more detail and correlating them with specific characteristics as found in the kernel metadata specification [KSpec]. It then compares the core DC semantics and DCMI Abstract Model [AModel] with kernel metadata elements and the Electronic Resource Citation (ERC) record structure for holding kernel resource descriptions.

Requirements

The overall goal of low-overhead, orderly management includes the needs to reliably identify problem objects during troubleshooting, and to query collections to produce ordered object subsets for the purpose of collection surveying. Organizations that perform orderly management should also be able to report externally on their support commitments and policies. The KAP frames these needs in the context of the following more specific requirments.

Reduction

Beginning with the 15 basic DC elements, the DC Kernel Specification [KSpec] distills out a smaller subset of elements to produce a concise description for troubleshooting that can be grasped in a glance. The kernel borrows from the journalistic tradition that "boils down" the essence of a story into the "who, what when, where" of an expression of an information resource.

Economy of Expression

To minimize the visual bandwidth in that glance, a simple eye- and machine-readable ERC format is specified that has both a normal and extra concise format (allowing suppression of labels by relying on positional elements). Multi-valued dates and ranges are also allowed so as to avoid having to rely on additional date elements, especially those indicating starts and ends of open-ended ranges.

Predictability

To meet the need for determinism during troubleshooting, the above four elements are required. Some flexibility in that requirement is permitted if the value for the given label is one of nine well-known values for "empty":

:unkn, :unav, :unac, :unap, :unas, :none, :null, :unal, :tba

Sort-Friendliness

To be useful in orderly management, element values are encouraged to be entered in such a way that adjacent records in a collection survey can be meaningfully ordered by simple lexical sort on that element. The "sort-friendly" feature is not a requirement, i.e., providers can opt out if the expense is prohibitive.

Economy of Interpretation

To minimize burden of metadata interpretation by collection manager scripts, the ERC format is based on email headers [ANVL] and may be parsed in two lines of Perl (eg, without a DOM parser as required for XML).

Mapping from Kernel to Dublin Core Elements

Kernel elements are mapped to the 15 Dublin Core elements according to the "story" type.

 erc:  the story of the expression of a resource
    who         from DC Creator, Contributor, or Publisher
    what        from DC Title
    when        from DC Date
    where       from DC Identifier

 about-erc:  the story of a resource's content
    about-who         from DC Subject (personage)
    about-what        from DC Subject
    about-when        from DC Coverage (temporal)
    about-where       from DC Coverage (spatial)

 meta-erc:  the story of the origin of the metadata record itself
    meta-who         (not mapped from DC)
    meta-what        (not mapped from DC)
    meta-when        (not mapped from DC)
    meta-where       (not mapped from DC)

 support-erc:  the story of a support commitment made to an object
    support-who         (not mapped from DC)
    support-what        (not mapped from DC)
    support-when        (not mapped from DC)
    support-where       (not mapped from DC)

The Abstract Model and DC Kernel Metadata Resource Descriptions

The following aspects of the DCMI abstract model are supported by the KAP:

• properties

• property URIs (base URL plus element name)

• value strings

• description sets

The KAP does not support the following aspects of the DCMI abstract model:

• value string languages

• encoding schemes

• encoding scheme URIs

• resource classes

• rich representations

• related descriptions

• property/sub-property relationships

URIs are not explicitly supported in the KAP, but may be implicit for:

• value URIs

• resource URIs

• resource class URIs

Each property may be repeated.

References