At 10:06 AM 9/30/97 EST, Ray Denenberg (Library of Congress) wrote:
>[...]if you want to convey publication date, would the content of
>the date element be:
> (a) "the publication date is 1994", or some construct
> that includes an indication that this is a publication
> date, such as an (attribute, value) pair; or
> (b) "1994", where 'publication date' is assumed because it
> is the default when date is not qualified.
>
>I suspect it's (b) we're talking about.
Mostly. The intent is to have something similar to the date information
that shows up in standard bibliographic citations. However, people could
(and no doubt will) enter things like
"Originally published in 1492, translated to Esperanto and issued as
a web page in November, 1997."
The not-so-secret structuralist inside me shudders at the thought of all
this document history info in a "date" field. But people are people.
>My primary point was: don't add distinct
>elements for different types of dates (date of publication, date
>last modified, etc.).
I can certainly agree with that. For more precise specifications of dates,
use qualifiers, subelements, etc. on the Date element.
>My secondary point: don't establish a hard
>default (like date of publication) to be assumed when date is
>supplied unqualified. And I say "unqualified" loosely, because
>in my view, if there is a hard default, the when the element is
>supplied without an explicit qualifier, it is, in effect,
>qualified, implicitly.
>
>My suggestion is this: for searching, when "date" is supplied
>without an explicit qualifier, the implied qualifier should be
>"host choice". For retrieval, date should not occur without an
>explicit qualifier.
OK, I see where my thinking has gone astray and agree with this.
Let me try to restate it so you can see if I am agreeing to what
you intend. :-)
The rule "unqualified elements are to be regarded as free text" means
that we can't *require* that unqualified occurances of Date
are to intepreted as "date of issue". The example above about the
date of the Esperanto translation shows this.
However, it can certainly be recommended practice that if people provide
an unqualified date, that should be its meaning. We can also recommend
that people provide a qualifier to make that explicit.
People, being people, will do what they want. Therefore if I get
an incoming DC record with an unqualified date, I may treat it as
"free text" which is essentially your notion of "host choice". Further,
Date elements with qualifiers that I don't understand can also be
treated as free text.
As a practical matter, I'd expect people to just toss all the contents of
Date fields into a field of their full-text index. Only organizations
with well-established date types that serve an ongoing business need will
bother to keep them distinct.
Later,
Ron Daniel Jr. voice:+1 505 665 0597
Advanced Computing Lab fax:+1 505 665 4939
MS B287 email:[log in to unmask]
Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545
|