innovation in metadata design, implementation & best practice

Date Element Working Draft

Creators: John A. Kunze
Date Issued: 1998-01-27
This Version: http://dublincore.org/specifications/dublin-core/1998/01/27/date-element/
Latest Version: https://www.dublincore.org/specifications/dublin-core/date-element/
Replaces:
  • https://www.dublincore.org/specifications/dublin-core/date-element/1997-10-01/
  • https://www.dublincore.org/specifications/dublin-core/date-element/1998-01-27/
  • Status: draft
    Description: This report is a record of the efforts of the Date working group constituted following the Helsinki Dublin Core Metadata Workshop (DC-5) of October, 1997. The recommendations are provisional and can be expected to evolve in the light of further implementation experience.

    This report is a record of the efforts of the Date working group constituted following the Helsinki Dublin Core Metadata Workshop (DC-5) of October, 1997. The recommendations are provisional and can be expected to evolve in the light of further implementation experience.

    Date Ranges
    It is proposed that Date ranges be specified using a subset of the ISO 8601 "period of time" specification as restricted to dates conformant with the W3C technical note specification http://www.w3.org/TR/NOTE-datetime. A typical range is given as start and end dates separated by a '/' (slash) character. Either the start or end date may be missing.

    Examples include:

    1992/1997 # starts in 1992 and ends in 1997
    1998-01-05T08:15/1998-01-05T13:15 # a range of 5 hours in early 1998
    1948/ # from 1948 (no end specified)
    /1989 # until 1989 (no start specified)
    Note that no consensus on this range format was reached.

    DC.Date Subelements
    Used without a subelement designation (i.e., unqualified), a DC.Date element contains a date associated with the creation or availability of the resource. All DC.Date subelements are consistent with this definition, but allow increased precision. They are intended for those collections (e.g., libraries and archives) and searchers for whom the benefit to discovery may justify the extra cost in metadata creation and maintenance.

    These subelements may be seen as falling into the three groups below, with DC.Created and DC.Issued providing perhaps the most commonly required extra precision. Different syntaxes for specifying subelements exist; the abstract subelement notation below is not a valid syntax.

    Resource Origination Resource Release Resource Transfer
    DC.Date-->Created DC.Date-->Issued DC.Date-->Accepted
    DC.Date-->DataGathered DC.Date-->Available DC.Date-->Acquired
    DC.Date-->Valid

    1. DC.Date->Created

    Date of creation of the resource.

    When DC.Date is insufficiently precise, use this subelement to distinguish a date that identifies just the creation of the present resource. Examples include the date that an article was written, a photograph taken, a piece of music composed, or a performance recorded. An HTML file created in 1997 as a transcription of an article written in 1875 could have both

    DC.Date->Created: 1997
    DC.Source->Date->Created: 1875

    Alternatively, a simpler description could include exactly one date as either

    DC.Date: 1997

    or, depending on the metadata provider's preference,

    DC.Date: 1875

    If you wished to describe different versions of a resource with one resource description, it would be appropriate to put the creation date of the latest version in DC.Date->Created. On the other hand, you might instead choose to describe each version with a separate resource description.

    1. DC.Date->Issued

    Date of formal issuance (e.g., publication) of the resource.

    When DC.Date is insufficiently precise, use this subelement to distinguish a release date that has recognized legal (e.g., copyright) or institutional (e.g., posting of a staff policy change) significance. For example, the description of a work published posthumously might have just "DC.Date: 1997", just "DC.Date: 1948", or both

    DC.Date->Issued: 1997
    DC.Date->Created: 1948

    A government file, officially released in 1997, consisting of photographs taken in 1985 of hundreds of meteorite fragments collected in 1952 could be described with the following metadata:

    DC.Date->Issued: 1997
    DC.Date->Created: 1985
    DC.Date->DataGathered: 1952

    1. DC.Date->Accepted

    Date of acceptance (e.g., dissertation or treaty) of the resource.

    When DC.Date and DC.Date->Issued are insufficiently precise, use this subelement to indicate when the resource was formally adopted by a party that accepts or vouches for it.

    1. DC.Date->Available

    Date (often a range) that the resource will become or did become available.

    When DC.Date and DC.Date->Issued are insufficiently precise, use this subelement to indicate a start, end, or both start and end of a period during which access to the resource was or will be granted. It may be needed to indicate an availability period that will start or end in the future, or did come to an end in the past. For example, a journal collection ranging from 1955 to 1996 may be given as

    DC.Date->Available: 1955/1996

    1. DC.Date->Acquired

    Date of acquistion or accession.

    When DC.Date and DC.Date->Issued are insufficiently precise, use this subelement to distinguish the time that a resource was acquired or accessioned in the context of a collection to which it belongs or in which it resides. For example,

    DC.Title: Treaty of 1645
    DC.Date->Issued: 1645
    DC.Date->Accepted: 1646
    DC.Date->Acquired: 1958

    1. DC.Date->DataGathered

    Date of sampling of the information in the resource.

    When DC.Date and DC.Date->Created are insufficiently precise, use this subelement to distinguish the time of raw data creation as opposed to resource content (e.g., intellectual content) creation, which belongs in DC.Date->Created. Examples include the date that a group of weather stations were sampled and a range of times during which radiation measurements were taken. To identify the date when a photograph was taken, DC.Date->Created is recommended.

    1. DC.Date->Valid

    Date (often a range) of validity of the resource.

    When DC.Date and DC.Date->Issued are insufficiently precise, use this subelement to indicate when the resource content may be considered to hold true. In a somewhat labored example, suppose a public transit system is in the practice of creating a new bus schedule, allowing two weeks for issuance of a print run, allowing two more weeks for printed copies of the schedule to be placed in distribution racks, and finally being required to do so at least one month in advance of drivers switching the timing on their routes. Metadata for such a bus schedule might include all of the following elements:

    DC.Description: City Bus Schedule
    DC.Date->Created: 1997-11-01
    DC.Date->Issued: 1997-11-15
    DC.Date->Available: 1997-12-01/1998-06-01
    DC.Date->Valid: 1998-01-01/1998-06-01