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

Re: Archiving of Websites



This is certainly one approach, but as you point out, it is very labor
intensive.  In point of fact, most institutional web sites are laid out in
components.  The home page may remain fairly stable while the subsidiary
pages change from time to time, quite often retaining the same title and
address while varying content.  The arrangement suggests an organization by
series and subseries according to the components that make up the over-all
site.  As each component is changed, all that is necessary is to preserve
the replaced component, along with metadata that describe date and
provenance.

What is not preserved under such a scheme are those pages that are created
"on the fly."  But if the cgi scripts are preserved, then the page and its
linkages can be recreated when needed.  If a user wants to reconstruct a web
page configuration, he is in for a bit of work, it is true, but for the most
part, access is likely to be to the information in a particular component
series.

For example:  A college may put its catalog on line.  Degree requirements
may change from year to year.  The "hot key" that leads to the web document
"degree requirements" is on the home page and is unlikely to change the
address it links to, no matter how often the design of the home page might
change.  Likewise, that hot key will almost certainly remain on the same
page.  [If not, then a note to that effect would be in the finding aid,
analogous to the sort of notes that describe the shifting of some
department's function to another department in traditional institutional
archival practice].   As degree requirements evolve, each successive degree
requirement document can be stored in the series "Requirements" for later
historical or legal reference.

Suppose a student entering under the 2003 catalog graduates in 2008; in
order to see if she has met the requirements in effect when she
matriculated, she need only refer to the series "Requirements."  This takes
very little time.  IF a historian [for reasons that escape me, but we
historians do do strange things] should happen to want to see what the exact
web configuration of the whole web site was in 2003, he is in for a few days
of reconstructive work.  All in all, this system leaves the greatest amount
of work to the least likely user.

1.  Unlike the snapshot system, it creates the lowest levels of redundancy
and reduces ambiguity.
2.  For a "snapshot" to be inclusive of all the referred to pages, a map of
the entire system would have to be generated anyway.  Why not use the map to
direct component level storage?  This way we include it all and don't
accidentally pull in material from extraneous websites.
3.  Working through a component system is the most likely way for archivists
and records managers to work in a complementary fashion with web developers
and web masters.

John Howard Fowler
Consulting Archivist
3221 W. 177th St.
Torrance CA 90504-4003
310-327-5848
az248@lafn.org


----- Original Message -----
From: "Terry Kuny" <terry.kuny@XIST.COM>
To: <ARCHIVES@LISTSERV.MUOHIO.EDU>
Sent: Monday, 16 October 2000 8:59 AM
Subject: Archiving of Websites


> Hello everyone,
>
> I would like to know if the following strategy for
> archiving a corporate website makes sense from an
> archival perspective:
>
> 1. Take a snapshot of the website on some established
>    schedule with appropriate config files.
>
> 2. Compress and store on an active server, i.e. one
>    that has regular backup of disks and is maintained
>    as a corporate resource.
>
> 3. There is an organizational commitment to migrating
>    all the data on active servers according to regular
>    hardware and server upgrade cycles.
>
>
> I recognize the devil is in the details here...
>
> One of the questions I have is:
>
> Should a website "snapshot" be kept in an active location,
> i.e. on a server. Or should a copy be kept offline in an
> archival format (optical disk/tape)?
>
> Any other ideas about operationally how to integrate
> website capture into archival record-keeping practices
> would be appreciated. Is there a "simple" or "good enough"
> strategy that might be followed for small and medium
> sized organizations?
>
> Discussion and thoughts appreciated!
>
> regards,
>
> -terry
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------
> Mr. Terry Kuny                  Phone:  819-234-9621
> XIST Inc.                       Email:  terry.kuny@xist.com
>                                           URL:    http://xist.com/
>
>         Box 1141, St. E, Ottawa, Ontario, Canada K1S 5J1
> ---------------------------------------------------------------
>
> 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>
>

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>