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

Re: Archiving information within databases - long



yeah but...

Dean's analogy works fine as a whole for the series, but the individual
records themselves are set in stone (or polyester, or whatever MF is made of
these days); that is to say, whether or not a user picks out of an alumni
record on MF "Name, address, phone", the record will still hold, and one can
view, the seven other "fields" of information.

With a DB, assuming we're trying to capture the user's/creator's "records",
if there's a group of different users with their own interfaces, each one
pulling out select pieces of the DB as a whole & never seeing the rest of a
"record", is that a record or a subset of it?  If, for example, the DB
creator has a hidden field for his own purposes that the end-user never
sees, is that part of the record or not?  If you're trying to document the
creator's work, you care about that field, but if you're interested in the
user's use, it's not really part of the record.

I've been struggling with defining this subject myself for a while, so
perhaps you'll all indulge me while I attempt an example to see how it plays
out:

The town of Yehuppitz (common in my high school circles & the Orthodox
Jewish world as being the hind end of nowhere) has John Smith create a
database to keep track of all registered voters in the town.  John builds in
a hidden field to keep track of each time the DB is accessed, to keep
statistics and because he gets paid by the number of users on the system.

The town clerk Mike Jones and his staff have a set of user screens that they
enter data in, search on, and print out reports.  They never see the tables
behind those forms, they just do their own thing on the front end.

The town contracts out to Steve Barnes, the local printer to send out
mailings before election time, and he gets access to the names & mailing
address parts of the DB, using his own screens & reports.

The public has access at the local library to select reports generated by
the DB - demographic data, population density, whatever.

Now, you tell me - what's a record in this case?  The DB as a whole?  You
capture John Smith's experience, but maybe nobody else's.  The list of
mailing information at the printer's?  To him, that's the set of records, or
the "record"; the rest of the information doesn't exist as far as he knows.
Capturing the tables with the information in them, but not the access
screens used by the clerk's office doesn't tell you the whole story - you
have no idea how the information was used.

This one's been a brain teaser to me for a long time, and I don't know that
there's a clear answer.  Like all records, part of it lies in the needs of
the end user.  I for one don't know if it _really_ matters beyond how we
describe the information we've collected and explaining to patrons how it
worked.  That is, if seven possible uses for a DB exist, we should try &
preserve all means of reaching the underlying data in those seven ways, and
explain to the users that it's not as cut & dried as using a series of
personal letters.

The real kicker is to try & be sure you've got every piece of a DB.  My
current hideous, miserable, unpleasant experience with Microsoft Access (do
I sound unhappy?), in which I am trying to cover over the entire back end of
the DB so the users won't get confused has demonstrated that there are many
more constituent parts than I ever knew of when working in my beloved
DB/Textworks.  If one thing is out of place, it's quite easy to ruin the
whole DB; ergo, when we, as archivists, acquire these things, it's incumbent
on us to get the whole picture, from backend to front.

I'm sorry, I went on way too long.

DS

______________________________________
Daniel Sokolow, Archives Coordinator
David Taylor Archives
North Shore-Long Island Jewish Health System
155 Community Drive
Great Neck, NY 11021
mailto:dsokolow@nshs.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>