Michele Combs wrote:
> As far as the way the visible date is written, I would think that you
> need not bother changing that at all unless you have more time and money
> than you know what to do with; we don't usually alter the way the dates
> appear in legacy finding aids when we do conversion, unless for some
> reason it affects the usefulness of the finding aid (e.g. if the format
> is so vague as to be uninterpretable or ambiguous enough to lead to more
> than one interpretation).
Hi
Just thought I'd say that normalising dates needn't be a completely
manual and painful process: programming can come to your (finding) aid.
With a comparatively simple script one could parse EAD files, isolate
the non-normalised date elements, and generate new normalised dates.
Perl's DateManip module, for example, can reliably identify a wide
range of dates in vernacular forms, and output them in ISO8601 or what
you will. You'd still need to verify the output, but if there's nothing
too kinky, it might reliably do the lot.
http://www.cise.ufl.edu/~sbeck/DateManip.html#examples
Little scripts can speed things up a lot - try to find a friendly hacker
to write you one! :)
Normalising dates may not be a pressing imperative, if your present
system merely displays them, but posterity is likely to be grateful if
it starts wanting to sort or search collections, or do other analysis,
based on date-like properties.
Hope this helps
Richard
--
/ Richard M. Davis
\ Digital Archives Specialist
/ University of London Computer Centre (ULCC)
\ 20 Guilford Street, London WC1N 1DZ
/ +44 (0) 20 7692 1350
/ [log in to unmask]
|