The nearest thing to a standard in this area is the SICI (Serial Item and
Contribution Identifier) (see
http://sunsite.berkeley.edu/SICI/version2.html), which deals with
"non-month chronologies" by the following codes:
Spring = 21
Summer = 22
Fall = 23
Winter = 24
First quarter = 31
Second quarter = 32
Third quarter = 33
Fourth Quarter = 34
(See section 6.3.2.2 of the standard.)
So, if we're going to use codes, shouldn't we use these?
This still doesn't get over the northern vs southern hemisphere meanings of
Spring, etc., and of coure the numbering of the SICI codes does demonstrate
a northern hemisphere bias, but that's a problem whatever numbering system
you use, since numbers will imply sequence, e.g. that Summer precedes
Winter in the calendar year.
Cliff
Andrew Koebrick <[log in to unmask]>@JISCMAIL.AC.UK> on
19/12/2000 23:14:00
Please respond to Andrew Koebrick <[log in to unmask]>
Sent by: The broadest of mailing lists related to the international Dublin
Core effo <[log in to unmask]>
To: [log in to unmask]
cc:
Subject: Re: ISO date; introduction
Greetings,
Many thanks to the folks who advised on adapting ISO-8601 to accommodate
seasonal date declarations. Thanks also to Eileen Quam for passing along
my request to this list. As I will be developing a few intranet/ web
publishing applications based (loosely) on DC over the next few months, I
though it wise to subscribe to this group myself and eavesdrop on the
development of the standard.
For those interested, here is the tweak I will using to "solve" the
ISO-8601/Season issue as it pertains to the citation database I am
building:
Seasons, quarters, and multiple-month declarations (i..e January-February)
will be mapped to the "day" number space, using digits above 31. For
example:
"Winter 2000" becomes "2000-12-35"
"Fourth Quarter" becomes "2000-10-40"...
Translation from these corrupted ISO dates to the intended string is
accomplished via a quicky Perl subroutine at the time of database
retrieval/display. Date creations are done with drop down menus to limit
the need for the data-entry people to understand the mapping.
If anyone is interested in using or critiquing it, I have posted the
subroutine code at: ftp://www.mnplan.state.mn.us/pub/date_swap.pl
I would be particularly interested in hearing if anyone with more
experience in this area can predict problems with this workaround which may
plague me in future years.
Cheers,
Andrew Koebrick
Web Coordinator/Librarian
MN-Planning (Office of Strategic and Long Range Planning)
658 Cedar St., Suite 300
St. Paul, MN 55155
651-296-4156 phone
651-296-3698 fax
"Whenever I see an adult on a bicycle I no longer despair for the human
race." -- H.G. Wells
www.mnplan.state.mn.us
|