In 2020 we released our first public data file, something we’ve turned into an annual affair supporting our commitment to the Principles of Open Scholarly Infrastructure (POSI). We’ve just posted the 2022 file, which can now be downloaded via torrent like in years past.
We aim to publish these in the first quarter of each year, though as you may notice, we’re a little behind our intended schedule. The reason for this delay was that we wanted to make critical new metadata fields available, including resource URLs and titles with markup.
Unfortunately, Bryan Vickery has moved onto pastures new. I would like to thank him for his many contributions at Crossref and we all wish him well.
I’m now pleased to announce that Rachael Lammey will be Crossref’s new Director of Product starting on Monday, May 16th.
Rachael’s skills and experience are perfectly suited for this role. She has been at Crossref since 2012 and has deep knowledge and experience of all things Crossref: our mission; our members; our culture; and our services.
Since we announced last September the launch of a new version of iThenticate, a number of you have upgraded and become familiar with iThenticate v2 and its new and improved features which include:
A faster, more user-friendly and responsive interface A preprint exclusion filter, giving users the ability to identify content on preprint servers more easily A new “red flag” feature that signals the detection of hidden text such as text/quotation marks in white font, or suspicious character replacement A private repository available for browser users, allowing them to compare against their previous submissions to identify duplicate submissions within your organisation A content portal, helping users check how much of their own published content has been successfully indexed, self-diagnose and fix the content that has failed to be indexed in iThenticate.
A re-cap We kicked off our Ambassador Program in 2018 after consultation with our members, who told us they wanted greater support and representation in their local regions, time zones, and languages.
We also recognized that our membership has grown and changed dramatically over recent years and that it is likely to continue to do so. We now have over 16,000 members across 140 countries. As we work to understand what’s to come and ensure that we are meeting the needs of such an expansive community, having trusted local contacts we can work closely with is key to ensuring we are more proactive in engaging with new audiences and supporting existing members.
Notification callback is a service you can use to notify you when a submission log 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)
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.
The notification callback service can be queried for past callbacks. The query is implemented as an HTTPSservice.(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.
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.
Page owner: Isaac Farley | Last updated 2022-May-06