2021 on Crossref

Event Data now with added references

Martyn Rittman — Wed, 10 Nov 2021 00:00:00 +0000

Event Data is our service to capture online mentions of Crossref records. We monitor data archives, Wikipedia, social media, blogs, news, and other sources. Our main focus has been on gathering data from external sources, however we know that there is a great deal of Crossref metadata that can be made available as events. Earlier this year we started adding relationship metadata, and over the last few months we have been working on bringing in citations between records.

Our members deposit references alongside other metadata, and we have a lot of them. In fact, we have over 1.2 billion, with hundreds of thousands of new references added each day. While our metadata APIs make it easy to see which works are cited, it is much more difficult to find a list of citations to a specific work. We can make this easier by presenting citations as events in Event Data. Now that the huge majority of our members have responded positively to the Initiative for Open Citations (I4OC) campaign and Crossref’s open-by-default reference policy, the move to make this data available via Event Data is a natural step.

A bumpy ride, but we got there

Adding such a large amount of data means a significant increase in the data coming into Event Data, which has presented some challenges. We’ve known for some time that Event Data is not very stable, but we expected it to cope with the new data coming in. We have mitigated by initially only looking at new data, not trying to immediately back-fill with old references. Unfortunately, even with this limitation it hasn’t been a smooth ride, and our first effort to put references into Event Data uncovered bugs we didn’t know about and we had to walk back the changes. We tried again and found that we were hitting rate limits for our own APIs. This is a sure sign of technical debt: we shouldn’t need to be shifting large amounts of our own data from one place to another, and not at rates that could be putting stress on APIs used by others in the community.

We have managed to work around these problems and I’m pleased to say that we are now adding metadata from reference lists to Event Data. They can be accessed via the Event Data API: https://api-eventdata-crossref-org.pluma.sjfc.edu/v1/events?rows=10&source=crossref&relation-type=references&from-collected-date=2021-10-01

Where to next?

There remains work to be done. We would like to backfill references, and there is also further work to include relationships to objects that have identifiers other than Crossref records (genes, proteins, ArXiv identifiers, and so on). Our work on investigating sources is proceeding and we will be looking to add more next year. While possible, these steps will be costly and time-consuming if we proceed without significant changes to the infrastructure supporting Event Data.

When we started Event Data the volumes of data were much smaller and our infrastructure coped well, but as we’ve said here before, it’s in need of an overhaul. In fact, our recent experience and some other considerations are making us look at some very fundamental changes in how we record events.

We are therefore working on a new data model that will allow events to be stored alongside the rest of our metadata. This work is still in the early stages, but if we are successful it will mean that we won’t need to move data between databases. It will also make it easier to provide access to all of our reference metadata along with other relationships that we’re not currently able to provide, and give us the capacity to add new data sources.

Open references

[EDIT 6th June 2022 - all references are now open by default with the March 2022 board vote to remove any restrictions on reference distribution].

It is worth noting that only open references will be available via Event Data. This covers 88% of works with references at present. Members have the option to deposit references with limited visibility, meaning only Metadata Plus users can access them; or closed visibility, meaning that only the member who owns the cited work can retrieve the citation, via Cited-by.

We encourage our members to make their references open and deposit them as metadata. It makes them usable downstream by thousands of tools that researchers use. Including open references also improves the quality of metadata, and there are reciprocal benefits for the large number of members who openly share their reference data: they contribute to a large, openly available pool of data with many applications that advance research, and drives usage of the content published by our members.

If you are a Crossref member and unsure whether your reference metadata is open or not, check your participation report. This will tell you the percentage of your records with deposited references, and the percentage of those that are open. You can change the reference visibility preference for each DOI prefix that you own by contacting our support team. For guidance on how to deposit references, see our user documentation.

Come and get your grant metadata!

Rachael Lammey — Mon, 08 Nov 2021 00:00:00 +0000

Tl;dr: Metadata for the (currently 26,000) grants that have been registered by our funder members is now available via the REST API. This is quite a milestone in our program to include funding in Crossref infrastructure and a step forward in our mission to connect all.the.things. This post gives you all the queries you might need to satisfy your curiosity and start to see what’s possible with deeper analysis. So have the look and see what useful things you can discover.

How it started

Back in 2017 we posted the outcomes of some discussions with a newly-reformed Funder Advisory Group, plotting Crossref’s path. In 2018, Wellcome described their rationale for supporting the grants effort with the help of Europe PMC, and in 2019 the sub-groups of the Advisory Board put out a call for feedback on the metadata plan as the fee model they created was also approved by our board.

Since late 2019, research funders have been registering metadata and identifiers for their grants with us. We currently have a healthy 26k grants registered with us, via 13 funding organisations. I’d specifically highlight Wellcome for volume (registering via Europe PMC), and the Australian Research Data Commons (ARDC) who was the first funder that included ROR IDs in their grant metadata, really getting the value of connecting all related entities and contributors.

The reasons for registering grants with Crossref? Let’s recap:

Support of open data and information about grants
Streamlined discovery of funded content
Improved analytics and data quality
More complete picture of outputs and impact
Better value from investments in reporting services
Improved timeliness, completeness and accuracy of reporting: save time for researchers
More complete information to support analysis and evaluation without relying on manual data entry

How it’s going

For grant information to be used, it’s key that it is is openly available and disseminated as widely as possible. That work starts with funders registering their grants, and continues with us. Now that we’ve completed the REST API’s Elasticsearch migration, we’re happy to announce that all our grant information is now available via our REST API.

Here’s a snippet of the kind of metadata you can see related to the grants registered with us. This is information related to grant record https://doi-org.pluma.sjfc.edu/10.35802/218300, found using this request (https://api-crossref-org.pluma.sjfc.edu/works/10.35802/218300) which you can use to see the full metadata record:

"publisher": "Wellcome",
"award": "107769",
"DOI": "10.35802/107769",
"type": "grant",
"created": {
"date-parts": [
[
2019,
9,
25
]
],
"date-time": "2019-09-25T07:17:20Z",
"timestamp": 1569395840000
},
"source": "Crossref",
"prefix": "10.35802",
"member": "13928",
"project": [
{
"project-title": [
{
"title": "Initiative to Develop African Research Leaders (IDeAL)"
}
],
"project-description": [
{
"description": "Research is key in tackling the heath challenges that Africa faces. In KWTRP we have been committed to building sustainable capacity alongside an active and diverse research programme covering social science, health services research, epidemiology, laboratory science including molecular biology and bioinformatics. Our strategy has been successful in delivering high quality PhD training, leveraging individual funding and programme funding in order to place students in productive groups and provide high quality supervision and mentorship. Here we plan to consolidate and build on these outputs to address long-term sustainability. We will emphasise the full career path needed to generate research leaders. KWTRP aims to address capacity building for research through an initiative that employs a progressive and long term outlook in the development of local research leadership. The overall aim of the \"Initiative to Develop African Research Leaders\" (IDeAL) is to build a critical mass of African researchers who are technically proficient as scientists and well-equipped to independently lead science at international level, able to engage with funders, policy makers and governments, and to act as supervisors and mentors for the next generation of researchers.",
"language": "en"
},

If you dig in, you can see information about the project, investigators (including their ORCID iDs), the funder, award type, amount, description of the grant, and a link to the public page showing information about the grant. More information on the required and optional fields is available in our grants markup guide.

Here are some examples of the kind of things you can now ask:

And bibliographic queries finding entries in…

Award number:

https://api-crossref-org.pluma.sjfc.edu/works?query.bibliographic=7196&filter=type:grant

Project title:

https://api-crossref-org.pluma.sjfc.edu/works?query.bibliographic=RIZ1&filter=type:grant

More to do

This is a milestone but it’s not the end of the story. We have more to add relationships, encourage the use of this metadata amongst publishers and their platforms, and to add grant records to our tools such as Participation Reports and Metadata Search. But in the meantime, feel free to get in touch if you have queries about registering grants with us or about using the related metadata in your tools and services.

This information will grow over time as more funders join Crossref and add their grant metadata and as more analyses is possible. We’re looking forward to the next steps!

Update on the outage of October 6, 2021

Geoffrey Bilder — Wed, 27 Oct 2021 00:00:00 +0000

In my blog post on October 6th, I promised an update on what caused the outage and what we are doing to avoid it happening again. This is that update.

Crossref hosts its services in a hybrid environment. Our original services are all hosted in a data center in Massachusetts, but we host new services with a cloud provider. We also have a few R&D systems hosted with Hetzner.

We know an organisation our size has no business running its own data center, and we have been slowly moving services out of the data center and into the cloud.

For example, over the past nine months, we have moved our authentication service and our REST APIs to the cloud.

And, we are working on moving the other existing services too. For example, we are in the midst of moving Event Data and, our next target, after Event Data, is the content registration system.

All new services are deployed to the cloud by default.

While moving services out of the data center, we have also been trying to shore up the data center to ensure it continues to function during the transition. One of the weaknesses we identified in the data center was that the same provider managed both our primary network connection and our backup connection (albeit- on entirely different physical networks). We understood that we really needed a separate provider to ensure adequate redundancy, and we had already had a third network drop installed from a different provider. But, unfortunately, it had not yet been activated and connected.

Meanwhile, our original network provider for the first two connections informed us months ago that they would be doing some major work on our backup connection. However, they assured us that it would not affect the primary connection- something we confirmed with them repeatedly since we knew our replacement backup connection was not yet active.

But, the change our provider made did affect both the backup (as intended) and the primary (not intended). They were as surprised as we were, which kind of underscores why we want two separate providers as well as two separate network connections.

So both our primary and secondary networks went down while we had not yet activated our replacement secondary network.

Also, our only local infrastructure team member was in surgery at the time (He is fine. It was routine. Thanks for asking).

This meant we had to send a local developer to the data center, but the data center’s authentication process had changed since the last time said developer had visited (pre-pandemic). So, yeah, it took us a long time to even get into the data center.

By then, our infrastructure team member was out of surgery and on the phone with our network provider, who realized their mistake and reverted everything. This whole process (getting network connectivity restored, not the surgery) took almost two hours.

Unfortunately, the outage didn’t just affect services hosted in the data center. It also affected our cloud-hosted systems. This is because all of our requests were still routed to the data center first, after which those destined for the cloud were split out and redirected. This routing made sense when the bulk of our requests were for services hosted in the data center. But, within the past month, that calculus had shifted. Most of our requests now are for cloud-based services. We were scheduled to switch to routing traffic through our cloud provider first, and had this been in place, many of our services would have continued running during the data center outage.

It is very tempting to stop this explanation here and leave people with the impression that:

The root cause of the outage was the unpredicted interaction between the maintenance on our backup line and the functionality of our primary line;
Our slowness to respond was exclusively down to one of the two members of our infrastructure staff being (cough) indisposed at the time.

But the whole event uncovered several other issues as well.

Namely:

Even if one of our three lines had stayed active, the routers in the data center would not have cut over to the redundant working system because we had misconfigured them and we had not tested them;
We did not keep current documentation on the changing security processes for accessing the data center;
Our alerting system does not support the kind of escalation logic, and coverage-scheduling that would have allowed us to automatically detect when our primary data center administrator didn’t respond (being in surgery and all) and redirect alerts and warnings to secondary responders; and
We need to accelerate our move out of the data center.

What are we doing to address these issues?

Completing the installation of the backup connection with a second provider;
Scheduling a test of our router’s cutover processes where we will actually pull the plug on our primary connection to ensure that failover is working as intended. We will give users ample warning before conducting this test;
Revising our emergency contact procedures and updating our documentation for navigating our data center’s security process;
Replacing our alerting system with one that gives us better control over escalation rules; and
Adding a third FTE to the infrastructure team to help us accelerate our move to the cloud and to implement infrastructure management best practices.

October 6th, 2021, was a bad day. But we’ve learned from it. So if we have a bad day in the future, it will at least be different.

More new faces at Crossref

Lindsay Russell — Thu, 21 Oct 2021 00:00:00 +0000

Looking at the road ahead, we’ve set some ambitious goals for ourselves and continue to see new members join from around the world, now numbering 16,000. To help achieve all that we plan in the years to come, we’ve grown our teams quite a bit over the last couple of years, and we are happy to welcome Carlos, Evans, Fabienne, Mike, Panos, and Patrick.

Our Software Development team has seen the most growth with the addition of Carlos, Mike, Panos, and Patrick; collectively, they bring specialist skills that are helping us to pay down technical debt, modernize our underlying infrastructure, and prepare for a consistent front-end experience. As a member of the Product team, Fabienne has a fresh take on our Similarity Check service, steering the upgrade to iThenticate v2. And Evans brings a scientific researcher perspective to our Member Experience team along with experience as a member who’s worked with our tools.

And now some words from each of them.

Carlos Del Ojo Elias

I am a computer scientist with a master’s degree in Bioinformatics. Previously I used to work as a security auditor. I’ve got experience in research and software development both in academia and industry. It’s very exciting for me to join Crossref as a Senior software developer on the technology team. My current project involves working on the authentication and authorization subsystems, exploring state-of-the-art technologies in order to improve our services. I have always enjoyed contributing to the open-source community, so it is a pleasure for me to work in an organisation that promotes the principles of openness and transparency of software and data.

Evans Atoni

I am a member of the Technical Support team having joined Crossref just a few weeks ago. I’m passionate about advancing open access and POSI. Helping our members sort through knotty technical queries and building relations with them to service their very diverse needs is what I’m most excited about in my role. In my spare time, I enjoy anything outdoors, family time, and traveling. I work remotely from Nairobi, Kenya.

Fabienne Michaud

I joined Crossref in April 2021 as a Product Manager for scholarly stewardship which includes the content comparison tool Similarity Check and I am thrilled to be a member of such a lovely, supportive and international team. I have a background in teaching and have worked in academic, research, and not-for-profit libraries in the UK for over 20 years in academic liaison, customer services, and management roles. These experiences have given me a user-centered approach and a drive to find collaborative, reliable, and pertinent technological solutions to support the research and scholarly community. Since starting at Crossref and, through my work with the Similarity Check Advisory Group, I have developed a good understanding of the current ethical issues facing the publishing sector (such as paper mills and other manipulations of the publication process) and a particular interest in how AI and automation tools can play a part in addressing these challenges.

Mike Gill

I’ve been a software developer for twenty years, having studied software engineering at university. During my career, I have worked mostly in the banking and engineering industries so this is my first time working in scholarly publishing. I confess that before joining Crossref I wasn’t aware that the community existed so I was excited to see how I could ply my trade in this new (to me!) field. The role also appealed as, having primarily been a team leader/line manager in my recent career, this was an opportunity to be hands-on again and work with modern languages such as Kotlin. In the end, though, what really sealed it for me was reading on the Crossref website that ‘we take the work seriously but not necessarily ourselves’ which basically sums me up. So I knew I’d be in good company and that has proven to be the case!

Panos Pandis

I joined Crossref as a Senior Software Developer in 2020, in the middle of the coronavirus pandemic. Moving to Crossref has been a much-needed breath of fresh air. I’m a big fan of open-source, and at Crossref, it just feels like home. Even more so after our recent commitment to the Principles of Open Scholarly Infrastructure (POSI). My main focus at the moment is Crossref’s Event Data service. I’m fascinated by the potential of Event Data and the broad audience I get to support and communicate with through the project. So if you spot me in a room, feel free to ask me anything about Clojure/Kotlin, Event Data, obscure technology, or kombucha recipes.

Patrick Vale

I’m delighted to have joined Crossref as the first Frontend Developer. My role covers the inauguration of a scalable framework in which we can build future User Interfaces, and generally making people’s lives easier as they interact with our products and services - if a human uses it, I’m interested! It’s my intention to provide a platform on which we can quickly iterate to build and adapt our interfaces to suit the rapidly changing needs of our community. It’s been a pleasure to learn about the impact Crossref has across the scholarly spectrum; and to work with a team of open, practical, and downright friendly colleagues is a privilege. Outside of work, I enjoy cycling, growing things, and most recently, avoiding two small cats while moving from anywhere to anywhere around the house.

Your contributions have been impactful and it will be fun to see all that you will surely contribute to our road ahead!

Outage of October 6, 2021

Geoffrey Bilder — Wed, 06 Oct 2021 00:00:00 +0000

On October 6 at ~14:00 UTC, our data centre outside of Boston, MA went down. This affected most of our network services- even ones not hosted in the data centre. The problem was that both of our primary and backup network connections went down at the same time. We’re not sure why yet. We are consulting with our network provider. It took us 2 hours to get our systems back online.

We are going to reprocess content that was in the process of being registered at the time of the outage in order to make sure everything gets registered correctly. This may take a few days to complete.

Why did we have such a complete outage and why did it take us so long to fix it?

We still run a significant amount of our infrastructure in a data centre outside of Boston that we manage ourselves. Even though we’ve been moving many of our services to the cloud, all our traffic was still routed through the data centre - so when it went down, most of our cloud services were unavailable as well.
It took us a long time to fix this because our infrastructure team only has two people in it. Only one of them is located near the data centre and was at the doctor’s when the outage occurred. Although we were alerted to the problem immediately, we had to send one of our development team members to the data centre to diagnose and fix the problem.

We have been aware of these weaknesses in our system since I took the role of director of technology in 2019, and we have been putting most of our efforts over the past two years into fixing them.

We know that an organisation of our size has no business trying to run and maintain a physical data centre ourselves. One of the strengths of cloud-based systems is that they can be administered from anywhere and don’t require anyone to physically go to a data centre to replace failed hardware or check that network connections are, in fact, live. We’ve been trying to move to the cloud as fast as we can. All new services that we build are cloud-based. At the same time we’ve been moving systems out of the data centre - starting with those that put the biggest load on our systems. To further aid this process we have budgeted to add an FTE to the infrastructure team in 2022.

What is really painful about this event is that we had just completed the last bit of work we needed to do before changing our traffic routing so that it would hit the cloud first instead of the data centre first. This would not have avoided the outage we just experienced, but it would have made it a bit less severe.

What is even more painful is that we had recently installed a third network connection with an entirely different provider because we were worried about just this kind of situation. But this third connection wasn’t yet active.

We already have a long list of tickets that we’ve created to address problems we faced in recovering from this outage. The list will undoubtedly grow as we complete a postmortem over the next few days. I will report back when we have more detail of what happened and have a solid plan for how to avoid anything similar in the future.

We know that an outage of this severity and duration has caused a lot of people who depend on our services extra work and anxiety. For this, we apologise profusely.

But at least we didn’t need to use an angle grinder.

2021 Board Election

Lucy Ofiesh — Tue, 28 Sep 2021 00:00:00 +0000

We are pleased to share the 2021 board election slate. Crossref’s Nominating Committee received over 60 submissions from members worldwide to fill five open board seats. It was a fantastic group of applicants and showed the strength of our membership community.

There are five seats open for election (three small, two large), and the Nominating Committee presents the following slate.

The 2021 slate

Candidate organisations, in alphabetical order, for the Small category (three seats available):

California Digital Library, University of California, Lisa Schiff
Center for Open Science, Nici Pfeiffer
Melanoma Research Alliance, Kristen Mueller
Morressier, Sebastian Rose
NISC, Mike Schramm

Candidate organisations, in alphabetical order, for the Large category (two seats available):

AIP Publishing (AIP), Penelope Lewis
American Psychological Association (APA), Jasper Simons
Association for Computing Machinery (ACM), Scott Delman

Here are the candidates’ organisational and personal statements

You can be part of this important process by voting in the election

If your organisation is a voting member in good standing of Crossref as of September 20, 2021, you are eligible to vote when voting opens on September 29, 2021.

How can you vote?

On September 29, 2021, your organisation’s designated voting contact will receive an email with the Formal Notice of Meeting and Proxy Form with concise instructions on how to vote. You will also receive a user name and password with a link to our voting platform.

The election results will be announced at the LIVE21 online meeting on November 9, 2021. Save the date!

Similarity Check news: iThenticate v2.0 ready for launch

Fabienne Michaud — Mon, 20 Sep 2021 00:00:00 +0000

Crossref Similarity Check news: iThenticate v2.0 ready for launch

Last year, we announced the upcoming launch of a new version of iThenticate, the product from Turnitin that powers Crossref Similarity Check. We know some of you have been waiting a long time for this upgrade and we are very happy to share with you that we are now ready to release it.

We will be rolling out this new version in stages, so not everyone will be able to upgrade to the new version immediately. We’ll start with new Crossref Similarity Check subscribers who use iThenticate in the browser, and one member who uses iThenticate via the eJournalPress API integration.

Next month, we will reach out to existing Crossref Similarity Check subscribers who use iThenticate in the browser (rather than through a manuscript tracking system), and further eJournalPress users. From then on, we’ll be contacting those of you who use Similarity Check through your manuscript tracking system, as and when your providers are ready to work with the new version.

Crossref Similarity Check - first things first

Crossref Similarity Check is a content comparison tool, powered by iThenticate and produced by Turnitin, to check the originality of scholarly works and detect potential cases of plagiarism. Crossref members are eligible for this service, which offers them a reduced rate for document checking (plus enhanced functionality) in exchange for making their own published content available to be indexed into the iThenticate database.

The Crossref Similarity Check service continues to grow in membership (1,531 members in 2020; 1,964 members in 2021, to date) and in the number of documents checked (1,922,621 manuscripts checked between January and July 2020 and 2,419,612 over the same period this year).

Just as with the current version of iThenticate, Crossref Similarity Check subscribers will be able to compare documents against a vast database of internet sources and over 78 million full-text documents contributed by the Crossref members that use the service:

Crossref - research articles, books, and conference proceedings provided by publishers of scholarly content all over the world
Crossref posted content - preprints, eprints, working papers, reports, dissertations, and many other types of content that has not been formally published but has been registered with Crossref
Internet - a database of archived and live publicly-available web pages, including billions of pages of existing content, and with tens of thousands of new pages added each day
Publications - third-party periodical, journal, and publication content including many major professional journals, periodicals, and business publications from sources other than Crossref Similarity Check members
Your Indexed Documents - other documents you have uploaded for checking (within your Crossref Similarity Check user account only, and not added to iThenticate’s main indexes)

What’s new

We are delighted to introduce the following new features and enhancements with iThenticate v2.0:

Increased document upload capacity
Suspicious and hidden character detection
Preprint exclusion filter
Refreshed and responsive interface
Similarity reports - save and share
Annotations
Content portal
Improved API

Increased document upload capacity

This new version of iThenticate has an increased document upload capacity of up to 800 pages/200 MB and a Google Drive document upload functionality. Please note that per-document fees allow for a maximum of 25,000 25,000 ~~characters~~ (EDIT 21/11/4: words), as one billable unit (25,001-50,000 25,000 ~~characters~~ (EDIT 21/11/4: words) is two billing units, and so on).

Suspicious or hidden character detection

A new ‘Red flag’ feature, highlighted at the top right hand side of the Similarity report and with in-line markers, signals the detection of hidden text such as text/quotation marks in white font or suspicious character replacement e.g., the substitution of a Latin e for a Cyrillic е or a Latin o for a Greek ο, which may have been deliberately added to avoid text-matching detection.

Red flag feature: Hidden characters in the iThenticate v2.0 Similarity report

Preprint exclusion filter

Increasingly, authors are making available a preprint of their article, either before or at the same time as submitting it to a journal. With Turnitin, we have therefore developed a new exclusion filter for ‘Preprint Sources’, which can be applied directly from your Similarity report.

Refreshed and responsive interface

The new iThenticate has a cleaner, more intuitive and accessible interface, with responsive design for ease of use on different screen sizes. The Similarity report is no longer a static image but a text that can be searched, copied and pasted. The display of matches has been improved and simplified with two views only: ‘Sources overview’ and ‘All sources’.

Similarity report in iThenticate v2.0

You can now save Similarity reports as a PDF file and share them via email through the iThenticate interface with authors. Please note: this is still work in progress and enhancements to this feature will be released in the coming months.

Annotations

Annotations in Similarity reports is a brand new feature available in private mode only (in shared folders) in this initial release. Annotations will display the date, time and comments and can be edited or deleted as required. These private annotations will not be included in the ‘save and share’ features mentioned above. Public, shareable, annotations will be included in a future release.

Private annotations in the new Similarity report

Content portal

The new ‘Content portal’ is a useful tool to check how much of your own published content has been successfully indexed into the iThenticate database and is now searchable. It will also help you self-diagnose and fix the content that has failed to be indexed.

Improved API for subscribers who integrate Similarity Check with their manuscript tracking system

API users will benefit from a new integration with manuscript tracking systems which will allow the display of the largest matching word count and the top 5 source matches alongside the Similarity score.

What’s next

We’re expecting a number of new features and enhancements to iThenticate version 2.0 as well as further manuscript tracking system API integrations in the coming months:

User/usage reporting functionality
Editorial Manager API integration
Further enhancements to the Similarity report user interface
Parent/child account management reporting, to assist Crossref Sponsors
Public vs. private annotations
Document resubmission flow
Customisable welcome email

We’ll keep you posted

We will post updates here as soon as new features, enhancements and API integrations are available and/or we are ready to upgrade the next group of members.

We’ll be contacting subscribers in stages to upgrade you to the new version, so keep your eyes open for an email from us. As you know, you have to supply full-text Similarity Check URLs in your Crossref metadata for over 90% of your own published content in order to be eligible for the service. We’ll be checking that anyone who wants to upgrade to v2.0 is still at 90% or above. You can check this yourself in advance on our eligibility checker - if you’ve fallen below 90%, the tool will give you instructions for adding your missing full-text Similarity Check URLs.

In the meantime, you will find the Similarity Check service documentation for the current version of iThenticate on our website. The documentation for the new version can be found on the Crossref Similarity Check site provided by Turnitin.

✏️ Do get in touch via support@crossref.org if you have any questions or suggestions or start a discussion on our Community Forum

Lesson learned, the hard way: Let’s not do that again!

Isaac Farley — Wed, 08 Sep 2021 00:00:00 +0000

TL;DR

We missed an error that led to resource resolution URLs of some 500,000+ records to be incorrectly updated. We have reverted the incorrect resolution URLs affected by this problem. And, we’re putting in place checks and changes in our processes to ensure this does not happen again.

How we got here

Our technical support team was contacted in late June by Wiley about updating resolution URLs for their content. It’s a common request of our technical support team, one meant to make the URL update process more efficient, but this was a particularly large request. Shortly thereafter, we were provided with nearly 1,200 separate files by Atypon on behalf of Wiley in order to update the resolution URLs of ~9 million records. We manually spot checked over 50 of these files, because, prior to this issue, our technical support team did not have a mechanism to automatically check for errors. That labor intensive review did not turn up any problems. That is, those 50 samples had no errors with the headers, like were found later.

Among the files we didn’t check, there were headers included in the files with different owning fromPrefix and acquiring toPrefix members’ DOI prefixes. In a URL update request, the prefixes should always be the same.

And still other files included requests to update records with DOIs that had never even been registered. Here are some examples:

_{H:email=support@crossref.org;fromPrefix=10.5555;toPrefix=10.5555

10.5555/doi1 http://www.newurl.com/whatever

10.5555/doi2 http://www.newurl.com/whatever2}

In the example above, these fictional DOIs are both under prefix 10.5555. Thus, the result of this request will ONLY be that the resolution URLs of DOI 10.5555/doi1 and 10.5555/doi2 are updated in the metadata.

_{H:email=support@crossref.org;fromPrefix=10.5555;toPrefix=10.9876

10.5555/doi1 http://www.newurl.com/whatever

10.5555/doi2 http://www.newurl.com/whatever2}

In this second example, these fictional DOIs are both under prefix 10.5555, but because the toPrefix in the header differs from the fromPrefix, the result of this request will be that the resolution URLs of 10.5555/doi1 and 10.5555/doi2 are updated in the metadata AND the owning prefix of both records will be transferred from prefix 10.5555 to prefix 10.9876.

We kicked off the URL update request on 30 June and all legitimate DOIs whose files were free of errors were updated by 7 July (yes, it takes about a week to update the resolution URLs for ~9 million records).

On 9 July, Peter Strickland of the International Union of Crystallography, one of 22 members affected by this mistake, contacted us to enquire how/why much of their content was resolving to incorrect URLs and why ownership of their content appeared within our search interface to be Wiley. Peter was rightly concerned. We were, too. Our technical support team quickly elevated this issue, because, frankly, this is not the first time our finicky URL update process has caused unwanted metadata updates, albeit not quite at this volume.

How we investigated the problem

We rallied our internal team. We investigated and discovered that we believed that some ~600,000 DOIs were erroneously included and updated in the requested 1,200 files. We later extended that estimate to include other conditions, in order to be as cautious as we could, to over 1 million DOIs. In the end, we determined that the incorrect files attempted updates of 1,228,041 DOIs. Due to the errors in the files (i.e., erroneous headers and non-registered DOIs), we only actually updated and then reverted 520,512 DOIs. The other 700,000+ DOIs were never updated (because of errors in the original files provided to us) or simply had never been registered with us.

Prior to this mistake, Crossref had never reverted a member’s metadata update before. To be clear, and as I said above, we have had other URL update mistakes over the years, like this one; they were just smaller in scale. We knew there were holes in our process that needed to be plugged. And we knew we needed a better solution for members to manage these updates themselves without our manual intervention. So, while there were mistakes made in the files supplied to us, this was our error and we’re fixing it; more on that below.

For this situation, we quickly realized that reversion of the metadata update was the best option for us, albeit we did not have an existing process in place to execute that reversion. That’s because we only keep the current version of each metadata record. We couldn’t back out of the change; we couldn’t simply restore these records to the metadata registered with us as of late June, because we no longer had an easily accessible, central record of those previous resolution URLs. What we did have was a record of all the previous submissions made against each DOI, so our technical team, focused their efforts there.

How we fixed all those records

We had two errors to correct: the ownership transfers (those records that had inadvertent and mismatched from/to prefixes) and the incorrect resolution URLs. We reverted all of the ownership transfers on 9 July and then double and triple checked that ownership during the week of 12 July to ensure we didn’t miss anything.

The resolution reversion was more complicated. We invested in creating a patch to identify the records that had been updated by our team, and then extract the last legitimate resolution URL registered with us by the owning member in order to revert the metadata for each record. In order to provide confidence that this mistake was contained, we also built a check into the patch to ensure that those DOIs that did have their ownership temporarily transferred were not updated during the few days that ownership was incorrect. That check helped us determine that none of the 520,512 DOIs were incorrectly updated beyond this mistaken URL update request.

The technical team built and tested this patch. The tests turned up gaps in the patch, so we refined it during the week of 2021 July 12. We kicked off the reversion of these records on Monday, 19 July at 20:05 UTC and the patch completed all reversions at 20:14 UTC, Thursday, 22 July.

In the end, we successfully reverted all of the resolution URLs for those 520,512 DOIs we identified; provided daily updates and apologies to the 22 affected members; together we worked some longer hours; and persevered.

Ed updates everyone internally on the situation and thanks all the people who worked together to resolve the issue

Next up

We don’t want this to ever happen again. Like, never. We clearly need to make changes to our internal processes to prevent this in the future.

Here’s what’s ahead:

We are building a checker that we can run URL update files through to automate and our checks. This means we will be able to check every single file in a large batch, rather than relying on manual and labor intensive spot-checking;
As said above, one compounding issue in this mistake was the mismatched from/to prefixes in the file headers. Our technical support team uses the same file headers to transfer ownership/stewardship of a record or set of records between members AND to update resolution URLs. These two tasks are almost never legitimately completed in the same file. That is, there is usually a lag between ownership transfers and resolution URL updates (most members will request an ownership transfer and then a month or two later update their URLs). Because of this, simply decoupling these two tasks (feel free to follow our work at this link) would help eliminate a glaring risk, so we’re working on that too;
Lastly, we’re researching ways we can streamline resource resolution URL updates. You can also monitor our progress on this one. No promises or specifics yet, but we’re eager to reduce toil on our technical support team, avoid problems like this one, and provide members safe and straightforward ways to better update your metadata.

Thanks for the support of the whole Crossref team and our community - and for reading this far! Never a dull moment…

Crossref Conversations: audio blog about helping open science

Rosa Morais Clark — Fri, 20 Aug 2021 00:00:00 +0000

Crossref Conversations is an audio blog we’re trying out that will cover various topics important to our community. This conversation is between colleagues Anna Tolwinska and Rosa Morais Clark, discussing how we can make research happen faster, with fewer hurdles, and how Crossref can help. Our members have been asking us how Crossref can support open science, and we have a few insights to share. So we invite you to have a listen.

[UPDATE: Since this recording ROR IDs are now part of the Crossref schema.]

Helpful links

Here are links to all the sources mentioned in the recording.

Thanks for listening!

Some rip-RORing news for affiliation metadata

Ginny Hendricks — Mon, 26 Jul 2021 00:00:00 +0000

We’ve just added to our input schema the ability to include affiliation information using ROR identifiers. Members who register content using XML can now include ROR IDs, and we’ll add the capability to our manual content registration form, participation reports, and metadata retrieval APIs in the near future. And we are inviting members to a Crossref/ROR webinar on 29th September at 3pm UTC.

The background

We’ve been working on the Research Organization Registry (ROR) as a community initiative for the last few years. Along with the California Digital Library and DataCite, our staff has been involved in setting the strategy, planning governance and sustainability, developing technical infrastructure, hiring/loaning staff, and engaging with people in person and online. In our view, it’s the best current model of a collaborative initiative between like-minded open scholarly infrastructure (OSI) organisations.

Last year, Project Manager Maria Gould described the case for publishers adopting ROR and ROR was ranked the number one priority at our last in-person annual meeting. Now it’s time that Crossref’s services themselves took up the baton to meet the growing demand.

The inclusion of ROR in the Crossref metadata will help everyone in the scholarly ecosystem make critical connections more easily. For example, research institutions need to monitor and measure their output by the articles and other resources their researchers have produced. Journals need to know with which institutions authors are affiliated to determine eligibility for institutionally sponsored publishing agreements. Funders need to be able to discover and track the research and researchers they have supported. Academic librarians need to easily find all of the publications associated with their campus.

Earlier this month, GRID and ROR announced that after working together to seed the community-run Research Organization Registry, GRID would be retiring from public service and handing the proverbial torch over to ROR as the scholarly community’s reliable universal open identifier for affiliations. That means that our members who have been using GRID now need to consider their move to ROR and think about how they can add ROR IDs into the metadata that they manage and share through Crossref.

The plan

We’ve been able to include ROR IDs for our grant metadata schema as affiliation information for two years, since July 2019. And the Australia Research Data Commons (ARDC) was the first member to add ROR IDs to the Crossref system in 2020. In early July, we completed the work to accept ROR IDs for affiliation assertions for all other types of records with an affiliation or institution element, such as journal articles, book chapters, preprints, datasets, dissertations, and many more.

Next, we will commence the plans to support ROR in our other tools and services, such as Participation Reports. We’ll work on alignment with the Open Funder Registry and share our plans to collect the information via the new user interface we’re developing for registering and managing metadata. Open Journal Systems (OJS) already has a ROR Plugin, developed by the German National Library of Science and Technology (TIB). This supports the collection of ROR IDs and future releases of this plugin and the OJS DOI plugin will allow including ROR IDs in the metadata sent to Crossref, to support thousands of our members to share ROR IDs via their Crossref metadata. We also aim to add ROR to our metadata retrieval options, including the REST API, which recently saw the start of an unblocking with our move to a more robust technical foundation.

The call for participation

Many Crossref publishers, funders, and service providers are already planning to integrate ROR with their systems, map their affiliation data to ROR, and include ROR in Crossref metadata. In addition to publishers and funders, libraries, repositories, and other stakeholders are developing support for ROR. For example, the Plan S Journal Checker tool uses ROR IDs to let people check whether a particular journal is compliant with an author’s funder and institutional open access policies. In addition, the ROR website shows a growing list of active and in-progress ROR integrations.

Crossref members registering research grants via Altum’s ProposalCentral system can already add ROR IDs. Now those registering articles, books, preprints, datasets, dissertations, and other research objects, can start including much clearer and all-important affiliation metadata as part of their content registration going forward. As with all newly-introduced metadata elements, we recommend adding ROR IDs from now and ongoing, but planning a distinct project to backfill older records. We know that more than 80% of records have been updated and enriched at least once with additional and cleaner metadata, so as members do this routinely, they can include ROR IDs alongside updating URLs, license or funding information, and other metadata.

For information on how ROR will be supported in the Crossref metadata, take a look at our latest schema release (version 5.3.0) or in this journal article example XML.

Join the discussion in our forum below and register for the Crossref/ROR webinar on September 29th at 3pm UTC to learn all you need to know about incorporating ROR into your Crossref metadata.

Behind the scenes improvements to the REST API

Patrick Polischuk — Tue, 06 Jul 2021 00:00:00 +0000

UPDATE, 24 August 2021: All pools have been migrated to the new Elasticsearch-backed API, which already appears to be more stable and performant than the outgoing Solr API. Please report any issues via our Crossref issue repository in Gitlab.

UPDATE, 9 August 2021: The cutovers for the polite and Plus pools are delayed again. We’re still working to ensure acceptable performance and stability before serving responses from the new application and infrastructure. Each cutover is currently delayed by one more week–the polite pool is scheduled for 2021 August 17 and the Plus pool is scheduled for 2021 August 24.

UPDATE, 2 August 2021: The cutovers for the polite and Plus pools are delayed. We’ve been mirroring traffic to the new polite pool and want to ensure acceptable performance and stability before serving responses from the new application and infrastructure. Each cutover is currently delayed by one week–the polite pool is scheduled for 2021 August 10 and the Plus pool is scheduled for 2021 August 17.

UPDATE, 13 July 2021: The first stage of the cutover is complete, so requests to the public pool are now being served by the new REST API. We took a slightly different approach to performing the cutover, so the “Documentation” and “Temporary domain” sections below have been updated.

Our REST API is the primary interface for anybody to fetch the metadata of content registered with us, and we’ve been working hard on a more robust REST API service that’s about to go live.

The REST API is free to use and it gets around 300 million requests each month (we encourage users to adhere to our etiquette guidelines to keep things running smoothly). It is used for bibliometric studies, by platforms like Dimensions, by organisations like the National Library of Sweden, and to support countless other efforts.

We also offer enhanced access to our APIs and other services with Metadata Plus, and we recommend it for production services and others that benefit from guaranteed up-time, a higher rate limit, and priority support from our helpful staff.

For a while now, we’ve been working to migrate the REST API from Solr to Elasticsearch and from our datacenter to a cloud platform in order to address issues of scalability and extensibility.

We’re pleased to announce that we’ll be cutting over to the Elasticsearch-backed version of the REST API over the next few weeks, beginning July 13. This cutover will occur one pool at a time–the public pool will be migrated first, followed by the polite pool on August 3, and the Plus pool on August 10 (see ’etiquette’ link above if you’re unfamiliar with our different pools). Please note updates at the top of this post for changes to the original schedule.

We’ve thoroughly tested the functionality and performance of the new REST API, and we’d like to invite you to test it out before we move production traffic to the new service. Try out your favorite API queries at https://api-production-crossref-org.pluma.sjfc.edu/.

Feature parity, but note a few differences

One of our primary objectives was to maintain feature parity between the old and new services, avoiding any breaking changes that might cause problems for existing services integrating with the REST API. We implemented a regression test suite which has given us the confidence to make such a foundational change. During the course of this project, we found it necessary and a good opportunity to make a few modifications. In each case, we analyzed usage and aimed to avoid making any breaking changes. We hope these represent improvements to the behavior and consistency of the REST API.

The group-title filter uses exact matching. This filter previously worked but was undocumented and unsupported.
The directory filter is deprecated. This was meant to be an experimental, unsupported filter, and the data has not met the standard we require.
The affiliation facet returns counts of affiliation strings rather than counts of terms within affiliation fields (thus resolving this Github issue).
Cursors may be used to page through results from the /members, /funders, and /journals routes, in addition to /works.
While we suggest that everyone use cursors for pagination, we still support the offset functionality. We have introduced a limit of 80000 for offset values for the /members /funders and /journals routes
offset behavior is slightly changed, now applying to the sum of rows and offsets rather than just offsets.
The published field is now present in API responses.
The /licenses route returns paged results.
Sorting by submitted is no longer supported. This was never officially supported or documented.
The /quality route has been removed. This was an undocumented, experimental feature.
Funder name in /works metadata is the name provided by the publisher.
Empty relation fields correctly return an empty object.
Only ISBN and isbn-type for a record will be returned. ISBNs for associated volumes will be omitted.
The institution field is a list.
query uses different stop word defaults, though we expect querying to remain roughly the same.
API responses may feature slightly different scores, as they come from different backends.

Some technical notes on the cutover

Documentation

The above changes are documented in our new REST API documentation, which is now automatically generated via Swagger, resulting in more comprehensive coverage and more efficient feature development. During the cutover, the right documentation for you will depend on which pool you are using. The documentation for the new API can be found by visiting the API in a browser, or by navigating to https://api-crossref-org.pluma.sjfc.edu/help; and the docs for the old API remain here: https://github.com/CrossRef/rest-api-doc. The Github-hosted documentation will be deprecated once the cutover is complete.

This may not come as news, but bears repeating as we mentioned GitHub. We have moved our source code repositories from GitHub to GitLab, including all of our issue tracking.

Temporary domain

UPDATE: We ended up performing the public pool cutover via reverse proxies instead of redirects–please disregard the note about temporary domains below. The api.crossref.org domain will remain the domain regardless of which pool you’re using or where we are in the cutover process.

Please note that the api.production.crossref.org domain is a temporary domain we are using during this cutover period. Traffic will be redirected to the new service one pool at a time via a 307 http redirect. Once the cutover is complete, we will go back to using the api.crossref.org domain. Do not update any software, scripts, libraries, tools, etc. to use the temporary domain.

Differences in query results

Due to inherent differences in how Solr and Elasticsearch perform queries and rank results, you may see slightly different results when comparing the old and new services. If for whatever reason your workflow involves using multiple API pools (which we don’t recommend), you may see inconsistent results.

Cursor behavior

Cursors may break if your script is paging through results at the exact moment the cutover is performed, and you should retry your request once the release is complete. We will post the precise maintenance window to https://status-crossref-org.pluma.sjfc.edu/.

Filing issues

Feature requests and bug reports should be filed into the Crossref issue repository in Gitlab during this testing phase and once the new Elasticsearch-backed API is live in production.

Coming next

While we hope the benefits of improved stability and extensibility are as exciting to you as they are to us, “feature parity” may not be the most thrilling message for our API users. In truth, one of the more exciting aspects of completing this migration is the end of the code freeze we instituted at the start of this effort. Now, we can work on new feature development and a continuous stream of bug fixes. We also improved the automatic test coverage as part of the work, meaning we can deliver features with greater confidence.

The first new feature we’ll be delivering via the REST API will be support for the “grants” record type, allowing for the retrieval of metadata for grants that have been registered with us, now numbering over 20,000 from 8 different funder members. This work is well underway and will be released once we are confident that the new REST API is stable in production. From there, we’ll continue to select the highest priority issues from our REST API backlog.

As always, should you have any questions about our REST API, check out the metadata retrieval section of our website, start a discussion on our community forum, file a Gitlab issue as mentioned above, or you can contact us via support@crossref.org.

DOAJ and Crossref sign agreement to remove barriers to scholarly publishing for all

Ginny Hendricks — Mon, 21 Jun 2021 00:00:00 +0000

22 June 2021, London, UK and Boston, MA, USA — The future of global open access publishing received a boost today with the signing of a Memorandum of Understanding between the Directory of Open Access Journals (DOAJ) and Crossref. The MOU formalizes an already strong partnership between the two organisations and furthers their shared pursuit of an open scholarly communications ecosystem that is inclusive of emerging publishing communities.

Both organisations aim to encourage the dissemination and use of scholarly research using open infrastructure, online technologies, regional and international networks, and community partners - all supporting local institutional capacity and sustainability around the world.

“DOAJ is delighted to be formalizing today’s agreement with Crossref, an organisation we are already closely aligned with. Together we stand a greater chance of encouraging an open, fair, and fully inclusive future for scholarly publishing,” said Lars Bjørnshauge, DOAJ Founder and Managing Director.

The agreement will enable content from journals indexed on DOAJ to be more easily identified through the use of Crossref metadata. The MOU also covers the exchange of a variety of services and information and greater coordination of technical and strategic requirements between DOAJ and Crossref. Included too is the development of outreach and training materials, coordination of service and feature development, as well as research studies to explore the overlaps and gaps in the journals and metadata covered by each organisation.

“As academic-led journals continue to grow in number and geographic reach, it’s important we support this community more effectively. Our partnership with DOAJ means we can share strategies, data, and resources in order to lower barriers for emerging publishers around the world,” said Ginny Hendricks, Crossref’s Director of Member & Community Outreach.

About DOAJ

DOAJ is a community curated online directory that indexes and provides access to high quality, open access, peer reviewed journals. DOAJ deploys more than one hundred carefully selected volunteers from among the community of library and other academic disciplines to assist in the curation of open access journals. This independent database contains over 15,000 peer-reviewed open access journals covering all areas of science, technology, medicine, social sciences, arts and humanities. DOAJ is financially supported worldwide by libraries, publishers and other like-minded organisations. DOAJ services (including the evaluation of journals) are free for all, and all data provided by DOAJ are harvestable via OAI/PMH and the API. See doaj.org for more information.

About Crossref

Crossref makes research objects easy to find, cite, link, assess, and reuse. We’re a not-for-profit membership organisation that exists to make scholarly communications better. We rally the community; tag and share metadata; run an open infrastructure; play with technology; and make tools and services—all to help put research in context. Visit crossref.org for further information.

Please contact louise@doaj.org or feedback@crossref.org with any questions.

Event Data: Help us fill in the gaps

Martyn Rittman — Fri, 11 Jun 2021 00:00:00 +0000

UPDATE August 2, 2021: This work was awarded to Laura Paglione of the Spherical Cow Group.

To date, we have collected around 740 million events from 12 different source since we launched our Event Data service service in 2017. Each event is an online mention of the research associated with a DOI, either via the DOI directly or using the associated URL. However, we know that there is much more out there. Because of this, we would like to explore where we could expand.

We invite proposals to conduct a gap analysis for Event Data sources, looking at what we currently collect and seeing what more could be added. For the most relevant new sources, we are seeking an estimate of the effort to include them, and establish whether it is possible: we know that there are sources that are paywalled or with restrictive licensing not compatible with Event Data.

The aim of the project is to identify a list of potential new sources. With community input, we will look to add a number of these to Event Data in the future based on needs and priorities.

For full details of the requirements and how to make a proposal, see here. The deadline for proposals is 11 July 2021 and we anticipate that the work will be completed by the end of October 2021.

An Advisory Group for Preprints

Martyn Rittman — Wed, 09 Jun 2021 00:00:00 +0000

We are delighted to announce the formation of a new Advisory Group to support us in improving preprint metadata. Preprints have grown in popularity over the last few years, with increasing focus brought by the need to rapidly disseminate knowledge in the midst of a global pandemic. We have supported metadata deposits for preprints under the record type ‘posted content’ since 2016, and members currently register a total of around 17,000 new preprints metadata records each month.

As preprints develop and different practices arise, we are keen to re-examine the metadata schema: to do this properly we need community input. We want to ensure that the schema is fit for purpose and supports the diversity of ways in which preprints are posted, linked with other objects, and used. Metadata schema need regular review, and this is just one example of a number of areas we are looking to update. Several topics we see as a high priority for preprints are better notification for when a preprint has been withdrawn or removed, accurate recording of versioning, and better indication of preprint server names.

We have invited a number of organisations we know to be active in this area, and are looking forward to some very positive discussions. Participants span five continents and include members who post preprints, indexing services, and others with significant experience in the area of preprints. The first meeting took place earlier this week and brought up a diverse range of themes that will be tackled in future meetings.

Time to put the "R" back in "R&D"

Geoffrey Bilder — Mon, 07 Jun 2021 00:00:00 +0000

It is time to put the ‘R’ back into R&D.

The Crossref R&D team was originally created to focus on the kinds of research projects that have allowed Crossref to make transformational technology changes, launch innovative new services, and engage with entirely new constituencies. Some Illustrious projects that had their origins in the R&D group include:

DOI Content Negotiation
Similarity Check (originally CrossCheck)
ORCID (originally Author DOIs)
Crossmark
The Open Funder Registry
The Crossref REST API
Linked Clinical Trials
Event Data
Grant registration
ROR

And for each project that has graduated, there have been several that have not. Some projects were simply designed to gather data. Others just didn’t generate enough interest. You are not truly experimenting if you don’t fail occasionally too.

Recently we’ve been doing very little experimenting of any kind. Instead, the R&D team has mostly been seconded to the software development team to help them through a period of organisational and process change. We would not have made it through the past two years without their help.

But now we’re ready to focus on more ‘R’ and less ‘D’. And to that end, we are increasing the size of the team as well. Rachael Lammey will be joining the team as Head of Strategic Initiatives. She will work alongside our Principal R&D Developers, Esha Datta and Dominika Tkaczyk. Together they will be able to engage with new communities and immediately start experimenting with ways in which Crossref might be able to address their needs and use-cases.

We hope to soon add to our list of distinguished R&D project alumni.

Rationale & details

The Crossref R&D group (AKA “Labs”) has been the incubator of many services that are now in production and which form a fundamental part of Crossref’s identity and value. Similarity Check, ORCID, Crossmark, Open Funder Registry, The REST API, Linked Clinical Trials, and Event Data all started as R&D projects. More recently the enhancement of our reference matching infrastructure and the development and launch of ROR were also R&D projects.

And prior to the formation of the outreach group in 2015, the R&D group also led a critical function engaging with communities that, at the time, Crossref only had tangential connections with: PKP; DOAJ; funders; and the data and altmetrics communities.

But since the R&D group merged with the technology team back in 2019, we have done very little “R.” and very little community engagement of our own. Instead, the R&D team has supported the development team through a period of major cross-cutting projects and organisational change. Dominika has led the REST API rewrite and Esha—when she is not acting as technical lead on ROR—has also worked on the API rewrite and has kept Crossref metadata search on its feet. We would not have been able to make it through the past few years without their help.

Throughout this period, Rachael Lammey has continued the vital work of identifying, engaging with, and advocating for members of our community who we previously didn’t even know were members of our community.

The strength of the R&D group was that it combined outreach, product, and development functions. It was not only able to engage with new constituencies, but to quickly experiment with ways in which Crossref might be able to serve them. Previously, members of the R&D team would return from a conference or workshop that no Crossref member had ever attended before with a set of new contacts and ideas for new services and tools. They’d form interest groups and develop prototypes. Sometimes the interest groups would lead nowhere and sometimes the prototypes would be discarded. But critically, some of them would turn into the major services and organisations that now form a foundational part of open scholarly infrastructure.

And this is why it makes so much sense for Rachael to join the R&D team. The group is most effective when it is able to engage with new communities and immediately start experimenting with ways in which Crossref might be able to address their needs and use-cases. Rachael’s extensive experience in both product management and outreach—combined with Esha and Dominika’s experience leading development projects—is exactly what we need to reinvigorate the group and put the R back into R&D.

To kick off, we are going to be working on some small-ish, discrete projects. These include:

Better matching and linking of preprints to published articles;
Extending our journal title classification to cover all journal and conference proceedings titles; and
Tools to allow us to community-source structured metadata correction information and feed it back to our members.

We will consult with and update the community on the kinds of projects we are working on through regular tech updates and a revitalised Labs area of our website.

Oh- and we will certainly be designing some new Labs creatures.
–G

The road ahead: our strategy through 2025

Ginny Hendricks — Thu, 03 Jun 2021 00:00:00 +0000

This announcement has been in the works for some time, but everything seems to take longer when there is a pandemic going on, including finding time and headspace to plan out our strategy for the next few years.

Over the last year or so we have had our heads down addressing how to scale our 20-yr-old system and operation – and adapting to new ways of working. But we’ve also spent time talking to people, forging alliances, looking ahead, and making plans. So we’re happy to now let everyone know exactly what we’ve been up to lately, what we are heading towards in 2025, and what projects and programs are prioritised on our near-term agenda.

Tl;dr

Introducing the new Crossref strategy through 2025, extending the one we published in 2018
There are now two additional strategic goals, to make six: bolstering our team; living up to POSI
Good progress has been made in reducing operational and technical debt - a lot of learning too
We’re unblocking stuff to get more done, including expanding R&D (more on that next week)
We have a new public roadmap 🎉
Come to next week’s mid-year update webinar to hear what’s happening and up next.

The emergence of a strategic agenda

2018 seems like a decade ago, doesn’t it? Back then we set out a 2018-2021 strategic direction—now archived—that described four goals: adapt to expanding constituencies; simplify and enrich services; selectively collaborate and partner with others; and improve our metadata quality and comprehensiveness. These themes were formed from the output of a planning exercise with our board in mid-2017 which tackled scenarios that remain true today, including: the increasing diversity in scholarly publishing (library-publishing, academic-led journals, shifting geographic dominance, etc.); the growth in preprints and other content formats; the sustainability of scholarly publishing (who is funding it and whether that is an expanding or shrinking pool); and the increase in policy and regulation in this space.

That meeting was the catalyst for embracing openness and a broader set of constituents. It was also decisive about Crossref’s role in this evolving community to focus on our core competencies, defined as:

A reputation as a trusted, neutral one-stop source of metadata and services

Managing scholarly infrastructure with technical knowledge and innovation

Convening and facilitating scholarly community collaboration.

So you can see how we got to focusing on metadata, services, infrastructure, and broad community collaboration.

Ahh, 2019, such an innocent time

When we wrote our post at the end of 2019 A turning point is a time for reflection we highlighted—with data—how different the Crossref community is nowadays. The post also linked to the results of our ‘value’ research project and a fact file which had even more hard data and posed the question Which Crossref initiatives should be top or bottom priorities?. To answer that, the LIVE19 annual meeting group voted (using betting chips) on priority initiatives, with the following results:

Support and implement ROR
Metadata best practices and principles
Support for multiple languages
Address technical and operational debt
Schema updates such as JATS and CRediT
Engagement with funders

We all know what happened next: the collective health and social trauma of the COVID-19 pandemic. All of us struggled. You all did too. Homeschooling, homeworking, homestaying. Caring for—and even saying goodbye to—sick friends and family. Also beloved colleagues. Alongside these unfamiliar new stresses, members were joining in growing numbers, funders kept joining to register grants, conferences went online and we loved them (before then hating them), the number of records we hosted kept going up, and publishing (especially preprints) skyrocketed.

The plan hasn’t actually changed much. Those charts in the 2019 fact file still make for remarkable reading as those same trends continue. We simply haven’t had time to update people on where we are with plans. So it’s high time we give an update on these priorities as well as contextualise them in longer-term goals.

But first, some framing

The chart below shows the approach we took to organise our thinking. A lot of it isn’t new; we have had the current mission statement, key messages (rally, tag, run, play, make), and truths since the rebranding work in 2015/2016. More recently, we have added POSI to our values, describing the principles and rules by which we operate as a committed open scholarly infrastructure organisation.

We already have a lot of 'words'. So why do we also need a vision statement and where do the goals fit in? In order to prioritize the things we will work on first, we need to be able to track everything to a higher vision, ensuring that everything we do is working toward an agreed destination. When we have organisation-wide goals, it means that everyone is clear on the direction, is able to prioritize individual and team work, and can see how their contribution fits in. This, in turn, instills confidence, and motivation - amongst staff as well as members and users.

Our working vision statement (feedback needed!) is:

We envision a rich and reusable open network of relationships connecting research organisations, people, things, and actions; a scholarly record that the global community can build on forever, for the benefit of society.

A vision is, of course, shared. It isn’t Crossref-specific but describes the world in which we all want to work together in future.

Now for those contextual six goals

Full details are on the new strategy page but here’s a summary below.

This goal is all about people, support, culture, and resilience. Not just because we’re coming through a panedmic, but also because we’re growing and we need to be able to scale and manage growth more purposefully, with appropriate policies, fees, and resources.

We published a POSI self-assessment earlier this year and like-minded initiatives are following suit. This is a stated goal because we want to be held publicly accountable to the Principles of Scholarly Infrastructure standards of governance, insurance, and sustainability.

This goal centres on growth, strengthening relationships, community facilitation, and content. Working with a growing number of Sponsors helps us lower barriers to participation around the world, including in languages other than English. Expanding the support we offer for research funders and institutions are priorities.

This goal involves researching and communicating the value of richer, connected, and reusable, open metadata, and incentivising people to meet best practices, while also making it possible (and easier) to do so.

We’ve always collaborated but we want to work even more closely with like-minded organisations to solve problems together. Perhaps in future we could also partner with others to find operating efficiencies for our overlapping stakeholders.

This goal is all about focus. And about delivering easy-to-use tools that are critically important for our community. A lot of invisible work has been happening behind the scenes; we’ve been strengthening (and will continue to strengthen) our code-base (while opening up all code) in order to unblock some of the initiatives we know people have been waiting for.

Read more about what projects are included in the above goals in our full 2025 strategic agenda.

You’re invited to a mid-year update webinar

Rather than saving everything for our annual—usually November—meeting, we’ll also do a mid-year update and plan to do so in May or June every year from now on, in addition to the November updates which include the board election and governance and budget information.

This year, we’re covering some of the main product development work we have completed, underway, and planned for the next quarter. We’ll run it live twice - once for those nearby The Americas timezones (June 8th 3pm UTC) and once for those nearby Asia Pacific timezones (June 9th 6am UTC). We have a lot to cover in 90 minutes—including unveiling [our public roadmap[(http://bit.ly/crossref-roadmap)]—but we’re going to try really hard to have a few minutes to discuss questions too.

In the meantime, or indeed anytime, join the discussion over on our community forum - see the discussion below and join in on our forum.

We want to be held accountable to these goals so we’re reliant on you, as a community, to let us know what you think of our 2025 strategic agenda. As always; we’re grateful for your support and advice.

Our annual open call for board nominations

Lucy Ofiesh — Thu, 27 May 2021 00:00:00 +0000

Crossref’s Nominating Committee is inviting expressions of interest to join the Board of Directors of Crossref for the term starting in 2022. The committee will gather responses from those interested and create the slate of candidates that our membership will vote on in an election in September. Expressions of interest will be due Friday, June 25th, 2021.

Board roles and responsibilities

The role of the board at Crossref is to provide strategic and financial oversight of the organisation, as well as guidance to the Executive Director and the staff leadership team, with the key responsibilities being:

Setting the strategic direction for the organisation;
Providing financial oversight; and
Approving new policies and services.

The board is representative of our membership base and guides the staff leadership team on trends affecting scholarly communications. The board sets strategic directions for the organisation while also providing oversight into policy changes and implementation. Board members have a fiduciary responsibility to ensure sound operations. Board members do this by attending board meetings, as well as joining more specific board committees.

Crossref’s services provide central infrastructure to scholarly communications. Crossref’s board helps shape the future of our services, and by extension, impacts the broader scholarly ecosystem. We are looking for board members to contribute their experience and perspective.

Who can apply to join the board?

Any active member of Crossref can apply to join the board. Crossref membership is open to organisations that produce content, such as academic presses, commercial publishers, standards organisations, and research funders. In fact, this year the board has specifically included in the committee’s remit to “propose at least one name from a funder member for the current round of elections.”

There is a link at the bottom of this post to submit your expression of interest.

What is expected of board members?

Board members attend three meetings each year that typically take place in March, July, and November. Meetings have taken place in a variety of international locations and travel support is provided when needed. Following travel restrictions as a result of COVID-19, the board adopted a plan to convene at least one of the board meetings virtually each year and all committee meetings take place virtually. Most board members sit on at least one Crossref committee. Care is taken to accommodate the wide range of timezones in which our board members live.

While the expressions of interest are specific to an individual, the seat that is elected to the board belongs to the member organisation. The primary board member also names an alternate who may attend meetings in the event that the primary board member is unable to. There is no personal financial obligation to sit on the board. The member organisation must remain in good standing.

Board members are expected to be comfortable assuming the responsibilities listed above and to prepare and participate in board meeting discussions.

About the election

The board is elected through the “one member, one vote” policy wherein every member organisation of Crossref has a single vote to elect representatives to the Crossref board. Board terms are for three years, and this year there are five seats open for election.

The board maintains a balance of seats, with eight seats for smaller members and eight seats for larger members (based on total revenue to Crossref). This is in an effort to ensure that the diversity of experiences and perspectives of the scholarly community are represented in decisions made at Crossref.

This year we will elect two of the large member seats (membership tiers $3,900 and above) and three of the small member seats (membership tiers $1,650 and below). You don’t need to specify which seat you are applying for. We will provide that information to the nominating committee.

The election takes place online and voting will open in September. Election results will be shared at the November board meeting and new members will commence their term in 2022.

About the nominating committee

The nominating committee will review the expressions of interest and select a slate of candidates for election. The slate put forward will exceed the total number of open seats. The committee considers the statements of interest, organisational size, geography, gender, and experience.

2021 Nominating Committee:

Liz Allen, F1000/Taylor & Francis, London, UK, committee chair
Melissa Harrison, eLife, Cambridge, UK
Andrew Joseph, Wits University Press, Johannesburg, South Africa
Abel Packer, SciELO, São Paulo, Brazil
Lisa Scott, New England Journal of Medicine, Boston, USA

How do you apply to join the board?

Please click here to submit your expression of interest or contact me.

Service Provider perspectives: A few minutes with our publisher hosting platforms

Jennifer Kemp — Mon, 24 May 2021 00:00:00 +0000

Service Providers work on behalf of our members by creating, registering, querying and/or displaying metadata. We rely on this group to support our schema as it evolves, to roll out new and updated services to members and to work closely with us on a variety of matters of mutual interest. Many of our Service Providers have been with us since the early days of Crossref. Others have joined as scholarly communications has grown and services have evolved. Though fewer than 20 in number, their impact far outweighs the size of the group.

They, like us, work with a great variety of members and have a broad view into publishing trends. In this post, we focus on views from some of the publishing hosting platform Service Providers, who’ve taken the time to share their thoughts on a few questions:

What is the biggest change you’ve experienced working with publisher metadata over the last few years and how have you adapted to it?

It has become more and more important that not only the DOIs are registered with the minimum of necessary metadata to get the DOIs registered, but that a most complete set of metadata is being sent along – including author identifiers, funding information, abstracts, licenses, to support other Crossref services and improve discoverability.

– de Gruyter

Our clients are increasingly aware of the key role metadata plays in the effective dissemination of research. With an increasing number of published articles and a clear domination of “search engines” and aggregation of content, metadata is the primary means of making sure that publications reach the right audience. Publishers’ value-add includes not just copy editing, formatting, and packaging, but also now creating journal articles for the digital age that are discoverable and well linked to the research corpus. Furthermore, we sense a clear move toward standardization, which goes beyond the structure to introduce standardized semantics: adopting common taxonomies for classifying content in different dimensions. Our response is to introduce effective, automated and consistent services that capture, and surface metadata throughout the value chain from authoring to publication and search.

– Atypon

Highwire’s publishers are always looking to use the latest DTD (Document Type Definition) for the content to stay up to current standards. Currently this would be JATS 1.2. They are choosing to remain current so that they can stay on top of all or new metadata that can enrich their deposits. We have handled this well and offer support for the latest version of DTD when they are released, but some publishers are not always familiar with what can/should be deposited with their content and this can be a learning process for them.

– MPS Limited

How do you explain to clients (and others!) why correct, quality metadata is important?

In the digital age, metadata is the key to enabling effective content consumption. Publications that cannot be effectively discovered are of little value. We can only increase the impact of research with “discoverable” and “machine readable” publications. So ensuring correct and quality metadata is the key to optimizing not only the processing (finding the right journal, editor, reviewers) but also to positioning each publication properly. As the volume of published scientific research increases, article metadata is the way forward — it brings “order” and enables our community to manage this volume.

– Atypon

Highwire always positions itself as “good content in” means “good content out”. This is true for our own content stores. Strong and valid metadata will result in valid and strong deposits. We explain this to all new clients on-boarded with Highwire and the use of current standards and for current client projects where content should/can be enriched through re-load.

– MPS Limited

Getting our journals to care about metadata is a two step process: First, make sure they understand how metadata will help their journal succeed (i.e. why it matters to them). Second, make it easy for them to produce metadata while minimizing the cost, time, or complexity of their workflow. The first step – making a case for why metadata matters – is often easier than you’d think. At the very least, most journal editors understand that metadata, e.g., JATS or DOI registration, is an important signifier of professionalism / prestige. In other words, they see that top journals publish metadata and want the same for their journal. From a more technical standpoint, metadata is important because that’s the format computers understand and, like it or not, the publishing ecosystem relies on computers to deliver all sorts of critical services – such as indexing, archiving, and discoverability. So, if you’re not publishing metadata, you’re likely missing the benefit of these services. The second step – making it easy to produce metadata – is more difficult. Journal editors generally understand metadata matters but often lack the technical skills or resources necessary to create metadata. This is where a platform, such as Scholastica, can be very helpful. Because platforms work with many journals, they can invest in tools to automate the creation of metadata, reducing costs for all their clients. For example, most platforms offer integrations to support automatic DOI registration. At Scholastica, we’re pushing this idea even further with automatic integration to more complicated services such as PubMed Central. By reducing cost and complexity, we can help new or small-budget journals have the same quality metadata normally reserved for large, established journals.

– Scholastica

We are sending other publishers’ metadata to academic libraries and distribution channels. Erroneous metadata will have a direct impact on how discoverable a title may be. The more uniform and correct the metadata, the better it will be indexed in other places.

– de Gruyter

What is the one industry development or trend you’re most excited about for the near future and why?

Open Science and the ability to deliver research with the tools for reproducing it is the most exciting and game changing trend. Technology has enabled the output of science to transition from two-dimensional printed text delivery into globally accessible and responsive web-based delivery. We are now taking the next steps to further leverage web technology to enhance research output with rich assets ranging from audio and video, datasets, executable code, high-resolution imagery, interactive applications and more. As more assets accompany research publications, viewing these assets as modular, individually citable, and reusable becomes a requirement. We are reviewing the whole research output flow from authoring to publishing, and most importantly to its dissemination through the myriad of discovery tools now available.

– Atypon

The move of everything to the cloud – this is changing and improving our infrastructure, our possibility to scale and to stay on top of technological development.

– de Gruyter

Thanks very much to the interviewees for their time and thoughts. We look forward to working with our entire Service Provider group on questions like these and many more. If you’d like more details, you can read about our Service Provider program or contact me for more information.

Next steps for Content Registration

Sara Bowman — Mon, 17 May 2021 00:00:00 +0000

UPDATE, December 2025: The legacy Metadata Manager interace will be switched off on 1 January 2026. We have been in touch with affected members throughout the year with guidance and resources on making the switch to our newest helper tool or alternative content registration methods.

---

Hi, I’m Sara, one of the Product Managers here at Crossref. I joined the team in April 2020, primarily tasked with looking after Content Registration mechanisms. Prior to Crossref, I worked on open source software to support scientific research. I’ve learned a lot in the last year about how our community works with us, and I’m looking forward to working more closely with you in the coming year to improve Content Registration tools.

Just over a year ago, we updated you on the status of Metadata Manager. TL;DR: We learned that our approach with the tool wasn’t flexible enough to easily and quickly add other record types or update the input schema, and paused new development. We’re back with another update on Metadata Manager and our strategy for Content Registration user interfaces (UIs) going forward.

Our helper tools for Content Registration

The bulk of content registered with us is done so programmatically; that is, our members’ (or their service providers’) machines talking to our machines using our APIs. But, there are plenty of our members that don’t have the technical expertise to work with us this way. For those members, we provide various helper tools to assist with manual content registration.

We offer a variety of interfaces for registering many different types of content, including Web Deposit form for most record types, Metadata Manager for journal content, and Simple Text Query to register references. Each of these has its own use cases and limitations, leading to a confusing and inconsistent experience for members who are manually depositing metadata. From our perspective, maintaining this many interfaces in different codebases is inefficient, in part because an update to the schema likely leads to separate updates in each of them. A unified user interface to register content would both improve and simplify the user experience for you, our community, and make updates quicker and more efficient. The original goal of Metadata Manager was to be this unified interface. But we’ve learned that the approach we took was flawed: there have been problems reported by users, and the tool itself isn’t flexible enough to easily and quickly add new record types or support new fields when our input schema changes.

A new approach to helper tools

So we’ve decided to build something new and retire the old. We’ll be focusing on creating a brand new Content Registration user interface that will eventually replace Metadata Manager, the Web Deposit form, and Simple Text Query. And what we’ve learned from our experiences with Metadata Manager and Web Deposit has greatly influenced our strategy going forward. The new tool will:

Have a Community focus

Design for small - Our membership demographic is evolving. A large (and growing) number of our members are very small, often with a single publication and no technical resources. Creating XML can be a barrier to participating in Crossref, and our helper tools are designed to lower that barrier.
Accessibility and localization support - All of our UIs should support major international accessibility guidelines and translation into local languages, to meet the needs of our global membership.
Open source code - Build in the open, so that others can contribute. This could mean an entire UI that we haven’t prioritized, or adding a new translation file, or tweaking some CSS.

Follow user-centered design processes

Unified user interface - Improve user experience and simplify tools and services by providing members with one place to go to register content via a UI.
Rapid iteration - Focus on a technical solution that allows for rapid development of UIs to support new record types and updates to our schema.
Building the right features for the right users - The needs of our large members and smaller members are different. Experience has shown us that the core audience for a helper tool is smaller members; we’ll tailor the features to solve the challenges of our smaller members.

Allow us to build content for the future

Tactical approach to record types - Quickly build UIs in a strategic order. We can’t build support for every record type at once, so we want to identify and build in the areas of highest impact/lowest effort first.
Deliberate approach to supported fields - Not all members will supply metadata for all fields in our schema. Building a UI to support all fields for a specific record type before moving on to another slows progress on that next record type. We’ll identify the most-used and most-useful fields to support first, and add more in a future iteration if needed.

Deprecating Metadata Manager

In order to free up the resources to develop the new Content Registration UIs, we need to stop doing other things - that means not adding to, supporting, or bug-fixing other Content Registration tools. We’re setting an aggressive goal of sunsetting Metadata Manager by the end of 2021, with a commitment to a smooth transition to our new tool. This means that new members should not start using Metadata Manager. New members who need a helper tool have a few choices:

those who use the OJS platform from PKP to host their journals (OJS V3 and above) should use the third party Crossref OJS plugin to register their content.
other new members should use the Web Deposit form
current members who are using Metadata Manager may continue to do so, but are advised that we won’t be doing bug fixes or further development on the tool, and that support will be scaled back. If possible, you should transition over to using the Web Deposit form.

This wasn’t a decision made lightly, but one made after considering multiple options and all the data available to us about member usage and internal resources.

To highlight some of the data that led to this decision: the Support team tracks the types of support tickets they handle. In 2020, the 3rd most common ticket type was Metadata Manager-related. But less than 4% of metadata records registered with us are registered using Metadata Manager. Supporting Metadata Manager requires resources disproportionate to the amount of use the tool gets. For comparison, twice as many records are registered using the Web Deposit Form, but it generates far fewer Support tickets. To fix the bugs and issues reported about Metadata Manager requires an equally disproportionate amount of developer resources. So far, we have been unable to free up resources we would need to fix them all. Continuing to maintain this tool is effectively preventing us from building something new that will better meet the needs of our smaller members.

We know this will surprise and concern some of you, especially heavy users of Metadata Manager. We’re committed to making this a smooth transition, and over the coming months, we’ll provide more guidance to help current members migrate to our other tools.

Involving the community

Building a tool that allows us to create and adapt content registration forms based on example input files is an exciting new approach - one that will allow us to better serve the needs of our smaller members across multiple record types and support those who want to adapt our tools to their own needs. We’ve already begun work on a proof-of-concept tool aligned with this new strategy and I’m excited to drive it to production. As this project develops, we’ll keep in close contact with members, conducting user interviews, feedback sessions, and using usage data to help guide our decision-making on features and design. As we’ll be building in the open, we’ll have prototypes to share along the way as we iterate to produce a tool that will stand the test of time as well as scale to support even more content and members in future. We welcome your feedback over on our Community Forum, where we’ve set up a dedicated category to discuss this topic.

Doing more with relationships - via Event Data

Martyn Rittman — Fri, 14 May 2021 00:00:00 +0000

Crossref aims to link research together, making related items more findable, increasing transparency, and showing how ideas spread and develop. There are a number of moving parts in this effort: some related to capturing and storing linking information, others to making it available.

By including relationship metadata in Event Data, we are taking a big step to improve the visibility of a large number of links between metadata. We know this is long-promised and we’re pleased that making this valuable metadata available supports a number of important initiatives. We will also be backfilling, so all previously deposited relationships will eventually become available as events. The first step will be to add relationships between items that have DOIs, such as between a research article and a related review report or dataset.

What are relationships?

When members register metadata with us, they have the possibility to identify other works, items, and websites that they know are related. This might be supplementary material or previous versions of a work (especially for preprints and working papers). Equally, identifiers for a protein, gene, or organism used in the research can be included. These are recorded as ‘relationships’ and can be accessed in the same way as the rest of the metadata we hold about registered content.

Some examples

Relationships in the metadata show links to the published article from this bioRxiv preprint. In the Crossref Rest API:

"relation": {
 "is-preprint-of": [
 {
 "id-type": "doi",
 "id": "10.1038/s41467-020-17892-0",
 "asserted-by": "subject"
 }
 ],
 "cites": []
},

And now in Event Data:

"subj": {
 "pid": "https://doi-org.pluma.sjfc.edu/10.1101/2020.05.21.109546",
 "url": "https://doi-org.pluma.sjfc.edu/10.1101/2020.05.21.109546",
 "work_type_id": "posted-content"
},
"obj": {
 "pid": "https://doi-org.pluma.sjfc.edu/10.1038/s41467-020-17892-0",
 "url": "https://doi-org.pluma.sjfc.edu/10.1038/s41467-020-17892-0",
 "method": "doi-literal",
 "verification": "literal",
 "work-type-id": "journal-article"
},

Linking to a dataset in the Dryad Digital Repository by a recent eLife article. In the Crossref metadata:

"relation": {
 "is-supplemented-by": [
 {
 "id-type": "doi",
 "id": "10.5061/dryad.s58qh",
 "asserted-by": "subject"
 }
 ],
 "references": [
 {
 "id-type": "doi",
 "id": "10.5061/dryad.s58qh",
 "asserted-by": "subject"
 }
 ],
 "cites": []
},

And now in Event Data:

"subj": {
 "pid": "https://doi-org.pluma.sjfc.edu/10.7554/elife.19920",
 "url": "https://doi-org.pluma.sjfc.edu/10.7554/elife.19920",
 "work_type_id": "journal-article"
},
"obj": {
 "pid": "https://doi-org.pluma.sjfc.edu/10.5061/dryad.s58qh",
 "url": "https://doi-org.pluma.sjfc.edu/10.5061/dryad.s58qh",
 "method": "doi-literal",
 "verification": "literal",
 "work-type-id": "Dataset"
},

If you are interested in relationships for a single DOI, we still recommend checking the metadata of that record, however Event Data is a great option for looking across multiple records. For example, to check for relationships across a prefix, in a given time period, or for a specific type of relationship.

Data citation

Data citations can be included in data deposits in relationship metadata, usually using the ‘is-supplemented-by’ relationship. By creating an event from each relationship, the links between journal articles and books, and the data they rely on are more visible. This makes the data much easier to locate.

Many datasets have DOIs which are usually recorded with DataCite, meaning you are unlikely to find them via searches of Crossref metadata. Making data citation relationship metadata available in Event Data means it will be available in the same format as citations from datasets to articles (which DataCite sends to Event Data) and citations from articles to datasets from Crossref reference metadata (more to come on this later this year). It also means we will convert this information into Scholix format so that it can be harvested and combined with other sets of Scholix-compliant article/data links. Data citations will therefore be available for the community to identify, share, link and recognise research data. We’re working with initiatives like Make Data Count and STM’s research data program to support the growing uptake of good data citation practices. This is a big step forward in making data citation happen for the community; we have more to do, but Crossref is committed to completing this work as a strategic priority.

What’s next?

In this first stage we are adding relationships that link two objects with a DOI, and later this year we will bring in relationships using other identifiers such as accession numbers and URIs. That will make it more straightforward to ask questions of Event Data such as which organisms have relationships to which works with a DOI.

More info and staying in touch

Find out more about Event Data in our support documentation or check out tickets in the GitLab repo.
Keep informed and ask us anything via our community forum for Event Data discussion

Open-source code: giving back

Joel Schuweiler — Fri, 30 Apr 2021 00:00:00 +0000

TL:DR;

Hi, I’m Joel
GitLab UI unsatisfactory
Wrote a UI to use the API
Wrote a missing API
Open company contributes changes back to another open company
Now have a method for getting work done much easier
Hurrah!

I’m Joel, a Senior Site Reliability Engineer here at Crossref. I have a long background in open source, software development, and solving unique problems. One of my earliest computer influences was my father. He wrote software to support scientists in search of things like the top quark, the most massive of all observed elementary particles.

One day my father came home with over 40 floppy disks, excited to have this cool, free operating system called Linux. Together we installed Linux and ended up with a fully functional computer. Learning and using Linux opened up an entirely new world to me of amazing open-source software that I could use freely. As I enjoyed all this new software now available to me, I tried to fix any bugs or problems I’d encounter and report solutions for them to the software developers. It felt great to be able to contribute back so others could benefit.

Software teams tend to manage their workflow by writing issues, reviewing them to make sure they make sense and have an achievable goal, estimate how much time it will take to complete, and finally––the crucial step––putting the issues in the order in which they should be completed. To manage my work, I’ve always used Jira––a product designed to help teams of all types prioritize work––and for the first time in over a decade, I find myself not using it in my work.

Product development tracking with GitLab

The Crossref team took the decision a few years ago to move all our development and product tracking work via GitLab––a commercial open-source product anyone can use to help keep track of software throughout the development life cycle––with an open-by-default policy. Work is tracked using the issues feature of Gitlab. GitLab will host it, so you don’t have worry about maintenance and backups. One major drawback I discovered with GitLab, is a lack of maturity when it comes to doing light project management work.

This is where the trouble begins with GitLab.

In the board view of your issues, you can transition your issues from waiting, to in progress, from in progress to done. The problem with this view is its width-restricted, and things like tags on issues, which are used to help categorize, take up valuable vertical space. With enough tags and a long enough subject line, you can only see five issues at a time on a MacBook Pro monitor, for example.

In the list view of your issues, you get a clean compact view; the perfect view to order issues. However there’s one major flaw, it’s paginated. (You know when you’re shopping and they make you click to see another page of goods? Yes, like that.) The problem with GitLab’s implementation is you can drag and drop issues on a given page, but there is no way to move the issues to another page in the list of results. Additionally, all newly-created issues are added to the end of the list.

The solution

I went about finding a solution by visiting GitLab’s own public issue page and found that requests requiring user interface (UI) changes would languish; in some cases, they would go years without getting approval. Instead of putting in all the work to open an issue with them, only to have it be discarded or ignored, I decided to look for another way.

GitLab has an API, what more could I need? I discovered I could log in and get a list of all the issues, by project, and by group. “This is perfect!”, I thought. I can write my own UI around it. It took three evenings writing a UI that was satisfactory to me. When I started writing javascript to interact with the UI, I learned that the ’re-ordering of issues’ didn’t actually have an API. Further investigation lead me to the issue tracker where I found an issue by a GitLab employee asking for the same functionality––the ability to re-order issues.

While in a chatroom for GitLab development, I was genuinely surprised by my experience. There was quick attentive help on locating the file I would need to implement the change, they set up a development environment, and even helped submit tests for my code while I worked on updating documentation and writing a changelog entry. It felt like GitLab must’ve designated an employee to work with the community on submitting improvements. In no time, the API for re-ordering was implemented. After the scheduled monthly release of GitLab rolled out with my new API, I was able to easily re-order issues.

GitLab’s response when help was needed along the way was impressive. Now there is a much easier method for getting work done that everyone can use. It’s rewarding when you can contribute back to the community for all to benefit.

Is GitLab as polished as Jira? No. Did they embrace me making changes by being open from the start and providing help along the way? Yes. Do I see Jira shifting its culture to match? Unlikely.

By emulating GitLab, an open organisation like Crossref has a shot at encouraging community development.

Stepping up our deposit processing game

Isaac Farley — Mon, 08 Mar 2021 00:00:00 +0000

Some of you who have submitted content to us during the first two months of 2021 may have experienced content registration delays. We noticed; you did, too.

The time between us receiving XML from members, to the content being registered with us and the DOI resolving to the correct resolution URL, is usually a matter of minutes. Some submissions take longer - for example, book registrations with large reference lists, or very large files from larger publishers can take up to 24 to 48 hours to process.

However, in January and February 2021 we saw content registration delays of several days for all record types and all file sizes.

Tell me more

Januaries and Februaries are usually busy at Crossref. Journal ownership changes hands. Members migrate from one platform to another (and can need to update tens of thousands of their resolution URLs). And, many of you are registering your first issues, books, or conferences of the year. Others of you have heard the calls of The Initiative for Open Citations (I4OC) and The Initiative for Open Abstracts (I4OA) and are enriching your metadata accordingly (thank you!). Tickets into our support and membership colleagues peak for the year. But did we see significantly more submissions this year?

As you can see, we did see larger-than-normal numbers of submissions in the first two months of the year. For the entire month of January 2021, we received nearly 1 million more submissions into our admin tool deposit queue than we did in January 2020 (2,757,781 in 2021 versus 1,848,261 in 2020). Under normal circumstances, this would lead to an increase in our processing times, so there’s that to consider. But there was also something else at play this year. We desperately needed to upgrade our load balancer, and so we did. Unfortunately, unforeseen at the time, these upgrades caused hiccups in our deposit processing and slowed down submissions even further, building up the number of unprocessed submissions in the queue.

When we saw the impact this was having we suspended the load balancer work until things were stable again. We also increased the resources serving our queue to bring it back down to normal. To make sure we don’t face the same problem again, we have put in better tools to detect trends in queue usage- tools which, in turn, will allow us to anticipate problems in the queue instead of reacting to them after they’ve already occurred. And as a longer-term project, we are addressing two decades of technical debt and rearchitecting our system so that our entire system is much more efficient.

Gory technical details

As part of our effort to resolve our technical debt, we’re looking to transition more of our services to the cloud. To accomplish this, we first needed to upgrade our internal traffic handling capabilities to route things to their new locations better. This upgrade caused some unforeseen and hard to notice problems, like the queue being stalled. Since the queue still showed things in process, it wasn’t immediately apparent that things were not processing (normally the processing on the queue will clear a thread if a significant problem occurs).

We initially noticed a problem on 5 February and thought we had a fix in place on the 10th. But, we again realized on 16 February that the underlying problem had recurred, and we needed a closer investigation.

For many reasons it took us too much time to realize the connection, until people started complaining.

While our technical team worked on those load balancer upgrades, some of your submissions lingered for days in the deposit queue. In a few examples, larger submissions took over a week to complete processing. Total pending submissions began to push nearly 100,000, an unusually large backlog. We called an emergency meeting, paused all related work, and dedicated additional time and resources to processing all pending submissions. On 22 February, we completed working through the backlog of pending submissions and new submissions were being processed at normal levels. As we finish up this blog on 2 March, there are less than 3,000 pending submissions in the queue, the oldest of which has been there for less than three hours.

This brings us back to the entire rationale for what we are doing with the load balancer - which, ironically, was to move some services out of the data centre so that we could free-up resources and scale things more dynamically to match the ebbs and flows of your content registration.

But before we proceed, we’ll be looking at what happened. The bumps associated with upgrading ancient software were expected, so we were looking for side effects. We just didn’t look in the right place. And we should have detected that the queues had stalled well before people started to report it to us. A lot of our queue management is still manual. This means we are not adjusting it 24x7. So if something does come in when we are not around, it can exacerbate problems quickly.

What are we going to do about it?

In a word: much. We know that timely deposit processing is critical. We can and will do better.

First off, we have increased the number of concurrently processing threads dedicated to metadata uploads in our deposit queue from 20 to 25. That’s a permanent increase. A million more submissions in a month necessitates additional resources, but that’s only a short-term patch. And we were only able to make this change recently due to some index optimizations we implemented late last year.

One of the other things that we’ve immediately put into place is a better system for measuring trends in our queue usage so that we can, in turn, anticipate rather than react to surges in the queue. And, of course, the next step will be to automate this queue management.

All this is part of an overall, multi-year effort to address a boat-load of technical debt that we’ve accumulated over two decades. Our system was designed to handle a few million DOIs. It has been incrementally poked and prodded to deal with well over a hundred million. But it is suffering.

Anybody who is even semi-technically-aware might be wondering what all the fuss is about? Why can’t we fix this relatively easily? After all, 130 million records—though a significant milestone for Crossref—does not in any way qualify as “big data.” All our DOI records fit onto an average sized micro-SD card. There are open source toolchains that can manage data many, many times this size. We’ve occasionally used these tools to load and analyse all our DOI records on a desktop computer. And it has taken in just a few minutes (admittedly using a beefier-than-usual desktop computer). So how can a queue with just 100,000 items in it take so long to process?

Our scale problem isn’t so much about the number of records we process. It is about the 20 years of accumulated processing rules and services that we have in place. Much of it undocumented and the rationale for which has been lost over the decades. It is this complexity that slows us down.

And one of the challenges we face as we move to a new architecture is deciding which of these rules and services are “essential complexity” and which are not. For example, we have very complex rules for verifying that submissions contain a correct journal title. These rules involve a lot of text matching and, until they are successfully completed, they block the rest of the registration process.

But the workflow these rules are designed for is one that was developed before ISSNs were widely deposited and before we had our own, internal title identifiers for items that do not have an ISSN. And so a lot of this process is probably anachronistic. It is not clear which (if any) parts of it are still essential.

We have layers upon layers of these kinds of processing rules, many of which are mutually dependent and which are therefore not easily amenable to the kind of horizontal scaling that is the basis for modern, scalable data processing toolchains. All this means that, as part of moving to a new architecture, we also have to understand which rules and services we need to move over and which ones have outlived their usefulness. And we need to understand which remaining rules can be decoupled so that they can be run in parallel instead of in sequence.

Pro tip: Due to the current checks performed in our admin tool, for those of you submitting XML, the most efficient way to do so is by packaging the equivalent of a journal issue’s worth of content in each submission (i.e., ten to twelve content items - a 1 MB submission is our suggested file size when striving for efficient processing)

Which brings us conveniently back to queues. We did not react soon enough to the queue backing up. We can do much better at monitoring and managing our existing registration pipeline infrastructure. But we are not fooling ourselves into thinking this will deal with the systemic issue.

We recognize that, with current technology and tools, it is absurd that a queue of 100,000 items should take so long to process. It is also important that people know that we are addressing the root of the issues as well. And that we’re not succumbing to the now-legendary anti-pattern of trying to rewrite our system from scratch. Instead we are building a framework that will allow us to incrementally extract the essential complexity of our existing system and discard some of the anachronistic jetsam that has accumulated over the years.

Content Registration should typically take seconds. We wanted to let you know, that we know, and we are working on it.

Discuss all things metadata in our new community forum

Vanessa Fairhurst — Thu, 11 Feb 2021 00:00:00 +0000

TL;DR: We have a Community Forum (yay!), you can come and join it here: community.crossref.org.

Community is fundamental to us at Crossref, we wouldn’t be where we are or achieve the great things we do without the involvement of you, our diverse and engaged members and users. Crossref was founded as a collaboration of publishers with the shared goal of making links between research outputs easier, building a foundational infrastructure making research easier to find, cite, link, assess, and re-use. It is at the very core of what we do and who we are. Our global community now includes publishers, libraries, government agencies, funders, researchers, universities, ambassadors, and more from over 140 countries. We are also actively part of the larger scholarly research community, which includes other open scholarly infrastructure organisations, metadata users and aggregators, open science initiatives, and others with shared aims and values.

What do we mean by ‘community’?

‘Community’ is often one of those words which gets bandied around without much thought given to its meaning. At Crossref, we are aware that expertise lies within our broad, global community and we engage with them (you!) in a variety of ways to ensure that decisions we make are community-led and that what we do, as well as what we don’t do, are in line with the views of our members and developed with your insights and input. We do this via our working groups, committees, ambassador program, beta-testing groups, in-person and online events, webinars, and on-going dialogues and feedback via our support channels and even social media. We are also involved in a number of collaborative projects with other organisations such as ROR, Metadata 2020, Make Data Count, PIDapooloza, and the FREYA project to name but a few.

Community is more than just signing up to be a Crossref member. It’s more than just attending an event or a webinar, or levelling up to include the use of a service like Crossmark or Similarity Check –– it’s really engaging with us and creating something together of shared value for the scholarly community. As an organisation, we’ve been so thrilled that there is a new group dedicated to highlighting community managers and our work. We are working with –– and learning a lot from –– the Centre for Scientific Collaboration & Community Engagement to improve the way we interact and involve people in Crossref. The model below shows a trajectory towards true collaboration that we aim to follow in the coming months and years.

Cite as: Center for Scientific Collaboration and Community Engagement. (2020) The CSCCE Community Participation Model – A framework for member engagement and information flow in STEM communities. Woodley and Pratt doi: 10.5281/zenodo.3997802

In the current climate, there are additional challenges and limitations on how we interact with all the various communities that we as individuals are a part of, both professionally and personally. I wrote in my last blog about how we have moved our events online and thought about new ways to better connect and engage with our community virtually. One of those ways is our Community Forum.

The purpose of our community forum

Hosted on the open-source discussion platform Discourse, you can find our forum at community.crossref.org. The goal of the community forum is to create an inclusive, open space where Crossref members, ambassadors, sponsors, service providers, and others who share a passion for scholarly infrastructure, can connect. This enables collaborative problem-solving, the sharing of expertise and experiences across time zones and languages, and allows members to post questions to be answered by other community members or even our staff. Members of the community engage via creating posts, commenting on existing content in the forum, volunteering for working groups or beta-testing projects, helping to co-create materials that include translations and shared FAQs, giving feedback on new developments, and joining online events and webinars. Throughout these interactions, we expect that those who use the community forum will form relationships –– a collective working together to advance their work with Crossref and shape the future of scholarly infrastructure.

When I joined Crossref as Community Manager over three years ago, the idea of a forum had already begun to take shape, but it wasn’t quite there just yet. There was additional research and consultation with the community to be done to check this was the approach we wanted to take.

This involved speaking to others working in scholarly communications about forums they were involved in running or were an active participant of –– check out the PKP forum for instance if you haven’t already –– and having numerous valuable conversations about successes, potential downfalls, and realistic expectations. The most important –– and commonly cited –– takeaway is that building an online community takes time. We are still at the start of this journey. It will only work if it is a place of value for all and a place where people feel a sense of belonging and co-ownership.

Preparing to rollout the forum

We tested the platform with a small group of beta-testers and also sent out a survey to over 1,700 of our members, taking a sample with a geographical and organisational spread. The responses thankfully held no major surprises and reinforced our belief that this is something of use to people.

Key research findings

77% of respondents had previously contacted our Support team for help resolving an issue.
90% stated either ‘yes’ or ‘maybe’ to whether they would use a community forum to post their questions, though over half have never used a forum before.
Most common reasons of importance for joining are ‘Community support in solving issues or answering questions’, ‘To locate FAQs and quickly find answers to common issues’, and ‘To connect with others working in a similar role and/or with similar interests’
Most commonly-stated things that would discourage or limit member’s participation would be how time-consuming and complex the forum is to use, and any potential language barriers.

Things you can do on the forum

We hope this will provide a much more open level of support for the community, enabling us to bring out all those great questions and thoughtful conversations we receive via our Support channels into the public sphere, where we can all benefit from these rich exchanges. Ultimately our goal for the future is that this space is owned by you, the Crossref community. This is a platform for you to connect and build relationships with others working in scholarly communications: metadata fanatics, identifier aficionados, developer gurus, and open research enthusiasts - we welcome you all!

Share what activities or projects you are working on and get input from others.
Share issues that you need some help resolving, post a question to the forum in your native language and get help from another community member.
Give us feedback on our plans and help us shape future developments at Crossref.
Test out new tools and services.
Find out about upcoming events and webinars, and share any you think are of interest to the community.
Help us identify better ways of working together through Crossref and co-create new materials and projects.

How to get started

So, how do I sign up you ask? Simply head over to community.crossref.org and set up an account. There’s a useful How-To guide available on our welcome post, as well as some Community Guidelines all our members should follow.

Do you have a question about registering or updating your metadata? Then head over to the Content Registration category and post your query to the group. Want to find out about getting started with Similarity Check service? Then take a look at our Similarity Check topic in our services category. Or maybe you want to know more about upcoming multilingual webinars at Crossref, or perhaps you have one of your own you’d like to share? Then check out the Community Calendar.

We’re also looking for talented linguists out there to help us translate our welcome email template into multiple languages so that anyone joining the community can get a welcome in their native language. To join in, visit my post in our ‘Questions from Crossref’ category.

We look forward to seeing you in the community soon!

Event Data: A Plan of Action

Martyn Rittman — Mon, 01 Feb 2021 00:00:00 +0000

Event Data uncovers links between Crossref-registered DOIs and diverse places where they are mentioned across the internet. Whereas a citation links one research article to another, events are a way to create links to locations such as news articles, data sets, Wikipedia entries, and social media mentions. We’ve collected events for several years and make them openly available via an API for anyone to access, as well as creating open logs of how we found each event. Some organisations are already using Event Data and we are keen for more to come on board.

Last year we gave an update on Event Data with apologies for being so quiet and a promise of more information at a later date. It’s been some time, so here goes…

I joined Crossref in the middle of last year as a Product Manager and was tasked with looking into Event Data. The first thing I found was a large amount of enthusiasm for Event Data, both within Crossref and further afield. The idea of gathering information beyond the metadata deposited by our members is popular, and creates valuable connections between DOIs and a range of other sources. Interest spans the spectrum of academic research, publishing, bibliometrics, and beyond.

At the same time, I found a project with a very solid, well-built code base but unstable performance. After being put into production in 2018, we didn’t provide sufficient support. Coupled with staff changes and other competing priorities, Event Data hasn’t had the opportunity to live up to early expectations.

To address these issues, we have embarked on a plan to make the server infrastructure more robust, improve monitoring, and make sure that the future of Event Data makes the best use of the resources we have without over-stretching. It means working with the community to determine the most essential aspects of Event Data, and providing support where it’s needed.

The steps below are not necessarily sequential and some depend on the completion of work in other parts of Crossref, but they outline the priorities we have for Event Data in 2021.

The Plan

Stability

Since we put in place our original Event Data infrastructure, the amount of incoming data has grown, and at an ever-increasing rate. In 2017 we were creating 2 million new events per month, that number is now over 20 million. We have known for some time that we need to refresh the infrastructure, but didn’t have the resources to move forward: now we do.

In the first part of the plan we will renew the server infrastructure that underpins Event Data. Maybe not a headline-grabbing move, but the aim is to reduce downtime and pull in missing data. Through improving our monitoring and shortening the response time when things go wrong, we will be able to ensure that events are added on a regular basis and the API can reliably handle requests.

We’ve made the first steps in this direction by upgrading our API infrastructure and making some other tweaks to improve performance. There is still work to do, but we’ve already seen a significant improvement in performance with nearly >99.99% uptime in December.

Consolidation

The second component of the plan is to review performance and data quality. We will evaluate the event sources, update artefacts (such as the lists of publisher landing pages and news websites, and review performance reporting. This will help us to have a better understanding of Event Data in its current form: if the stability component is about improving what comes in and goes and out, this part will give us increased confidence in what Event Data already contains.

Future roadmap

While the two steps above are being carried out, we will revisit the applications of Event Data and talk to organisations that currently use it or have expressed an interest. These conversations will feed into future development in which we will evaluate new sources and other ways to optimize the service.

Central to the roadmap will be continued support of the data citation endpoint in Scholix format, which we run in close collaboration with DataCite. Additionally, we will add new data from relationships between Crossref works, for example a preprint is matched to a journal article, or where there are corrections, retractions, or translations of works.

We expect to continue supporting the current sources of events and where there are organisations with either a strong interest in a particular source or a database of events that they can send directly, we are keen to build collaborations. Event Data, like everything that Crossref does, is a community-based effort.

Staying in touch

To join the conversation about Event Data and keep informed, head over to our Community pages. You can also check out our Gitlab pages. At the end of last year we updated the Education pages where you can learn more about Event Data.

New public data file: 120+ million metadata records

Jennifer Kemp — Tue, 19 Jan 2021 00:00:00 +0000

2020 wasn’t all bad. In April of last year, we released our first public data file. Though Crossref metadata is always openly available––and our board recently cemented this by voting to adopt the Principles of Open Scholarly Infrastructure (POSI)</agic––we’ve decided to release an updated file. This will provide a more efficient way to get such a large volume of records. The file (JSON records, 102.6GB) is now available, with thanks once again to Academic Torrents.

Use of our open APIs continues to grow, as does the metadata. Last year’s file was 112 million records and 65GB. Just nine months later (though it feels longer than that!), the new file is over 120 million records and over 102GB. That’s all of the Crossref records ever registered up to and including January, 7, 2021. We continue to see around 10% growth in records each year––and while journal articles account for most of the volume, preprints and book chapters are two of our fast-growing record types. In addition to the growth in the number of records, many of the records are getting bigger and better as members look at their participation report and understand the value of enriching metadata records for distribution throughout the scholarly ecosystem. Elsevier recently opened its references, enriching over 12 million records. A number of members, including Royal Society, Sage, Emerald, OUP, World Scientific and more have started adding <a href="/blog/open-abstracts-where-are-we/" target="_blank"gicabstracts which now number over 9 million.

Help us help you––using the torrent and other important notes

We decided to release these public data files largely to help support COVID-19 research efforts but of course use cases for Crossref metadata vary widely and a few pointers should help all users:

Use the torrent if you want all of these records. Everyone is welcome to the metadata but it will be much faster for you and much easier on our APIs to get so many records in one file.
Use the REST API to incrementally add new and updated records once you’ve got the initial file. Here is how to get started (and avoid getting blocked in your enthusiasm to use all this great metadata!).
‘Limited’ and ‘closed’ <a href="/education/content-registration/descriptive-metadata/references/#00564/" target="_blank"gicreferences are not included in the file or our open APIs. And, while bibliographic metadata is generally required, lots of metadata is optional, so records will vary in quality and completeness.

Questions, comments and feedback are welcome at support@crossref.org.

Here’s hoping 2021 is a better year for us all! Stay well.

2021 on Crossref

Event Data now with added references

A bumpy ride, but we got there

Where to next?

Open references

Come and get your grant metadata!

How it started

How it’s going

Show me who is registering grants:

Show me all of the grants registered by Wellcome:

Show me all of the grants associated with the investigator name Caldas:

Award number:

Project title:

More to do

Update on the outage of October 6, 2021

More new faces at Crossref

Carlos Del Ojo Elias

Evans Atoni

Fabienne Michaud

Mike Gill

Panos Pandis

Patrick Vale

Outage of October 6, 2021

Why did we have such a complete outage and why did it take us so long to fix it?

2021 Board Election

The 2021 slate

Here are the candidates’ organisational and personal statements

You can be part of this important process by voting in the election

How can you vote?

Similarity Check news: iThenticate v2.0 ready for launch

Crossref Similarity Check - first things first

What’s new

Increased document upload capacity

Suspicious or hidden character detection

Preprint exclusion filter

Refreshed and responsive interface

Similarity reports - save and share

Annotations

Content portal

Improved API for subscribers who integrate Similarity Check with their manuscript tracking system

What’s next

We’ll keep you posted

Lesson learned, the hard way: Let’s not do that again!

TL;DR

How we got here

How we investigated the problem

How we fixed all those records

Next up

Crossref Conversations: audio blog about helping open science

Helpful links

Some rip-RORing news for affiliation metadata

The background

The plan

The call for participation

Behind the scenes improvements to the REST API

Feature parity, but note a few differences

Some technical notes on the cutover

Documentation

Temporary domain

Differences in query results

Cursor behavior

Filing issues

Coming next

DOAJ and Crossref sign agreement to remove barriers to scholarly publishing for all

About DOAJ

About Crossref

Event Data: Help us fill in the gaps

An Advisory Group for Preprints

Time to put the "R" back in "R&D"

Rationale & details

The road ahead: our strategy through 2025

Tl;dr

The emergence of a strategic agenda

Ahh, 2019, such an innocent time

But first, some framing

Now for those contextual six goals

You’re invited to a mid-year update webinar

Our annual open call for board nominations

Board roles and responsibilities

Who can apply to join the board?