DCMI Administrative Metadata Working Group
Administrative Dublin Core™ (A-Core) Element
A proposal to be discussed in the DCMI Administrative Metadata Working Group
10 SEPTEMBER 2001
Creators: Jytte Hansen, Danish Bibliographic Centre and Leif Andresen, Danish National Library Authority.
The process of this document
This proposal is for discussion in the DCMI Administrative Working Group in September 2001. Based on the discussion the authors will revise the document and present a new version on the DC-9 Workshop in Tokyo in October 2001. Next step will be a formal approval in the working group. Parallel with this process the proposal will be sent to DCMI Usage Committee for comments according to the role of this committee.
Please feel free to send comments and questions to the DCMI Administrative WG mailing list: [email protected]
You are also welcome to send questions and proposals for editorial changes to the chair, Leif Andresen, [email protected]
Introduction
This proposal is based on the work of Renato Ianella and Debbie Campbell [1], who were the authors of the A-core. The intention of this proposal is to extend the A-core to cover a broader range of administrative functions when handling metadata. It has not been the purpose to define a core and discuss which elements should be mandatory and which optional. The idea is the same as Dublin Core™ for content metadata: it is the practical use that determines which elements are needed. It will vary from project to project how many elements are relevant.
We have in this proposal included metadata for exchange between systems. But inclusion of these elements is subject for discussion.
The definitions in this specification do not depend on the format of the metadata. But it is obvious that XML/RDF are more suitable than HTML to cover grouping of information - e.g. name and email, which are two different aspects of the same entity.
None of the elements are specified as mandatory for all kinds of use of A-core. 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 A-core elements for specific use.
The idea is that the different projects, organisations, institutions etc. shall pick up the elements they can use. That is the reason why we have chosen not to introduce a more complex structure for all dates. We have maintained the idea of single elements. But in the case of three very important dates: date of creation, date of modifying, date of checking, we have proposed a possibility of an alternative, connected structure of name, activity, and date.
The question to you is not: can you find any not relevant administrative metadata in this proposal.
Everybody can do that.
The question is: do you miss any administrative metadata in this proposal?
We don't have to agree on a core. The intention is to reuse the definition of administrative metadata, so interoperability between systems gets better conditions. The intention is not to dictate a mandatory use.
Formal definitions
Name: Identifier
Identifier: identifier
Definition: A string or a number, which identified the metadata record
Obligation: Optional
Comment: Can be the internal number in a database.
Name: Scope
Identifier: scope
Definition: Declaration of the scope of application
Obligation: Optional
Comment: Will often be declared by means of a separate form.
Name: Name
Identifier: name
Definition: The name of the entity responsible for undertaking a defined action on the content metadata
Obligation: Optional
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
Obligation: Optional
Comment: The email address must be encoded to be consistent with Internet Address standard RFC822 [2].
Name: Contact Information
Identifier: contact
Definition: Information on how to contact the responsible entity
Obligation: Optional
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: Activity
Identifier: activity
Definition: The action performed on the content metadata by the
responsible entity
Obligation: Optional
Comment: The actions are taken from a non-exhaustive list including:
created, submitted, modified, checked, link collected, resource harvested, expired, mail sent.
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 [3]
Name: Comment
Identifier: comment
Definition: Comment on the Acore metadata
Obligation: Optional
Comment: E.g. comments pointing at special circumstances in connection with the transmitted metadata
Name: Date of Activity
Identifier: dateActivity
Definition: The date on which the activity took place by the responsible entity
Obligation: Optional
Comment: Encoded to the W3C Profile of ISO 8601 [4].
This unspecified date must be used in connection with a declared activity, e.g. "submitted"
Name: Date of Creation
Identifier: dateCreated
Definition: The date on which the Acore metadata were created
Obligation: Optional
Comment: Encoded to the W3C Profile of ISO 8601 [4].
One of the three dates of actions, treated separately
(NB: This is an alternative dating method)
Name: Date of Modification
Identifier: dateModified
Definition: The date on which the Acore metadata were changed
Obligation: Optional
Comment: Encoded to the W3C Profile of ISO 8601 [4].
One of the three dates of actions, treated separately
(NB: This is an alternative dating method)
Name: Date of Checking
Identifier: dateChecked
Definition: The date on which a colleague or a controller checked the content metadata
Obligation: Optional
Comment: Encoded to the W3C Profile of ISO 8601 [4].
One the the three dates of actions, treated separately
(NB: This is an alternative dating method)
Name: Identification of creating unit
Identifier: createdBy
Definition: An identification (name, initials, number) of person or function, which has
created the content metadata
Obligation: Optional
Comment: Encoded to the W3C Profile of ISO 8601 [4].
(NB: This is an alternative naming method)
Name: Identification of modifying unit
Identifier: modifyedBy
Definition: An identification (name, initials, number) of person or function, which has
checked the content metadata
Obligation: Optional
Comment: Encoded to the W3C Profile of ISO 8601 [4].
(NB: This is an alternative naming method)
Name: Identification of checking unit
Identifier: checkedBy
Definition: An identification (name, initials, number) of person or function, which has
checked the content metadata
Obligation: Optional
Comment: Encoded to the W3C Profile of ISO 8601 [4].
(NB: This is an alternative naming method)
Name: Affiliation
Identifier: affiliation
Definition: The organization with which the named person was associated when involved with the resource
Obligation: Optional
Comment: Often the "affiliation institution" will be the formally responsible entity
Name Status
Identifier: status
Definition: Statement of a stage of a record, or stage of the work with a record
Obligation: Optional
Comment: The actions are taken from a non-exhaustive list including:
The record is established manually/automatically
The record is under construction
Name Language
Identifier: language
Definition: Language of metadata
Obligation: Optional
Comment: The actions are taken from a non-exhaustive list including:
The record is established manually/automatically, the record is public/not public
Name: Metadata Location
Identifier: location
Definition: An unambiguous reference to the content metadata within a given context
Obligation: Optional
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: Rights Ownership
Identifier: rights
Definition: Information about rights held in and over the content metadata
Obligation: Optional
Comment: Typically, the Rights element will contain a rights management statement for the content metadata, or refer to a service providing such information.
Name: Valid Date Range
Identifier: dateRange
Definition: The start and/or end date of the validity of the content metadata
Obligation: Optional
Comment: Content metadata accessed outside the date ranges should be considered to be invalid.
Encoded to the W3C Profile of ISO 8601 [7] 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 are attached some SCHEMEs with the values YES and NO.
Obligation: Optional
Comment: Some possible SCHEMEs:
Harvest: the record shall be included in a harvesting (YES/NO)
Public: the content metadata must be shown to the public (YES/NO)
Manual: can the metadata record be checked automatically (YES/NO)
Keep: when adding administrative metadata, shall old versions of same element
be kept (YES/NO)
Mail: Mail to be sent
This element defines instructions of future actions. (See also the element: Activity)
A number of elements, most relevant in connection with data exchange via batch files
Name: Database
Identifier: database
Definition: Code identifying a database
Obligation: Optional
Comment: The code is used to identify the database to which a batch file is sent.
Is related to Location (see below)
Name: Transmitter
Identifier: transmitter
Definition: Name or code for transmitter
Obligation: Optional
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
Obligation: Optional
Comment: Name of the individual batch file. It may be combined with transmitter name.
Name: Technichal format
Identifier: technichalFormat
Definition: Technical data exchange format
Obligation: Optional
Comment: The format is taken from a non-exhaustive list including:
ISO2709, XML, HTML
Name: Character set
Identifier: characterSet
Definition: Name of character set used
Obligation: Optional
Comment: The character sets must refer to relevant standards
Name: Bibliographic format
Identifier: BibliographicFormat
Definition: Bibliographic format for data exchange
Obligation: Optional
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
Obligation: Optional
Comment: E.g. an email address of a transmitter
Name: Action
Identifier: action
Definition: The action to be performed in the database
Obligation: Optional
Comment: The actions are taken from a non-exhaustive list including:
append, modify, delete. If needed, further specification can be found in ISO8459-5.
General comments
A practical responsible person will often appear in the Name Field with email contact address. This will be sufficient in the data exchange.
In connection with the affiliation institution, a series of contact information, rights, and comments may be interesting. The simplest way of handling this information may be to make a specific group of information "around" the affiliation institution. E.g. accessible via codes. This information may be kept in a separate database.
Syntax examples
Parallel example
() () () (Most appropiate if name, action, and date are sufficiant information)
Background information
(_If the affiliation information is kept in a separate database, there will be no activity and date_).
Grouping information in HTML is not reliable because the order is extremely important. Coding of these more complex data works better when using XML
References:
[1] The A-Core: Metadata about Content Metadata:
Admin Core - Administrative Container Metadata (A-Core)
[2] RFC822 Standard for the Format of ARPA Internet Text Messages
ftp://ftp.isi.edu/in-notes/rfc822.txt
[3] USMARC Relator Code List
http://www.loc.gov/marc/relators/re9802r1.html
[4] Date and Time Formats (based on ISO 8601), W3C Technical Note
http://www.w3.org/TR/NOTE-datetime