About this Guide
This guide is intended for people who want an overview of the service, and to determine if the Repository Junction Broker can supply a service to them.
The Frequently Asked Questions (FAQs) are provided to clarify the service and the terms under which it may be used.
If you have further questions about the service that are not answered by the guide please use the UK RepositoryNet+ Helpdesk contact form or send email direct to: support@repositorynet.ac.uk
About the Repository Junction Broker
The role of the broker is to act as a clearing-house between organisations who will receive deposits and organisations who have records they wish to deposit.
The RJ Broker is, in effect, a delivery service for research output that accepts deposits from data providers such as institutional and subject repositories, and funder and publisher systems. For each deposit, it uses the metadata for the deposit to identify organisations and any associated repositories that are suitable for receiving the deposit. It then transfers the deposit to the repositories (IRs) that have registered with the RJ Broker service.
In order to receive deposits from the RJ Broker, IRs have to register their SWORD credentials with the service to give the RJ Broker an access point to their systems for data input.
The RJ Broker: a Research Output Delivery Service post on the OA-RJ project blog provides background information on the origins of the broker service at a session of the 7th International Conference on Open Repositories (OR2012) held in Edinburgh in July 2012.
Why is a Broker needed?
A majority of articles are attributed to more than one author, and a significant number of those articles are written by authors from multiple organisations. This situation requires each record be entered separately into each Individual Repository, leading to a massive duplication of effort.
We know that there are Subject Repositories such as ArXive.org and PubMed Central, who have a rich source of published material. We also know Publishers already have submissions systems, and these systems are already a part of the academic's life, so why not make use of what is, after all, a deposit workflow, with another name.
These submissions systems will have all the metadata that is wanted: authors, title, abstracts, publication details, the correct version of the document(s), and availability (authors final copy or publishers copy, with or without embargoes). By tapping into the existing publishers systems, and the large subject repository ecosystems, and using these systems to supply the data, we can save hundreds of hours of duplicated effort for the Individual Repository.
In the world without a broker service, each Repository seeking data would need to talk to each Supplier, and each supplier might have different demands and requirements for engaging with users, and different formats for making that data available. This means that there would be (R x S) connections required: repository managers would need to negotiate with each supplier, and each supplier would have very similar talks with each of the repository managers. This idea simply does not scale: there is simply not the time for people do do that.
Having a central clearing-house means that both suppliers and consumers only need to negotiate with one agent, and each supplier/consumer only has to interact with one system, the broker. This means we reduce our connections to (R + S), a dramatic reduction, and save time and effort for everyone, capitalising on existing efforts for the benefit of all.
Advantages for Suppliers
For the supplier, there are a number of advantages:
- Increased visibility without much additional work.
- Individual Repositories are not usually blessed with a ready resource of technical staff, so IRs will generally be looking for solutions that work with minimal effort required on their part (meaning they want the work done by someone else)
- Publishers, in particular, have policies on copyright and self-archiving as listed in RoMEO. By supplying a deposit record, publishers can ensure that only the correct versions of the files are put into a repository, along with the metadata they want.
- Likewise, Publishers have embargo periods they want to define, and the Broker passes them on (and required adherence as part of the subscription requirement)
- The Broker is agnostic on the Green v's Gold argument, and suppliers can provide files and/or DOIs/URLs to the authoritative source, which the Broker will pass on.
- The broker makes metadata visible, but embargoes all files that are not Open Access (the period of that embargo is part of the agreement the Broker has with the supplier)
- Support for Open Access mandates and policies such as those of Europe PMC and the Welcome Trust.
Advantages for Recipients
The case for Individual Repositories is even easier:
- By receiving data from suppliers, the repository managers will:
- receive fairly complete records,
- with the correct files (vis-a-vis RoMEO conditions), and
- be reasonably sure of spelling and typos.
- With multiple suppliers to collect data from, using a broker means that only one negotiation is needed.
- Set up is easy and uses existing infrastructure.
- With just one data feed, only one suite of tools needs to be added to the repository.
- IRs will also not be reliant on all the various authors entering records into their own repositories, easing the administrative burden on research and academic staff.
- IRs are required to honour any embargo periods defined, as part of the “sign-up” agreement.
- Supports reporting to funders, compliance with Open Access mandates and promotes the institution's work and research output.
- Promotes interoperability between repositories by the use of a common deposit format.
Example Supplier Engagement
An example of how a publisher could interact with the broker is given, to demonstrate how the broker can benefit both parties. The example assumes the publisher has an existing submission system, which the Principal Author is familiar with, and already uses.
- The author submits an article, which is peer-reviewed and catalogued by the publisher, before entering the publication process.
- Upon publication, i.e. when the Issue, Volume, Page details are known, the Publisher then transfers the record metadata, along with any associated files to the broker.
- The broker returns a URL where the supplier can track any onward progression of the record.
- The publisher can now periodically query the broker to find out whether record has been transferred, and the submission interface can reflect that forwarding to the submitting author.
Online Access to the RJ Broker
The broker runs on an instance of EPrints v3 that provides an online interface through which the current contents of the broker can be browsed and searched. Insitutional Repositories interested in joining can appreciate the potential enhanced visibility, funders and suppliers can see the range of target repositories, and the online download process is illustrated.
For further details go to this URL: URL to be supplied.
Frequently Asked Questions
- What repository software does the RJ Broker currently support?
- The RJ Broker presently supports ePrints v3.2.1 - 3.2.2 using an EDINA supplied plugin and DSpace v3 out of the box. Fedora is not presently supported.
- Why do I need to sign a legal agreement to subscribe to the broker?
- The broker requires repositories to honour embargo periods. The legal agreement is the way that this agreement can be enforced.
- How long will the broker retain records?
-
Records are reviewed after a period (currently 6 months).
Records that have not been successfully transferred to any repositories are deleted in their entirety.
The metadata for records that have been successfully transferred are kept, however all associated files are deleted as they are available in target repositories. - What does the Broker do about duplicates?
- Nothing: this is currently out-of-scope for the Broker. Duplicates are a fact of life in the Information Age, and de-duplication is a topic fraught with issues and problems.
- What happens when a new Supplier joins?
- Repositories just get more records – they should not notice any other changes
- What happens when a repository goes off-line?
- If it is temporary, there will be a temporary hiatus in deposits until the repository comes back on-line
If it is permanent, then the Internet has some more broken links: this is an unfortunate fact-of-life for the Internet. - What version of SWORD is used?
- SWORD 1.3 See: http://swordapp.org/sword-v1.
SWORD 2 is not “in scope” for this version of the broker, however the development team are aware of it and have conceptual plans for including it in later versions of the broker. - Why is SWORD 2 not supported?
- SWORD 2 is focused on CRUD (Create, Read, Update, Delete), which is to say that it is designed to enable modifications, additions, and deletions from records.
The problem for the broker is this leads to an expectation that cannot be matched: that the Broker will modify and/or update records in Individual Repositories - Does the Broker support standards such as RIOXX
- The broker does not (currently) export data in any such standards (at the time of writing, RIOXX has not been published), however the broker does expose Funders and Grant Codes (where they are supplied), and has OAI-PMH ListSets for them.