innovation in metadata design, implementation & best practices

DCMI Administrative Metadata Working Group

AC - Administrative Components

Dublin Core DCMI Administrative Metadata

A proposal to be discussed in the DCMI Administrative Metadata Working Group

7 OCTOBER 2002

Jytte Hansen, Danish Bibliographic Centre
Leif Andresen, Danish National Library Authority.

The process of this document

This proposal is for discussion in the DCMI Administrative Working Group at meeting in Florence October 2002 at DC-2002. Please send comments to the list before DC-2002 if you don't attend DC-2002. Next step will be a formal approval in the working group.

Please feel free to send comments and questions to the DCMI Administrative WG mailing list: DC-ADMIN@JISCMAIL.AC.UK
You are also welcome to send questions and proposals for editorial changes to the chair, Leif Andresen,


On the meeting on the working group in October 2001 a proposal for a A-Core (Administrative Core) was discussed. Based on the discussion we have revised the scope for this set of metadata for administrative use. First of all: the goal is not to promote a core set of metadata. The goal is to give a practical tool for users of metadata to manage metadata with special focus on interoperability between different systems. That is the reason for the in June 2002 announced changed name for this metadata set: Administrative Components.

This implies the limitations of this proposal: it is for administration of metadata - not for administration of resources. This aspect is handle by other communities (e.g. ISO TC46 / SC11) and another DCMI working group.

In consequence of the focus on interoperability between systems, we have renounced the idea of make a solution useable also in very simple implementation. We have also remarked the growing importance of XML, so this proposal is based on use of XML. This solves the problem of tying information together: e.g. creation of metadata record, date of creation, who create, comments to the creation etc.

This document does not provide guidelines for encoding Dublin Core in RDF/XML. Nor does it take a position on the relative merits of encoding metadata in 'plain' XML rather than RDF/XML.

Relation to other initiatives:

This is a follow-up of the proposal presented at DC-9 in Tokyo October 2001. This proposal was built upon The A-Core: Metadata about Content Metadata by R. Iannella and D. Campbell (1999).

The focus for this metadata set is interoperability between systems with content metadata. Other initiatives have others focus. The word "administrative" is in METS (Metadata Encoding & Transmission Standard) used for management of digital library objects. Other related functions are record keeping, resource management and preservation metadata.

None of these initiatives meet the requirement to control interchange og metadata records between system. This is the reason for this proposal.

This document sets out a three-part proposal for a standard for administrative metadata:

· Metadata for the entire record
· Metadata for update and change
· Metadata for batch interchange of records

Two informative annexes complement it.

Compared to proposal sent to the DCMI Administrative WG mailing list in September 2002 is added two informative annexes with examples and some background information for related Danish projects. The introduction is separated from the text of what strictly speaking is the proposal. In the proposal itself only a few changes in the first part General rules are made.

AC - Administrative Components

Dublin Core DCMI Administrative Metadata

Proposal of 7 OCTOBER 2002

General rules

The name of this metadata element set is Administrative Components.

The DCMI namespace URI is not yet determined, but shall follow the rules for DCMI namespaces. So the namespace for AC will be

All metadata elements are optional and repeatable. A specific implementation can define additional rules including that some elements are mandatory.

None of the elements are specified as mandatory for all kinds of use of AC. It is up to the individual project, organisation, website etc. to decide which elements are to be mandatory. A tool for that can be an Application Profile to specify instructions for use of Dublin Core, domain specific metadata element set(s) and metadata about management of the content metadata - including e.g. mandatory AC elements for specific use.
The idea is that the different projects, organisations, institutions etc. shall pick up the elements they can use.


Metadata for the entire record

Name: Identifier
Identifier: identifier
Definition: A string or a number, which identified the metadata record
Comment: Can be the internal number in a database.

Name: Scope
Identifier: scope
Definition: Declaration of the scope of application
Comment: Will often be declared by means of a separate form. This element can be used either as unstructured text just with an informal declaration like "national bibliography" or by using a SCHEME for a formal declaration like "catalogue code.

Name: Comment
Identifier: comment
Definition: Comment on the Acore metadata
Comment: E.g. comments pointing at special circumstances in connection with the transmitted metadata

Name: Metadata Location
Identifier: location
Definition: An unambiguous reference to the content metadata within a given context
Comment: This element is used if the content metadata and A-Core metadata
are not in the same location.
Recommended best practice is to identify the content metadata by means of a string or number conforming to a formal identification system. Examples of formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL)) and the Digital Object Identifier (DOI).
Other identifiers, such as local repository/database keys, may be used.

Name Language
Identifier: language
Definition: Language of metadata
Comment: Encoded ISO 8601 ISO 639-2.

Name: Rights Ownership
Identifier: rights
Definition: Information about rights held in and over the content metadata
Comment: Typically, the Rights element will contain a rights management statement for the content metadata, or refer to a service providing such information. For at more detailed control specific projects can use SCHEMEs for administration of rights for the specific project.

Name: Valid Date Range
Identifier: dateRange
Definition: The start and/or end date of the validity of the content metadata
Comment: Content metadata accessed outside the date ranges should be considered to be invalid.
Encoded to the W3C Profile of ISO 8601 including the use of the "/" to indicate the range scope. For example, "/1999-12-31" indicates validity up to 31 December 1999, "1999-01-01/" indicates validity from 1 January 1999 onwards, and "1999-01-01/1999-12-31 indicates validity between the two specified dates.

Name: Handling specification
Identifier: handling
Definition: Instructions for handling the administrative metadata and the metadata record in full. To this element is attached a SCHEME with the values:
· Harvest: the record shall be included in a harvesting
· Public: the content metadata must be shown to the public
· Manual: can the metadata record be checked automatically
· Keep: when adding administrative metadata, shall old versions of same element be kept
· Mail: Mail to be sent
Comment: This element defines instructions of future actions. (See also the element: Activity)

Metadata for update and change

Name: Activity
Identifier: activity
Definition: The action performed on the content metadata by the responsible entity
Comment: The actions are taken from a non-exhaustive list including:
created, submitted, modified, checked, link collected, resource harvested, expired, mail sent and three codes for deleted: delete_error_record, delete_disappearance and delete_out_of_scope
This list may be seen as showing the history of actions. (See also the element: Handling).
Other sources may be used for the activity values such as codes from the USMARC Relator List.


Name: Name
Identifier: name
Definition: The name of the entity responsible for undertaking a defined action on the content metadata
Comment: Examples of Name include a person, an organisation, or a service.
Where the person has an affiliation with an organisation, this information may be included.
The name of a person should be provided in reverse order, that is, last name before first name, with a comma separator.

Name: Email Address
Identifier: email
Definition: Electronic Mail address for the responsible entity
Comment: The email address must be encoded to be consistent with Internet Address standard RFC822.

Name: Contact Information
Identifier: contact
Definition: Information on how to contact the responsible entity
Comment: The information should be one or more of: a street or postal address, a telephone number, a facsimile number, an Internet address, or other forms of physical or electronic contact information.
Links to full descriptions of the responsible entity may also be included, such as name registries.

Name: Date
Identifier: date
Definition: The date on which the activity took place by the responsible entity
Comment: Encoded to the W3C Profile of ISO 8601.
This unspecified date must be used in connection with a declared activity, e.g. "submitted"

Name: Affiliation
Identifier: affiliation
Definition: The organization with which the named person was associated when involved with the resource
Comment: Often the "affiliation institution" will be the formally responsible entity

Metadata for batch interchange of records

A number of elements relevant in connection with data exchange via batch files

Name: Database
Identifier: database
Definition: Code identifying a database
Comment: The code is used to identify the database to which a batch file is sent.
Is related to Metadata Location.

Name: Transmitter
Identifier: transmitter
Definition: Name or code for transmitter
Comment: The name/code (e.g. a library number) will be used to identify an organization with which formal routines of data exchange are established.
A code may include the type of transmitter (e.g. public library, research library, publisher)

Name: Filename
Identifier: filename
Definition: Name of a batch file
Comment: Name of the individual batch file. It may be combined with transmitter name.

Name: Technichal format
Identifier: technichalFormat
Definition: Technical data exchange format
Comment: The format is taken from a non-exhaustive list including:

Name: Character set
Identifier: characterSet
Definition: Name of character set used
Comment: The character sets must refer to relevant standards

Name: Bibliographic format
Identifier: BibliographicFormat
Definition: Bibliographic format for data exchange
Comment: The actions are taken from a non-exhaustive list including:
MARC21, danMARC2, DC

Name: Address of result file
Identifier: resultFile
Definition: Localization of result file
Comment: E.g. an email address of a transmitter

Annex 1

Informative annex

Examples of Encoding in XML of three records

Beyond the actual namespaces of DCMI "dc" and "dcterms" these examples include the proposed namespace "ac" and namespace "dkbib" for elements, schemes, etc. defined specifically for interchange of DC records among Danish libraries.

<?xml version="1.0" ?>
ac:identifier2 418 799 3/ac:identifier
- ac:activity
dc:titleDesign from Denmark/dc:title
dcterms:alternativespecial - tribute to Arne Jacobsen/dcterms:alternative
dansk møbelkunst;dansk design;industriel design;1900-1999/dc:subject
99.4 Jacobsen, Arne f. 1902/dc:subject
Nogle af designeren Arne Jacobsens (1902-1971) møbler og indretningsartikler præsenteres på de lokaliteter hvor de i dag er placeret. Derudover vises møbler og andre genstande fra en bred vifte af danske designere/dc:description
dc:publisherWorld Pictures/dc:publisher

ac:identifier2 412 191 7/ac:identifier
- ac:activity
- ac:activity
ac:nameAndresen, Leif/ac:name
dc:titleDanish library policy/dc:title
dcterms:alternativeselection of recent articles and papers/dcterms:alternative
dc:creatorThorhauge, Jens/dc:creator
En samling artikler om dansk bibliotekspolitik/dc:description
dc:publisherDanish National Library Authority/dc:publisher
dcterms:extent410675 bytes/dcterms:extent

ac:identifier2 381 393 9/ac:identifier
ac:commentNot accessible/ac:comment
- ac:activity
- ac:activity
ac:nameHansen, Jytte/ac:name
dc:titleComing to Denmark?/dc:title
dcterms:alternativea guide to education and training/dcterms:alternative
uddannelsessystemet;uddannelse;studieophold;Danmark;vejledninger; for udlændinge/dc:subject
Orientering til udlændinge som overvejer at komme til Danmark og har brug for oplysninger om studie- og uddannelsesmuligheder/dc:description
dcterms:extent870164 bytes/dcterms:extent

Comments to AC - Administrative Components

Need for Admin Components in the Library Sector in Denmark
3rd October, 2002
Jytte Hansen, The Danish Bibliographic Centre (DBC)

The Danish library sector and the WWW
Danish Net Services:
FNG, BibHit, NetKat, DEF, all discovering, selecting, and registering valuable net resources. All using DC elements in their databases.
FNG - a portal, based on the co-operation of c. 20 public libraries
BibHit - a selection of net resources, based on the co-operation of c. 25 public libraries
NetKat - a selection of net resources, made by 4 public libraries, reported to DBC via a DC generator
DEF - a portal, based on the co-operation of c. 80 research and special libraries

The Danish Bibliographic Centre:
Producing the Danish national bibliography, since 1997 including static "booklike" net documents, registered in the Danish MARC format. Experimenting with the registration of dynamic resources like databases and homepages in DC.

The Danish National Library Authority (BS):
The Danish National Library Authority (Biblioteksstyrelsen) is the Danish government's central administrative and advisory body to the public libraries and the research libraries and is an independent agency under the Ministry of Culture. BS is advising and co funding the above mentioned initiatives and has among other things the responsibility for standardisation.

The creation of a common pool of metadata records

Cooperation and exchange of records:
Till now all the above mentioned initiatives have made their experiences separately, but there is a need for cooperation to avoid double work.

The goal:
A common pool of metadata records, representing all resources, registered by the Danish actors. In this way a survey of the resources is created together with the possibility of reuse.
The means:
DBC has in cooperation with BS evolved the Admin Components and thus created a frame, covering all present needs in connection with exchange of both single records and batch files in the Danish library community.