Figshare is building out our existing data (or non-traditional research outputs) repository functionality to cover all the functionality needed for a traditional Institutional Repository (IR). We have worked hard over the past 5 years to build what we believe to be the best data repository available. We have worked on distributing our infrastructure to comply with funder storage policies around the globe, whilst consistently adding functionality, from citation counts to customizable metadata. As such, we now have a customizable system that can live on institutional domains, with institutional branding and institutional DOIs. We accept any file format and are focussed on making all outputs findable, accessible, interoperable and reusable (FAIR) for humans and machines.
So when we were approached by Monash University to see if we could fill their need for a new thesis repository without them having to buy a new system, we found that we already provided the functionality they needed. A lot of this functionality centered around the ability for administrators to review and approve content before it was made live. When combined with group level custom metadata and landing pages to filter content by type (eg. videos, papers), our clients also suggested that we could provide all of the functionality needed for an IR. A couple of gap analyses later and we highlighted the extra functionality needed in 2018 to be as good as the best IR services available today. We began an IR working group with around 100 institutions represented and got feedback on why this approach fits so well with their current workflows.
The above small scale quizzes identified the following as the biggest factors in determining which system would work best for their institution:
Looking back, funder policies around open access to all research outputs means institutions are paying for several repository systems. However, tightening library budgets indicate that an all encompassing system would be a better fit. We are very aware that it is harder to add data support to existing repository systems than it is to add IR gaps to Figshare. Our ability to handle individual files up to 5TB means that even the biggest monograph can be accommodated.
Our team has experience migrating content from DSpace, ePrints, and bepress repositories, and we have begun moving clients onto a single repository system. Some decisions still need to be made on the client end about how many front ends make sense, even with a single backend. Would academics prefer to use data.institution.edu and papers.institution.edu or just repository.institution.edu? We have also began working on a core set of improvements:
In 2017, COAR defined a next generation repository as one that:
This fits perfectly with our vision for the future of repositories. Interoperability between academic systems is as important as interoperability between research outputs. Some of team Figshare’s core beliefs are that:
We know we haven’t answered all of the questions in this fast moving area. My colleague Patrick highlighted some important discussions to be had with the community and our IR working group in a recent talk:
We’d love to hear your thoughts on these questions and anything described above. If you are interested in hearing whether these ideas would be a good fit at your institution, pleaseget in touch at firstname.lastname@example.org or via twitter, facebook or google+.