Sheila,

We operate a bespoke management system at the AHDS that is used for
recordkeeping. As a data archive, we have slightly different requirements
that may not be applicable to an IR. However, the overall structure is
applicable. We've used all of the approaches you mention in your e-mail - we
began by storing a physical paper trail used to track projects. This was
later replaced by a departmental database, written in MS Access.

More recently, we identified a needs to establish a more consistent approach
across different departments and introduced an AHDS-wide tracking system,
intended to track our day-to-day work in a co-ordinated manner. This has
proven particularly useful, reducing the potential risk of different
departments inadvertently contacting the same person. There are dozens, if
not hundreds of query tracking software available. However, the ones that we
tested did not meet our needs or were too complex to use. In the absence of
an off-the-shelf system, a custom tracking database was produced using an
underlying Oracle database fronted by JSP pages (this is likely to change to
MySQL at a later date). To avoid potential problems when/if we replace the
system, we are able to export the database to an appropriate metadata
scheme, as well as tab-delimited text formats.

At the moment we use the management system for four purposes:

1) Recording contact details - it's useful to store contact details of
potential or existing depositors, funders, or other people that should be
aware of the IR. Typically, the information is used when contacting a
project towards the end of its funding, though we also use it to promote the
archive to relevant people in the research community.

2) Submission Tracking - Les summarised the purpose of submission tracking
in an earlier e-mail. In addition to storing information on the current
stage of negotiation and deposit (e.g. licence form has been sent to the
depositor, but has yet to be returned), we've found it useful to store
details of potential depositors that may submit data to us in the future.
Through discussion with a creator or a funder, we often discover that their
project is due to finish on a certain date and can set a reminder to contact
the creator on a specific date.

3) General query tracking - We developed a module to track general queries
about the archive - users who encounter problems when using the repository,
users who wish for permission to access restricted content (similar to
EPrints e-mail author request form), etc. This is used for reporting stats
to our funders.

4) Accession information - As an archive with a long-term commitment to
storing and preserving data, we also store extensive information on the
state in which data was provided and a workflow of data processing. Certain
information is unlikely to be relevant to an IR (unless you receive data on
physical media), but its useful to store details on actions performed (e.g.
migration), when they were performed, the software used and by whom, etc.

As I mentioned, our requirements are likely to differ from your own needs.
The database system that we currently use took several months to develop and
test, which may be too much if you are working in a single department and
impractical if you do not have access to server hardware. It's often easier
to scope your requirements, begin with an MS Access database and decide at a
later date if you require a more complex solution.

Regards,
Gareth
--
Gareth Knight
Digital Preservation Officer
Arts and Humanities Data Service
email: [log in to unmask]
phone: 0207 848 1979
http://www.sherpadp.org.uk/