All,
Thanks for the continued discussion on this issue. A few points:
DISCLAIMER
A qualifier regarding my date-expression system which I perhaps should have made explicit from the beginning:
My custom DD number extensions will only be used internally in the mysql database I am using to manage my metadata. In lieu of a recognized standard for these complex dates, when they are output to page they will always be converted to either strings i.e. "Spring") or converted to complient ISO format (i.e. "2000-03-00". My hacked together subroutine will do the swap automatically. I would not just make up a novel scheme and push it out there...
SICI/MARC CODES
Thanks for pointing out the SICI and MARC system of expanding the MM field for seasons and quarters. I was not aware of them. The problem with adopting these codes for my situation is that they would muck up any sorting done by date. In my system I can do a SQL query, sort by date, and have all the "Spring", "March-April", and "March" resources fall together. Using SICI codes in the Month field would cause all seasons to land at the bottom of the list, unless I preprocessed the results. Also 2000-03-21 could be both "March 21, 2000" and "Spring 2000"...
Now that I have been made aware of the SICI/MARC system however, I will expand my date_swap routine to allow for an output in this standard.
ALTERNATIVE LOCATIONS FOR INFO
One of my major design considerations is minimizing the input of redundant (or very close) information. I need my input forms to be as simple as possible so that support staffers can enter the data. And I would like them to do it as quickly as possible. Having them enter both a 2000-03-21 and "Spring" in different fields (i.e. dc:date and dc:identifier), though potentially more "correct", offends my sense of laziness.
That said, however, once a standard is established and a decision is made as to where this info should be stored, I will simply change my display templates, and remap my mysql fields to the established DC locations.
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
www.mnplan.state.mn.us
"Incrementalism is the enemy of innovation" -Peter Drucker
>>> <[log in to unmask]> 12/21/00 03:20AM >>>
I've been giving more thought to this too since my posting yesterday, where
I referred to the SICI codes for seasons and quarters. (As Rebecca Guentler
pointed out in her posting, these were actually derived from MARC codes.)
It seems to me this whole debate arose from a wish to use dc:date to
describe this information. Responses so far have been along the following
lines:
1) Use something that looks like an ISO date (CCYYMMDD) but has codes for
seasons etc. These codes could be used in the DD position (as Andrew
Koebrick suggested, e.g. 2000-12-35 for Winter 2000) or could be used in
the MM position (as I suggested, based on the SICI Chronology codes, e.g.
2000-24 for Winter 2000).
But neither of these would be recognized as conformant ISO dates, would
they?
2) Don't even try to force this problem into an ISO date format. Let's say
you have the Spring issue of the Journal of Metaphysical Metadata, and
let's say that this is also Volume 1, no. 1, and that it was published on
21 March 2000. To me, the date that goes into dc:date is 20000321. (You
could be more precise and use dc:date.issued if you were using DCQ.) If you
also want to say that this is the Spring issue, I'd say you had four (not
mutually exclusive) choices:
i) All DC data elements allow text strings, so you could use dc:date=Spring
as well as dc:date=20000321.
ii) You could use a SICI in dc:identifier, where the Chronology piece would
indicate Spring by "21".
iii) You could follow the recommendations of the dc-citation Working Group
and put the following into dc:identifier for the issue - "Journal of
Metaphysical Metadata (Spring 2000), Volume 1, Issue 1". (See the
discussion list archives at
http://www.jiscmail.ac.uk/lists/dc-citation.html.)
iv) You could mention that it's the Spring issue in dc:description.
3) The other issue that has been raised is location. I agree with Alex that
the obvious place for this is in dc:publisher. It certainly doesn't belong
in dc:coverage, and there is no need to invent yet another DC element such
as dc:creation.location. (Apart from anything else, it's not the location
of the creation that's at issue here - it's the location of the issuing
body, i.e. publisher.) dc:publisher is one of those poorly-qualified
elements (that is, it hasn't got any qualifiers in DCQ), but as ever with
DC, there's nothing to stop you putting location information in the
dc:publisher text string, so you could put dc:publisher=John Wiley & Sons,
Chichester, or dc:publisher=John Wiley & Sons Australia, Brisbane. What you
can't do is structure this in any way in the current incarnation of DC
(which just takes us back to the minimalist vs structuralist arguments that
are at the heart of so many DC issues).
And for anyone hoping for future releases of DCQ to include such constructs
as dc:publisher.location, I should point out that this breaks the dumb-down
principle unless you repeat the publisher, e.g. dc:publisher.location=John
Wiley & Sons, New York would comply with dumb-down principles, but
dc:publisher=John Wiley & Sons plus dc:publisher.location=New York would
break the principles.
Regards
Cliff Morgan
*************************************************************************************
Publishing Technologies Director Tel (+44) 1243 770440
John Wiley & Sons Ltd
Baffins Lane Fax (+44) 1243 770 460
Chichester
PO19 1UD [log in to unmask]
UK
*************************************************************************************
Alex Satrapa <[log in to unmask]>@JISCMAIL.AC.UK> on 20/12/2000 21:20:50
Please respond to Alex Satrapa <[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
At 10:48 +0100 2000-12-20, Jack van der Elsen wrote:
Hello everyone, Since Spring-2001 in Australia is not the same period as
Spring-2001 in the Netherlands, it becomes important to know where in the
world the document is created/produced.Is there a possibility to add this
element -creation area- in one of the 15 DC elements ?
This could be covered by DC.Coverage, using a geographic coverage scheme.
http://purl.org/DC/documents/rec/dcmes-qualifiers-20000711.htm#coverage
For spatial coverage, the following schemes are suggested in that document;
- DCMI Point
- ISO 3166 (Country code)
- DCMI Box
- TGN (The Getty Thesaurus of Geograpic Names)
However, DC.Coverage relates to the region referred to or described by the
content of the document, rather than the location of the publisher or place
of publication of the document.
This could be confusing in the instance of a hypothetical publication
called "Snow Tours In Australia, Summer 2000 Edition". This publication
might be a brochure produced by an American travel agency, advertising
skiing holidays to Australia. The DC.Coverage would definately be about
Australia (or the Snowy Mountains in particular, or even just one of the
ski resorts), which makes Summer 2000 the period 2000-12/2001-02, rather
than 2000-06/2000-07.
Some indication of the publisher's geographic location would be necessary.
This could possibly be done using the meta data record describing the
publisher (though how you locate this given the sparse information in the
DC.Publisher field, I'll leave as an excercise for the reader :)
HTH
Alex
--
Alex Satrapa tSA Consulting Group Pty Limited
ICQ: 5691434 1 Hall Street, Lyneham, Canberra 2603
PGP Key 0x4C178C9C fx: +61 2 6257 7311 ph: +61 2 6257 7111
PGP Fingerprint E4FA ADE6 97A4 3610 E008 A466 A03E 3D01 4C17 8C9C
|