Maintenance and Support of Open Access Repositories

Support Services

Contact details for support should be liberally spread throughout your repository website. You should at least provide a generic support email address and helpline phone number. Better still, named contacts for support because people tend to prefer to contact a specific person than a generic helpline. There should always be someone available to answer queries as promptly as possible. Ideally there should be more than one person to field queries, even if one person simply takes messages for the main contact during busy periods or absences.

You are likely to receive requests for general advice on the eligibility of depositors and material, and on any institutional mandates and policies. you are also likely to get requests for practical advice on registration, PDF-making, and deposition. All these topics may already be covered by your online guides or FAQ. Direct requests may therefore indicate a lack of clarity, so you should constantly review your online documentation in the light of queries.

Any requests to investigate alleged copyright violations or to remove items should be dealt with as a matter of priority.

Suggested Workflows

It is generally good to establish a routine, either daily or weekly, depending on your deposition rates. Typical tasks include:

• Acknowledging newly-submitted items, if this is not done automatically by your software.
• Checking the eligibility of depositors and/or the types of item being deposited
• Verifying, and if necessary querying copyright permissions
• Validating metadata. There may, for instance, be a need to check which version of the item is being deposited (i.e. preprint, author's peer-reviewed version, published version, etc.
• Approving the submissions - i.e. making them publicly visible.
• Releasing embargoed full texts when the relevant period has expired - if your software does not do this automatically

Mediated Deposition

There are additional steps to be inserted into the workflow if you have mediated deposition rather than self-archiving. Typical extra tasks include:

• Obtaining all the required metadata from the author, and
• Creating PDF files from the authors' original native-format documents.

PDF-Making Services

Creating PDF versions of documents for depositors is one of the defining features of a mediated service. Native-format documents that arrive as a single file should be straightforward to process, but it becomes more complicated where there are multiple files that need to be interpolated. Typically, the extra files may be figures, illustrations, tables or appendices, created using a variety of software packages. The additions may also use different page sizes - the equivalent, for instance, of a hard-copy A3 fold-out table.

Most PDF-making will allow you to 'print' PDF files from Microsoft programs such as Excel and PowerPoint. The compatibility or facilities offered by other more specialised packages such as LaTeX or chemical drawing packages may vary. In some cases, you may even need to scan hard-copy originals.

Decent PDF-making software such as the full version of Adobe Acrobat will allow you to merge separate PDFs into one large file. This may be the best approach, rather than trying to converting multiple documents directly into one PDF. Your PDF-making package may also provide additional features such as internal linking, subdocuments and so forth. You should decide whether or not you wish to offer these options as services to depositors.

Good Administrative Practice

Much administrative practice has already been covered above under 'Suggested Workflows' and 'Mediated Deposition'. There some additional requirements that occur less frequently:

Despite the innocent goodwill of your depositors and your own administrative vigilance, it is still possible that something may get into your repository that should not be there. You may receive a complaint about copyright violation from a publisher, or possibly a thesis may have been accidentally deposited containing material that could invalidate a patent application. You should already have policies in place to deal with such eventualities (see Submission Policies and Preservation Policies). All such situations must be investigated to see if the complaint is valid. It is usually advisable to remove the relevant item from public view immediately while the investigation takes place. This would become permanent if the complaint is upheld. Otherwise, the item can be reinstated. In many cases, however, it will be a corrected or revised version that is reinstated.

The other main requirement relates to preservation. Firstly, it is important, at the very least, to ensure that regular back-ups are made of the repository - usually by your IT systems administrators. A full back-up should be made at least every week, with daily "sinces" in between. You should also ensure that effective file restore procedures are in place with acceptable turn-round times. Ideally you should test that backups work correctly.

In the longer term, you may wish to use a preservation service, such as the one operated by the Centre for e-Research (CeRch) at King's College London (formerly AHDS).

Software Upgrades

There are three sorts of software upgrade:

• Software patches - These amend the installed software and usually fix specific bugs.
• Minor upgrades - These typically correct bugs and/or add minor functional enhancements, and will usually incorporate any earlier patches. In most cases, you need to do nothing more than download and install the upgrade file.
• Major upgrades - These may entail changes to the data model (i.e. the way information is stored in the database), and/or radical changes to the user interface. Consequently, you may need to migrate your existing data into the new data format, re-customise the user interface, and possibly modify your workflows and advice to depositors.

Whatever the type of upgrade, you need to handle it systematically. Carefully read the accompanying documentation to find out what the implications might be. For instance, will you have to re-customise the software? Will you have to shut down the service while the upgrade is installed?

For all but the simplest patches and upgrades, you may need to do a trial run on a development installation. This is where you would do any re-customisation, develop and test your data migration scripts, and run acceptance tests. Using this experience you can then plan the steps required for the final changeover, so that it can be completed in the quickest possible time with minimum disruption to end users.

If you need to re-customise the software, the copious notes you should have made when you originally installed the software will be indispensible. If you are lucky, you may just need to repeat the same steps, but if the functionality of the software has changed radically, you may need to make further modifications. Once again, thoroughly document the changes you make.