
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!
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.
As a membership organization, our members are our most important source of information. We try to stay in touch with all our members, look for them at conferences, and take all input seriously. However, to date we hadn’t gathered structured feedback on how we’re doing. To change that, we sent out a member survey at the end of last year. This is the first survey in what will become a yearly member satisfaction survey.
What has hundreds of heads, 91,000 affiliations, and roars like a lion? If you guessed the Research Organization Registry community, you’d be absolutely right! Last month was a big and busy one for the ROR project team: we released a working API and search interface for the registry, we held our first ROR community meeting, and we showcased the initial prototypes at PIDapalooza in Dublin.
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.
Today we are announcing our first new functionality of 2019, a much improved search for DataCite DOIs and metadata. While the DataCite Search user interface has not changed, changes under the hood bring many important improvements and are our biggest changes to search since 2012.
DataCite is pleased to announce our newest service. The link checker is here! Many of you have asked for an automated link checking service to help you maintain your DOI records, and it’s now out of the box and ready for Members to use. The link checker is a custom-built crawler (based on the popular open-source tool Scrapy) that works its way through one DOI per DataCite Client per day and attempts to follow the URL registered in the metadata.
All DataCite DOIs have associated metadata, described in the DataCite Metadata Schema Documentation (@https://doi.org/10.5438/0014), validated and stored as XML in the DataCite Metadata Store (MDS). These metadata are then made available via DataCite APIs and services. For these services XML is not always the best format, and we are thus providing the metadata in other formats, most notably JSON.