RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jesse Wilkins <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Wed, 2 Apr 2008 12:46:10 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
Hi Fred, all, 

Let me preface this response with this: I am not an archivist. Not trained
as an archivist. Don't even watch TV shows that have archivists in them
generally speaking (only because I don't watch a lot of TV period :) ). 

I will defer on the color question. And I will to some extent agree to
disagree on the other question as I'm not sure that an uncompressed TIFF is
particularly less complex than a compressed one, for most compression
algorithms it supports. Group III and Group IV TIFF, at least, are not that
complex. 

<snip>
In addition, archivists often feel the best image capture is one that is of
sufficient quality that researchers don't bother to ask to see the original.
</snip>

I just don't believe that a 120+MB file fits this description. Maybe if they
are accessing the file locally but this is a file that cannot be emailed,
cannot be easily accessed over the Web, and will require lots of storage,
whether CD (5 files per), DVD (38 or so files, maybe 70 for DL) or even a
500 GB hard disk (4,000 files). Frankly, I also wonder whether a standard
TIFF viewer can view these files - I'm thinking Windows Imaging
specifically, but any other mainstream reader. If not, that suggests that
there's an accessibility issue to be addressed. 

I'd be interested though in seeing what current best practice is - NARA says
400-600, with 300 an acceptable minimum in some circumstances; APIS says 600
and 24-bit color as minimum; I imagine there are a number of others
including TASI, the various archivists' societies, etc. that could weigh in
here. But as was noted earlier in the thread, 1200 dpi used to be the
recommendation based on years of experience with the materials and the needs
of the users. That tells me that a) there is not as much consensus on this
as would probably be useful and b) what consensus there is changes over
time. Not that there's anything wrong with that - any practices should be
reevaluated periodically to determine whether they should be updated to
account for current practices. 

Finally, from my distinctly non-archival perspective, some of the issues in
the thread relate to the inherent limitations of the physical media as well
as the digital representation of that. In other words, there's no question
in MY mind that an archival photograph would be better scanned at higher
resolutions than lower, all else being equal. But for a document, what's
being archived might not necessarily be the physical object as much as the
content it represents. So for a document that's created electronically, if
it's printed and the electronic version discarded for whatever reason, but
later determined to be of archival value, that cheap office supply recycled
paper doesn't really need such a crisp image of it, so why save it such a
high-quality archival format? Better yet, why not save it as e.g. XML so
that there is zero chance of it not being able to be interpreted in 100
years - then it could even be printed for long-term preservation and simply
OCRed and reconstructed to its original digital format (and see my post
earlier about ODF and OOXML)?

And to come full circle, I don't know whether Kirk's documents are
digital-born or paper, but I *do* know that for every organization it will
be more the former than the latter as each year passes. Archival issues have
been and will continue to be raised for born-digital information that simply
aren't applicable to the physical world. 

Respectfully submitted,

Jesse Wilkins
[log in to unmask] 

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]

ATOM RSS1 RSS2