 |
 |
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/