DatePractices
From oaibp
Main Page >> Shareable Metadata
Note: Summary of best practices added. Jenn Riley 10/12/05
Contents |
[edit] Dates in OAI Records
[edit] Summary of Best Practices
- Date elements in OAI records should contain values important for discovery of the resource by end-users.
- When providing multiple dates in an OAI record, clearly indicate the relationship of each to the resource, and repeat the relevant date element for each date.
- Include only easily-parsable values in date elements.
- Present dates in a consistent format, according to established machine-readable standards.
[edit] Choice of Dates
Dates in OAI records should refer to events most relevant to discovery of the resource by end-users.
For unpublished born-digital content, this is often the date of creation of the digital resource. For published resources that were born-digital, the most relevant date is generally the date of publication.
For analog resources that have been digitized, the choice is more complex. However, in general, the date of creation of the original analog resource, not the date of creation of the digital reproduction, is the most relevant to end-users searching for the resource.
Useful <date>:
<identifier>http://infomotions.com/etexts/literature/english/1600-1699/shakespeare-sonnets-59.txt</identifier> <creator>Shakespeare, William</creator> <title>Sonnets</title> <date>1609</date>
Here, the date reflects when the sonnets were written, rather than when this particular digital version of them was created. This allows a service provider to provide access to this material by the date it was written. See DC Alex Text 1 for the complete record from which this example was taken.
Confusing <date>:
<title>Lieutenant General Jubal Anderson Early C.S.A.: Autobiographical Sketch and Narrative of
the War between the States</title>
<creator>Jubal Anderson Early</creator>
<publisher>Philadelphia; London: J. B. Lippincott Company, 1912</publisher>
<date>2003-04-24T13:15:52Z</date>
Here, the date reflects when the digital resource was created or made accessible. Although this example reflects greater adherence to the Dublin Core 1:1 principle (see Describing Versions and Reproductions) than the previous example, the record as it stands is confusing and difficult for a service provider to process. In particular, a service provider would find providing access by 1912 (the date the analog text was published) difficult. See DC American South Text 1 for the complete record from which this example was taken.
[edit] Use of Multiple Dates
Multiple dates (for example, date of creation and date of last modification) should only be used if they can be properly distinguished from one another. When providing multiple dates, repeat the relevant date elements for each distinct date value. Dates in your OAI records should be as unambiguous as possible. Ideally it should be obvious from the record itself what events the dates in it refer to. This, however, is not possible in simple DC; dates carefully distinguished in qualified DC or another metadata format will map to multiple <dc:date> elements with no distinction between them. In some cases this problem can be solved by "dumbing down" or crosswalking only the most important date when creating a simple DC expression of a richer metadata record.
Example in MODS, distinguishing between two types of dates:
<mods:titleInfo>
<mods:title>Houses in Eureka valley San Francisco from Collingwood near 22nd St.</mods:title>
</mods:titleInfo>
<mods:name type="personal">
<mods:namePart type="family">Cushman</mods:namePart>
<mods:namePart type="given">Charles Weever</mods:namePart>
<mods:namePart type="date">1896-1972</mods:namePart>
</mods:name>
<mods:dateCreated encoding="w3cdtf" keyDate="yes">1955-03-14</mods:dateCreated>
<mods:copyrightDate encoding="w3cdtf">2003</mods:copyrightDate>
</mods:originInfo>
See MODS IU Charles Cushman Collection 1 for the complete record from which this example was taken.
The same item represented in simple Dublin Core, displaying only the most relevant date for retrieval purposes:
<dc:title>Houses in Eureka valley San Francisco from Collingwood near 22nd St.</dc:title>
<dc:creator>Cushman, Charles Weever, 1896-1972</dc:creator>
<dc:date>1955-03-14</dc:date>
See DC IU Charles Cushman Collection 1 for the complete record from which this example was taken.
It may be tempting, when using a metadata format that does not allow the encoded qualification of dates, to put information in the actual element value qualifying a date, such as:
<title>Champaign County, Illinois</title> <creator>United States. Agricultureal Adjustment Administration</creator> <creator>Woltz Studios, Inc. Aerial Survey</creator> <date>Created: 1940-06-19</date> <date>Issued: 1940-01-01</date> <date>Scanned and Processed: 1998-06-01</date> <type>image</type>
See DC UIUC Aerial Photo 1 for the complete record from which this example was taken.
This practice, however, makes it difficult for an OAI service provider to process the metadata as the service provider will need to separate out the label from the value and determine which dates to use for indexing purposes. As stated above it is best practice to expose only the most relevant date for discovery of the resource (in this case either 1940-06-19 or 1940-01-01).
[edit] Formats of Dates
The first considerations when choosing a date format are the requirements of the metadata schema in use. The recommendations below should be followed if your schema of choice provides for multiple formats, or gives no guidance at all.
Ideal
Ideally, dates should be in a standard, machine-readable format, such as ISO8601 or, if the date represented is a single date, with a known year, the W3CDTF profile of ISO8601. These machine-readable dates allow service providers to easily use them for chronological sorting of search results and date searching of resources.
Example in simple Dublin Core:
<dc:title>Houses in Eureka valley San Francisco from Collingwood near 22nd St.</dc:title>
<dc:creator>Cushman, Charles Weever, 1896-1972</dc:creator>
<dc:date>1955-03-14</dc:date>
See DC IU Charles Cushman Collection 1 for the complete record from which this example was taken.
Example in MODS:
<mods:title>Houses in Eureka valley San Francisco from Collingwood near 22nd St.</mods:title>
<mods:name type="personal">
<mods:namePart type="family">Cushman</mods:namePart>
<mods:namePart type="given">Charles Weever</mods:namePart>
<mods:namePart type="date">1896-1972</mods:namePart>
<mods:role>
<mods:roleTerm authority="marcrelator" type="text">photographer</mods:roleTerm>
<mods:roleTerm authority="marcrelator" type="code">pht</mods:roleTerm>
</mods:role>
</mods:name>
<mods:dateCreated encoding="w3cdtf" keyDate="yes">1955-03-14</mods:dateCreated>
See MODS IU Charles Cushman Collection 1 for the complete record from which this example was taken.
Adequate
When it is not possible or practical to encode dates in ISO8601 or W3CDTF, it is essential to format dates consistently and to give service providers enough information on the format used to interpret the dates properly. Pick a format that is commonly used or understood within your knowledge domain, to better allow service providers within that community to use the records. Once you choose a format, use it consistently within your repository or within a set. Provide as much information as possible about the format chosen and how to interpret it in a set description [see SetPractices] or your OAI Identify response. The following examples show a date format that, if used consistently, could be understood and parsed by a service provider.
Example in simple Dublin Core:
<dc:title>Map and profile of the proposed Paterson and Dover Rail Road and Paterson and Ramapo Rail Road.</dc:title>
<dc:creator>Allen, J. W.</dc:creator>
<dc:creator>Paterson and Dover Railroad.</dc:creator>
<dc:date>[ca. 1847]</dc:date>
See DC LOC Map 1 for the complete record from which this example was taken.
Example in MARCXML:
<marc:datafield tag="100" ind1="1" ind2=" ">
<marc:subfield code="a">Allen, J. W.</marc:subfield>
</marc:datafield>
<marc:datafield tag="245" ind1="1" ind2="0">
<marc:subfield code="a">Map and profile of the proposed Paterson and Dover Rail
Road and Paterson and Ramapo Rail Road.</marc:subfield>
<marc:datafield tag="260" ind1=" " ind2=" ">
<marc:subfield code="a">New York,</marc:subfield>
<marc:subfield code="c">[ca. 1847]</marc:subfield>
</marc:datafield>
See MARCXML LOC Map 1 for the complete record from which this example was taken.
