[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: capturing websites



Ms. Lowe--

This is NOT an attempt to argue against your system.  I really am
curious, and I 'd like to have more details and clarifications.  If I
seem to be raising objections it's because I am very interested in seeing
how you handle certain key concerns that I have in this matter.

I am still a little unsure what you are saying.  If you fetch HTML
documents and they have hot links to jpeg docs, shouldn't the browser you
use also fetch those jpegs, reproducing the entire page as it was
originally constituted?  True, the appearance may not be the same on your
browser as on mine, but that is the characteristic of web pages in
general.

Likewise, the problem of "scatter" through the server is confusing.  The
relative address of the links should work whether they are scattered or
if they are gathered together in one folder.  I grant you that dealing
with deeply hierarchialized file stuctures can cause some problems,
requiring a bit of sophistication in the software and initial system
design, but a system that can turn an HTML screen into pdf is pretty
sophisticated in itself.

Or is what you are saying that the Ur-document is actually a set of
word-processed documents that are captured in pdf and also translated
into HTML for use on the web?  If so, my own theoretical bias is that the
original document (the word-processed one) is what should be preserved,
although a pdf might be made available for distribution.

My experience with pdf formats has been that successive versions do not
translate very well, and that the storage of a pdf document automatically
implies preservation of the particular reader appropriate to that version
of the format, though it is true that Adobe seems to be getting a little
better in that regard, of late.  My own concern is to store as much as I
can in stable formats:  HTML, JPEG, TEXT-ONLY, et al., will probably be
around for a while, obviating much of the burden of translation and
specialty shells.

I am also intrigued by the idea that there exists a set of pdf tools that
can create less memory intensive files than a combination of HTML (which
is simply ANSI text-only) and JPEG.  On the face of it, it would seem
that one could not get more minimalist.  Has pdf technology gone
somewhere new while I turned my back on it?  [That is, this is very
interesting:  What software are you using to achieve this?]

I do agree that accessing replicas for public use is a critical function
of our work as archivists.  And I am impressed with the system you have
described.  It certainly is a step in the right direction.  As I said, I
just have some technical and theoretical qualms.  But I am certainly open
to instruction.

John Howard Fowler, PhD, MLIS
Consulting Archivist
3221 W. 177th
Torrance, CA  90504-4003
310-327-5848

On Thu, 15 Mar 2001 09:37:29 -0500 Joan Lowe <jlowe@AFSC.ORG> writes:
> [B]ecause it gives us an exact replica of the page including the
graphics, which we
> wouldn't get unless we also saved each individual graphic file in the
same
> directory. Our optical storage media (like all that I know about) does
not store
> files in directories but rather scattered throughout the media, so we
could
> not retrieve these files satisfactorily. The html can certainly be
> fetched, but we will get only the text and no graphics. Since it is,
after all, a
> web page, the graphics are important. ...

> [B]ecause pdf is what we use when we email simple requests -- nice,
neat, photo clear
> image in a portable document file -- MUCH smaller than a jpeg file --
and we
> send only one pdf file, pdq, rather than 5 or 10 or more graphical
files
> and an html. The reader is free and readily accessible to whoever wants
it.
>
> Joan Lowe
> American Friends Service Committee
> Philadelphia, PA  19102
>

A posting from the Archives & Archivists LISTSERV List!

To subscribe or unsubscribe, send e-mail to listserv@listserv.muohio.edu
      In body of message:  SUB ARCHIVES firstname lastname
                    *or*:  UNSUB ARCHIVES
To post a message, send e-mail to archives@listserv.muohio.edu

Or to do *anything* (and enjoy doing it!), use the web interface at
     http://listserv.muohio.edu/archives/archives.html

Problems?  Send e-mail to Robert F Schmidt <rschmidt@lib.muohio.edu>