DataCite DOIs describe resources such as datasets, samples, software and publications with rich metadata.

We’ve previously shared with you our plans to migrate all of our services from Solr to Elasticsearch. (See for example our 2019 preview [@https://doi.org/10.5438/bckb-qy95] or how we’ve used Elasticsearch to make an improved DataCite Search [@https://doi.org/10.5438/vyd9-ty64]. Elasticsearch is already a key component of DOI Fabrica and of DataCite Search, and we’re in the process of bringing it to our other services, too.

When we launched the DOI registration form in DOI Fabrica last year, we purposely kept it pretty basic. We wanted to get the most-used metadata fields in front of the people who needed them as soon as possible. But it’s always been our intention to expand the form and make it more useful for more metadata needs for more people. Today we’re announcing a new and improved DOI Fabrica form that takes a step in that direction. What has changed?

Those of you attending the recent General Assembly might have heard us talk about how DataCite is at a crossroads. We’ve spent the last several years building and honing the infrastructure necessary to make it simple for institutions to create and manage DOIs for their data, and our members have created DOIs for a host of different research outputs.

DOI metadata provenance is describing the history of a particular DOI metadata record, i.e. what changes were made when and by whom. This information is now stored and provided via an API for all DOI registrations since March 10, 2019. The following provenance information is now available via a new /activities REST API endpoint: prov:wasGeneratedBy . The unique identifier for the activity making changes to a DOI record.

As part of our 10-year anniversary, we want to tell you the story of how DataCite was founded 10 years ago. Therefore, we approached several people ‘who were there’ to tell you their part of the story. This guest blog post is by Frauke Ziedorn, who was TIB’s DOI Service Manager from 2010 until 2015 and the first co-chair of DataCite’s Metadata Working Group. I came to the TIB and DataCite in 2010.

On April 1, DataCite organized its yearly member meeting and General Assembly. This year it was not just a chance to present and discuss DataCite’s current activities, but also a celebration as we look back on 10 very successful DataCite years!

This post has been cross-posted from the FREYA blog. Persistent identifiers (PIDs) are not only important to uniquely identify a publication, dataset, or person, but the metadata for these persistent identifiers can provide unambiguous linking between persistent identifiers of the same type, e.g. journal articles citing other journal articles, or of different types, e.g. linking a researcher and the datasets they produced.

The DataCite Metadata Schema is the basis for the metadata you submit to DataCite. It tells you the available fields and structure for your metadata records, and it’s what we validate against to make sure everything is as it should be. The metadata schema is maintained by the Metadata Working Group, which is composed of member representatives. The Working Group meets monthly to talk through issues raised and to plan new releases of the schema.

At the end of last year, we made significant changes to how testing works for our Members and Clients. We re-introduced a completely separate test system and did away with testing within the production account. We think these changes will ultimately make testing clearer and easier to understand.

As self-confessed PID nerds, we’re big fans of persistent identifiers. However, we’re also conscious that the uptake and use of PIDs isn’t a done deal, and there are things that challenge how broadly these are adopted by the community.