Working with the British Library and DataCite Institutional Case Studies

Transcription

1 Working with the British Library and DataCite Institutional Case Studies

2 Contents The Archaeology Data Service Working with the British Library and DataCite: Institutional Case Studies The following case studies present the experiences of three British Library DataCite clients. These include both subject-specific and institutional data repositories and demonstrate the differing approaches to using the service. We hope that they will be useful for institutions that are considering signing up to use DataCite with the British Library. The Archaeology Data Service 01 The University of Bristol research data repository: data.bris 05 The University of Southampton 08 The Archaeology Data Service (ADS) started working with the British Library and DataCite in This case study follows the ADS from their initial decision to adopt DOIs, through to the process of planning and development that was required to integrate DataCite into their existing infrastructure and workflows. About the ADS The ADS is an open access repository of digital archaeological research outputs. The service, which is based at the University of York, was established in 1996 to support archaeological research and teaching in the UK by providing access to high quality and dependable digital resources. It caters to archaeologists across the spectrum: from professionals in the academic and commercial sectors to amateur enthusiasts. Over one million digital objects are held in the repository, ranging from simple documents and spreadsheets to 3D and remote sensing data. Most objects are part of a larger archive representing the output of an archaeological investigation. As of January 2015, the ADS hold over 455 such archives. Beyond these, the ADS also hosts the Grey Literature Library 1 : a collection of over 30,000 previously unpublished fieldwork reports generated from commercial archaeological investigations. ADS Archive and data DOI module Collection Management System (CMS) API Depositors Digital Archivist Data ADS archiving ADS Web Interface Grey Literature Library DataCite Store Depositors Reports OASIS ColdFusion Transfer Reports and API capture within OASIS Figure 1 Infrastructure of the ADS repository, showing both modes of data deposit (direct deposit to archive and grey literature via OASIS) and interaction with the DataCite 01

3 Working with DataCite Why DOIs? The decision to adopt Digital Object Identifiers was primarily driven by a desire to increase the citability of ADS-held data. A characteristic of archaeological research is that the investigative process itself is destructive, meaning that raw data collected during an investigation becomes the primary record. Preserving and managing this data for future generations to re-visit is therefore particularly important. Establishing an effective means of citation is a vital part of this. While other identifiers (such as ARKs) were considered for use in the repository, the infrastructure and centralised resolution offered by the DataCite DOI system was judged to best serve the needs of the ADS. Many service users were already familiar with DOIs as a means of citing traditional publications, which was an additional factor in their favour. Policies and planning The decision to use DOIs as persistent identifiers was just the first stage in the process. A number of policy decisions then had to take place before minting could begin, the fundamental question being: what do we attach a DOI to? Granularity Content in the repository exists at many levels of granularity: from archive (or collection) to individual digital object, i.e. file. An archive consists of a collection of related digital objects and their associated metadata. After an initial assessment of the needs of ADS users and of existing repository workflows, it was decided that DOIs should be minted at archive level. Applying DOIs at this level integrated well with existing ADS practices as landing pages had already been created for each archive. In addition, the contents of an archive are, in most cases, unlikely to be subject to further changes, so are particularly suitable for persistent identification. Examples of ADS archives: As content in the Grey Literature Library is deposited in the form of reports, which represent the output of individual investigations, DOIs are applied at report level. These reports are usually single documents although they occasionally contain multiple files and are similar to archives. Examples of Grey Literature Library records: Versioning Although most ADS archives are deposited in their completed state, for some collections, a regular program of updates is agreed with the data producer. In such cases a new DOI is issued and the edition number in the archive metadata is amended to keep track of the number of versions received. The landing pages of the older versions are updated to direct users towards the latest version of the data. For example, resolving the DOI / returns a landing page which informs users that the data has an updated version and provides a link to the new landing page. Embargoed data Only open and non-sensitive data is hosted by the service but, occasionally, an archive is deposited which must be embargoed while the associated publication is completed. A DOI can still be minted and published with a temporary landing page to allow data citation. Once the data is ready to be released, the DOI is updated with the new landing page. DOI syntax Once the decision on what DOIs should be allocated to had been taken, the format of the DOI had to be agreed. The ADS chose to use a system of opaque numeric identifiers drawn from a sequence ( ) for their DOI suffixes, a method selected for its simplicity. These are prefixed with their unique data centre identifier ( ). For example: / and / Integrating DataCite into ADS systems The large number of archives and reports in the repository meant that the ADS chose to semi-automate the minting process using the DataCite API 2. The first task after signing up with the British Library was to mint DOIs for each of the archives and grey literature reports already in the repository. A custom script was designed to grab completed archives from the Collection Management System (CMS) database and send requests to the DataCite API to mint DOIs in bulk. This script took the landing page URL of each resource, automatically generated a DOI and sent these details to the DataCite Store (MDS). Building the service To manage the day-to-day interaction with the Store, a custom DOI module was built for the CMS which allows the Digital Archivists to carry out most tasks from within their existing workflows. This module had to accommodate the requirements identified in the planning stage and performs the following tasks: Mint DOIs for new deposits (as described above) Update landing pages: The URL for a new landing page can be automatically sent to the Store via a pop-up in the module Mint new DOIs for updated archives: To manage versioning for archives that are periodically updated, the module allows the Archivist to mint a new DOI with the current landing page and to amend the landing page for the original DOI with information about the update Compare metadata: The ability to directly compare CMS and DataCite metadata records ensures that any change made to metadata in the Store is reflected within the ADS system. A different approach had to be found for grey literature reports, which are deposited in an intermediate service (OASIS) 3 and are effectively published as soon as they enter the ADS system. The original code written for the archive DOI minting process was adapted to allow the DataCite API to interact directly with OASIS, sending a DOI minting request automatically at the point when the record is transferred to the Grey Literature Library. So, by making use of the API, both ADS content streams can be managed by the Digital Archivists from within their existing workflows with very little additional effort. ADS project-level metadata is based on an extended Dublin Core schema 4 which maps closely to the DataCite schema 5. Depositors are asked to complete a project-level metadata template 6 for their data which is input into the CMS by the Digital Archivist. This metadata is mapped to the DataCite metadata schema. For Grey Literature Library items, the metadata is captured externally within OASIS and then automatically sent to the Store

4 The University of Bristol research data repository: data.bris Summary The ADS s experience as an early user of DataCite DOIs demonstrates that the service is sustainable over the longer term and, after the initial set up, can be managed with little additional resourcing. The nature of the repository also shows that DataCite can be integrated into a relatively complex workflow. Although assigning DOIs at archive level is sufficient for most citation purposes, in the future the ADS will mint DOIs for individual digital objects within the archives. But, with more than one million digital objects and no existing mechanism to create landing pages for each of these, this will take time to realise. The Jisc-funded data.bris project was set up to establish a pilot data repository at the University of Bristol. As part of this project, data.bris signed up with the British Library s DataCite service and has begun minting DOIs for data. This case study looks at why data.bris chose to work with DataCite and what they have learned from their first experiences of issuing DOIs. As the pilot develops into a fully-fledged institutional data repository, it also considers what further developments might be made. References and Resources 1 ADS Grey Literature Library 2 DataCite API documentation 3 OASIS: Online AccesS to the Index of archaeological investigations 4 Dublin Core Element Set, Version DataCite Schema Repository 6 ADS metadata templates depositcreate3#section-depositcreate creatingrecordsfordatasets Acknowledgements This case study was based on a piece written by Michael Charno, Applications Developer at the Archaeology Data Service. About data.bris The data.bris project built upon the University s existing Research Data Storage Facility (RDSF), which offers secure, long-term storage for data created by Bristol researchers. As well as making selected data held in the RDSF 1 accessible via a public interface, data.bris offers curation, policy and training to complement the basic storage service. Data.bris focused solely on data from the Faculty of Arts, but as the project moved into a two year pilot Research Data Service, an institution-wide data repository was launched in The focus of the repository is on data that does not have an obvious home elsewhere in a subject repository like the UK Data Service, for example and researchers will be helped to find the most suitable location to deposit their data. Working with DataCite Why DOIs? From early on in the project, the data.bris team knew that they wanted to have DOIs for data in the repository. As well as the obvious benefits of being able to more easily identify and cite data, the team felt that there were other, less tangible, advantages to joining the service. First, the association with established organisations like DataCite and the British Library was invaluable when making the case for the service to researchers and managers within the University. Signing up to the service early on was also a demonstration of the project team s commitment, which was a great help when promoting the service to potential users. Additionally, the standards offered by DataCite in the form of the metadata schema and recommended citation format were an attraction, as was the sense of being part of a community of organisations that are all working towards similar research data management goals. Policies and planning The team took an iterative approach to developing policies for DOI issues, and intend to continue learning and adapting as the service matures. The following, however, should serve as a good basis for the initial minting requirements of the repository service. What will have a DOI? The repository only accepts data that is the product of University of Bristol research that underpins (or will underpin) a published output or is part of a research project. DOIs will be automatically assigned to data upon deposit

5 Openness The focus of the data.bris project was on openness and accessibility, so all repository content was to be fully open (available under the terms of a Non-Commercial Government Licence for public sector information 3 ). However it quickly became clear that there was a demand to provide access to restricted data. Therefore the University is setting up policies and procedures for providing controlled access to data. Data.bris specified a minimal set of mandatory metadata 4 that is based upon the five DataCite mandatory properties: Identifier, Creator(s), Publisher, Title and PublicationYear. These were chosen as they satisfy the requirements for citation and can also be mapped to Dublin Core, meaning that repository metadata is compatible with other services within the University. The basic metadata is collected upon deposit and enriched by a range of additional information, some of which is automatically generated (e.g. by extracting information from the deposit itself) or captured from other sources, such as the University s Research Information System. Despite the lightweight deposit process, many more items of metadata are available to the end user from the data.bris Research Data repository interface. Integrating DataCite into the repository The first DOI was minted upon request by a University of Bristol virologist who wished to make the data underlying a published article permanently accessible by other researchers. The dataset in question can now be cited with a DOI as: David Matthews. (2012). Integrated Omics - Human. University of Bristol. doi: /bris.12mjtnrtsdjfs17sl4pq2ucqrk Although this was an unplanned experiment with DOI issuing, the process served as a valuable trial of the minting workflow. Compatibility with other services As the data.bris repository was developed and built from scratch, the team had the luxury of being able to choose which tools to incorporate, the only major constraint being the need to ensure compatibility with other university services. Summary With the technical infrastructure for the repository already in place, a key challenge for the team is testing how scalable their processes are as demand for data publication increases within the institution. The deposit process has been designed to be under the control of the individual researcher, but relies on repository staff to quality assure the metadata and to authorise the request for a DOI to be assigned to the dataset. Setting up the repository was only the first stage and a major focus of the first few years. In the medium to longer term the Research Data Service will have an additional important role in ensuring that research data held at the University is adequately maintained and preserved where appropriate. These curation tasks include making sure files are still accessible, technical format changes, checksum integrity checks, migration across platforms, etc. References and Resources 1 University of Bristol Research Data Storage Facility (RDSF) 2 Open Data Commons Licenses from the Open Knowledge Foundation non-commercial-government-licence.htm 4 Data.bris blog post explaining the choice of mandatory metadata properties 5 Pure, research information management from Elsevier Research Data Management guidance for University of Bristol researchers Acknowledgements Thanks to David Boyd and Stephen Gray of data.bris for talking to us about their work with DataCite DOIs. Bristol has an existing institutional repository based on Elsevier s Pure tool 5. Eventually is it envisaged that researchers will be able to create the metadata for their data deposits through the Pure interface and link them to the repository. Data.bris worked not only with other Bristol University services but also with external data repositories (currently UKDA, NERC and ADS) to harvest University of Bristol data. The ultimate aim is to hold metadata-only records of all externally-held data

6 The University of Southampton The University of Southampton has long been at the forefront of new initiatives in research dissemination and communication. Projects like the now widely-adopted eprints software were developed there and, currently, projects like the ecrystals repository and LabTrove are bringing new possibilities for data sharing to the research community. The University of Southampton mints DOIs for content in these services, as well as the institutional data repository. This case study looks at these three distinct use cases. ecrystals Southampton s first experiments with DOI minting were for data held in the ecrystals repository, a national open access archive of crystallographic data that is managed by the University s Chemical Crystallography Group. Each entry in the repository consists of a collection of files relating to the x-ray diffraction study of a single crystal. The experimental results, which may include raw and processed data, images and documentation, are accompanied by bibliographic information: sample owner, data collector/processor and details of the experimental process itself. A DOI is allocated at study level, i.e to each entry in the repository, enabling researchers to cite the results in any subsequent paper. As the crystal structures are frequently the subject of ongoing study, ecrystals operates a standard embargo period of three years following the original analysis. A DOI is automatically minted once this embargo period is over. Applying DOIs to a well-established archive like ecrystals has provided feedback during the development of Southampton s wider DOI minting activities. LabTrove LabTrove is an electronic lab notebook (ELN) service that was originally developed as part of the Jisc-funded Smart Research Framework project 1 and is now managed by the University of Southampton. The blog-style format allows researchers to share their notes, observations and data throughout the entire experimental process. Fully documenting the research process in this way allows other researchers to reproduce and adapt the original experiments. To facilitate the re-use and citation of this material, DOIs are being assigned to individual Notebooks. In future, the aim is to be able to issue DOIs at varying levels of granularity, for example for an individual entry, or subset of entries, within a Notebook. Data in the Institutional Repository The University s research data is held in the eprints-based institutional repository. Although, at the time of writing, they have not yet minted their first data DOI, when the full service is running, like data.bris, the repository will accept any University of Southampton data that does not have an obvious home elsewhere, for example in a subject-specific repository. There will also be significance testing to establish which data should be deposited, although this will happen at discipline level and will not be carried out by repository staff. The DOI allocation policy is still to be fully determined, although certainly any data that supports a published article will be eligible for a DOI. In principle, if a researcher wishes to have a DOI for a dataset, they will consider it. There is also ongoing discussion as to whether theses in the repository should be eligible for DOIs. One particularly interesting feature of the Southampton repository is their adoption of the newly developed ReCollect plug-in 2 which enhances eprints ability to manage complex data, with an expanded metadata profile based on DataCite, DDI and INSPIRE standards. The data deposit workflow is a work-in-progress, and the repository will develop and adapt the service as they learn what works best. They may develop disciplinary data deposit models to provide guidance for depositors. Summary The University s flexible approach to data management reflects the evolving status of institutional RDM practices. Best-practices and standards are yet to emerge, and the ability to adapt as users needs become clear is hugely beneficial. This pragmatic attitude extends to DOI allocation, with policies and procedures being developed through practice and community requirements. Southampton s example also illustrates the wide-applicability of DOIs, with use-cases in the institutional repository, ecrystals and LabTrove. Having multiple services under one umbrella also means that lessons learned in one sphere can be of benefit throughout the institution. References and Resources 1 Smart Research Framework 2 ReCollect plug-in for eprints University of Southampton Research Data Management guidance for researchers University of Southampton Research Data Management Policy Acknowledgements Thanks to Wendy White, Head of Scholarly Communication, and Simon Coles, Researcher and Director of the National Crystallography Service, for their help in compiling this case study

7 Contact If you d like to talk to us about using DataCite DOIs in your organisation, please us at datasets@bl.uk