Hi Jenn,
We've been researching this issue at LC for MODS, PREMIS, etc. I have an inelegant solution to this that we didn't end up adopting for open ended ranges. It still complies with ISO8601, however, and it seems that a number of systems (Microsoft uses it in a number of apps) have used this format. If you use the string "PT0S" as the end date, that indicates an open or infinite duration. "P" is the 8601 designator to show an interval or duration, "T" means time, and "0S" means zero seconds. Some variations of this are PT0Y (year), PT0D (day), etc. They all mean the same thing when qualified as zero.
TEMPER didn't help with this either. I think it also recommends just leaving the unknown end date blank. No spec that I've seen has a way of indicating "a future date that /will/ end at some point, but we don't know when".
In your example, if you choose to use this, it would look like:
<unitdate normal="1970/PT0S">1970-</unitdate>
Clay
~~~~~~~~~~~~~~~~~~
Clay Redding
Digital Project Coordinator
Network Development & MARC Standards Office
Library of Congress
LA308, Mail Stop 4402
101 Independence Ave. SE
Washington, DC 20540
[log in to unmask]
202-707-7196
~~~~~~~~~~~~~~~~~~
>>> "Riley, Jenn" <[log in to unmask]> 12/06/07 9:04 AM >>>
Any other suggestions for how to encode an open-ended date range? Even if DACS says not to do this, not all EAD implementers will be using DACS. I know it's convenient to make @normal conform to the ISO8601 data type, but we're really excluding a significant use case here...
Thanks all!
Jenn
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf
> Of Kellams, Dina M
> Sent: Tuesday, December 04, 2007 7:33 AM
> To: [log in to unmask]
> Subject: Re: open ended-date range
>
> Because you'll probably hear this from others, according to DACS, we
> are no longer supposed to leave anything with open date ranges, but to
> instead give it a closing date and update it as necessary. I know, I
> know, I still have some finding aids out there with an open date range
> (BFC & Trustees) but I just haven't found it necessary to go back and
> clean those up yet.
>
> (DACS rule 2.4.8: When further accruals are expected, record the
> inclusive dates pertaining to the holdings currently in the custody of
> the repository. Record information about expected accruals in the
> Accruals Element (5.4). When the accruals are received, revise the date
> as necessary.)
>
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf
> Of Riley, Jenn
> Sent: Monday, December 03, 2007 7:36 PM
> To: [log in to unmask]
> Subject: open ended-date range
>
> Hello all,
>
> In working with finding aids encoded according to the EAD 2002 W3C
> Schema instead of the DTD, we've run into an issue with the
> unitdate/@normal attribute. The data type for the unitdate/@normal
> attribute doesn't see<unitdate normal="1970/">1970-</unitdate>m to support open-ended date ranges (because it's
> based on ISO8601, which doesn't support them either, is that right?).
> So what's the best encoding to use for a date range that, say, starts
> in 1970 and continues to the present day? These aren't valid:
>
> <unitdate normal="1970/">1970-</unitdate>
> <unitdate normal="1970/9999">1970-</unitdate> (that's a hack, but I've
> seen it in use before)
>
> I can think of these other options:
>
> <unitdate normal="1970">1970-</unitdate> (treat it as a single date in
> the normal attribute)
> <unitdate>1970-</unitdate> (leave the normal attribute off entirely)
>
> I don't like either of those options, though. What would you do?
>
> Jenn
>
> ========================
> Jenn Riley
> Metadata Librarian
> Digital Library Program
> Indiana University - Bloomington
> Wells Library W501
> (812) 856-5759
> www.dlib.indiana.edu
>
> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
|