Cover Sheets:
A cover sheet is usually an extra page to a document inserted at the front. This is not the same as a title page that a content creator might use on an individual ad hoc basis (see the guidance about adding a title sheet to the individual software packages in the content creators section), a cover sheet approach in a repository will ensure an consistent application across a whole group of (if not all) objects within the repository and will include some standardised information. For example, a cover sheet will frequently include copyright information or details about other repository policies.
Adding a cover sheet to digital objects is an excellent way of imbedding version information into an object. This is primarily most useful for text documents, including articles and presentation slides, although a cover sheet could also be manifested as an extra worksheet in a spreadsheet.
Some repositories are already using standardised cover sheets for text documents held in their repository.
For an example of a cover sheet including version information, see here: http://eprints.lse.ac.uk/2631/.
Information that a coversheet could include:
- Title
- Author(s)
- Dates
- Details of the hosting repository
- Identifiers
- Digital Object Identifier (DOI - external link)
- URL of metadata record/splash page
- Version description:
- possibly using a controlled vocabulary or taxonomy
- version number
- Citation
The process of adding a cover sheet is straightforward in word processor type documents, but could be handled two ways for presentation slides. If these are being sorted by the repository in PDF format (possibly as part of a policy decision to use certain open file types) then the cover sheet could be added as a text document at the start of the newly created PDF file.
Pros:
Uniformity:
The object continues to be indentified clearly, including its
version status, even if it is removed from the repository itself. For
example, if it is saved to a desktop or saved and uploaded to somewhere
else, such as a slide-sharing website. A user familiar with a
repository's cover sheet system will be able to identify the right
information incredibly quickly and easily.
Detail:
A cover sheet allows the best possible opportunity for all
versioning detail to be given and to embed a significant amount of
useful information. Not only can all of the types of essential
versioning information (dates, taxonomies and so on) be used, any fields
can be fully and properly described, for example, a number of dates can
be given, each with their status made clear. Furthermore there is room
if required for a free text comment, explaining any specific potential
cause of confusion.
Linking to other repository information:
The versioning information is present in the same places as other
information, such as copyright policies, that might be related. For
example, when referring to copyright status, the user does need to know
which version in the publishing workflow he or she is viewing.
Cons:
Time and Resource Commitment:
A manual process of adding cover sheets can be labour intensive and
ultimately poses questions about scalability. The VIF team is aware that
some discussion of developing an automated tool to generate cover sheets
has taken place and strongly encouraging more work in this area.
Perceived interference:
Academics might not like their work being interfered with, and may
prefer to have their work left as it was upon deposit. A related issue could be the introduction of branding on the coversheet that the author does not welcome,
such as a university or repository logo.
Some content creators may also feel aggrieved that the introduction of a cover sheet relegates the start of their content (e.g. abstract and beginning of article) to the second page.
Page numbering could be altered or made unclear by the process:
There are ways of avoiding, or at least minimising this potential
problem. Please look at the Information about Page Numbering
page.
Preservation Issues:
Some may view the object as
representative of how the research process stands at the time of
deposit, and that altering
it, even in such a 'behind the scenes' way, is a threat to the
integrity of the work in an archiving sense. One answer to this is
to record information about any changes made in the course of depositing
or preserving an object in specific preservation metadata, known
as PREMIS.