Persistence on Crossref

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.

Calling all 24-hour (PID) party people!

Kathleen Luschek — Tue, 13 Oct 2020 00:00:00 +0000

While we wish we could be together in person to celebrate the fifth PIDapalooza, there’s an upside to moving it online: now everyone can participate in the universe’s best PID party! With 24 hours of non-stop PID programming, you’ll be able to come to the party no matter where you happen to be.

Send us your ideas for #PIDapalooza21

Now is your chance to share your work in the #PIDapalooza21 spotlight! We’re seeking proposals for short, interactive sessions about what you are doing––or want to do––with persistent identifiers and the communities that love and use them.

#PIDapalooza21 will feature sessions around the broad theme of PIDs and Open Research Infrastructure, focusing on the following areas:

Theme 1. PIDs 101

For PID beginners! You’ve got just 30 minutes to get attendees up to speed on a PID or PIDs. Make it fast! Make it fact-filled! Make it fun!

Theme 2. PID Communities International

Have you always wanted to host a Spanish-language PID session, or bring together PID people in the humanities? Tell us how you’d connect with PID peers around the world!

Theme 3. PID Success Stories

There’s nothing better than hearing about what’s working in the PID world––and why! Share your success stories so we can all benefit from them.

Theme 4. PID Party!

It wouldn’t be PIDapalooza without the party sessions, so be creative! Help us make this the best PID party ever!

Propose a session now!

The call for proposals will be open until October 30. Submit your PIDea now!

*Note: The PIDapalooza submission form uses Google. If you are unable to access Google Forms, email your session idea.

Get the full low-down on #PIDapalooza21 at the PIDapalooza website.

EASE Council Post: Rachael Lammey on the Research Nexus

Rachael Lammey — Mon, 12 Oct 2020 00:00:00 +0000

This blog was initially posted on the European Association of Science Editors (EASE) blog: “EASE Council Post: Rachael Lammey on the Research Nexus”. EASE President Duncan Nicholas accurately introduces it as a whole lot of information and insights about metadata and communication standards into one post…

I was given a wide brief to decide on the topic of my EASE blog, so I thought I’d write one that tries to encompass everything - I’ll explain what I mean by that.

In the past, Crossref has had the opportunity to talk to EASE members about the importance of registering content whose metadata contains important information related to the article. Richer metadata helps to connect the content to other key information such as who wrote it, who it was funded by, the relevant license, the research it cites, any updates to the work such as corrections and retractions, and the data that underpin the research. The use of open persistent identifiers like DOIs, funder IDs, ORCID iDs and ROR IDs are always recommended.

Such rich and connected metadata also helps discoverability of the published research in a different way than just direct access; if you can find something based on looking at the publications related to a particular funder, author, or institution, then there are more ways to come across what you’re looking for. Making links between objects underpinning the research also helps put the research in context and can help further research by making connections to other valuable information that may have been more difficult to make otherwise.

I’ve mentioned the Research Nexus in the title of this post. It’s achieved by declaring relationships between publications and other associated research objects, and from those objects to related publications. The metadata that reveals relationships between research objects can be as informative as the objects themselves. These relationships can assert certain facts that may not be otherwise obvious: this is our goal with the Research Nexus. These relationships and assertions need to exist not just on the web pages of the outputs, but also reflected in a standard way in the metadata so that the information is computer-readable and can be used at scale. As Jennifer Lin, who coined the term, explains:

“Researchers are adopting new tools that create consistency and shareability in their experimental methods. Increasingly, these are viewed as key components in driving reproducibility and replicability. They provide transparency in reporting key methodological and analytical information. They are also used for sharing the artefacts which make up a processing trail for the results: data, material, analytical code, and related software on which the conclusions of the paper rely. Where expert feedback was also shared, such reviews further enrich this record.”

In her Crossref blog, Jennifer goes on to give some examples, including:

Linking to an entire collection of methods and video protocols via Protocols.io
Linking to software and peer reviews in JOSS
Linking to preprint, data, code, source code, peer reviews in Gigascience

I’d include an additional example of linking research to the grant using the grant identifier and associated metadata from the funding section of this PLOS paper (read more about the example from EuroPMC who register grants with Crossref for Wellcome).

These links can be established by adding them into the Crossref relationship metadata schema. The information is then made available to anyone via our open APIs, so that they can easily see and use the information.

In all of these, publishers and other parties are linking to associated research outputs to support the reproducibility and discoverability of content.

The reproducibility point is worth reiterating; EASE has always supported projects to maintain high standards around the review of research, publication standards and ethics, and the reduction of research waste. And connecting articles to data, preprints, protocols, and peer reviews, and making the relationships open for analysis will help achieve this.

We also know that there are work and cost involved in establishing these links, and we’re working on ways to lower the barriers in doing so by:

Revisiting what we charge to encourage best practice. Starting in 2020, we have removed fees for registering vital information on corrections, retractions and other Crossmark metadata. This is timely in light of the updates to the EASE Standardised Retraction form.
We’re also working to remove fees for translations and versions that are linked together by the appropriate relationship metadata so that publishers posting translations or different versions of an article don’t have to pay multiple times for these. Our Membership & Fees Committee is currently reviewing other ways we can support publishers keen to make these connections.
Finding ways to make it easier for publishers to collect this information from authors e.g. submission systems integrations with data repositories to collect robust information on article/data links.
Allowing the registration of peer review metadata for content other than journal articles e.g. books, preprints (coming soon).
Making it easier for publishers to register this information with us at Crossref via the provision of simple to use tools, interfaces and reporting.

The outputs of the research process, such as journal articles, don’t exist in isolation - you only have to look at the interest in the corpus of COVID-19 publications, preprints and associated data to see this. This thinking is also supported by campaigns like Metadata 2020 advocating for “richer, connected, and reusable, open metadata will advance scholarly pursuits for the benefit of society.” The relationships revealed by the Research Nexus may one day help progress research to realise benefits that help us all, providing we all make efforts to effectively support them. More to come…

Crossref: the sustainable source of community-owned scholarly metadata

Dominika Tkaczyk — Wed, 01 Jan 2020 00:00:00 +0000

Crossref: The sustainable source of community-owned scholarly metadata

Published in Quantitative Science Studies (2020), this paper describes the scholarly metadata collected and made openly available by Crossref — its history, scale, content types, and role in the research ecosystem.

Strategists

Understand why Crossref metadata is foundational scholarly infrastructure. The history, governance, and community model that make Crossref a sustainable, neutral, member-owned source of scholarly data.

Decision-makers

Know what’s in the metadata and what it enables. 106 million records, 13 content types — not just bibliographic basics but funding, licences, citation links, corrections, and retractions.

Practitioners

Learn how to access Crossref metadata at scale. A technical overview of the REST API and OAI-PMH, with context on citation data provision and metadata quality trends.

What this paper covers

History and governance — how Crossref was founded in 2000 and why its member-owned, not-for-profit structure matters for long-term sustainability
Scale of the metadata set (in 2021) — over 106 million records across journals, conference papers, books, datasets, preprints, peer reviews, grants, and more
Richness beyond basic bibliographic data — abstracts, full-text links, funding and licence information, citation links, corrections, updates, and retractions
Role in the research ecosystem — how Crossref metadata directly supports scientometrics, research assessment, and scholarly communications research
APIs and access — the REST API and OAI-PMH as the primary routes to Crossref metadata at scale
Citation data — the evolution of Crossref’s citation data provision, including the move to open references
Metadata quality and curation — trends in completeness and accuracy over time, and plans for improvement

Read the full paper

Loading…

We'll be rocking your world again at PIDapalooza 2020

Ginny Hendricks — Sun, 18 Aug 2019 00:00:00 +0000

The official countdown to PIDapalooza 2020 begins here! It’s 163 days to go till our flame-lighting opening ceremony at the fabulous Belem Cultural Center in Lisbon, Portugal. Your friendly neighborhood PIDapalooza Planning Committee—Helena Cousijn (DataCite), Maria Gould (CDL), Stephanie Harley (ORCID), Alice Meadows (ORCID), and I—are already hard at work making sure it’s the best one so far!

We have a shiny [new website](https://pidapalooza.org), with loads more information than before, including spotify playlists (please add your PID songs to [the 2020 one](https://open.spotify.com/playlist/1oJtbpTzF9I3MewQ1Yasml?si=D0TKdR8BTJSL-GA3X_LwVQ)!), an instagram photo gallery, and of course registration information. Look out for updates there and on [Twitter](https://twitter.com/pidapalooza).

And, led by Helena, the Program Committee is starting its search for sessions that meet PIDapalooza’s goals of being PID-focused, fun, informative, and interactive. If you’ve a PID story to share, a PID practice to recommend, or a PID technology to launch, the Committee wants to hear from you. Please send them your ideas, using this form, by September 27. We aim to finalize the program by late October/early November.

Don’t forget to tie your proposal into one of the six festival themes:

Theme 1: Putting Principles into Practice

FAIR, Plan S, the 4 Cs; principles are everywhere. Do you have examples of how PIDs helped you put principles into practice? We’d love to hear your story!

Theme 2: PID Communities

We believe PIDs don’t work without community around them. We would like to hear from you about best practice among PID communities so we can learn from each other and spread the word even further!

Theme 3: PID Success Stories

We already know PIDs are great, but which strategies worked? Share your victories! Which strategies failed? Let’s turn these into success stories together!

Theme 4: Achieving Persistence through Sustainability

Persistence is a key part of PIDs, but there can’t be persistence without sustainability. Do you want to share how you sustain your PIDs or how PIDs help you with sustainability?

What would make heterogeneous PID systems ‘interoperate’ optimally? Would standardized metadata and APIs across PID types solve many of the problems, and if so, how would that be achieved? And what about the social aspects? How do we bridge the gaps between different stakeholder groups and communities?

Theme 6: PID Party!

You don’t just learn about PIDs through powerpoints. What about games? Interpretive dance? Get creative and let us know what kind of activity you’d like to organize at PIDapalooza this year!

PIDapalooza: the essentials

What? PIDapalooza 2020 - the open festival of persistent identifiers
When? 29-30 January 2020 (kickoff party the evening of January 28)
Where? Belem Cultural Center, Lisbon, Portugal (map)
Why? To think, talk, live persistent identifiers for two whole days with your fellow PID people, experts, and newcomers alike!

We hope you’re as excited about PIDapalooza 2020 as we are and we look forward to seeing you in Lisbon.

Request for feedback on grant identifier metadata

Patricia Feeney — Thu, 07 Feb 2019 00:00:00 +0000

We first announced plans to investigate identifiers for grants in 2017 and are almost ready to violate the first rule of grant identifiers which is “they probably should not be called grant identifiers”. Research support extends beyond monetary grants and awards, but our end goal is to make grants easy to cite, track, and identify, and ‘Grant ID’ resonates in a way other terms do not. The truth is in the metadata, and we intend to collect (and our funder friends are prepared to provide) information about a number of funding types. Hopefully we encompass all of them.

Our technical & metadata working group (a subset of the broader Funder Advisory Group) includes folks from Children’s Tumor Foundation, Europe PMC, European Research Council, JST, OSTI (DOE), Smithsonian, Swiss National Science Foundation, UKRI, Wellcome, as well as colleagues at DataCite and ORCID.

They have provided a wealth of funding data and feedback, and together we’ve come up with a metadata schema that works for us. Just as important - does this set of metadata meet your needs? Did we miss something? Let us know.

The details

For those of you familiar with Crossref Content Registration, Grant IDs will have their own dedicated schema that differs from our publication schema. The Grant ID schema will follow some of the same conventions as we’ll be using the same system to process the files (which will be XML) but since we are collecting metadata for a new community and moving beyond published content, this is an opportunity to rethink how we handle some basics like person names and dates.

Each Grant ID can be assigned to multiple projects. The metadata within each project includes basics like titles, descriptions, and investigator information (including affiliations) as well as funding information. Funders will supply funder information (including funder identifiers from the Crossref Funder Registry) as well as information about funding types and amounts.

A major accomplishment of the group was to develop a simple taxonomy of types of funding. Supported types are:

award
contract
grant
salary-award
endowment
secondment
loan
facilities
equipment
seed-funding
fellowship
training-grant
other

Funding involves more than monetary grants or awards and we’ve attempted to capture the broad categories of funding types. This list is taken from types of funding as defined by our participating funder organisations. We anticipate this list will evolve over time.

Ready to dig in? The schema and documentation are available on GitHub. We will actively take feedback until the end of February 2019. We hope to begin implementation soon after that. Please let us know what you think through GitHub, or feel free to contact me via feedback@crossref.org.

Zen and the Art of Platform Migration

Amanda Bartell — Mon, 28 Jan 2019 00:00:00 +0000

Nowadays we’re all trying to eat healthier, get fitter, be more mindful and stay in the now. You think you’re doing a good job — perhaps you’ve started a yoga class or got a book on mindfulness. And then, wham! Someone in your organisation casually mentions they’re planning a platform migration. I can sense the panic from here.

While the Holmes and Rahe Stress Scale doesn’t include platform migration as one of the top ten most stressful life events, we hear from our members that it should probably be in there somewhere. There’s so much to think about and plan for - how do you know you’re choosing the right platform partners for the future? How can you be sure that your understanding of what they offer really matches what you need? Will it make it easier for your readers to access your content? What about delays? What if it all breaks on changeover day?

Gaaaaah!

With all that to think about, worrying about whether your DOIs will resolve and what the migration will mean for the quality of your Crossref metadata just seems like an unnecessary layer of stress. It is, however, very important to consider this - even before you start thinking about who your platform partners will be. The process of working through these things up front could help you make better decisions, and set you up for success with the project and into the future.

So, to help you plan ahead, we’ve created a platform migration guide that offers guidance on things like:

What to consider even before you start selecting a new service provider
Planning the change over process
The change over itself (and what that means for your URLs)
What you should do after the migration is complete

The guide gives advice on how to plan for what you really need right now, and what you’re going to need in the future. For example, what metadata are you going to want to register with us and share with the thousands of industry organisations that make use of the data? What other Crossref services might benefit you in the future? What different record types are in your publishing plans?

The guide also has a handy checklist which you can include in your Request For Proposal documentation, to ensure that you’re asking the right questions of potential suppliers.

Once you’ve read the platform migration guide, let us know if there’s anything else you think we should add to it - we’re sure many of you have platform migration stories, and it’s good to share!

Presenting PIDapalooza 2019

Christine Cormack Wood — Tue, 28 Aug 2018 00:00:00 +0000

PIDapalooza, the open festival of persistent identifiers is back and it’s better than ever. Mark your calendar for Dublin, Ireland, January 23-24, 2019 and send us your session ideas by September 21.

Yes, it’s back and – with your support – it’s going to be better than ever! The third annual PIDapalooza open festival of persistent identifiers will take place at the Griffith Conference Centre, Dublin, Ireland on January 23-24, 2019 - and we hope you’ll join us there!

Hosted, once again, by California Digital Library, Crossref, DataCite, and ORCID, PIDapalooza will follow the same format as past events – rapid-fire, interactive, 30-60 minute sessions (presentations, discussions, debates, brainstorms, etc.) presented on three stages – plus main stage attractions, which will be announced shortly. New for this year is an unconference track, as suggested by several attendees last time.

In the meantime, get those creative juices flowing and send us your session PIDeas! What would you like to talk about? Hear about? Learn about? What’s important for your organisation and your community and why? What’s working and what’s not? What’s needed and what’s missing? We want to hear from as many PID people as possible! Please use this form to send us your suggestions. The PIDapalooza Festival Committee will review all forms submitted by September 21, 2018 and decide on the lineup by mid-October.

As a reminder, the regular themes are:

PID myths: Are PIDs better in our minds than in reality? PID stands for Persistent IDentifier, but what does that mean and does such a thing exist?
PIDs forever - achieving persistence: So many factors affect persistence: mission, oversight, funding, succession, redundancy, governance. Is open infrastructure for scholarly communication the key to achieving persistence?
PIDs for emerging uses: Long-term identifiers are no longer just for digital objects. We have use cases for people, organisations, vocabulary terms, and more. What additional use cases are you working on?
Legacy PIDs: There are of thousands of venerable old identifier systems that people want to continue using and bring into the modern data citation ecosystem. How can we manage this effectively?
Bridging worlds: What would make heterogeneous PID systems ‘interoperate’ optimally? Would standardized metadata and APIs across PID types solve many of the problems, and if so, how would that be achieved? What about standardized link/relation types?
PIDagogy: It’s a challenge for those who provide PID services and tools to engage the wider community. How do you teach, learn, persuade, discuss, and improve adoption? What’s it mean to build a pedagogy for PIDs?
PID stories: Which strategies worked? Which strategies failed? Tell us your horror stories! Share your victories!
Kinds of persistence: What are the frontiers of ‘persistence’? We hear lots about fraud prevention with identifiers for scientific reproducibility, but what about data papers promoting PIDs for long-term access to reliably improving objects (software, pre-prints, datasets) or live data feeds?

We’ll be posting more information on the PIDapalooza website over the coming months, as well as keeping you updated on Twitter (@pidaplooza).

In the meantime, what are you waiting for!? Book your place now – and we also strongly recommend that you book your accommodation early as there are other big conferences in Dublin that week.

PIDapalooza, Dublin, Ireland, January 23-24, 2019 - it’s a date!

PIDs for conferences - your comments are welcome!

Aliaksandr Birukou — Thu, 19 Apr 2018 00:00:00 +0000

Aliaksandr Birukou is the Executive Editor for Computer Science at Springer Nature and is chair of the Group that has been working to establish a persistent identifier system and registry for scholarly conferences. Here Alex provides some background to the work and asks for input from the community:

Roughly one year ago, Crossref and DataCite started a working group on conference and project identifiers. With this blog post, we would like to share the specification of conference metadata and Crossmark for proceedings and are inviting the broader community to comment.

Why are conferences important?

One common misbelief is that most published research appears in journals. However, next to new ways of communication research results (blogs, presentations,…) and journals there are also other publication options, like books, very important in humanities, or conference proceedings, which are very important in computer science and a couple of related disciplines. Conference proceedings are collections of journal-like papers, often undergoing a more competitive peer review process than in journals. For instance, looking at original research in computer science in Scopus published in CS in 2012-2016, 63% of articles appeared in proceedings, while only 37% were published in journals. DBLP, one of the most important indexing services in CS, lists more than two million conference papers organized in ~5,400 conference series.

So, while it is true that CS has a significant share of conference proceedings, conferences are also relevant in many other disciplines which do not publish formal proceedings. For instance, inSPIRE contains ~23,000 conferences in high-energy physics, the American Society of Mechanical Engineers (ASME) publishes roughly 100 proceedings volumes annually.

Why do we need an open persistent ID for a conference or a conference series?

With publishers, learned societies, indexing services, libraries, conference management systems, research evaluation and funding agencies using conferences directly or indirectly in their daily work, a common vocabulary would simplify data processing, reporting and minimize errors. Right now, a publisher assigns a unique conference ID to the conference to be published, then an indexing service does it, then it is assigned in a library. Wouldn’t it be easier to do this at the very beginning of the process, when the conference planning starts, and keep the same identifier through the whole conference lifecycle?

The joint Crossref and DataCite group on conference and project identifiers has discussed this topic at half a dozen calls and various PID community meetings (PIDapalooza, FORCE conferences, AAHEP Information Provider Summit). The result of those discussions is a draft of the specification of conference metadata and Crossmark for proceedings.

The document first defines the concepts of a conference, conference series, joint and co-located conferences. It then introduces the information we want to store about those entities, e.g., the ID, name, acronym, other IDs, URL and the maintainer of the conference series, or the ID, conf series ID, number, dates, location, and URL for conferences. Such metadata can be submitted to Crossref and DataCite by conference organizers or publishers on their behalf and linked to the existing proceedings metadata, where appropriate. It can be then used for linking research outputs from a conference (beyond formal proceedings), recognizing reviewers via services such as ORCID and Publons, computing metrics of a conference series, conference disambiguation in indexing services and ratings (CORE, QUALIS, CCF), and so on.

The second part of the document introduces Crossmark for conference proceedings. Its goal is to structure and preserve the information about the peer review process of a conference as declared by the general or program chairs. Depending on how much information is available from the conference organizers, one can use the basic or extended versions of Crossmark.

In order to comment, please open the specification and leave comments using “comment” feature of Google Docs. The draft remains open for comments till the 31st of May 2018.

Next steps

After hearing from YOU, we will update the document to reflect the community comments. In parallel, we start a subgroup discussing the governance models, looking into whether we need a new membership category at Crossref, what fees should be covered, etc.

Wellcome explains the benefits of developing an open and global grant identifier

Ginny Hendricks — Fri, 16 Feb 2018 00:00:00 +0000

Wellcome, in partnership with Crossref and several research funders including the NIH and the MRC, are looking to pilot an initiative in which new grants would be assigned an open, global and interoperable grant identifier. Robert Kiley (Open Research) and Nina Frentrop (Grants Operations) from the Wellcome explain the potential benefits this would deliver and how it might work.

Introduction

As a funder we want to be able to track the outputs that arise from research we have funded. Currently, this is not as straightforward as it should be as researchers do not always cite their funder correctly, let alone their specific grant number. And, even when they do this accurately, because every funder users its own set of grant IDs, these numbers are not unique. For example, we can use EuropePMC to look up outputs from grants with ID 207467, and see that there is one Wellcome grant with this number, and one from the European Research Council.

To resolve such issues, we need a system in which every grant awarded is giving a unique, global ID. Global IDs are already assigned to articles DOIs, people ORCIDs and even biological materials RRIDs. It is time for the funder community to follow suit.

Benefits of an open & global grant identifier system

Once implemented, it would make the identification of grant-specific research outputs more accurate, whilst simultaneously reducing the burden on the researcher.

Currently, researchers are typically asked to manually disclose what outputs have arisen from their funding. In the future, such disclosures would be fully automated. We are already seeing how publishers—who collect ORCIDs through their manuscript submission system—automatically update the author’s ORCID record with details of new publications. If a global ID system for grants was developed, publishers and repositories could also require these to be disclosed on submission, and this data could then programmatically be passed to researcher assessment platforms, like ResearchFish.

How would it work?

For a global grant ID system to work, two things need to happen. First, when a new grant is awarded, that grant must be assigned a unique ID. For the pilot project we plan to contract with Crossref who will register a unique ID, (a DOI) for every grant we register.

Second, every DOI must resolve to a publicly accessible web site, where information about that grant is disclosed. Again, for this pilot we will almost certainly use the Europe PMC Grants Finder Repository, as we already make grant data available from this resource.

A working group has been established to determine precisely what metadata we should make available, but it is likely to include the name of the grant holder, title and value of the award, a short abstract, along with the name of the funder and the unique ID. Mindful that funders already assign IDs to the grants they award and that any changes to this process may be problematic (and certainly time consuming), the plan is to register a DOI which still makes use of the existing grant ID. To make it unique however, the ID will be prefixed with a funder identifier, most likely the Funder Registry ID.

Next steps

Whilst the metadata working group is focusing on the technical aspects of the pilot, a separate “governance group” is examining how a funder might become a member of Crossref and what the business model for registering grant DOIs should be.

In parallel with this, a pilot “proof of concept” initiative is under way, and we anticipate that by autumn 2018 we will have registered DOIs for a defined cohort of grants.

Ultimately we want to get to a situation where every grant has a unique ID, which can then be unambiguously linked to the all outputs – articles, data, code, materials, patents etc. – which arise from it.

And, if every funder were to adopt such a system and expose their grant metadata in a consistent, machine-readable way, it would facilitate the development of applications to help funders get a greatly enhanced picture of the global funding landscape, which in turn would inform strategic planning and resource allocation.

Thanks to guest authors:

Robert Kiley, Head of Open Research, Wellcome [ORCID: 0000-0003-4733-2558] Nina Frentrop, Grants Information & Systems Manager, Wellcome

Please read Crossref for funders for context, and contact Ginny Hendricks at Crossref with any questions.

The PIDapalooza lineup is out; come rock out with us at the open festival of persistent identifiers

Ginny Hendricks — Fri, 01 Dec 2017 00:00:00 +0000

PIDs’R’Us and if they’re you, too, please join us for the second PIDapalooza, in Girona, Spain on January 23-24, for a two-day celebration of persistent identifiers.

Together, we will achieve the incredible - make a meeting about persistent identifiers and networked research fun! Brought to you by California Digital Library, Crossref, DataCite, and ORCID, this year’s sessions are organized around eight themes:

PID myths
Achieving persistence
PIDs for emerging uses
Legacy PIDs
Bridging worlds
PIDagogy
PID stories
Kinds of persistence

The program is now final and there really is something for everyone (well, every PID geek)

Hmm, Do Researchers Need to Care about PID Systems? Excellent question.
We’ll hear Stories from the PID Roadies: Scholix.
Nevermind the The Bollockschain and other PID Hallucinations.
An intriguing session on #ResInfoCitizenshipIs?.
There will be a plenary by Johanna McEntyre on As a biologist I want to reuse and remix data so that I can do my research.
And we’ll enjoy another plenary from Melissa Haendel (title to be confirmed).

With half the places already booked, now’s the time to register and plan your trip. We hope to see fellow festival-goers there for some PIDtastic party time (and actually some epic serious conversations).

Contact me via the steering committee at PIDapalooza@datacite.org with any questions, music requests, or backstage passes.

Full lineup

View the Crossref LIVE17 agenda.

PIDapalooza is back and wants your PID stories

Ginny Hendricks — Thu, 14 Sep 2017 00:00:00 +0000

Now in its second year, this “open festival of persistent identifiers” brings together people from all walks of life who have something to say about PIDs. If you work with them, develop with them, measure or manage them, let us know your PID adventures, pitfalls, and plans by submitting a talk by September 18. It’ll be in Girona, Spain, January 23-24, 2018.

One of the great strengths of last year’s PIDapalooza was the number of people who spoke and all the conversations that were kindled. So if you’re thinking of going, we encourage you to propose a talk, so we can hear what you’re working on and you can get some feedback.

At the inaugural PIDapalooza event Crossref took to the stage twice, with Ed Pentz covering Org IDs and Joe Wass talking about Event Data.

Here we have Joe’s memories of the event and Ed’s update on the Org ID status.

Joe Wass reflects:

At Crossref, the subject of Persistent Identifiers is something we care deeply about, and linking between DOIs, ORCID iDs and other identifiers is the reason we get up in the morning. But a whole conference dedicated to them? If I’m honest, the first time I heard about PIDapalooza I thought the subject was rather niche.

How wrong I was. It turns out there are people from all walks of life who care about “things” using persistent identifiers to link, describe and reference them. There was a great balance between presenters and attendees, and the programme meant that lots of people had a chance to speak. We heard about identifiers for research vessels, pieces of scientific equipment, individual bottles of milk, plus the usual subjects like scholarly publishing, datasets, organisations and funders, and how to cite them.

Between sessions we chatted over a wide range of subjects, noted similarities between subject areas, offered advice and exchanged ideas. Who knew this stuff was all related?

Ed Pentz on plans for the new organisation IDs

An important presentation at the 2016 PIDapalooza meeting was on organisation identifiers. A week before the conference Crossref, DataCite and ORCID released three documents for public comment outlining a proposed way forward. The goal is launch and sustain an open, independent, non-profit organisation identifier registry to facilitate the disambiguation of researcher affiliations. At the packed PIDapalooza session Crossref, DataCite and ORCID gave an update on their work over the previous year and their proposals going forward.

There was a lively discussion and debate about the issues. Following the meeting the three organisations set up the OI Project Working Group with a broad group of stakeholders. The group has been meeting over the last year and will release two documents next week - a set of Governance Recommendations and Product Principles and Recommendations for community feedback. So watch this space.

The PIDapalooza conference really helped galvanize the work in this area by bringing together a broad range of people interested in persistent identifiers. If you have an idea about PIDs, please come and tell us about it.

Check out the decks from last year's talks, the PIDapalooza website with all the info, and sumbit a proposal for your talk before September 18.

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.

Preprints are go at Crossref!

Rachael Lammey — Wed, 02 Nov 2016 00:00:00 +0000

We’re excited to say that we’ve finished the work on our infrastructure to allow members to register preprints. Want to know why we’re doing this? Jennifer Lin explains the rationale in detail in an earlier post, but in short we want to help make sure that:

links to these publications persist over time
they are connected to the full history of the shared research results
the citation record is clear and up-to-date

Doing so will help fully integrate preprint publications into the formal scholarly record.

What’s new?

We’ve had to do some work on our own infrastructure to facilitate the inclusion of preprints, enabling:

Crossref membership for preprint repositories by updating our membership criteria and creating a policies for preprints
The deposit of 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 (this custom metadata will then be visible to anyone using the Crossref metadata).
Notification of links between preprints and formal publications that may follow (journal articles, monographs, etc.).
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.
It will also allow for the collection of “event data” that capture activities surrounding preprints (usage, social shares, mentions, discussions, recommendations, links to datasets and other research entities, etc.).

Now we’re ready to go!

Early adopters

We have been working with various preprint publishers who are launching (or planning to launch) their own preprint initiatives.

Preprints.org is the first to successfully make preprints deposits using the dedicated schema. For example, this preprint https://doi-org.pluma.sjfc.edu/10.20944/preprints201608.0191.v1 is registered with Crossref. It is linked to a published journal article https://doi-org.pluma.sjfc.edu/10.3390/data1030014 both in the online display as well the preprint’s Crossref metadata record. Others are getting ready to go - will your organisation be next? (Technical documentation available here.)

Martyn Rittman, from Preprints, operated by MDPI said: Preprints.org is delighted to be the very first to integrate the Crossref schema for preprints. We believe it is an important step in allowing working papers and preliminary results to be fully citable as soon as they are available. It also makes it easy to link to the final peer-reviewed version, regardless of where it is published. Thanks to the hard work of Crossref and clear documentation, the schema was very simple to implement and has been applied retrospectively to all preprints at Preprints.org.

Jessica Polka, Director, ASAPbio adds: ASAPbio is a scientist-driven community initiative to promote the productive use of preprints in the life sciences. We’re thrilled to see Crossref’s development of a service that enables preprints to better contribute to the scholarly record. This infrastructure lays a necessary foundation for increasing acceptance of preprints as a valuable form of scientific communication among biologists.

Questions?

Get in touch with any questions or comments, or join our upcoming webinar to talk about preprints, infrastructure and where we go from here.

Announcing PIDapalooza - a festival of identifiers

Ginny Hendricks — Tue, 30 Aug 2016 00:00:00 +0000

The buzz is building around PIDapalooza - the first open festival of scholarly research persistent identifiers (PID), to be held at the Radisson Blu Saga Hotel Reykjavikon November 9-10, 2016.

PIDapalooza will bring together creators and users of PIDs from around the world to shape the future PID landscape through the development of tools and services for the research community. PIDs support proper attribution and credit, promote collaboration and reuse, enable reproducibility of findings, foster faster and more efficient progress, and facilitate effective sharing, dissemination, and linking of scholarly works.

We believe that by bringing together everyone who’s working with PIDs for two days of discussions, demos, workshops, brainstorming, updates on the state of the art, and more, we can make this happen faster. And you can help by giving us your input on which sessions would be most valuable. Please send us your ideas, using this form by September 18. We will send session proposal notifications the first week of October with the festival lineup.

Register to attend

Registration is now open — come join the festival with a crowd of like-minded innovators. And please help us spread the word about PIDapalooza in your community!

Stay updated with the latest news on on the PIDapalooza website and on Twitter (@PIDapalooza) in the coming weeks.

Looking forward to seeing you in November!

The article nexus: linking publications to associated research outputs

Jennifer Lin — Thu, 25 Aug 2016 00:00:00 +0000

Crossref began its service by linking publications to other publications via references. Today, this extends to relationships with associated entities. People (authors, reviewers, editors, other collaborators), funders, and research affiliations are important players in this story. Other metadata also figure prominently in it as well: references, licenses and access indicators, publication history (updates, revisions, corrections, retractions, publication dates), clinical trial and study information, etc. The list goes on.

What is lesser known (and utilized) is that Crossref is increasingly linking publications to associated scholarly artifacts. At the bottom of it all, these links can help researchers better understand, reproduce, and build off of the results in the paper. But associated research objects can enormously bolster the research enterprise in many ways (e.g., discovery, reporting, evaluation, etc.).

With all the relationships declared across all 80+ million Crossref metadata records, Crossref creates a global metadata graph across subject areas and disciplines that can be used by all.

Research article nexus

As research increasingly goes digital, more research artifacts associated with the formal publication are stored or shared online. We see a plethora of materials closely connected to publications, including: versions, peer reviews, datasets generated or analysed in the research, software packages used in the analysis, protocols and related materials, preprints, conference posters, language translations, comments, etc. Occasionally, these resources are linked from the publication. But very rarely are these relationships made available beyond the publisher platform.

Crossref will make these relationships available to the broader research ecosystem. When publishers register content for a publication, they can identify the associated scholarly artifacts directly in the article metadata. Doing so not only groups digital objects together, but formally associates with the publication. Each link is a relationship and the sum of all these relationships constitutes a “research article nexus.”

An assortment of connections already abound in the wild today. Examples include:

F1000Research article http://doi.org.pluma.sjfc.edu/10.12688/f1000research.2-198.v3 connected to initial version http://doi.org.pluma.sjfc.edu/10.12688/f1000research.2-198.v1

OECD publication http://dx.doi.org.pluma.sjfc.edu/10.1787/empl_outlook-2014-en and its German translation http://dx.doi.org.pluma.sjfc.edu/10.1787/empl_outlook-2014-de

PeerJ article http://doi.org.pluma.sjfc.edu/10.7717/peerj.1135 and its peer review http://doi.org.pluma.sjfc.edu/10.7287/peerj.1135v0.1/reviews/3

eLife article http://doi.org.pluma.sjfc.edu/10.7554/eLife.09771 and its BioArXiv preprint http://doi.org.pluma.sjfc.edu/10.1101/018317

PLOS ONE article http://doi.org.pluma.sjfc.edu/10.1371/journal.pone.0161541 with underlying data in Dryad http://doi.org.pluma.sjfc.edu/10.5061/dryad.d2vf8

Frontiers article http://doi.org.pluma.sjfc.edu/10.3389/fevo.2015.00015 with a figshare http://doi.org.pluma.sjfc.edu/10.6084/m9.figshare.1305089.v1 video

Journal of Chemical Theory and Computation article http://doi.org.pluma.sjfc.edu/10.1021/ct400399x with software archived in Zenodo http://doi.org.pluma.sjfc.edu/10.5281/zenodo.60678

Nature Biotech article http://doi.org.pluma.sjfc.edu/10.1038/nbt.3481 with a Protocols.io protocol http://doi.org.pluma.sjfc.edu/10.17504/protocols.io.dm649d

To date, almost all these relationships are not directly recorded in the article metadata (great job, PeerJ!). And as a result, they are more than likely “invisible” to the broader scholarly research ecosystem. Publishers can remedy these gaps by depositing associations when registering content with Crossref or updating the records after registration. That is how the article nexus is formed.

(Associated datasets can also be identified in the reference list as per Joint Declaration of Data Citation Principles as with the FORCE11 Software Citation Principles. Stay tuned next week for a follow up blog post on Crossref’s support for publisher data and software citations through its metadata.)

Forming the nexus

The mechanism of declaring these relationships is straightforward and a longstanding part of the standard deposit process. For each associated research object, simply provide the identifier and identifier type for the object, an optional description of it, as well as name the relationship into the metadata record. For the latter, Crossref and DataCite share a closed list of relationship types, which ensures interoperability between mappings. See Crossref technical documentation for more details.

We maintain a list of the recommended relation types for a host of associated research objects to promote standardization across publishers. If you have relationships not specified, please contact us at feedback@crossref.org to identify a suitable one considered best practice. Common adoption of relation types will make relationship metadata useful to tool builders and systems. For example, programmatic queries on supporting materials require proper tagging of their respective relationship types.

This approach is highly extensible and accommodates the introduction of new research object forms as they emerge. It also supports associated research objects regardless of identifier type. When an associated entity has a DOI, however, we can validate the relationship during metadata processing as well as provide a more reliable representation of the article nexus.

Article nexus: a far richer scholarly map

Bibliographic metadata is like a ship’s manifest that catalogs each item of cargo in a ship’s hold - crate, drum, sack, and barrel. It identifies the components that have an internal relation to the publication (contributor, funder, article update, license, etc.), each of which are well-understood points on the scholarly map. But when we integrate the article nexus into the graph, new territories become visible - not isolated islands, but places with highways connecting them to addresses already known.

When a publication has its relationships clearly identified, the connections both go out as well as lead back to it. The more connections, the more visibility on the scholarly map, as the Art of Cartography goes. Numerous systems tap into this map: publishing, funders, research institutions, research councils, indexers & repositories, indexers, research information systems, lab & diagnostics systems, reference management and literature discovery, other PID suppliers. So publishers, you can provide the fullest value to your own publishing operation, your authors, their research communities, and the overall research enterprise by ensuring that all publications are fully linked both inside and out.

Where do DOI clicks come from?

Joe Wass — Thu, 19 May 2016 00:00:00 +0000

As part of our Event Data work we’ve been investigating where DOI resolutions come from. A resolution could be someone clicking a DOI hyperlink, or a search engine spider gathering data or a publisher’s system performing its duties. Our server logs tell us every time a DOI was resolved and, if it was by someone using a web browser, which website they were on when they clicked the DOI. This is called a referral.

This information is interesting because it shows not only where DOI hyperlinks are found across the web, but also when they are actually followed. This data allows us a glimpse into scholarly citation beyond references in traditional literature.

Last year Crossref Labs announced Chronograph, an experimental system for browsing some of this data. We’re working toward a new version, but in the meantime I’d like to share the results for 2015 and some of 2016. We have filtered out domains that belong to Crossref member publishers to highlight citations beyond traditional publications.

Top 10 DOI referrals from websites in 2015

This chart shows the top 10 referring non-primary-publisher domains of DOIs per month. Note that if browsers don’t send the referrer (e.g. from an HTTPS page), we don’t get to find out. Because the top 10 can be different month to month, the total number of domains mentioned can be more than 10. Subdomains are combined, which means that, for example, the wikipedia.org entry covers all Wikipedia languages. This chart covers all of 2015 and the first two months of 2016.

The top 10 referring domains for the period:

webofknowledge.com
baidu.com
serialssolutions.com
scopus.com
exlibrisgroup.com
wikipedia.org
google.com
uni-trier.de
ebsco.com
google.co.uk

It’s not surprising to see some of these domains here: for example serialssolutions.com and exlibrisgroup.com are effectively proxies for link resolvers, Baidu and Google are incredibly popular search engines which would show up anywhere. But it is exciting to see Wikipedia ranked amongst these. For more detail look out for the new Chronograph.

HTTP vs HTTPS in 2015

We’ve also seen a steady increase in HTTPS referral traffic, i.e. people clicking on DOIs from sites that are using HTTPS. While it is still dwarfed by HTTP, there was a steady uptick throughout 2015.

This chart shows HTTP vs HTTPS referrals per day, which shows up the weekly spikes. It doesn’t include resolutions where we don’t know the referrer.

Increasing numbers of people are moving to HTTPS for reasons of security, privacy and protection from tampering. Google has announced plans to take HTTPS into account when ranking search results. Wikipedia has moved exclusively to HTTPS, and I’ll be telling the story of how Crossref and Wikipedia collaborated in an upcoming blog post.

Chronograph

Another version of Chronograph will be available soon. It will contain full data for all non-primary-publisher referring domains. Stay tuned!

Getting Started with Crossref DOIs, courtesy of Scholastica

Anna Tolwinska — Mon, 25 Apr 2016 00:00:00 +0000

I had a great chat with Danielle Padula of Scholastica, a journals platform with an integrated peer-review process that was founded in 2011. We talked about how journals get started with Crossref, and she turned our conversation into a blog post that describes the steps to begin registering content and depositing metadata with us. Since the result is a really useful description of our new member on-boarding process, I want to share it with you here as well. As always, comments and questions are welcome here, at member@Crossref.org, and @CrossrefOrg. - Anna_

The internet is in a constant state of change, with new content being added to the web by the minute and old content sometimes getting moved around. While the benefit of publishing scholarly outputs online is that it’s possible to update them at any moment, moving or modifying content can also …

Rehashing PIDs without stabbing myself in the eyeball

Geoffrey Bilder — Thu, 11 Jun 2015 00:00:00 +0000

Anybody who knows me or reads this blog is probably aware that I don’t exactly hold back when discussing problems with the DOI system. But just occasionally I find myself actually defending the thing…

About once a year somebody suggests that we could replace existing persistent citation identifiers (e.g. DOIs) with some new technology that would fix some of the weaknesses of the current systems. Usually said person is unhappy that current systems like

DOI, Handle, Ark, perma.cc, etc. depend largely on a social element to update the pointers between the identifier and the current location of the resource being identified. It just seems manifestly old-fashioned and ridiculous that we should still depend on bags of meat to keep our digital linking infrastructure from falling apart.

In the past, I’ve threatened to stab myself in the eyeball if I was forced to have the discussion again. But the dirty little secret is that I play this game myself sometimes. After all, the best thing a mission-driven membership organisation could do for its members would be to fulfil its mission and put itself out of business. If we could come up with a technical fix that didn’t require the social component, it would save our members a lot of money and effort.

When one of these ideas is posed, there is a brief flurry of activity as another generation goes through the same thought processes and (so far) comes to the same conclusions.

The proposals I’ve seen generally fall into one of the following groups:

Replace persistent identifiers (PIDs) with hashes, checksums, etc.
Just use search (often, but not always coupled with 1 above)
Automagically create PIDs out of metadata.
Automagically redirect broken citations to archived versions of the content identified
And more recently… use the blockchain

I thought it might help advance the discussion and avoid a bunch of dead ends if I summarised (rehashed?) some of the issues that should be considered when exploring these options.

Warning: Refers to FRBR terminology. Those of a sensitive disposition might want to turn away now.

DOIs, PMIDs, etc. and other persistent identifiers are primarily used by our community as “citation identifiers”. We generally cite at the “expression” level.
Consider the difference between how a “citation identifier” a “work identifier” and a “content verification identifier” might function.
How do you deal with “equivalent manifestations” of the same expression. For example the ePub, PDF and HTML representations of the same article are intellectually equivalent and interchangeable when citing. The same applies to csv & tsv representations of the same dataset. So, for example, how do hashes work here as a citation identifier?
Content can be changed in ways that typically doesn’t effect the interpretation or crediting of the work. For example, by reformatting, correcting spelling, etc. In these cases the copies should share the same citation identifier, but the hashes will be different.
Content that is virtually identical (and shares the same hash) might be republished in different venues (e.g. a normal issue and a thematic issue). Context in citation is important. How do you point somebody at the copy in the correct context?
Some copies of an article or dataset are stewarded by publishers. That is, if there is an update, errata, corrigenda, retraction/withdrawal, they can reflect that on the stewarded copy, not on copies they don’t host or control. Location is, in fact, important here.
Some copies of content will be nearly identical, but will differ in ways that would affect the interpretation and/or crediting of the work. A corrected number in a table for example. How would you create a citation form a search that would differentiate the correct version from the incorrect version?
Some content might be restricted, private or under embargo. For example private patient data, sensitive data about archaeological finds or the migratory patterns of endangered animals.
Some content is behind paywalls (cue jeremiads)
Content is increasingly composed of static and dynamic elements. How do you identify the parts that can be hashed?
How do you create an identifier out of metadata and not have them look like this?

This list is a starting point that should allow people to avoid a lot of blind alleys.

In the mean time, good luck to those seeking alternatives to the current crop of persistent citation identifier systems. I’m not convinced it is possible to replace them, but if it is- I hope I beat you to it. 🙂 And I hope I can avoid stabbing myself in the eye.

January 2015 DOI Outage: Followup Report

Geoffrey Bilder — Tue, 17 Mar 2015 00:00:00 +0000

Background

On January 20th, 2015 the main DOI HTTP proxy at doi.org experienced a partial, rolling global outage. The system was never completely down, but for at least part of the subsequent 48 hours, up to 50% of DOI resolution traffic was effectively broken. This was true for almost all DOI registration agencies, including Crossref, DataCite and mEDRA.

At the time we kept people updated on what we knew via Twitter, mailing lists and our technical blog at CrossTech. We also promised that, once we’d done a thorough investigation, we’d report back. Well, we haven’t finished investigating all implications of the outage. There are both substantial technical and governance issues to investigate. But last week we provided a preliminary report to the Crossref board on the basic technical issues, and we thought we’d share that publicly now.

The Gory Details

First, the outage of January 20th was not caused by a software or hardware failure, but was instead due to an administrative error at the Corporation for National Research Initiatives (CNRI). The domain name “doi.org” is managed by CNRI on behalf of the International DOI Foundation (IDF). The domain name was not on “auto-renew” and CNRI staff simply forgot to manually renew the domain. Once the domain name was renewed, it took about 48 hours for the fix to propagate through the DNS system and for the DOI resolution service to return to normal. Working with CNRI we analysed traffic through the Handle HTTP proxy and here’s the graph:

The above graph shows traffic over a 24 hour period on each day from January 12, 2015 through February 10th, 2015. The heavy blue line for January 20th and the heavy red line for January 21st show how referrals declined as the doi.org domain was first deleted, and then added back to DNS.

It could have been much worse. The domain registrar (GoDaddy) at least had a “renewal grace and registry redemption period” which meant that even though CNRI forgot to pay its bill to renew the domain, the domain was simply “parked” and could easily be renewed by them. This is the standard setting for GoDaddy. Cheaper domain registrars might not include this kind of protection by default. Had there been no grace period, then it would have been possible for somebody other than CNRI to quickly buy the domain name as soon as it expired. There are many automated processes which search for and register recently expired domain names. Had this happened, at the very least it would have been expensive for CNRI to buy the domain back. The interruption to DOI resolutions during this period would have also been almost complete.

So we got off relatively easy. The domain name is now on auto-renew. The outage was not as bad as it could have been. It was addressed quickly and we can be reasonably confident that the same administrative error will not happen again. Crossref even managed to garner some public praise for the way in which we handled the outage. It is tempting to heave a sigh of relief and move on.

We also know that everybody involved at CNRI, the IDF and Crossref have felt truly dreadful about what happened. So it is also tempting to not re-open old wounds.

But it would be a mistake if we did not examine a fundamental strategic issue that this partial outage has raised: How can Crossref claim that its DOIs are ‘persistent’ if Crossref does not control some of the key infrastructure on which it depends? What can we do to address these dependencies?

What do we mean by “persistent?”

@kaythaney tweets on definition of “persistent”

To start with, we should probably explore what we mean by ‘persistent’. We use the word “persistent” or “persistence” about 470 times on the Crossref web site. The word “persistent” appears central to our image of ourselves and of the services that we provide. We describe our core, mandatory service as the “Crossref Persistent Citation Infrastructure.”

The primary sense of the word “persistent” in the New Oxford American Dictionary is:

Continuing firmly or obstinately in a course of action in spite of difficulty or opposition.

We play on this sense of the word as a synonym for “stubborn” when we half-jokingly say that, “Crossref DOIs are as persistent as Crossref staff.” Underlying this joke is a truth, which is that persistence is primarily a social issue, not a technical issue.

Yet presumably we once chose to use the word “persistent” instead of “perpetual” or “permanent” for other reasons. “Persistence” implies longevity, without committing to “forever.” Scholarly publishers, perhaps more than most industries, understand the long term. After all, the scholarly record dates back to at least 1665 and we know that the scholarly community values even our oldest journal backfiles. By using the word “persistent” as opposed to the more emphatic “permanent” we are essentially acknowledging that we, as an industry, understand the complexity and expense of stewarding the content for even a few hundred years to say nothing of “forever.” Only the chronologically naïve would recklessly coin terms like “permalink” for standard HTTP links which have a documented half-life of well under a decade.

So “persistent” implies longevity- without committing to forever- but this still begs questions. What time span is long enough to qualify as “persistent?” What, in particular, do we mean by “persistent” when we talk about Crossref’s “Persistent Citation Infrastructure?” or of Crossref DOIs being “persistent identifiers?”

What do we mean by “persistent identifiers?”

]5 @violetailik tweets on outage and implication for term “persistent identifier”

First, we often make the mistake of talking about “persistent identifiers” as if there is some technical magic that makes them continue working when things like HTTP URIs break. The very term “persistent identifier” encourages this kind of magical thinking and, ideally, we would instead talk about “persist-able” identifiers. That is, those that have some form of indirection built into them. There are many technologies that do this- Handles, DOIs, Purls, ARKs and every URL shortener in existence. Each of them simply introduces a pointer mapping between an identifier and location where a resource or content resides. This mapping can be updated when the content moves, thus preserving the link. Of course, just because an identifier is persist-able doesn’t mean it is persistent. If Purls or DOIs are not updated when content moves, then they are no more persistent than normal URLs.

Andrew Treloar points out that when we talk about “persistent identifiers,” we tend to conflate several things:

The persistence of the identifier- that is the token or string itself.
The persistence of the thing being pointed at by the identifier. For example, the content.
The persistence of the mapping of the identifier to the thing being identified.
The persistence of the resolver that allows one to follow the mapping of the identifier to the thing being identified.
The persistence of a mechanism for updating the mapping of the identifier to the thing being identified.

If any of the above fails, then “persistence” fails. This is probably why we tend to conflate them in the first place.

Each of these aspects of “persistence” is worthy of much closer scrutiny, however, in the most recent case of the January outage of “doi.org,” the problem specifically occurred with item “D”- the persistence of the resolver. When CNRI failed to renew the domain name for “doi.org” on time, the DOI resolver was rendered unavailable to a large percentage of people over a period of about 48 hours as global DNS servers first removed, and then added back the “doi.org” domain.

Turtles all the way down*

The initial public reaction to the outage was, almost unanimous in one respect- people assumed that the problem originated with Crossref.

@iainh_z tweets to Crossref enquiring about failed DOI resoluton

@LibSkrat tweets at Crossref about DOI outage

This is both surprising and unsurprising. It is surprising because we have fairly recent data indicating that lots of people recognise the DOI brand, but not the Crossref brand. Chances are, that this relatively superficial “brand” awareness does not correlate with understanding how the system works or how it relates to persistence. It is likely plenty of people clicked on DOIs at the time of the outage and, when they didn’t work, simply shrugged or cursed under their breath. They were aware of the term ‘DOI’ but not of the promise of “persistence”. Hence, they did not take to twitter to complain about it, and if they did, they probably wouldn’t have known who to complain to or even how to complain to them (neither CNRI or the IDF has a Twitter account).

But the focus on Crossref is also unsurprising. Crossref is by far the largest and most visible DOI Registration Agency. Many otherwise knowledgeable people in the industry simply don’t know that there are even other RAs.

They also generally didn’t know of the strategic dependencies that exist in the Crossref system. By “strategic dependencies” we are not talking about the vendors, equipment and services that virtually every online enterprise depends on. These kinds of services are largely fungible. Their failures may be inconvenient and even dramatic, but they are rarely existential.

Instead we are talking about dependencies that underpin Crossref’s ability to deliver on its mission. Dependencies that not only affect Crossref’s operations, but also its ability to self-govern and meet the needs of its membership. In this case there are three major dependencies: Two of which are specific to Crossref and other DOI registration agencies and one which is shared by virtually all online enterprises today. The organisations are: The International DOI Foundation (IDF), Corporation for National Research Initiatives (CNRI) and the Internet Corporation for Assigned Names and Numbers (ICANN).

Dependency of RAs on IDF, CNRI and ICANN. Turtles all the way down.

Each of these agencies has technology, governance and policy impacts on Crossref and the other DOI registration agencies, but here we will focus on the technological dependencies.

At the top of the diagram are a subset of the various DOI Registration Agencies. Each RA uses the DOI for a particular constituency (e.g. scholarly publishers) and application (e.g. citation). Sometimes these constituencies/applications overlap (as with mEDRA, Crossref and DataCite), but sometimes they are orthogonal to the other RAs, as is the case with EIDR. All, however, are members of the IDF.

The IDF sets technical policies and development agendas for the DOI infrastructure. This includes recommendations about how RAs should display and link DOIs. Of course all of these decisions have an impact on the RAs. However, the IDF provides little technical infrastructure of its own as it has no full-time staff. Instead it outsources the operation of the system to CNRI, this includes the management of the doi.org domain which the IDF owns.

The actual DOI infrastructure is hosted on a platform called the Handle System which was developed by and is currently run by CNRI. The Handle System is part of a quite complex and sophisticated platform for managing digital objects that was originally developed for DARPA. A subset of the Handle system is designated for use by DOIs and is identified by the “10” prefix (e.g. 10.5555/12345678). The Handle system itself is not based on HTTP (the web protocol). Indeed, one of the much touted features of the Handle System is that it isn’t based on any specific resolution technology. This was seen as a great virtue in the late 1990s when the DOI system was developed and the internet had just witnessed an explosion of seemingly transient, competing protocols (e.g. Gopher, WAIS, Archie, HyperWave/Hyper-G, HTTP, etc.). But what looked like a wild-west of protocols quickly settled into an HTTP hegemony. In practice, virtually all DOI interactions with the Handle system are via HTTP and so, in order to interact with the web, the Handle System employs a “Handle proxy” which translates back and forth between HTTP, and the native Handle system. This all may sound complicated, and the backend of the Handle system is really very sophisticated, but it turns out that the DOI really uses only a fraction of the Handle system’s features. In fact, the vast majority of DOI interactions merely use the Handle system as a giant lookup table which allows one to translate an identifier into a web location. For example, it will take a DOI Handle like this:

10.5555/12345678

and redirect it to (as of this writing) the following URL:

http://psychoceramics.labs.crossref.org.pluma.sjfc.edu/10.5555-12345678.html

This whole transformation is normally never seen by a user. It is handled transparently by the web browser, which does the lookup and redirection in the background using HTTP and talking to the Handle Proxy. In the late 1990s, even doing this simple translation quickly, at scale with a robust distributed infrastructure, was not easy. These days however we see dozens if not hundreds of “URL Shorteners” doing exactly the same thing at far greater scale than the Handle System.

It may seem a shame that more of the Handle Systems features are not used, but the truth is the much touted platform independence of the Handle System rapidly became more of a liability and impediment to persistence than an aid. To be blunt, if in X years a new technology comes out that supersedes the web, what do we think the societal priority is going to be?

To provide a robust and transparent transition from the squillions of existing HTTP URI identifiers that the entire world depends on?
To provide a robust and transparent transition from the tiny subset of Handle-based identifiers that are used by about a hundred million specialist resources?

Quite simply, the more the Handle/DOI systems diverge from common web protocols and practice, then the more we will jeopardise the longevity of our so-called persistent identifiers.

So, in the end, DOI registration agencies really only use the Handle system for translating web addresses. All of the other services and features one might associate with DOIs (reference resolution, metadata lookup, content negotiation, OAI-PMH, REST APIs, Crossmark, CrossCheck, TDM Services, FundRef etc) are all provided at the RA level.

But this address resolution is still critical. And it is exactly what failed for many users on January 20th 2015. And to be clear, it wasn’t the robust and scaleable Handle System that failed. It wasn’t the Handle Proxy that failed. And it certainly wasn’t any RA-controlled technology that failed. These systems were all up and running. What happened was that the standard handle proxy that the IDF recommends RAs use, “dx.doi.org”, was effectively rendered invisible to wide portions the internet because the “doi.org” domain was not renewed. This underscores two important points.

The first is that it doesn’t much matter what precisely caused the outage. In this case it was an administrative error. But the effect would have been similar if the Handle proxies had failed of if the Handle system itself had somehow collapsed. In the end, Crossref and all DOI registration agencies are existentially dependent on the Handle system running and being accessible.

The second is that the entire chain of dependencies from the RAs down through CNRI are also dependent on the DNS system which, in turn, is governed by ICANN. We should really not be making too much of the purported technology independence of the DOI and Handle systems. To be fair, this limitation is inherent to all persistent identifier schemes that aim to work with the web. It really is “turtles all the way down.”

What didn’t fail on January 19th/20th and why?

You may have noticed a lot of hedging in our description of the outage of January 19th/20th. For one thing, we use the term “rolling outage.” Access to the Handle Proxy via “dx.doi.org” was never completely unavailable during the period. As we’ve explained, this is because the error was discovered very quickly and the domain was renewed hours after it expired. The nature of DNS propagation meant that even as some DNS servers were deleting the “doi.org” entry, others were adding it back to their tables. In some ways this was really confusing because it meant it was difficult to predict where the system was working and where it wasn’t. Ultimately it all stabilised after the standard 48-hour DNS propagation cycle.

But there were also some Handle-based services that simply were not affected at all by the outage. During the outage, a few people asked us if there was an alternative way to resolve DOIs. The answer was “yes,” there were several. It turns out that “doi.org” is not the only DNS name that points to the Handle Proxy. People could easily substitute “dx.doi.org” with “dx.crossref.org” or “dx.medra.org” or “hdl.handle.net” and “resolve” any DOI. Many of Crossref’s internal services use these internal names and so the services continued to work. This is partly why we only discovered the “doi.org” was down from people reporting it on Twitter.

And, of course, there were other services that were not affected by the outage. Crossmark, the REST API, and Crossref Metadata Search all continued to work during the outage.

Protecting ourselves

So what can we do to reduce our dependencies and/or the risks intrinsic to those dependencies?

Obviously, the simplest way to have avoided the outage would have been to ensure that the “doi.org” domain was set to automatically renew. That’s been done. Is there anything else we should do? A few ideas have been floated that might allow us to provide even more resilience. They range greatly in complexity and involvement.

Provide well-publicised public status dashboards that show what systems are up and which clearly map dependencies so that people could, for instance, see that the doi.org server was not visible to systems that depended on it. Of course, if such a dashboard had been hosted at doi.org, nobody would have been able to connect to it. Stoopid turtles.
Encourage DOI RAs to have the members point to Handle proxies using domain names under the RA’s control. Simply put, if Crossref members had been using “dx.crossref.org” instead of “dx.doi.org”, then Crossref DOIs would have continued to work throughout the outage of “doi.org”. The same with mEDRA, and the other RAs. This way each RA would have control over another critical piece of their infrastructure. It would also mean that if any single RA made a similar domain name renewal mistake, the impact would be isolated to a particular constituency. Finally, using RA-specific domains for resolving DOIs might also make it clear that different DOIs are managed by different RAs and might have different services associated with them. Perhaps Crossref would spend less time supporting non-Crossref DOIs?
Provide a parallel, backup resolution technology that could be pointed to in the event of a catastrophic Handle System failure. For example we could run a parallel system based on PURLs, ARKs or another persist-able identifier infrastructure.
Explore working with ICANN to get the handle resolvers moved under the special “.arpa” top level domain (TLD). This TLD (RFC 3172) is reserved for services that are considered to be “critical to the operation of the internet.” This is an option that was first discussed at a meeting of persistent identifier providers in 2011.

These are all tactical approaches to addressing the specific technical problem of the Handle System becoming unavailable, but they do not address deeper issues relating to our strategic dependence on several third parties. Even though the IDF and CNRI provide us with pretty simple and limited functionality, that functionality is critical to our operations and our claim to be providing persistent identifiers. Yet these technologies are not in our direct control. We had to scramble to get hold of people to fix the problem. For a while, we were not able to tell our users or members what was happening because we did not know ourselves.

The irony is that Crossref was held to account, and we were in the firing line the entire time. Again, this was almost unavoidable. In addition to being the largest DOI RA, we are also the only RA that has any significant social media presence and support resources. Still, it meant that we were the public face of the outage while the IDF and CNRI remained in the background.

And this is partly why our board has encouraged us to investigate another option:

Explore what it would take to remove Crossref dependencies on the IDF and CNRI.

Crossref is just part of a chain of dependencies the goes from our members down through the IDF, CNRI and, ultimately, ICANN. Our claim to providing a persistent identifier structure depends entirely on the IDF and CNRI. Here we have explored some of the technical dependencies. But there are also complex governance and policy implications of these dependencies. Each organisation has membership rules, guidelines and governance structures which can impact Crossref members. Indeed, the IDF and CNRI are themselves members of groups (ISO and DONA, respectively) which might ultimately have policy or governance impact for DOI registration agencies. We will need to understand the strategic implications of these non technical dependencies as well.

Note that the Crossref board has merely asked us to “explore” what it would take to remove dependencies. They have not asked us to actually take any action. Crossref has been massively supportive of the IDF and CNRI, and they have been massively supportive of us. Still, over the years we have all grown and our respective circumstances have changed. It is important that occasionally we question what we might have once considered to be axioms. As we discussed above, we use the term “persistent” which, in turn, is a synonym for “stubborn.” At the very least we need to document the inter-dependencies that we have so that we can understand just how stubborn we can reasonably expect our identifiers to be.

The outage of January 20th was a humbling experience. But in a way we were lucky: Forgetting to renew the domain name was a silly and prosaic way to partially bring down a persistent identifier infrastructure, but it was also relatively easy to fix. Inevitably, there was a little snark and some pointed barbs directed at us during the outage, but we were truly overwhelmed by the support and constructive criticism we received as well. We have also been left with a clear message that, in order for this good-will to continue, we need to follow-up with a public, detailed and candid analysis of our infrastructure and its dependencies. Consider this to be the first section of a multi-part report.

@kevingashley tweets asking for followup analysis

@WilliamKilbride tweets asking for followup and lessons learned

Image Credits

Turtle image CC-BY “Unrecognised MJ” from the Noun Project

Problems with dx.doi.org on January 20th 2015- what we know.

Geoffrey Bilder — Wed, 21 Jan 2015 00:00:00 +0000

Hell’s teeth.

So today (January 20th, 2015) the DOI HTTP resolver at dx.doi.org started to fail intermittently around the world. The doi.org domain is managed by CNRI on behalf of the International DOI Foundation. This means that the problem affected all DOI registration agencies including Crossref, DataCite, mEDRA etc. This also means that more popularly known end-user services like FigShare and Zenodo were affected. The problem has been fixed, but the fix will take some time to propagate throughout the DNS system. You can monitor the progress here:

https://www.whatsmydns.net/#A/doi.org

Now for the embarrassing stuff…

At first lots of people were speculating that the problem had to do with somebody forgetting to renew the dx.doi.org domain name. Our information from CNRI was that the problem had to do with a mistaken change to a DNS record and that the domain name wasn’t the issue. We corrected people who were reporting that domain name renewal as the cause, but eventually we learned that it was actually true. We have had it confirmed that the problem originated with CNRI manually renewing the domain name at the last minute. Ugh. CNRI will issue a statement soon. We’ll link to it as soon as they do. UPDATE (Jan 21st): CNRI has sent Crossref a statement. They do not have it on their site yet, so we have can included it below.

In the mean time, if you are having trouble resolving DOIs, a neat trick to know is that you can do so using the Handle system directly. For example:

http://hdl.handle.net/10.5555/12345678

Crossref will, of course, also analyse what occurred, and issue a public report as well. Obviously, this report will include an analysis of how the outage effected DOI referrals to our members.

The amazingly cool thing is that everybody online has been very supportive and has helped us to diagnose the problem. Some have even said that the event underscores a point we often make about so-called “persistent-identifiers”- which is that they are not magic technology; the “persistence” is the result of a social contract. We like to say that Crossref DOIs are as persistent as Crossref staff. Well, to that phrase we have to add “and IDF staff” and “CNRI staff” and “ICANN staff”. It is turtles all the way down.

We don’t want to dismiss this event as an inevitable consequence of interdependent systems.And we don’t want to pass the buck. We need to learn something practical from this. How can we guard against this type of problem in the future? Again, people following this issue on Twitter have already been helping with suggestions and ideas. Can we crowd-source the monitoring of persistent identifier SLAs? Could we leverage Wikipedia, Wikidata or something similar to monitor critical identifiers and other infrastructure like purls, DOIs, handles, PMIDs, perma.cc, etc? Should we be looking at designating special exceptions to the normal rules governing DNS names? Do we need to distribute the risk more? Or is it enough cough to simply ensure that somebody, somewhere in the dependency chain had enabled DNS protection and auto-renewal for critical infrastructure DNS names?

Truly, we are humbled. For all the redundancy built into our systems (multiple servers, multiple hosting sites, Raid drives, redundant power), we were undone by a simple administrative task. Crossref, IDF and CNRI- we all feel a bit crap. But we’ll get back. We’ll fix things. And we’ll let you know how we do it.

We will update this space as we know more. We will also keep people updated on twitter on @CrossrefNews. And we will report back in detail as soon as we can.

CNRI Statement

"The doi.org domain name was inadvertently allowed to expire for a brief period this morning (Jan 20). It was reinstated shortly after 9am this morning as soon as the relevant CNRI employee learned of it. A reminder email sent earlier this month to renew the registration was apparently missed. We sincerely apologize for any difficulties this may have caused. The domain name has since been placed on automatic renewal, which should prevent any repeat of this event."

DOIs unambiguously and persistently identify published, trustworthy, citable online scholarly literature. Right?

Geoffrey Bilder — Fri, 20 Sep 2013 00:00:00 +0000

The South Park movie , “Bigger, Longer & Uncut” has a DOI:

a) http://dx.doi.org.pluma.sjfc.edu/10.5240/B1FA-0EEC-C316-3316-3A73-L

So does the pornographic movie, “Young Sex Crazed Nurses”:

b) http://dx.doi.org.pluma.sjfc.edu/10.5240/4CF3-57AB-2481-651D-D53D-Q

And the following DOI points to a fake article on a “Google-Based Alien Detector”:

c) http://dx.doi.org.pluma.sjfc.edu/10.6084/m9.figshare.93964

And the following DOI refers to an infamous fake article on literary theory:

d) http://dx.doi.org.pluma.sjfc.edu/10.2307/466856

This scholarly article discusses the entirely fictitious Australian “Drop Bear”:

e) http://dx.doi.org.pluma.sjfc.edu/10.1080/00049182.2012.731307

The following two DOIs point to the same article- the first DOI points to the final author version, and the second DOI points to the final published version:

f) https://web.archive.org/web/20160423204031/https://figshare.com/articles/Relating_ion_channel_expression,_bifurcation_structure,_and_diverse_firing_patterns_in_a_model_of_an_identified_motor_neuron/96546

g) http://dx.doi.org.pluma.sjfc.edu/10.1007/s10827-012-0416-6

This following two DOIs point to the same article- there is no apparent difference between the two copies:

h) http://dx.doi.org.pluma.sjfc.edu/10.6084/m9.figshare.91541

i) http://dx.doi.org.pluma.sjfc.edu/10.1038/npre.2012.7151.1

Another example where two DOIs point to the same article and there is no apparent difference between the two copies:

j) http://dx.doi.org.pluma.sjfc.edu/10.1364/AO.39.005477

k) http://dx.doi.org.pluma.sjfc.edu/10.3929/ethz-a-005707391

These journals assigned DOIs, but not through Crossref:

l) http://dx.doi.org.pluma.sjfc.edu/10.3233/BIR-2008-0496

m) https://web.archive.org/web/20160423192452/https://figshare.com/articles/Role_of_brain_glutamic_acid_metabolism_changes_in_neurodegenerative_pathologies/95564

n) http://dx.doi.org.pluma.sjfc.edu/10.3205/cto000081

These two DOIs are assigned to two different data sets by two different RAs:

o) http://dx.doi.org.pluma.sjfc.edu/10.1107/S0108767312019034/eo5016sup1.xls

p) http://dx.doi.org.pluma.sjfc.edu/10.1594/PANGAEA.726855

This DOI appears to have been published, but was not registered until well after it was published. There were 254 unsuccessful attempts to resolve it in September 2012 alone:

q) http://dx.doi.org.pluma.sjfc.edu/10.4233/uuid:995dd18a-dc5d-4a9a-b9eb-a16a07bfcc6d

The owner of prefix, ‘10.4223,’ who is responsible for the above DOI had 378,790 attempted resolutions in September 2012 of which there were 377,001 failures. The top 10 DOI failures for this prefix each garnered over 200 attempted resolutions. As of November 2012 the prefix had only registered 349 DOIs.

Of the above 16 example DOIs 11 cannot be used for CrossCheck or Crossmark. 3 cannot be used with content negotiation. To search metadata for the above examples, you need to visit four sites:

https://web.archive.org/web/20131229210637/http://search.crossref.org.pluma.sjfc.edu/

https://ui.eidr.org/search

https://www-medra-org.pluma.sjfc.edu/en/search.htm

https://search.datacite.org/

The 14 examples come from just 4 of the 8 existing DOI registration agencies (RAs) It is virtually impossible for somebody without specialized knowledge to tell which DOIs are Crossref DOIs and which ones are not.

Background

So DOIs unambiguously and persistently identify published, trustworthy, citable online scholarly literature. Right? Wrong.

The examples above are useful because they help elucidate some misconceptions about the DOI itself, the nature of the DOI registration agencies and, in particular issues being raised by new RAs and new DOI allocation models.

DOIs are just identifiers

Crossref’s dominance as the primary DOI registration agency makes it easy to assume Crossref’s particular application of the DOI as a scholarly citation identifier is somehow intrinsic to the DOI. The truth is, the DOI has nothing specifically to do with citation or scholarly publishing. It is simply an identifier that can be used for virtually any application. DOIs could be used as serial numbers on car parts, as supply-chain management identifiers for videos and music or as cataloguing numbers for museum artifacts. The first two identifiers listed in the examples (a & b) illustrate this. They both belong to MovieLabs and are part of the EIDR (Entertainment Identifier Registry) effort to create a unique identifier for television and movie assets. At the moment, the DOIs that MoveLabs are assigning are B2B-focused and users are unlikely to see them in the wild. But we should recall that Crossref’s application of DOIs was also initially considered a B2B identifier- but it has since become widely recognized and depended on by researchers, librarians and third parties. The visibility of EIDR DOIs could change rapidly as they become more popular.

Multiple DOIs can be assigned to the same object

There is no International DOI Foundation (IDF) prohibition against assigning multiple DOIs to the same object. At most the IDF suggests that RAs might coordinate to avoid duplicate assignments, but it provides no guidelines on how such cross-RA checks would work.

Crossref, in its particular application of the DOI, attempts to ensure that we don’t assign two different copies of the same article with different DOIs, but that is designed in order to avoid having publishers mistakenly making duplicate submissions. Even then, there are subtle exceptions to this rule- the same article, if legitimately published in two different issues (e.g. a regular issue and a thematic issue) will be assigned different DOIs. This is because, though the actual article content might be identical, the context in which it is cited is also important to record and distinguish. Finally, of course, we assign multiple DOIs to the same “object” when we assign book-level and chapter level DOIs. Or when we assign DOIs to components or reference work entries.

The likelihood of multiple DOIs being assigned to the same object increases as we have multiple RAs. In the future we might legitimately have a monograph that has different Bowker DOIs for different e-book platforms (Kindle, iPad, Kobo.) yet all three might share the same Crossref DOI for citation purposes.

Again, the examples show this already happening. The examples f & g are assigned by DataCite (via FigShare) and Crossref respectively. The first identifies the author version and was presumably assigned by said author. The second identifies the publisher version and was assigned by the publisher.

Although Crossref, as a publisher-focused RA, might have historically proscribed the assignment of Crossref DOIs to archive or author versions, there has never been and could never be any such restrictions on other DOI RAs. These are legitimate applications of two citation identifiers to two versions of the same article.

However, the next set of examples, h, i, j and k show what appears to be a slightly different problem. In these cases articles that appear to be in all aspects identical have been assigned two separate DOIs by different RAs. In one respect this is a logistical or technical problem- although Crossref can check for such potential duplicate assignments within its own system, there is no way for us to do this across different RAs. But this is also a marketing and education problem- how do RAs with similar constituencies (publishers, researchers, librarians) and application of the DOI (scholarly citation) educate and inform their members about best practice in applying DOIs in that particular RAs context?

DOI registration agencies are not focused on record types, they are focused on constituencies and applications

The examples f through k also illustrate another area of fuzzy thinking about RAs- that they are somehow built around particular record types. We routinely hear people mistakenly explain that difference between Crossref and DataCite is that “Crossref assigns DOIs to journal articles” and that “DataCite assigns DOIs to data.” Sometimes this is supplemented with “and Bowker assigns DOIs to books.” This is nonsense. Crossref assigns DOIs to data (example o) as well as conference proceedings, programs, images, tables, books, chapters, reference entries, etc. And DataCite covers a similar breadth of record types including articles (examples c, h, f, l, m ). The difference between Crossref, DataCite and Bowker is their constituencies and applications- not the record types they apply DOIs to. Crossref’s constituency is publishers. DataCite’s constituency is data repositories, archives and national libraries. But even though Crossref and DataCite have different constituencies, they share a similar application of the DOI- that is the use of DOI as citation identifiers. This is in contrast to MovieLabs whose application of the DOI is supply chain management.

DOI registration agency constituencies and applications can overlap or be entirely separate

Although Crossref’s constituency is “publishers”, we are catholic in our definition of “publisher” and have several members who run repositories that also “publish” content such as working papers and other grey literature (e.g. Woods Hole Oceanographic Institution, University of Michigan Library, University of Illinois Library). DataCite’s constituency is data repositories, archives and national libraries, but this doesn’t stop DataCite (through CDL/FigShare) from working with the publisher, PLoS, on their “Reproducibility Initiative” which requires the archiving of article-related datasets. PloS has announced that they will host all supplemental data sets on FigShare but will assign DOIs to those items through Crossref.

Crossref’s constituency of publishers overlaps heavily with Airiti, JaLC, mEDRA, ISTIC and Bowker. In the case of all but Bowker we also overlap in our application of the DOI in the service of citation identification. Bowker, though it shares Crossref’s constituency, uses DOIs for supply chain management applications.

Meanwhile, EIDR is an outlier, its constituency does not overlap with Crossref’s and its application of the DOI is different as well.

The relationship between RA constituency overlap (e.g. scholarly publishers vs television/movie studios) and application overlap (e.g. citation identification vs. supply chain management) can be visualized as such:

The differences (subtle or large) between the various RAs are not evident to anybody without a fairly sophisticated understanding of the identifier space and the constituencies represented by the various RAs. To the ordinary person these are all just DOIs, which in turn are described as simply being “persistent interoperable identifiers.”

Which of course begs the question, what do we mean by “persistent” and “interoperable?”

DOIs only are as persistent as the registration agency’s application warrants.

The word “persistent” does not mean “permanent.” Andrew Treloar is known to point out that the primary sense of the word “persistent” in the New Oxford American Dictionary is:

Continuing firmly or obstinately in a course of action in spite of difficulty or opposition

Yet presumably the IDF once chose to use the word “persistent” instead of “perpetual” or “permanent” for other reasons. “Persistence” implies longevity, without committing to “forever.”

It may sound prissy, but it seems reasonable to expect that the useful life-expectancy for the identifier used for managing inventory of the the movie “Young Sex Crazed Nurses” might be different than the life expectancy for the identifier used to cite Henry Oldenburg’s “Epistle Dedicatory” in the first issue of the Philosophical Transactions. In other words, some RAs have a mandate to be more “obstinate” than others and so their definitions of “persistence” may vary. Different RAs have different service level agreements.

The problem is that ordinary users of the “persistent” DOI have no way of distinguishing between those DOIs that are expected to have a useful life of 5 years and those DOIs that are expected to have a useful lifespan of 300+ years. Unfortunately, if one of the more than 6 million non-Crossref DOIs breaks today, it will likely be blamed on Crossref.

Similarly, if a DOI doesn’t work with an existing Crossref service, like CrossCheck, Crossmark or Crossref Metadata Search, it will also be laid at the foot of Crossref. This scenario is likely to become even more complex as different RAs provide different specialized services for their constituencies.

Ironically, the converse doesn’t always apply. Crossref oftentimes does not get credit for services that we instigated at the IDF level. For instance, FigShare has been widely praised for implementing content negotiation for DOIs even though this initiative had nothing to do with FigShare, instead it was implemented by DataCite with the prodding and active help of Crossref (DataCite even used Crossref’s code for a while). To be clear, we don’t begrudge praise for FigShare. We think FigShare is very cool- this just serves as an example of the confusion that is already occurring.

DOIs are only “interoperable” at a least common denominator level of functionality

There is no question that use of Crossref DOIs has enabled the interoperability of citations across scholarly publisher sites. The extra level of indirection built into the DOI means that publishers do not have to worry about negotiating multiple bilateral linking agreements and proprietary APIs. Furthermore, at the mundane technical level of following HTTP links, publishers also don’t have to worry about whether the DOI was registered with mEDRA, DataCite or Crossref as long as the DOI in question was applied with citation linking in mind.

However, what happens if somebody wants to use metadata to search for a particular DOI? What happens if they expect that DOI to work with content negotiation or to enable a CrossCheck analysis or show a Crossmark dialog or carry FundRef data? At this level, the purported interoperability of the DOI system falls apart. A publisher issuing DataCite DOIs cannot use CrossCheck. A user with a mEDRA DOI cannot use it with content negotiation. Somebody searching Crossref Metadata Search or using Crossref’s OpenURL API will not find DataCite records. Somebody depositing metadata in an RA other than Crossref or DataCite will not be able to deposit ORCIDs.

There are no easy or cheap technical solutions to fix this level of incompatibility baring the creation of a superset of all RA functionality at the IDF level. But even if we had a technical solution to this problem- it isn’t clear that such a high-level of interoperability is warranted across all RAs. The degree of interoperability that is desirable between RAs is only in proportion to the degree that they serve overlapping constituencies (e.g. publishers) or use the DOI for overlapping applications (e.g. citation)

DOI Interoperability matters more for some registration agencies than others

This raises the question of what it even means to be “interoperable” between different RAs that share virtually no overlap in constituencies or applications. In what meaningful sense do you make a DOI used for inventory control “interoperable” with a DOI used for identifying citable scholarly works? Do we want to be able to check “Young Sex Crazed Nurses” for plagiarism? Or let somebody know when the South Park movie has been retracted or updated? Do we need to alert somebody when their inventory of citations falls below a certain threshold? Or let them know how many copies of a PDF are left in the warehouse?

The opposite, but equally vexing issue arrises for RAs that actually share constituencies and/or applications. Crossref, DataCIte and mEDRA have all built separate metadata search capabilities, separate deposit APIs, separate OpenURL APIs, and separate stats packages- all geared at handling scholarly citation linking.

Finally, it seems a shame that a third party, like ORCID, who wants to enable researchers to add any DOI and its associated metadata to their ORCID profile, will end up having to interface with 4-5 different RAs.

Summary and closing thoughts

Crossref was founded by publishers who were prescient in understanding that, as scholarly content moved online, there was the potential to add great value to publications by directly linking citations to the documents cited. However, publishers also realized that many of the architectural attributes that made the WWW so successful (decentralization, simple protocols for markup, linking and display, etc.), also made the web a fragile platform for persistent citation.

The Crossref solution to this dilemma was to introduce the use of the DOI identifier as a level of citation indirection in order to layer a persist-able citation infrastructure onto the web. The success of this mechanism has been evident at a number of levels. A first-order effect of the system is that it has allowed publishers to create reliable and persistent links between copies of publisher content. Indeed uptake of the Crossref system by scholarly and professional publishers has been rapid and almost all serious scholarly publishers are now Crossref members.

The second order effects of the Crossref system have also been remarkable. Firstly, just as researchers have long expected that any serious paper-based publication would include citations, now researchers expect that serious online scholarly publications will also support robust online citation linking. Secondly, some have adopted a cargo-cult practice of seeing the mere presence of a DOI on a publication as a putative sign of “citability” or “authority.” Thirdly, interest in use of the DOI as a linking mechanism has started to filter out to researchers themselves, thus potentially extending the use of Crossref DOIs beyond being primarily a B2B citation convention.

The irony is that although the DOI system was almost single-handedly popularized and promoted by Crossref, the DOI brand is better known than Crossref itself. We now find that new RAs like EIDR, DataCite and new services like FigShare are building on the DOI brand and taking it in new directions. As such the first and second order benefits of Crossref’s pioneering work with DOIs are likely to be effected by the increasing activity of the new DOI RAs as well as the introduction of new models for assigning and maintaining DOIs.

How can you trust that a DOI is persistent if different RAs have different conceptions of persistence? How can you expect the presence of a DOI to indicate “authority” or “scholarliness” if DOIs are being assigned to porn movies? How can you expect a DOI to point to the “published” version of an article when authors can upload and assign DOIs to their own copies of articles?

It is precisely because we think that some of the qualities traditionally (and wrongly) accorded to DOIs (e.g. scholarly, published, stewarded, citable, persistent) are going to be diluted in the long term that we have focused so much of our recent attention on new initiatives that have a more direct and unambiguous connection to assessing the trustworthiness of Crossref member’s content. CrossCheck and the CrossCheck logos are designed to highlight the role that publishers play in detecting and preventing academic fraud. The Crossmark identification service will serve as a signal to researchers that publishers are committed to maintaining their scholarly content as well as giving scholars the information they need to verify that they are using the most recent and reliable versions of a document. FundRef is designed to make the funding sources for research and articles transparent and easily accessible. And finally we have been both adjusting Crossref’s branding and display guidelines as well as working with the IDF to refine its branding and display guidelines so as to help clearly differentiate different DOI applications and constituencies.

Whilst it might be worrying to some that DOIs are being applied in ways that Crossref has not expected and may not have historically endorsed, we should celebrate that the broader scholarly community is finally recognizing the importance of persist-able citation identifiers.

These developments also serve to reinforce a strong trend that we have encountered in several guises before. That is, the complete scholarly citation record is made up of more than citations to the formally published literature. Our work on ORCID underscored that researchers, funding agencies, institutions and publishers are interested in developing a more holistic view of the manifold contributions that are integral to research. The “C” in ORCID stands for “contributor” and ORCID profiles are designed to ultimately allow researchers to record “products” which include not only formal publications, but also data sets, patents, software, web pages and other research outputs. Similarly, Crossref’s analysis of the Cited-by references revealed that one in fifteen references in the scholarly literature published in 2012 included a plain, ordinary HTTP URI- clear evidence that researchers need to be able to cite informally published content on the web. If the trend in Cited-by data continues, then in two to three years one in ten citations will be of informally published literature.

The developments that we are seeing are a response to the need that users have to persistently identify and cite the full gamut of record types that make up the scholarly literature. If we can not persistently site these record types, the scholarly citation record will grow increasingly porous and structurally unsound. We can either stand back and let these gaps be filled by other players under their terms and deal reactively with the confusion that is likely to ensue- or we can start working in these areas too and help to make sure that what gets developed interacts with the existing online scholarly citation record in a responsible way.

Persistence on Crossref

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

Calling all 24-hour (PID) party people!

Send us your ideas for #PIDapalooza21

Theme 1. PIDs 101

Theme 2. PID Communities International

Theme 3. PID Success Stories

Theme 4. PID Party!

Propose a session now!

EASE Council Post: Rachael Lammey on the Research Nexus

Crossref: the sustainable source of community-owned scholarly metadata

Crossref: The sustainable source of community-owned scholarly metadata

Strategists

Decision-makers

Practitioners

What this paper covers

Read the full paper

We'll be rocking your world again at PIDapalooza 2020

Don’t forget to tie your proposal into one of the six festival themes:

Theme 1: Putting Principles into Practice

Theme 2: PID Communities

Theme 3: PID Success Stories

Theme 4: Achieving Persistence through Sustainability

Theme 5: Bridging Worlds - Social and Technical

Theme 6: PID Party!

PIDapalooza: the essentials

Request for feedback on grant identifier metadata

The details

Zen and the Art of Platform Migration

Presenting PIDapalooza 2019

PIDs for conferences - your comments are welcome!

Why are conferences important?

Why do we need an open persistent ID for a conference or a conference series?

Next steps

Wellcome explains the benefits of developing an open and global grant identifier

Introduction

Benefits of an open & global grant identifier system

How would it work?

Next steps

Thanks to guest authors:

The PIDapalooza lineup is out; come rock out with us at the open festival of persistent identifiers

The program is now final and there really is something for everyone (well, every PID geek)

Full lineup

PIDapalooza is back and wants your PID stories

Joe Wass reflects:

Ed Pentz on plans for the new organisation IDs

URLs and DOIs: a complicated relationship

Full circle

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

HTTP redirects

Extraordinary diversity

Experiment 1: Does Crossref know all Landing Pages?

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

Interlude

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

A Fair Test

Why all the redirects?

Internal DOI resolvers

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

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

Assumption 4: Every DOI points somewhere unique

Experiment 4: Aliased DOIs

Experiment 5: Duplicate Resource URLs

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

Cookies

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