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
|
