Re the Date element.
Element refinements
Date.Accepted
Date.Captured
Date.Copyright
Date.Submitted
AC. Support these proposals; no changes suggested.
Encoding schemes for Date element
Prefer ISO 8601if encoded and free text otherwise
Ambiguity, approximation, unknowns
Thanks Eric for a clear presentation of the issues here. Presentation in
free text with a syntax based on a blend of AACR2 and MARC21 for DC Lib
seems a good one to go with.
Ann Chapman
----- Original Message -----
From: "Childress,Eric" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, March 27, 2002 2:34 AM
Subject: date -- ambiguity, approximation, unknowns
> Background/initial discussion:
> Establishing important dates for some resources in the collections of
> cultural heritage agencies (libraries, museums, archives) is problematic.
> Typically this reflects the incomplete state of records/evidence available
> to establish a firm and precise date for specific events (e.g., the
> publication of a book, the birth and/or death date of an agent) or there
is
> cause to believe that "known" dates (e.g., a date borne by an item) are,
or
> may be, inaccurate.
>
> Some simple abbreviations (frequently of Latin words/phrases) and
> punctuation syntax practices have arisen over the centuries among scholars
> in Western countries for conveying approximation, known/probable
inaccuracy,
> and imprecision. These practices have been generally embraced and
modified
> by cultural heritage agencies for use in their own record-keeping and are
> probably most readily suited to standard presentations of free-text rather
> than as guides for computer-readable encoding of dates.
> Examples of scholarly/cultural heritage agency representations of
> approximate/imprecise dates:
> 1. "Scylitzes, John fl. 1081" where "fl." stands for "flourished" -- this
> historian's precise birth/death dates are not known [N.B. known historical
> facts: Ioannes Skylitzes; b. after 1040; d. at begin. of 12th cent.; ca.
> 1090 was named Drugarios tes Biglas by Byzantine Emperor; historian]
> 2. "ca. 475 BC" where "ca." stands for the Latin word, "circa," (about)
> (See also the "discussion -- free text" section below).
>
> Discussion -- encoding:
> -ISO 8601 (and by extension W3C-DTF) makes no provision for encoding that
a
> date value is an approximation, or known/probable inaccurate value.
Reduced
> precision is supported by ISO 860, but reduced precision is limited to
> right-handed truncation of precise dates (i.e., 2002-03-15 may be reduced
to
> 2002-03 or 2002, but ISO 8601 does not allow for the possibility of, say,
> fully representing 200u-03-02, where "u" represents an unknown year even
> though the century, decade, month, and date may be known -- ISO 8601 would
> force the reduction to take the form of "200n" (e.g., "2001") where "n"
> represented an actual year (possibly arbitrarily assigned)). ISO 8601
makes
> no provision for ranges as terminal points (e.g., if an event was known to
> have started between 1952-03-15 and 1952-03-25, and ended between
1953-02-13
> and 1953-02-23).
> -DCMI Period in combination with the right scheme (which would have to be
> defined) conceivably could convey approximation, known/probable
inaccuracy,
> and imprecision, but DCMI Period has no significant, *inherent* strengths
> for these categories of dates so like ISO 8601 I'll ignore it for the
> purposes of further discussion.
> -MARC 21 provides a rich mix of strengths and weaknesses for encoding
dates
> which represent approximation or known/probable inaccurate values. Dates
> may be single dates or ranges. MARC 21:
> --The 008 field [see
> http://lcweb.loc.gov/marc/bibliographic/ecbd008s.html#mrcb008] allows for
a
> date type code (1 character) and a combination of two date bytes (4
> positions each -- either CCYY & CCYY or MMDD & CCYY combinations. 008 may
> be used in combination with 046 (and must be used in combination to
> represent BCE dates). The one-character date type codes (e.g., "r" for
> reissue) provide an admirable level of granularity for characterizing the
> intellectual meaning of date values. Of note also are two practices in
the
> 008 encoding scheme: 1. "u" may be used to substitute for any unknown in
the
> CCYY & CCYY or MMDD & CCYY combinations that 008 supports (e.g.,
200u-03-02
> could be represented in MARC 21 008 as date type code="e" [for detailed
> date]; date 1= "0302" & date 2="200u") , and 2. the concept of starting
> point-is-known, but ending date is unknown (typically for current, serial
> publications) using the established value of "9999" in date 2 as a
> convention for representing "future, unknown end date."
> --Capture date (MARC 033)
> [http://lcweb.loc.gov/marc/bibliographic/ecbdnumb.html#mrcb033]
effectively
> follows in ISO 8601's footsteps (i.e. allowing for the right-handed
> truncation of precise date/time values).
> --The Time period of content field (045)
> [http://lcweb.loc.gov/marc/bibliographic/ecbdnumb.html#mrcb045] has
similar
> boundaries to the 033 though it has an interesting option for employing a
> MARC 21 date encoding scheme to render century/year/decade spans in a
short
> form using a combination of alpha-numeric characters.
> --The special coded dates field (046)
> [http://lcweb.loc.gov/marc/bibliographic/ecbdnumb.html#mrcb045] shares
> characteristics with the 008 field (see next item) including the ability
to
> code the nature of the date values using a date type codes list (e.g., "q"
> for questionable).
> --In a wide array of MARC 21 fields, specific subfields provide for simple
> encoding (e.g., Projected Publication Date (263)) or free-text, but the
> subfield -- to varying degrees --characterizes the nature of the date
(e.g.,
> in field 260, $c represents the date of publication, distribution, etc.
and
> $g represents the date of manufacture).
>
> Discussion -- free text
> AACR2 provides significant guidance for 1. determining which among
available
> dates are significant/reliable, and 2. employing a syntax for consistently
> recording free-text representations of inaccurate, probable, approximate,
> corrected, and imprecise dates.
> The following are drawn from AACR2 1.4F:
> 1.4F2: Incorrect date that appears on resource -- transcribe incorrect
date
> and follow with correct date in brackets with the prefix "i.e."
> example: "1697" appears on item, but it is a known transcription error for
> "1967". AACR2 dictates: "1697 [i.e. 1967]"
> 1.4F5: Copyright date: "c1965" and phonogram copyright date: "p1975"
> 1.4F7 provides for a variety of scenarios. If date value is not on
resource
> and fits one of the following categories:
> -- One year or another: "[1971 or 1972]"
> -- Probable date: "[1969?]"
> -- Approximate date: "[ca. 1960]"
> -- Decade certain: "[197-]"
> -- Century certain: "[18--]"
> -- Century probable "[18--?]"
> And this pattern can be extended to ranges, e.g., if a starting point is a
> probable decade, but the end point is known: "[197-?]-1982"
> Added note: Although not part of AACR2, there is an established practice
> among serial catalogers (and at LC for cataloging multipart items) in the
> U.S. of using angle brackets ("<>") to indicate what in effect is a "best
> available information" status for dates when the terminal dates of a
> multi-year publication are unknown. "<1978-1985>" for example, would
convey
> that issues were known to be published between 1978-1985, and it's
> believed/assumed/possible that earlier and later issues were also
published,
> but the actual start and end dates cannot be readily determined.
>
> Recommendations/questions:
> RG: Partially known dates: suggest a syntax, using question marks or "u"
for
> the unknown digits. ("u" is used in MARC 21 in coded date fields). Date
> unknown: I'm not sure how this is different than [using question marks or
> "u" for the unknown digits]. If it's completely unknown then isn't it just
> left out? If it's partially unknown then use [using question marks or "u"
> for the unknown digits]?
> EC: As is obvious, there is no standard encoding scheme that addresses
> approximation,known/probable inaccurate values, or imprecision to the
level
> cultural heritage agencies often operate:
> --Best option?: Within the cultural heritage community, the
categorizations
> supported in AACR2 and MARC 21 presumably have value, and a syntax
approach
> such as Rebecca suggests is probably acceptable. A thoughtful blend of
> AACR2 and MARC 21 008 syntax would probably be reasonably useful (e.g., we
> might adopt AACR's abbreviations (exception: copyright -- prefer the use
of
> the qualifier instead), brackets and question mark(to represent
> uncertainty), with MARC 21's "u" (rather than hyphens) for imprecision to
> convey most categories with a consistent syntax). Ideally this would be a
> published scheme, but absent that one supposes it could be incorporated in
> the DC-Lib?
> -Issue we should discuss: Conveying these various categorizations of date
> values (e.g., "questionable") is probably of significance to the cultural
> heritage community, but probably not to most others -- others who would
> presumably prefer to process "1967" rather than "1697 [i.e. 1967]" as a
date
> value. If we assume that dc.date values are something many agencies will
> normally attempt to process/index automatically, should we at least adopt
a
> scheme value to forewarn others that the date value (e.g., "[ca. 1960]")
> isn't likely to be easy to automatically process and index (perhaps
"DC-Lib"
> as a scheme?)? Or are there other options we should consider?
>
>
> Eric
>
>
> Eric Childress
> Consulting Product Manager
> OCLC Metadata Services Division
> OCLC Online Computer Library Center, Inc.
> 6565 Frantz Rd., Dublin, OH 43017 USA
> US: (800) 848-5878 or (614) 764-6000
> Fax: (614) 718-7361 email: [log in to unmask]
>
|
