On 8 Mar 2007, at 16:05, Gareth Knight wrote:

> 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.
This sounds like something that could be co-ordinated or shared at  
some level. Surely every repository needs the contact emails of all  
the various publishers. Sounds like an extension to SHERPA-ROMEO to  
me (sorry Bill and Pete).

Can I ask whether your contacts are done via email or paper memos?  
Could/should a repository do this?

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

One of the suggestions that have been made to our repository  
developers is to work up a robust event management suite - to handle  
timeouts for licensing and embargoes, but also to keep track of  
managed programs of deposits and other situations as you have just  
described.

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

Do your enquirers raise "tickets"? That seems to be a common  
management tool.

> 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.
This is definitely in the realm of preservation  metadata to be  
managed by the repository.


I agree that if it is easier, one should probably use Outlook or  
Access rather than trying to fit extra functionality into a  
repository. But it is interesting to speculate about the boundaries  
of the system.
--
les