Date Working Group - Date Element Working Draft
|
Title:
|
Date Element Working Draft |
|
Creator:
|
|
|
Date Issued:
|
1997-10
|
|
Identifier:
|
|
|
Replaces:
|
|
|
Is Replaced By:
|
Not applicable
|
|
Latest Version:
|
|
|
Status of Document:
|
This is a DCMI Working
Draft.
|
| Description of Document: | 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
- 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.
- 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
- 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.
- 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
- 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
- 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.
- 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