The Haplo Repository has been carefully designed to meet the demands on institutional repositories. By using established information management principles, we’ve mitigated the pain points which have limited what institutions have previously been able to do with their repository. Here’s a few of the key benefits enjoyed by repository managers using Haplo:
Repository systems often can’t distinguish between John and Jane Smith if they both prefer the citation “Smith, J.”. They also get confused if Jane were to change her name to Jane McEnroe, and then prefer to be cited as “McEnroe, J.”.
Librarians figured out how to deal with the authoritative name for an author decades ago, and because the design of Haplo was influenced by a librarian from the start, we weren’t going to make the same mistake as other repository systems.
Haplo Repository creates unique records per person, not per citation, and the user interface enables the author to choose their citation text independently of the link to their profile. So different outputs can use different citations for the same person, and different people can have the same citation.
Managing the REF is a key priority for repository managers. Yet many older repository systems can only report a simple “Pass/Fail” status for REF compliance of items in the deposit process.
By properly managing metadata, Haplo Repository is able to provide a more intelligent solution. For example, if an item is still in the deposit process, it won’t yet have a deposit date required for REF Open Access compliance. However, simply labelling the item as “non-compliant” is unhelpful, as the item may still be deposited within the allowed 3 month time period from acceptance.
In cases like this, Haplo Repository displays a “Will pass on publication” status, enabling repository managers to know at a glance whether items need extra attention to achieve REF Open Access compliance.
Many repository systems have very limited data models, and as such struggle to store and manage records of a variety of types. Institutions have to work around this by having two repositories, one for research data, one for traditional outputs such as articles. Whereas for the researcher and those interested in the research, it makes far more sense to have all research outputs related to a research project in one place.
As well as this, it’s not uncommon for non-traditional outputs such as performances or videos to be stored in a third system or managed individually, because the repository can’t handle them adequately.
Haplo Repository can represent any type of information, and has been designed from the start to manage datasets, traditional and non-traditional output types together. The schema is incredibly flexible, and can accommodate new types being added at any stage, giving Haplo Repository users peace of mind that the system will be able to meet any requirements in the future.
With the rising importance of Research Data Management, being able to safely manage sensitive information is critical for a modern repository.
However, traditionally repository systems were designed to make all data and outputs available without restriction. It’s challenging to retro-fit security adequately onto a system that hasn’t been designed with it in mind, which leaves institutions having to shoulder the additional administrative burden of maintaining alternative, secure stores for sensitive information.
Haplo Repository has security as one of its core principles, and Haplo has been managing sensitive personal information properly for over a decade. By designing security in from the start Haplo Repository enables the deposit of all research data, with access to that data managed from within the system.
A successful repository is used by many different roles within an institution, which requires the repository to support fine-grained and flexible access permissions. Older repository systems were often created with a narrower set of users and permission requirements in mind, making it more difficult to support the rules that are required by the wider organisation, such as “Heads of Department should get administrative reports for items in their own department only”, or “authors should be able to update their own outputs”.
Haplo Repository systems include a fine-grained role based permissions system, so rules like these can be implemented naturally. Rules can be added down to the individual metadata field level, not just for the whole output, enabling administrative fields to be hidden to all but privileged users, or embargoed files to be available to output authors (but not any other researcher).
Supporting sophisticated handling of multiple embargoes for different files on an output is a natural extension of the wider Haplo Repository permission system. The schema adds different metadata fields for each kind of file (Version of Record, Accepted Manuscript, etc.), and a different embargo can be placed on each one, using the inbuilt field-level permissions system.