This year, metadata development is one of our key priorities and we’re making a start with the release of version 5.4.0 of our input schema with some long-awaited changes. This is the first in what will be a series of metadata schema updates.
What is in this update?
Publication typing for citations
This is fairly simple; we’ve added a ‘type’ attribute to the citations members supply. This means you can identify a journal article citation as a journal article, but more importantly, you can identify a dataset, software, blog post, or other citation that may not have an identifier assigned to it. This makes it easier for the many thousands of metadata users to connect these citations to identifiers. We know many publishers, particularly journal publishers, do collect this information already and will consider making this change to deposit citation types with their records.
Every year we release metadata for the full corpus of records registered with us, which can be downloaded for free in a single compressed file. This is one way in which we fulfil our mission to make metadata freely and widely available. By including the metadata of over 165 million research outputs from over 20,000 members worldwide and making them available in a standard format, we streamline access to metadata about scholarly objects such as journal articles, books, conference papers, preprints, research grants, standards, datasets, reports, blogs, and more.
Today, we’re delighted to let you know that Crossref members can now use ROR IDs to identify funders in any place where you currently use Funder IDs in your metadata. Funder IDs remain available, but this change allows publishers, service providers, and funders to streamline workflows and introduce efficiencies by using a single open identifier for both researcher affiliations and funding organizations.
As you probably know, the Research Organization Registry (ROR) is a global, community-led, carefully curated registry of open persistent identifiers for research organisations, including funding organisations. It’s a joint initiative led by the California Digital Library, Datacite and Crossref launched in 2019 that fulfills the long-standing need for an open organisation identifier.
We began our Global Equitable Membership (GEM) Program to provide greater membership equitability and accessibility to organizations in the world’s least economically advantaged countries. Eligibility for the program is based on a member’s country; our list of countries is predominantly based on the International Development Association (IDA). Eligible members pay no membership or content registration fees. The list undergoes periodic reviews, as countries may be added or removed over time as economic situations change.
Notification callback is a service you can use to notify you when a submission log, either in the test or production admin tool, is available for a metadata, batch query, or Cited-by query submission. Notification is provided in the form of a HTTP(S) URL where the log can be retrieved. If the notification callback service is enabled, you will no longer receive submission log emails.
How the notification callback service works
The callback will be an HTTP(S) request to a URL (notify-url) provided by the member with all data relayed via HTTPS headers. The notification specifies the availability of the result, some context of the request, and an HTTP(S) URL from which to get the result. The submission log may then be retrieved using the HTTP(S) URL.
The headers use the simple name and value structure; that is, the value has no additional structure that divides it into parts. To ensure that all Unicode values can be accommodated all header values will be UTF-8 encoded.
When the notify-url is used the following HTTPS headers are provided:
CROSSREF-NOTIFY-ENDPOINT: the notify-endpoint (required) is just the name used to identify the specific notification (more on this below)
CROSSREF-EXTERNAL-ID: the id given by the member with regards to the request. For metadata deposits, for example, it is the value of the doi_batch_id element (Optional)
CROSSREF-INTERNAL-ID: the id given by us with regards to the request (Optional)
CROSSREF-RETRIEVE-URL: the URL for the member to use to retrieve the request’s result. Since the HTTPS header value is UTF-8 encoded, the URL will contain no URI encodings. For example, an Á will not be encoded as %C3%81
CROSSREF-SERVICE-DATE: the date and time stamp of the service request. Learn more about format specification in RFC 2616.
CROSSREF-RETRIEVE-URL-EXPIRATION-DATE: the timestamp after which service result is no longer available at the given retrieve-url.
Setting up an endpoint
You’ll need to set up and register an endpoint to receive callbacks.
your endpoint info (notify-endpoint and notify-url) – the notify-endpoint is just a name to identify the specific notification. The notify-endpoint should be something you can recognize so when you receive responses that include the endpoint name, it is easy to know which of the callback feeds it is coming from. Thenotify-url has to be the actual URL of your callback receiver, as that is where the notification callback transmits to via http/https
the services you’re activating the service for (metadata submissions, batch querying, Cited-by alerts)
the username and/or DOI prefix you’ll be using
if configuring the notification callback service for Cited-by alerts, you’ll need to provide us with the email address that was used to set your fl_query alerts
Make sure you inform us of any changes to your endpoint: if a message fails to send we will retry for up to a week after which you will no longer be able to receive it.
Example of a notification
For the submission 1368966558 the notification would be as follows (new lines have been added between header name and header value to improve readability):
The notification callback service can be queried for past callbacks. The query is implemented as an HTTPS service (access control and limits to end-points and time frames TBD).
The query takes 3 criteria, the notify-endpoints, an inclusive from timestamp, and an exclusive until timestamp. All timestamps use the ISO 8061 format YYYY-MM-DD’T’hh:mm:ss’Z, for example, 2014-07-23T14:43:01Z.
The query results in a JSON array of callbacks. For example, querying for the single endpoint “1CFA094C-4876-497E-976B-6A6404652FC2” returns:
A flat structure is used to aid processing the result as a stream. There is no order defined.
The audit item is a record of attempted callbacks. It details the notify-endpoint’s notify-url used at the time of the callback, the timestamp of the callback, and the HTTPS status of the callback. If more than one attempt has been tried then the audit array will contain multiple elements; there is no order defined.
The usr and pwd are your Crossref username and password. The ENDPOINT value is a notify-endpoint or a space separated set of notify-endpoints.
A note on trusting Let’s Encrypt
We use Let’s Encrypt, a global Certificate Authority, to enable secure HTTPS connections. Please ensure your local certificate library is updated to include the letsencrypt root certificate before requesting a notification callback for your account/prefix.
Glossary of notification callback service terms
notify-url: the URL that the member provides and is used to notify them of the availability of a service request’s result. How the URL is provided to us will depend on the service.
notify-endpoint: an opaque token used to select a notify-url. The token will be anonymous and difficult to guess. The notify-endpoint is provided by the member. The notify-endpoint is associated with one notify-url (many notify-endpoints can be associated with the same notify-url).
retrieve-url: the URL that we provides that is used by the member to get the service request result.
notify-payload: the data that specifies what service request this notification is for. This payload will use HTTPS headers so as to be HTTPS method-neutral (such as POST, PUT).
retrieve-payload: the service result. Each service will define its own result content-type (that is very much like what would be sent in email today).
notification-authentication: This is the method of authentication we will use with the notify-url. Credentials are provided by the member.
retrieval-authentication: This is the method of authentication the member will use with the retrieve-url. The account credentials are provided by us.