Ok, I've avoided opening up Pandora's box long enough!! I find the
entire search for an acceptable definition for the DATE element
sufficient proof that there is something fundamentally wrong with the
field. Date, as I've said to a number of people, is a data type, not a
semantically meaningful term. Unqualified it is useless. I think it is
fundamentally wrong for us to have a field in the DC that can not be
used without qualification (alright, I'll admit it, I'm a minimalist).
While I realize the great risk of going down this path, I propose that
we throw out the DATE field in favor of two meaningful fields, for which
I will offer initial suggestions below. Note that I don't get into the
format discussion for each - I'm happy to go along with the ISO date
standards suggested by those who know a lot more about them.
CREATION_DATE: Date that the resource was originally made available.
For example, Shakespeare's "Comedy of Errors' might have 1592 inthis
field.
ENTRY_DATE: Date that the resource was put into its present form. For
example, this might be the scanning date for a set of TIFF's for
Shakespeare's "Comedy of Errors'
My notion is that for basic resource discovery, these fields answer the
two most common temporal questions:
"find me things that were created in date range xxx"
"find me things that were last changed in date range xxx"
Am I the only person that thinks we need to have a serious discussion of
this in Helsinki??
My flame resistant suit is on :-)
Carl
---There, I got it off my chest - see you all next week
-----Original Message-----
From: Rebecca S. Guenther [SMTP:[log in to unmask]]
Sent: Friday, September 26, 1997 2:56 PM
To: Ricky Erway
Cc: [log in to unmask]
Subject: Re: DATE and PUBLISHER element definition change
proposal
On Wed, 24 Sep 1997, Ricky Erway wrote:
>
> 7.Date [less specific]
> Label: DATE
> The date the resource was ---made available in its present
> form---+++issued+++. Recommended best practice is an 8-digit
number
> in the form YYYY-MM-DD as defined in
> http://purl.org/metadata/dc/8601-date-profile, a profile of
ISO 8601.
> In this scheme, the date element +++value+++, 1994-11-05,
corresponds
> to November 5, 1994. Many other schema are possible, but if
used,
> they should be identified in an unambiguous manner.
>
> to read:
> The date the resource was issued. Recommended best practice
is an
> 8-digit number in the form YYYY-MM-DD as defined in
> http://purl.org/metadata/dc/8601-date-profile, a profile of
ISO 8601.
> In this scheme, the date element value, 1994-11-05,
corresponds to
> November 5, 1994. Many other schema are possible, but if
used, they
> should be identified in an unambiguous manner.
Does the Date Subgroup have any comment on this? I thought we
were looking
at a much more general definition like "a date associated with
the
resource" to allow for many different types of dates (date
created; date
last verified; date valid to, etc.) using the type qualifier.
However, I
have no objection to the above definition being the default type
of date
(i.e. the assumed definition when no qualifier is used).
Rebecca
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^ Rebecca S. Guenther ^^
^^ Senior MARC Standards Specialist ^^
^^ Network Development and MARC Standards Office ^^
^^ Library of Congress ^^
^^ Washington, DC 20540-4020 ^^
^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^
^^ [log in to unmask] ^^
^^ ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|