Introduction to populating an embedded repository

Whatever the precise model of embedding which is adopted in any particular institution, the challenge remains to get researchers themselves engaged in populating the system with metadata and outputs.

Routes to populating the repository may differ – for example, direct to the repository or via a research information system of some kind – and so are likely to be associated with different institutional drivers and policies which may well affect researchers’ motivations. For example, an institution may purchase a research information system because the process of collecting data for the RAE2008 was inefficient and onerous; it may then tell researchers that they must enter their publications data in it if they want to be submitted to the Research Excellence Framework (REF). A step on from this – and perhaps easier than pushing for deposit into a separate, unlinked repository – is to add the output itself. The research information system may be able to push out publications data to researchers’ profiles, and adding full text or objects to a repository to enable the profile to link to the actual article, book chapter, photograph or other content may make more sense to the researcher than before.

The more comprehensive any system is in terms of containing the largest proportion of information relative to the possible universe of information in that category, the more use it will be to internal and external users, and therefore the more it will motivate researchers to engage with it.

There is now a great deal of experience in identifying models of advocacy, motivations, and barriers to engagement. Some of these experiences may date from earlier stages of repository evolution, but they can still be highly relevant to the ‘embedded’ repository.

It seems to be generally agreed that simplicity of workflows, and therefore using the least time possible in the process, is absolutely crucial to achieving researcher engagement. This minimisation of effort by the researcher should be coupled with the maximisation of use and re-use of data entered. ‘Enter once, use many times’ is the mantra here.

Part of the minimisation of effort also encompasses the usability of the interface and customisation for particular user groups, for example, creative arts researchers.

Metadata is the glue that holds disparate systems together and drives much of the usefulness of the systems for researchers and institutions. Metadata can be created by humans or automatically generated; some metadata may not need to be created within the institution; it can be drawn from external systems or databases, for example from Web of Science.

However, there are always issues of quality and consistency in metadata, and also issues of interoperability between systems. There may be trade-offs where a system which cascades metadata downwards to a repository increases the number of records in it but downgrades the metadata the repository itself previously contained for the same records, or at least causes conflicts which need to be resolved.

Identifying and disambiguating authors’ name has long been a very important problem for many repositories. It is being addressed in a number of ways. Glasgow, for example, has tackled it by building an authorised list of the names of (Glasgow) authors, linked to their university IDs. There is also a JISC-funded project to create a shared service that can be used by institutions of all sizes, ensuring that effort in this area is not duplicated.

No comments yet.

Leave a Reply