Content Registration on Crossref

Building, refining, and connecting: summary of our May 2026 community update

Rosa Morais Clark — Tue, 30 Jun 2026 00:00:00 +0000

Our 2026 Community Update took place on 13 May. Two calls, one for the eastern and one for the western time zone, highlighted how our global community is growing, how we’re refining the metadata that supports trust in the scholarly record, and connecting records more effectively through our latest tools.

Operations, governance, and a growing membership

Our Chief Operating Officer, Lucy Ofiesh and Executive Director, Ed Pentz, opened each session with an update on operations and governance, starting with the Principles of Open Scholarly Infrastructure (POSI). We adopted POSI in 2020. Recently, the Principles were updated by a group of adopters, following a community consultation, and four new principles were added: periodic review of purpose and community value; transparent operations as a distinct principle; refined guidance on financial reserves; and attention to volunteer labour and transition planning. Recordings and slides are also available.

Infrastructure organisations can use POSI to assess themselves and demonstrate to the community how they’re adhering to the principles, which support forkability, long-term sustainability, open assets, and transparent, community-led governance. We published a biannual report on how we measure up against them, so we’ll publish our next self-audit against the new set at the end of 2026.

Financially, we’re in good shape. With so many new members joining every month, our revenue grew 8% last year, while expenses came in 3% under budget, and Content Registration was up 13% year-on-year at the end of March, well above our long-term average of around 7%. We’ve used our operating surplus to build up and maintain a reserve fund of 12-months of operating expenses, which matters for long-term sustainability. We use additional surplus funds beyond our reserves to reinvest in our mission and community.

We had our call for board nominiations in May. Seven seats are up this year, one large and six small, and any member can stand. Voting runs for around five weeks, one vote per member, regardless of size. Last year, just 6% of members voted, and we’d like to see that increase. The call for expressions of interest is now closed for 2026, and candidates will be announced by our Nominating Committee in the coming months in advance of the election and annual meeting, which will be held on 22nd October 2026.

Robbykha Rosalien and Maryna Kovalyova from our membership team then took us through the membership picture. We’re now 25,000 organisational members from 167 countries, with around 51% based in Asia. The majority of our new members are universities, scholar-led publishers, societies, small journal publishers, and government agencies. We have help from 140 sponsoring organisations and 42 ambassadors, and we’re grateful for all the support they offer our members.

The metadata corpus and its use have grown alongside the community

Turning to new members, over 3,000 have joined from 142 countries since the last community update. 54% are from Asia, with Indonesia accounting for 17.5% of the total and India next at 9.5%. We continue to have members joining from the US and the UK, and we also have over 100 new members from Türkiye, with strong growth in Brazil and Pakistan as well.

January 2026 brought a major change with the introduction of a new fee tier for members with annual revenue or expenses (whichever is higher) of under USD 1,000. Since then, 40% of the new members joined under this new tier. 40% of our new members identify themselves as publishers and 40% as universities or scholarly organisations, with plenty of societies (13%), governmental agencies or NGOs (4%), and others, such as hospitals. The most popular publishing platform choice among the new members remains Open Journal Systems by PKP at 55%, with 30% saying they have no platform, and WordPress (4%) and Scholastica (2%) following. Notably, we’re working with PKP this year to help members transition to OJS 3.5, which supports richer metadata.

We also extended our Global Equitable Membership (GEM) program at the start of the year to include 18 additional countries. GEM offers Crossref membership and Content Registration without any fees. Since the last community update, we’ve gained our first members in Haiti, South Sudan, and Niger, and 20% of all independent members who have joined since then are GEM-eligible.

Introducing the Member Practices Working Group

Our Membership Director, Amanda Bartell, introduced our new Member Practices Working Group with a reminder of Crossref’s role in preserving the Integrity of the Scholarly Record (ISR). We’ve always aimed to keep barriers to membership as low as possible, because the best way to support a healthy scholarly ecosystem is to make metadata about published content as open and transparent as possible. That openness lets members demonstrate their practices through metadata, signalling trustworthiness to the scientific community as a whole, and when practices fall short, the metadata itself can surface those issues. Our member terms already make the importance of accurate metadata clear: if the community identifies inaccurate metadata, we can suspend or revoke membership. That is a last resort, and our first approach is always to contact the member, explain the problem, and work with them to get the metadata record corrected.

But what if the reports we receive from the community don’t relate to metadata, and instead to the member’s broader practices? This is an increasing issue, and it has been unclear how and when we should respond.

In consultation with our board, we updated our member terms last year and added an obligation for members to comply with a set of published member practices. The role of the working group is to draft this set of practices and provide clear guidelines on what we expect of Crossref members. In rare situations where issues can’t be resolved, the Member Practices will provide the basis for acting decisively, including suspending or revoking membership.

The Crossref Member Practices Working Group brings together differently sized members from different regions, metadata users, bibliometricians, and scholarly sleuths. Once drafted, we’ll take the Member Practices out for community consultation, with a board vote expected at their November meeting. It’s particularly important to us that the practices are achievable for all types of members, and we don’t want to create any extra barriers to entry or to continue membership for less experienced or less well-resourced members.

To seek feedback from the community on emerging themes, Amanda ran two live polls during the call. One of her questions was: for the records you register with Crossref, are you the journal owner, the nominated publisher, or a bit of both? 45% of respondents said a bit of both, with the journal owner as the next most popular response, and the nominated publisher after that. The second poll asked whether the phrase “nominated publisher” accurately describes what those of you in that role do. The result suggested it is broadly acceptable, though we’d still like to hear how you’d phrase it if not.

Metadata schema

Patricia Feeney and Helena Cousijn from our programs and services team walked us through a year of schema work and what’s coming next. Schema 5.4 was released in March 2025 with three key features: typed citations, version numbers, and preprint status.

Typed citations give members the chance to indicate in the metadata what type of citation it is, so when an article cites a dataset, it’s now possible to explicitly say so. So far 23 DOI prefixes are using typed citations, so adoption is starting, and we’d really like to see it grow. If this is something you think is useful for you, please take a look, or reach out, and we’ll help you get started.

Version numbers, which 25 DOI prefixes now use and mostly for preprints, let you indicate different versions. We’re not yet seeing much use for articles or other record types, which we’d like to encourage. Notably, when you’re registering new versions of the same record, there’s no separate content registration fee, as long as you include the relationship in the metadata.

Preprint status lets you indicate that a preprint has been retracted or withdrawn, for example.

Earlier this year, we added the ability to include grant DOIs in funding metadata. When you register metadata for any research output, you can now include the persistent identifier to indicate which grant funded the work. The number of grants registered as part of the Grant Linking System by our funder members grows (with now over 200,000 grant DOIs in existence). This dedicated new field provides an opportunity for members registering works to unambiguously identify the grants that funded the work. The grant DOI links to a full grant record, including funding type, project information, investigator details, funder and program/schema details, and institutional relationships.

We’re working on Schema 5.5. The main thing we know many of you have been waiting for is support for the CRediT taxonomy and its 14 contributor roles. We’re also enabling multiple roles for a single contributor, and within the Crossref vocabulary, which we still support, it will be possible to specify the corresponding author.

After 5.5 comes the update to our dedicated grant schema. Grant Schema 0.3.0 adds the ability to indicate that a grant was awarded to an institution (via a ROR affiliation ID), reflects that roles can change over time, and adds support for a persistent project identifiers, RAiD – a service that functions as a project identifier to indicate how a grant relates to one or more projects.

We’re also deprecating older schema versions. We’re supporting over 27 at the moment, which is too many and not helpful to members. The fundamental structures need updating, and we also need to tighten some of our requirements to obtain better and more complete metadata. We started the project at the end of last year, and we’ll be saying goodbye to a set of versions at the end of this year. Everyone using those versions has already been contacted, so if this concerns you, you should have heard from us. The project continues over the coming years, and we’ll work on deprecating other Schema 4 versions, so that by the end, we’ll only be supporting the different Schema 5 versions and the upcoming Schema 6. We’ll notify everyone impacted and let you know how to transition.

Once 5.5 and the grant schema are out, we’ll start working on remodelling contributor names, which is a really big project. A proposed model was circulated for feedback in May. The same update will also work on statements, currently for funding, acknowledgments, ethics, accessibility, AI use, data availability, copyright, and conflict of interest.

Tools and demos

Funder matching, rebuilt around ROR

Dominika Tkaczyk and Jason Portenoy from our technology and data science team gave an update on the Metadata Matching work, framed around the vision of the Research Nexus: a rich and open network of relationships connecting organisations, people, outputs, and activities within the scholarly record. First up for the project is funder matching, and Dominika and Jason took us through the new methodology and progress on implementing the work.

Funding metadata involves three main entities: funders, grants, and research outputs. Organisations are identified by Open Funder Registry (OFR) IDs or ROR IDs, and research grants and outputs have DOIs. These entities should be linked in order for provenance and attribution to be determined, which is important for evidence but also for things like research assessment and compliance.

The three entities: Funding and academic organisations→recipients are awarded grants→ repositories and publishers support outputs.

In practice, many of those relationships are missing when metadata is deposited. The new Crossref funder matching identifies the funding organisation from the name in the metadata and, when successful, inserts the correct organisation identifier, disambiguating the relation between the research output and its funder. Applying matching over the years has added around 2.8 million funder identifiers to records, shrinking the gap.

So why rebuild what we already have? Two reasons. We’re committed to supporting ROR more deeply across our services, and as part of that, we want to switch to ROR IDs as the main identifier for funders. Second, our current funder matching is part of our legacy system, which lacks transparency, thorough evaluation, or flexibility.

The new strategy is part of our metadata matching project. The core architecture is built, and the new strategy has been tested; we’re now adding features such as sending redeposits, with more testing later this quarter and a release aimed for around the middle of the year. After that, we’ll move on to a grant-matching workflow to link outputs to grant records where that link is missing.

They closed with a live demo covering four cases. Starting with a simple example of Wellcome, which matched cleanly because the input name matched the official organisation name exactly, they then moved on to more complex examples, showing increasing discrepancies between the input and the name variant in ROR, yet the strategy still resolved it. However, some names are not possible to match in this way, such as the “Faculty of Arts and Social Sciences,” which is a very generic name that many organisations might use as part of their structure. That matters too: the strategy recognises when no match should be returned, limiting the level of incorrect information that might be introduced into the metadata.

Data citations API endpoint

Martyn Rittman who heads up our Research Nexus development, and Panos Pandis from our technology team introduced the new data citations API endpoint. It exposes data citations from deposited metadata, with over 700,000 included so far. Among all the reference information we hold, individual data citations are difficult to pick out, and there’s a specific community interest in them, so we’ve put them together and made them available through a dedicated API.

Data citations can be included in two parts of a metadata record: references and relationships. We look for links to datasets registered with a Crossref DOI or a DataCite DOI. Documentation can be found here.

Through March 2026, we typically collected 400 to 600 data citations per day, with some variation, especially on weekends. The new endpoint is still in beta, and we invite feedback: is it useful, what would make it more useful, and what should we do next? Let us know on the forum.

Metadata Manager: new content types coming

Lena Stoll, who heads up our community trends program and Patrick Vale from technology took us through Metadata Manager. We retired the legacy interface at the end of last year and replaced it with a more modern and flexible helper tool for record registration. It’s already in use by an increasing number of members for grants and journal article records.

A recent addition is a search field, where you can enter the DOI of any supported record (currently a journal article or a grant) and edit it directly, if you have permissions. We’ve also added fields to the journal article registration form to include relationship metadata, which is key to building the Research Nexus.

Plenty more is coming. The new Metadata Manager will expand to support books and chapters, conference proceedings, reports, dissertations, and post-publication updates over the next few months. The interfaces follow a similar workflow: a page or two of work-level metadata, optionally chapter, or paper, or series metadata if applicable, a review step, and submission. We want to keep them as simple and usable as possible.

We hope that the post-publication update form will be welcomed by our members, as it will enable registration of retractions, corrections, and expressions of concern without any knowledge of XML. Lena and Patrick walked through a live demo of a retraction notice end-to-end. The system checks that the DOI being retracted exists, and any errors surface right away rather than later by email. We’re collecting feedback on the new tools on the forum.

The team also shared an update for institutions that use DSpace – its next version (version 10), will include a Crossref integration that lets you register Crossref metadata and DOIs automatically for content such as dissertations hosted in your DSpace repository.

Looking ahead

A new Service Providers Program

Madhura Amdekar shared our plans to launch a new version of the Crossref Service Providers Program later this year. Service providers are hosting platforms, manuscript submission systems, XML or metadata providers, and general publisher service organisations that work with our members to create, register, or display metadata on their behalf. They’re key partners in promoting metadata best practices, and we’re looking forward to collaborating with these organisations more closely. The program will not charge any fees; it will offer certification in two tiers, depending on the depth of integration with Crossref services.

We’d really like to hear from you: which service providers in this space would you like to see as part of the new program? Drop suggestions on the forum or get in touch with us directly.

Thanks to our speakers and to everyone who joined, asked questions, and voted in the polls. Recordings and slides are available, and the conversation continues on our community forum.

See you at the next one.

DOI resolution and deposit outage on 17 March 2026

Dominika Tkaczyk — Mon, 30 Mar 2026 00:00:00 +0000

On 17 March 2026, we experienced an outage that affected DOI resolution for Crossref DOIs and the deposit of metadata records by Crossref members. In this summary, we outline what happened, the impact on our community, and the steps we are taking to strengthen our systems and processes as a result.

Starting around 06:30 UTC, a surge of traffic to the Handle System, governed by the DOI Foundation and operated by CNRI, caused instability across several handle servers. As a result, users couldn’t resolve Crossref DOIs. Because the Crossref system relies on the Handle System to register new DOIs and update resolution information for existing ones, metadata deposits by Crossref members were also failing.

Although the handle service was restored by 09:30 UTC, the Crossref system held onto stale authentication sessions and did not automatically recover. Once we restarted the affected servers, deposit processing returned to normal around 10:18 UTC. We later reprocessed the failed submissions to ensure that members did not need to take any action.

While incidents like this are disruptive for our community, several aspects of our response worked well. Our support and technology teams reacted quickly, and we were able to restore the deposit workflow promptly. We were also able to reach CNRI through established communication channels, and they responded out of hours to begin mitigation.

The incident also highlighted areas where we can improve our processes and resilience. In addition to the changes made by CNRI (more backend handle servers and tighter rate limiting), Crossref is taking the following actions:

Knowledge sharing and documentation: Crossref, like all Registration Agencies, relies on the Handle System. We are reviewing the technical documentation describing how the Crossref system integrates with the Handle System, and we will continue working with CNRI to stay informed as the handle infrastructure evolves.
Improving handle session management: We are reviewing how our system manages handle sessions to explore how recovery could occur automatically after connection disruptions.
Submission rerun process improvements: We will review, clarify, and document the workflow for identifying and rerunning affected member submissions after disruptions to deposit processing.

Reliable DOI resolution and deposit processing are central to the research ecosystem. We’re committed to continuously improving the resilience of our systems and we will continue to learn from incidents like this one to strengthen them further.

If you have any questions, we are always happy to hear from you.

You can stay informed about the status of our services by subscribing to updates at status.crossref.org

Innovation in scientific publishing and its implications for Crossref DOI registration practices - MetaROR’s approach

Ludo Waltman — Tue, 03 Feb 2026 00:00:00 +0000

A couple of months ago, Ludo Waltman and André Brasil raised some questions about good practices for Crossref DOI registration, asking for input from the scholarly communication community. In this post, Ludo and André reflect on the input received and discuss the approach to DOI registration that the MetaROR publish-review-curate platform is going to take.

Practices for assigning DOIs and structuring the associated metadata are not merely technical details. They shape how scholarly outputs are discovered, cited, evaluated, indexed, and preserved over time. As new models of publishing emerge, especially those that decouple dissemination from evaluation, these infrastructural choices increasingly influence what counts as a scholarly object, as well as how credit and accountability mechanisms are organized.

As editors of MetaROR (MetaResearch Open Review), a platform launched in 2024 and operating under the publish-review-curate model, we are interested in good practices for Crossref DOI registration in the context of innovative new approaches to scientific publishing. In the earlier blog post, we invited members of the broader scholarly communication community to share their perspective on the following two questions:

For each article on the MetaROR platform, there is a corresponding article on a preprint server. Is it acceptable to have two Crossref DOIs, one registered by the preprint server and one registered by the MetaROR platform, for essentially the same article?
If Crossref DOIs are registered for articles on the MetaROR platform, should the articles be assigned the type ‘journal-article’ or the type ‘preprint’ in their Crossref metadata, or something else entirely?

We were pleasantly surprised by the level of interest in these two questions. We received about 15 responses from colleagues in the scholarly communication community. Some colleagues posted a reply at the bottom of our blog post. Others responded on social media (Bluesky, LinkedIn) or shared their perspective by email.

Below we reflect on the responses received and we outline the approach to Crossref DOI registration that MetaROR is going to take.

DOI registration for articles on the MetaROR platform

Colleagues offered mixed opinions on the question of whether articles on the MetaROR platform should have their own DOI, in addition to the DOI these articles have on the preprint server on which they were originally published. Some colleagues argued there is no good reason for registering DOIs for articles on the MetaROR platform and suggested this may cause confusion. One colleague reasoned that “if we want peer review to be something more ongoing and evolve beyond a single point in time judgment”, our approach should be to “better map the connections between events” rather than registering a new DOI each time an article has been peer-reviewed.

However, other colleagues expressed support for registering DOIs for articles on the MetaROR platform. One colleague pointed out that this “allows the user to reference the exact artefact they have consulted”. This colleague also reminded us that in the past “people were worried about having a different DOI for a preprint and another for a VoR (version of record)”, while nowadays this is a generally accepted practice. Another colleague emphasized the value of decentralization and suggested to “let a thousand DOIs bloom”. Authors of an article peer-reviewed by MetaROR argued in favor of “an overarching DOI for the full package (preprint, reviews, author response and link to updated preprint)”, which in their view would make MetaROR’s “process more coherent”.

Having considered the various arguments in favor of or against registering DOIs for articles on the MetaROR platform, we feel the arguments in favor are more compelling. Our perspective is that an article on the MetaROR platform differs in a meaningful way from the corresponding article on a preprint server, since the article on the MetaROR platform has been enriched with an evaluation by peer reviewers and editors. MetaROR provides a carefully curated package that includes not only the article itself, but also review reports and an editorial assessment. In our view, this justifies registering DOIs for articles on the MetaROR platform. We also see DOI registration for articles on the MetaROR platform as a way to promote appropriate recognition for authors of articles peer-reviewed by MetaROR, similar to the way authors get recognition for articles published in traditional peer-reviewed journals.

Of course, when an article has multiple versions, each with their own DOI, it is important to establish a link between the different DOIs, indicating that the DOIs are associated with the same work. This is important for articles published first on a preprint server and then on a platform such as MetaROR just like it is important for articles published first on a preprint server and then in a peer-reviewed journal. In practice, we establish these links by registering relationships between DOIs in the associated metadata. In this way, we ensure that indexing services, discovery systems, and research analytics tools are able to recognize that the DOIs refer to different manifestations of the same work rather than independent outputs.

Record type for articles on the MetaROR platform

Our second question is about the record type to be used when registering a Crossref DOI for an article on the MetaROR platform. Many colleagues who provided input on this question argued there is a need for a new Crossref record type for ‘reviewed preprints’.

We feel the idea of such a new record type is interesting and its pros and cons deserve further consideration. However, any solution that requires changes in Crossref’s metadata schema will take time to realize, while for MetaROR we need a solution in the short term. At the moment, the most obvious options for MetaROR therefore seem to be to use either the record type ‘journal-article’ or the record type ‘preprint’ (which is in fact a subtype of the record type ‘posted-content’).

The use of the record type ‘preprint’ seems somewhat problematic to us, because preprints are typically understood to be articles that have not yet been formally peer-reviewed. In a way, articles on the MetaROR platform are the opposite of this, since these articles have undergone formal peer review. An article on the MetaROR platform is part of a package that also includes review reports and an editorial assessment. Such a package provides readers with a more informed understanding of an article than what they get from reading only the article itself. For this reason, we do not consider the record type ‘preprint’ to be suitable for articles on the MetaROR platform.

Instead of the record type ‘preprint’, we have decided to use the record type ‘journal-article’ for articles on the MetaROR platform. The record type ‘journal-article’ is intended for articles published in journals. To be clear, MetaROR considers itself a ‘platform’, not a ‘journal’. However, the distinction between ‘platforms’ and ‘journals’ is not very well defined and the choice of terminology therefore involves a certain degree of arbitrariness. Moreover, articles on the MetaROR platform have been formally evaluated, and in that sense they resemble articles in traditional peer-reviewed journals. Although the nature of the evaluation is different (i.e., MetaROR provides a narrative assessment, while traditional journals provide a ‘stamp of approval’), we feel the resemblance justifies the use of the record type ‘journal-article’. We also hope that the use of this record type will help to ensure that articles evaluated by publish-review-curate (PRC) platforms are treated similarly to articles evaluated by traditional journals, advancing beyond more conservative ways of dealing with articles on PRC platforms.

There is a precedent for using the Crossref record type ‘journal-article’ for articles evaluated by PRC platforms. For over a decade, this approach has been used by platforms operated by F1000, such as F1000Research, Gates Open Research, Open Research Europe, and Wellcome Open Research. The approach we are taking at MetaROR is similar to the approach taken by these platforms. At the same time, our approach is different from the approach of eLife, another prominent PRC platform. eLife uses the record type ‘preprint’ for all versions of an article on its platform except for the version that the authors consider to be final and that they choose to designate as the ‘version of record’. This version has the record type ‘journal-article’.

Summary of MetaROR’s approach to Crossref DOI registration

Figure 1 summarizes MetaROR’s approach to Crossref DOI registration. The figure considers the situation in which an article went through two rounds of peer review by MetaROR. Both rounds of peer review involved two reviewers. After two rounds of peer review by MetaROR, the article was published in a journal. We emphasize that journal publication is optional in MetaROR’s PRC approach. It is included in Figure 1 for the sake of completeness.

Figure 1: MetaROR’s approach to Crossref DOI registration

Each element in Figure 1 represents an item that has its own Crossref DOI. The shape of an element indicates the Crossref record type of an item (‘preprint’, ‘journal-article’, ‘peer-review’). MetaROR is responsible for the blue elements in the figure. The gray elements are the responsibility of other actors, either a preprint server or a journal. Arrows represent relationships between items. These relationships are captured in the Crossref metadata of the various items.

Figure 1 shows how MetaROR treats articles, review reports, editorial assessments, and author responses as first-class research objects. Each object has its own DOI, while the objects are linked through structured metadata. Assigning DOIs to review reports, editorial assessments, and author responses is central to our commitment to transparency, recognition, and reuse of evaluative contributions.

We note that Figure 1 assumes each version of an article on a preprint server has its own DOI. This is indeed how DOI registration is handled by many preprint servers, such as the OSF servers (e.g., MetaArXiv, PsyArXiv, SocArXiv), ChemRxiv, Research Square, and Preprints.org. However, some preprint servers use a single DOI for all versions of an article. This is the case for bioRxiv and medRxiv and also for arXiv, which registers DOIs with DataCite rather than Crossref. In the future, we hope these preprint servers will also adopt versioned DOIs.

Outlook

Over the past 25 years, practices for registering DOIs and associated metadata have evolved along with broader developments in the scholarly communication landscape. Inevitably, DOI registration practices will always be lagging behind the most recent developments in scholarly communication. From this point of view, the lack of agreement on good practices for DOI registration in the context of PRC platforms is not surprising. This lack of agreement can in fact be seen as part of a larger discussion about the pros and cons of different infrastructural approaches for handling ‘preprint review metadata’, including for instance the COAR Notify approach and the DocMaps approach.

MetaROR’s approach to DOI registration demonstrates both the power and richness of Crossref’s metadata schema and its limitations. As discussed above, several colleagues who responded to our earlier blog post consider the lack of a record type for ‘reviewed preprints’ to be a significant limitation. With the growing interest in PRC models for scientific publishing, there appears to be a need to systematically evaluate possible improvements that can be made to Crossref’s metadata schema to offer better support for new approaches to scientific publishing.

We see this not only as a technical challenge but also as an issue of infrastructure governance. We therefore invite further dialogue between DOI registration agencies, other metadata infrastructures, preprint servers, PRC platforms, and indexing services to explore pathways for improving metadata standards, whether through new record types, extended relationship vocabularies, or shared best practices. We hope our experiences with MetaROR will contribute to the collective effort needed to ensure that emerging models of scholarly communication are represented accurately, transparently, and responsibly in the scholarly record.

Crossref note: This discussion chimes with related plans for extending our schemas: more granular vocabulary for items within journal articles, preprints, reviews, and others; clearer relationship types; and support for the forthcoming NISO JAV recommendations. Our Preprint Advisory Group will discuss the topic this year, and our Metadata Advisory Group has both ‘journal article type vocab’ and ‘relationships’ on its radar for 2026. We look forward to engaging further on this topic as we work towards more flexible schemas in support of the Research Nexus.

The sunset is on the horizon for Metadata Manager. What's next?

Lena Stoll — Thu, 06 Nov 2025 00:00:00 +0000

TL;DR. Metadata Manager will be retired at the end of 2025. Over the past four years, we have been developing a new helper tool to replace it, and that tool has now reached a stage of maturity that means we will be able to switch off Metadata Manager by the end of the year.

How did we get here?

In 2021, we said that we would be retiring the deprecated Metadata Manager as soon as we can offer members a suitable replacement for registering their journal content. So this news has been a long time coming - Metadata Manager has been very challenging for us to support, and we have found it impossible to develop additional features. However, we did not want to take the final step of switching off the interface until we were able to offer a suitable replacement for members who rely on manual helper tools to register their journal content.

That replacement, our new record registration form, has now been used by many members for over a year to register their journal content. The feedback so far has been positive, and we have been able to add functionality to the tool at a pace that we are happy with.

In July 2025, we contacted those members who are still using Metadata Manager to let them know that the tool will no longer be available after December 2025. So if you are affected by this news, you were probably already aware of it. But we wanted to go into a little more detail on the sunsetting of Metadata Manager, why we are doing it, and what’s next for Crossref’s content registration helper tools.

What has happened since 2021?

We have been developing the record registration form ever since that announcement in 2021. It began its life as a helper tool for registering grant records, but we knew we wanted to expand it to cover journal articles and other record types as soon as we could.

To see whether the concept behind the grants form could be applied to journal content, we first built an initial prototype and tested it with a number of Crossref ambassadors and volunteers. We wanted to ensure that the tool was intuitive to use, and to understand what functionality it would need to support for it to be truly useful to our members. Following some iteration on the invaluable feedback we received from our testers, we finally released the tool to production in September 2024 and began encouraging members to use it for their real-life article deposits.

We have been continuously adding new functionality since then, from additional fields for registering richer metadata to a feature that allows members to edit their articles’ metadata without having to re-enter everything into the form.

Now, about two months from the target date for retiring Metadata Manager, the record registration form is used by members to register about 200 articles per day, while Metadata Manager still sees about double that volume of submissions. So we have some way left to go.

Why is now the right time to retire Metadata Manager?

2025 has been a year of addressing technical debt for Crossref. My colleague Sara wrote about this co-ordinated push towards modernising our system in her post about our cloud migration in the summer.

Having the long-awaited replacement for Metadata Manager in place will allow us to free up the resources that have been tied up for years by troubleshooting Metadata Manager, in terms of both technology and user support, so that we can focus on projects and initiatives that align with our longer-term strategy.

How will we avoid the new tool developing the same problems as Metadata Manager?

As stated above, Metadata Manager has caused us many issues and headaches in different ways - but we have also learned a lot from dealing with these problems. As Bryan Vickery wrote in 2020, Metadata Manager is “not flexible enough to easily add other record types, like books/book chapters, or to include any changes we may make to our input schema.” To address this, we built the record registration form in a schema-driven way, which makes it adaptable to any future schema changes. It also means that we can spin up prototypes of new forms for additional record types quite quickly.

So while Metadata Manager was custom-built in a way that could only ever work for journal content, the record registration form already supports two record types and will support more in future. This is key for our goal of building a complete research nexus, which extends far beyond journal content, and even beyond “content” as such (did someone say grants?).

What happens next?

Metadata Manager will no longer be available from January 2026.
Starting next year, if you attempt to access Metadata Manager at https://www-crossref-org.pluma.sjfc.edu/metadatamanager/, you will be redirected to a deprecation note on https://www-crossref-org.pluma.sjfc.edu/deprecated/ which will link out to the new tool.

What options do I have for registering my journal content going forward?

If your organisation still uses Metadata Manager to register metadata for your journal articles, now is a good time to begin familiarising yourself with the alternatives available to you from 2026 forward - these include, but are not limited to, the new record registration form.

If your journal has an ISSN

We recommend you begin using the record registration form as soon as possible. Simply go to https://manage-crossref-org.pluma.sjfc.edu/records and sign in with your Crossref account credentials to register a journal article. You can also see a list of all the journal article records you have previously registered using our manual helper tools at https://manage-crossref-org.pluma.sjfc.edu/records/edit and edit their metadata using the form.

To help you make the switch from Metadata Manager, we will be hosting an interactive webinar on 13 November about how to transition to the new tool. Register here or look out for the recording, which will be shared in our events archive.

If your journal does not have an ISSN

The record registration form currently only supports ISSNs as journal identifiers. Title-level and volume/issue-level DOIs, which are at the core of how Metadata Manager handles journal metadata, have been the cause for some of the problems we have had over the years with that particular tool. Also, Crossref DOIs have always been intended primarily as citation identifiers, and entire journals/volumes/issues are very rarely cited. For that reason, we built the Record Registration Form such that it doesn’t support registering or using journal-level DOIs.

With that being said, if you do not (yet) have an ISSN for your journal for whatever reason, you can use our web deposit form to register your articles with journal DOI. If you do obtain an ISSN for your title later on, you can then simply begin using the record registration form from that point onward.

How will the new tool continue to be developed?

We will continue to work with our members and community to develop additional functionalities for the journal article form. Currently we are working on allowing relationships metadata to be registered using the form.

Ultimately, the goal is for the record registration form to become the one-stop shop for members who manually register and update their metadata. To this end, we are working on expanding the tool to cover additional record types - we have recently developed a prototype for registering books and chapters, and we will be looking to test this in the coming months with volunteers who are currently registering their book metadata via other avenues such as the web deposit form.

If you would like to support these efforts, or you have begun using the new tool and would like to share your feedback, come join the discussion in our community forum.

References

Bowman, S. (2021). Next steps for Content Registration. Crossref. https://doi-org.pluma.sjfc.edu/10.64000/30vzx-r5x16
Bowman, S. (2025). We’ve migrated to the cloud; we hope you didn’t notice (but maybe you did). Crossref. https://doi-org.pluma.sjfc.edu/10.64000/wd6rx-vpq73
Vale, P. (2022). Forming new relationships: Contributing to Open source. Crossref. https://doi-org.pluma.sjfc.edu/10.64000/cvq2e-q8t24

Innovation in scientific publishing and its implications for Crossref DOI registration practices - Request for input

Ludo Waltman — Thu, 25 Sep 2025 00:00:00 +0000

Lots of exciting innovations are being made in scientific publishing, often raising fundamental questions about established publishing practices. In this guest post, Ludo Waltman and André Brasil discuss the recently launched MetaROR publish-review-curate platform and the questions it raises about good practices for Crossref DOI registration in this emerging landscape.

Digital Object Identifiers (DOIs) are unique identifiers commonly assigned to research outputs such as journal articles, preprints, peer review reports, and datasets. The DOI of a research output allows the output to be identified online in a persistent way, even when the underlying publishing infrastructure changes (e.g., a journal moving from one publisher to another).

There are several DOI registration agencies. Most of the larger scientific publishers work with Crossref, and so do many preprint servers, and therefore our focus in this post is on Crossref. Crossref also keeps track of metadata associated with research outputs, such as the title, authors, and publication date of an output, and it makes this metadata openly available via APIs for all kinds of services to ingest and reuse. Because indexing, discovery, and evaluation tools rely heavily on this metadata, content registration practices and metadata design choices can have major effects on the visibility and findability of research outputs and on analytics used to monitor and assess research outputs and their contributors.

For the most common types of research outputs, such as journal articles and preprints, a broad consensus has emerged over the past decades on good practices for DOI registration. Such consensus means that articles are assigned the record type ‘article’ in their Crossref metadata. Likewise, many preprint servers register DOIs for preprints at Crossref, with the record type ‘preprint’ in the metadata. (The arXiv preprint server is an exception; it registers DOIs for preprints with DataCite rather than Crossref.)

For innovative new publication platforms, however, good practices for DOI registration are less clear. The approaches to scientific publishing offered by these platforms often do not fit neatly into established ways of working. For instance, for some of these platforms, the traditional distinction between peer-reviewed articles published in scientific journals and non-peer-reviewed articles posted on preprint servers is no longer applicable. This raises fundamental questions about suitable DOI registration practices for new approaches to scientific publishing.

MetaROR

The MetaROR (MetaResearch Open Review) platform, launched in November 2024 by the Research on Research Institute (RoRI) and the Association for Interdisciplinary Meta-Research and Open Science (AIMOS), offers an example of the challenge of developing appropriate DOI registration practices for new publishing models.

Inspired by similar initiatives such as eLife and others, MetaROR adopts the so-called publish-review-curate model. Authors first publish their article on a preprint server and then submit it to MetaROR. MetaROR then organizes an open peer review process for the article. Review reports are published on the MetaROR platform, along with a copy of the preprinted article and an editorial assessment. Rather than a simple binary decision (accept vs. reject), an editorial assessment is a short one-paragraph statement summarizing the strengths and weaknesses of an article. Each review report and each editorial assessment has its own DOI registered at Crossref. In this way, review reports are treated as first-class research outputs that can, for instance, be indexed in scientific literature databases and can be cited in other research outputs.

For an article submitted to MetaROR, the publication of the review reports, the editorial assessment, and a copy of the article itself concludes MetaROR’s publish-review-curate process. The authors of the article may revise their work in light of the feedback received, and MetaROR may review the revised article. However, there is no requirement that revisions must be made. The primary aim of the review reports and the editorial assessment published on the MetaROR platform is to offer context for readers of the article, helping readers understand the strengths and weaknesses of the article.

Crossref DOI registration

Registration of DOIs for open peer review reports is increasingly common. By registering Crossref DOIs for review reports and editorial assessments, MetaROR enables reviewers and editors to be recognized for their contributions. But what about recognition for authors?

A crucial element in MetaROR’s philosophy is that authors of articles peer-reviewed by MetaROR deserve to be recognized in a similar way as authors of articles published in traditional peer-reviewed journals. One way to promote appropriate recognition for authors of articles peer-reviewed by MetaROR is to ensure that articles on the MetaROR platform, just like articles in peer-reviewed journals, have their own DOI. While this may seem straightforward to arrange, it actually raises two non-trivial questions about good practices for Crossref DOI registration:

For each article on the MetaROR platform, there is a corresponding article on a preprint server. Is it acceptable to have two Crossref DOIs, one registered by the preprint server and one registered by the MetaROR platform, for essentially the same article?
If Crossref DOIs are registered for articles on the MetaROR platform, should the articles be assigned the type ‘article’ or the type ‘preprint’ in their Crossref metadata, or something else entirely?

On the first question, it could be argued that having two Crossref DOIs for the same article is problematic and that MetaROR, therefore, should not register DOIs for articles on its platform. Alternatively, one could argue that an article on the MetaROR platform differs in a meaningful way from the corresponding article on a preprint server, since the article on the MetaROR platform has been enriched with peer review reports and an editorial assessment, similar to the way an article in a peer-reviewed journal may be seen as an enriched version of the corresponding article on a preprint server. This line of reasoning would justify registering DOIs for articles on the MetaROR platform.

On the second question, the argument could be made that articles on the MetaROR platform should be assigned the type ‘preprint’ in their Crossref metadata, since the type ‘article’ is intended for articles in journals and MetaROR does not consider itself to be a journal (in fact, MetaROR works with partner journals to enable articles peer-reviewed by MetaROR to be published in journals) and does not certify articles in the way journals do (i.e., MetaROR does not make accept/reject decisions). On the other hand, one could argue that articles on the MetaROR platform should be assigned the type ‘article’, since the peer-reviewed nature of articles in journals is typically seen as the key factor distinguishing these articles from articles on preprint servers. Articles on the MetaROR platform have been peer-reviewed, and in that sense, they resemble articles in journals. A third line of reasoning could be that neither the ‘preprint’ nor the ‘article’ type is fully appropriate for articles on the MetaROR platform and, consequently, that there is a need for a new Crossref record type.

What is your take?

The MetaROR team, in consultation with Crossref, will need to decide how to deal with the two questions discussed in this blog post. After some preliminary conversations between the MetaROR team and Crossref, we decided to share these questions more widely to solicit input from the broader community. We invite you to share your thoughts on the two questions, either by posting a comment on this blog post or by reaching out to us on social media or by email. Community perspectives will help shape good practices not only for MetaROR but also for other publish-review-curate initiatives facing similar questions. We look forward to hearing from you!

Ludo Waltman and André Brasil are members of the editorial team of MetaROR. Ludo and André are grateful to Ginny Hendricks at Crossref for valuable discussions about the issues raised in this blog post.

Scholarly blogs and their place in the research nexus

Lena Stoll — Tue, 24 Jun 2025 00:00:00 +0000

If you are reading this blog on our website, you may have noticed that alongside each post we now list a Crossref DOI link, which was not the case a few months ago (though we have retroactively added DOIs to all older posts too). You can find the persistent link for this post right above this paragraph. Go on, click on it, we’ll wait.

Are you back here? Good. As you probably expected, the DOI link for this post resolves to the post itself, and you should use it anytime you want to cite this post. But the DOI does more than just point readers to this page––it is part of a rich metadata record that includes the authors’ ORCID iDs, the publication date, and more. In other words, the posts on this blog are part of what we call the research nexus: the open network of relationships connecting research outputs, people, organisations, and actions.

Crossref research nexus vision

Why blogs deserve a place in the scholarly record

A blog post may not be the first thing that comes to mind when you think of scholarly outputs. But scholarly blogs have been around since at least the early 2000s and have carved out a niche for themselves as a type of “grey literature” that allows researchers to write about research in a way that may not fit neatly into more traditional, peer-reviewed publishing venues, but also is too long-form for social media. Science blogs can give readers a window into ongoing work that isn’t ready to publish yet, serve as a self-publishing venue, or allow researchers to comment on others’ work and recent developments in science and science communication. These kinds of perspectives add crucial context to the scholarly record that should not be overlooked.

However, as Martin Fenner explained at the #Crossref2023 annual meeting, blogs have largely not benefitted from the metadata and long-term archiving solutions that tend to be applied to more “traditional” forms of publishing. As a result, most blogs have been left out of the scholarly record. But in recent years, there have been some efforts in the community to change this. Earlier this year, ORCID added support for the work type blog post, among others, to align more closely with the Confederation of Open Access Repositories (COAR) vocabulary of resource types.

At our 2025 midyear community update, we asked our community what content types they saw as growing in importance. Blog posts were mentioned several times as a ‘trending’ record type, and as one that members would like to see support for in the Crossref system.

Eating our own dog food

We had already been thinking for a while about how our own blog should be a part of the research nexus. We started out by manually uploading XML files through our Admin tool for each post. We did this for a few months and quickly found, like many of our members do, that this can be a laborious and error-prone process.

In the product management world, the process of using the products you usually spend your time building and maintaining is often referred to as dogfooding. The idea is that firsthand experience makes it easier to understand your end users’ needs and feel their pain - and we have certainly found that registering metadata for our blog posts has reinforced the importance of making manual registration easier for our members, but also of supporting and enabling machine-to-machine integrations.

What did we do?

The Crossref website, which includes this blog, uses an open-source static site generator named Hugo. Rather than using a content management system (CMS), we edit the website content in Markdown format using code editors. Whenever we start working on a post for this blog, we not only write the content of the post itself, but also include some front matter for the page, which contains some key metadata about the post.

The front matter of a recent post on this blog

We wanted this metadata to be part of the research nexus. But then there was also the question of archiving. Our membership terms state that:

The Member shall use best efforts to contract with a third-party archive or other content host (an “Archive”) (a list of which can be found here) for such Archive to preserve the Member’s Content and, in the event that the Member ceases to host the Member’s Content, to make such Content available for persistent linking.

So we knew that if this blog was to be part of the scholarly record, we would need to ensure that it would be available in perpetuity, even if www.crossref.org were to go offline one day.

Doing this properly was starting to look like a sizeable project!

Fortunately, we knew that others had already done some great work in this field, so we would not have to start from scratch. After considering our options, we opted to integrate our blog with an established workflow for registering blog metadata: the Rogue Scholar service.

The Rogue Scholar was launched in 2023 by Martin Fenner as an archive for scholarly blog posts, hosted by Front Matter. Rogue Scholar improves science blogs in important ways, including full-text search, long-term archiving, and DOIs and metadata, such as versions and relationships along with identifiers such as ORCID iDs and ROR IDs. It provides the necessary tools to treat blog posts as research outputs through better attribution, preservation, and discoverability.

How did we do it?

Rogue Scholar works on the basis of consuming RSS and ATOM feeds (you may remember them from the days of getting headlines direct to your browser or feed reader). We created a new feed, including the proposed DOI as each entry’s id: and taking full advantage of the ATOM format by listing the post’s authors and including their ORCID iDs. We also provide the entire post as the entry’s <content> to allow for full-text indexing and archiving.

The XML feed entry for a recent post on this blog

For each post, we generate and assign a unique DOI under the Crossref prefix 10.64000. The Rogue Scholar integration then registers the DOI along with the metadata of the post as posted content. If you are interested in getting a similar workflow set up for your blog, you can read more in the Rogue Scholar blog and documentation.

What does the future hold for scholarly blogs?

Researchers are increasingly sharing their early work, or commenting on others’ work, in less formal ways, and if you look at the growth in the number of blogs covered in the Rogue Scholar platform in just a couple of years, it seems like science blogging is here to stay and will only increase. We believe that this practice is an integral part of a healthy scholarly ecosystem, and it needs to be represented in the research nexus.

The Crossref input schema does not include a blog work type, but we are planning to add it as a subtype of posted content in our next schema update. We will discuss this and other plans and ideas in the metadata advisory group that we are currently forming.

If you have thoughts on the role of blogs in the public discourse around science and science communications, or you would like to share your experience of registering metadata for your blog, let us know by commenting below. Your comments will be threaded in our community forum for discussion.

Solving your technical support questions in a snap!

Isaac Farley — Thu, 25 Jan 2024 00:00:00 +0000

My name is Isaac Farley, Crossref Technical Support Manager. We’ve got a collective post here from our technical support team - staff members and contractors - since we all have what I think will be a helpful perspective to the question: ‘What’s that one thing that you wish you could snap your fingers and make clearer and easier for our members?’ Within, you’ll find us referencing our Community Forum, the open support platform where you can get answers from all of us and other Crossref members and users. We invite you to join us there; how about asking your next question of us there? Or, simply let us know how we did with this post. We’d love to hear from you!

A little about us and what drives the team

I’m fortunate to manage a great team - Evans, Kathleen, Paul, Poppy, and Shayn - who enjoy and are hardwired to guide. We have different strengths and interests, but the thing that unites us is that we are energized when we can unpick tricky problems for all of you, our members and users. In 2023, the technical support team answered around 11,000 questions from all of you. We do that with one-to-one requests sent to us via email and within our support center (using a closed-source software called Zendesk). And, we’ve been providing more and more support in our Community Forum, where we’re aiming for open interactions, so we can all learn from the rich exchanges with all of you (the Forum has an integration with Zendesk, so posts made in the Forum are delivered to us there, so our team won’t miss any of your questions).

We established in the previous paragraph that we have a great technical support team who all pride themselves on helping you. But we’re also human; the reality is that many of those ~11,000 technical support questions asked of us in 2023 were repetitive, and there are always trends in the questions asked. That’s another important reason why we’re hoping to have more and more of these questions asked and answered within our Community Forum; again, so we can all learn from one another. We know certain parts of content registration, metadata retrieval, and everything in between are, well, complicated. The Crossref learning curve can be steep for all of us. Collectively, our technical support team has more than 25 years of Crossref experience, and we’re continuously learning new things about the Research Nexus and the scholarly ecosystem from one another and all of you.

Learning through this complexity is one of the most enriching parts of our days. Our daily stand-up, modeled off of different software development methodologies, where together we troubleshoot tangly questions from all of you, share ideas, and just keep up-to-date on the latest from across the organisation leads to a lot of knowledge exchange. So, years ago, we decided to transform the issues we discuss in those stand-ups into public-facing posts in our Community Forum. It gave us the opportunity to share much-needed examples in a new community space; and, we knew, since these were the issues we were all discussing and learning from ourselves, that many of you would also benefit from us surfacing the topics openly. We call these posts tickets of the month, since the majority of topics we discuss have originated from tickets in our support center.

Examples of some of the most popular topics in the last two-plus years have been:

Snapping our fingers

Like I said, these posts originated from real-life questions of us from our community members. In most cases, we’ve been asked these questions by many of you. These Community Forum posts are our attempts to unlock understanding of our services, rich metadata, or the larger Research Nexus. Said another way: we all see value in putting in the effort to post one more example or answer that nuanced question. Perhaps one of our posts will include an example that really resonates with you and/or your work.

In that spirit, I asked Evans, Kathleen, Paul, Poppy, and Shayn to answer this question below (yes, I’m going to weigh in, too):

What’s that one thing that you wish you could snap your fingers and make clearer and easier for our members?

Evans, Technical Support Specialist

As a publisher and a Crossref member, at one point or another, you might have made a mistake in the metadata deposited for a given DOI. I’m sure after the slight ‘shock’, the next question you had in mind was, ‘How can I correct this mistake?’ Well, here is a simplified guide on how to do that correction/update!

Can I modify/ update the metadata of a registered DOI? As indicated by my colleague Shayn below in this blog post, Crossref DOIs are designed to be persistent (and cannot be changed/deleted once registered). And YES, you can update the metadata associated with any of your registered DOIs whenever necessary, at no additional fee.

How can I perform a standard metadata update? To add, change, or remove any metadata element from your existing records, you generally just need to resubmit your complete metadata record with the correct/new changes included. How you choose to update a DOI metadata record is highly dependent on the content registration tool/platform you are using/comfortable working with, as described below:

OJS: Navigate to the article record you wish to update, add in your new metadata/delete relevant metadata fields, and deposit it again using the Crossref import/export plugin. You must be running at least OJS 3.1.2 and have the Crossref import/export plugin enabled.
Web deposit form: Open the web deposit form, and re-enter all the metadata, including the new changes - leave the relevant field blank to delete it, or add in your new metadata to update it - and resubmit the form (note: there are a handful of exceptions to this for the web deposit form).
Depositing XML files with Crossref: Make changes to the relevant XML file and resubmit it to Crossref via the admin tool. When making an update, you must supply all the bibliographic metadata for the record being updated, not just the fields that need to be changed. During the update process, we overwrite the existing metadata with the new information you submit, and insert null values for any fields not supplied in the update. This means, for example, that if you’ve supplied an online publication date in your initial deposit, you’ll need to include that date in subsequent deposits if you wish to retain it. Note that the value included in the element must be incremented each time a DOI is updated.

If you’re looking for real-life examples of other members who have updated their metadata, the Community Forum is a great starting point. If you have follow-up questions on any of the existing threads, I invite you to post a message today.

Kathleen, Technical Support Specialist

One of my favorite types of queries to tackle are those regarding content registration problems. I love a good mystery and getting to the bottom of why that pesky submission just didn’t succeed. Sometimes members come to us with an error message and specific questions about what has gone awry. But, in fact, two of the most common questions we receive are: 1) I deposited something; did it work? and 2) I deposited something; why isn’t it showing up?!

To address the first question of whether your submission went through or not, I wrote a forum post back last June talking about how to use the admin tool to see whether your registration was successful or not. We know there are also email alerts and perhaps status messages within your own registration platform, but using the admin tool is a great way to concretely check where your submission has ended up. If it’s not there, we didn’t get it!

Using the admin tool is also a great way to get more details about the submission and more information in case the submission happened to fail. You may have had the experience in which you contacted us with a question about a failed deposit, and we asked you for the submission ID. You can find that info in the admin tool! And we ask for that, because that helps us get to the bottom of those error message mysteries.

And, as for the second question of when will your DOI be active, my colleague, Paul, wrote a fantastic post on the forum (with an excellent flowchart and all!), explaining when you can expect to see your DOI up and running. Often members will submit a deposit and expect the DOI to resolve immediately. When that doesn’t happen, many think that something has gone wrong or perhaps there is an error, but, in fact, our systems may still be updating and processing the metadata.

I recommend giving these two posts a read if you’re at all concerned about whether you’re depositing your content correctly or not. Hopefully, they’ll help ease your content-registration worries.

Isaac, Technical Support Manager

Oh, thanks for asking! Many of our members, after receiving one of our reports, will respond to us in support with a message similar to: ‘What did I do wrong? Please help me fix this. I don’t want to be out of compliance!’

The receipt of one of our reports does not necessarily mean that you’ve done anything wrong. In truth, the reports we send to our official member contacts are produced using very simple logic. It’s true that they may signal larger, more complicated problems, but we really need your help to determine next steps (and, in some cases, no action is needed because there is no issue for members to fix (e.g., many failed resolutions within the resolution reports)).

Let’s look at the conflict and resolution reports since those are the reports we get the most questions about:

Conflict reports are the most complicated of our reports to navigate. But, the reports are generated using simple logic: if you register two or more DOIs with matching bibliographic metadata, we’ll flag those DOIs as being in conflict, which will generate a warning message at the time of registration and a subsequent conflict report. When members receive this report, we often get the sense that members simply want us, the technical support team, to tell them how to fix it. The problem is we don’t know your content, so we don’t know if the two DOIs do represent a duplicate, or if both DOIs, while having very similar bibliographic metadata, are legitimate and will be maintained going forward (e.g., for errata). Paul wrote a great post in our community forum about what conflicts are and how to resolve them.

Resolution reports, like conflict reports, are generated using simple logic: a resolution is the result of a click on that DOI. If a DOI has been registered, that click results in a successful resolution. If that DOI has not been registered, that click results in a failed resolution. Our monthly report is a count of those resolutions - successful and failed. Failures can represent content registration errors in a member’s workflow. Or, they can signal that an end user has made a mistake when attempting to click the DOI in question. So, for example, an end user perhaps added an extra period onto their DOI link. Instead of trying to resolve https://doi-org.pluma.sjfc.edu/10.5555/cupnfcm2wj, a legitimate DOI, they added a period to the end and tried to resolve https://doi-org.pluma.sjfc.edu/10.5555/cupnfcm2wj. instead. That extra period at the end of the DOI has made it a completely different DOI that is not registered with us, thus they get a failed resolution. This is pretty common. For members with content being regularly clicked, there will be user errors in the logs appearing as failed resolutions. The first question members should ask themselves when reviewing the failed .csv report within the resolution report is: ‘are any of these DOIs legitimate DOIs that I thought we had registered?’ We have more on the basics of resolution reports also over in our Community Forum.

Paul, Technical Support Specialist & R&D Support Analyst

I know we were asked to name “one thing” but I have two that are closely related. May I snap my fingers twice and fix two issues? [Of course, Paul! Take it away!]

Paul’s first snap

One of the most asked questions we get in support is “why is my DOI not working?” 90% of the time it is down to a failed submission. A good proportion of those failures are a result of title mismatches between the deposited container title and the one we have stored on the system here. There are other error messages that occur, too, which I wrote about back in 2020.

So, “why do we fail submissions because of title differences?” You might ask.

Well, the title and ISSN/ISBN and/or the title level DOIs act like locks to the title record, which need the right keys to unlock the title so that you can add or update the records against it. So if you don’t match what was in the original submission, you get a failure. Without that stringent check, we would have way too many iterations of titles and matching to those would be a nightmare. Not to mention sorting those DOIs into one container in the REST API.

Isaac wrote a great forum post about these title-level issues as well.

If a title update is required due to an error with an original title deposit, then these need to be made by the support team, so get in touch with us on the Community Forum.

And, a second

Permissions against titles and DOIs: Lots of our members don’t realise that each DOI has its own permissions against the prefix that currently ‘owns’ or is associated with that DOI in the background.

It would be fair to assume you can tell just by looking at a DOI who the current publisher is, based on the prefix at the start —but that’s not always the case. Things can (and often do) change. Individual journals get purchased by other publishers, and whole organisations get bought and sold.

What you can tell from looking at a DOI prefix is who originally registered it, but not necessarily who it currently belongs to. That’s because if a journal (or whole organisation) is acquired, DOIs don’t get deleted and re-registered to the new owner. The update will of course be reflected in the relevant metadata, but the prefix on the DOI will stay the same. It never changes—and that’s the whole point, that’s what makes the DOI persistent. Isaac also wrote this in much more detail and explains the internal Crossref processes in his blog “What can often change, but always stays the same?“

These permissions are very important to understand when it comes to title transfers and working with updating your metadata against transferred DOIs to prevent duplicate DOIs for the same work.

Poppy, Technical Support Contractor

As a researcher myself, I’d like to talk about references in a journal article, book, conference paper, etc. (I’ll just use ‘article’ going forward for simplicity). These are the references included in an article by the author. References in one article result in citations for another article. It’s the thing every author dreams of and accruing citations can be a big deal for authors, journals, and publishers.

For readers, articles with no references can be less discoverable using systems that use citation links for relevance, and that discoverability is of critical importance for our members who decide to register references with us. We all want your content to be shared, cited, linked, and used far and wide.

We receive many questions from authors asking why citations don’t show up; it’s usually due to metadata deposits with no references included. There may be an assumption that our process is like Google Scholar, which crawls full text and websites. This misunderstanding has a big impact on references and citation counts. However, as we do not store a copy of the paper, our intake system does not extract references from the article, regardless if they have a DOI. This is one of the main reasons that Crossref citation counts are lower than services that use extraction methods. We only store the data that a publisher registers and maintains with us. On deposit of a metadata record that includes references, our system performs a matching process - if there is a match, a cited-by connection is applied to the metadata. With deposits with no references, however, there is no data to match to other articles (and, therefore limitations on the discoverability and no cited-by count increase).

An article with no references has big impacts for the authors, the journal, the publisher, researchers, and ultimately, the readers. This can mean decreased distribution of the content itself, reduced citation counts for cited articles, lower impact metrics for journals, and can ultimately affect value for publishers. For example, researchers just don’t include articles without references for scientometric analysis.

Our documentation on references includes the elements for both structured and unstructured data. Including the DOI in the structured data is best practice as it provides a precise location with rich data for matching. If the matcher does not see a link between the deposited DOI and the cited DOI at the time of deposit, then the references are stored to be crawled with other matching algorithms later. So, we’re always working to create those rich cited-by linkages between works (raising the content’s profile and overall discoverability), no matter when you register reference metadata. You can also see how your publisher is doing on depositing references by viewing their Participation Report. If you are an author, you can check if your DOIs that were registered contained any references by using our REST API. Don’t see them? You can always contact the editor of the journal or the publisher that published your paper and ask them to add them. Didn’t hear back? Just drop us a line in the Community Forum, we’re happy to help.

Shayn, Technical Support Specialist

Let’s ‘zoom out’ to the big picture. What are DOIs for? What makes them useful? What are we all doing here anyway?!

There are a lot of different answers to those questions. It’s a complex picture. But, way back in the late ‘90s, the DOI system was designed in order to allow for the creation of unique and persistent identifiers. Crossref members use these identifiers to represent their research outputs and publications. This allows for reliable linking to those items, and the ability to identify and communicate the relationships between them, notably (but not exclusively!) citation relationships.

So, what do we mean when we say that Crossref DOIs should be unique and persistent? In basic terms, unique means that there is only a single Crossref DOI registered for a given citable research output. And, persistent meaning that the DOI associated with a given research output today will continue to be associated with, and link to, that same research output indefinitely into the future.

Yes, there are some grey areas, and we know that everything doesn’t always work 100% perfectly all the time. But, the more deviations from persistence and uniqueness, the harder it becomes for end-users, publishers, Crossref, and other services which make use of our metadata to reliably find research outputs and reliably relate them to one another. It weakens the value and utility of DOIs for everyone.

So, what does this mean in practice?

Be certain that every item you register with Crossref is something you can maintain in the long-term.
- Have an arrangement with an archive that can take responsibility for your content if your organisation stops hosting it or ceases to exist.
- Don’t register things that you know will only exist for a short time.
When you’re about to register new content, be absolutely sure that it hasn’t been registered already, either by your organisation or any other organisation.
- If you acquire a new journal from another publisher, have a process in place to check what content has already been registered and adopt the use of the DOIs registered by the prior publisher for that content. We can always provide a list of the existing DOIs for a journal.
- If you publish books, and have a co-publishing agreement with another publisher, distributor, or hosting platform, be aware that one of those other parties may have already registered DOIs for your books. Adopt the use of those DOIs rather than assigning and registering new ones. And, if you don’t want them to do that going forward, communicate that to your co-publishing partners.
When mistakes happen, inadvertently resulting in duplicate DOIs for a single item, identify them quickly. Alias the new duplicate DOI to the long-standing original DOI, and remove all instances of the new DOI from your website or platform.
Ensure that your publishing software, platform, or journal management system can accommodate DOIs with various prefixes for the same publication. You should be able to use (display, link, update metadata and URLs for) the DOIs registered for older content by any prior publishers as easily as you use the DOIs that you registered yourself for more recent content.

Things like persistence and uniqueness can sound like theoretical abstractions, but they actually play an important role in the day-to-day grind of your publishing operations. Their impact on linking, citing, discovery, and analysis of your content is concrete and important. Thus, it’s not surprising that we often hear from members and others in the research community who share this commitment to persistence, uniqueness, and overall rich, accurate metadata. You’ll see that play out in the Community Forum where members and users get involved to troubleshoot issues, compare notes, and share ideas with us and one another. We appreciate the commitment to the Research Nexus and the overall spirit to serve in this growing community. Like we said at the top, we’re all wired to contribute in this way, so building an open, welcoming space that moves us forward excites us.

Again, we invite you to join the discussion on this and many other Crossref-related topics over in our Community Forum.

Shooting for the stars – ASM’s journey towards complete metadata

Kornelia Korzec — Tue, 14 Mar 2023 00:00:00 +0000

At Crossref, we care a lot about the completeness and quality of metadata. Gathering robust metadata from across the global network of scholarly communication is essential for effective co-creation of the research nexus and making the inner workings of academia traceable and transparent. We invest time in community initiatives such as Metadata 20/20 and Better Together webinars. We encourage members to take time to look up their participation reports, and our team can support you if you’re looking to understand and improve any aspects of metadata coverage of your content.

In 2022, we have observed with delight the growth of one of our members from basic coverage of their publications to over 90% in most areas, and no less than 70% of the corpus is covered by all key types of metadata Crossref enables (see their own participation report for details). Here, Deborah Plavin and David Haber share the story of ASM’s success and lessons learnt along the way.

Could you introduce your organisation?

The American Society for Microbiology publishes 16 peer-reviewed journals advancing the microbial sciences, from food microbiology, to genomics and the microbiome, comprising 14% of all microbiology articles. Six of those are open-access journals, and 56% of ASM’s published papers are open access. Together, our journals contribute 25% of all microbiology citations.

Would you tell us a little more about yourselves?

DH: David Haber, Publishing Operations Director at the American Society for Microbiology. I live in a century-old house that is in a perpetual state of renovation due to my inability to stop starting new projects before I complete old ones.

DP: Deborah Plavin, Digital Publishing Manager at the American Society for Microbiology. Following David’s example, my apartment in Washington D.C. is just up the block from one of the homes Duke Ellington lived in https://www.hmdb.org/m.asp?m=142334.

What value do society publishers in general see in metadata in your view?

DP: In my view, robust metadata allows publishers to look at changes over time, do comparative analysis within and across research areas, more easily identify trends, and plan for future analysis (e.g., if we deposit data citation information and we change our processes to make it more straightforward, do we see any change in the percentage of articles that include that information, etc.).

DH: To echo Deborah’s point, to be able to name something distinctly and clearly identify its specific attributes is vital to understanding past research and planning for future possibilities. One of our fundamental roles as a publisher for a non-profit society is to properly lay this metadata foundation so that we can provide services and new venues for our members, authors, and readers that match their needs and track with the trends in research. Without good and robust metadata, it is impossible to truly understand the direction in which our community is pointing us.

Metadata for your own research outputs in the last year has grown rapidly. Why such focus on metadata in 2022?

DP: This is something that ASM has been chipping away at over time. Years ago we found that it wasn’t always easy to take advantage of deposits that included new kinds of metadata. That was either because we needed to work out how and where to capture it in the process or because platform providers weren’t always ready — coming up with ways to process the XML that publishers supply in many different ways takes time. These back-end processes that feed the infrastructure aren’t usually of great interest to stakeholders, and so it allowed us to play around, flounder, fail, refine, and try again.

We looked at having 3rd parties deposit metadata for us, and while that helped expand the kind of metadata we were delivering, it created workflow challenges of its own. What turned out to be most effective was budgeting for content cleanup projects and depositing updated and more robust metadata to Crossref.

We also benefited from a platform migration, which allowed us to take advantage of additional resources during that process.

DH: Coming from a production background, I have always been fascinated with the when and how of capturing key metadata during the publishing process. When are those data good and valuable, and when should they be tossed or cleaned up for downstream deliveries? Because Deborah and ASM directors saw a more complete Crossref metadata set for our corpus as a truly valuable target, we were able to really think hard about what kind of data we were capturing and when, how those requirements may have influenced our various policies and copyediting requirements over the years, and how best to re-engineer our processes with the goal of good metadata capture throughout our publishing workflows. From our perspective, Crossref gave us a target, a “this-is-cool-bit-of-info" that Crossref can collect in a deposit; therefore, how can we capture that during our processes while driving further efficiencies? ASM journals had been so driven by legacy print workflows that such a change in perspective (toward metadata as a publishing object) really allowed us to re-imagine almost everything we do as a publisher.

Has the OSTP memo influenced your effort?

DP: I think that the Nelson memo hasn’t changed our focus; instead, I think it’s been another data point supporting our efforts and work in this area.

DH: Deborah is exactly right. The release of this memo only re-affirmed our commitment to creating complete and rich metadata. The Nelson memo points to many possible paths forward, in terms of both Open Access and Open Science, but we feel our work on improving our metadata outputs positions us well to pick a path that best suits our goals as a non-profit society publisher.

How big was this effort? Could you draw us a picture of how many colleagues or parts of the organisation were involved? Did you involve any external stakeholders, such as authors, editors, or others?

DH: It was simple. Took five minutes… In all seriousness, the key is having the support of the organisation as a whole. To do this properly, it is vitally important to know the end from the beginning, so to speak. It is one thing to say let’s start capturing ORCID IDs and deliver them to Crossref, but it is completely another to create a cohesive process in which those IDs are authenticated and validated throughout the workflow. So something as simple as a statement “ORCID IDs seem cool, let’s try to capture them” could affect how researchers submit files, how reviewers log into various systems (i.e., ORCID as SSO), how data are passed to production vendors, what copyeditors and XML QC people need to be focused on, and what integrations authors may expect at the time of publication. Being part of an organisation that embraced such change allowed us to proceed with care with each improvement to the metadata we made.

But that is more about incremental improvement. The beginning of this process started when we were making upgrades to our online publishing platform, and we were trying to figure out how best to get DOIs registered for our older content. When we started looking at this, we soon realized that, sure, we could do the bare minimum and just assign DOIs to this older content outside the source XML/SGML, but did that make sense? Wouldn’t it make more sense, especially since we were updating the corpus to a new DTD, to populate the source content with these newly assigned DOIs? Once we decided that we were going to revise the older content with DOIs, it made sense for us to create a custom XSL transform routine to generate Crossref deposits that would capture as much metadata as possible. So, working with a vendor to clean and update our content for one project (an online platform update) allowed us also to make massive improvements to our Crossref metadata as a side benefit.

Of course, I do have to apologize to the STM community for the Crossref outages in late 2019. That was just me depositing thousands of records in batches one sleepless night.

What were the key challenges you encountered in this project, and how did you overcome them?

DH: Resources and time are always an issue. Much of the work was done in-house in spare moments captured here and there. But there are great resources in github and at Crossref to help focus on defining what is important and what is possible in such a project. And, honestly, defining what was important and weighing that against the effort to find said important bit in the corpus of articles we have was the most challenging part of this process. In other words, limiting the focus. Once one decides to start looking at the inconsistencies in older content, it is hard not to say: “Oh, look. That semi-important footnote was treated as a generic author note rather than a conflict-of-interest statement; let’s fix that.” Once you start down that path, you can spend years fiddling with stuff. For me, a key mantra was: “We now have access to the content. We can always do another Crossref metadata update if things change or shift over time.”

Have there been any important milestones along the way you were able to celebrate? Or any set-backs you had to resolve in the process?

DP: For as long as I can remember, the importance of good metadata has been among the loudest messages of best practice in the industry. I don’t think that I have been able to really quantify/ demonstrate the value of that work. Looking at the consistent increases in the Crossref monthly resolution reports that we saw between 2015 and 2022 and looking at our participation reports has helped provide some measure of progress. For example, the number of average monthly successful resolutions in that Crossref report in 2015 was ~390,000. The last time I checked, the 2022 numbers were ~ 3.7 million. In 2023, I hope that we will be able to leverage Event Data for this as well.

The setbacks have fallen into two categories: timing and process. Our internal resourcing to get this done within our preferred time frame, to have the content loaded and delivered, and triage problems—it’s a battle between the calendar and competing priorities.

DH: When Deborah first shared those stats with me, I was floored. I don’t think either of us suspected such an increase was possible. For me, the biggest setback was mistakenly sending about ~50,000 DOI records to queue and watching them all fail because I grabbed the wrong batch. Ooops. I never made that mistake again, though.

Was any specific type of metadata or any part of the schema particularly easy or particularly difficult to get right in ASM’s production process?

DH: For us, the most difficult piece of metadata revolves around data availability and how we capture linked data resources (outside of data citation resources). Because of our current editorial style (which had been print-centric for years), we did not do a good job of identifying whether there are data associated with published content in a consistent machine-readable way. We did some experiments with one of our journals to capture this outside of our normal Crossref deposit routine, but that was not as accurate or sustainable as we would have liked. But, in that experiment, we learned a few things about how we treat these data throughout our publishing process and we have plans to create a sustainable integrated workflow for this to capture resource/data linkages in our Crossref deposits.

What were your thoughts on last year’s move to open references metadata? Has that impacted on your project in any way?

DP: We were really excited about this; based on the rather limited approach to sorting out impact at the moment, the more metadata we push out into the ecosystem, the more it appears to be used. In my view, that is at the core of what society publishers want to do—ensure that research is accessible and discoverable wherever our users expect to find it.

DH: 100% agree.

How did you keep motivated and on-course throughout?

DP: These kinds of things are never done; for example, we have placeholders for CRediT roles, and getting ready for that work as part of a DTD migration will be the next big thing. The motivation for that is really meeting our commitment to the community, seeing the impact of the author metadata versus article metadata, and seeing what we can learn.

DH: Metadata at its core is one of the pillars of our service as a publisher. To provide the best service, we need to provide the best metadata possible. Just remembering that this can be incremental, allows us to celebrate the large moments and the small. And whether one is partying with a massive 7 layer cake or a smaller cake pop, both are sweet and motivating.

Now that the project is completed, are you seeing the benefits you were hoping to achieve?

DP: This is a hard one to answer as we are using limited measurements at this time. At a high level, I am pleased. While I am eager to leverage event data in the coming year, it would be really helpful to get feedback from the community on how we can improve as well as other ways to evaluate impact.

DH: I want to take up this idea of metadata as a service once more. I don’t mean in terms of discoverability or searchability, either. Let’s take ORCID deposited into Crossref as an example. When done properly (with the proper authentication and validation occurring in the background), we are able to integrate citation data directly to an author’s ORCID profile. We have found that this small service is really appreciated.

Is there any metadata that you’d like to be able to include with your publishing records in the future that isn’t possible currently? What would it be and why?

DP: CRediT roles would be great because it could give greater insight into collaboration within and across disciplines, it could allow for some automation and integration opportunities in the peer review process, and maybe it would visualize aspects of authors’ careers.

DH: I second capturing CRediT roles. What would be really interesting is also creating a standard that quantifies the accessibility conformance/rating of content and passing that into Crossref.

What was the key lesson you learned from this project?

DP: Incremental change can be just as challenging as a massive overhaul, and so it’s important to reevaluate your goals along the way—things always change. There have been cases where we were able to do things that we hadn’t initially thought were feasible.

DH: Always keep the larger goal in mind and remember that any project can birth a new project. Everything does not happen at once.

What’s your next big challenge for 2023?

DP: There is a lot to contend with in the industry right now, and in addition to that we are going through some serious infrastructure changes in our program. With all that madness comes many opportunities. For that reason, when I take a step back from the tactical implications of all that and what we are interested in doing, I think our biggest challenge in 2023 will be identifying what has made an impact and why.

DH: In the short-term, it is making sure that none of our production process changes has negatively affected the past metadata work we spent so much time honing. Once that settles down, it will be determining the best way forward from a publishing perspective in handling true versioning and capturing accurate event data.

Based on your experience, what would be your advice for colleagues from other scholarly publishing organisations?

DP: It can seem daunting, but the small wins can create momentum and do not have to be expensive. Remembering that your publishing program benefits as much as everyone else’s when you deposit more metadata can help refine your short-term and long-term priorities.

DH: Don’t be afraid of making a mess of things. Messes are okay. They aren’t risky. They just reveal the clutter. And clutter gives one reason to clean things up.

THANK YOU for the interview!

About the American Society for Microbiology

The American Society for Microbiology is one of the largest professional societies dedicated to the life sciences and is composed of 30,000 scientists and health practitioners. ASM’s mission is to promote and advance the microbial sciences.

ASM advances the microbial sciences through conferences, publications, certifications and educational opportunities. It enhances laboratory capacity around the globe through training and resources. It provides a network for scientists in academia, industry and clinical settings. Additionally, ASM promotes a deeper understanding of the microbial sciences to diverse audiences. For more information about ASM visit asm.org.

Flies in your metadata (ointment)

Isaac Farley — Mon, 25 Jul 2022 00:00:00 +0000

Quality metadata is foundational to the research nexus and all Crossref services. When inaccuracies creep in, these create problems that get compounded down the line. No wonder that reports of metadata errors from authors, members, and other metadata users are some of the most common messages we receive into the technical support team (we encourage you to continue to report these metadata errors).

We make members’ metadata openly available via our APIs, which means people and machines can incorporate it into their research tools and services - thus, we all want it to be accurate. Manuscript tracking services, search services, bibliographic management software, library systems, author profiling tools, specialist subject databases, scholarly sharing networks - all of these (and more) incorporate scholarly metadata into their software and services. They use our APIs to help them get the most complete, up-to-date set of metadata from all of our publisher members. And of course, members themselves are able to use our free APIs too (and often do; our members account for the vast majority of overall metadata usage).

We know many organisations use Crossref metadata. We highlighted several different examples in our API case study blog series and user stories. Now, consider how errors could be (and often are) amplified throughout the whole research ecosystem.

While many inaccuracies in the metadata have clear consequences (e.g., if an author’s name is misspelled or their ORCID iD is registered with a typo, the ability to credit the author with their work can be compromised), there are others, like this example of typos in the publication date, that may seem subtle, but also have repercussions. When we receive reports of metadata quality inaccuracies, we review the claims and work to connect metadata users with our members to investigate and then correct those inaccuracies.

Thus, while Crossref does not update, edit, or correct publisher-provided metadata directly, we do work to enrich and improve the scholarly record, a goal we’re always striving for. Let’s look at a few common examples and how to avoid them.

Pagination faux pas

First page marked as 1

In the XML registered

<pages>
<first_page>1</first_page>
<last_page>1</last_page>
</pages>

https://api-crossref-org.pluma.sjfc.edu/works?filter=type:journal-article&select=DOI,title,issue,page&sample=100

Other pagination errors

In the XML registered

<item_number item_number_type="article-number">1</item_number>

In the XML registered

<pages>
<first_page>121-123</first_page>
<last_page>129</last_page>
</pages>

Author naming lapses

Examples: Titles (Dr., Prof. etc.) in the given_name field; Suffixes (Jr., III, etc.) in the surname field; superscript number, asterisk, or dagger after author names (usually carried over from website formatting that references affiliations); full name in surname field

In the XML registered

<contributors>
<person_name sequence="first" contributor_role="author">
<given_name>DOCTOR KATHRYN</given_name>
<surname>RAILLY</surname>
</person_name>
<person_name sequence="additional" contributor_role="author">
<given_name>DOCTOR JOSIAH S.</given_name>
<surname>CARBERRY</surname>
</person_name>
</contributors>

<contributors>
<person_name contributor_role="author" sequence="first">
<surname>Mahmoud Rizk</surname>
</person_name>
<person_name contributor_role="author" sequence="additional">
<surname>Asta L Andersen(</surname>
</person_name>
</contributors>

organisations as authors slip-ups

Examples: The contributor role for person names is for persons, not organisational contributors, but we see this violated from time to time. Unfortunately, no persons are being credited with contributing to content that have these errors present in the metadata record.

In the XML registered

<contributors>
<person_name sequence="first" contributor_role="author">
<surname>Society</surname>
</person_name>
</contributors>

<person_name contributor_role="author" sequence="first">
<given_name>University of Melbourne</given_name>
<surname>University of Melbourne</surname>
</person_name>
</contributors>

Null no-nos

Examples: Too many times we see “N/A”, “null”, “none” in various fields (pages, authors, volume/issue numbers, titles, etc.). If you don’t have or know the metadata, it’s better to omit it for optional metadata elements than to include inaccuracies in the metadata record.

In the XML registered

<journal_volume>
<volume>null</volume>

<pages>
<first_page>null</first_page>
<last_page>null</last_page>
</pages>

<person_name sequence="first" contributor_role="author">
<given_name>Not Available</given_name>
<surname>Not Available</surname>
</person_name>
<person_name sequence="additional" contributor_role="author">
<given_name>Not Available</given_name>
<surname>Not Available</surname>
</person_name>

Where to go from here?

One thing we’ve said throughout this blog that we’ll reiterate here is: accurate metadata is important. It’s important in itself, and the metadata registered with us is heavily used by many systems and services, so think Crossref and beyond. In addition to that expanding perspective, there are practical steps members and metadata users can take to help us:

As a member registering metadata with us:

make sure we have a current metadata quality contact for your account and update us if there’s a change
if you receive an email request from us to investigate a potential metadata error, help us
if you do not know what to enter into a metadata element or helper tool field, please leave it blank; perhaps some of the examples of errors within this blog were placeholders that the responsible members intended to come back to - to correct in time; that’s also a practice to avoid
if you find a record in need of an update, update it - updates to existing records are always free (we do this to encourage updates and the resulting accurate, rich metadata, so take advantage of it).

As a metadata user:

if you spot a metadata record that doesn’t seem right, let us know with an email to support@crossref.org and/or report it to the member responsible for maintaining the metadata record (if you have a good contact there)
if you’re eager to confirm the last update of a metadata record, our REST API is a great resource; here’s a handy query to use as a starting point: this one returns records on our Crossref prefix 10.5555 that have been updated in 2022: https://api-crossref-org.pluma.sjfc.edu/prefixes/10.5555/works?rows=500&filter=from-update-date:2022-01-01,until-pub-date:2022-12-31&mailto=support@crossref.org

Making connections between research objects is critical, and inaccurate metadata complicates that process. We’re continually working to better understand this, too. That’s why we’re currently researching the reach and effects of metadata. Our technical support team is always eager to assist in correcting errors. We’re also keen on avoiding those mistakes altogether, so if you are uncertain about a metadata element or have questions about anything included in this blog post, please do contact us at support@crossref.org. Or, better yet, post your question in the community forum so all members and users can benefit from the exchange. If you have a question, chances are others do as well.

Hiccups with credentials in the Test Admin Tool

Isaac Farley — Wed, 26 Jan 2022 00:00:00 +0000

TL;DR

We inadvertently deleted data in our authentication sandbox that stored member credentials for our Test Admin Tool - test.crossref.org. We’re restoring credentials using our production data, but this will mean that some members have credentials that are out-of-sync. Please contact support@crossref.org if you have issues accessing test.crossref.org.

2025 update

We’re working to scale back our support for the test admin tool. We will continue to support our XML parser for anyone wanting to test their XML. If you’re a service provider and would like to test your integrations, which we will continue to support, you may POST submissions to our test system using https://test-crossref-org.pluma.sjfc.edu/servlet/deposit. You’ll need to email us at support@crossref.org so we can configure an account within the test system before you test your integration.

The details

Earlier today the credentials in our authentication sandbox were inadvertently deleted. This was a mistake on our end that has resulted in those credentials no longer being stored for our members using our Test Admin Tool - test.crossref.org.

To be clear, this error has had no impact on the production Admin Tool - doi.crossref.org - or any member’s access to registering content therein. If you’re a member who registers content with us using our helper tools (e.g., the web deposit form) or OJS, you’re likely unfamiliar with the Test Admin Tool, and this issue will not affect you or your registration of content.

We don’t configure all member accounts for the Test Admin Tool, so, fortunately, this is an issue for the minority of our members. That said, for those members who do use the Test Admin Tool, this is not a trivial problem. And, we’re going to dedicate additional resources across the organisation to ensure it is fixed.

Next steps

We’ve repopulated the credentials in the Test Admin Tool based on our production accounts. It was our best option. While we don’t know your current credentials, our support and membership teams do know that the majority of our members using the Test Admin Tool have historically shared credentials between the Test Admin Tool and our production Admin Tool - doi.crossref.org. That means that many of you will be able to access the Test Admin Tool using those shared credentials; but some of you - who have used different credentials between the two systems - will not.

We also know that for many of you testing submissions is an integral step in your workflow, so we’ve determined this is an all-hands-on-deck situation and our staff, across the organisation, will be assisting members who have issues with access to test.crossref.org. Starting today, we’re actively monitoring submissions to the Test Admin Tool for access errors through Friday, 11 February. We’ll be proactively contacting affected members to reset their passwords. If you encounter problems before we reach out to you, please do contact us at at support@crossref.org and include ‘Accessing Test Admin Tool’ in your subject line.

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…

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.

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.

Open Abstracts: Where are we?

Ludo Waltman — Fri, 25 Sep 2020 00:00:00 +0000

The Initiative for Open Abstracts (I4OA) launched this week. The initiative calls on scholarly publishers to make the abstracts of their publications openly available. More specifically, publishers that work with Crossref to register DOIs for their publications are requested to include abstracts in the metadata they deposit in Crossref. These abstracts will then be made openly available by Crossref. 39 publishers have already agreed to join I4OA and to open their abstracts.

Where are we at the moment in terms of openness of abstracts? For an individual publisher working with Crossref, the percentage of the publisher’s content for which an abstract is available in Crossref can be found in Crossref’s Participation Reports. The chart presented below gives the overall picture (as of September 1, 2020) for medium-sized and large publishers working with Crossref. The vertical axis shows the number of journal articles of a publisher in the period 2018-2020. Because of the large differences between publishers in the number of articles they publish, this axis has a logarithmic scale. The horizontal axis shows the percentage of the articles of a publisher for which an abstract is available in Crossref. The orange dots represent publishers that have agreed to join I4OA. The publishers colored in blue have not yet agreed to join the initiative.

A similar chart was published a few months ago in this blog post on the importance of open abstracts. Comparing the above chart with the one published a few months ago, the first effects of I4OA are already visible. While for most publishers the percentage of abstracts available in Crossref has hardly changed, it has increased from 11% to 95% for the Royal Society, one of the founding publishers of I4OA. This reflects the efforts the Royal Society has made over the past months to improve the availability of abstracts in Crossref for its content, not only for new content but also for existing content. For SAGE, another founding publisher of I4OA, the percentage of abstracts available in Crossref has increased from 38% to 50%. A further increase can be expected to take place in the coming months. The third founding publisher of I4OA, Hindawi, has remained at a stable level, with abstracts being available for 97% of its content.

The above chart shows that many publishers supporting I4OA are already making abstracts available in Crossref. Other publishers do not yet make abstracts available in Crossref but have nevertheless decided to join I4OA. This is the case for Frontiers, PLOS, and Karger, and also for several smaller publishers not visible in the above chart, such as EMBO and Ubiquity Press. These publishers are currently adjusting their workflows and will start submitting abstracts to Crossref soon.

Of the publishers that have not yet joined I4OA, some may not yet be aware of I4OA, while others may need more time to decide whether they will join the initiative. As can be seen in the above chart, most publishers that have not yet joined I4OA do not make abstracts available in Crossref at the moment. However, some publishers have not yet joined I4OA even though they do make abstracts available in Crossref. We hope these publishers will join I4OA soon. By joining the initiative, these publishers would formalize their commitment to openness of abstracts.

None of the publishers in the above chart makes abstracts available in Crossref for 100% of its journal content. Some publishers, such as Copernicus and Hindawi, are close to 100%, but even these publishers have some content for which no abstract is available. Importantly, this does not necessarily mean that publishers have failed to submit abstracts to Crossref for some of their content. Instead, it may simply mean that some of their journal content does not have an abstract. Research articles usually have an abstract, but many other types of content published in journals, such as book reviews, letters, editorials, and corrections, often do not have an abstract. For most publishers, it is therefore impossible to make abstracts available for 100% of their content. Moreover, since Crossref does not distinguish between different types of content published in journals, we cannot provide separate statistics on the availability of abstracts for different types of journal content.

As an example, let’s consider Brill, a publisher that has joined I4OA and that mainly focuses on the humanities and social sciences. Abstracts are available in Crossref for 57% of Brill’s content in the period 2018-2020. This may suggest that Brill has failed to submit abstracts to Crossref for a significant share of its content. However, when we look up journal publications of Brill in 2018 and 2019 in the Web of Science database, abstracts turn out to be available for only 68% of these publications. Assuming that Web of Science has more or less complete coverage of abstracts, this seems to indicate that Brill has already submitted most of its abstracts to Crossref. In fact, Web of Science shows that about a quarter of the publications of Brill are book reviews and that hardly any of these book reviews has an abstract. This illustrates why some publishers, for instance those that publish many book reviews, cannot be expected to get close to 100% availability of abstracts.

Despite the above caveats, it is clear that there is still a long way to go in improving the availability of abstracts in Crossref. As of September 1, 2020, abstracts were available for 21% of all journal articles in Crossref in the period 2018-2020. In Web of Science (Science Citation Index Expanded, Social Sciences Citation Index, and Arts & Humanities Citation Index), 86% of all journal publications in 2018 and 2019 that have a DOI also have an abstract.

Publishers who wish to distribute their abstracts openly through Crossref can include them in the normal content registration process. They can send XML to Crossref (using Crossref’s metadata deposit schema), either directly via HTTPS POST or via the Crossref admin system. For back-content, a resubmission of the full XML is required. In addition, various tools can be used to deposit abstracts. Open Journal Systems (OJS) has a plugin that supports the depositing of abstracts. Metadata Manager also facilitates this, but only for journal articles. Crossref’s web deposit form does not yet support abstracts, but Crossref is working on this.

To keep track of the progress publishers are making in depositing abstracts in Crossref, we plan to publish regular updates of the chart presented above on the I4OA website. We look forward to witnessing the impact of I4OA in the coming months!

Thank you to guest authors Bianca Kramer and Ludo Waltman, as well as the other founding members of I4OA.

Get involved with Peer Review Week 2020 and register your peer reviews with Crossref

Amanda Bartell — Mon, 21 Sep 2020 00:00:00 +0000

Just when you thought 2020 couldn’t go any faster, it’s Peer Review week again! Peer Review is such an important part of the research process and highlighting the role it plays is key to retaining and reinforcing trust in the publishing process.

As the Peer Review Week team states:

“Maintaining trust in the peer review decision-making process is paramount if we are to solve the world’s most pressing problems. This includes ensuring that the peer review process is transparent (easily discoverable, accessible, and understandable by anyone writing, reviewing, or reading peer-reviewed content) and that everyone involved in the process receives the training and education needed to play their part in making it reliable and trustworthy.”

A key way that publishers can make peer reviews easily discoverable and accessible is by registering them with Crossref - creating a persistent identifier for each review, linking them to the relevant article, and providing rich metadata to show what part this item played in the evolution of the content. It also gives a way to acknowledge the incredible work done by academics in this area.

For Peer Review week last year, Rosa and Rachael from Crossref created this short video to explain more.

Fast forward to 2020 and over 75k peer reviews have now been registered with us by a range of members including Wiley, Peer J, eLife, Stichting SciPost, Emerald, IOP Publishing, Publons, The Royal Society and Copernicus. We encourage all members to register peer reviews with us - and you can keep up to date with everyone who is using this API query. (We recommend installing a JSON viewer for your browser to view these results if you haven’t done so already).

Register peer reviews and contribute to the Research Nexus

At Crossref, we talk a lot about the research nexus, and it’s a theme that you’re going to hear a lot more about from us in the coming months and years.

The published article no longer has the supremacy it once did, and other outputs - and inputs - have increasing importance. Linked data and protocols are key for reproducibility, peer reviews increase trust and show the evolution of knowledge, and other research objects help increase the discoverability of content. Registering these objects and stating the relationships between them support the research nexus.

Peer reviews in particular are key to demonstrating that the scholarly record is not fixed - it’s a living entity that moves and changes over time. Registering peer reviews formally integrates these objects into the scholarly record and makes sure the links between the reviews and the article both exist and persist over time. It allows analysis or research on peer reviews and highlights richer discussions than those provided by the article alone, showing how discussion and conversation help to evolve knowledge. In particular, post-publication reviews highlight how the article is no longer the endpoint - after publication, research is further validated (or not!) and new ideas emerge and build on each other. You can see a real-life example of this from F1000 in a blog post written by Jennifer Lin a few years ago.

As we’ve said before:

Article metadata + peer review metadata = a fuller picture of the evolution of knowledge

Registering peer reviews also provides publishing transparency and reviewer accountability, and enables contributors to get credit for their work. If peer review metadata includes ORCID IDs, our ORCID auto-update service means that we can automatically update the author’s ORCID record (with their permission), while our forthcoming schema update will take this even further, making CRediT roles available in our schema.

How to register peer reviews with Crossref

You need to be a member of Crossref in order to register your peer reviews with us and you can currently register peer reviews by sending us your XML files. Unfortunately, you can’t currently register peer reviews using our helper tools like the OJS plugin, Metadata Manager, or the web deposit form.

You can find out more about registering peer reviews on our website - we even have a range of markup examples.

We know that there’s a range of outputs from the peer review process, and our schema allows you to identify many of them, including referee reports, decision letters, and author responses. You can include outputs from the initial submission only, or cover all subsequent rounds of revisions, giving a really clear picture of the evolution of the article. Members can even register content for discussions after the article was published, such as post-publication reviews.

Get involved with Peer Review Week 2020

We’re looking forward to seeing the debate sparked by Peer Review Week and hearing from our members about this important area. You can get involved by checking out the Peer Review Week 2020 website or following @PeerRevWeek and the hashtags #PeerRevWk20 #trustinpeerreview on Twitter.

We’re excited to see what examples of the evolution of knowledge will be discoverable in registered and linked peer reviews this time next year!

Memoirs of a DOI detective...it’s error-mentary dear members

Paul Davis — Mon, 27 Apr 2020 00:00:00 +0000

Hello, I’m Paul Davis and I’ve been part of the Crossref support team since May 2017. In that time I’ve become more adept as a DOI detective, helping our members work out whodunnit when it comes to submission errors.

If you have ever received one of our error messages after you have submitted metadata to us, you may know that some are helpful and others are, well, difficult to decode. I’m here to help you to become your own DOI detective.

Motive: ridding the world of bad metadata

When depositing xml files to us, there can be a plethora of error messages returned to you in the submission logs. Wait, what are submission logs? If that is the first thing that came to mind, then you’re in the right place; do keep reading.

Means: XML deposits

After each content registration or update is received into our deposit admin system, it is initially placed in the submission queue and later, once its time comes, is processed. Whether that deposit comes from the web deposit form, Metadata Manager, or a good old fashioned XML deposit, a submission log is created in our system. This log contains important information about the deposit and its success or failures.

I will go through how you will find and receive this log later on. At the bottom of the submission log you will see a status message that looks like this:

 <batch_data>
<record_count>***</record_count>
<success_count>***</success_count>
<warning_count>***</warning_count>
<failure_count>***</failure_count>
</batch_data>

To some, this might look a bit like a crime scene. If the status report displays the same number in the <record_count> and the <success_count>, then no crime (against deposits) has been committed. Everything you have tried to register or update has been successful and we are all free as DOI detectives to knock off early.

At some point you will probably come across an error or failure in the submission logs, where the failure count is 1.

 <batch_data>
<record_count>1</record_count>
<success_count>0</success_count>
<warning_count>0</warning_count>
<failure_count>1</failure_count>
</batch_data>

For the purposes of this blog, this type of message means a “crime” has been committed. The worst kind of crime - a metadata crime. In the real world, outside of this blog, it just means that your deposit has failed and you need to take some action to fix it. You will also receive accompanying error messages (an evidence log) with details about what went wrong with your submission. We’ll deliver these submission details to you as well in the following ways:

For those submitting via the web deposit form, to the email address used to register your submission
On screen and within the admin tool using the submission ID for those submitting via Metadata Manager
For those submitting XML, to the email included in the <email_address> element of your deposit XML
You can also find the submission log in the admin system at any point

More information on viewing past deposits in the admin system can be found on our support site.

The usual suspects

Those serial offenders, when it comes to failed deposits, are:

Timestamps

Misdemeanor - Every deposit has a <timestamp> value, and that value needs to be incremented each time the DOI is updated. This is done automatically for you in Metadata Manager, the Web Deposit Form and the OJS plugin. But if you’re updating an existing DOI by sending us the whole XML file again, you need to make sure that you update the timestamp as well as the field you’re trying to update.

Error: <msg>Record not processed because submitted version: 201907242206 is less or equal to previously submitted version 201907242206</msg>

Rehabilitation - simply resubmit your XML file, but make sure that you increment the timestamp value to be larger than the current timestamp value.

Titles

Misdemeanor - These need to match exactly between what we have on the system against the ISSN/ISBN and what is in the deposit file.

Error: <msg>Deposit contains title error: the deposited publication title is different than the already assigned title</msg>

Error: <msg>ISSN "123454678" has already been assigned, issn (123454678) is assigned to another title (Journal of Metadata)</msg>

Rehabilitation - you can check the title we have on the system against the ISSN/ISBN on the title list and make the necessary changes, or contact support for us to check the title in our system and make changes to match the title in the deposit to the one in the system, if known.

Title level DOIs

Misdemeanor - These also need to match up exactly in both system and deposit

Error: <msg>Deposit contains title error: The journal has a different DOI assigned; If you want to change the journal's DOI please contact Crossref support: title=Journal of Metadata; current-doi=10.14393/JoM; deposited-doi=10.14393/JoM.1.1</msg>

Rehabilitation - contact us to change the journal level DOI in the system or change the DOI in the deposit yourself to match the one already registered for the title.

Errors in the xml

Misdemeanor - Poor formatting, self closing tags, invalid values.

Error: <msg>Deposited XML is not well-formed or does not validate: Error on line 538</msg>

Rehabilitation - update the xml file that was deposited as it was not well formed against our schema or as an xml file in general. Check you have saved the file correctly (as an .xml file), edited it in an xml editor and not a word processor and if that fails, then contact support and we will try to assist. We also have a collection of new xml examples you may use as a template.

Forensics

There are a few tools we offer to help with the deciphering of the error messages –– we think of these as our magnifying glass(es).

The Title list: A list of all of the titles in our database, you can check against the ISSN/ISBN to see what the title on our system is and whether it matches the title you have in your deposit.
The Depositor Report: Shows all journals, books, and conference proceedings against each member. The report includes all DOIs for each journal, book, conference; the most recently used timestamps; and citation counts for each DOI.
The Reports tab in the admin system: You can find out the history behind a DOI by searching against this in the admin console.
Our common error messages are documented within our support documentation. You can always find out more about most of the error messages are system displays at the link above.
You can find the current xml metadata against a DOI by adding the DOI to the end of this link http://doi.crossref.org.pluma.sjfc.edu/search/doi?pid=support@crossref.org&format=unixsd&doi= (you might need an xml viewer browser extension to view the xml in a more readable format).

Calling for backup

We’ll also soon be adding more leads to our submission logs and error messages for the best of our detectives. These improvements will point our DOI detectives to better documentation about interpreting error messages and taking the appropriate action to resolve those errors.

But there are a lot more error messages out there. If you have trouble deciphering any error message you encounter, then please do send the case number (submission ID) over to CSI (Crossref Support Investigations) at support@crossref.org.

You can also find lots of great information in the pages of our new documentation.

Changes to resolution reports

Isaac Farley — Fri, 10 Apr 2020 00:00:00 +0000

This blog is long overdue. My apologies for the delay. I promised you an update in February as a follow up to the resolution reports blog originally published in December by my colleague Jon Stark and me. Clearly we (I) missed that February projection, but I’m here today to provide said update. We received many great suggestions from our members as a result of the call for comments. For those of you who took time to write: thank you! We took extra time to review and evaluate all of your comments and recommendations. We have reached a decision about the major proposed change - removal of all filters from monthly resolution reports - as well as a couple of suggested improvements from that feedback.

Quick recap of our original blog

Jon wrote the original version of the resolution report in late 2009 in an effort to provide you, our members, with information about the usage of registered Crossref DOIs. At that time, Jon and others at Crossref thought it important to segment human-driven traffic from resolutions by machines (bots). Thus, we decided to filter out well-known machine activity in an attempt to only present you with resolutions by individual humans.

In the last ten-plus years things changed. We live in a time where most of our work requires both human and machine interaction. Therefore, we have hypothesized that some, or most, of those resolutions from machines today represent legitimate activity and should be reported to you each month. Since we don’t have a reliable method to segment those resolutions, and don’t think we should be making judgments about which resolutions should and should not be included in the reports, we proposed removing all filters and presenting you with all the numbers.

What we heard from you

In addition to soliciting comments in the blog, I also reached out to all of our members who had written into our support desk in the last year about anything related to resolution reports. We received dozens of responses from the blog and my outreach via email. The most common response was from members expressing their appreciation for and highlighting the utility of the reports. Most everyone told us how they were using the reports - from monitoring failure rates to mitigate issues to identifying trends over time. And a great number of respondents expressed concern that removing the filters might alter how or what we present to you in the reports (more on that soon). And, finally, several of you shared suggestions for improvement.

Where we go from here

Our existing filters have been removing between 100 and 150 million resolutions from the monthly numbers we report to all members, collectively. Based on those figures, when we remove the filters all resolutions numbers will increase by about 25%. Those increased resolutions will vary from member to member because the numbers are based on actual bots crawling specific content, so some members may see more of an increase than others. We are mindful of how our members might adjust to that new baseline, since these changes will mean a noticeable (and, significant) increase in resolution totals for the majority of our members.

Outside of the suggested tweaks from members below and that 25% increase I mentioned (due to the retirement of the filters), the reports will remain unchanged. You’ll continue to receive successful resolutions, the report of top 10 DOIs, and the csv file containing failed resolutions. Our most important consideration throughout this process is that these reports continue to serve you.

The changes

We liked some of your suggestions, so we’re set to adopt a few of the more straightforward improvements. Those that are more complicated we’re considering for the Member Center (working title, subject to change) project, where we will start to bring together all business and technical information for our members, service providers and metadata users.

As I said, we’re removing the filters. Starting in June, we’ll present all of the resolutions to you. No filters. On average, monthly resolution numbers will therefore increase by about 25%.
We currently link to the failed DOI.csv near the bottom of the resolution report. For many members with large volumes of content, the resolution report can take some time to load and sift through, so we’re moving the link to the failed DOI.csv file up the page (Note: we know they are other changes we can make to the report itself that will make it easier to work with for members with large volumes of data; we’re exploring those improvements).
We learned during this process that some members were not receiving resolution reports when they only had failed resolutions. One of the aims of the reports is to help members identify content registration problems, so this was a bug we are keen to repair. We are fixing it. Once it is fixed, all members who have at least one resolution - successful or failed - during the previous month will receive the report.

What we can’t change

Many members who responded to the call and who also enquire throughout the year (outside of this call) express interest in receiving more information from the resolution reports. You want resolution numbers for all your DOIs. You want referral information about where the resolutions are coming from (e.g., IP addresses) and breakdowns by machine/human. You want more information about how and why the failure rate is growing over time. We understand.

In the past, we did try to process more information for IP addresses and user agents but it turns out that generating that volume of extra data and processing monthly is simply impractical. The other issue is one of privacy. IP addresses are considered personally identifiable information (PII), or data that could potentially be used to identify particular people. We are committed to maintaining the privacy of our members and users and therefore cannot provide this level of granularity in our reports.

Next up

Look for these changes starting in June. If you read this far, you may not need it, but we’ll also include a reminder atop the report itself about the increase in resolution totals as a result of our changes.

You’ve had your say, now what? Next steps for schema changes

Patricia Feeney — Thu, 02 Apr 2020 00:00:00 +0000

It seems like ages ago, particularly given recent events, but we had our first public request for feedback on proposed schema updates in December and January. The feedback we received indicated two big things: we’re on the right track, and you want us to go further. This update has some significant but important changes to contributors, but is otherwise a fairly moderate update. The feedback was mostly supportive, with a fair number of helpful suggestions about details.

Feedback and changes

Many of you are excited about CRediT, and a number of members have indicated that they are ready and waiting to send us CRediT roles. To support this, as in my initial proposal, we’re adding a new role element and role_type attribute that supports existing Crossref-defined roles and CRediT roles, as well as a required vocab attribute to specify which vocabulary is being supplied.

<role role_type="author" vocab="crossref">author</role> <role role_type="writing-original_draft" vocab="credit"/>

CRediT as it exists now is an informal standard coordinated by CASRAI, but a formal standard is in the works via NISO. CRediT is currently a list of well considered and defined roles that are not particularly machine-readable. I’ve created a list for implementation that eliminates spaces and ampersands. CRediT also lacks reliable PIDs or persistent URLs for the role definitions, so that has been omitted from our implementation. We’ll adopt any changes resulting from the NISO standard, but have decided to go forward with it as-is, as many of our members are eager to implement.

Beyond CRediT, we’ll also be expanding and refining our contributor support in a number of ways:

We’ll be expanding our affiliation metadata beyond a simple string to include organisation identifiers like ROR, and allow markup of organisation names and locations.
We’re expanding the contributor identifiers as well - in addition to ORCID iDs, members can send us Wikidata, ISNI, and other identifiers.
We’re adding support for multiple names to support contributors whose names can be expressed in multiple alphabets, or who have aliases or nicknames.
We’re changing surname to family_name and will be relaxing the requirement that all person names have a “surname” - a given name may be supplied on its own to support contributors who do not have family names.
The current element for corporate/group authors, organisation, will be replaced by collab as the term “organisation” was widely confusing (we have a lot of affiliation info registered as group authors!), and the collab section will also allow organisation identifiers.

Many of these updates align with how JATS supports contributors - I hope these changes will allow our members to supply robust contributor metadata without the burden of complicated conversions.

I’m also including the proposed changes to support data citation and typing of citations. Additionally, we’ll be adding support for members who want to:

supply Grant IDs in their metadata records
register identifiers for conferences.

A draft 5.0 xsd file is available in a branch of our GitLab schema repository with the details of the planned updates, and more robust documentation and examples are forthcoming.

Implementation plans

My house was built in 1890 and there are always surprises whenever we need to fix or renovate anything. Our system is just as old in technology years - it’s been chugging along since the aughts. This means while we don’t think it’s powered by knob-and-tube wiring, we can’t be sure until we open up the walls. We want to implement our plans (in fact we want to do more!) but if we run into any big blockers or crucial issues, we may roll out the changes over several iterations. These updates are fairly conservative and I remain optimistic we’ll be able to implement them as-is. Our update will help us build a foundation for future updates, allowing us to continuously evolve our schema as we move forward.

Some of you are understandably worried about our implementation schedule and backwards incompatibility. We’re aware that changes are expensive and inconvenient, and making them on our schedule doesn’t always work for your schedule. That’s why we’ve sustained 12+ versions of our schema over the past 12 years. We won’t be mandating a change any time soon, and definitely won’t do so without sufficient warning and community involvement. In the future we’ll need to make a sustained effort to retire older schema, but now isn’t the time for that.

We intend to commence work in Q2 but won’t have a firm timeline for a few more weeks. I will be providing regular updates as we progress, and will be asking for volunteers to test the updates when we’re ready. I’ll also be sharing more documentation and information about how the changes will be represented in our metadata outputs.

Have more to say?

Our feedback period has finished and we do plan to implement the changes as described, but if you have opinions, please share them.

Encouraging even greater reporting of corrections and retractions

Kirsty Meddings — Mon, 30 Mar 2020 00:00:00 +0000

TL;DR: We no longer charge fees for members to participate in Crossmark, and we encourage all our members to register metadata about corrections and retractions - even if you can’t yet add the Crossmark button and pop-up box to your landing pages or PDFs.

–

Research doesn’t stand still; even after publication, articles can be updated with supplementary data or corrections. When research outputs are is changed in this way the publisher should report and link it, so that those accessing and citing the content know if it’s been updated, corrected or even retracted. This also emphasizes the member’s commitment to the ongoing stewardship of research outputs.

Many people find and store articles to read later, either as PDFs on their laptop or on one of any number of reference management systems - when they come back to read and cite these articles, possibly many months later, they want to know if the version they have is current or not.

Removing Crossmark fees

To encourage even wider adoption of Crossmark, and to promote best practice around better reporting of corrections and retractions, we will no longer be charging additional fees for our Crossmark service. This change applies to all Crossmark metadata registered from 1 January 2020. All members are now encouraged to add Crossmark metadata and add the Crossmark button and pop-up box to their publications - and you can do so as part of your regular content registration.

Richer metadata gives important context

We know that there are many more corrections and retractions that are not yet being registered, and to address this, we are now asking all of our members to start registering metadata for significant updates to your publications, even if you don’t implement the Crossmark button and pop-up box on your content. Remember, anyone can access the Crossmark metadata through our public REST API, and start using it straight away - even if you’re not ready to implement the Crossmark button.

Check out how to get started; if you only want to deposit metadata, follow steps one through four. If you also want to add the Crossmark button and pop-up box to your web pages/PDFs so that readers can easily see when content has changed, then also follow the rest of the steps.

Crossmark

We launched Crossmark in 2012 to raise awareness of these critical changes, by asking Crossref members to:

record such updates in your metadata, either as part of your regular Crossref metadata deposit, or deposited as stand-alone data for back-year records
help readers find out about the changes by placing a Crossmark button and pop-up box (which is consistent across all members making it recognizable to readers) on your landing pages and in PDFs

Members can also use Crossmark to register additional metadata about content, giving further context and background for the reader. These metadata appear in the “More Information” section of the Crossmark box. 7 million DOIs have some additional metadata, the most common being copyright statements, publication history, and peer review methods.

Anyone can access the Crossmark metadata through our public REST API, providing a myriad of opportunities for integration with other systems, and analysis of changes to the scholarly record.

Who has implemented Crossmark?

440 Crossref members have implemented Crossmark to date. 11.4 million DOIs have some Crossmark metadata.

	Total DOIs	DOIs with Crossmark metadata	%
Journal articles	80,862,460	10,155,340	12.56%
Book chapters	14,040,646	792,953	5.65%
Conference Papers	6,175,733	457,237	7.40%
Datasets	1,862,852	19,206	1.03%
Books	753,298	239	0.03%
Monographs	469,333	23	0.00%

Of those, about 130,000 contain an update:

You can see which members or journals have implemented Crossmark by viewing the relevant Crossref Participation Report.

Metadata Manager Update

Bryan Vickery — Tue, 24 Mar 2020 00:00:00 +0000

At Crossref, we’re committed to providing a simple, usable, efficient and scalable web-based tool for registering content by manually making deposits of, and updates to, metadata records. Last year we launched Metadata Manager in beta for journal deposits to help us explore this further. Since then, many members have used the tool and helped us better understand their needs.

What we’ve learned has made us realize how useful such a tool can be to both large and small publishers, but also that the approach we took with Metadata Manager needs to be changed - it’s not flexible enough to easily add other record types, like books/book chapters, or to include any changes we may make to our input schema.

With that in mind, we’re pausing development on Metadata Manager to allow us to properly evaluate what we’ve learned. If you’re currently using Metadata Manager for journal deposits without any problems, please do continue - you’re helping us learn a lot! But if you haven’t used Metadata Manager before, or are having problems, please:

use our existing Web Deposit Form instead, or
upload XML directly through the deposit system admin interface

We won’t be fixing bugs in Metadata Manager, except for providing any essential security updates. Of course, if you still need help please read our Content Registration help pages, or contact the Support team.

Metadata Manager’s features will be reimagined as part of our planned Member Center (working title, subject to change) project, where we will start to bring together all business and technical information for our members, service providers and metadata users. The Member Center will be the heart of our strategy to make it easier for you to work with Crossref to:

register and update metadata
view, update and transfer titles
visualize your activity/participation and act on problems with metadata
understand your bills and invoices
manage your users and service providers and their access and entitlements
and more

We’re in the early stages of planning for the Member Center and will be seeking feedback from members, service providers and metadata users in the coming months.

Metadata Corrections, Updates, and Additions in Metadata Manager

Shayn Smulyan — Mon, 13 Jan 2020 00:00:00 +0000

It’s been a year since Metadata Manager was first launched in Beta. We’ve received a lot of helpful feedback from many Crossref members who made the switch from Web Deposit Form to Metadata Manager for their journal article registrations.

The most common use for Metadata Manager is to register new DOIs for newly published articles. For the most part, this is a one-time process. You enter the metadata, register your DOI, and success!

But everything doesn’t always go quite as expected. Humans make mistakes, and typos in metadata are bound to happen on occasion, even for the most careful users.

We always want to make it as easy as possible for our members to find and correct metadata errors, and to add additional metadata when it becomes available. Our Schematron, Conflict, and Resolution reports can help you identify existing metadata errors. We never charge content registration fees for metadata updates, additions, or corrections, so cost won’t be a barrier to getting the most accurate and thorough metadata possible. And, now, Metadata Manager can make those corrections easier to do.

Correcting Errors

Because accurate and comprehensive metadata is so important for the linking and discoverability of your publications, it’s important to catch these occasional errors and correct them.

We send out reports that automatically screen for particular types of metadata errors, and we pass along comments from users who contact us with concerns about metadata quality to our contacts at the relevant publisher.

The “Review all” feature in Metadata Manager also allows you to do a final check of all the metadata you entered right before you’re about to submit your deposits. So, we also rely on you to evaluate your own accuracy there as well.

Once you’ve identified an error, you’ll need to correct it. To do that, you must resubmit a whole new metadata deposit for the affected item. The newly deposited metadata will entirely overwrite the previously deposited metadata.

If you’re used to using the Web Deposit Form, you know that the redeposit can be a little tedious. For example, if you find that you misspelled an author’s last name, you’d have to manually type in or copy-paste not just the corrected last name, but all of the journal-level, issue-level, and article-level metadata that applies to the article.

Using Metadata Manager, the process is much simpler. The full metadata record is retained or imported and you only need to correct the error itself.

For articles originally registered using Metadata Manager

If you find a metadata error in an article which you initially registered in Metadata Manager itself, you can locate the article in one of two ways:

Navigate through the list of Accepted articles within a given journal
Or, search by article title in the Deposit History

Once you’ve located the relevant article, click on the article title to open the article’s metadata record. From there, you can make the necessary corrections. With the corrections complete, click “Continue” and then “Add to deposit.” After that, the process is exactly the same as depositing a new article.

For articles registered using the Web Deposit Form or any other deposit method

If you registered an article using the Web Deposit Form, an XML deposit, or the OJS plugin, you can still use Metadata Manager to quickly correct an error. But, first you have to import the article’s metadata into Metadata Manager.

To do this, click into the relevant journal from your Metadata Manager home page. Then, search for the article title using the “Add existing article” search box. Select “Add” next to the article title in the search results, which will import the article’s metadata record into Metadata Manager.

From here, make any necessary corrections and click “Continue” and then “Add to deposit.” Navigate to the “To deposit” tab and “Review all” to ensure that your metadata record is accurate. Then select “Deposit” to finalize your submission. You’ll receive immediate feedback as to whether your metadata deposit was successful or not.

Adding additional metadata

Perhaps there are no problems with your metadata, and everything is completely accurate. That’s great! But, we encourage our members to submit metadata that is not just accurate, but also as thorough as possible. Check your Participation Report to see if there are any types of metadata that you haven’t been submitting yet, or that you haven’t been submitting for certain journals.

Metadata Manager allows you to deposit references, licenses, and relationships between your articles and other DOIs, which weren’t possible to add using the Web Deposit Form. The same process described above for corrections will allow you to import previously registered articles and add in these new metadata elements.

We also know that many of our members register DOIs for their articles when they’re first published online, but aren’t yet included in an issue. When the articles are published in their final versions, there is important metadata added which wasn’t yet available when the DOI was first registered. This includes things like volume number, issue number, page numbers, and full publication date, all of which are extremely important for linking and discoverability. Sometimes the resolution URL changes when the article is moved from its pre-publication status to its final version.

So, when each issue is published, you can use Metadata Manager to pull up all the already-registered articles included in that issue and add in the newly relevant metadata like page numbers, issue number, URL, etc. Then add them to a new deposit, review, and submit.

Please check out the full Metadata Manager help documentation for more details, or join us on an upcoming workshop to test out Metadata Manager in real-time with us. And, as always, feel free to email us at support@crossref.org with any questions.

Resolution reports: a look inside and ahead

Isaac Farley — Tue, 17 Dec 2019 00:00:00 +0000

Isaac Farley, technical support manager, and Jon Stark, software developer, provide a glimpse into the history and current state of our popular monthly resolution reports. They invite you, our members, to help us understand how you use these reports. This will help us determine the best next steps for further improvement of these reports, and particularly what we do and don’t filter out of them.

Isaac joined Crossref in April 2018. Before that, he was with one of our members, a geoscience society in Oklahoma (USA). As a Crossref member, like all of our members, he received the resolution reports to his inbox during the first week of each month. And like many of you, he had questions.

What exactly is this report?
What are all these numbers?
Now, what about those 10 top DOIs is making them so popular?
Why are some of these DOIs failing?
And, what’s with this filtering of “known search engine crawlers?”

Now that Isaac is the Crossref Technical Support Manager, instead of asking these questions, he answers many of them.

Whoa…too fast…what exactly are resolution reports?

The resolution report provides an overview of DOI resolution traffic, and can identify problems with your DOI links. The failed DOI.csv linked to your resolution report email contains a list of all DOIs with failed resolution attempts (more on this later). If a user clicks on a DOI with your DOI prefix and the DOI is not registered, it won’t resolve to a web page, and thus will appear on your report.

What are those numbers?

This is always a good starting point for wrangling statistical information. Resolution statistics are based on the number of DOI resolutions made through the DOI proxy server on a month-by-month basis. These statistics give an indication of the traffic generated by users - both human and machine - clicking (or, resolving) DOIs. CNRI (the organisation that manages the DOI proxy server) sends us resolution logs at the end of every month and we pass the data on to you.

Resolution reports are sent by default to the business contact on your account, and we can always add or change the recipient(s) as needed. We send a separate report for each DOI prefix you’re responsible for.

Historically we have done our best to filter out obvious crawlers and machine activity - thus valuing human-driven traffic to traffic generated by machines. That sentence above about those obvious crawlers is the real reason we are here today blogging.

Why are some of those DOIs failing?

The ideal failure rate is 0%. A failure rate of 0% would mean that every DOI you owned that was clicked in the previous month successfully resolved to the resolution URL you registered with us. But, in reality, a 0% failure rate is rare, because any string of characters that is combined with your prefix (e.g., 10.5555/ThisIsNOTARealDOI) and attempted to be resolved will go through the resolver and result in another single failed count toward your monthly resolution report. If you are new to Crossref, or have only deposited metadata for a small number of content items, you may have a high failure percentage (for example, 2 failures and 8 successes = 20% failure rate).

Before 2019, the overall resolution failure rate across all publishers held fairly steady each month between 2 and 4%. You may have noticed that that number has been climbing this year. And, as a result, we think a new normal is closer to 10%.

Given this new norm, if your overall resolution failure rate is higher than 8 to 12%, we advise you to look closely at the failed DOI.csv file that we include in the monthly report we email you. The first step in your analysis of this portion of the report is to make sure the DOIs listed have been registered. Very often failures of legitimate DOIs are the result of content registration errors or workflow inefficiencies (i.e., DOIs are shared with the editorial team and/or contributors before being registered with us, leading to premature clicks). If during your investigation, you find invalid DOIs (like the example above: 10.5555/ThisIsNOTARealDOI) - and you will find invalid DOIs because we all make mistakes when resolving DOIs - you may simply ignore those DOIs within the report.

What’s with this filtering of “known search engine crawlers?”

You may have recently noticed that we made a few changes to the resolution reports. We merged, rearranged, and in some cases completely rewrote the report you receive to your inboxes, because, well, it needed it. It was confusing. Parts of the report still are. Most specifically, those “known search engine crawlers.” To that point, you may have also noticed that the reports that arrived to your inboxes in early November 2019 were scrubbed of nearly 150 million resolutions across all members.

Based on Jon’s analysis of these 150 million filtered resolutions, they were from bots. In the past, it was important to filter out bots, as we found our community was most focused on human readers. But should we be filtering out resolutions from bots any more? We live in a time where most of our work (at least in the Crossref community) requires both human and machine interaction; thus, aren’t at least some of these resolutions from machines legitimate?

Our internal analysis shows that we cannot reliably determine which usage is from:

Individual humans;
Machines acting as intermediaries between researchers and DOIs;
Internet service providers with real human users behind them; or,
Bots that do not result in actual human usage.

As a result, it is our thinking that we may serve you better by not filtering any traffic, as we cannot guarantee that we’re removing the right things. We feel that it may be better for us to just give you everything we know. And invite you to make your own judgments.

How’d we get here?

Jon joined Crossref in 2004. He wrote the original version of the resolution report in late 2009 in an effort to provide you, our members, with information about the usage of registered Crossref DOIs. At that time, most members were creating DOIs, but then had no real feedback about the traffic that was getting to their content (via the DOI proxy server lookups of their DOIs). These reports filled that gap. The other benefit of the report was the information it provided about failed resolutions. As suggested above, the list of failed resolutions helped members identify potential problems with the content registration process.

A DOI that appeared on the report as a failed resolution could be cause of concern for the member. But, then again, humans and machines make mistakes when attempting to resolve DOIs (e.g., typos). Thus, not much has changed in the last ten years - the DOIs that appear in the failed resolution reports must be evaluated. Care should especially be taken when a DOI that should have been registered has not and appears as a failed resolution (e.g., data problem, agent behind on deposits, etc.) within this report.

Like we said, mistakes happen. Users may enter a DOI incorrectly when looking it up. Or, it could be a bot throwing randomly generated traffic that looks like a DOI, but is not. And, sometimes bots are scraping through PDFs for DOIs and simply extract them incorrectly. These are all user errors, and not necessarily a concern for our members. That’s why we provide that list of what failed.

At the start, there were a few well known crawlers that were resolving large numbers of DOIs regularly. It was our opinion at the time that it would be helpful to filter that usage since we assumed members only cared about human-driven traffic. As the next decade passed, it became clear that the internet had and would continue to change. With bots popping up every day and IP addresses moving or spanning broad address ranges (and IPs we had already filtered with the potential of being repurposed), it was obvious that we would always miss as much as we caught.

Between the constantly changing landscape and the fact that real usage can be hidden behind IP addresses that appear like bot traffic, we no longer have confidence in our filtering process. It may be best for our users to just get the data as the data exists and know that our metadata world covers a vast range of usages - many as valid and valuable today as that human-driven traffic we prioritized ten years ago. Perhaps there is some other metric we can provide that might be useful for understanding the traffic in better ways, but filtering some of this traffic seems no longer useful.

Your help with next steps

There you have it. Our thinking: we’ve been filtering these resolution reports the best we can for ten years. Today, our confidence in the filtering process has waned. We’re proposing a change: we want to give you the raw resolution numbers, for machines and humans alike. We want to make this change soon, but we also want to hear from you.

How are you using the resolution reports?
What you do you think of this proposed change?
Will our removal of all filters from monthly resolution reports affect how you use the information within?

We want to hear from you, and we’re inviting you to help us determine our next steps. We are going to give you until Friday, 31 January to tell us what you think of this proposed change. Then, Isaac and Jon will be back in early February to share with you what you have helped us decide. Thanks in advance!

Proposed schema changes - have your say

Patricia Feeney — Wed, 04 Dec 2019 00:00:00 +0000

The first version of our metadata input schema (a DTD, to be specific) was created in 1999 to capture basic bibliographic information and facilitate matching DOIs to citations. Over the past 20 years the bibliographic metadata we collect has deepened, and we’ve expanded our schema to include funding information, license, updates, relations, and other metadata. Our schema isn’t as venerable as a MARC record or as comprehensive as JATS, but it’s served us well. It’s not currently positioned to fully support everything we want to do long term - we’d like to support assertions, map cleanly to JATS and schema.org magically at the same time, and maybe even move beyond XML - but for now it’s something we can work with to empower member metadata to help find, cite, and connect scholarly content.

We’ve maintained backwards compatibility for most things since 2007 but this update will require some moderate changes to how contributors are modeled. The balance between supporting established tagging and addressing the evolution of what we collect and how it is expressed can be tricky. We want to collect good metadata without significantly disrupting the workflow of our membership, who are the source of the metadata. Even so, this is a fairly pragmatic update that will position us well for the future. I look forward to supporting new types of content and metadata in the future, but for now take a look at what I’m proposing.

Leave feedback, ask questions, and make suggestions in the feedback document or via email to feedback@crossref.org.

Next update

I’m proposing some updates and additions to the metadata we collect, and would like your feedback. To fully and elegantly support affiliation identifiers and multiple author roles, we need to break backwards compatibility. Specifically, we want to:

Add support for CRediT

The CASRAI CRediT taxonomy is increasingly used to represent roles common to contributors to research outputs. Our members are applying CRediT to contributors, so we want to capture them as well. Supporting CRediT allows Crossref and our membership to identify and credit contributors beyond authors and editors.

As most of you know, a contributor often does more than one thing - they write, they edit, they curate. We currently only allow one contributor role as an attribute, but, to realistically support CRediT and accurately capture evidence about the work, we need to allow multiple contributor roles. This will break backwards compatibility. We can potentially support the old way and the new way, but I’m trying to avoid awkward compromises wherever possible.

Supporting CRediT doesn’t mean you need to adopt CRediT. We’ll continue to support existing author roles, but they’ll be marked up differently. Details are in our request for feedback document.

Expand support for author and organisation identifiers

We collect ORCID iDs in our metadata but do not currently support other types of contributor identifiers. We also don’t support affiliation or organisation identifiers beyond those assigned within our funder and clinical trial registries. We’ve had increasing demands from both metadata suppliers and users to expand support for affiliation identifiers because…identifiers are useful. We also want to expand author identifier support as ORCID IDs may only be registered by researchers who are able to curate their own ORCID record. Adding support for ISNI and Wikidata IDs is a common request, but we anticipate there’s a need for other identifiers as well.

Our plan is to accept identifiers registered with identifiers.org as well as other identifiers upon request. We prefer to remain consistent with the identifiers.org registry as much as possible.

We’re particularly keen to support open community-led identifiers like ORCID and ROR and will continue to do so, but also want to support the metadata our members want to distribute. organisation identifiers will be particularly useful as they’ll help us populate records with ROR IDs in the future, leading to better quality affiliation metadata.

Expand support for a range of contributor names

We currently require a surname for all contributors, and don’t provide comprehensive support for contributors whose names are represented by multiple alphabets, or who have nicknames or aliases, or who don’t have a surname. To begin with, we’ll replace surname with the more widely used ‘family name’ and remove the fixed surname requirement, allowing only a given name to be provided where appropriate. We’ll also allow a variety of names to be provided for each contributor.

Expand affiliation support

We currently collect affiliation as a single string - we’re going to break that up to support affiliation names, and add in support for organisational identifiers like ROR.

Expand support for data citation

For those of you who send us references, we’re adding a few fields to better support data citation. We’re also going to allow you to (optionally) supply a specific publication type for references.

Other updates

We’re making some other small updates as well. If you have a small request, we may be able to accommodate it in our next update. Larger changes or additions will probably have to wait for future updates, but we’d love to start collecting suggestions now.

We need your feedback!

I’ll be giving a webinar on December 19 at 02:00 and 15:00 UTC to go over these changes in detail - please visit our webinars page to register.

Again, please leave feedback, ask questions, and make suggestions in the feedback document, or if you prefer send feedback via email to feedback@crossref.org. We’ll be taking feedback through January 15, 2020.

Request for feedback: Conference ID implementation

Patricia Feeney — Fri, 13 Sep 2019 00:00:00 +0000

We’ve all been subject to floods of conference invitations, it can be difficult to sort the relevant from the not-relevant or (even worse) sketchy conferences competing for our attention. In 2017, DataCite and Crossref started a working group to investigate creating identifiers for conferences and projects. Identifiers describe and disambiguate, and applying identifiers to conference events will help build clear durable connections between scholarly events and scholarly literature.

Chaired by Aliaksandr Birukou, the Executive Editor for Computer Science at Springer Nature, the group has met regularly over the past two years, collaborating to create use cases and define metadata to identify and describe conference series and events. We first asked for input on metadata specifications in April 2018. Technical implementation kicked off in February with a workshop at CERN to discuss the mechanics of making PIDs for conferences a reality.

We’ve reached another milestone and want your feedback

Crossref has supported a number of conference publication-related PIDs for years - members can currently register PIDs for conference series publications, conference proceedings, and of course individual conference papers - and that won’t change, but we will also be supporting DOI registration for conferences. A crucial step towards this is of course integrating the new identifier into our metadata input schema.

The details

We currently collect some limited metadata describing the conference itself such as theme, location, and dates as part of the conference series or proceeding metadata, but do not apply a DOI to that information. The new Conference ID records will include expanded metadata as defined by the working group. You’ll be able to register a distinct metadata record for a single conference. You’ll also be able to register a record for a conference series, and connect Conference IDs to conference proceeding metadata records and DOIs.

Changes to the conference-specific metadata are backwards compatible. Members will be able to register event metadata per usual, or can instead use the new event metadata to register an identifier for their conference event and/or series. This means a member can:

Register conference, conference series, proceedings series, proceedings, and papers in one submission
Register proceedings or proceedings series and papers without a Conference ID included
Register Conference IDs only
Update an existing conference record with a Conference PID

I’ve written up our proposal in this google doc and we want your feedback before we proceed with implementation. Please comment directly in the Google doc, open a Gitlab issue, or feedback@crossref.org. We’ll keep the document open for comments until September 30.

Building better metadata with schema releases

Patricia Feeney — Wed, 21 Aug 2019 00:00:00 +0000

This month we have officially released a new version of our input metadata schema. As well as walking through the latest additions, I’ll also describe here how we’re starting to develop a new streamlined and open approach to schema development, using GitLab and some of the ideas under discussion going forward.

What’s included in version 4.4.2

The latest schema as of August 2019 is version 4.4.2 and this release now includes:

Support for “pending publication”
Support for JATS 1.2 abstracts
Abstract support to dissertations, reports, and allow multiple abstracts wherever available
Support for multiple dissertation authors
A new acceptance_date element added to journal article, book, book chapter, and conference paper record types

“Pending publication” is the term we’ve coined for the phase where a manuscript has been accepted for publication but where the publisher needs to communicate a DOI much earlier than most article metadata is available. Some members asked for the ability to register and assign DOIs prior to online publication, even without a title, so this allows members to register a DOI with minimal metadata, temporarily, before online publication. There is of course no obligation to use this feature.

It’s worth calling out the addition of acceptance_date too. This is a key attribute that is heavily requested by downstream metadata users like universities. Acceptance dates allow people to report on outputs much more accurately, so we do encourage all members to start including acceptance dates in their metadata. It’s highly appreciated!

Schema files public on GitLab

I’ve added our latest schema to a new GitLab repository, There you’ll find the schema files, some documentation, and the opportunity to suggest enhancements. The schema has been released as bundle 0.1.1 and also includes our new Grant metadata schema for members that fund research.

The schema has been available in some form for months but at this point we consider it ‘officially’ released to kick off our new but necessary practice of formal schema releases. Any forthcoming updates will be added to the next version.

Schema management process

We’ve been adding sets of metadata and new record types over the years, but also need to have a defined process for small but vital pieces of metadata that you need to provide and retrieve from our metadata records. If you’re wondering what our procedure for updating our schema is, you are not alone! We have not had a formal process, instead relying on ad-hoc requests from our membership and working groups. Our release management and schema numbering has also not been consistent.

Going forward, I will ensure that all forthcoming versions of our metadata schema are be posted as a draft on GitLab for review and comment, and the final version will be officially released via GitLab as well.

It’s important to note that when we talk about “the schema”, we generally mean the input schema specifically i.e. what members of Crossref can register about the content they produce. As always, the output for retrieving that metadata is subject to separate development plans for our Metadata APIs. I’m working with our technical team so we can develop and introduce an ’end-to-end’ approach that doesn’t in future treat the input and the output as such separate considerations.

What’s next

Many of the updates in this latest release have been in the works for some time. Changes to our metadata both large and small are considered carefully, but I’d like to do this in a transparent and cooperative way with our community.

I recently set up the “Metadata Practitioners Interest Group” and we’ve just had our second call. A big topic was how to best manage the ideas and requests from the community. The ability for public comments on GitLab is a first step.

This most recent update contains a mix of long term projects and updates to keep our metadata current and useful. Other changes that are under discussion will require more development on our end. But stay tuned for more information about forthcoming changes, as well information about how you can contribute.

Putting content in context

Kirsty Meddings — Mon, 13 May 2019 00:00:00 +0000

You can’t go far on this blog without reading about the importance of registering rich metadata. Over the past year we’ve been encouraging all of our members to review the metadata they are sending us and find out which gaps need filling by looking at their Participation Report.

The metadata elements that are tracked in Participation Reports are mostly beyond the standard bibliographic information that is used to identify a work. They are important because they provide context: they tell the reader how the research was funded, what license it’s published under, and more about its authors via links to their ORCID profiles. And while this metadata is all available through our APIs, we also display much of it to readers through our Crossmark service.

Crossmark is also about providing context. It is a button placed on content, which when clicked on brings up a pop-up box that tells the reader about significant updates such as corrections and retractions, together with other information about the publishing and editorial processes that have been applied to the content ahead of publication.

The Crossmark box can display information about authors, funders and licenses. In addition, our members can add “More information” and often do in the form of publication history, links to supporting materials, and peer review information. All of this supporting information helps the reader assess how well the content has been - and continues to be - curated by the publisher.

Who’s in?

250 Crossref members have signed up to use Crossmark (it’s an add-on service with its own fees). Though optional, some star pupils have even added Crossmark to their back-year content and as a result have Crossmark coverage on 99% of their content (kudos to PLOS, Rockefeller University Press and the societies represented by KAMJE, to name a few).

At the other extreme, some have applied Crossmark to less than 10% - these tend to be members with back-year records going back many decades, who are just implementing Crossmark for their more recent research outputs. Crossmark coverage is one of the things tracked in Participation Reports - pop over and take a look if you want to see what your organisation is doing.

So what additional metadata has been registered by members using Crossmark? (data snapshot from our REST API April 2019):

8,711,500 content items have some Crossmark metadata
104,650 updates to content have been registered. Of these
55,000 are corrections and 28,000 errata
16,000 are new versions or new editions
2,700 are retractions and 1,280 are withdrawals
4,830,510 content items have some custom metadata, which appears in the More Information section of the Crossmark box. The most common metadata provided here is publication history, followed by copyright statements, the peer review method used, and whether the item has been checked for originality using Similarity Check.

Some news on clicks and views

We’ve been collecting usage statistics more or less since the Crossmark service launched in 2012, but have lacked a suitable way to share them. This will change later this year! In preparation, I’ve been digging around in the data and uncovered some interesting things.

I was able to do a degree of comparison between Crossmark usage against overall article views using PLOS articles as they make their usage data openly available. I spot-checked fifteen articles and found that most of them had a monthly number of clicks on the Crossmark button in the low-twenties, regardless of the number of total page views the article had received.

The highly viewed paper above shows relatively very few clicks on the Crossmark button, whereas on the paper with fewer views, below, clicks on the button follow the overall pattern of usage.

It’s not unreasonable to suppose that a paper with very high usage has a higher proportion of lay readers visiting it, whereas a more niche paper is being visited by those with a research interest. This is encouraging, as it suggests researchers are interested in checking the status of the content and the additional “trust signals” that the Crossmark box can provide.

Web pages vs PDFs

We track the number of clicks on the Crossmark button in PDFs separately to those that come from web pages. (There are some that we can’t determine, usually because the link behind the button has been incorrectly formatted, but for most members these are minimal.)

I looked at the 30 members with most Crossmark coverage, and averaged the number of clicks over a six month period in 2018. For two thirds of these members, clicks on the Crossmark button on their web pages exceed those in their PDFs, but there are also definite outliers.

Some are easily explained: member #6 hasn’t put the Crossmark button in any of their PDFs, while member #21 has only put it in their PDFs. Member 10 has the button on its article landing pages hidden in a “more information” section that the reader has to click to expand.

That said, member #20 has the button displayed prominently next to the article title but gets 85% of Crossmark clicks from PDFs. There’s no obvious subject bias - four of the members above are physics publishers - two have many more PDF clicks, two have more HTML.

None of the findings above contain nearly enough data to draw any definitive conclusions, but I hope they pique your interest to find out more when we make Crossmark usage statistics available to all members later this year. In the meantime if you have any suggestions/questions, or would be interested in helping us when we come to testing the statistics interface, please let me know.

A simpler text query form

Isaac Farley — Tue, 30 Apr 2019 00:00:00 +0000

The Simple Text Query form (STQ) allows users to retrieve existing DOIs for journal articles, books, and chapters by cutting and pasting a reference or reference list into a simple query box. For years the service has been heavily used by students, editors, researchers, and publishers eager to match and link references.

We had changes to the service planned for the first half of this year - an upgraded reference matching algorithm, a more modern interface, etc. In the spirit of openness and transparency, part of our project plan was to communicate these pending changes to STQ users well in advance of our 30 April completion date. What would users think? Could they help us improve upon our plans?

About a month ago, I reached out to the 21,000 plus users we had on record of using STQ since January 2018. We received nearly 85 responses from the messages we sent. Questions ranged from: if we were making changes, would PubMed ID matching be supported? To: What about the reliability of the returned reference links? And: Could we better accommodate larger reference lists?

Many of the users we heard from told us how STQ was critical to their work. I read all these messages. The concerns raised by users were legitimate and much appreciated. We reassessed our project timeline and plans, and decided to shift course. So, what are we doing?

What’s changing?

The previous hurdle of having to register your email address simply to return reference links was confusing and unnecessary. We removed it.
We previously limited the number of monthly reference links to 5,000 per email address. Most didn’t reach the limit, but those who did were frustrated by it and/or found ways around it. We want you to match and register as many references as possible, so we removed the monthly limit too.
Many of you with long reference lists found that you were occasionally reaching our limit of 30,000 characters per submission. Once again, we want you to match and register as many references as possible so we removed the character limit altogether and instead are just looking at the number of references per submission. We now provide space for 1,000 references per submission (We checked. The most references we have ever received via the STQ form in one submission was around 750. Thus, we rounded up.).
We did make a change to the backend of the service. We updated the algorithm we use to return reference links. We think it’s an improvement. Let us know how you find it.

What’s remaining the same?

Core functionality. It’s all in the name. Retrieve DOIs for journal articles, books, and chapters by cutting and pasting a reference or reference list into a simple query box.
PubMed ID matching. You use it. You need it. We’re keeping it.
Deposits. You’ll still need an email address for this, but we won’t ask for it until you’re at the deposit screen.
The interface. We’re still eager to give the user interface a much-needed refresh, but, as many users pointed out to us, there’s still some core functionality that’s important that we need to retain with any interface update. For instance, you need to be able to easily copy and paste reference links into your reference list. That functionality isn’t going anywhere.
Resetting reference links. Submit references, match, reset, and repeat. Many users like the reset button. It’s not going anywhere either.

XML queries

The change to the backend of the service that I mentioned above is not confined to reference matching and depositing for STQ users. XML queries for reference matching are also now powered by that new backend. We think it’s a seamless transition, but if you find it is not, please let us know.

I’m excited for these changes and hope you are too. I invite you to try the simpler and improved STQ form, and let us know what you think.

Quarterly deposit invoices: avoiding surprises

Isaac Farley — Wed, 10 Apr 2019 00:00:00 +0000

Whenever we send out our quarterly deposit invoices, we receive queries from members who have registered a lot of backlist content, but have been charged at the current year’s rate. As the invoices for the first quarter of 2019 have recently hit your inboxes, I thought I’d provide a timely reminder about this in case you spot this problem on your invoice.

This problem is usually the result of metadata being registered that makes it look as though the content was current, despite the fact that it was backlist. This post will show you what to do if you spot this problem in your latest invoice - and more importantly, how you can avoid this situation in the future.

About current and backlist Content Registration fees

There are different fees for registering content depending on whether it’s current (this year and the previous two years - 2017, ‘18, and ‘19) or backlist (older than that). As an example, it’s $1 each for a current journal article, and $0.15 for each backlist article. So, if you’ve incorrectly registered your content as published in 2019 when actually it was published in 2012, your quarterly invoice will overcharge you based on the metadata discrepancy.

We send you the quarterly deposit invoice at the end of each quarter. This example is an invoice for all deposits of the first quarter of 2018 for username ‘test’ - months January, February, and March.
The BY code represents backlist (or, back year) content (journal article, in this example). Backlist content is charged at $0.15 per content item.
The CY code represents current year content (journal article, in this example, although you can see that this invoice has charges for other content items as well). Current year content is charged at $1 per content item.

Determining whether content is current or backlist

A record is determined to be either a backlist or current year deposit based on the metadata that you deposit with us. If you use our helper tools - Metadata Manager or the web deposit form - the system looks at the information you’ve entered into the “publication date” field. If you deposit XML with us, it looks at the date in the <publication_date> element. And we look at each individual item separately—so even if you’ve put a publication date at journal level, you still need to put it at the journal article level too.

Additionally, sometimes we find that deposits mistakenly include the deposit date in place of the publication date. These two dates - the deposit date and the publication date - are not necessarily one and the same, especially if you are depositing backlist content. Please take care to double check this before you submit your deposit(s).

What to do if you think you’ve registered the wrong publication date

As you can only update a publication date by running a full redeposit, it’s important to get it right the first time. If you’ve registered the wrong publication date and have received an invoice for the wrong amount, please redeposit your content and then get in contact with us. If you do this as soon as you spot the error, we’ll be able to send a new invoice for the correct amount.

Before, during, and after - a journey through title transfers

Isaac Farley — Mon, 25 Feb 2019 00:00:00 +0000

In January, I wrote about how we’ve simplified the journal title transfer process using our new Metadata Manager tool. For those disposing publishers looking for an easy, do-it-yourself option for transferring ownership of your journal, I suggest you review that blog post. But, whether you choose to process the transfer yourself via Metadata Manager or need some help from Paul, Shayn, or myself, there’s more to a transfer than just the click of a transfer button or the submission of an email to support@crossref.org, as I’m sure those of you who have been through a title transfer can attest.

Prepping your title transfer

Sometimes members get on the other side of a title transfer and find you’re encountering problems even if you followed the process for transferring titles. You might find you can register new content for the new title against your own prefix without any issues. But you are not able to update the metadata for back-year records after we’ve made the transfer.

When we investigate, the problem is usually that the DOIs you’re trying to update don’t exist in our system yet. This means the deposit isn’t considered an update to the content, it’s considered a new deposit. And you don’t have permission to do that, since you’re effectively attempting to register new content to a prefix that is not your own.

This problem is because the former publisher didn’t ever register the DOIs with us - even though they’ve been displaying them on their website. This is bad practice and isn’t in keeping with our membership terms, but it does sometimes happen.

Before you request a title transfer, do check with the former publisher that they’ve definitely registered all the DOIs that they’ve been displaying and distributing to their readership. You can spot check this yourself by following a few of the DOI links and checking that they resolve to the right place. If you want a full list of DOIs registered to a journal title, our depositor reports are the place to start. Depositor Reports list all DOIs deposited for a title on a publisher-by-publisher basis. Or, alternatively, if you know the journal cite ID, the unique internal, Crossref identifier for the journal, you can bypass the publisher-by-publisher title list (in my example you’d need to replace my fictional 123456 journal ID with your journal’s cite ID):

`http://data.crossref.org.pluma.sjfc.edu/depositorreport?pubid=J123456`

Top tips for a pain-free title transfer

If your organisation has gained new titles, you’ve checked the depositor report for your new journal and are happy that all the existing DOIs have been registered, then you’re ready to process the transfer. Here are three key steps to ensure a pain-free transfer.

If you are not acquiring all existing journal articles as part of this transfer, you’ll need to contact us at support@crossref.org to confirm the details. Once we have those details sorted, we’ll transfer ownership for the select, specified articles.
Carefully check the existing metadata associated with your new titles - some metadata provided for text and data mining or Similarity Check are publisher-specific and must be updated or removed when content is acquired by another member.
If the metadata supplied is fine, you just need to update the URLs to direct DOIs to your content. You can do this by sending us a URL update file or by redepositing the metadata with the correct URLs.

If you need to update more than the URLs, you should redeposit the metadata with the correct information plus the correct URLs.

Note: If you, as the disposing publisher, are prepared to transfer your journal to an acquiring publisher, and would like to transfer ownership of the journal and all existing journal articles, please try your new title transfer via Metadata Manager.

On the other side

If you follow the steps I’ve outlined above, you should get to the other side of your title transfer with few problems and are likely to encounter smooth metadata seas ahead. That said, some of our members follow these steps to a tee and still are faced with occasional transfer-related problems.

Perhaps the previous journal owner used a different scheme to assign timestamps and now you’re receiving mysterious timestamp errors when you deposit. Or, that same previous owner made a mistake with a previous deposit and accidentally submitted more than one journal title record. Or, you encounter a strange, new error in Metadata Manager when working with your new titles (yes, we’re still in beta!). If so, please reach out to us at support@crossref.org and we’ll help solve what are surely confounding problems, since you’ve undoubtedly read this post in its entirety and taken heed of the above advice.

As always, if you have questions, need guidance as you’re working through this process, or have recommendations on how we can improve title transfers, please contact us at support@crossref.org.

What can often change, but always stays the same?

Isaac Farley — Thu, 24 Jan 2019 00:00:00 +0000

Hello. Isaac here again to talk about what you can tell just by looking at the prefix of a DOI. Also, as we get a lot of title transfers at this time of year, I thought I’d clarify the difference between a title transfer and a prefix transfer, and the impact of each.

When you join Crossref, you are provided with a unique prefix, you then add suffixes of your choice to your prefix and this creates the DOIs for your content.

It’s a logical step then to assume you can tell just by looking at a DOI prefix who the current publisher is—but that’s not always the case. Things can (and often do) change. Individual journals get purchased by other publishers, and whole organisations get bought and sold.

What you can tell from looking at a DOI prefix is who originally registered it, but not necessarily who it currently belongs to. That’s because if a journal (or whole organisation) is acquired, DOIs don’t get deleted and re-registered to the new owner. The update will of course be reflected in the relevant metadata, but the prefix itself will stay the same. It never changes—and that’s the whole point, that’s what makes the DOI persistent.

Here’s a breakdown of how this works internally at Crossref:

Title transfers

Member A acquires a single title from member B. We transfer the title (and all relevant reports) over to member A. Member A must then register new content for that journal on their own prefix. The existing (newly acquired) DOIs maintain the ‘old’ prefix but member A can update metadata against these existing DOIs for that journal. Back-year and current DOIs for that journal may, therefore, have different prefixes—and that’s OK!

Organisation transfers

Member C acquires member D. We move the entire prefix (and all relevant reports) over to Member C, and close down Member D’s account with Crossref. Member C can continue to register DOIs on member D’s prefix (the original prefix) if they want to, or they can use their own existing prefix. So again, back-year and current records for that journal may have different prefixes.

And, if Member C uses a service provider to register metadata on their behalf, we will simply enable their username to work with the prefix.

It’s now easier to transfer titles

We’ve recently made the process of transferring journal titles a lot easier with our new Content Registration tool, Metadata Manager.

Improved processes, and more via Metadata Manager

Shayn Smulyan — Thu, 17 Jan 2019 00:00:00 +0000

Hi, Crossref blog-readers. I’m Shayn, from Crossref’s support team. I’ve been fielding member questions about how to effectively deposit metadata and register content (among other things) for the past three years. In this post, I’ll take you through some of the improvements that Metadata Manager provides to those who currently use the Web Deposit form.

We recently announced the launch of Metadata Manager, a new tool from Crossref that makes it easier for you to submit robust, accurate, and thorough metadata for the content you register. Metadata Manager already covers journals and articles; more record types will be supported soon. It offers some extra features that will make your experience less stressful, make your metadata better, and ultimately make your content more discoverable.

Metadata Manager has the potential to improve your metadata registration experience in a number of ways:

by correcting one-off errors in previously registered metadata
by directly allowing you to add references, license data, funder information, or any other ancillary metadata to items that have previously been registered
by updating Crossmark data, in the case of a retraction or withdrawal

With the Web Deposit form, you finish entering your metadata for a new issue of your journal, and then get asked for your password, and of course that’s when you realize you’ve forgotten it (it happens a lot!). With Metadata Manager, the very first step is to log in, so you know your login credentials are accurate before you get down to the task of entering your metadata.

Easily import journals, or add new ones

When you switch to Metadata Manager, you can import the journals already associated with your account. Simply go to the search bar on the Home screen, search for your journal by title, then click ’Add’. If you are registering your first article for a journal that you’ve not registered before, you can add the journal information on the Home screen, by clicking “New Publication”.

Adding a Journal DOI

In the Web Deposit form, the Journal DOI is optional, as long as you include a valid ISSN. However, with Metadata Manager, a Journal DOI must be created for each journal you register. So, you need to enter a Journal DOI and a Journal URL for each of your journals before your deposits can be submitted. The Journal DOI won’t become active until you submit your first successful deposit for an article within that journal.

If you’ve never registered a Journal DOI before and are unsure what to use for your Journal DOI’s suffix, take a look at our suggested best practice for constructing DOI suffixes.

Adding new articles

Once your journal is added, the process of adding articles in Metadata Manager should be familiar, as it’s similar to the Web Deposit form process. You type in or paste as plain text (without formatting) all your relevant, accurate, and thorough metadata into the appropriate fields in the form.

Save your work as you go

In Metadata Manager there is no need to complete a full issue’s worth of articles at once. And, you don’t need to worry about losing your progress if you accidentally close your browser window, or your laptop runs out of battery while you’re in the middle of a deposit. You can simply and easily ‘save-as-you-go’, one article at a time, until you’re ready to submit them all. You can even review your saved metadata to make sure there aren’t any errors before the deposit is finalized.

Other metadata fields you didn’t know you needed (but you do!)

Have you ever wanted to add an abstract to your content’s metadata? How about license information, so that other organisations know what they can and can’t do with the work? Does your journal use article ID numbers instead of page numbers? These are all elements that can be added to Metadata Manager that were not available in the Web Deposit form. Additionally, you can add funding data, Similarity Check links, and relationships between your articles and other content. These types of metadata are hugely valuable for building a robust, interconnected web of scholarly communication.

Adding references

Unlike the Web Deposit form, Metadata Manager allows you to easily add references to your article’s metadata—this is an important requirement for participating in our Cited-by service.

To add references to an article’s metadata, you can copy and paste its reference list into the references field on the same screen as the rest of the article metadata (as per the image below).

Metadata Manager will match DOIs to those references (where available), and include the full list in your record. So, if you’ve been putting off participating in Cited-by because the reference deposit requirement was too much of a hassle, we hope this will help ease the way! The more references everyone registers, the more robust our Cited-by counts and Cited-by data become.

Edit mistakes without having to re-enter all your metadata

Mistakes happen. Sometimes you put an author’s first name in the last name field. Sometimes you copy and paste some stray HTML tags into your abstract. You might break a link by leaving a space in the middle of a URL, or enter the first-page number as 3170 instead of 317.

With Metadata Manager you can fix any errors quickly and easily right in the interface, then just click to redeposit the article with its metadata corrected. You won’t need to re-enter all the metadata or worry about editing the XML files directly.

We’ll have another blog post coming soon that will be devoted entirely to updating, correcting, or otherwise editing metadata for already-registered DOIs in Metadata Manager.

Find out immediately if your registration was successful

When you have finished adding the metadata for your articles, navigate to the “To deposit” section and click ‘Deposit’ to submit them. Instead of having to wait for your content to go through our processing queue, you’ll get immediate feedback. The number of Accepted and Failed deposits show immediately. Any articles which have failed are clearly marked with a red triangle icon and an explanation for the error. If you don’t understand an error message or how to correct the metadata, please contact us at support@crossref.org.

To get started with Metadata Manager take a look at our full help documentation.

Resolutions 2019: Journal Title Transfers = Metadata Manager

Isaac Farley — Thu, 03 Jan 2019 00:00:00 +0000

UPDATE, 12 December 2022
Due to the scheduled sunsetting of Metadata Manager, this title transfer process has been deprecated. Please find detailed guidance for transferring titles on our documentation site here.

When you thought about your resolutions for 2019, Crossref probably didn’t cross your mind—but, maybe it should have…

Because we know—with a high level of certainty—that Shayn, Paul and I will be spending the first few weeks of the year transferring the ownership of many journal titles. Last year we processed almost 60 journal transfer requests during this time, and we’re heading toward a similar number for 2019. There’s no objection; it’s a just a fact. We’re happy to do it, but there is another way.

Unlike previous years, we now have a tool that gives you the control to transfer titles without any intervention from the Crossref support team—Metadata Manager. With just a few clicks, you, as the disposing publisher, can transfer your journal to the acquiring publisher yourself. Here’s how:

Transferring your journal in five easy steps using Metadata Manager:

Log into Metadata Manager using your username and password (the same one you use for the Crossref Web Deposit form).

Find the journal you’re transferring on your Metadata Manager workspace using the “search publications” box and click to load the journal’s container (or, dashboard).

Within the journal container, select Transfer Title from the Action drop-down.

On the transfer title screen select the acquiring (destination) publisher’s name and DOI prefix of where ownership will be transferred to. Click Transfer.

(In addition to transferring ownership of the title itself, all existing journal article DOIs previously registered will also be transferred to the new owner using this mechanism. They will persist on their original prefix, but the acquiring publisher will be able to update the metadata associated with these DOIs).

Confirm the title transfer. It may take up to 24 hours for the transfer to be reflected within Metadata Manager, and we’ll send a courtesy email to the acquiring (destination) publisher’s technical contact when the transfer has been completed.

As always, if you have questions, need guidance as you’re working through this process, or have recommendations on how we can improve title transfers—or anything else within Metadata Manager (the tool is in beta)–please let us know at support@crossref.org. There’s also comprehensive support documentation available for Metadata Manager to help and guide you.

Newly approved membership terms will replace existing agreement

Ginny Hendricks — Wed, 05 Dec 2018 00:00:00 +0000

In its July 2018 meeting, the Crossref Board voted unanimously to approve and introduce a new set of membership terms. At the same meeting, the board also voted to change the description of membership eligibility in our Bylaws, officially broadening our remit beyond publishers, in line with current practice and positioning us for future growth.

Tl;dr

It’s a very good thing to have clearer terms; we want everyone to understand what Crossref is about and what you’re getting into. It’s a material change so we will be notifying members by direct email in December. Nobody needs to sign anything as the new terms are not signed, but are click-through acceptances on application, and that process is already in effect for new applicants. The new terms come into effect on 1st March 2019 for existing members and no action is needed.

If you’re a sponsored member you’ll have a slightly adapted message soon as we work with your sponsor.
If you’re an NGO or US State Actor you will receive a slightly adapted message.

This post is for background explanation and information. We will email existing members directly, but no acceptance or signature—nor any action—will be needed.

Why are we updating the terms?

Being almost 20 years old the old agreement is out-of-date with current practice and technology, and has become quite long and confusing, especially for applicants for whom English is not their first language. Specific reasons include:

1. To improve efficiency

Over the years we’ve had feedback that our application process is too long and involved. The membership agreement used to be signed manually by each new Crossref member, often days after they applied. We also now process around 180 new members each month which is too many for a wholly manual process managed by just one person.

2. To clarify the wording

People would tell us that the agreement is too long and confusing, especially when English is not their first language. There are often questions about the “legalese” style of language that takes up too much time in back-and-forth discussions to ensure everyone has understood. Also, the main structure of the agreement has been in place for over a decade and needs updating to avoid confusion and to align with up-to-date language, services, technologies, and current practices.

3. To emphasize the community aspect and our members’ obligations

It is quite a commitment to participate fully in Crossref, and we want people to understand up-front what their obligations are as part of the collective membership. And also to realize what value they are receiving as well as contributing to other members. We needed clearer terms so that every organisation can understand what they are getting into.

Additionally, moving from signing contracts to click-through acceptance of standard terms emphasizes that Crossref is not a service provider or vendor. We are a not-for-profit community organisation. We don’t have the resources to negotiate and keep track of individual custom agreements.

What’s changing, step-by-step

We consulted with former and current legal counsel, the Membership & Fees Committee, and also with the M&F organisations individually. We have also absorbed a lot of feedback from many other members of all kinds and sizes.

For new members

The manually-signed membership agreement has already—for new members— been turned into a set of click-through terms that organisations agree to as part of the initial application process. It is no longer a separate document that needs to be signed or countersigned. This will simplify the application process for both new applicants and our staff.

For existing members

The new membership terms will come into effect for existing members on March 1st, 2019. Because this is a material change to the terms, we will be emailing members with more information but it’s important to note that no action is necessary from existing members. The new terms will replace the old terms automatically.

The table below sets out clause-by-clause the precise changes. Here is the 2018 membership agreement and the new terms in full.

The nitty-gritty details

Topic	New section	Old section	Summary of change(s)
Overall			Eliminates legalese in favor of plain English. Updates defined terms to current usage. Shifts from execution by signature to acceptance by affirmative action.
Introduction	Background	1	Updates description of Crossref’s activities to be current. Provides for a new applicant’s acceptance of Terms upon acceptance of application by Crossref and payment of first annual fee.
Members’ rights	1	2(a)	Streamlines wording; eliminates reference to right to recommend working committee members.
Members’ obligations	2	2(b)	Significant revision. Old 2(b) mentioned only payment of fees and appointment of a contact person. New Sec. 2 aims to capture all of a Member’s operational obligations in one place.
Metadata deposits	2(a), (b)	3(a)(i)	Updates language regarding metadata deposits to current terminology and practice.
Rights to content	2(c)	15	Streamlines wording.
Registering identifiers	2(d)	3(a)ii)	Streamlines the language around registering identifiers.
Linking	2(e)	3(a)(iii)	States, in clearer language, the obligation to embed identifiers.
Reference linking	2(f)	3(a)(iv)	Eliminates outdated provision on Cross-Linking; replaces with a best efforts covenant to engage in Reference Linking.
Display identifiers	2(g)	N/A	Adds an obligation to comply with Crossref’s display guidelines and ensure each identifier is hyperlinked to be citable.
Maintaining and updating metadata	2(h)	3(b)	Streamlines language. Adds obligation to maintain the URL and the accuracy of identifier data. Adds common examples of failure to maintain and update metadata.
Archiving	2(i)	3(d)	Adds link to examples of third-party archive providers. Adds option for Crossref to point to a “defunct DOI” page. Inserts best efforts obligation to contract with a third-party archive.
Content-specific obligations	2(j)	N/A	Adds reference to Crossref’s record type rules and obligation to comply.
Fees	3	2(b)	Old agreement referred generally to “all membership dues and any charges or fees as established by the Board from time to time and set forth on the PILA Site.” New Section 3 aims to summarize the categories of fees associated with membership, including a reference to service fees for optional services if and when elected by the Member. Adds Member obligation to cover wire transfer fees/other payment costs.
General license	4(a)	4	Clarifies that the license grant covers only metadata and identifiers “corresponding to such Member’s Content.”
Metadata rights & limitations	4(b)	5	Significantly streamlines wording.
Crossref’s IP	4(c)	6	Significantly streamlines wording.
Distribution of metadata	5	9(b)	Updates language regarding Crossref’s rights to distribute Metadata. Adds an explicit carveout for a Member’s reference distribution preference.
	N/A	7, 8, 9(a)	Deletes extensive provision relating to obsolete “Clean-Up” and “Reverse Look-Up” services. Deletes provisions relating to obsolete “caching and transfer” activities, and local hosting.
Use of marks	6	10	Substantially rewritten, including to reflect Crossref’s more permissive approach to use of its logo.
Maintenance of the Crossref Infrastructure	7	[No analog.]	Adds covenant of Crossref to maintain the Crossref Infrastructure.
Term	8	11	Eliminates the concept of automatically renewing 12-month terms. Replaces with a perpetual term that continues until superseded by an amended version.
Termination of membership	9(a)	11	Provides for termination by the member upon written notice, rather than 90 days’ written notice, to align with the Bylaws. Adds a for-cause termination right by the Member, and corresponding right to receive a refund of fees. Sets out certain bases for termination of membership by Crossref, consistent with the Bylaws.
Appeal rights	9(b)	13	No material change.
Effect of termination of membership	9(c)	12	Adds refund right for for-cause terminations.
Enforcement	10	13	Replaces “Crossref has the right but not the obligation to enforce the terms of this Agreement …” with “Crossref shall take reasonable steps to enforce these Terms … .”
Governing law; venue	11	14(a)	Keeps New York as choice of law, but moves forum to Boston, nearer to Crossref’s US location.
Disputes	12	14(b)	No material change (but note venue provision moved to 11(a)).
	N/A	15	Eliminates mutual “warranty” provision; addresses rights to content and anti-infringement under other provisions.
Indemnification	13	16	Removes concept that Member is indemnifying other Crossref Members. Streamlines and cleans up the indemnity language.
Limitation of Liability	14	17	Adds explicit reference to the Crossref Infrastructure.
Assignment	16(c)	22	Removed language providing that Crossref’s consent to assignment of the Terms shall not be unreasonably delayed or conditioned.
Amendment	18	2(c)	Old: “The Board shall have the power to modify the terms of this Agreement by publishing amended versions that will automatically supersede prior versions … . PILA will use its reasonable discretion in deciding if a modification is material, and if so will provide written notice” to the Member of the material changes. New: “These Terms may be amended by Crossref, via updated Terms posted on the Website and emailed to each Member not less than sixty (60) days prior to effectiveness. By using the Crossref Infrastructure after the effective date of any such amendment hereto, the Member accepts the amended Terms.”
Data privacy	19	N/A	Adds a GDPR-compliant privacy provision; adds a linked reference to Crossref’s new Privacy Policy.
Compliance	20	N/A	Adds a mutual compliance covenant and an OFAC/sanctions representation.
Various legal “boilerplate” terms (taxes, waiver, independent contractor	15-17	18-28	Streamlined; replaced with more contemporary formulations; eliminated some excess verbiage.

Thanks for reading this far!

Please contact our member experience team with any questions.

It’s not about the money, money, money.

Amy Bosworth — Thu, 18 Oct 2018 00:00:00 +0000

But actually, sometimes it is about the money. As a not-for-profit membership organisation that is obsessed with persistence, we have a duty to remain sustainable and manage our finances in a responsible way. Our annual audit is incredibly thorough, and our outside auditors and Board-based Audit committee consistently report that we’re in good shape.

Our Membership & Fees committee regularly reviews both membership fees and Content Registration fees for a growing range of research outputs. Together with our staff, the Board regularly reviews financial projections that inform our budgeting process and approve our budget each year.

Financial sustainability means the persistence of our infrastructure and services

We run a tight ship here at Crossref. We have to. So it’s not ideal when we have to chase members and users for late payments, but it’s an important part of keeping the organisation afloat, and keeping our dedicated service to scholarly communications running. And that’s my job at Crossref.

Working here for over six years now, I’ve seen a lot of development in our finance department. We strive as a team to always improve our communication with members and users to deliver the best ‘customer’ experience. To do this, we are always tweaking our processes to improve efficiency and accuracy, and welcome all feedback.

How the invoice schedule works

Our annual membership invoices are sent out each January, and our Content Registration invoices are generated four times a year, each quarter. All invoices are emailed to the billing contact for your organisation (please be sure to update us with any contact changes!) and have a due date of net 45 days. Our invoices now have a “pay now” link in the body of the email. This offers a faster and more convenient way for you to pay, simply by clicking on the link to our payment portal. You can also view invoices as PDFs in the payment portal. An important part of our accounting process is the automated invoice reminder schedule. There are three billing reminders we send by email:

The day immediately after the invoice due date;
21 days past the invoice due date; and
45 days past the invoice due date.

We don’t want to see you go!

We understand there are many factors that can make prompt payment a challenge for some people: international transfer delays or fees; funding for your publishing operations may end; change of contacts; problems receiving our emails.

When an account is 90 days past due, a further email notifies you that your service is at risk of suspension. If an account is then suspended for non-payment it becomes at risk of being ‘terminated’. Once an account has been terminated, you will need to contact our membership specialist to rejoin Crossref. Please note that we send numerous notifications/reminders before suspension or termination takes place (we don’t want to see you go!). We can always be reached at billing@crossref.org for any invoice inquiries you may have.

Tips that work for other users

There are some things you can do to speed-up or simplify payments:

Pay with a credit card, using our online payment portal. This is fast, convenient, and lower in fees
Always reference an invoice number on the payment to ensure that it’s applied to your account efficiently
Be sure to make billing@crossref.org a ‘safe’ email address, so that you receive our invoices and reminders
Always keep us up-to-date with any contact changes at your organisation, to ensure that we have accurate information for invoicing and other communication
We recommend giving us a generic email address for your accounts payable team, such as accounts@publisher.com so that if somebody leaves that job, invoices can still get through.

Thanks for working with us! Please let me know in the comments below if you have any feedback or additional tips for your fellow Crossref community members.

Good, better, best. Never let it rest.

Jennifer Kemp — Tue, 16 Oct 2018 00:00:00 +0000

Best practices seem to be having a moment. In the ten years since the Books Advisory Group first created a best practice guide for books, the community beyond Crossref has developed or updated at least 17 best practice resources, as collected here by the Metadata 2020 initiative. (Full disclosure: I co-chair its Best Practices group.)

Books have been one of the fastest growing resource/record types at Crossref for some time, and best practices are just one of the Book Advisory Group’s efforts. Over the past ten years, the members of the books group have updated and added to the guide, and it’s now time for it to get some visibility, so we have added it to our website for easy reference.

These best practices are not documented for the sake of it. They have real value and can help guide internal conversations to evaluate current practices, for example. They can also play a role in making or changing policies, training staff and providing instructions to authors on citation formatting.

Here are a few recent changes I’d like to highlight:

A new section has been added that addresses books hosted on multiple platforms
The section on versions, (including books in multiple formats) has been expanded and clarified
A section on the use of DOIs in citations has been added

It is neither final nor comprehensive, and never will be. Best practices by their very nature must evolve over time—and those with such a broad scope as books will inevitably lack some detail—but that’s all the more reason for the community to stay engaged. Looking ahead to future work from the group, chapter-level metadata is likely to get more attention.

Over the past few years the Books Advisory Group, chaired with aplomb by Emily Ayubi of the American Psychological Association (APA), has spent a lot of time on Crossref initiatives, like Multiple Resolution and DOI display changes but also on broader industry topics like ORCID iDs for book authors, and the Books Citation Index.

As Emily’s term as chair comes to an end this year, we welcome Charles Watkinson of the University of Michigan as chair starting in 2019. The group meets next on 12 December when we will hear from Coko about Editoria and have a discussion about developing our new Metadata Manager Content Registration tool for books, and more.

If you want to share your thoughts on best practices or if you have other topics you’d like us to consider, please get in touch.

Metadata Manager: Members, represent!

Jennifer Lin — Mon, 15 Oct 2018 00:00:00 +0000

Over 100 Million unique scholarly works are distributed into systems across the research enterprise 24/7 via our APIs at a rate of around 633 Million queries a month. Crossref is broadcasting descriptions of these works (metadata) to all corners of the digital universe.

Whether you’re a publisher, institution, governmental agency, data repository, standards body, etc.: when you register and update your metadata with Crossref, you’re relaying it to the entire research enterprise. So make sure your publications are fully and accurately represented.

Metadata Manager is here to help

This year, we’ve released a new tool aimed to make this easier and give you, members, full control over your metadata. Presenting: Metadata Manager. It helps to:

Simplify and streamline the Content Registration service, with a user-friendly interface
Give you greater flexibility and control of metadata deposits
Support users who are less familiar with XML
Boost metadata quality, encourage cleaner and more complete metadata records

Metadata Manager is available to all our members and the service providers they work with, providing assistance with a wide range of metadata-related tasks:

Regular Content Registration conducted by journal staff, editors and service providers
Registering corrections, retractions, or other editorial expressions of concern
Matching references to their DOIs and registering them with the publication
Adding metadata to existing records such as license and funding information, abstracts, or data citations
Late-arriving editorial updates/corrections after initial publication
Unexpected corrections to production hiccups
Emergency editorial changes that affect publication record
Accelerated registration for special pieces published outside of regular workflow
Securely and efficiently transfer titles to another publisher as the authorized owner

Issues arise all the time in the dynamic and challenging work of scholarly communications. Metadata Manager provides a fast and easy way to meet these head-on when broadcasting new content or updating existing content. Submissions through this tool are processed immediately upon submission (i.e., no queues!).

This new tool empowers our members to “represent” in the exhilarating thrum of data reaching our API users. At this moment in time, it only supports journals, but our development team is currently working hard to include the remaining record types.

Features

Here’s a smattering of highlights from the Metadata Manager feature list:

All metadata: easily adds any and all metadata, allowing publishers to add richness and depth to their records.
Prevents rejected submissions: it ensures you have satisfied all the basic Content Registration requirements and points out any input errors.
Expedited deposit: the Content Registration system processes each submission immediately, bypassing the deposit queue.
Historic log: easy to read archive of all previous submissions.
Effortless review: provides a clean, condensed view of metadata (invariably complicated and lengthy) to support human review of the content before submission.
Aids members to follow best practices: checks for completeness and reminds users of the full breadth of metadata available for the article, volume/issue, and the journal itself.
Full control over title transfers: no need to make these requests through our support channels. Complete the transfer at your convenience, directly through the system.

For those of you that have looked at your own metadata contribution with the use of our new Participation Reports, you’ll find using Metadata Manager a quick and useful way to help you level-up your records.

Members, represent!

We invite you to register and update your publications with Metadata Manager, relay the metadata fully and accurately to the entire research enterprise. Check out the comprehensive help documentation to find out how to set up your workspace and get started right away with your usual Content Registration login details.

As mentioned, we are continuing development, adding support for all remaining record types as well as enhancing existing features. The webDeposit form will remain available throughout this time. For journal publishers, give us a whirl and let us know if you see something missing or there’s a function that would improve your Content Registration experience!

100,000,000 records - thank you!

Ed Pentz — Wed, 26 Sep 2018 00:00:00 +0000

100,000,000. Yes, it’s a really big number—and you helped make it happen. We’d like to say thank you to all our members, without your commitment and contribution we would not be celebrating this significant milestone. It really is no small feat.

To help put this number into context; the National Museum of China has just over 1 million artifacts, the British Library has around 25 million books, Napster has 40 million tracks, and Wikidata currently contains 50 million+ items.

Digging into the 100 Million

Within these 100 Million registered content records there are many different record types.

And within these record types, more than 69 million records have full-text links, 31 million+ have license information and 3 million+ contain some kind of funding information. An overview of these and other Crossref vital statistics is available on our dashboard.

100 Million—what does your contribution look like?

Our recently-launched participation reports allow anyone to see the metadata Crossref has. It’s a valuable education tool for publishers, institutions and other service providers looking to understand the availability of the metadata they have registered with us.

Through an itemized dashboard Participation Reports allows you to monitor the metadata you are registering, even if this work is done by a third party or another department. You can see for yourself where your gaps are, and what you could improve upon. Next to each metadata element, there’s a short definition, letting you know more about it, and—crucially—what practical steps you can take to improve the score.

The dashboard provides the percentage counts across ten key metadata elements: References, ORCID iDs, Funder Registry IDs, Funding award numbers, Crossmark metadata, License URLs, Text-mining links, Similarity Check URLs, and Abstracts.

And not only can you see your own metadata—the dashboard enables you to view the registered metadata of all our 11,076 members.

How are these 100 Million content records being used?

Every service we provide is based on our metadata, and our APIs expose all of that metadata. Over the past year or so we have been collecting use cases from members that actively utilize the Metadata APIs and have turned these into a Metadata APIs blog series so that we can share these stories of how our metadata is used with the wider community.

A big number. Even bigger ambitions.

Gaps or errors in metadata are passed on to thousands of other services, which causes problems downstream and means we all suffer. So it makes sense for the metadata you deposit to be as accurate and complete as possible. The more elements there are to the metadata, the higher the chance of others finding and using the content. We aim to continually find effective ways to communicate this wider story around the importance of open infrastructure and metadata.

Over the years we’ve made great progress in connecting information about researchers, their affiliations, grants, and research outputs. Imagine how much more powerful this information would be if supplemented by more comprehensive, accurate, and up-to-date metadata.

Sources - all data as of Sept 26, 2018
National Museum of China has 1,050,000 artifacts
The British Library has around 25 million books, more than any other library
Wikidata currently contains 50,290,632 items
NAPSTER currently has 40 million tracks (Napster is known as Rhapsody in the US)

Where does publisher metadata go and how is it used?

Laura J Wilkinson — Mon, 17 Sep 2018 00:00:00 +0000

Earlier this week, colleagues from Crossref, ScienceOpen, and OPERAS/OpenEdition joined forces to run a webinar on “Where does publisher metadata go and how is it used?”.

Stephanie Dawson explained how ScienceOpen’s freely-accessible, interactive search and discovery platform works by connecting and exposing metadata from Crossref. Her case study showed that articles with additional metadata had much higher average views than those without - depositing richer metadata helps you get the best value from your DOIs!

Pierre Mounier of OPERAS/OpenEdition showed us how a variety of persistent identifiers (PIDs) including DOIs, ORCID iDs, and Funder Registry IDs have been used on OA book platforms to improve citations, author attribution, and tracking of funding. He described a forthcoming annotations project with Hypothes.is, and explained how Crossref metadata is being used in both usage and alternative metrics.

Five ways to register content with Crossref

My overview of Content Registration outlined the five ways to register content with Crossref:

Via the manual web deposit form
Through Crossref’s new Metadata Manager tool (beta)
With OJS’s Crossref plugin - more information here (see OJS downloads Version 3.1.0 and above is the best option for supporting the fullest Crossref metadata)
With a manual XML upload file
Or, using HTTPS to POST XML

I also emphasized the importance of depositing, adding, and updating your metadata, and spoke about:

Basic citation metadata: titles, author names, author affiliations, funding data, publication dates, issue numbers, page numbers, ISSNs, ISBNs…
Non-bibliographic metadata: reference lists, ORCID iDs, license data, clinical trial information, abstracts, relationships…
Crossmark: errata, retractions, updates, and more
How important it is to have accurate, clean, and complete metadata
The importance of registering your back-year records

How to see the metadata you have

Anna Tolwinksa, Crossref’s Member Experience Manager, gave us an overview of the new Participation Reports tool. She explained how Participation Reports allows anyone to see the metadata Crossref members have registered with us, and how you can see for yourself where the gaps in your metadata are, and—importantly—how you can improve your coverage.

What we learnt

There are 10 key metadata elements or checks in Participation Reports that aid in Crossref members’ content discoverability, reproducibility and research integrity:
- References
- ~~Open References~~ [EDIT 6th June 2022 - all references are now open by default].
- ORCID iDs
- Funder Registry IDs
- Funding award numbers
- Text mining URLs
- License URLs
- Similarity Check URLs
Every day, research organisations around the world rely on metadata from Crossref, and use it in a variety of systems. Here are a few examples. Many organisations that enable research depend on Crossref’s metadata; we received over 650 million queries just last month
Crossref members should check Participation Reports to see what percentage of their content includes rich metadata If the percentages are low, Crossref is happy to work with you to help understand and improve your coverage
Richer metadata helps research to be found, cited, linked to, assessed, and reused
To make sure your work can be found!

Catch up with the webinar recording, and slides from Laura, Stephanie, Pierre, and Anna’s presentations, and please contact us if you have any questions.

Leaving the house - where preprints go

Jennifer Lin — Tue, 21 Aug 2018 00:00:00 +0000

“Pre-prints” are sometimes neither Pre nor Print (c.f. https://doi-org.pluma.sjfc.edu/10.12688/f1000research.11408.1, but they do go on and get published in journals. While researchers may have different motivations for posting a preprint, such as establishing a record of priority or seeking rapid feedback, the primary motivation appears to be timely sharing of results prior to journal publication.

So where in fact do preprints get published?

Although this is a simple question, we have not had an easy way to answer how this varies across disciplines, preprint repositories and journals. Until now. Crossref metadata provides not only an open and easy way to do so, but up-to-date data to get the latest results.

rOpenSci makin’ it sweet & easy

Crossref asks preprint repositories to update their metadata once a preprint has been published by adding the article link into its record via the “is-preprint-of” relation. As the record is processed, we make the link available going both directions, while preserving the provenance of the statement in the metadata output (“asserted-by”: “subject” or “asserted-by”: “object”). This results in bidirectional assertions in the Crossref REST API where search engines, analytics providers, indexes, etc. can get from the preprint to the article (“is-preprint-of”) as well as vice versa (“has-preprint”), making it easier to find, cite, link, assess, and reuse.

Using rOpenSci’s R library for the Crossref REST API (rcrossref), we pulled all articles connected to a previous preprint (https://api-crossref-org.pluma.sjfc.edu/works?filter=relation.type:has-preprint&facet=publisher-name:&rows=0) and then aggregated them based on journal via their ISSNs (https://api-crossref-org.pluma.sjfc.edu/works?filter=relation.type:has-preprint&facet=issn:), tallying the results in a tidy table with the journal name (ex: PLOS Biology (https://api-crossref-org.pluma.sjfc.edu/journals/2167-8359)).

The big reveal

So without further delay, let’s look at the results of the 20 journals with the highest number of preprints associated with its articles (data from August 21, 2018):

Publisher	Journal	Count
PeerJ	PeerJ	1184
Springer Nature	Scientific Reports	394
eLife	eLife	375
PLOS	PLOS ONE	338
Proceedings of the National Academy of Sciences	PNAS	205
PLOS	PLOS Computational Biology	196
Springer Nature	Nature Communications	187
PLOS	PLOS Genetics	169
The Genetics Society of America	Genetics	168
Oxford University Press	Nucleic Acids Research	148
Oxford University Press	Bioinformatics	138
The Genetics Society of America	Genetics	120
The Genetics Society of America	G3: Genes, Genomes, Genetics	104
Cold Spring Harbor Laboratory	Genome Research	104
Oxford University Press	Molecular Biology and Evolution	100
MDPI AG	Energies	98
MDPI AG	Sensors	96
Springer Nature	BMC Genomics	92
MDPI AG	International Journal of Molecular Sciences	86
JMIR Publications	Journal of Medical Internet Research	83

This list has not been normalized or weighted based on the size of the journal. The following observations are informed speculations, as we can only infer so much from the raw data:

Disciplinary practice: This phenomenon where preprints are a part of disciplinary practice accounts for about half of the journals represented on the list. Certain communities such as genetics and computational fields have been early adopters of preprints. As such, we see higher rates of preprint-to-article publication in journals that publish their work.
Partnerships: Partnerships that facilitate submission from the preprint repository directly to a publisher or peer review service (ex: BioRxiv B2J program) make it easier for researchers to move from preprint-sharing seamlessly to submitting their journal article manuscript.
Tie-ins: A quarter of the journals on the list are run by publishers with a preprint service, and have been able to tie together both arms of publishing. This removes barriers to journal article submission in the same manner as integrations between repositories and publishers, but does so as a single party.
Publisher support and treatment: We also see that strong proponents and early partners of preprint repositories tend to have higher counts. Some publishers have been more outspoken in their welcome of preprints, such as PNAS. Sometimes this support also comes in the form of special treatment. In the process of crafting editorial policy on publishing results previously posted in a preprint, some journals have carved out particular affordances in their publication workflow and content delivery streams that may contribute to the higher counts of articles. For example, Nature Research displays the preprints of submitted articles under consideration: https://nature-research-under-consideration-nature-com.pluma.sjfc.edu/.
Mega-journals: Mega-journals such as Scientific Reports and PLOS ONE have not discouraged preprints. As such, and due to the size of their publication output, they have easily found a place among the higher counts on the list.

Taking a closer look

One major consideration in these results, concerns what’s missing in the data. These fall into two camps: incomplete member data, and incomplete membership coverage.

We have been working with our members to deposit preprints using the proper record type, and to provide links to published articles in their metadata. However, not all have yet done so (ex: SSRN), leading to holes in our research nexus graph, which subsequently detracts from the completeness of the data.

We celebrate the preprint repositories who are required to update their metadata when an article is published from a preprint, thereby populating the map with critical bridges between preprints and articles. Crossref participation benefits not only the content owner, but the membership at large and all the systems across the research ecosystem powered by Crossref metadata.

Lastly, this data is dependent on the coverage of preprint repositories who register content with us. We are thrilled that Center for Open Science, our newest preprints addition who represents 21 community repositories, has recently filled in swaths of the map. But there remain dead zones in the research graph from repositories who are not Crossref members (ex: ArXiv). Their disciplines, as a result, are under represented in these results.

Everyone dive in!

As to the question of “where do preprints get published?”, anyone in fact can answer this question based on the metadata Crossref collects and provides to the community as an open infrastructure provider. We encourage the community to explore and analyze the data further with other available datasets to glean more insights on how scholarly communications is changing with the increasing growth of preprints. For example, the effective results across all journals represented can be weighted based on the number of articles published by each journal.

Crossref data is open for all to examine and reuse through our REST API. Please dive in and share your findings with us!

Preprints growth rate ten times higher than journal articles

Jennifer Lin — Thu, 31 May 2018 00:00:00 +0000

The Crossref graph of the research enterprise is growing at an impressive rate of 2.5 million records a month - scholarly communications of all stripes and sizes. Preprints are one of the fastest growing types of content. While preprints may not be new, the growth may well be: ~30% for the past 2 years (compared to article growth of 2-3% for the same period). We began supporting preprints in November 2016 at the behest of our members. When members register them, we ensure that: links to these publications persist over time; they are connected to the full history of the shared research results; and the citation record is clear and up-to-date.

Summary

As of May 24, 2018 we have 44,388 works (see API query https://api-crossref-org.pluma.sjfc.edu/types/posted-content/works with a json viewer) registered as posted content. Today that number is over 150k. Preprints are part of this record type category, which is meant to house scholarly outputs that have been posted online and intended for publication in the future.

For a more granular view, see the monthly stats captured by Jordan Anaya in PrePubMed. This data is based on a slightly different set of preprint repositories, though both show the same trends.

The figure below shows the preprints registered with Crossref, broken down by repository.

We eagerly await our newest preprints member, Center for Open Science, who will soon be registering the preprints from their 18 community archives with us (~9k preprints total to date).

Metadata coverage

We accept a range of metadata for the preprints registered with us, including:

Repository name & hosting platform
Contributor names & ORCID iDs
Title
Dates (posted, accepted)
License
Funding
Abstract
Relations
References

As with all resource/record types, certain metadata is required, though others are optional. We encourage full coverage of metadata in the record where applicable and possible. So what are publishers including in their posted content records? The summary view is as follows:

License: 9926 (json), 22% (PeerJ Preprints, ChemRxiv)
Funder: 0 (json), 0%
ORCID: 19309 (json), 44% (bioRxiv, PeerJ Preprints, Preprints.org, ChemRxiv)
Abstracts: 35874 (json), 81% (bioRxiv, PeerJ Preprints, ChemRxiv)
References: 1921 (json):, 4% (JMIR)

Compared to all the published content registered with us over time, preprints have above average coverage of ORCID iDs deposited and show well above average with abstract metadata. However, they are significantly lagging behind with depositing references, license, and funding metadata. (See a summary of the full corpus stats taken two months ago in the blog post, A Lustrum over the Weekend).

Preprint-article pairs

Members registering preprints have an obligation to update the metadata record when a journal article is subsequently published, to clearly identify this work. This pairing is passed on to our metadata users: indexing platforms; recommendations engines; platforms; tools, etc. which pull from our APIs. (The preprint landing page also must link to the article.) As such, the preprint-article pairings are amassing as each week passes. We currently have a total of 12983 (json) preprints connected to articles. The figure below provides the counts based on repository.

Citations

We can see from preprint Cited-by counts that researchers are indeed citing preprints in their articles. This practice is an extension of the common citation behavior to provide evidence for and credit to previous work, a natural consequence of work shared with their peers. The most highly cited preprint papers (json) as of May 24, 2018 are as follows. In some cases, a subsequent paper was published from the results shared in the preprint. These have also accrued citations in their own right and these are also indicated in the table below.

No.	Cited-by	Preprint DOI	Preprint title	Date	Subsequent journal article	Citations of journal article
1	Cited-by 72	https://doi-org.pluma.sjfc.edu/10.1101/005165	qqman: an R package for visualizing GWAS results using Q-Q and manhattan plots	May 14, 2014.	n/a	n/a
2	Cited-by 63	https://doi-org.pluma.sjfc.edu/10.1101/002824	HTSeq - A Python framework to work with high-throughput sequencing data	August 19, 2014	Bioinformatics, https://doi-org.pluma.sjfc.edu/10.1093/bioinformatics/btu638	2372
3	Cited-by 43	https://doi-org.pluma.sjfc.edu/10.1101/030338	Analysis of protein-coding genetic variation in 60,706 humans	May 10, 2016	Nature, https://doi-org.pluma.sjfc.edu/10.1038/nature19057	1598
4	Cited-by 38	https://doi-org.pluma.sjfc.edu/10.1101/002832	Moderated estimation of fold change and dispersion for RNA-seq data with DESeq2	November 17, 2014	Genome Biology, https://doi-org.pluma.sjfc.edu/10.1186/s13059-014-0550-8	3284
5	Cited-by 32	https://doi-org.pluma.sjfc.edu/10.1101/021592	Salmon provides accurate, fast, and bias-aware transcript expression estimates using dual-phase inference	August 30, 2016	Nature Methods, https://doi-org.pluma.sjfc.edu/10.1038/nmeth.4197	112
6	Cited-by 22	https://doi-org.pluma.sjfc.edu/10.1101/012401	DensiTree 2: Seeing Trees Through the Forest	December 8, 2014	n/a	n/a
7	Cited-by 21	https://doi-org.pluma.sjfc.edu/10.1101/011650	FusionCatcher - a tool for finding somatic fusion genes in paired-end RNA-sequencing data	November 19, 2014	n/a	n/a
8	Cited-by 19	https://doi-org.pluma.sjfc.edu/10.1101/048991	Analysis of shared heritability in common disorders of the brain	September 6, 2017	n/a	n/a
9	Cited-by 18	https://doi-org.pluma.sjfc.edu/10.1101/006395	Error correction and assembly complexity of single molecule sequencing reads	June 18, 2014	n/a	n/a
10	Cited-by 18	https://doi-org.pluma.sjfc.edu/10.1101/032839	Spread of the pandemic Zika virus lineage is associated with NS1 codon usage adaptation in humans	November 25, 2015	n/a	n/a

The relationship between preprints and the proceeding publication is an interesting area that is not yet well understood. We invite the community to analyze the Crossref metadata using the REST API in concert with other datasets. For example, the citation lifecycle for these two research products has been one of speculation so far without a systematic investigation into patterns and timeframes of preprint citations and those of its succeeding article across the corpus. Here, submission dates would be critical data to this research question as publication windows vary significantly by publisher and by paper.

How good is your metadata?

Kirsty Meddings — Thu, 26 Apr 2018 00:00:00 +0000

Exciting news! We are getting very close to the beta release of a new tool to publicly show metadata coverage. As members register their content with us they also add additional information which gives context for other members and for services that help e.g. discovery or analytics.

Richer metadata makes content useful. Participation reports will give—for the first time—a clear picture for anyone to see the metadata Crossref has. This is data that’s long been available via our Public REST API, now visualized.

Who are participation reports for? Everyone!

It’s an opportunity to evaluate and educate. See for yourself where the gaps are, and what our members could improve upon. Understand best practice through seeing what others are doing, and learn how to level-up.

Monitor what metadata is being registered, even if this work is done by a third party or another department. And see what other organisations in scholarly communications see when they use Crossref metadata in their research, tools, and services.

The beta release—expected after acceptance testing some time late May—will let anyone look up any of our 15,000+ members and see whether they are registering ten key elements that add context and richness to the basic required bibliographic metadata.

What do we mean by ‘richer metadata’?

The ten checks for Beta, will be:

References
~~Open references~~ [EDIT 6th June 2022 - all references are now open by default].
ORCID iDs
Funder IDs
Funding award numbers
Crossmark metadata
License information
Full text links
Similarity Check URLs
Abstracts

Each of these additional metadata elements helps increase discovery and wider and more varied use—and usefulness—of research outputs.

Why are we doing this and what do we mean by ‘participation’?

Over the years when we’ve talked with our members about their metadata, we learned that many just can’t be certain exactly how they’re performing. It could be that they’ve outsourced Content Registration to another service provider or larger publisher, or it could be they just weren’t previously aware they could collect and share authors’ ORCID iDs, Funder IDs, and so on. So our primary aim is to give our members the information they need in order to make a case for improving their metadata records. Each check will come with information about why it is important and guidance on how to improve. Additionally, with the growing use of Crossref as a central source of metadata for the research community, it’s in everyone’s interest to be as transparent as possible about what metadata we have - and encourage greater understanding of what’s possible.

Member ‘participation’ is an important concept. Crossref distinguishes itself from other DOI registration agencies by providing this richer infrastructure which allows for things like funding information, license information, links between data and preprints, and so on—all contributing to the research nexus for everyone’s benefit.

Membership of Crossref is not just about getting a persistent identifier for your content, it’s about placing your content in context by providing as much metadata as possible and looking after it long-term.

Here’s a sneak preview of what the report will look like:

So whether you’re a member who wants to run a “health check” on your own metadata, or a consumer of metadata interested in what’s available and from whom, watch this space for Participation Reports!

Would you like a heads-up on your report, pre-beta?

Beta will be released some time in May or June this year, following acceptance testing with members and others. Then we’re looking for about 20 members to have a half-hour phone call with a walk-through ‘health check’. Please contact Anna if you’d like to schedule one.

URLs and DOIs: a complicated relationship

Joe Wass — Fri, 04 Nov 2016 00:00:00 +0000

As the linking hub for scholarly content, it’s our job to tame URLs and put in their place something better. Why? Most URLs suffer from link rot and can be created, deleted or changed at any time. And that’s a problem if you’re trying to cite them.

Thus the Crossref DOI was born: an Identifier which is Persistent, which means that it’s designed to live forever (or, as Geoff Bilder rather more prosaically puts it, as long as we do), and also Resolvable, which means that you can click on it. A DOI is a URL, but it’s imbued with special properties. I say special, not magical, because all of the things that make Crossref DOIs what they are, are obtained through agreements and common standards rather than any kind of magic.

As part of the development of Crossref Event Data I’ve been doing some research about the relationship between DOIs and URLs. It’s a problem we have to solve in order to make Event Data work, but it’s a much broader and more interesting story, and the results have wide applicability. I’ll be telling this story at PIDapalooza. If you’re interested in Persistent Identifiers you should go and registration is open, though hurry, as it’s next week and in Rejkjavik, Iceland!

This is also a story in progress. As I write not all of the data is in, and we can be certain that it will evolve in ways we have no idea about. It’s also quite long but I’ll do my best to disqualify it from the bedtime reading list.

Full circle

Crossref was established just over fifteen years ago with the purpose of forming the linking hub between publishers. Our job was — and still is — to register content for publishers and then continue to work with them to ensure their DOIs always point to the right location of the content. To do this we need to do one main thing: send people in the right direction when they click on a DOI, and know which direction to point them in.

Today, linking is still an important part of what Crossref does, but we do a huge amount more. One of the new things we’re working on is Crossref Event Data. It’s a service for tracking how and where people use scholarly content (such as articles) across the web and social media. Early research suggested that if we limited ourselves to just looking for DOIs we wouldn’t find much. Instead we broadened our aims a little: rather than looking for mentions of registered content exclusively via their DOIs, we look for them via the most suitable mechanism. In most cases this means the actual URL of the Item. So we have come full circle: we started linking DOIs to URLs. Now we’re trying to link URLs back to DOIs.

Which URL are we talking about here? The Crossref Guidelines say:

DOI-routed reference links enabled by Crossref must resolve to a response page containing no less than complete bibliographic information about the target content …

http://www.crossref.org.pluma.sjfc.edu/02publishers/59pub_rules.html

This is what’s referred to as the Landing Page. Every Landing Page has a URL. Usually when you want to read information about an Article, it’s the Landing Page that you’re looking at. I should also say at this point that when I say Article I mean any item of Crossref Registered Content with a DOI. So the same applies to books, chapters, conference proceedings etc. But as most items are Articles, I’ll stick with that for now.

I’m going to make some assumptions. Unfortunately, and I don’t want to spoil the surprise here, they all turn out to be false. They’re all reasonable assumptions, though, and you would be forgiven for thinking, or at least wishing, that they were true.

So suspend your disbelief and follow me down the rabbit-hole…

Assumption 1: A DOI points directly to a Landing Page URL

When you click on a DOI you are taken to the Article Landing Page. It seems like a perfectly valid assumption to think that you are taken directly there.

The DOI system is essentially a big lookup table. In the first column is the DOI and in the second column is the URL. Publishers request that we register each item’s DOI and supply us with the URL it should point to. We work with CNRI and the International DOI Foundation to keep the system running and it means that when you, the reader at home, click on a DOI, you end up on the article’s Landing Page.

It would be very convenient if our assumption were true. If we wanted to turn a URL back into an article page, we could just swap the two columns and find the DOI by looking up the URL.

It turns out that it’s not quite so simple.

The Landing Page is under control of the publisher, as is the URL that they supply us with. They don’t need to supply us with the final landing page URL, only with one that leads to the landing page.

HTTP redirects

When you request a URL, either by typing it into your browser or by clicking on a link, your browser contacts the server and gets a reply. That reply can be “200 OK, here’s your page”, “303, look over there” or the dreaded “404, I can’t find it”. Other HTTP response codes are available, including well-known classics such as 201, 500 and 418.

If it’s a 303, your browser will follow the redirect URL. The response that comes back from that redirect could be another 303. You could end up following a whole chain of redirects. You wouldn’t notice anything, except having to wait an extra few milliseconds.

Extraordinary diversity

Crossref was created by a group of publishers who needed a way to link between articles. It was an ambitious goal: create a central system with which any publisher can integrate their own systems; one that allows linking to any article no matter who published it. Today we have over 5,000 members and counting, all contributing to our metadata engine. And up to 2 million DOIs are resolved every day, by all kinds of people and systems. Our wide range of members means a wide range of systems with a wide range of designs.

This brings an extraordinary diversity of behavior. If we want to make observations about DOIs we can’t just take a random sample of the over 80 million. Instead, we need to take a sample of DOIs per Publisher System. Even taking a sample per publisher might not do the job because some publishers run a variety of systems.

Experiment 1: Does Crossref know all Landing Pages?

By NASA / Paul Riedel (Great Images in NASA: Home - info - pic) [Public domain], via Wikimedia Commons

Hypothesis: Crossref knows the Landing Page URL for all DOIs.

For a sample of Items, we can follow the DOI link all the way through to the Landing Page, following any redirects, then compare the final Landing Page URL to the one that Crossref knows about. If there are extra redirects, that means that the one we have on file isn’t the final one.

We need to tighten up the terminology at this stage:

DOI URL - The full DOI, e.g. https://doi-org.pluma.sjfc.edu/10.5555/12345678 .
Resource URL - The URL that Crossref has on file (stored in our system). This is where the browser is initially redirected.
Destination URL - The URL that we end up at if we follow all the redirects.
Article Landing Page - The page that represents the item. If everything works, this should be the same as the Destination URL.

The reason we’re talking about the Destination URL as distinct from the Article Landing Page when they should be the same thing will become clear later. Consider yourself foreshadowed.

So let’s re-word our hypothesis:

Hypothesis: The Destination URL is the same as the Resource URL.

Method: A sample of DOIs was taken (most items updated in 2016, all from 2009 or earlier). The Resource URL was obtained for all of them. The DOIs were split by the domain name of the Resource URL (to give a good coverage of all Publisher systems). A sample of Resource URLs was followed per domain, at least 200 (or fewer if that exceeds the number of DOIs available). Where there were HTTP redirects they were followed.

Observations:

Number of Items sampled Destination URL: 253,381
Number where Resource URL = Destination URL: 46,995 or 19.96%

Conclusion: Not all Resource URLs are the same as the Destination URL by a long shot. Crossref does not automatically know every landing page URL.

Now we know the truth about our first assumption: DOIs don’t point directly to Landing Pages. If we want to reverse Landing Pages back into DOIs, we’re going to need to go a bit deeper…

Interlude

But first, an interlude with some information about publishers, owners, and systems, because now seems like the right time to do it.

Assumption 2: You can tell the publisher of a DOI by looking at its prefix

This is a real one one that people believe. Again, it’s entirely understandable. People look at a DOI like https://doi-org.pluma.sjfc.edu/10.1371/journal.pone.0136117.g001 , which takes them to PLoS and naturally assume that another DOI like https://doi-org.pluma.sjfc.edu/10.1371/journal.pone.0136053.t003 — because it has the same prefix of 10.1371 — is also for a PLoS item.

Whilst this turns out to be true most of the time, it’s not true for all Items, which makes it a dangerous assumption to make.

It is true that every publisher is given a prefix. They can then register DOIs with this prefix. It is also true that Items can be transferred between publishers. Because DOIs are persistent, the prefix in the DOI doesn’t change. So you might find a DOI that belongs to a publisher that has an unexpected prefix. Publishers can also be bought and sold, merged and split, which means that whilst most publishers have a single prefix, some, like Elsevier, have several. Take the case of Elsevier, who has 26 at the time of writing (you can see this in Elsevier’s entry in the Crossref Metadata API).

Every Item has an ‘owner prefix’ in addition to the prefix in the DOI. The owner prefix is the same as the DOI prefix when the Item is created, but over time, as articles are transferred, that can change to indicate that it is owned by another publisher.

Every Item has a DOI, and every DOI has a prefix. But every Item also has an Owner Prefix (you can check this in the Metadata API in the ‘prefix’ field).

So Assumption 2 has been laid to rest. The only thing you can tell from looking at a DOI is that it is, in fact, a DOI (you can tell by the “10.” index code).

Why do we care about identifying publishers anyway?

A Fair Test

We fundamentally want to conduct a fair test. The reason we can’t just take a random sample from the set of all DOIs is that there are lots of members who all do things slightly differently. Therefore we need to take a sample per publisher ‘system’. The word ‘system’ is a bit fuzzy, but my assumption is that two articles in the same system will behave the same way so we can treat them the same.

We also know that each Crossref member may be running more than one system, or a mixture. Therefore just looking at the owner of a DOI may not give accurate results if we want to conduct a survey of all the systems out there.

There’s no perfect answer, but the approach I’m taking is to look at the domain name of the Resource URL. We often find lots of subdomains for the same publisher, for example, “psw.sagepub.com”, “pol.sagepub.com”, “psx.sagepub.com” and “bpi.sagepub.com”. It’s clear that these are all operated by Sage, but they might or might not all be running on different ‘systems’.

Therefore I’m splitting DOIs up into groups based on the domain of their Resource URL. It may turn out that some publishers use a single system running on many domains, or it may turn out that some publishers use a different system for each domain they use. The key point is to find a sampling technique that broadly works, and that allows us to explore and differentiate, as keenly as possible, the variety of systems and behaviours.

Why all the redirects?

Curious minds might at this stage be wondering about all these extra redirects. Surely it’s extra stuff for the publisher to maintain. Why don’t they just point the DOI directly to the landing page?

The answer must be prefaced by repeating that there is a huge number of publishers, running a variety of systems, so we’ll never be able to completely answer that. But some humble suggestions:

They might want to be able to change the URLs of the Landing Pages. It may be easier to update their internal systems than send the update to Crossref, especially in bulk.
Different parts of their technology stack may be owned by different parts of the company, or outsourced. It’s easier to define internal boundaries than to co-ordinate business units and cross an external one.
A publisher may run a mix of different technology. As part of their systems integration process, they set up a redirect server to make everything work together.
A publisher assigns DOIs to articles but also has their own internal IDs. They maintain their own DOI-to-internal-ID lookup service.

Internal DOI resolvers

That last point is an interesting one. The DOI system is the canonical “DOI-to-URL resolver”. That doesn’t prevent publishers from running their own. Indeed, many do.

To take a real example of PLoS, an Open Access publisher who registers lots of content with Crossref. To follow one of their DOIs we go on the following journey of redirects:

http://dx.doi.org.pluma.sjfc.edu/10.1371/journal.pone.0164910
http://dx.plos.org/10.1371/journal.pone.0164910
http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0164910
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0164910

Given that the last step uses a DOI, this suggests that they use the DOI as an internal identifier. All those redirects were for some purpose, but they weren’t mapping a DOI to an internal ID. This is therefore not an internal DOI resolver.

Another example from JAMA Surgery:

In this case we see a mapping from the DOI 10.1001/archsurg.142.7.595 to the ID 487551.

Can we define a heuristic for this pattern? Yes, but not a perfect one. My test is this:

Does the resource URL contain the DOI?
If so, does it redirect to a different destination URL?
If so, does the destination URL not contain the DOI?

The last step is important, because we can’t really say the publisher is running a DOI resolver if they use the DOI all the way through.

It’s not perfect and no doubt has false negatives. But we’re just trying to find out whether some publishers run their own DOI resolver systems.

Experiment 2: Determine how widespread use of internal DOI resolvers is:

Hypothesis: Some publishers run their own DOI resolvers.

Method: A number of Destination URLs were sampled per Resource URL Domain. If the Resource URL contains the DOI but the Destination URL doesn’t, that’s marked as a Publisher DOI resolver redirect.

Observations:

Number of Items sampled with Resource URL and Destination URL: 253,381
Number of Items that appear to be DOI resolvers: 166,352 = 65.6%

Conclusions: Some publishers run their own DOI resolvers.

This isn’t of much practical use, but it’s interesting to know, and hints at the way the Crossref system and DOIs are integrated with Publishers’ systems. Now that we’ve got a little insight into the reasons that publishers might run their own DOI resolvers, we can resume our journey of assumptions.

Assumption 3: We can find the Landing Page for Every DOI

Now we know that we can’t just use the lookup table in reverse, but have to follow the links all the way to their destination. Does this approach actually work?

This is a pretty big question and we need to be clear about what we mean by ‘every’ DOI. The set of DOIs I’m using (although I’m using a subset) is “all DOIs in our Metadata API that are found in doi.org”.

What is a DOI? Geoff Bilder went over it in the DOI-like-strings blog post earlier this year. The definition I’m working to here is:

A DOI is an identifier for an item of content registered in the DOI system.

That is, if you resolve the DOI on https://doi-org.pluma.sjfc.edu/ and it’s recognised, that counts as a DOI. I’m working from the set of DOIs found in the Crossref system as I’m primarily concerned with Crossref DOIs. However, we collaborate closely with DataCite.

Back to our assumption: “we can find the Landing Page for every DOI”. The answer is that we can, most of the time. But because Crossref Event Data has to work as well as possible, and therefore work with as many DOIs as possible, we have to scour all the nooks and crannies.

Assumption 4: Every DOI points somewhere unique

Stop me when you find the deliberate mistake:

Every Item corresponds to a different thing
Every Item has a single DOI
Every DOI is different
Every DOI points to a landing page
Therefore every DOI points to a different landing page

Two things immediately suggest themselves:

“Every item has a single DOI” should be true, but it isn’t. We find that sometimes two DOIs are assigned to the same item. This can happen when publications change hands between publishers, or when mistakes are made, or for a variety of other reasons. We also find that in some cases Publishers registered a DOI for the metadata and one for the article abstract. The two DOIs point to the same place. In some cases where there were two DOIs registered for the same thing we create an Alias.

When we alias a DOI we simply say “this DOI should actually point to this one”. Both DOIs still exist, and both still point to the ‘correct’ thing, it’s just that they both point to the same place. If we have two DOIs pointing to the same place, then there isn’t a one-to-one mapping, and Assumption 4 is incorrect.

Experiment 4: Aliased DOIs

Hypothesis: There isn’t a one-to-one mapping between DOIs and URLs because some DOIs are aliased to others.

Method: We collected a sample of Resource URLs from the DOI API. We count how many DOIs are classified as Aliases in the DOI system.

Observations:

From a sample of 11,227,458 DOIs
14,566 are aliased to others, or 0.129%

Conclusion: There aren’t many aliases. But there are some, and we should be aware of them.

Experiment 5: Duplicate Resource URLs

Hypothesis: There isn’t a one-to-one mapping between DOIs and URLs because some DOIs have duplicate Resource URLs.

Method: A sample of Resource URLs was collected from the DOI API. We counted how many DOIs have Resource URLs that aren’t unique. We subtract the number of deleted DOIs because all deleted DOIs have the same resource URL.

Observations:

From a sample size of 11,227,458
a total of 112,195 have duplicate resource URLs, or 0.99%
of these duplicates, 77,896 have the ‘deleted’ URL
leaving 34,229, or 0.30% having non-unique Resource URLs

Conclusion: A small number of DOIs have duplicate Resource URLs, even if we exclude those that have been deleted, which means that not every DOI can have a unique URL.

Assumption 5: The Landing Page is the same as the Destination Page.

HTTP has a very neat system for doing redirects. If it were that simple, then we could easily look up every Destination page and confidently say that it was the Landing Page. Not so.

Cookies

Web browsers aren’t the only tools that use HTTP. Most programming languages have HTTP capabilities built in.

Using cookies is a requirement of some websites, but it’s not a requirement of HTTP. Most websites use cookies in some way or another. When you log into a site, you expect cookies. But when you’re just browsing there isn’t any technical need. A small number of websites absolutely require cookies to be enabled to use the site, even if you’re just browsing and not logged in. Unfortunately, this includes some publishers.

Requiring cookies to use a publisher site means that you can’t fully resolve a DOI without enabling cookies. Most tools out there don’t. Some privacy-conscious people quite reasonably don’t enable cookies from all sites.

Using cookies when resolving a DOI adds considerable overhead and isn’t fool-proof.

Let’s try a quick experiment to see when we land up on a cookie page. Here’s an example page that tells us that we should have enabled cookies: http://www-tandfonline-com.pluma.sjfc.edu/action/cookieAbsent . It’s reachable from the DOI: https://doi-org.pluma.sjfc.edu/10.1016/j.envhaz.2007.09.007 .

Experiment 6: Some DOIs can’t be resolved without cookies

Hypothesis: We can’t resolve some DOIs to the Landing Page using standard tools because cookies are required.

Method: A sample of DOIs was taken per Resource URL Domain. They were resolved by following HTTP links. Where the Destination URL contains the word ‘cookie’, we mark that as a DOI requiring a cookie.

Observations:

A sample of 253,381 DOIs were resolved following HTTP redirects where necessary
a total of 6305 resolved to a page with ‘cookie’ in the URL or 2.48%

Conclusion: There are cookies at play for at least 2.48% of DOIs. This is probably a very conservative estimate, as we’re using a blunt tool looking for ‘cookie’ in the URL.

Cookies Required

For one DOI I found, the publisher system set cookies, then sent us on a series of redirects which set cookies that expired in the past and then, as far as I can tell, checked whether or not they were sent back. My working hypothesis is that it was profiling the behaviour to see what browser I was using.

I have also seen javascript-based redirects. This is where a web page loads a javascript file, which executes and sends the browser onto another URL. This seems to be to be a browser detection method. There is no way you can follow these DOIs without actually using a real browser.

This is a problem for Crossref Event Data. We can’t fire up a browser and follow every DOI: it isn’t practical. When I tried this for a sample as an experiment I got an email from another publisher who was worried that we were scraping data (good bot operators always put contact details in their request headers!).

The Crossref member rules leave some wiggle-room about whether this is allowed, but for the Event Data service, we can say that it’s a physical impossibility to collect all Event Data for DOIs like this.

Bring in the Browser

To quantify the size of the problem, we need to bring in a web browser. If we assume that some Publishers design their sites to work only with real browsers, that’s what we’ll use. Luckily there are web browsers packaged up into an automatable package, and we can use these to visit the DOI.

Using one of these is considerably slower than just following link headers.

I have split the ‘destination’ concept into two:

Naïve destination URL: The URL that you get from following HTTP redirects acccording to the HTTP specification
Browser destination URL: The URL that you get from letting a browser follow the DOI doing whatever a browser does.

Rather than defining a complicated spectrum of types of DOI resolution behaviour, I am classifying DOIs into two groups: those where standard HTTP redirects are sufficient and everything else.

The method I am using is to resolve a sample of URLs using the browser. I can then compare the Naïve Destination URL with the Browser Destination URL. If they are the same, then I didn’t need to use the browser after all. If they give a different result however, I trust the Browser one better and declare that DOI to require a browser to resolve.

Again, I took a sample of DOIs per Resource URL domain.

Experiment 7: Quantify proportion of DOIs that require a browser to redirect

Hypothesis: A number of DOIs can’t be resolved with standard tools but instead require a browser.

Method: A sample of DOIs was selected per Resource URL domain. The links were followed using standard HTTP and using a browser. Where the URLs between the two were different, the DOI was counted as requiring a browser to resolve.

Observations:

A total of 59,453 items were followed both using the Naïve and Browser methods.
Of these 5,883 items have a different URL between the two methods, or 9.88%

Conclusion: We can’t rely on the Naïve redirect, and would have to fire up the browser in about 10% of cases in the sample.

Other gnarly things

There are one or two supplementary gnarly things that crop up.

First, session IDs are sometimes embedded in the URL. This is a tracking technique similar to cookies, but instead of sending cookies, which are invisible to the user, a unique code is placed on the end of the URL. This means that everyone gets a different URL. The most popular of these is the JSESSIONID, which is used by servers in the Java ecosystem. An example URL is:

http://onlinelibrary.wiley.com.pluma.sjfc.edu/doi/10.1002/047084289X.rn00615.pub3/abstract;jsessionid=0D1B7AC4689A494E0EA78BD2F0A710C4.f04t04

We can easily remove these if they appear at the end of a URL. Sometimes they occur in the middle of a URL, as above. Sometimes they appear as query parameters:

http://jpharmsci.org/action/consumeSharedSessionAction?SERVER=WZ6myaEXBLGvmNGtLlDx7g%3D%3D&MAID=npYBLvZTaUI3JTHw%2BH63WQ%3D%3D&JSESSIONID=aaajjhdDL5ssK6d1HHrFv&ORIGIN=207988872&RD=RD

In this case we make no attempt to remove them. These URLs won’t be any use for matching, and we have to acknowledge that and move on.

Interpreting the results

All the above experiments involved taking as many DOIs as we had time for, gathering the Resource URLs, and then grouping the DOIs per Resource URL Domain. A sample of DOIs was investigated per each Resource URL domain to give the best chance at even coverage. The above figures have been presented as a proportion of the sampled data-set.

Now it’s time to draw some practical conclusions. I grouped the results per Resource URL Domain, so I can say that “for this domain, X% of DOIs was deleted, or aliased, or whatever”. This means that we can look at the statistics for a given domain and work out the best method for working with DOIs that belong to it.

I have created histograms of domains by their various proportions.

Our first chart is histogram of Resource URL Domains where the Naïve Destination = the Resource URL. Each domain is given a proportion which represents how many DOIs sampled on that domain have a Landing Page equal to the Resource URL.

There’s a clear bimodal distribution here. The conclusion here is “most domains require you to follow the link to find the destination URL“. Furthermore, the domains are consistent: there are virtually no domains that have a mix of DOIs that behave differently.

Our second chart is a histogram of Resource URLs where the Browser-based redirect = the Naive URL. Each domain is given a proportion which represents how many DOIs sampled on that domain require us to fire up a browser.

Overwhelmingly, the Browser Redirect URL is the same as the Naïve Redirect URL, meaning that we don’t need to fire up the browser, we can just use the Naïve URL, which is much easier to compute. There are some resource URL domains which require every DOI to be followed in a browser rather than just following links.

We know from this that we don’t have to use the browser most of the time. There is a small number of domains where we’re unsure (under 500) and a small number of domains where we know that we have to use a browser. This means we can focus our efforts.

There are lots of DOIs and they all behave differently.

There are thousands of publishers out there registering DOIs. There are thousands of domains. Some publishers have lots of domains. This makes it impossible to make many general observations about DOIs.

You can’t tell anything by looking at the DOI

Just by looking at the DOI you can’t tell who published it, or which publisher’s system is hosting it. Therefore you can’t tell how it’s going to behave.

We’ve looked at five kinds of URLs:

The DOI itself
The Resource URL
The “naïve” redirect URL
The “browser” redirect URL
The Article Landing Page

In some cases, the Resource URL, naïve redirect URL, browser redirect and Article Landing Page are the same. In some cases they aren’t. Of these, the fifth is somewhat mythical.

DOIs fall into classifications

Each DOI falls into a category, most preferable first:

The Resource URL is the same as the Landing Page.
The Landing Page can be discovered by following HTTP redirects.
The Landing Page can be discovered by firing up a web browser to follow redirects.
The Landing Page can’t be determined.

We can predictively group DOIs

We can group DOIs by their Resource URLs and take a sample per Resource URL Domain. If all samples for a domain behave a certain way, we can place the DOIs into one of the above four groups with a probability.

We’ll never know the full story.

Because of the diversity of Publisher Systems and the long history of Crossref DOIs, we’ll never be able to describe exactly what’s going on for all DOIs.

What next?

We’re continuing to develop Crossref Event Data. The part of the system that handles turning URLs back into DOIs will never be perfect, but we know from this research that we can at least work with a subset.

I’m also working on another project which will attempt to reverse a Landing Page URL back into a DOI by looking at the metadata on the Landing Page. You can read about it here. Ultimately we’re going to have to take a blended approach. Building a useful set of Landing Page URL to DOI mappings will be part of the mix.

As Event Data matures we’ll be sharing all the datasets automatically as part of our infrastructure, including our DOI-to-URL mapping.

And any members reading, please make your DOIs as easy to follow as possible! Please don’t require JavaScript or cookies when resolving DOIs.

If you’re read this far, perhaps you’re as interested in DOIs as we are. There’s a lot more to say on the subject, but that’s enough for now. See you at PIDapalooza!

Image Credits

All images from Wikipedia Commons. Click or hover on the image to see the attribution.

Getting ready to run with preprints, any day now

Jennifer Lin — Tue, 16 Aug 2016 00:00:00 +0000

While preprints have been a formal part of scholarly communications for decades in certain communities, they have not been fully adopted to date across most disciplines or systems. That may be changing very soon and quite rapidly, as new initiatives come thick and fast from researchers, funders, and publishers alike. This flurry of activity points to the realization from these parties of preprints’ potential benefits:

Accelerating the sharing of results;

Catalyzing research discovery;

Establishing priority of discoveries and ideas;

Facilitating career advancement; and

Improving the culture of communication within the scholarly community.

To acknowledge them as a legitimate part of the research story, we need to fully build preprints into the broader research infrastructure. Preprints need infrastructure support just like journal articles, monographs, and other formal research outputs. Otherwise, we (continue to) have a two-tiered scholarly communications system, unlinked and operating independently.

Infrastructure for preprints

For this reason, the team at Crossref is extending its infrastructure services to allow members to register preprints. This new development is designed to provide custom support for preprints. It will ensure that: links to these publications persist over time; they are connected to the full history of the shared research results; and the citation record is clear and up-to-date. We established this preprints service to fully integrate preprint publications into the formal scholarly record with features such as:

Crossref membership for preprint repositories, joining the community of publishers who have made a commitment to maintain and connect scholarly publications.

Persistent identifiers for preprints to ensure successful links to the scholarly record over the course of time via the DOI resolver.

Content Registration for preprints with custom metadata that reflect researcher workflows from preprint to formal publication.

Notification of links between preprints and formal publications that may follow (journal articles, monographs, etc.).

Collection of “event data” that capture activities surrounding preprints (usage, social shares, mentions, discussions, recommendations, links to datasets and other research entities, etc.).

Reference linking for preprints, connecting up the scholarly record to associated literature

Auto-update of ORCID records to ensure that preprint contributors get credit for their work.

Preprint and funder registration to automatically report research contributions based on funder and grant identification.

Supporting utility & effectiveness of preprints for all

To build the service, we are listening to the research community tell us their vision of what preprints will do. We solicited use cases from the community and have built a registry of preprint user stories with researchers, publishers, funding agencies, tenure and promotion committees in academic institutions, and technology providers.

To realize the user stories, the research enterprise will no doubt need brand new tools and existing systems enhancements. Crossref’s preprints infrastructure will support the development of all needs currently registered. The community at large can focus on building effective solutions, instead of finding or securing access to data. All data are available without restriction to all so that participants as well the services and systems supporting them can access the data and reuse it for advancing early dissemination, literature discovery, research tracking, promotion and funding assessment, etc.

These are exciting days for scholarly communications. Over time, we envision an even more vibrant ecosystem of research outputs that include existing artefacts linked up to preprints. And Crossref is committed to providing infrastructure for the dynamic enterprise all along the way.

We plan to announce the availability of the preprints infrastructure and further technical details within the next few weeks. If you’re interested in learning more about how these will be supported, get in touch!

A fairer approach to waiting for deposits

Chuck Koscher — Wed, 20 Jul 2016 00:00:00 +0000

If you ever see me in the checkout line at some store do not ever get in the line I’m in. It is always the absolute slowest.

Crossref’s metadata system has a sort of checkout line, when members send in their data they got processed essentially in a first come first served basis. It’s called the deposit queue. We had controls to prevent anyone from monopolizing the queue and ways to jump forward in the queue but our primary goal was to give everyone a fair shot at getting processed as soon as possible. With many different behaviors by our members this could often be a challenge and at times some folks were not 100% happy.

We recently made a change where the queue now cycles through all waiting users and selects a job from each. This means that low-frequency users will always get a pretty fast service even if there are a lot of unique users waiting. Everyone gets one bite of the apple on each cycle through the waiting list. Of course, we still have some special controls to help deal with large quantities of files from a single user and ways to jump the queue under really special circumstances.

We believe this will, on average, yield a better experience and minimize the backups that formerly required administrator attention to resolve.

Hello preprints, what’s your story?

Jennifer Lin — Thu, 23 Jun 2016 00:00:00 +0000

The role of preprints

Crossref provides infrastructure services and therefore we support scholarly communications as it evolves over time. Today, preprints are increasingly discussed as a valuable part of the research story (beyond physics, math, and a small set of sub-disciplines). Preprints might play a positive role in catalyzing research discovery, establishing priority of discoveries and ideas, facilitating career advancement, and improving the culture of communication within the scholarly community.

As we shared in an earlier blog post last month, members will be able to register Crossref DOIs for preprints later this year. We will connect the full history of a research work, and ensure the citation record is clear and up-to-date. As we build out this new record/resource type, we’d love to hear how the research community envisions what preprints will do.

What’s your story, preprint?

So we can develop a service that supports the whole host of potential uses for all stakeholders, we ask the entire research community to contribute preprints user stories . User stories are concrete descriptions of a specific need, typically used in technology development: As a [x], I want to [y] to that I can [z]. User stories take the “end-user’s” perspective as they focus on a discrete result and its value. They are essential when implementing solutions that must meet a wide range of needs, across a diverse set of constituents. For example:

As an author, I want to share results before my paper is submitted to a journal so that I can get rapid feedback on it and make improvements before publication.

As a researcher who is part of a tenure and promotion committee or funder review panel, I want to know the reach of early results published from the candidate so that I can more quickly track the impact of results, rather than relying only on journal articles that take much longer to publish.

As a journal publisher, I want to know whether a preprint exists for a manuscript submitted to me so that I can decide whether I will accept the submission based on my editorial policy.

We aim to assemble a full catalog that cuts across research disciplines and stakeholder groups. We want to hear from you: researchers, publishers, funding agencies, scholarly societies, academic institutions, technology providers, other infrastructure providers , etc .

Tell us your story here

To ensure that your needs are included, please send us your user stories via this user story “deposit” form . They will be added to the full registry of contributions from the community, which we hope will serve as a key resource for all those developing preprints into a core part of scholarly communications (e.g., ASAPbio, etc.).

Community responses to our proposal for early content registration

Geoffrey Bilder — Tue, 01 Mar 2016 00:00:00 +0000

TL;DR:

We will proceed with implementing the proposed support for registering content before online availability. Adopting the workflow will be optional and will involve no extra fees.

Background

At the end of January, Crossref issued a “request for community comment” on a proposed new process to support the registration of content including DOIs before online availability. We promised that we would summarize the results of the survey once we had received and analyzed all the responses.

Support for Crossref implementing the proposed new workflow was overwhelming. Of the 104 responses, 90 were positive, 7 were neutral and 7 were negative. As such we will proceed to make the necessary changes to better support registering content before online availability. We aim to enable this functionality in the second half of 2016.

We received survey responses varying in length from one or two sentences to multiple pages. A lot of the responses also interspersed questions and observations about entirely different issues that were of interest to respondents. As such, it has taken a while for us to analyze the results. We also found it was pretty much impossible for us to tabulate a summary of the responses to the direct questions. Instead we’ll summarize the responses at a high level and then drill down into some of the nuances in the answers and issues that were raised from the responses.

The positive responses

By “positive” we mean the respondent understood the issues we were trying to address and thought what we were proposing was a reasonable way to address the problems. Here are a few (anonymized) excerpts from the responses:

“[This] is very timely as we have been made aware of changes to manuscript deposit requirements for UK authors. Authors who partake in the REF system will have to deposit articles at their manuscript stage before publication. We need to set an embargo on the articles so that they only become discoverable at some point after the publication date. Ideally we would like this to happen with all articles regardless of where they are from as authors will put their own work up on open access sites.”

“Your proposal and the associated workflow look good to us and will help with our media embargo timelines, as well as our authors’ institutional requirements.”

“The workflows and solutions seem reasonable … The temporary landing page seems like a sustainable technical solution. Hosting by Crossref is key to this – there is no way that all publishers would otherwise take on maintaining temporary pages. And having a standard display for metadata consistency is crucial too.”

“Early assignment and recording of DOIs from the point of acceptance forms a key step in [the university’s] proposed ‘Submit-accept-deposit’ workflow. We welcome the proposal by Crossref to enable early assignment of DOIs for publications.”

Note that a positive response did not mean the respondents thought the problems necessarily applied to them or that they would necessarily be implementing the changes - just that what we were proposing seemed sound for those who needed to address the issues.

“While not directly relevant to our business the proposal seems aimed to protect the integrity of DOIs and Crossref’s role and that is not a bad thing.”

“I would consider it an irresponsible use of the system on the part of a publisher to circulate dois that don’t (yet) work. This is bound to lead to frustration with users encountering errors. However I appreciate that this situation may arise in some workflows and therefore your proposals to implement temporary landing pages make sense.”

“I was not aware of these issues, but think that your solutions seem feasible. We are a small journal and generally don’t add doi’s or publish until the article is complete (i.e., we don’t post anything that’s just accepted - only finalized). So we would be unlikely to update our workflow.”

Also, though respondents might have been generally positive about the proposal - that didn’t always mean they were also sanguine about it. For example, several shared concerns about the potential costs of changing their workflows.

“[we] would consider implementing this change into our workflow. Limiting factors would include the effort and additional cost to enable our paper management system vendor…”

“My only comment is that the process needs to be streamlined as much as possible so small publishers without great technical capacity will not be burdened with twice the work or with additional expense. After reading through Crossref’s proposal, I believe you have taken such things into account and will implement an efficient and worthwhile system.”

“The workflow makes sense as a solution to the problem you describe […] but will require extensive workflow changes on our end in order to implement. Speaking for a small publishing house I’m not sure it’s reasonable to expect this from us on any short term.”

Several of the positive respondents also wondered about how we would handle particular edge cases (e.g. rescinding acceptances) and/or offered suggestions to improve the proposal. We will discuss these further at the end of this post.

The neutral responses

The responses we categorised as “neutral” were generally too short to conclude much about. They consisted of one or two sentences that said something like “this doesn’t apply to me.” It wasn’t clear whether it didn’t apply to them because they didn’t have the problems we described or because they’d already solved the problems we described (e.g. by providing their own interim landing pages). They also didn’t comment on the applicability to other members or whether they thought the issues might eventually affect them.

The negative responses

We categorised responses as “negative” when the member rejected that the issues we outlined were actual problems or they rejected the mechanisms we were proposing to address the problems.

“…a formal letter of acceptance on a letter in PDF will be OK for authors. Why a DOI is better?”

“…I am aware of funder and institutional requirements for authors to take action on acceptance of manuscripts for publication in journals but don’t think the time pressure is so high that it has to happen in short time between acceptance and published ahead of print online…”

“Of all the accepted-but-not-yet-published papers in existence at any time, the number whose existence must be demonstrated to promotion and tenure review boards must be awfully small.”

There are a few common themes here. The first is that, historically, the industry has been content with acceptance letters as proof of publication and that it was relatively rare for authors to have to produce such proof.

The problem that has led us to propose support for a modified workflow is that now we have situations where all the researchers in a country require such letters on a regular basis - not just when they are up for promotion or tenure. This is the new reality faced by researchers and institutions who are subject to regular national evaluation schemes like the REF and ERA.

One of the negative respondents added:

“This is very familiar territory. It’s definitely coming out of STEM.”

Indeed, the initial pressure to support the earlier registration of DOIs is certainly falling on our members who focus on STEM publishing. Researchers in the STEM fields are generally under more pressure to publish articles frequently and they are primarily affected by emerging funder mandates. The relatively high research output in STEM fields combined with the need for regular compliance checks and regular evaluation schemes is creating an environment that requires more automated mechanisms to keep track of publications. Asking for and processing letters of acceptance in these situations just doesn’t scale.

Some of the negative responses also questioned our assertions about the hazards of promulgating unregistered DOI-like strings and/or the problems associated with the delay between when content is made available online and when the content is registered.

“I don’t buy the argument that people lose trust in DOIs in general because they once tried to resolve one and it didn’t lead to an article. By the same argument, URLs in general are similarly undermined.”

“where authors ask me for their DOIs so they can accurately cite the paper in another publication or use it for grants and applications. I explain that it won’t work until the issue as a whole posts and I have never heard back about confusion or distrust of the system.”

To this all we can say is, we have the data. Next to typos, unregistered DOIs account for the second greatest category of failed resolutions on the Crossref system. Our help desk has to explain them to researchers constantly. We have promoted DOIs as being more robust, persistent identifiers than ordinary URLs. People are not surprised when URLs don’t work. They are surprised when DOIs don’t work. We’d like to keep it that way.

What seems to be at the the root of the few negative responses - is that most assumed that Crossref was mandating that publishers change their workflow - even if they didn’t face any of the issues outlined in the proposal. There is very little that Crossref mandates to participate. This is by design. Our membership is just too diverse for us to have mandates that can be sensibly applied to all. Still - we should have made it clearer in the proposal that the proposed changes would not be mandated. We will certainly need to make this clearer when we roll out support for the new processes.

Oh yeah - one respondent called us out for using the phrase “advanced publication” instead of “advance publication”. For this we are truly sorry. The employee who made this mistake has been dragged out and shotted.

Issues raised and questions asked

Both the positive and negative respondents raised issues, asked questions and provided suggestions regarding the proposal. We will make sure that, when the proposal is implemented, we address all of these issues more clearly, but in the meantime, we thought it would be helpful if we answered some of them briefly here.

Q: Would Crossref charge extra for the new workflow?

A: No. We should have made this clear in the proposal. We should have also mentioned that, in the “Crossref-facilitated Early Registration” scenario members will only be charged once they have replaced the “registered_content” metadata with metadata for the published item using one of the existing content schemas (e.g. article, book, confproc).

Q: Would Crossref require that publishers adopt the new proposed workflows?

A: No. But we will recommend them to members who need to address the issues outlined in the proposal. And in general, we will recommend that our members register DOIs as early in the process as practicable.

Q: What does “acceptance” mean? It was pointed out that there were lots of variations of “acceptance” including “acceptance pending revisions”, etc.

A: We would expect that “contingent acceptance” does not constitute final acceptance and that in this case “acceptance” should mean that the publisher has a copy of the manuscript in which the author has made all of the changes asked of them.

Q: Doesn’t “acceptance” works both ways? A researcher has to grant permission to publish to the publisher.

A: This is a vital point - the publisher should only register content for which they have already secured the rights to publish.

Q: Collecting and verifying the metadata associated with a paper is expensive and time consuming. As such, some publishers only produce complete and robust metadata after a paper has been accepted. We face a Catch-22. if we deposit metadata immediately after acceptance, it will be sparse and unreliable. If we wait to collect and verify the metadata, then we risk violating some of the emerging mandates. How do we resolve this dilemma?

A: This is clearly beyond our control, but we expect that those issuing the mandates will have to make some reasonable accommodations if they expect publishers to register content both early and with reasonably useful metadata.

Q: How would publishers handle rescinded acceptances?

A: Publishers can handle this the same way they handle retractions or withdrawals. Additionally, the registered record type and the “intent to publish” landing page will both support Crossmark for those members who use Crossmark to promulgate corrections to the literature. We will explore adding a new “acceptance rescinded” update type to the Crossmark schema.

Q: The Crossref DOIs we generate contain embedded publication information such as volume and issue. We don’t know these details at acceptance so how can we register DOIs early?

A: Many of our members generate Crossref DOIs with embedded semantic information in them such as volume/issue, publication date or even author initials and title. After 16 years of experience, we have found that this tends to be a bad idea. Publication schedules slip. Metadata changes. We will soon be revising our guidelines on DOI best practice in Crossref DOI generation to recommend against embedding such information into the DOI itself. Clearly, if you decide to assign Crossref DOIs at acceptance, you will need to adopt a DOI structure that accommodates this.

Q: Our hosting provider manages DOI registrations for us. If we have to register DOIs earlier in the process, can we have one party (e.g. a manuscript tracking system vendor) register the initial “registered_content” metadata and then have different party (e.g. hosting provider or typesetter) replace that record with the final metadata?

A: Yes.

Q: Will you be working with industry vendors to help them support this new workflow?

A: Yes.

Q: Will we support the pre-registration of DOIs in the the deposit forms on the Crossref site?

A: Yes.

Q: If Crossref hosts the “intent to publish” landing page, how will publishers be able to account for visits to the page and incorporate that information into their metrics?

A: While visitors to the Crossref hosted page will not show up in the publisher’s own hosting platform logs, publishers will be able to easily see how many times their “intent to publish” landing page was accessed by looking at their standard Crossref DOI resolution logs.

Q: Could the Crossref-hosted landing page also include the URL that the DOI will eventually be associated with?

A: This is an interesting idea and was suggested by two separate respondents. The challenge will be in explaining to the user that the URL might or might not work. We are also concerned that this would reduce the incentive for publishers to replace the holding page in a timely manner. We’ll explore this option as we continue to work on implementation.

Q: Would the Crossref-hosted landing page be open to indexing by Google and others? If so, wouldn’t this undermine articles under press embargoes?

A: The idea behind the limited metadata required for registering content is that it allows the publisher to control the balance between discovery (needed to meet funder requirements) and discretion (needed to manage publicity). So yes, the Crossref-hosted landing pages would be open to indexing, but publishers can still control what gets indexed by withholding metadata as needed.

Q: The table of required metadata elements for the “registered content” type does not include the author. How are such records supposed to be used as proof of acceptance if they do not include the author name?

A: ~~We made a mistake. The table should have included the contributor in the required element column.~~ Update: We retract our retraction! We are trying to accommodate several different use cases for ’early content registration’ and these different use cases often have contradictory metadata implications. So, for example, including the author is certainly important for monitoring mandate compliance. However, including the author might be problematic when the publisher is trying to manage publicity around an upcoming publication. Again, Crossref is not in a position to resolve this dilemma and we expect that those issuing the mandates will make some reasonable accommodations with publishers who need to manage publicity around publications. In short, “authors” will remain optional metadata.

Summary and conclusions

We were delighted with the response rate on the proposal. It is clear to us that a lot of the respondents really appreciated both being alerted to a set of issues that they were not yet aware of and that they valued the chance to comment on our proposed mechanisms for addressing said issues. We also learned some lessons on how to better structure any such future surveys in order to make them easier for us to summarise and respond to. The wide variety of responses and detailed descriptions of different workflows reconfirmed our sense that Crossref members vary widely in their working practices. We need to continue to work directly with members and understand these different working practices so that we can provide appropriately flexible services to our membership and to the scholarly community in general.

Finally, the feedback we received will be used by our product team and our communications & outreach teams to refine our rollout plans for registering content before online availability. We expect that we will rollout this functionality in the second half of 2016.

Thanks to those who responded to our RFC. Some of those responses included questions about other matters relating to Crossref. We have attempted to extract these and answer them directly- but if we have not yet answered one of your questions, please follow-up with us at feedback@crossref.org

Request for Community Comment: registering content before online availability

Ginny Hendricks — Thu, 21 Jan 2016 00:00:00 +0000

Crossref is proposing a process to support the registration of content—including DOIs and other metadata—prior to that content being made available, or published, online. We’ve drafted a paper providing background on the reasons we want to support this and highlighting the use cases. One of the main needs is in journal publishing to support registration of Accepted Manuscripts immediately on or shortly after acceptance, and dealing with press embargoes.

Proposal doc for community comment

We request community comment on the __proposed approach as outlined in this report.

Some examples of what we’d like to know:

Are you aware of the issues outlined in this proposal?
Are you aware of the funder and institutional requirements for authors to take action on acceptance of manuscripts for publication in journals?
Do you think the proposed solution and workflows are reasonable?
Are you likely to update your workflow to register content early?
If you are likely to update your workflow, how long do you estimate it will take?
Any other general comments, questions or feedback on anything raised in this document.

Please send comments, feedback and questions to me, Ginny, at feedback@crossref.org. The deadline for comments is February 4th. Thanks!

Content Registration on Crossref

Building, refining, and connecting: summary of our May 2026 community update

Operations, governance, and a growing membership

Introducing the Member Practices Working Group

Metadata schema

Tools and demos

Funder matching, rebuilt around ROR

Data citations API endpoint

Metadata Manager: new content types coming

Looking ahead

A new Service Providers Program

DOI resolution and deposit outage on 17 March 2026

Innovation in scientific publishing and its implications for Crossref DOI registration practices - MetaROR’s approach

DOI registration for articles on the MetaROR platform

Record type for articles on the MetaROR platform

Summary of MetaROR’s approach to Crossref DOI registration

Outlook

The sunset is on the horizon for Metadata Manager. What's next?

How did we get here?

What has happened since 2021?

Why is now the right time to retire Metadata Manager?

How will we avoid the new tool developing the same problems as Metadata Manager?

What happens next?

What options do I have for registering my journal content going forward?

If your journal has an ISSN

If your journal does not have an ISSN

How will the new tool continue to be developed?

References

Innovation in scientific publishing and its implications for Crossref DOI registration practices - Request for input

MetaROR

Crossref DOI registration

What is your take?

Scholarly blogs and their place in the research nexus

Why blogs deserve a place in the scholarly record

Eating our own dog food

What did we do?

How did we do it?

What does the future hold for scholarly blogs?

Solving your technical support questions in a snap!

A little about us and what drives the team

Snapping our fingers

Evans, Technical Support Specialist

Kathleen, Technical Support Specialist

Isaac, Technical Support Manager

Paul, Technical Support Specialist & R&D Support Analyst

Poppy, Technical Support Contractor

Shayn, Technical Support Specialist

Shooting for the stars – ASM’s journey towards complete metadata

Could you introduce your organisation?

Would you tell us a little more about yourselves?

What value do society publishers in general see in metadata in your view?

Metadata for your own research outputs in the last year has grown rapidly. Why such focus on metadata in 2022?

Has the OSTP memo influenced your effort?

How big was this effort? Could you draw us a picture of how many colleagues or parts of the organisation were involved? Did you involve any external stakeholders, such as authors, editors, or others?

What were the key challenges you encountered in this project, and how did you overcome them?

Have there been any important milestones along the way you were able to celebrate? Or any set-backs you had to resolve in the process?

Was any specific type of metadata or any part of the schema particularly easy or particularly difficult to get right in ASM’s production process?

What were your thoughts on last year’s move to open references metadata? Has that impacted on your project in any way?

How did you keep motivated and on-course throughout?

Now that the project is completed, are you seeing the benefits you were hoping to achieve?

Is there any metadata that you’d like to be able to include with your publishing records in the future that isn’t possible currently? What would it be and why?

What was the key lesson you learned from this project?

What’s your next big challenge for 2023?

Based on your experience, what would be your advice for colleagues from other scholarly publishing organisations?

About the American Society for Microbiology

Flies in your metadata (ointment)

Pagination faux pas

First page marked as 1

In the XML registered

Related REST API query

More on the problem

Other pagination errors

In the XML registered

More on the problem

In the XML registered

More on the problem

Author naming lapses

In the XML registered

Related REST API queries

More on the problem