APIs on Crossref

Strengthening support for data citations and saying goodbye to Event Data

Martyn Rittman — Tue, 24 Mar 2026 00:00:00 +0000

We’re excited to announce a new data citation API endpoint and are seeking your feedback. The new service makes existing data citation relationships in our metadata available, thereby surfacing this part of the research nexus. At the same time, we’ve decided that it’s time to move on from Event Data.

Time to say goodbye

Metadata about published scholarly research has evolved, and continues to evolve in exciting ways. A published article, book, or conference paper is only a single piece of the puzzle. A host of digital identifiers and items can be put together to form a more complete picture of a research project. This is what forms the basis of the research nexus—a rich and reusable open network of relationships connecting research organisations, people, things, and actions; a scholarly record that the global community can build on forever, for the benefit of society.

Ten years ago, we launched Event Data to surface mentions of research around the Internet. What were people saying about published research? Could this discourse contribute to post-publication review and validation? We set up Event Data to capture use of Crossref DOIs in the online world from a variety of sources, including blog posts, social media, websites, and annotations. The idea was that diverse mentions (or “events”) could supplement traditional citation counts as a way to capture the value of research.

Today, the focus is increasingly on transparency, research integrity, and the completeness of outputs. Trust in research is shaped by knowing who the funder was, being able to reanalyse the original data, or checking for bugs in the analysis code. There are also more identifiers for objects within the research space and they are used more widely. This shift is evident in the relatively low usage of Event Data. We can no longer justify the resources and cost that goes into maintaining it as a service. Instead, we will focus on enabling and surfacing relationships between different types of research outputs, starting with links to datasets.

For these reasons, we have decided to sunset the Event Data API and from 23 April 2026 it will no longer be available (although historical data will still be available). In its place, we’re making available an API endpoint for data citations.

Visibility for data citations

The new API endpoint focuses solely on data citations and uses references and relationships deposited by Crossref members, including Crossref articles referencing datasets with either Crossref or DataCite DOIs. While our metadata contains many data citations, and some of them are labelled as data citations, it is often difficult to find them because they are swamped in number by other citations. If you are trying to get data citations directly from our REST API, it’s like looking for a needle in a haystack. This new endpoint makes connections easier to find, enabling organisations to track when research is reused, cited, and built upon. By putting this metadata into a dedicated service, we are making it easier for interested organisations to track and find data citations. Our goal is to make existing sets of connections easier to access, giving clarity to how scholarly works link to the data that supports them.

This beta version will allow us the opportunity to incorporate feedback from the community and make changes to improve delivery. We received early positive feedback from a number of interested organisations. Later this year we will assess whether it is ready for production, needs more work, or if insufficient interest from the community suggests we should pursue a different solution.

Anyone interested in data citations is invited to try the new endpoint. Please let us know your feedback via the community forum. You can find supporting documentation on our website and Swagger documentation, including the opportunity to try out features.

Edited 15 June 2026: link to historical Event Data added.

2026 public data file now available

Martyn Rittman — Tue, 17 Mar 2026 00:00:00 +0000

Once a year we release all metadata records for content registered with Crossref in a public data file. This year’s version, containing nearly 180 million records, is now available. It includes metadata associated with all Crossref-registered DOIs in JSON-lines format.

All our metadata is openly available via our REST API at all time and this file provides the same information all in one place for those who find that format useful for their tools and analysis. You can access the file via Academic Torrents at https://doi-org.pluma.sjfc.edu/10.13003/nggf-vt1j or directly from AWS. For further guidance and tips, see our documentation. The complete, compressed files are 208 GB.

Our metadata has several sources:

Primarily, it comes from records deposited by over 24,000 members spread across over 160 countries. This year, we are pleased to have added a number of new countries by expanding our GEM program, which supports participation in the Crossref community from those in the most economically disadvantaged regions.
Second, we enrich the data by adding automated matches, for example by adding DOIs to deposited references, and organisation identifiers to funders. We are undertaking a renewal of our matching processes, starting later this year with matching funders to ROR identifiers.
Finally, we use selected third party sources to enrich the metadata. Currently we include retractions from the Retraction Watch database.

Most of the data can be freely reused and is not subject to copyright. Some limitations are applied to abstracts. See our documentation for more details about licensing.

Why do we do this?

The community is key to everything we do. Without the thousands of members depositing metadata, we would have nothing to share. And without countless organisations and individuals making use of the metadata, it would have no impact or value. Our mission is to serve our community, and making metadata publicly and openly available is one of our key values. The public data file is just one of a number of ways in which we enable metadata retrieval.

Over the last year, there have been over 600 downloads of the public data file. In addition, we see around 2 billion hits to our public APIs each month. We are always excited to hear about the diverse and interesting ways in which metadata can be used.

What’s different this year?

Thanks to the rich metadata, the records deposited with Crossref are interconnected with many types of relationships between works, people, and organisations, that tell the story of the research endeavor. The latest public data file reflects the current status of the research nexus as we know it and we’re delighted to share it with the community.

This year’s dataset contains 12.7 million new records (a 7.6% increase since last year). Across the board, we’re also seeing richer metadata records, with more abstracts (up 15%), ORCID identifiers for authors (up 20%), ROR identifiers for organisations (up 250%), and links to grant identifiers for funding (reaching 50,000 records).

Research integrity is a current theme in our community. We can see that members increasingly look to leverage metadata in service of asserting trust in their works. An additional 27% more records have Crossmark enabled, meaning that the member responsible is open about research integrity practices, and committed to communicating corrections, retractions, and other post-publication changes. In addition, this year’s snapshot contains retractions from the Retraction Watch database. If you have any questions or feedback about the public data file, or would like to discuss how you can use it, head over to our community forum and join the conversation.

Announcing changes to REST API rate limits

Martyn Rittman — Wed, 05 Nov 2025 00:00:00 +0000

Our REST API makes all of the metadata we hold publicly available. It receives the majority of our API traffic, with around 1 billion hits per month. It’s one of the key ways that we fulfil our mission to make research objects easy to find, cite, link, assess, and reuse. From 1 December 2025, we will be revising the rate limits for the public and polite pools of the REST API to ensure that we can maintain a stable and reliable system, and that metadata is freely available to everyone.

We haven’t changed the rate limits since the REST API was launched in 2013. In the past five years, the number of requests to the REST API has tripled and the number of metadata records has increased by a third, from 120 million to around 180 million. This means an increase in the resources needed to run it, and we’ve seen periods of instability where we haven’t been able to keep the API available for all users. We have decided that it is the right time to revisit rate limits to check that they’re in line with what our technology can provide and what our community needs. As a result, we will apply the following for the public and polite pools:

Public pool:

Request type	Rate limit	Concurrency limit
Single record	5	1
List of records (queries, filters, etc.)	1	1

Polite pool:

Request type	Rate limit	Concurrency limit
Single DOI record	10	3
List of records (queries, filters, etc.)	3	3

The rate limit is the number of total requests that can be made per second. The concurrency limit is how many requests can be running at the same time. This means that for longer-running requests you may need to wait for previous requests to finish before you can make a new one.

Here are some examples of single records requests:

The second case here will be directed to the polite pool because an email is included using the ‘mailto’ parameter. And here are examples of requests that return lists of records:

The second and third examples here will use the polite pool.

Our guiding principle in making these changes is to keep all of the metadata available to everyone, all of the time. These changes to rate limits won’t restrict current users from accessing the metadata they want to retrieve, but it will make it easier for us to maintain the system now and in the future.

Which use cases do we support?

Our metadata has a broad range of applications. If you’re someone who uses the REST API, we’re glad that you are part of our community! Our mission includes making it easier to find, reuse, and assess scholarly research outputs. By using metadata, you’re helping us to fulfil that goal.

The main uses of the REST API fit into several categories. The new rate limits will continue to support these, among many others:

I have some metadata, what is the DOI?
I have a DOI, what is its metadata?
I want all of the metadata, just give me everything.
Research on a specific topic or subset of metadata, often refreshing the results every few weeks or months.

Rate limits can encourage responsible usage. The majority of API users make requests at a low rate and will not need to make any changes, however a few send spikes of large numbers of requests in a short space of time, sometimes making it difficult for others to access the service. These can be smoothed out by lower rate limits. Complex requests that search across large numbers of items put more pressure on our systems than requests for a single content item, so we have decided to set different rate limits for different types of request.

Who will be affected?

We estimate that the changes might affect around 40 users per week across the public and polite pools, and this is only for some of their requests. In all of the cases we’ve seen, the rate of requests could be slowed down and users would still be able to get the same results. In other words, the aim of these changes is to make the load on the API more predictable, not to reduce the total number of requests or amount of metadata transferred. No changes are being made to the Metadata Plus service or other APIs, such as the XML API and OAI-PMH endpoint.

Do I need to change how I use the API?

If you’re reading this, thank you! It’s clear that you want to be a considerate user of our services. Almost all users can continue to use the REST API in exactly the same way, you won’t need to change anything. Here is some general advice that will help you make the most of the service and ensure that you won’t encounter issues.

Use a mailto parameter. This gives you access to the polite pool meaning higher rate limits and meaning we can get in touch with you if needed. We’ll only use your address to contact you about your API requests.
Check the HTTP response status for your requests. This is always good practice and can help you identify malformed requests and where you reach rate limits.
Cache results to avoid repeatedly making the same requests. Most records don’t change on a regular basis. How often you update the cache will depend on what you are interested in, but most metadata fields rarely change.
If you are making a very high volume of requests or have very complex analysis to carry out, consider downloading the public data file which is made available once a year and contains all of our metadata. You can update it with recent additions using the REST API.
If you are relying on our metadata in a production service, Metadata Plus can provide more stability, support, and access to monthly snapshots of our entire database.

We have more tips and tricks for the REST API in our documentation. If you have questions, please join the conversation on our Community Forum.

Evolving the preprint evaluation world with Sciety

Luis Montilla — Tue, 17 Jun 2025 00:00:00 +0000

This post is based on an interview with Sciety team at eLife.

What is Sciety?

Sciety is a community-led initiative developed by a team within eLife, that brings together expert evaluations of papers in one place. It is focused on preprints, preprint review and curation.

Can you tell us more about how Sciety works?

Sciety aggregates preprints from different sources to facilitate the processes of discovery and evaluation. Groups can triage the content and offer preprint reviews and endorsements, and individual researchers can learn about and share preprints of interest and their evaluations. We see the value of increasing trust in preprints, and transparency around the process of peer review, and we are trying to highlight this value and encourage more people to take part.

There are two key angles to Sciety: first, as preprints proliferate, we’re helping to make people more productive in their research by only surfacing the content they might be interested in and that they know they can trust. Second, we are also trying to get more people involved in the public review and curation of preprints. Contributors on Sciety are part of ‘groups’, representing organisations and other communities that facilitate some form of preprint evaluation. We’re broadly talking about peer review, but we also see the highlighting and summarisation of research. eLife, Biophysics Colab, MetaROR and Gigabyte, for example, are all providing some kind of review summary which Sciety shows as a ‘curation statement’. There’s also this additional layer of individual curation on top of it: we have people creating their own highlights in lists which they curate by topic; for example, ‘preprints by authors in the Global South’ or ‘Papers we want to discuss in our lab’. There is also an update feed available to users to help them keep track of all the reviews and endorsements from the groups they follow. We post these assessments and reviews alongside the preprint, which others can then use as an indicator of trust: why should one care about this particular study? As a given group – let’s say GigaByte – and its reviewers highlight the specific strengths of a preprint or reference an updated version, this feedback offers essential context for readers.

By making this evaluation and curation activity visible, Sciety clarifies who has reviewed the work and which groups have added it to their lists. These signals are invaluable for readers seeking reliable, curated research. The activity feed, which at present shows you all the added value in the form of comments, reviews and curation we are bringing from diverse sources, could be expanded to show different forms of curation activity in the future. Furthermore, other providers ingest and surface this information on their own platforms, such as Europe PMC and bioRxiv.

What is your main use of Crossref resources?

We started using the Crossref API to pull in the front matter of articles. Originally, these were only bioRxiv preprints, and then we expanded to various other preprint servers. We would aggregate reviews and build on top of all the preprint servers that have put the authors’ content out there.

We were mostly after a representation of the papers that we could link to: titles, authors, abstracts, publication dates, and, to have a way to go from the DOI of a paper, a classic Crossref entry point. Initially, we used the public API, but the performance wasn’t high enough for what we needed and we switched to Metadata Plus. This immediately increased the speed at which we got data to the point where we could compose pages on the fly and talk to Crossref simultaneously. Even if we needed to pull 10 or 20 different paper titles at the same time to show a list of articles, it stayed that way for a long time. Next, we implemented caching – that is, we started storing temporal local copies to improve performance further. Eventually, we expanded the set of preprint servers we were interested in. It’s always been quite a good experience to be able to put in a DOI and use the same code, essentially, to pull out titles, author information and so on. Crossref does this great job of aggregating the world of content so that we don’t have to. The metadata standardisation via Crossref’s API saves us the need to write special code for every new preprint server.

By the end of 2023, we were interested in multiple revisions and versions of a single preprint. Because the scholarly world is moving on, we can now see cases where the updates to a manuscript produce multiple versions in bioRxiv, and these might eventually evolve into an article in eLife, Nature, or another journal. The publication history complexity of papers has been increasing and we started relying a lot on Crossref to trace the relationships and the different versions of a paper across time. There is some good support on the relationship metadata on Crossref APIs, where you can see that a preprint has a new version with a different DOI, or conversely, that a preprint has an older version. Or you can see that a preprint has become a journal article, or the journal article was originally a preprint – along with all the dates that accompany these different versions. And we can establish the time it took for a preprint to become a journal article. In some cases it can take years, which is not great, right? We don’t want science to be stuck and not relied upon for years. So it helps us to make our case that preprints are the evolution of publishing, that authors publish them and then the preprints evolve rather than being stuck between gates kept by journals.

What can you tell us about the use of preprints?

We have noticed an increase in the interest in how a paper evolves over time and the cross-links between different preprint expressions or journal articles. We’re now seeing enthusiasm from those who are trying alternative publishing models to bring reviewed scientific preprints to people faster, and there is also interest in the transparency of a journal. And I think that’s part of what the Crossref relationship metadata gives us.

For example, we collaborated on a paper aimed at enhancing the culture of preprint peer review. One of the things we observed was that it was published on an OSF preprint server, and then went on to be published in PLOS Biology. As we’d started this project to show the relationships between something that had originally been a preprint, we noticed that the connection between PLOS and OSF for that specific preprint was not explicit. So, we asked a colleague if this was something that could be done. And our contact at PLOS said, “yes, we’ll do this”. At the time, we were aware of Crossref’s intention to either make this more manageable or to do it in bulk. This also prompted another group on Sciety to explore whether they could do the same. Consequently, GigaByte and GigaScience, two other reviewing communities on Sciety, inquired with their publishing platform, Riverview, if they could do the same. Eventually, they realised there was a way to connect the dots through Crossref, and they also started doing it. So, there seems to be a lot of enthusiasm around this idea of making the relationships more explicit: we should show if something has been a preprint, because it’s important to the authors, and it’s important to show the transparency in the journey. That was a real-world example of something that we’re able to service through Sciety by using the Crossref metadata, and the community is responding in a very positive manner to that.

How has your experience been using Crossref services? What are you looking forward to seeing in the future?

The works endpoint is really the 99% of what we have been historically interested in. We generally experiment by putting DOIs in the public API or trying to discover content in the API itself. The amount of data is so big that there are always different examples of what we seek. And we don’t have many performance problems now because we have adopted some aggressive caching. So anything that comes from Crossref is typically cached for 24 hours.

For example, take a bioRxiv preprint that might have multiple versions available on bioRxiv itself, because it’s quite common for authors to update the preprint as they make new changes to it. With this context, an example of something we would like to see is supporting the preprint version number. So this is something that we could implement for bioRxiv over some specific preprint servers on Sciety. But in the end, as we expanded our set of preprint servers, we had to get rid of that, because there wasn’t a sustainable way to aggregate it across most servers, like we would do with Crossref. So there’s probably a space there for papers as living documents. And we certainly have an interest in preprint-specific metadata – that’s where we will place our bets.

Also, as part of the preprint review metadata group, which is something that formed out of the recent meeting with EMC Europe and ASAPbio, we’re trying to drive forward a recommendation and prototypes for more consistency in preprint review metadata. It’s quite exciting to be involved in this and, as you can see, Sciety is a place where we’re starting to pull all this stuff together. And like I say, it is a bit of a Wild West. There are so many things that are called a review, but in metadata, we know there are different terminologies. As people are saying, everyone should be commenting on preprints, everyone should be curating them, and we’re trying to make some sense of that.

Working on Sciety and exploring Crossref metadata to make preprint review more open and valuable has been a rewarding experience.

With thanks to Giorgio Sironi, former Tech Lead Manager, and Mark Williams, Product Manager, at eLife

2025 public data file now available

Martyn Rittman — Wed, 12 Mar 2025 00:00:00 +0000

Every year we release metadata for the full corpus of records registered with us, which can be downloaded for free in a single compressed file. This is one way in which we fulfil our mission to make metadata freely and widely available. By including the metadata of over 165 million research outputs from over 22,000 members worldwide and making them available in a standard format, we streamline access to metadata about scholarly objects such as journal articles, books, conference papers, preprints, research grants, standards, datasets, reports, blogs, and more.

Our metadata is used by thousands of services, researchers, and other organisations. We make it openly available through our APIs, which can be used to obtain a subset of records. If you want to work with our full corpus, the best way is to get a copy of the public data file and update it via the REST API with any new records created or changed since its release.

By providing an annual copy of the full corpus, we also expand the ways in which the metadata can be used and interrogated. It is ideal for groups using large samples of the scholarly record, such as metaresearchers or research integrity experts. You can find examples of the public data file used in research on journal editorial practices and in projects investigating gaps in the scholarly record.

How to access the public data file

The total size of the file is 197 GB and it is available in JSON-lines format. We also provide an experimental tool to convert the file to an Sqlite database. Before downloading the full dataset, you may wish to download the sample dataset containing 100 files (with 100 records in each, around 24 MB). This is a randomly sampled subset of metadata records and can be used for prototyping and development.

To get a copy of the annual data file you can access it directly via https://doi-org.pluma.sjfc.edu/10.13003/87bfgcee6g, or get the sample dataset and previous public data files from Academic Torrents. We make a donation to Academic Torrents to support their work, which allows the data to be accessible in this way. Some organisations have reported policies that prevent access to torrents, so we provide a copy that can be downloaded from AWS, which requires an AWS account and a small payment to cover the data transfer costs. You can find the details about access here.

We have some tips for working with the public data file. If you would like to have access to monthly snapshots of the whole corpus, along with higher API rate limits and other benefits, you can subscribe to Metadata Plus.

What’s different this year?

This year’s public data file contains an additional 9 million records, and many updates to previously deposited records. The formats and method of access are the same as last year, except that it uses JSON lines, meaning that each metadata record is on a single line and the file suffix is jsonl instead of json. The records have been sorted by DOI, meaning it should be easier to navigate.

A change this year is that the file does not contain aliased DOIs, which are DOI that are redirected to another DOI. Aliasing is necessary on rare occasions, for example when two DOIs are registered for the same content. Previously we haven’t indicated aliasing in the REST API and public data files; this year only the prime DOIs (the ones to which they are redirected) are included. This makes statistical analysis of the metadata more accurate, but beware that it may give different results in cases where many aliased DOIs were previously counted. See this community forum post for more details.

The file also contains retractions from the Retraction Watch database, which was acquired by Crossref in September 2023 and recently integrated into the REST API.

If you have questions, want to let us know how you will use the metadata, or want to discuss anything on the topic of retrieving Crossref metadata, head to our community forum. From there, you can also keep updated about changes to our schema and APIs.

Drawing on the Research Nexus with Policy documents: Overton’s use of Crossref API

Luis Montilla — Sat, 15 Jun 2024 00:00:00 +0000

Update 2024-07-01: This post is based on an interview with Euan Adie, founder and director of Overton._

What is Overton?

Overton is a big database of government policy documents, also including sources like intergovernmental organisations, think tanks, and big NGOs and in general anyone who’s trying to influence a government policy maker. What we’re interested in is basically, taking all the good parts of the scholarly record and applying some of that to the policy world. By this we mean finding all the documents, finding what’s out there, collecting metadata for them consistently, fitting to our schema, extracting references from all the policy documents we find, adding links between them, and then we also do citation analysis.

What do you mean by the good parts of the scholarly record?

What I mean by the good parts of the scholarly record is, from a data perspective, having persistent open metadata for items on different stable, interoperable platforms and being able to build up layers of data to suit specific use cases. That’s a better approach than trying to do everything in a silo here and a silo there and trying to do stuff bit by bit or in a hundred different ways.

There’s also a bad part, which is less to do with metadata and more around citation analysis and responsible metrics. With all this data… as the famous Spiderman quote goes… with great power comes a great responsibility: once you start systematically collecting this data, it’s very easy to fall into the trap of thinking that if we can put numbers on it, and then maybe we could start reading meaning into those numbers, and then it spirals out of control. So the idea for Overton was: can we take the system, some of the infrastructure and apply those ideas? But then come at it already knowing where the later pitfalls are and try to avoid them.

What is your main use of Crossref resources?

We rely heavily on Crossref to link policy documents to the scholarly record. The question we’re trying to answer is: does this government document cite academic work? We work a lot with universities, think tanks, and IGOs. They’re asking where is the research we produce ending up? Is it being used by the government? In some countries, like the UK, there’s a big impact agenda where it’s quite important to demonstrate that for government funding. In the US as well, state universities for example aim to impact the local policy environment. Right? Are we producing things that went on to change life for local residents for the better? And that’s really what we’re trying to support. And so that’s one of the main use cases of the database.

Can you tell us a little bit more about the story of Overton, how did this idea start?

It really came from two things. The first one is that I’d always been interested in this area and before Overton, I founded a company called Altmetric.com, which was looking at kind of broader impact metrics for papers. And we looked at Twitter, and news, and blogs, and other things, including policy. But policy wasn’t a primary focus.

When I left Altmetric two things were happening in the UK – not that everything is about Brexit, but Brexit was happening, and then COVID happened as well. And in both cases, I think it just drove home to me that other people seemed to be very interested in the evidence that the government has used to make decisions. Be they good decisions like some of the evidence based initatives in COVID or bad decisions like Brexit. So, how can you find out what it was? And it is actually very difficult to do. You can’t really track back how this decision was made. I thought that there is a growing need for that kind of impact analysis. So the second thing was, can we do something that helps make it easy to see what evidence goes into policy? The scholarly evidence but also the other kind of policy influence that goes into any document or discussion.

What are the main challenges that you face when you are trying to retrieve these policy documents?

Well, first is another thing that the scholarly record does well, which is persistence. We have CLOCKSS and all the dark archives¹. So the whole idea is that if you have a DOI, if something moves, we can track it and it maintains the ID, and even if the publisher goes bust it’ll never disappear. For citing it, then there’s always going to be a copy of it somewhere available even if it’s in a library or a dark archive.

One of the biggest challenges with policy documents is that kind of persistence doesn’t exist… There are a lot of statistics about link rot², and they hold true for policy documents as much as anywhere else. Every year a percentage of the links everywhere basically break because websites are redesigned or a government changes, it’s even worse because it can be by design. If you think about it, a new government comes into power, they change… let’s say the Department of Agriculture and they merge it with the Department of Fisheries. That would refer to a completely new third thing. And the other two departments disappear or they start linking off, like, redirecting or whatever.

One of the challenges is just keeping track of all the changes in the landscape and constantly trying to stay on top of the data. And that’s a big part of what we do. Another challenge for us, and I think about it compared to journals, when you cite something in a scholarly document, you cite it in a given style, but there are no standards for referencing styles in policy documents. So even in the same document, we can see, like, four or five different ways of referring to something, and sometimes they’re missing important data and sometimes they’re not. And it means when we’re using Crossref search, we usually have much more unparsable text.

How has your experience been so far using our Crossref API or our services in general?

It’s been great. I would happily say this anywhere, I always talk about the Crossref API as being one of the best examples of a well-done scholarly infrastructure API. It’s well-documented. It’s fast. It’s clear. The rate limits are clear. It’s up when it should be up. I like that you can trust it. So the technical aspect is great. From an organisational aspect, in contrast with a lot of infrastructure in the scholarly world that you don’t know if it’s even going to be there in a given time, Crossref is pretty stable.

What would you say are the main challenges or things that we can improve in the future? What other expectations or suggestions do you have?

It depends, if we’re talking about how the service could be improved versus how the data could be improved. Data-wise, and I appreciate this is a publisher problem, not a Crossref one, but, we still have to pull other data from OpenAlex, for example, for things like affiliations just because it’s missing from so many articles. And then equally things like ORCID for authors. And in fact also disambiguation in general. This is a huge problem that either the user doesn’t solve or you end up using a hundred different author disambiguation systems. I don’t know if there’s necessarily something Crossref wants to get into, but there’s definitely not something out there generally accepted already.

Another kind of improvement I see is to make sure that changes in one API are reflected in the other, and they don’t get out of sync. When somebody updates their ORCID record, I’d like it reflected in the Crossref record if we’re using that as the “canonical” metadata record for the DOI. Retrospectively enriching records.

I think it’s harder than I expected to just find preprints because you can’t simply use the item type but I understand that this is maybe a bigger issue. So maybe it’s not for a short time.

Finally, this is very specific, but we experienced friction when going from the snapshots to having something useful, either in Elasticsearch or in, like, Postgres. It might be nice to have some open-source scripts to download and process everything, convert it to relational tables, or send it to an Elasticsearch cluster or something.

Rebalancing our REST API traffic

Stewart Houten — Tue, 04 Jun 2024 00:00:00 +0000

Since we first launched our REST API around 2013 as a Labs project, it has evolved well beyond a prototype into arguably Crossref’s most visible and valuable service. It is the result of 20,000 organisations around the world that have worked for many years to curate and share metadata about their various resources, from research grants to research articles and other component inputs and outputs of research.

The REST API is relied on by a large part of the research information community and beyond, seeing around 1.8 billion requests each month. Just five years ago, that average monthly number was 600 million. Our members are the heaviest users, using it for all kinds of information about their own records or picking up connections like citations and other relationships. Databases, discovery tools, libraries, and governments all use the API. Research groups use it for all sorts of things such as analysing trends in science or recording retractions and corrections.

So the chances are high that almost any tool you rely on in scientific research has somewhere incorporated metadata through us.

Optimising performance

For some time, we’ve been noticing reduced performance in a number of ways, and periodically we have a flurry of manually blocking/unblocking IP addresses from requesters that are hammering and degrading the service for everyone else, and this is of course only minimally effective and very short term. You can always watch our status page for alerts. This is the current one about REST API performance: https://status-crossref-org.pluma.sjfc.edu/incidents/d7k4ml9vvswv.

As the number of users and requests has grown, our strategies for serving those requests must evolve. This post discusses how we’re approaching balancing the growth in usage for the immediate term and provides some thoughts about things we could try in the future on which we’ll gladly take feedback and advice.

Load balancing

In 2018, we started routing users through three different pools (public, polite, and plus). This coincided with the launch of Metadata Plus, a paid-for service with monthly data dumps and very high rate limits. Note that all metadata is exactly the same and real-time across all pools. We also, more recently, introduced an internal pool. Here’s more about them:

Plus: This is the aforementioned premium option; it’s really for ‘enterprise-wide’ use in production services and is not really relevant here.
Public: This is the default and is the one that is struggling at the moment. You don’t have to identify yourself and, in theory, we don’t have to work through the night to support it if it’s struggling (although we often do). Public currently receives around 30,000 requests per minute.
Polite: Traffic is routed to polite simply by detecting a mailto in the header. Any system or person including an email is being routed to a currently-quieter pool, this means we can always get in touch for troubleshooting (and only troubleshooting). Polite currently receives around 5,000 requests per minute.
Internal: In 2021, we introduced a new pool just for our own tools where we can control and predict the traffic. Internal currently receives around 1,000 requests per minute.

The volumes of traffic across public, polite and internal pools are very different and yet each pool has always had similar resources. The purpose of each of these pools has been long-established but our efforts to ask the community to use polite by default have not been particularly successful and it is clear that we don’t have the right balance.

The internal pool has been dedicated to our internal services that have predictable usage and that have requests that are not initiated by external users. The internal pool has previously included reference matching but not Crossmark, Event Data, or search.crossref.org, which all use the polite pool instead, along with the community. We have the capacity on the internal pool to shift all of this “internal” traffic across, and in doing so we will create more capacity for genuine polite users and redefine what we consider to be “internal”.

Creating more capacity on polite will also give us the opportunity to load-balance requests to both polite and public across the two pools. We are at a point where we cannot eke more performance out of the API without architectural changes. In order to buy ourselves time to address this properly, we will modify the routing of polite and public and evenly distribute requests to the two pools 50/50.

The public and polite pools have equal resources at the moment yet handle very different volumes of traffic (30,000 req/min vs 5,000 req/min), and with the proposed changes to internal traffic the polite pool would handle a fraction of this. The result would look something like 31,000 req/min evenly distributed across public and polite.

Rate limiting

Our rate-limiting also needs review. We track a number of metrics in our web proxy but only deny requests on one of them - the number of requests per second. On public and polite we limit each IP address to sending 50 req/sec and if this rate is exceeded users are denied access for 10 seconds. These limits are generous and we cannot realistically support this volume of request for all users of the public or polite API.

However, when requests are taking a long time to return, we potentially have a separate problem of high concurrency as hundreds of requests could be sent before the first one has returned. We intend to identify and impose an appropriate rate limit on concurrent requests from each IP to prevent a small number of users from disproportionately affecting all users with long-running queries.

Longer-term

So, in the short-term we will revise our pool traffic as described above. We’ll do that this week. Then we will review the current rate limits and reduce them to something more reasonable for the majority of users. And we’ll identify and introduce a rate limit for concurrent requests from each user.

Longer-term, we need to rearchitect our Elasticsearch pools so that we can:

Reduce shard sizes to improve performance of queries
Balance data shards and replicas more evenly
Optimise our instance types for our workload

Want to help?

Thanks for asking!

Firstly, please, everyone, do always put an email in your API request headers - while the short term plan will help stabilise performance, this habit will always help us troubleshoot e.g. we can always contact you instead of blocking you!

Secondly, we know many of you incorporate Crossref metadata, add lots of value to it in order to deliver important services, and also develop APIs of your own. We’d love any comments or recommendations from those of you handling similar situations on scaling and optimising API performance. You can comment on this post which is managed via our Discourse forum. We’ll also be adding updates to this thread as well as on status.crossref.org. If you’d like to be in touch with any of us directly, all our emails are firstinitiallastname@crossref.org.

2024 public data file now available, featuring new experimental formats

Patrick Polischuk — Tue, 14 May 2024 00:00:00 +0000

This year’s public data file is now available, featuring over 156 million metadata records deposited with Crossref through the end of April 2024 from over 19,000 members. A full breakdown of Crossref metadata statistics is available here.

Like last year, you can download all of these records in one go via Academic Torrents or directly from Amazon S3 via the “requester pays” method.

Download the file: The torrent download can be initiated here. Instructions for downloading via the “requester pays” method, along with other tips for using these files, can be found on the “Tips for working with Crossref public data files and Plus snapshots” page.

In January, Martin Eve announced that we had been experimenting with alternative file formats meant to make our public data files easier to use by broader audiences. This year’s file will be published alongside the tools that can be used on the public data file to produce two experimental formats: JSON-lines and SQLite (and a bonus Rust version). You can read more about our thinking behind this work in Martin’s blog post, and we are keen to hear your thoughts on these alternatives.

Our annual public data file is meant to facilitate individuals and organisations interested in working with the entirety of our metadata corpus. Starting with the majority of our metadata records in one file should be much easier than starting from scratch with our API, but because Crossref metadata is always openly available, you can use the API to keep your local copy up to date with new and updated records.

If you’re curious about what you’ll get with the public data file, we’ve also published a sample version so that you can take a peek before committing to downloading the ~212 gb file. This file includes a random sample of JSON files and is available exclusively via torrent here.

We hope you find this public data file useful. Should you have any questions about how to access or use the file, please see the tips below, or share your questions below (you will be redirected to our community forum).

Tips for using the torrent and retrieving incremental updates

Use the public data file if you want all Crossref metadata records. Everyone is welcome to the metadata, but it will be much faster for you and much easier on our APIs to get so many records in one file. Here are some tips on how to work with the file.
Use the REST API to incrementally add new and updated records once you have the initial file. Here is how to get started (and avoid getting blocked in your enthusiasm to use all this great metadata!).
While bibliographic metadata is generally required, because lots of metadata is optional, records will vary in quality and completeness.

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

Subject codes, incomplete and unreliable, have got to go

Patrick Polischuk — Wed, 13 Mar 2024 00:00:00 +0000

Subject classifications have been available via the REST API for many years but have not been complete or reliable from the start and will soon be deprecated. dfdfd

The subject metadata element was born out of a Labs experiment intended to enrich the metadata returned via Crossref Metadata Search with All Subject Journal Classification codes from Scopus. This feature was developed when the REST API was still fairly new, and we now recognize that the initial implementation worked its way into the service prematurely.

While subject classifications in Crossref metadata could be very useful, the current implementation in the REST API is problematic for three primary reasons:

They are misleadingly exposed in the API as a property of the work, when in fact they are a property of the container (e.g. a journal or conference proceeding). Just because a journal’s broad topic category is “X” doesn’t mean that a particular article in the journal is about “X.”

Existing works may have outdated subjects. Originally, subject codes were not updated periodically. However, subjects exposed in the /journals route are now updated once a day. Those exposed via the /works endpoint are indexed along with works, and so when a new subject list is ingested, new DOIs start getting new subjects, but existing works may have outdated subjects. We don’t have a mechanism for forcing updates when incorrect subject values are returned via the REST API, so this data can be stale and incorrect.

They are not applied to everything. This is because the Scopus list does not cover all the journals that Crossref has (conversely, the Scopus list contains some journals Crossref does not have), and does not contain other container types.

The Labs team investigated options for improving subject classification coverage but ultimately concluded that there are insufficient solutions to the coverage problem. For more, please see Esha Datta’s findings published at Force11’s Upstream: https://doi-org.pluma.sjfc.edu/10.54900/n6dnt-xpq48

Where does that leave us? Rather than continuing to supply unreliable and misleading subject category metadata, we will be deprecating this feature in the coming weeks. To minimize disruption and avoid breaking changes at this time, we will be removing this data from our index, so the subject element will simply be empty. We may remove the subject element in the future.

We know that the community’s desire for subject-based analysis of metadata is very strong, and we have supported efforts to establish a multidisciplinary taxonomy. Inaccurate codes in the meantime do not help but actually hinder these efforts, giving the false impression that they are correct.

We aim to deprecate the subject codes in April of this year.

Please let us know if you have any questions or concerns by leaving a comment below, which will start a thread in our community forum.

Frequently asked questions

Q. Will the subject field continue to be available and functional?
A. The subject metadata element will continue to be included in the JSON response but will not return any values.

Q. Will new subject codes be added in the future?
A. We do not have any current plans to add new subject codes in the future.

Q. I received a notification about this, but we don’t use subject codes. Do I need to do anything?
A. No, if you do not currently use the subject element, you do not need to do anything about this change.

Q. I noticed that wrong or inaccurate subject codes were assigned to my works. Is this a solution?
A. Yes. Until we can identify an accurate and sustainable system for assigning subject codes to Crossref metadata records, we want to stop assigning inaccurate subject codes and remove all existing assignments.

Increasing Crossref Data Reusability With Format Experiments

Martin Eve — Fri, 19 Jan 2024 00:00:00 +0000

Every year, Crossref releases a full public data file of all of our metadata. This is partly a commitment to POSI and partly just what we do. We want the community to re-use our metadata and to find interesting ends to which they can be put!

However, we have also recognized, for some time, that 170GB of compressed .tar.gz files, spread over 27,000 items, is not the easiest of formats with which to work. For instance, there’s no indexing capacity on these files, meaning that it is virtually impossible simply to pull out the record for a DOI. Decompressing the .tar.gz files takes a good three hours or more even on high-end hardware, without any additional processing.

To that end, the Crossref Labs team has been experimenting with different formats for trial release that might allow us to reach broader audiences, including those who have not previously worked with our metadata files. The two new formats, alongside the existing data file format, with which we have been experimenting, are JSON lines and SQLite.

JSON-L

The first format with which we’ve been experimenting is JSON-L (JSON lines). With one JSON entry per line, as opposed to one giant JSON file/block, JSON-L lends itself to better parallelisation in systems such as SPARC, because the data can easily be partitioned.

This data format also has the benefit of being appendable, one line at a time. Unlike conventional JSON, which requires the entire structure to be parsed in-memory before an append is possible, JSON-L can simply be written to and updated. It’s also possible to do multi-threaded write operations on the file, without each thread having to parse the entire JSON structure and then sync with other threads.

In our experiments, JSON-L came with substantial parallelisation benefits. Our routines to calculate citation counts can be completed in ~20-25 minutes. Calculating the number of resolutions per container title takes less than half an hour.

SQLite

SQLite is a library written in C with client bindings for Python, Java, C#, and many other languages that produces an on-disk, portable, single-file SQL database. You can produce the SQLite file using our openly available Rust program, rustsqlitepacker. We also have a Python script that can produce the final SQLite file, for those happier working in this language.

The resultant SQLite file is approximately 900GB in size, so it requires quite a lot of free disk space to create in the first place (alongside storage of the data file that is needed to build it). However, queries are snappy when looking up by DOI and other indexes can be constructed (the indexing part of the procedure takes about 1.5 hours per field).

The database structure, at present, is the bare minimum that will work. It contains a list of fields for searching/indexing – DOI, URL, member, prefix, type, created, and deposited – and a metadata field that contains the JSON response that would be returned by the API for this value.

This allows for the processing and extraction of individual JSON elements using SQLite’s built-in json_extract method. For example, to get just the title of an item, you can use:

SELECT json_extract(metadata, ‘$.title’) from works WHERE doi=“10.1080/10436928.2020.1709713”;

The balance that we have had to strike here is between flattening the JSON so that more fields are indexable and searchable, as against the trade-off in time and processing that this takes to create the database in the first place. The first draft version of our experiment was wildly ambitious in flattening all the records and using an Object Relation Mapper (ORM) to present Python models of the database. Like painting the Forth Bridge, this initial attempt would not finish in any sane length of time. Indeed, by the time we’d created this year’s data file, we’d need to begin work on the next.

What are the anticipated use cases here? When people need to do an offline metadata search on an embedded device, for instance, the portability and indexed lookup of the SQLite database can be very appealing. One of our team has even got the database running on a Raspberry Pi 5. You can also load the database into Datasette if you want to explore it visually.

Where do we go from here with this? It would be good to flatten a few more fields, but we would welcome feedback on use cases that we haven’t anticipated for SQLite and we’d love to hear whether this is already too unwieldy (at 900GB).

Data Files

As usual, we will be releasing the annual data file in the next few months. As an experiment this year, we will also be releasing the tools that can be used on that file to produce these alternative file formats. We will consider releasing the final data files for each of these formats, too.

What we would like to hear from the community is whether there are other data file formats that you might wish to use. Are there use cases that we haven’t anticipated? What would you ideally like in terms of file formats?

2023 public data file now available with new and improved retrieval options

Patrick Polischuk — Tue, 02 May 2023 00:00:00 +0000

We have some exciting news for fans of big batches of metadata: this year’s public data file is now available. Like in years past, we’ve wrapped up all of our metadata records into a single download for those who want to get started using all Crossref metadata records.

We’ve once again made this year’s public data file available via Academic Torrents, and in response to some feedback we’ve received from public data file users, we’ve taken a few additional steps to make accessing this 185 gb file a little easier.

First, we’re proactively hosting seeds in a few locations around the world to improve torrent download performance in terms of both speed and reliability.

And second, we’ve added an option to download this year’s public data file directly from Amazon S3 for a small transaction fee paid by the recipient, bypassing the need to use the torrent altogether. The fee just covers the AWS cost of the download. Instructions for downloading the public data file via the “Requester Pays” method are available on the “Tips for working with Crossref public data files and Plus snapshots” page.

The 2023 public data file features over 140 million metadata records deposited with Crossref through the end of March 2023, including over 76,000 grant records. Because Crossref metadata is always openly available, you can use our API to keep your local copy of our metadata corpus up to date with new and updated records.

In previous years, closed and limited references were removed from the public data file. Since we updated our membership terms to make all deposited references open in 2022, the 2023 public data file for the first time includes all references deposited with us.

We hope you find this public data file useful. Should you have any questions about how to access or use the file, please see the tips below, or bring your questions to our community forum.

Tips for using the torrent and retrieving incremental updates

Use the public data file if you want all Crossref metadata records. Everyone is welcome to the metadata, but it will be much faster for you and much easier on our APIs to get so many records in one file. Here are some tips on how to work with the file.
Use the REST API to incrementally add new and updated records once you have the initial file. Here is how to get started (and avoid getting blocked in your enthusiasm to use all this great metadata!).
While bibliographic metadata is generally required, because lots of metadata is optional, records will vary in quality and completeness.

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

2022 public data file of more than 134 million metadata records now available

Patrick Polischuk — Fri, 13 May 2022 00:00:00 +0000

In 2020 we released our first public data file, something we’ve turned into an annual affair supporting our commitment to the Principles of Open Scholarly Infrastructure (POSI). We’ve just posted the 2022 file, which can now be downloaded via torrent like in years past.

We aim to publish these in the first quarter of each year, though as you may notice, we’re a little behind our intended schedule. The reason for this delay was that we wanted to make critical new metadata fields available, including resource URLs and titles with markup.

Crossref metadata is always openly available via our API. We recommend you use this method to incrementally add new and updated records once you’re up and running with an annual public data file. If you’re interested in more frequent and regular “full-file” downloads, consider subscribing to our Metadata Plus program. Plus subscribers have access to monthly snapshots in JSON and XML formats.

Every year our metadata corpus grows. The 2020 file was 65GB and held 112 million records; 2021 came in at 102GB and 120 million records. This year the file weighs in at 160 GB and contains metadata for 134 million records, or all Crossref records registered up to and including April 30, 2022.

Tips for using the torrent and retrieving incremental updates

Use the torrent if you want all of these records. Everyone is welcome to the metadata, but it will be much faster for you and much easier on our APIs to get so many records in one file. Here are some tips on how to work with the file.
Use the REST API to incrementally add new and updated records once you’ve got the initial file. Here is how to get started (and avoid getting blocked in your enthusiasm to use all this great metadata!).
‘Limited’ and ‘closed’ references are not included in the file or our open APIs. And while bibliographic metadata is generally required, lots of metadata is optional, so that records will vary in quality and completeness.

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

With a little help from your Crossref friends: Better metadata

Jennifer Kemp — Thu, 31 Mar 2022 00:00:00 +0000

We talk so much about more and better metadata that a reasonable question might be: what is Crossref doing to help?

Members and their service partners do the heavy lifting to provide Crossref with metadata and we don’t change what is supplied to us. One reason we don’t is because members can and often do change their records (important note: updated records do not incur fees!). However, we do a fair amount of behind the scenes work to check and report on the metadata as well as to add context and relationships. As a result, some of what you see in the metadata (and some of what you don’t) is facilitated, added or updated by Crossref.

Much of the work is automated but some of it still requires manual intervention (sound familiar?). Here’s an overview:

Before registration

Our open APIs allow for Crossref metadata to be used throughout research and scholarly communications systems and services, before and after records are registered with us. Those who have used a search function in something like a manuscript submission system, rather than having to hand key or copy and paste the information, will appreciate how these integrations reduce time, effort and the likelihood of errors in collecting metadata well before it gets to Crossref.

For one example, it’s very common for members to use the metadata to add DOIs to reference lists when preparing deposits. Of course, new members first need a prefix (and a memberID and name, but more on that later) in order to register content. We also provide a suffix generator for help in constructing DOIs. If you’re not sure how best to make use of existing metadata in deposits, we’ve got a few options for you. Questions are welcome.

We don’t often put it this way but we should: Crossref members rely on the metadata as much, if not more, than the rest of the community. More and better metadata directly benefits our members.

Upon registration

There are a number of ways we work with the metadata when deposits are received.

Checking for uniqueness In order to avoid duplicate records, we check to make sure that a title or work hasn’t been registered before. Depending on what we find, a conflict report or failed registration may result.
Adding DOIs to references When references come to us without DOIs, we’ll try to match and add them.
ORCID auto-update We automatically update authors’ ORCID records (with their permission of course) whenever deposits include their ORCID iDs.
Preprint to VoR reports We compare title information and provide notifications of matching records to members depositing preprints, to help them fulfill their obligation to link to Versions of Record (VoRs), where they exist.
Relationships Like preprint to VoR links, components are another kind of relationship. These might be supplementary material such as figures we can link to the ‘parent’ record.
Funding data When members register only a funder name as part of the information on who funded the work, we’ll try to match it to its identifier from the Funder Registry, to support better linking between funders and works.
Timestamps We add date-times for first created and last updated to member-supplied timestamps.
Count of references That’s right, we count all the references for each record that includes them and add the total to the metadata.

After registration

Once registered, we check, report on and update metadata in a few ways.

Link checking We email each member a monthly Resolution Report with details of the number of failed and successful resolutions for their DOIs. If someone in the community reports a DOI that isn’t registered, we email the member a DOI Error Report.
Citation counts and matches Citation counts for records of members participating in our Cited-by service are openly available in our REST API. The matching citations themselves are available to members, for their own records only.
Title transfers Title, prefix and DOI transfers are common and require assistance from our team.
MemberID It’s not uncommon for members to have more than one prefix. The memberID means users of the REST API can query for records associated with all of a member’s prefixes.
Digital preservation We handle the infrequent but critical update of URLs that are necessary when titles are triggered for digital preservation. We also preserve the metadata itself, with both CLOCKSS and Portico.

Of course, since records are often redeposited with updates (note, deposit fees are only charged once per record), some of these processes on our side are repeated as necessary.

This list isn’t exhaustive and other needs and opportunities will emerge. For example, we are looking at matching to add ROR IDs, as we do for funderIDs, and doing some research into how we might determine and assert subject classifications at the work-level. If you’re interested in more about this kind of work, you’ll want to read this recent post by my Labs colleague Dominika on matching grants to outputs.

Get in touch if you have questions or for more information.

A ROR-some update to our API

Rachael Lammey — Wed, 19 Jan 2022 00:00:00 +0000

Earlier this year, Ginny posted an exciting update on Crossref’s progress with adopting ROR, the Research Organization Registry for affiliations, announcing that we’d started the collection of ROR identifiers in our metadata input schema. 🦁

The capacity to accept ROR IDs to help reliably identify institutions is really important but the real value comes from their open availability alongside the other metadata registered with us, such as for publications like journal articles, book chapters, preprints, and for other objects such as grants. So today’s news is that ROR IDs are now connected in Crossref metadata and openly available via our APIs. 🎉

This means ROR can be used by and within all the tools services that integrate with Crossref APIs to analyse, search, recommend, or evaluate research. It’s an important element of the Research Nexus, our vision of a fully connected open research ecosystem, and helps identify, share, and link the affiliations of those producing and publishing different types of research or receiving grants.

Now that this metadata is available, it helps confer the downstream benefits of ROR for different (and interconnected) groups:

It makes it easier for institutions to find and measure their research output by the articles their researchers have published, or perhaps make it easier to track the grants they’ve received.
Funders need to be able to discover and track the research and researchers they have supported.
Academic librarians need to easily find all of the publications associated with their campus.
Journals need to know where authors are affiliated so they can determine eligibility for institutionally sponsored publishing agreements.
Editors can use more accurate information on author and reviewer institutions during the peer review process, which can help avoid potential conflicts of interest.

Those are just a handful of use cases, which is why disseminating ROR affiliation identifiers via our APIs is so important; it lets others choose to do what they need to with the information, without restriction.

The story so far

A growing number of our members have started to include ROR in the metadata they register with us, so we’re excited to be able to see this via simple API queries.

At the time of writing we can see nearly 4,000 RORs being registered by these 21 members (we’ve removed test accounts). Note that many of these are being baked into metadata being registered for grant records, also recently released and now findable through the REST API:

"Wellcome": 2821,
"Natural Resources Canada/CMSS/Information Management": 277,
"University of Szeged": 139,
"RTI Press": 104,
"American Cancer Society": 103,
"University of Missouri Libraries": 77,
"Keldysh Institute of Applied Mathematics": 52,
"Boise State University, Albertsons Library": 52,
"Australian Research Data Commons (ARDC)": 52,
"The Neurofibromatosis Therapeutic Acceleration Program": 49,
"Boise State University": 12,
"The ALS Association": 11,
"Children's Tumor Foundation": 9,
"Episteme Health Inc": 3,
"The University of the Witwatersrand": 2,
"Office of Scientific and Technical Information": 2,
"AGH University of Science and Technology Press": 2,
"York University Libraries": 1,
"SZTEPress": 1,
"Masaryk University Press": 1,
"Institut für Germanistik der Universität Szeged": 1,

Our grants schema accommodated ROR first, so it’s the funder members and grant records that dominate the adoption of ROR… so far! But there are a few articles and reports there too already. These record types include ROR in their records:

"Grant": 3047,
"Report": 382,
"Dissertation": 164,
"Journal Article": 140,
"Conference Paper": 22,
"Posted Content": 12,
"Dataset": 7,
"Monograph": 6,
"Book": 3,
"Chapter": 2,
"Proceedings Series": 1,
"Peer Review": 1,
"Journal Issue": 1,
"Book Set": 1,
"Book Series": 1

We can currently see 205 different ROR IDs in Crossref metadata, with the most frequently provided ROR ID being: https://ror.org/02jx3x895, or University College London as it’s also known as.

If you’re a Crossref member keen to assert affiliation identification in your content, our recent webinar, Working with ROR as a Crossref member: what you need to know, covers all the detail.

Interested in using the information? Dig into our REST API documentation and into the API itself, use the polite pool if you can (i.e. identify yourself). There’s also a wealth of information on the ROR support site or being shared among integrators in the growing ROR community.

Join us in doing more with ROR!

New public data file: 120+ million metadata records

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

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

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

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

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

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

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

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

Helping researchers identify content they can text mine

Geoffrey Bilder — Thu, 16 Apr 2020 00:00:00 +0000

TL;DR

Many organisations are doing what they can to aid in the response to the COVID-19 pandemic. Crossref members can make it easier for researchers to identify, locate, and access content for text mining. In order to do this, members must include elements in their metadata that:

Point to the full text of the content.
Indicate that the content is available under an open access license or that it is being made available for free (gratis).

How to do it.

If your content is open access

Make sure the Crossref metadata for all of your open access content includes:

The URL of the open access license the content is under.
A URL that points to the full text of the content on your site (PDF, XML or HTML).

Instructions for including license and full text URLs in your metadata.

If you are making subscription content available for text mining (temporarily or otherwise).

Make sure the Crossref metadata for the content you are making freely available for text mining includes:

The URL of the publisher license the content is under.
A URL that points to the full text of the content where it is being made freely available (PDF, XML or HTML). This might not be on your site.

Instructions for including license and full text URLs in your metadata.

In addition, you need to flag the content that you are making freely available.

A “free to read” element in the access indicators section of your metadata indicating that the content is being made available free-of-charge (gratis).
An assertion element indicating that the content being made available is available free-of-charge.

Instructions for flagging your content as “free”

Note that step #4 is required in order for users to be able to find content marked as “gratis” in Crossref’s REST API.

And if you decide to revoke the free access in the future, you will need to update the data to reflect that restrictions have been reimposed.

Sounds great. Has anybody else actually done this?

Yes.

Over 43 million metadata records already have a license and a full text link. https://api-crossref-org.pluma.sjfc.edu/works?filter=has-license:true,has-full-text:true&rows=0

Millions of the above items have one of the Creative Commons licenses or a dedicated text and data mining license provided by the publisher.

And in the past three weeks (as of the writing of this blog post) over 23,000 articles have been flagged as “free” so they are available for text mining.

https://api-crossref-org.pluma.sjfc.edu/v1/works?filter=assertion:free,has-full-text:true

Free public data file of 112+ million Crossref records

Jennifer Kemp — Thu, 09 Apr 2020 00:00:00 +0000

A lot of people have been using our public, open APIs to collect data that might be related to COVID-19. This is great and we encourage it. We also want to make it easier. To that end we have made a free data file of the public elements from Crossref’s 112.5 million metadata records.

The file (65GB, in JSON format) is available via Academic Torrents here: https://doi-org.pluma.sjfc.edu/10.13003/83B2GP

It is important to note that Crossref metadata is always openly available. The difference here is that we’ve done the time-saving work of putting all of the records registered through March 2020 into one file for download.

The sheer number of records means that, though anyone can use these records anytime, downloading them all via our APIs can be quite time-consuming. We hope this saves the research community valuable time during this crisis.

A few important notes

All records are included. In other words, the data file has every DOI ever registered with Crossref through March 31st, 2020. This means it’s a large file, 65GB.
- Metadata is supplied by our members and, as such, not all records have the same completeness (or quality) of metadata. Bibliographic metadata is generally required. All other metadata, e.g. license and funding information, ORCIDs, etc. is optional (though very much encouraged).
- References (i.e. authors’ cited sources) are also optional metadata. Nearly 50 million records include references and, of those, nearly 30 million have open references that are included in the data file. “Limited” and “Closed” references are not included in the data file. [EDIT 6th June 2022 - all references are now open by default with the March 2022 board vote to remove any restrictions on reference distribution].
- If an error in the metadata is found, please report it directly to the publisher to correct.
The records are in JSON.
New and updated records can be added incrementally using our REST API, which includes a number of date filter options, e.g. index-date.
No registration is required to use our REST API but we do strongly encourage being a ‘polite’ (i.e. identified) user. It makes troubleshooting much easier and reduces the chance of negatively impacting other users.

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

We thank AcademicTorrents.com for helping us make this data available. And we are grateful for the incredible efforts of everyone working to support research everywhere–stay safe and well.

Crossref metadata for bibliometrics

Ginny Hendricks — Fri, 21 Feb 2020 00:00:00 +0000

Our paper, Crossref: the sustainable source of community-owned scholarly metadata, was recently published in Quantitative Science Studies (MIT Press). The paper describes the scholarly metadata collected and made available by Crossref, as well as its importance in the scholarly research ecosystem.

Containing over 106 million records and expanding at an average rate of 11% a year, Crossref’s metadata has become one of the major sources of scholarly data for publishers, authors, librarians, funders, and researchers. The metadata set consists of 13 record types, including not only traditional types, such as journals and conference papers, but also data sets, reports, preprints, peer reviews, and grants. The metadata is not limited to basic publication metadata, but can also include abstracts and links to full text, funding and license information, citation links, and the information about corrections, updates, retractions, etc. This scale and breadth make Crossref a valuable source for research in scientometrics, including measuring the growth and impact of science and understanding new trends in scholarly communications. The metadata is available through a number of APIs, including REST API and OAI-PMH.

In the paper, we describe the kind of metadata that Crossref provides and how it is collected and curated. We also look at Crossref’s role in the research ecosystem and trends in metadata curation over the years, including the evolution of its citation data provision. We summarize the research that used Crossref’s metadata and describe plans that will improve metadata quality and retrieval in the future.

Using the Crossref REST API (with Open Ukrainian Citation Index)

Rachael Lammey — Wed, 05 Feb 2020 00:00:00 +0000

Over the past few years, I’ve been really interested in seeing the breadth of uses that the research community is finding for the Crossref REST API. When we ran Crossref LIVE Kyiv in March 2019, Serhii Nazarovets joined us to present his plans for the Open Ukrainian Citation Index, an initiative he explains below.

But first an introduction to Serhii and his colleague Tetiana Borysova.

Serhii Nazarovets is a Deputy Director for Research at the State Scientific and Technical Library of Ukraine. Serhii has a Ph.D. in Social Communication Science. His research interests lie in the area of scientometrics and library science. Serhii is the Associate Editor for DOAJ (www.doaj.org) and the Regional Editor for E-LIS (Eprints in Library and Information Science). Serhii has worked in different scientific libraries of Ukraine for more than 10 years. Tetiana Borysova is a Senior Researcher at the State Scientific and Technical Library of Ukraine. Her research interests are focused on topics such as research data management, journal management and scientometrics.

Introducing OUCI

OUCI (Open Ukrainian Citation Index) is a new search engine and a citation database based on publication metadata from Crossref members.

OUCI is intended to simplify the search of scientific publications, to attract the editors’ attention to the problem of completeness and quality of the metadata of Ukrainian scholarly publications, and will allow bibliometricians to freely study the relations between authors and documents from various disciplines, in particular in the field of social sciences and humanities. OUCI is open for every user in the world without any restrictions.

OUCI launched in November 2019. The project is being implemented by the State Scientific and Technical Library of Ukraine with the support of the Ministry of Education and Science of Ukraine.

In Ukraine, we do not have a national citation database, and this significantly impedes the search and analysis of information about Ukrainian publications. According to preliminary estimates, more than 3,000 titles of scientific journals are currently published in Ukraine. At the same time, only around 100 Ukrainian journal titles are indexed in authoritative citation databases, such as Scopus and Web of Science Core Collection. Thus, researchers and managers lack this citation data to understand the impact of Ukrainian journals and their demand in the scientific communication system. Our approach is that OUCI database contains metadata from all publishers that use the Crossref’s Cited-by service and who support the Initiative for Open Citations by making the reference metadata they publish with Crossref openly available.

How is Crossref metadata used in OUCI?

A publication can only be indexed in OUCI if there is a DOI. At first glance, the idea of creating an index of national publications based on this condition may seem too optimistic. However, in January 2018, a new requirement was adopted by the List of scientific publications of Ukraine (a list of Ukrainian journals recognized by experts as qualitative for publishing their research results for a scientific degree), which listed a DOI as one of the requirements for inclusion. After that, the number of publishers who received the DOI prefix from Crossref has tripled, to 352 in November 2019.

Another important feature of OUCI is that publishers have to use Crossref’s Cited-by service and support the Initiative for Open Citations. We are working to build a new fair infrastructure where everyone who is interested in the dissemination of scientific knowledge can present their publications to the community, develop expert judgment skills and access citations to explore the links between documents. The philosophy of the index is to use only open resources to fill it.

In addition to standard filters from Crossref metadata (such as publisher, publication, type, year), OUCI offers to refine search results by:

indexation in Web of Science and/or Scopus,
journal category (A or B according to the List of scientific publications of Ukraine),
the field of knowledge and scientific specialties (according to the Ukrainian legislation) and other aspects important to Ukrainian users characteristics.

Figure 1: OUCI search and filter options

Beyond the ability to search articles, OUCI displays profiles for Ukrainian journals (the titles of these journals will include hyperlinks in the search results). Administrators can manage them, add and edit information about their journals: web-site, aims and scope, scientific fields of the journal according to the Ukrainian classification. Also, you can see some quantitative characteristics of journals: number of publications, number of citations, h-index, i10-index etc.

Figure 2: Display of journal information in OUCI

In addition, we have implemented an analytics module. Using the data about the number of articles and citations from Crossref, it allows users to analyze Ukrainian journals by field.

Figure 3: Publication and citation information

What are the future plans for OUCI?

In the near future, we plan to add:

the ability to export search results for further analysis;
integration with Unpaywall;
alternative metrics from Crossref Event Data.

In the ideal future for our index, every Ukrainian article will be registered with Crossref and have open references. We plan to promote the importance of reach and quality metadata in Crossref among Ukrainian publishers. We also encourage all publishers to support the Initiative for Open Citations.

What else would OUCI like to see in Crossref metadata?

One of the main problems we encountered when creating OUCI was the metadata about the authors. Very few publications contain data about the author’s ORCID iD. Focusing publishers on the need to transmit full metadata to Crossref, as well as monitoring their quality is a must for the resources like this. Also we look forward to the growing usage of ROR (Research Organization Registry) - identifiers for research organisations, similar to the way that ORCID offers identifiers for researchers. We believe that the ROR will help to obtain reliable data for analyzing the scientific activity of Ukrainian institutions.

Another issue we’ve identified in some Ukrainian journals that some of the small publishers that register content via Crossref Sponsors did not take care getting their own prefix, so it can be difficult to see their publications - this is something that showing the metadata via an index can help them see and therefore fix.

Questions?

We’ve had lots of questions about OUCI in the run up to the launch and now that it’s live. Here is a selection of our FAQs, all available on our website. You can also get in touch directly if you have another question we haven’t answered yet.

Underreporting of matched references in Crossref metadata

Geoffrey Bilder — Tue, 05 Feb 2019 00:00:00 +0000

TL;DR

About 11% of available references in records in our OAI-PMH & REST API don’t have DOIs when they should. We have deployed a fix, but it is running on billions of records, and so we don’t expect it to be complete until mid-April.

Note that the Cited-by API that our members use appears to be unaffected by this problem.

The gory details

When a Crossref member registers metadata for a publication, they often include references. Sometimes the member will also include DOIs in the references, but often they don’t. When they don’t include a DOI in the reference, Crossref tries to match the reference to metadata in the Crossref system. If we succeed, we add the DOI of the matched record to the reference metadata. If we fail, we append the reference to an ever-growing list which we re-process on an ongoing basis.

You may have seen that the R&D team has been doing work to improve our reference matching system. We will soon be rolling out a new reference matching process that will increase recall significantly.

But while testing our new reference matching approach, we started to see inconsistent results with our existing legacy reference matching system. When we implemented new regression tests, we noticed that, even when using our legacy system, we were consistently getting better results than were reflected in the metadata we exposed via our APIs. For example, we would pick a random Crossref DOI record that included 3 matched references, and when we tried matching all the references in the record again using our existing technology, we would get more matched references than were reported in the metadata.

At first, we thought this might have something to do with sequencing issues. For example, that article A might cite article B, but somehow article A would get its DOI registered with Crossref prior to article B. In this theoretical case, we would initially fail to match the reference, but it would eventually get matched as we continued to reprocess our unmatched references. But this wasn’t the issue. And the problem was not with the matching technology we are using. Instead, we discovered a problem with the way we process references on deposit.

When a member deposits references with Crossref, each reference has to include a member-defined key that is unique to each reference they are depositing in the DOI record. When we match a reference- we report to the members that we matched the reference with key X to DOI Y. The problem is that sometimes members would deposit references with an empty key. If there was only one such reference, then, technically, it would pass our test for making sure the key was unique within the record. So we would process the reference, and match it, and report it via our Cited-by service, but later in the process, when we went to include the matched DOI in the reference section of our API metadata, we’d skip including DOIs for references that had blank keys. The reference itself would be included in the metadata, it would just appear that we hadn’t matched it to a DOI when we actually had.

Again, we estimate this to have resulted in about 11% of the references in our metadata to be missing matched DOIs. We are processing our references again and inserting the correctly matched DOIs in the metadata. We expect the process to complete in mid-April. We will keep everybody up-to-date on the progress of this fix.

We will also be integrating the new matching system that we’ve developed. As mentioned at the start of this post, this matching system will also increase the recall rate of our reference matching and so, the two changes combined, should result in users seeing a significant increase in the number of matched references included in Crossref metadata.

And finally, as part of the work that we are doing to improve our reference matching, we are putting a comprehensive testing framework that will make it easier for us to detect inconsistencies and/or regressions in our reference matching.

Please contact Crossref support with any questions or concerns.

How Crossref metadata is helping bring migration research in Europe under one roof

Christine Cormack Wood — Tue, 29 Jan 2019 00:00:00 +0000

Conflict, instability and economic conditions are just some of the factors driving new migration into Europe—and European policy makers are in dispute about how to manage and cope with the implications. Everyone agrees that in order to respond to the challenges and opportunities of migration, a better understanding is required of what drives migration towards Europe, what trajectories and infrastructures facilitate migration, and what the key characteristics of different migrant flows are, in order to inform and improve policy making.

The abstract above is taken from the successful Horizon 2020[1] project proposal called CrossMigration, an initiative of IMISCOE, Europe’s largest migration research network, in which a consortium of 15 universities, think tanks and international organisations, led by Erasmus University Rotterdam is currently designing a Migration Research Hub. The Hub is a web-based platform aimed at helping researchers and policymakers get a quick and comprehensive overview on research in the field of migration studies. This platform will also feature reports on specific fields, methodological briefing papers and other relevant content produced by the consortium.

The core of this Hub will consist of a database providing access to publications, research projects and datasets on migration drivers, and infrastructures, flows, and policies on current and future migration questions, indicators and scenarios. And that’s where our metadata story starts.

At the tail end of December I had the pleasure of speaking to the four researchers and developers working on this database; Vienna-based researchers Roland Hosner and Meike Palinkas from the International Centre for Migration Policy and Development (ICMPD), Bogdan Taut, CEO of YoungMinds, in Bucharest, Romania, and Nathan Levy, currently studying for his PhD at Erasmus University Rotterdam, Department of Public Administration and Sociology, Netherlands.

There are four of you, can each of you give me a very brief introduction to yourselves and how you fit into project?

Bogdan: I’m from YoungMinds, based in Bucharest in Romania. We were the last to join the consortium as the technical developer on the project. I am the project manager of the team, coordinating the technical development of the database.

Roland: I am a research officer with the International Centre for Migration Policy Development (ICMPD) in Vienna, and we are leading a part of this research project which deals with the population and implementation of the research database—which is core to the Migration Research Hub, and to the whole project.

Meike: I am also a research officer at ICMPD and work together with Roland. I joined the team in September this year.

Nathan: I’m part of the coordinating team of the overall project of CrossMigration. We are coordinating putting together the Migration Research Hub, the biggest part of which is the migration database. I am based at Erasmus University in Rotterdam and I work for Professor Peter Scholten who is the overall coordinator of the whole project along with Dr. Asya Pisarevskaya.

How long has the project been in progress?

Roland: It’s a two-year project than runs from March 2018 to the end of February 2020.

So it’s a two-year project and you are 10 months in—that makes it nearly at the halfway mark. Have you encountered any stumbling blocks that have held you back?

Bogdan: How to put this in a diplomatic way? We are all working around the clock to meet the deadline that we set ourselves and promised to deliver by. We have made the decision to produce the database in stages—very soon we will have the beta version out, so we have something to present. Then we are going to continue populating it with more items from every record type – journal articles, datasets, books, book chapters, reports etc.. At this point the other partners in the consortium can actually use it and work with it to map the fields and find the most recent and relevant literature on their respective subtopics such as migration drivers or migration infrastructures. In the summer when we are confident that it is a sound and attractive tool to be released, we will make it publicly available.

Nathan: In terms of specific deliverables for the project so far, our team has developed a taxonomy for migration research to give the fields a logical structure, and to structure this research database.

How has Crossref metadata contributed to your project?

Bogdan: We began by discussing all of the sources that need to be in the database and we put together an inventory of publishers, books and book chapters, etc., that would be relevant. Part of the scope of work for YoungMinds was to find ways of extracting information and relevant content from those sources. Once we started to dig into the content we found out that there are relevant aggregators, such as Scopus, Crossref, Web of Science and so on. We actually found Crossref through a recommendation from Scopus, someone there said ‘OK Crossref might be able to help you more’. Then Crossref became one of our main sources for metadata—in terms of basic metadata related to some types of content we gather for our database, such as journals and journal articles.

Roland: The more we moved forward, the more we saw how difficult it was to get in touch with each publisher individually, with each journal individually, to try and secure an agreement with them. So, it became very clear to us very quickly that we would not be able to create a properly inclusive database this way and we knew we had to look for partners and make use of existing resources. As we progressed from one conversation to the next we received a lot of advice, and that’s how we found out about Crossref. It soon became clear that Crossref was the ideal source for us because everything that has a DOI can be found in there. We knew if we had an agreement with Crossref then our project is half won, our database is halfway built, perhaps even more. And, then we just need to fill the gaps.

Nathan: Yes, this is one of Crossref’s key strengths—rather than having individual researchers or individual projects go to each publisher to try to find the appropriate people to talk to and negotiate—you use Crossref.

Which of the metadata values are important to you, what do you extract?

Roland: We thought about this a lot at the beginning, what we wanted to include. There are certain key things that are indisputably relevant—such as titles, names of the authors, editors, the year, DOI, dataset and so on, because we always link to the original source—the publisher’s website, or the journal article website. Ideally we would include keywords and abstracts (where they are available) because the richer the information the better. We also wanted to classify the items we have according to the taxonomy the CrossMigration project has established.

Nathan: In addition, abstracts and keywords have value for us. We want to apply a logical structure into the taxonomy on migration research, but we need content in order to do that. We need something for the algorithms that YoungMinds have developed to read to in order categorize research accordingly. The body of research on migration is so great and we cannot read through every abstract that’s ever been published on migration. That’s where the value of abstracts and keywords comes in for the Taxonomizer (as we fondly refer to it!).

What else would you like to see in the REST API that isn’t there?

Roland: More abstracts! We love abstracts!

Bogdan: Our data schema contains more fields, so we need more metadata than we can find from Crossref and other sources. Basically, the publisher’s website would produce the richest data, but it is the hardest to read. We are on a quest to find more sources because our algorithm works better if it has more information.

Once it’s complete, what are your plans to roll it out to the wider world?

Bogdan: IMISCOE is the leading organisation of this consortium and it is in touch with most of the migration experts in Europe, so we already have all the contacts of the relevant people in the field.

Meike: It’s a tool for helping the community, so once we have all the relevant content inside it, we believe that word will spread relatively easily.

Have you all actually met in person?

Roland: Yes! Myself and Nathan met at the project kick-off meeting in Rotterdam in March 2018, then we met at a conference in Florence in June that was partly for the consortium but also had other invited experts and scholars. That was where we met face-to-face for the first time—it was just after we signed with YoungMinds for the IT services. And we recently met at another joint conference of IMISCOE and CrossMigration called 'Towards the IMISCOE Research Infrastructure of the Future'.

[1] Horizon 2020, the biggest EU Research and Innovation programme ever with nearly €80 billion of funding available.

Great speaking to you all and learning a bit about this important project that will help policymakers manage and cope with the implications of migration—and may possibly even help them find ways to influence it.

If you’d like to share how you use our Metadata APIs please contact the Community team.

Using the Crossref REST API. Part 12 (with Europe PMC)

Christine Cormack Wood — Wed, 10 Oct 2018 00:00:00 +0000

As part of our blog series highlighting some of the tools and services that use our API, we asked Michael Parkin—Data Scientist at the European Bioinformatics Institute—a few questions about how Europe PMC uses our metadata where preprints are concerned.

Tell us a bit about Europe PMC

Europe PMC is a knowledgebase for life science research literature and a platform for innovation based on the content, such as text mining. It contains 34.6 million abstracts and 5 million full-text articles. At Europe PMC we support the research community by developing tools for knowledge discovery, linking publications with underlying research data, and building infrastructure to support text and data mining. Our goal is to create a supportive environment around open access content and data, to maximise its reuse.

What problem is your service trying to solve?

Recent years have seen a dramatic increase in the popularity of preprints within life sciences literature. Preprints have been supported by Crossref since November 2016. In response to the rise in popularity, we have started indexing preprints alongside traditional journal publishing within Europe PMC. We expect this will:

provide another means to access and discover this emergent form of scholarly content
help explore more transparently the role of preprints in the publishing ecosystem
support their inclusion in processes such as grant reporting and credit attribution systems

How do you use Crossref metadata?

Europe PMC operates an open citation network that uses reference lists from our full-text content, supplemented with metadata supplied by the Crossref OAI-PMH API. The number of citations we retrieve from Crossref increased significantly in 2017 thanks to the efforts of the Initiative for Open Citations (I4OC) in improving awareness about sharing citation data.

Our work to ingest preprints into Europe PMC, however, represents our first use of the Crossref REST API. We make a series of queries for each preprint provider, making use of the “posted-content”, “prefix” and (optionally) “has-abstract” filters. We intend to migrate to using the REST API for the majority of retrievals of Crossref content in due course.

What metadata values do you make use of?

Currently we make use of the following fields:

posted as a publication date
abstract
DOI
author for author given names and surnames
title as the preprint title
is-preprint-of to establish preprint –> article links

How often do you extract/query metadata?

We query the REST API daily making use of the from-index-date filter and cursor pagination to insert new or modify existing records. This means that preprints will be available in Europe PMC within 24 hours of the metadata being sent to Crossref. We store the full REST response in MongoDB, a document-based database. Here are some examples of Crossref API queries used to preprint provider PeerJ Preprints:

calling `https://api-crossref-org.pluma.sjfc.edu/works?filter=type:posted-content,has-abstract:true,from-index-date:2018-07-29,prefix:10.7287&sort=updated&rows=1000&cursor=*`
calling `https://api-crossref-org.pluma.sjfc.edu/works?filter=type:posted-content,has-abstract:true,from-index-date:2018-07-29,prefix:10.7287&sort=updated&rows=1000&cursor=AoN4ldf88uQCe6e1g%2FPkAj8SaHR0cDovL2R4LmRvaS5vcmcvMTAuNzI4Ny9wZWVyai5wcmVwcmludHMuMjcwNjJ2MQ%3D%3D`
Done importing PeerJ Preprints
modified: 2
inserted: 10

What do you do with the metadata?

From the database we parse out the relevant fields and pass them to our main relational database prior to indexing. This avails the preprint abstracts to all of the value-added services we offer for peer-reviewed abstracts, such as citations, grants, ORCID claiming, text mining, etc. We assign a unique persistent identifier comprising “PPR” followed by a number (1) to each preprint record.

This is displayed on the Europe PMC site as an abstract record, analogous to PubMed records, but with an obvious banner (2) indicating to readers the preprint designation; a tooltip provides further explanation of what a preprint is in comparison to a peer-reviewed article.

Once available on the Europe PMC platform, we then apply downstream processes including:

providing an Unpaywall link directly to the full-text (3);
adding a hyperlink to the final published version (if there is one that we can detect) (4);
incorporating the preprint into our citation network (5);
adding useful links to e.g. alternative metrics, scientific comments and peer reviews, underlying research data in life science databases (6);
providing text mined annotations via SciLite (7);
including funding information (8);
displaying ORCID claims in the author list (9).

What are the future plans for Europe PMC and preprints?

The inclusion of preprints within Europe PMC is of immediate benefit to researchers who want to explore the very latest research. Moreover we see this as an opportunity for both ourselves and the community to explore how preprints fit into the wider publishing ecosystem; for example to answer questions such as: How often will they be cited? How will they be linked to grant funding and other credit systems? How will they be reused?

What else would you like our API to do?

The REST API and rich metadata model provided by Crossref around preprints are both excellent, but the population of the metadata fields by preprint providers can be limited and/or heterogeneous. The key challenge we see is in encouraging providers to populate the Crossref metadata fields more fully and in a uniform manner.

Thanks to Michael.

If you’d like to share how you use our Metadata APIs please contact the Community team.

Using the Crossref REST API. Part 11 (with MDPI/Scilit)

Christine Cormack Wood — Tue, 18 Sep 2018 00:00:00 +0000

Continuing our blog series highlighting the uses of Crossref metadata, we talked to Martyn Rittman and Bastien Latard who tell us about themselves, MDPI and Scilit, and how they use Crossref metadata.

Can you give us a brief introduction yourselves, and to MDPI/Scilit

Martyn is Publishing Services Manager at MDPI. He joined five years ago as an editor and has worked on editorial, production, and software projects. Prior to joining MDPI, he completed a PhD and worked as a postdoc. His research covered physical chemistry, biochemistry and instrument development. Bastien Latard is the project leader of Scilit. He created Scilit as part of his Master’s degree in 2013. He is now completing a PhD on the subject of semantically linking research articles, using data from Scilit.

Scilit was developed in 2014 by open access (OA) publisher MDPI with the goal of having a backup of metadata for all OA articles. Soon, Scilit became more general and embraced all articles with a digital object identifier (DOI) from Crossref and those with a Pubmed ID (PMID). After seeing the potential of the database and how it could be used in a number of different contexts, we decided to make it public. Recently, other article types, including preprints have been integrated. Our main goal now is to provide useful services to the research and academic publishing communities.

What problem is your service trying to solve?

Other indexing databases offer paid access, are highly selective, or host documents apart from research articles. We want to offer a comprehensive database, but also one that clearly identifies open access material. The last part is still a work in progress, but we have made good progress recently.

To make the access as direct as possible, we have recently integrated several OA aggregators that pick up or host free versions of full-text articles, including CORE, Unpaywall, and PubMed Central.

Can you tell us how you are using the Crossref Metadata API at MDPI/Scilit?

Scilit queries Crossref’s API in order to index metadata for single articles. DOIs are a key part of the system; because they are standards, we can use them to merge new sources into Scilit while avoiding duplicates. We cross-check the data from Crossref against other sources and update it as necessary. Citation data is also really appreciated and opens doors to further developments.

As a publisher, MDPI makes daily deposits to Crossref, to register journal articles on mdpi.com, conference papers from sciforum.net, and preprints from Preprints.org. We also use the data collected at Scilit to find suitable reviewers and let authors know when their work has been cited.

What metadata values do you pull from the API?

As much as we can! Scilit crawls the latest indexed articles every few hours to ensure it is as up-to-date as possible. This is the most important function of our system because it provides metadata for the very latest published articles, including a link to the publisher version. Scilit parses Crossref metadata and saves them. They are then indexed into our solr search engine for fast, real-time usage.

Have you built your own interface to extract this data?

We wrote our own code to get the data, but the API interface made this very straightforward. Scilit has been developed completely in-house by MDPI and the lead developer, Bastien Latard, is currently completing a PhD looking at how to make the most of the data using semantic data extraction.

What are the future plans for MDPI/Scilit?

Scilit is and will be highly used in MDPI current and future projects. We have a few ideas about how to improve Scilit. We are, for example, implementing a scientific profile networking service, which will allow scholars to build their own (scientific) network with lots of functionalities. We think that it will be a really good place to search, comment, exchange around articles… maybe even more!

What else would you like to see the REST API offer?

Crossref is already doing a great job, especially with its integrated citation data. Maybe further analysis and mapping of data about organisations and institutions would be an improvement.

Thank you Martin and Bastien. If you’d like to share how you use the Crossref Metadata APIs please contact the Community team.

Leaving the house - where preprints go

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

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

So where in fact do preprints get published?

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

rOpenSci makin’ it sweet & easy

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

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

The big reveal

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

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

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

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

Taking a closer look

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

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

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

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

Everyone dive in!

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

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

Using the Crossref REST API. Part 10 (with Kudos)

Christine Cormack Wood — Mon, 13 Aug 2018 00:00:00 +0000

Continuing our blog series highlighting the uses of Crossref metadata, we talked to David Sommer, co-founder and Product Director at the research dissemination management service, Kudos. David tells us how Kudos is collaborating with Crossref, and how they use the REST API as part of our Metadata Plus service.

Introducing Kudos

At Kudos we know that effective dissemination is the starting point for impact. Kudos is a platform that allows researchers and research groups to plan, manage, measure, and report on dissemination activities to help maximize the visibility and impact of their work.

We launched the service in 2015 and now work with almost 100 publishers and institutions around the world, and have nearly 250,000 researchers using the platform.

We provide guidance to researchers on writing a plain language summary about their work so it can be found and understood by a broad range of audiences, and then we support researchers in disseminating across multiple channels and measuring which dissemination activities are most effective for them.

As part of this, we developed the Sharable-PDF to allow researchers to legitimately share publication profiles across a range of sites and networks, and track the impact of their work centrally. This also allows publishers to prevent copyright infringement, and reclaim lost usage from sharing of research articles on scholarly collaboration networks.

An example of a Kudos publication page showing the plain language summary

How is Crossref metadata used in Kudos?

Since our launch, Crossref has been our metadata foundation. When we receive notification from our publishing partners that an article, book or book chapter has been published, we query using the Crossref REST API to retrieve the metadata for that publication. That data allows us to populate the Kudos publication page.

We also integrate earlier in the researcher workflow, interfacing with all of the major Manuscript Submission Systems to support authors who want to build impact from the point of submission.

More recently, we started using the Crossref REST API to retrieve citation counts for a DOI. This enables us to include the number of times content is cited as part of the ‘basket of metrics’ we provide to our researchers. They can then understand the performance of their publications in context, and see the correlation between actions and results.

A Kudos metrics page, showing the basket of metrics and the correlation between actions and results

What are the future plans for Kudos?

We have exciting plans for the future! We are developing Kudos for Research Groups to support the planning, managing, measuring and reporting of dissemination activities for research groups, labs and departments. We are adding a range of new features and dissemination channels to support this, and to help researchers to better understand how their research is being used, and by whom.

What else would Kudos like to see in Crossref metadata?

We have always found Crossref to be very responsive and open to new ideas, so we look forward to continuing to work together. We are keen to see an industry standard article-level subject classification system developed, and it would seem that Crossref is the natural home for this.

We are also continuing to monitor Crossref Event Data which has the potential to provide a rich source of events that could be used to help demonstrate dissemination and impact.

Finally, we are pleased to see the work Crossref are doing to help improve the quality of the metadata and supporting publishers in auditing their data. If we could have anything we wanted, our dream would be to prevent “funny characters” in DOIs that cause us all kinds of escape character headaches!

Thank you David. If you would like to contribute a case study on the uses of Crossref Metadata APIs please contact the Community team.

Using the Crossref REST API. Part 9 (with Dimensions)

Christine Cormack Wood — Wed, 27 Jun 2018 00:00:00 +0000

Continuing our blog series highlighting the uses of Crossref metadata, we talked to the team behind new search and discovery tool Dimensions: Daniel Hook, Digital Science CEO; Christian Herzog, ÜberResearch CEO; and Simon Porter, Director of Innovation. They talk about the work they’re doing, the collaborative approach, and how Dimensions uses the Crossref REST API as part of our Metadata Plus service, to augment other data and their workflow.

Introducing Dimensions

Dimensions is a next-generation approach to discovering, connecting with and contextualising research. Modern academics need data about the research ecosystem in which they exist as much as the administrators who develop institutional research strategies. All academics are now required to think long-range about their research projects, contextualise their research, and demonstrate the impact of their program. Additionally, they need to find funding, ensure that students go on to good positions, and hire talented colleagues whose skills fit well with ongoing projects. Dimensions gives the first fully-linked view of publications, grants, patents and clinical trials in an analytically-centred user experience.

How is Crossref data used within Dimensions?

For an article to appear in Dimensions it must have a Crossref DOI, so it would not be possible to create Dimensions’ Publication index without Crossref’s data. Dimensions is built on several principles that we’ve talked about before. Here the most relevant of those principles are:

unique identifiers should underlie everything that we do;
data should not be inclusive and the tool should allow the user to select what they want to see;
data should be more available to our community;
data should be presented with as much contextual information as possible;
the community should have enough data available to be able to create and experiment with their own metrics and indicators.

In the context of these principles, Crossref makes a perfect starting place to create a tool like Dimensions. We use the Crossref data to know about our possible “universe” of articles. We then enhance the Crossref core with data from several different places: open access publications in the DOAJ, PubMed, BioArXiv, and through relationships with publishers. In all, 60 million of the 95 million articles in the Dimensions index have a full text version that we can text and data mine for additional information.

In Dimensions’ enhancement stage we can extract address information (where not included in the original Crossref record) and map it to GRID funding information and the list of funders in Crossref’s Funder Registry as well as to our database of grants in Dimensions.

How have you incorporated citation data?

Access to citations has historically been a thorny issue for citations databases. However, I4OC celebrated its first anniversary in April this year and this project has been a key driver in helping us to build Dimensions with the level of citation coverage that we managed –– it is a fantastic enabling initiative and should be warmly welcomed by the sector. Crossref is not the only source we were able to use to gather citation data; some text mining was needed to get a full graph. Dimensions goes beyond inter-article citations and includes links between patents and publications, links between clinical trials and publications, and Altmetric mentions of publications.

Is Dimensions openly available?

Given that there is so much open data in Dimensions, it was always our intention to give a free version to the community. If you visit http://app.dimensions.ai.pluma.sjfc.edu then you’ll be able to play with the system and use it for your research. While only the publications index is fully open, when you see a link to a grant, patent or clinical trial in an article detail page, you’ll be able to navigate to that record so that you can see the full context of the data.

Beyond the ability to link the publications, Dimensions also displays the CV information which the researcher made visible publicly.

Most recently, we’ve integrated ORCID into Dimensions. This means that you can push data from Dimensions into ORCID if you connect your ORCID account to your Dimensions account.

What are the future plans for Dimensions?

Dimensions is still moving quickly and adding more functionality. Our aim is to release more data facets very soon. We plan to add a Policy Document archive and a Research Data archive. We’ve already found some fascinating insights from joining the existing data together and these two new archives should add even more interesting data.

What else would Dimensions like to see in Crossref metadata?

Open access information is something that we work with Unpaywall to source for Dimensions right now. It would be great if Crossref and Unpaywall could work together to make this data higher quality and more ubiquitous.

Thank you Daniel, Christian and Simon.

If you would like to contribute a case study on the uses of Crossref Metadata APIs please contact the Community team.

Using the Crossref REST API. Part 8 (with Researchfish)

Christine Cormack Wood — Mon, 23 Apr 2018 00:00:00 +0000

Continuing our blog series highlighting the uses of Crossref metadata, we talked to Gavin Reddick, Chief Analyst at Researchfish about the work they’re doing, and how they’re using our REST API as part of their workflow.

Introducing Researchfish

Researchfish is the world’s leading platform for the reporting of the outputs, outcomes and impacts of funded research. It is used by over 100 funding organisations in Europe, North America and Australasia and currently tracks around €50 billion of funding, across 125,000 grants. Researchers have reported around 2.5 million attributed outcomes in Researchfish and roughly half of these are publications with the other half being collaborations, further funding, data sets, policy influences, engagement activities etc.

Funders use Researchfish to ask grantees to report on the outcomes of their grant and Researchfish makes it easy for researchers to do this in a structured way. Researchfish seeks to improve the quality and robustness of the evidence base available for evaluation. It works with funders, research organisations and researchers to present, explain and evaluate the impact of research across all disciplines and a wide range of output types.

How is the Crossref REST API used in Researchfish?

Search
As publications are a major output of research it is important to make the reporting of those publications be as easy as possible and quality of the information on those publications as high as possible. Researchfish integrates with a number of publication APIs, including Crossref, which enables users to enter a number of DOIs or search by author, title, etc. to find their publication.
Direct Harvest
Researchfish uses funding acknowledgements in the Crossref metadata to add publications to researchers’ portfolios and report the publications as arising from the grant. If the acknowledgement exists it’s important to use it instead of asking researchers to report the same thing twice.
Interoperability
Research organisations can upload publications to Researchfish on behalf of researchers, re-using information from their local systems. We use the Crossref REST API to validate the data provided by universities before uploading.
Metadata Enrichment – Open Access
We use the license and embargo period information in the Crossref metadata to help understand the open access status of publications and whether they meet any policy requirements, without researchers having to take any steps to report in this complex area.
Metadata Enrichment – Normalisation/deduplication
As Researchfish allows users to add information from lots of different sources it is very important to normalise the data and prevent the same publication being reported multiple times in different ways. We use the Crossref REST API as part of this process.

What are the future plans for Researchfish?

We are looking to expand the range of integrations to support non-publication outputs and allow some of the same functionality that we have built for publications. We already have integrations to support the reporting of patents, collaborations, further funding and next destinations but are looking to enhance these, along with expanding links to data sets, clinical trials, software and spin out companies.

What else would Researchfish like to see in Crossref?

Crossref is an excellent resource and most of our wish list would be to see more uptake of existing fields e.g. retractions and the ability to use them more flexibly in the REST API. We would also like to see a little more consistency in some of the metadata – publication type is the area that seems to cause the most confusion, particularly around conference proceedings and clinical trials.

Thank you Researchfish! If you would like to contribute a case study on the uses of Crossref Metadata APIs please contact the Community team.

Using the Crossref REST API. Part 7 (with CHORUS)

Christine Cormack Wood — Mon, 27 Nov 2017 00:00:00 +0000

Continuing our blog series highlighting the uses of Crossref metadata, we talked to Sara Girard and Howard Ratner at CHORUS about the work they’re doing, and how they’re using our REST API as part of their workflow.

Introducing CHORUS

CHORUS (www.chorusaccess.org) is an innovative non-profit organisation that supports funders, publishers, authors and institutions to deliver public access to articles reporting on funded research. Our vision is to create a future where the output flowing from funded research is easily and permanently discoverable, accessible and verifiable by anyone in the world.

CHORUS currently monitors over 400,000 articles for more than 20 US federal and two international funding agencies, and has partnerships with Department of Defense, Department of Energy, National Science Foundation, National Institute of Standards and Technology, Office of the Director National of Intelligence: Intelligence Advanced Research Projects Activity, Smithsonian Institution, US Department of Agriculture, US Geological Survey, Japan Science and Technology Agency, and the Australian Research Council. CHORUS is supported by over 50 publisher and affiliate members who represent the majority of funded published research.

What problem is your service trying to solve?

CHORUS is the first service of CHOR Inc., founded in 2013 in response to the directive of the US Office of Science and Technology Policy (OSTP) for all US federal research agencies to develop and implement plans to widen public access to publications and data associated with federally funded research.

CHORUS aims to minimize public access compliance burdens and ensure the long-term preservation and accessibility of articles reporting on funded research. We provide the necessary metadata infrastructure and governance to enable a smooth, low-friction interface between funders, authors, institutions and publishers in a distributed network environment. CHORUS’ services track public accessibility of articles regardless of whether they are published Gold OA or made open by the publisher.

Can you tell us how you are using the Crossref REST API at CHORUS?

The Crossref REST API is a key source for the metadata database that powers the CHORUS Dashboard, Search and Reporting services for Funders, Institutions and Publishers.

What metadata values do you pull from the API?

We pull the basic bibliographic information such as publisher, journal title, article title, authors and publication date. Perhaps even more important to our area of focus are the funder, grant and license information.

How often do you extract/query data?

CHORUS uses the Crossref REST API every day.

Can you describe your workflow using Crossref metadata?

Every night we query the Crossref API to send us metadata for all article or conference proceeding records for our member publishers that have funder metadata matching the funders monitored by CHORUS.

CHORUS monitors these DOIs for public accessibility on publisher websites; inclusion in agency search tools; deposit in a growing list of funder repositories (e.g.,US DOE PAGES,NSF PAR, and USGS Publications Warehouse and NIH PubMed Central); and for associated ORCID researcher records. CHORUS also uses the reuse license metadata to identify when an article is expected to be made publicly accessible.

Finally, we check for ingestion in CLOCKSS and/or Portico to ensure long-term preservation and accessibility of research findings reported in journal and proceedings articles. Our preservation partners keep the full text in their dark archives, only making it available when the content may no longer be made publicly accessible by the publisher.

The collected and enhanced metadata is presented in our dashboard, search and reporting services all including links back to the publisher sites via the Crossref DOI.

What are the future plans for CHORUS?

Following the success of our Funder and Publisher Dashboards, CHORUS is expanding the services we provide to international funders, non-governmental funders, and institutions. Our first funder partnership outside of the United States is with the Japan Science and Technology Agency (JST). CHORUS announced its new Institution Dashboard service this Autumn after successfully concluding pilots with the University of Florida and University of Denver. CHORUS will also be adding links to relevant datasets and other metadata utilizing forthcoming identifiers and metadata standards.

What else would you like to see the REST API offer

It would be great to see more identification of funders from Crossref members. While we have seen great leaps since 2013, we all have a long way to go. We are also eager to see Crossref incorporate the organisation Identifiers that they have begun with ORCID, DataCite and others.

Thanks, CHORUS! If you would like to contribute a case study on the uses of Crossref Metadata APIs please contact the Community team.

Changes to the 2018 membership agreement for better metadata distribution

Ginny Hendricks — Mon, 09 Oct 2017 00:00:00 +0000

We are making a change to section 9b of the standard Crossref membership agreement which will come into effect on January 1, 2018. This will not change how members register content, nor will it affect membership fees in any way. The new 2018 agreement is on our website, and the exact wording changes are highlighted below. The new membership agreement will automatically replace the previous version from January 1, 2018 and members will not need to sign a new agreement.

What’s changing?

At its July meeting the Crossref board unanimously approved recommendations from the Membership and Fees Committee to update Crossref’s metadata delivery offerings. One of the recommendations was to remove the option for case-by-case opt outs of metadata delivery through the OAI-PMH channel used for Enhanced Crossref Metadata Services.

This opt-out was only used by a small number of our members (around 40 of nearly 9,000), who have been contacted directly. This means that for the vast majority of members there is no change in how Crossref makes their metadata available but we wanted to make everyone aware of the change to the membership agreement.

So, as is currently the case, all metadata registered with Crossref is available via all the Metadata APIs under an appropriate agreement with the user or terms and conditions for the service. The one exception to this is how references are distributed - we will contact members next week about the options for references.

Why are we making this change?

Our metadata services have become very popular with users of all kinds throughout scholarly communications–including search and discovery platforms, libraries, other publishers, reference managers, sharing services, and analytics providers. More and better metadata means more and better discoverability of publisher content.
The change also brings this service into line with our mission to improve scholarly communications through quality metadata and related infrastructure services, removing the need for bilateral agreements between publishers and third parties.
Many members complained when we contacted them about opt-outs whenever a new OAI-PMH user came on board. It is better for our members and for our staff if there is a common standard across the board.

Changes to 2018 membership agreement

9) Sharing of Metadata by PILA

a) Local Hosting. [no change]

b) Other Metadata Services. Subject to compliance by the entity receiving the Metadata and Digital Identifiers with the terms and conditions ~~set forth in a separate agreement between~~ established by PILA for the particular service through which access is provided, and ~~the entity receiving the Metadata and Digital Identifiers~~, PILA may ~~license~~ authorize third parties to receive and use ~~bulk deliveries of~~ Metadata and Digital Identifiers from ~~the~~ PILA ~~System from members who have chosen to participate in Metadata Services,~~ which PILA shall provide directly to such third parties. At least thirty (30) days prior to making such Metadata delivery PILA will notify each PILA Member whose Metadata and Digital Identifiers are intended to be included in such delivery of the anticipated delivery date, the identity of the third party and the purpose for which the delivery is being made. Metadata and Digital Identifiers belonging to any PILA Member who notifies PILA in writing prior to the specified delivery date of its desire to be excluded from such delivery will be excluded or removed from such delivery.

Please contact our membership specialist if you have any feedback or questions.

Using the Crossref REST API. Part 6 (with NLS)

Christine Cormack Wood — Fri, 06 Oct 2017 00:00:00 +0000

Continuing our blog series highlighting the uses of Crossref metadata, we talked to Ulf Kronman, Bibliometric Analyst at the National Library of Sweden about the work they’re doing, and how they’re using our REST API as part of their workflow.

Introducing the National Library of Sweden (NLS)

The NLS is a state agency, has a staff of about 320, and its main offices in Stockholm. Its primary duty is to preserve the Swedish cultural heritage by collecting everything printed in Sweden, and has been doing so since 1661. Nowadays the library also collects Swedish TV and radio programs, movies, videos, music, and computer games.

The National Library coordinates services and programs for all publicly funded libraries in Sweden and runs the national library catalogue system Libris and the national database for Swedish scholarly output, SwePub. The library also runs the Bibsam consortium, negotiating national subscription licenses and open access publishing agreements with publishers.

Images left to right: External and internal view of the National Library of Sweden, and Ulf Kronman, Bibliometric Analyst at NLS.

What problem is your service trying to solve?

The metadata in the national scholarly publication database SwePub is harvested from the Swedish universities’ local publication systems, where data often is entered manually by librarians and researchers. This means that the metadata can contain a lot of omissions, synonyms, spelling variants and errors. Using Crossref, we can enhance and correct the metadata delivered to us, if we just have a correct DOI.

Can you tell us how you are using Crossref metadata at the National Library of Sweden?

The Crossref metadata is presently used in two projects; Open APC Sweden and in our local analysis database for publication statistics used in negotiations with publishers.

Open APC Sweden is a pilot project to gather data on open access publication costs (APC’s – Article Processing Charges) from Swedish universities. The project is modelled from the German Bielefeld University Open APC initiative, which is a part of the INTACT project. After APC data has been delivered to the APC system, scripts are run against the Crossref API to fetch information about publishers and journals. A description of Open APC Sweden can be found here.

When building our local analysis database for publisher statistics, we download data from the SwePub database, use the Crossref DOIs for API lookup against Crossref to add correct ISSN and publisher data to the records and then match the records against a list of publisher serials. In this way, we can get information about how much Swedish researchers have been publishing with a certain publisher and use this data when negotiating conditions for open access publishing with the publisher in question.

What metadata values do you pull from the API?

In Open APC Sweden, a Python script supplied by staff at the Bielefeld University is used to pull metadata about publisher and journal names and ISSN’s from the Crossref API. The result is entered into an enriched version of the APC data files delivered by the universities and then statistics can be calculated on the result using an R script. The result can be seen here.

In the local analysis database, a modified copy of the Bielefeld Python script is used to add the same metadata to the records before matching them against publisher serial ISSNs.

Have you built your own interface to extract this data?

In Open APC Sweden, the Python script is developed and maintained at the Bielefeld University and an exact copy is being run in the Swedish project.

In the local analysis system, the Python script is somewhat modified to suit the special demands of this system.

But sometimes it is very convenient just to use the main DOI lookup to do a manual check-up of problematic records.

How often do you extract/query data?

In Open APC Sweden, usually about two-three times a month, when new datasets are delivered from the universities. In the local analysis database, usually lookups are being done on a daily basis as development of the database continues.

What do you do with the metadata once it’s pulled from the API?

In Open APC Sweden, the metadata is going into the APC data files for processing of statistics. In the local analysis database, the metadata is used to match against publisher journal ISSN’s.

What plans do you have for the future?

For the Open APC Sweden I would like to build a database system to make the system more scalable than just working with flat data files.

With both the SwePub system and the local analysis system, we are now using the new service oaDOI and their API to look up metadata about the open access status of the publications to enrich our local systems.

What else would you like to see the REST API offer?

In the process of normalising the publishers’ names, the names returned are sometimes at a “too high” or on a too generic level to be used to generate good statistics. For instance, Springer Nature are sometimes returned as Springer Nature, sometimes as Springer Science + Business Media and sometimes as Nature Publishing Group. A similar thing is valid for Taylor & Francis, where the mother company Informa UK Limited is returned instead of the publishing subsidiary of the company. One thing to wish for here is that we could agree on some kind of normalisation of the publishers’ names and that Crossref could return this as a supplement to the present metadata.

Thanks Ulf! If you would like to contribute a case study on the uses of Crossref Metadata APIs please contact the Community team.

More metadata for machines-citations, relations, and preprints arrive in the REST API

Kirsty Meddings — Mon, 11 Sep 2017 00:00:00 +0000

Over the past few months we have been adding to the metadata and functionality of our REST API, Crossref’s public machine interface for the metadata of all 90 million+ registered content items. Much of the work focused on a review and upgrade of the API’s code and architecture in order to better support its rapidly growing usage. But we have also extended the types of metadata that the API can deliver.

One of the biggest changes is that references are now available if the publisher has made them public (a simple email instruction to us). Currently 45% of all publications with deposited references are now accessible. For example:

This article studying fluid ejection from animals has 55 references and they are all in the metadata here. You can also see that the article has an is-referenced-by count of 6.
This article exploring whether people bitten by their cat are more likely to develop depression has 142 references and is referenced by 12.

We recently announced that we would be accepting preprints, and the metadata for 15,000 preprints registered to date is now in the API, labelled as posted-content. Over 4,000 have been subsequently published in a journal, and the Crossref metadata now links these preprints to their respective articles (and vice versa). For example this article in Biorxiv has since been published in a journal, and this relationship is recorded in its metadata as is-preprint-of.

Also new to the API:

Cited-by counts - the number of times each work has been referenced by other content registered with us. Look for is-referenced-by-count within a record.
This article from 1953 about a fairly notable discovery has been cited 4832 times, but the two most cited articles both have over 100,000 citations and thousands have been cited more than Watson and Crick.
Abstracts for over 1 million works.
Similarity Check URLs–the ones that Turnitin crawl to add content to the database–are now showing so that participating publishers can check that they are including them in their metadata deposits.
Subject categories have been added for an additional 7000 journal titles, taking the total number of classified titles to ~45,000.

Are you already using our Metadata APIs for your system or project? We’re always keen to hear new use cases and happy to answer any questions.

You may need to install a JSON viewer extension in your browser to render API queries in a human-friendly way.

Using the Crossref REST API. Part 5 (with OpenCitations)

Christine Cormack Wood — Sun, 10 Sep 2017 00:00:00 +0000

As part of our blog post series on the Crossref REST API, we talked to Silvio Peroni and David Shotton of OpenCitations (OC) about the work they’re doing, and how they’re using the Crossref REST API as part of their workflow.

Introducing OpenCitations

OpenCitations employs Semantic Web technologies to create an open repository of the citation data that publishers have made available. This repository, called the OpenCitations Corpus (OCC), contains RDF-based scholarly citation data that are made freely available so that others may use and build upon them. All the resources published by OC – namely the data within the OCC, the ontologies describing the data, and the software developed to build the OCC – are available to the public with open licenses.

What problem is your service trying to solve?

OC was started to address the lack of RDF-based open citation data. To our knowledge, when the project formally started with Jisc funding in 2010 the prototype OCC was the first RDF-based dataset of open citation data.

We collect accurate scholarly citation data derived from bibliographic references harvested from the scholarly literature, so as to make them available under a Creative Commons public domain dedication (CC0) by means of Semantic Web technologies, thus making them findable, accessible, interoperable, and re-usable, as well as structured, separable, and open.

OCC citation data are described using standard and/or well-known vocabularies, including the SPAR Ontologies , PROV-O, the Data Catalog Vocabulary, and VoID. The use of such vocabulary is described in the OCC metadata document, and is implemented by means of the OpenCitations Ontology (OCO).

The OCC resources are made available and accessible in different ways, so as to facilitate their reuse in different contexts: as monthly dumps, via the SPARQL endpoint, and by accessing them directly by means of the HTTP URIs of the stored resources (via content negotiation; example)

Can you tell us how you are using the Crossref Metadata API at OpenCitations?

At present, basic citation information is retrieved from PubMed Central, and the Crossref API is then used to retrieve additional metadata describing the citing and cited articles, and to disambiguate bibliographic resources and agents by means of the identifiers retrieved (e.g., DOI, ISSN, ISBN, URL, and Crossref member URL). In future, we will retrieve full citation data direct from Crossref.

What metadata values do you pull from the API?

We pull the titles, subtitles, identifiers (e.g. DOI, ISSN, ISBN, URL, and Crossref member URL), author list, publisher, container resources (issue, volume, journal, book, etc.), publication year and pages.

Have you built your own interface to extract this data?

The SPAR Citation Indexer, a.k.a. SPACIN, is a script and a series of Python classes that allow one to process particular JSON files containing the bibliographic reference lists of papers, produced from the PubMed Central API by another script included in the OpenCitations GitHub repository.

SPACIN processes such JSON files and retrieves additional metadata information about all the citing and cited articles by querying the Crossref API, among others. Once SPACIN has retrieved all these metadata, RDF resources are created (or reused, if they have been already added in the past) and stored in the file system in JSON-LD format. In addition, they are also uploaded to the OCC triplestore (via the SPARQL UPDATE protocol).

How often do you extract/query data?

The entire OpenCitations ingestion workflow is running continuously, processing about half a million citations per month.

What do you do with the metadata once it’s pulled from the API?

All the metadata relevant to bibliographic entities are stored by using the OCC metadata model. The ontological terms of such metadata model are collected within an ontology called the OpenCitations Ontology (OCO), which includes several terms from the SPAR Ontologies and other vocabularies. In particular, the following six bibliographic entity types occur in the datasets created by SPACIN:

bibliographic resources (br), class fabio:Expression – resources that either cite or are cited by other bibliographic resources (e.g. journal articles), or that contain such citing/cited resources (e.g. journals);
resource embodiments (re), class fabio:Manifestation – details of the physical or digital forms in which the bibliographic resources are made available by their publishers;
bibliographic entries (be), class biro:BibliographicReference – literal textual bibliographic entries occurring in the reference lists of bibliographic resources;
responsible agents (ra), class foaf:Agent – names of agents having certain roles with respect to the bibliographic resources (i.e. names of authors, editors, publishers, etc.);
agent roles (ar), class pro:RoleInTime – roles held by agents with respect to the bibliographic resources (e.g. author, editor, publisher);
identifiers (id), class datacite:Identifier – external identifiers (e.g. DOI, ORCID, PubMedID) associated to bibliographic resources and agents.

Do you have plans to enhance your metadata input?

We already handle additional information, such as ORCIDs, that are extracted by means of the ORCID API applied to the citing and cited articles included in the OCC. In addition, we are developing scripts in order to use all the new citation data Crossref now makes available as consequence of the Initiative for Open Citations (I4OC).

What are the future plans for OpenCitations?

With funding received from the Alfred P. Sloan Foundation, we will shortly extend the current infrastructure and the rate of data ingest. Our immediate goal is to increment the daily ingestion of citation data from about half a million citations per month to about half a million citations per day. In addition, we plan to analyse the OCC so as to understand the quality of its current data, and to develop new user interfaces, including graph visualizations of citation networks, that will expand the means whereby users can interact with the OpenCitations data.

What else would you like to see our REST API offer?

Categorising articles/journals/any bibliographic resources according to their main discipline (Computer Science, Biology, etc.) and, eventually, by means of subject terms and/or keywords. Additionally, provision of authors’ institutional affiliations and funder information would be extremely valuable.

Thank you Silvio and David!

If you are keen to share what you’re doing with the our Metadata APIs, contact feedback@crossref.org and share your story.

Using the Crossref REST API. Part 4 (with CLA)

Rachael Lammey — Tue, 25 Jul 2017 00:00:00 +0000

As a follow-up to our blog posts on the Crossref REST API we talked to the Copyright Licensing Agency (CLA) about the work they’re doing, and how they’re using the Crossref REST API as part of their workflow.

Alex Cole, Senior Business Analyst at the Copyright Licensing Agency introduces the DCS

The Digital Content Store (DCS) is an innovative rights, technology and content platform for UK Higher Education Institutions (HEIs), which was developed collaboratively with HEIs, publishers and technology partners. The platform is included in the CLA annual licence fee and is an optional tool for licensees.

At its core, the system is a searchable repository of digital copies that have been created under the licence by HEIs (the CLA Digital Content Store), it also functions as a workflow management tool. When extracts are digitised by HEIs under the CLA Licence, they are uploaded directly to the DCS. Once an extract is uploaded and assigned to a course, students are able to access the extract via a secure link. Every year HEIs are obliged to report all of these digitised items to CLA as part of the terms of their copyright blanket licence. Prior to the DCS, HEIs were having to submit this data manually, a process that could take days, if not weeks. The system removes the need for annual census reporting to CLA, reducing the data collection burden on the HE sector and creating administrative efficiencies through streamlining the digital course pack creation process.

Can you talk about how you’re using the Crossref REST API within CLA Digital Content Store (DCS)?

When a DCS user adds a new extract to a course they need to include relevant metadata. This metadata is necessary, as it ultimately helps CLA in correctly identifying the copyright owner of the extract so that we can make sure they receive fair payment in our royalties distributions. The Crossref REST API supplies the DCS user with article and journal metadata so that they can provide the correct information about the content they are uploading. Using the API saves the user the time they would have otherwise spent searching for this data, streamlining their workflow and making the process more efficient.

Searching for and adding content in the DCS

What are your future development plans?

We’re continuing to develop the DCS in order to improve user experience for our customers. We’re currently looking into opening up access for our users by allowing academics to submit requests to the DCS via a web-form and our own DCS Course Content URL API. We are also looking into incorporating the Crossref REST API into some of our back office workflows to improve efficiency and simplify our workflow. The metadata that we can retrieve from Crossref can help us match customer usage to our rights database.

What else would you like to see in Crossref metadata?

Going forward we’d like to see:

More books included in the database.
Indicating if an ISSN is associated with the print or digital edition of a journal.

Thanks Alex!

How do you deposit data citations?

Jennifer Lin — Thu, 02 Mar 2017 00:00:00 +0000

Please visit Crossref’s official Data & Software Citations Deposit Guide for deposit details.

Very carefully, one at a time? However you wish.

Last year, we introduced linking publication metadata to associated data and software when registering publisher content with Crossref Linking Publications to Data and Software. This blog post follows the “whats” and “whys” with the all-important “how(s)” for depositing data and software citations. We have made the process simple and fairly straightforward: publishers deposit data & software links by adding them directly into the standard metadata deposit via relation type and/or references. This is part of the **existing Content Registration ** process and requires no new workflows.

Relationships

Data & software citations are a valuable part of the “research article nexus”, comprised of the publication linked to a variety of associated research objects, including data and software, supporting information, protocols, videos, published peer reviews, a preprint, conference papers, etc. For all of these resources, we use relation types in the metadata deposit to “anchor” the article in the article nexus and link to it.

For data & software, we ask for:

identifier of the dataset/software
identifier type: “DOI”, “Accession”, “PURL”, “ARK”, “URI”, “Other” *
relationship type: “isSupplementedBy” or “references”
description of dataset or software.
*Additional identifier types beyond those used for data or software are also accepted, including ARXIV, ECLI, Handle, ISSN, ISBN, PMID, PMCID, and UUID.

Crossref maintains an expansive set of relationship types to support the various resources linked in the research article nexus. For data and software, we recommend “isSupplementedBy” and “references” as relationship types in the metadata. Use the former if it was generated de novo as part of the research results. For those generated by another project and then reused, we recommend applying “references” in the relationship type. These were selected in consultation with DataCite and data working groups. They will provide the level of specificity requested by the community.

To illustrate how to represent the link within the metadata deposit, we offer two examples from two popular dataset identifiers, one for each of the relationship types.

Dataset	Snippet of deposit XML containing link
Dataset with DOI: Data from: Extreme genetic structure in a social bird species despite high dispersal capacity. Database: Dryad Digital Repository DOI: https://doi-org.pluma.sjfc.edu/10.5061/dryad.684v0	`<program xmlns="http://www.crossref.org.pluma.sjfc.edu/relations.xsd">` `<related_item>` `<description>Data from: Extreme genetic structure in a social bird species despite high dispersal capacity</description>` `<inter_work_relation relationship-type="isSupplementedBy" identifier-type="doi">10.5061/dryad.684v0</inter_work_relation>` `</related_item>` `</program>`
Dataset with accession number: NKX2-5 mutations causative for congenital heart disease retain functionality and are directed to hundreds of targets Database: Gene Expression Omnibus (GEO) Accession number: GSE44902 URL: https://www-ncbi-nlm-nih-gov.pluma.sjfc.edu/geo/query/acc.cgi?acc=GSE44902	`<program xmlns="http://www.crossref.org.pluma.sjfc.edu/relations.xsd">` `<related_item>` `<description>NKX2-5 mutations causative for congenital heart disease retain and are directed to hundreds of targets</description>` `<inter_work_relation relationship-type="references" identifier-type="Accession">GSE44902</inter_work_relation>` `</related_item>` `</program>`

In the examples above, the Dryad dataset was generated as part of the research published in an article. Hence, it contains the “isSupplementedBy” relationship type. The GEO dataset was reused by and referenced in a scholarly article published separate from the project that generated this dataset. Hence, it contains the “references” relationship type.

Both Crossref and DataCite employ this method of linking. Data repositories who register their content with DataCite follow the same process and apply the same metadata tags. This means that we achieve direct data interoperability with links in the reverse direction (data and software repositories to journal articles).

References

Another mechanism for depositing data and software citations is to insert it into the manuscript’s references. Publishers then deposit it as part of the article’s references. To do so, publishers follow the general process for depositing references. (Visit Crossref’s Support page for step-by-step instructions.)

Publishers can deposit the full data or software citation as a unstructured reference.
<citation key="ref=3">
<unstructured_citation>Morinha F, Dávila JA, Estela B, Cabral JA, Frías Ó, González JL, Travassos P, Carvalho D, Milá B, Blanco G (2017) Data from: Extreme genetic structure in a social bird species despite high dispersal capacity. Dryad Digital Repository. http://dx.doi.org.pluma.sjfc.edu/10.5061/dryad.684v0</unstructured_citation\>
</citation>
</citation_list>

Or they can employ any number of reference tags currently accepted by Crossref. Most do not readily suit datasets and software as the suite was originally established to match article and book references. This leaves out substantial metadata needed to identify and describe the dataset, however, if the resource does not have a DOI.
<citation key="ref2">
<doi>10.5061/dryad.684v0</doi>
<cYear>2017</cYear>
<author>Morinha F, Dávila JA, Estela B, Cabral JA, Frías Ó, González JL, Travassos P, Carvalho D, Milá B, Blanco G</author>
</citation>
We are exploring the JATS4R recommendations while we consider expanding the current collection. We welcome additional suggestions from the community.

Precise, accessible links

Crossref’s infrastructure is setup to facilitate the flow of information about scholarly works across the research network. We maintain a fair degree of flexibility both in the structure and completeness of metadata deposited. The aim, though, is to make the links rich in metadata, accurate in associating literature to corresponding resource, and available to both human and machine consumers as per Principle #5 and #7 in the Joint Declaration of Data Citation Principles.

As with the other associated resources in the article nexus, we recommend depositing data/software links in the publication metadata via relationships. Publishers are free to do this on top of or independent of references. Relationship metadata offer a high degree of precision. References are a hodgepodge of various resources cited by the publication, including articles, books, media, blogs, reference materials, etc. and data citations are hard to isolate. Furthermore, the unstructured, “spaghetti string” text is difficult for systems to parse and extract specific information.

With relationship metadata, data and software resources are expressly designated. We obtain a more accurate link that specifies identifier type and explicitly identifies data generated as part of the research shared in the paper or as reuse of existing data). The richer metadata contained here enables consumers to conduct powerful queries based on different attributes (identifier type, description, relationship), taking data discovery and mining to the next level.

Furthermore, relationships are important for achieving full accessibility of data and software citations. Access to references is based on publisher permission so not all data citations can be shared (excluding DataCite DOIs). In contrast, all links deposited via relationships are publicly available.

Publishers play an important role in supporting research validation and reproducibility. Data & software citation is a basic part of of this practice, and instrumental in enabling the reuse and verification of these research outputs, tracking their impact, and creating a scholarly structure that recognizes and rewards those involved in producing them. For the full scoop of how to deposit (i.e., technical details and more), we encourage you to reference the Crossref Data & Software Citations Deposit Guide and contact us (support@crossref.org) with questions or feedback.

Included, registered, available: let the preprint linking commence.

Rachael Lammey — Mon, 05 Dec 2016 00:00:00 +0000

We began accepting preprints as a new record type last month (in a category known as “posted content” in our XML schema). Over 1,000 records have already been registered in the first few weeks since we launched the service.

By extending our existing services to preprints, 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
the citation record is clear and up-to-date.

It’s not just collecting the metadata however, it’s also making it available so that it can be as widely used as possible. Preprint metadata is no different. As with all record types, we make the metadata available for machine and human access, across multiple interfaces (e.g. REST API, OAI-PMH, Crossref Metadata Search)

For example, you can see information on the preprint https://doi-org.pluma.sjfc.edu/10.20944/preprints201608.0191.v1 in a number of ways:

If you want to see all the preprint metadata deposited so far, try https://api-crossref-org.pluma.sjfc.edu/v1/types/posted-content/works. Over 1,000 records have already been registered in the first few weeks since we launched the service.

Crossref members depositing preprints need to make sure they:

Register content using the posted content metadata schema.
Respond to our match notifications that a manuscript / version of record (AM/VOR) has been registered and link to that within seven days.
Label the manuscript as a preprint clearly, above the scroll on the preprint landing page, and ensure that any link to the AM/VOR is also prominently displayed above the scroll.

It’s important to clearly label the record type so we can ensure that the connections between preprints and the associated literature are clearly visible, to both humans and machines.

As with other record types, there is a registration fee to include content in the Crossref system. For preprints, it’s $0.25 fee for current preprint files and $0.15 for back-year records.

Are you an existing Crossref member who wants to assign preprint DOIs? Let’s talk about getting started or migrating any existing content over to the dedicated preprint deposit schema.

Interested in becoming a Crossref member to assign DOIs to your preprints? Contact our membership specialist so we can answer any questions and get you set up as a member.

Using the Crossref REST API. Part 3 (with SHARE)

Rachael Lammey — Thu, 01 Dec 2016 00:00:00 +0000

As a follow-up to our blog posts on the Crossref REST API we talked to SHARE about the work they’re doing, and how they’re employing the Crossref metadata as a piece of the puzzle. Cynthia Hudson-Vitale from SHARE explains in more detail…

Cynthia Hudson-Vitale, digital data librarian in Research Data and GIS Services at Washington University in St. Louis Libraries and visiting program office for SHARE

SHARE (http://share-research.org) is building a free, open, data set about research and scholarly activities across their life cycle. It is a higher education initiative whose mission is to maximize research impact by making research widely accessible, discoverable, and reusable. SHARE’s data set is free, openly licensed, and built with open source technology developed at the Center for Open Science (COS). Launched in beta in April 2015 the data set has grown to more than 6 million records from 100+ providers, including Crossref, Social Science Research Network (SSRN), DataONE, 50+ library institutional repositories, and more.

How is the Crossref REST API used within SHARE?

SHARE currently harvests metadata from Crossref using the Crossref application programming interface (API). We pull such metadata values as journal title, author, DOI, journal name, and publisher, to name just a few. This metadata is then fed into our data processing pipeline, normalized, and aggregated into the full data set.

What are the future plans for SHARE?

Phase II of SHARE, launched in late 2015, focuses on adding metadata providers, enhancing the metadata, and making connections and links between the metadata records. These links will show the entire life cycle of research and scholarship—connecting a data management plan, grant award information, data deposits, analytic/software code, pre-publications, final manuscripts, and more.

To move these plans forward, SHARE is applying machine-learning and automation techniques and working with the community to verify metadata enhancements and curate the metadata. Current technology work focuses on imputing subject domain keywords and object types into the SHARE data set using learning models and heuristics. Data models and schemas are in development to connect the research lifecycle, connect multiple instances of an object to a single entity, and capture metadata provenance.

What else would SHARE like to see in Crossref metadata?

We would love to see rights-declaration metadata elements and article references/citations included in the metadata about digital objects. The rights-declaration information is invaluable for individuals who want to know what category the object is in (public domain, copyrighted, etc.), what constraints or permission requirements exist, contact information, and more. Additionally, networks of research can be discovered and meta-scholarship facilitated by making article reference lists machine-readable and openly available.

What’s next?

Does this give you any ideas? Feel free to get in touch with questions or take the API for a spin yourself and let us know what you can do with it!

Using the Crossref Metadata API. Part 2 (with PaperHive)

Rachael Lammey — Thu, 08 Sep 2016 00:00:00 +0000

We first met the team from PaperHive at SSP in June, pointed them in the direction of the Crossref Metadata API and let things progress from there. That’s the nice thing about having an API - because it’s a common and easy way for developers to access and use metadata, it makes it possible to use with lots of diverse systems and services.

So how are things going? Alexander Naydenov, PaperHive’s Co-founder gives us an update on how they’re working with the Crossref metadata:

PaperHive

PaperHive is a web-platform for collaborative reading and a cross-publisher layer of interaction on top of research documents. It lets researchers communicate in published documents in a productive and time-saving way. PaperHive thus puts academic literature, which is integrated with the platform, in the limelight and increases content usage and reader engagement.

Transforming reading into a process of collaboration gives researchers a reason to return to the content and discover new enrichments they can benefit from. Functionality like hiving, deep linking, and the PaperHive browser extension embeds communication in the researcher’s workflow. PaperHive is free to use!

How is the Crossref API used within PaperHive?

PaperHive extends the concept of a living document and offers an innovative way of displaying content without hosting it. Instead, academic documents are dynamically pulled from the publisher’s servers thus ensuring compliance with content licensing. It enables readers to stay in touch with the articles of interest beyond just saving them in an offline folder.

Crossref is the common ground on which third party companies and initiatives can build valuable services for publishers and researchers. It facilitates the integration of content into PaperHive by providing the metadata of articles and books from numerous publishers independent of the technology behind their content platforms. Moreover, if the publishers provide ORCID identifiers of authors in the Crossref metadata, researchers can immediately interact with the readers of their works.

What are the future plans for PaperHive?

In addition to integrating further publishers’ content and extending PaperHive’s feature set for readers, we also plan to extend our partnerships with other technology providers.

As far as our cooperation with Crossref is concerned, we are looking forward to the implementation of the Crossref Event Data API.

What else would you like to see in Crossref metadata?

- The quality of the existing metadata should be improved significantly. We noticed that important fields such as author or title are missing in the metadata of many documents. PaperHive ignores articles and books with incomplete metadata because it impairs the user experience. Publishers, authors and readers can only benefit from the wider and more active usage of content, so we hope that more publishers will improve the data their provide Crossref with.

- Since researchers are working with full texts on PaperHive, it would be great if links to the full text are provided in the metadata of all articles and books. The metadata should also contain information about the format of the full text (e.g., PDF, EPUB, HTML).

Thanks Alex!

Just getting started with the API or what to know more? Get in touch via feedback@crossref.org and pass on your questions and comments.

Linking Publications to Data and Software

Jennifer Lin — Wed, 07 Sep 2016 00:00:00 +0000

TL;DR

Crossref and Datacite provide a service to link publications and data. The easiest way for Crossref members to participate in this is to cite data using DataCite DOIs and to include them in the references within the metadata deposit. These data citations are automatically detected. Alternatively and/or additionally, Crossref members can deposit data citations (regardless of identifier) as a relation type in the metadata. Data & software citations from both methods are freely propagated. This blog post also describes how to retrieve the links collected between publication and data & software.

Data & software citation is good research practice (DataCite-STM Joint Statement and FORCE11 Joint Declaration of Data Citation Principles) and is part of the scholarly ecosystem supporting research validation and reproducibility. Data & software citation is also instrumental in enabling the reuse and verification of these research outputs, tracking their impact, and creating a scholarly structure that recognises and rewards those involved in producing them.

Crossref supports the propagation of data & software citations alongside a publisher’s standard bibliographic metadata. members deposit the data citation link as part of the overall publication metadata when registering their content. Crossref partners with DataCite and together, we jointly provide a clearinghouse for the citations collected. These are all made freely available to the community as open data.

Citation practices are evolving across different communities of practice. Crossref’s offering is flexible and easily accommodates variations and changes, since it does not rely on a specific set of citation metadata elements, citation format, nor manner of credit and attribution. Publishers deposit data & software citations in their metadata deposit via a) references and/or b) relation type.

Method A: Bibliographic references

Crossref and DataCite have partnered to provide automatic linking between publications registered with Crossref and datasets bearing DataCite DOIs. This is the most efficient and effective way to ensure that data citations are fully integrated into the scholarly research information network with full and accurate metadata.

All data & software citations that include datasets bearing a DataCite DOI are eligible for auto-update linking with Crossref. In this method: authors cite the dataset or software containing the DataCite DOI per journal article submission guidelines and add it to the article citation list (c.f. FORCE11 citation placement, FORCE11 Software Citation Principles). Publishers then deposit references as part of their standard practice when registering content. Crossref checks every reference deposited for a DOI. If the DOI is identified as DataCite’s, we automatically link it to the article. With this method, no additional action is needed when publishers register their content with Crossref.

Data citation links to non-DataCite DOIs can only be exposed in the references if the publisher makes references openly available. Even in the event that the data citation is shared, it remains undifferentiated from other references. Method B described below offers another approach.

Method B: Relation type

Publishers can link their publication to a variety of associated research objects as part of the article metadata directly in the metadata deposited to Crossref, including data & software, protocols, videos, published peer reviews, preprints, conference papers, etc. Doing so not only groups digital objects together, but formally associates them with the publication. Each link is a relationship and the sum of all these relationships constitutes a ‘research article nexus.’ Data & software citations are a valuable part of this.

To tag the citation in the metadata deposit, we ask for:

description of dataset or software (optional)

dataset or software identifier

identifier type

relationship type.

Crossref can accommodate research outputs with any identifier, though we currently only validate DOI relationships during metadata processing. Technical details are documented in the [Data & Software Citations Deposit Guide][4].

Combining methods increases total available citations

The two methods are independent and can be used exclusively or jointly. Each caters to a different set of conditions and their practical considerations. See the comparison of benefits and limitations for each method in the deposit guide. We recommend that publishers use both methods where possible at this time for optimum specificity and coverage.

How to access data & software citations

Crossref and DataCite make the data & software citations deposited by Crossref members and DataCite data repositories openly available to a wide host of parties, including both Crossref and DataCite communities as well as the extended research ecosystem (funders, research organisations, technology and service providers, research data frameworks such as Scholix, etc.).

Data & software citations from references can be accessed via the Crossref Event Data API Citations included directly into the metadata by relation type can be accessed via Crossref’s APIs in a number of formats (REST, OAI-PMH, OpenURL). (A single channel containing data & software citations across interfaces is in development and will be released next year.)

Publishers, visit our detailed guide on how to deposit data and software citations. We welcome your questions and concerns at feedback@crossref.org.

Special thanks to the following who provided valuable feedback in developing the guide: Martin Fenner (DataCite), Amye Kenall (Springer Nature), Brooks Hanson (AGU), Shelley Stall (AGU), and the FORCE11 Data Citation Implementation Pilot publisher’s subgroup.

Using the Crossref Metadata API. Part 1 (with Authorea)

Rachael Lammey — Thu, 18 Aug 2016 00:00:00 +0000

Did you know that we have a shiny, not so new, API kicking around? If you missed Geoffrey’s post in 2014 (or don’t want a Cyndi Lauper song stuck in your head all day), the short explanation is that the Crossref Metadata API exposes the information that publishers provide Crossref when they register their content with us. And it’s not just the bibliographic metadata either-funding and licensing information, full-text links (useful for text-mining), ORCID iDs and update information (via Crossmark)-are all available, if included in the publishers’ metadata.

Interested? This is the kickoff a series of case studies on the innovative and interesting things people are doing with the Metadata API. Welcome to Part 1.

What can you do with the Metadata API?

Build search interfaces. We’ve built some ourselves. Check out Crossref Metadata Search to search the metadata of over 80 million journal articles, books, standards, datasets & more. Or Crossref Funder Search to search nearly 15,000 funders and the 982,162 records we have that contain funding data.

Provide cross-publisher support for text and data mining applications.

Get really interesting top-level reports on the metadata Crossref holds - or look at subsets of the information you’re interested in.

Third parties are free to build their own products and tools that build off of the Metadata API (below are some of the many examples that we will highlight in this series).

Importantly, there’s no sign-up required to use the Metadata API - the data are facts from members, therefore not subject to copyright and free to use for whatever purpose anyone chooses.

To help, Scott Chamberlain of rOpenSci has built a set of robust libraries for accessing the Metadata API. These libraries are now available in the R, Python and Ruby languages. Scott’s blog post has some great information on those. For those using the libraries, there have been a few updates since Scott’s post - to serrano, and support for field queries has been added to habanero (coming to serrano and rCrossref soon). Any feedback/bug reports can be submitted via the GitHub repos serrano or habanero. There’s also a javascript library, authored by Robin Berjon.

Who’s using the Crossref Metadata API?

We get around 30 million requests a month. We’d like to share a few case studies to showcase what they’re doing and how they’re using it. Look out for a series of posts over the next few months where we’ll open the floor to those using the API and let them explain how and why.

We’ll let Authorea kick things off…

Alberto Pepe, co-founder of Authorea explains:

Authorea is a word processor for researchers and scholars. It is a collaboration platform to write, share and openly research in real-time: write manuscripts and include rich media, such as data sets, software, source code and videos. The media-rich, data-driven capabilities of Authorea make it the perfect platform to create and disseminate a new generation of research articles, which are natively web-based, open, and reproducible. Authorea is free to use.

How is the Crossref Metadata API used within Authorea?

Authorea is specifically made for scholarly documents such as research articles, conference papers, grey literature, class notes, student papers, and problem sets. What makes scholarly documents so peculiar are their citations and references, mathematical notation, tables, and data. For citations and references, we built a citation tool which allows authors to search and cite scholarly papers with ease, without having to leave the editor. While in the middle of writing a sentence, authors can click the “cite” button and a citation tool opens up:

We currently use two engines for searching scholarly literature via their APIs: Crossref and Pubmed. Our authors love being able to search (by author name, paper title, topic, etc) and add references to their papers on the fly, in one click.

What are the future plans for Authorea?

Among the many plans we have for the future, there is one which is also tied to Crossref: we are going to let authors assign DOIs to Authorea articles such as blog posts, preprints, “data papers”, “software papers” and other kinds of grey literature which does not fit in the traditional scholarly journals.

What else would you like to see in our metadata?

Well, since you ask: we would love to see unique BibTex IDs being served by the Metadata API (right now, you create the ID automatically using author name and year). Also, in some cases, some important metadata fields are missing (even author or title). I think it is actually more important to fix existing metadata rather than add new fields!

Keen to share what you’re doing with the Crossref Metadata API? Contact feedback@crossref.org and share your story.

Distributing references via Crossref

Geoffrey Bilder — Fri, 17 Jun 2016 00:00:00 +0000

Known unknowns

If you follow this blog, you are going to notice a theme over the coming months- Crossref supports the deposit and distribution of a lot more kinds of metadata than people usually realise.

We are in the process of completely revamping our web site, help documentation, and marketing to better promote our metadata distribution capabilities, but in the mean time we think it would be useful highlight one of our most under-promoted functions- the ability to distribute references via Crossref.

One of the questions we most often get from members is- “can we distribute references via Crossref?” The answer is an emphatic yes. But to do so, you have to take an extra and hitherto obscure step to enable reference distribution. [EDIT 6th June 2022 - all references are now open by default with the March 2022 board vote to remove any restrictions on reference distribution].

How?

Many members deposit references to Crossref as part of their participation in Crossref’s Cited-by service. However - for historical reasons too tedious to go into - participation in Cited-by does not automatically make references available via Crossref’s standard APIs. In order for publishers to distribute references along with standard bibliographic metadata, publishers need to either:

Contact Crossref support and ask them to turn on reference distribution for all of the prefixes they manage.
Set the reference_distribution_opt element to any for each content item registered where they want to make references openly available.

Either of these steps will allow references for the affected member DOIs to be distributed without restriction through all of Crossrefs APIs and bulk metadata dumps.

Note that by doing this, you are not enabling the open querying of your Cited-by data- you are simply allowing the references that you already deposit to be redistributed to interested parties via our public APIs.

Who?

So who does this now? Well, at the moment not many members have enabled this feature. How could they? They probably didn’t know it existed. At the time of writing this 29 publishers have enabled reference distribution for at least some of their DOIs.

But that’s why we are writing this post. Given the interest expressed by our members, we expect the list to start growing quickly over the next few months. Particularly now that they know they can do it and have clear instructions on how to do it. 🙂

If you are of a geeky persuasion and want to see the list of publishers who are doing this, you can check via our API.

The following query will just show you the total number of members who are distributing references for at least some of their DOIs.

https://api-crossref-org.pluma.sjfc.edu/v1/members?filter=has-public-references:true&rows=0

And this query will allow you to page through the member records and see who is distributing references.

https://api-crossref-org.pluma.sjfc.edu/v1/members?filter=has-public-references:true

That cool, but can you see how many total DOIs have reference distribution enabled? No, but will will be adding that capability to our API soon.

OMG! OMG! OMG! Does this mean I can get references from api.crossref.org?

Yep. But before you get too excited- note above that not many of our members are doing this yet and that our API is still being updated to allow you to better query this information. At the moment references are not included in our JSON representation- they are only included in our XML representation. You can get the XML for a Crossref DOI either through content negotiation, or by using the following incantation on our API (using an eLife DOI as an example):

~~https://api-crossref-org.pluma.sjfc.edu/v1/works/10.7554/eLife.10288.xml~~

~~As we update our API to better support querying DOIs that include references, you will see the new functionality reflected in our documentation at:~~

Yes. 🤗. See the API docs below.

https://api-crossref-org.pluma.sjfc.edu

Python and Ruby Libraries for accessing the Crossref API

Scott Chamberlain — Fri, 04 Mar 2016 00:00:00 +0000

I’m a co-founder with rOpenSci, a non-profit that focuses on making software to facilitate reproducible and open science. Back in 2013 we started to make an R client working with various Crossref web services. I was lucky enough to attend last year’s Crossref annual meeting in Boston, and gave one talk on details of the programmatic clients, and another higher level talk on text mining and use of metadata for research.

Crossref has a newish API encompassing works, journals, members, funders and more (check out the API docs), as well as a few other services. Essential to making the Crossref APIs easily accessible—and facilitating easy tool/app creation and exploration—are programmatic clients for popular languages. I’ve maintained an R client for a while now, and have been working on Python and Ruby clients for the past four months or so.

The R client falls squarely into the analytics/research use cases, while the Python and Ruby clients are ideal for general data access and use in web applications (the Javascript library below as well).

I’ve strived to make each client in idiomatic fashion according to the language. Due to this fact, there is not generally correspondence between the different clients with respect to data outputs. However, I’ve tried to make method names similar across Ruby and Python; although the R client is quite a bit older, so method names differ from the other clients and I’m resistant to changing them so as not to break current users’ projects. In addition, R users are likely to want a data.frame (i.e., table) of results, so we give back that - whereas with Python and Ruby we give back dictionaries and hashes, respectively.

Crossref clients

Python:
- Source: https://github.com/sckott/habanero
- Pypi: https://pypi.python.org/pypi/habanero
Ruby:
- Source: https://github.com/sckott/serrano
- Rubygems: https://rubygems.org/gems/serrano
- serrano also comes with a command line tool of the same name that’s installed when you install serrano (examples below)
R:
- Source: https://github.com/ropensci/rcrossref
- CRAN: https://cran.rstudio.com/web/packages/rcrossref/
Javascript:
- Source: https://github.com/scienceai/crossref
- NPM: https://www.npmjs.com/package/crossref

I’ll cover the Python, Ruby, and R libraries below.

Installation

Python

on the command line

pip install habanero

Ruby

on the command line

gem install serrano

in an R session

install.packages("rcrossref")

Examples

Output is indicated by the syntax #> in all examples below.

Python

in a Python REPL (e.g. iPython)

Import the Crossref module from within habanero, and initialize a client

from habanero import Crossref
cr = Crossref()

Query for the phrase “ecology”

x = cr.works(query = "ecology", limit = 5)

Index to various parts of the output

x['message']['total-results']
#> 276188

Extract similar data items from each result. The records are in the “items” slot

[ z['DOI'] for z in x['message']['items'] ]
#> [u'10.1002/(issn)1939-9170',
#> u'10.4996/fireecology',
#> u'10.5402/ecology',
#> u'10.1155/8641',
#> u'10.1111/(issn)1439-0485']

In habanero for some methods we require you to instantiate a client.

You can set a base URL and API key. This is a future looking feature

as Crossref API does not require an API key.

Note: I’ve tried to make sure habanero is Python 2 and 3 compatible. Hopefully you’ll find that’s true.

Ruby

in a Ruby repl (e.g., pry), load serrano

require 'serrano'

Query for “peerj” on the journals route

x = Serrano.journals(query: "peerj")

Collect just ISSN’s from each result

x['message']['items'].collect { |z| z['ISSN'] }
#> => [["2376-5992"], ["2167-8359"]]

Shell

The serrano command line tool is quite powerful if you are used to doing things there.

Here, search for one article; summary data is shown.

serrano works 10.1371/journal.pone.0033693
#> DOI: 10.1371/journal.pone.0033693
#> type: journal-article
#> title: Methylphenidate Exposure Induces Dopamine Neuron Loss and Activation of Microglia in the Basal Ganglia of Mice

There’s also a -json flag to give back JSON data, which can be parsed with the command line tool jq.

serrano works --filter=has_full_text:true --json --limit=5 | jq '.message.items[].link[].URL'
#> "http://api.wiley.com.pluma.sjfc.edu/onlinelibrary/tdm/v1/articles/10.1002%2F9781119208082.ch9"
#> "http://api.wiley.com.pluma.sjfc.edu/onlinelibrary/tdm/v1/articles/10.1002%2F9781119208082.index"
#> "http://api.wiley.com.pluma.sjfc.edu/onlinelibrary/tdm/v1/articles/10.1002%2F9781119208082.ch11"
#> "http://api.wiley.com.pluma.sjfc.edu/onlinelibrary/tdm/v1/articles/10.1002%2F9781119208082.ch15"
#> "http://api.wiley.com.pluma.sjfc.edu/onlinelibrary/tdm/v1/articles/10.1002%2F9781119208082.ch4"

In an R session, load rcrossref

library("rcrossref")

Search the works route for the phrase “science”

res <- cr_works(query = "science", limit = 5)
#> $meta
#> total_results search_terms start_index items_per_page
#> 1 4333827 science 0 5
#>
#> $data
#> Source: local data frame [5 x 23]
#>
#> alternative.id container.title created deposited DOI funder indexed
#> (chr) (chr) (chr) (chr) (chr) (chr) (chr)
#> 1 2013-11-21 2013-11-21 10.1126/science <NULL> 2015-12-27
#> 2 Science Askew 2004-11-26 2013-12-16 10.1887/0750307145/b426c18 <NULL> 2015-12-24
#> 3 2006-04-10 2010-07-30 10.1002/(issn)1557-6833 <NULL> 2015-12-25
#> 4 2013-08-27 2013-08-27 10.1002/(issn)1469-896x <NULL> 2015-12-27
#> 5 2013-12-19 2013-12-19 10.5152/bs. <NULL> 2015-12-28
#> Variables not shown: ISBN (chr), ISSN (chr), issued (chr), link (chr), member (chr), prefix (chr), publisher
#> (chr), reference.count (chr), score (chr), source (chr), subject (chr), title (chr), type (chr), URL
#> (chr), assertion (chr), author (chr)
#>
#> $facets
#> NULL

Index through to get the DOIs

res$data$DOI
#> [1] "10.1126/science" "10.1887/0750307145/b426c18" "10.1002/(issn)1557-6833"
#> [4] "10.1002/(issn)1469-896x" "10.5152/bs."

rcrossref also has faster versions of most functions with an underscore at the end (_) which only do the http request and give back json (e.g., cr_works_())

Comparison of Crossref Client Methods

After installation and loading the libraries above, the below methods are available

<th>
<span >Python</span>
</th>
<th>
<span >Ruby</span>
</th>
<th>
<span >R</span>
</th>

<td>
<span ><code>cr.works()</code></span>
</td>
<td>
<span ><code>Serrano.works()</code></span>
</td>
<td>
<span ><code>cr_works()</code></span>
</td>

<td>
<span ><code>cr.members()</code></span>
</td>
<td>
<span ><code>Serrano.members()</code></span>
</td>
<td>
<span ><code>cr_members()</code></span>
</td>

<td>
<span ><code>cr.funders()</code></span>
</td>
<td>
<span ><code>Serrano.funders()</code></span>
</td>
<td>
<span ><code>cr_funders()</code></span>
</td>

<td>
<span ><code>cr.types()</code></span>
</td>
<td>
<span ><code>Serrano.types()</code></span>
</td>
<td>
<span ><code>cr_types()</code></span>
</td>

<td>
<span ><code>cr.licenses()</code></span>
</td>
<td>
<span ><code>Serrano.licenses()</code></span>
</td>
<td>
<span ><code>cr_licenses()</code></span>
</td>

<td>
<span ><code>cr.journals()</code></span>
</td>
<td>
<span ><code>Serrano.journals()</code></span>
</td>
<td>
<span ><code>cr_journals()</code></span>
</td>

<td>
<span ><code>cr.members()</code></span>
</td>
<td>
<span ><code>Serrano.members()</code></span>
</td>
<td>
<span ><code>cr_members()</code></span>
</td>

<td>
<span ><code>cr.registration_agency()</code></span>
</td>
<td>
<span ><code>Serrano.registration_agency()</code></span>
</td>
<td>
<span ><code>cr_agency()</code></span>
</td>

<td>
<span ><code>cr.random_dois()</code></span>
</td>
<td>
<span ><code>Serrano.random_dois()</code></span>
</td>
<td>
<span ><code>cr_r()</code></span>
</td>

API Route
works
members
funders
types
licenses
journals
members
registration agency
random DOIs

Other Crossref Services

<th>
<span >Python</span>
</th>
<th>
<span >Ruby</span>
</th>
<th>
<span >R</span>
</th>

<td>
<span ><code>cn.content_negotiation()</code><a href="#footnote-1">[1]</a></span>
</td>
<td>
<span ><code>Serrano.content_negotiation()</code></span>
</td>
<td>
<span ><code>cr_cn()</code></span>
</td>

<td>
<span ><code>cn.csl_styles()</code><a href="#footnote-1">[1]</a></span>
</td>
<td>
<span ><code>Serrano.csl_styles()</code></span>
</td>
<td>
<span ><code>get_styles()</code></span>
</td>

<td>
<span ><code>counts.citation_count()</code><a href="#footnote-2">[2]</a></span>
</td>
<td>
<span ><code>Serrano.citation_count()</code></span>
</td>
<td>
<span ><code>cr_citation_count()</code></span>
</td>

Service
content negotiation
CSL styles
citation count

[1] from habanero import cn

[2] from habanero import counts

Features

These are supported in all 3 libraries:

Filters (see below)
Deep paging (see below)
Pagination
Verbose curl output

Filters

Filters (see API docs for details) are a powerful way to get closer to exactly what you want in your queries. In the Crossref API filters are passed as query parameters, and are comma-separated like filter=has-orcid:true,is-update:true . In the client libraries, filters are passed in idiomatic fashion according to the language.

Python

from habanero import Crossref
cr = Crossref()
cr.works(filter = {'award_number': 'CBET-0756451', 'award_funder': '10.13039/100000001'})

Ruby

require 'serrano'
Serrano.works(filter: {award_number: 'CBET-0756451', award_funder: '10.13039/100000001'})

library("rcrossref")
cr_works(filter=c(award_number=TRUE, award_funder='10.13039/100000001'))

Note how syntax is quite similar among languages, though keys don’t have to be quoted in Ruby and R, and in R you pass in a vector or list instead of a hash as in the other two.

All 3 clients have helper functions to show you what filters are available and what the options are for each filter.

<th>
<span >Python</span>
</th>
<th>
<span >Ruby</span>
</th>
<th>
<span >R</span>
</th>

<td>
<span ><code>filters.filter_names</code><a href="#footnote-3">[3]</a></span>
</td>
<td>
<span ><code>Serrano::Filters.names</code></span>
</td>
<td>
<span ><code>filter_names()</code></span>
</td>

<td>
<span ><code>filters.filter_details</code><a href="#footnote-3">[3]</a></span>
</td>
<td>
<span ><code>Serrano::Filters.filters</code></span>
</td>
<td>
<span ><code>filter_details()</code></span>
</td>

Action
Filter names
Filter details

[3] from habanero import filters

Deep paging

Sometimes you want a lot of data. The Crossref API has parameters for paging (see rows and offset), but large values of either can lead to long response times and potentially timeouts (i.e., request failure). The API has a deep paging feature that can be used when large data volumes are desired. This is made possible via Solr’s cursor feature (e.g., blog post on it). Here’s a run down of how to use it:

cursor: each method in each client library that allows deep paging has a cursor parameter that if you set to * will tell the Crossref API you want deep paging.
cursor_max: for boring reasons we need to have feedback from the user when they want to stop, since each request comes back with a cursor value that we can make the next request with, thus, an additional parameter cursor_max is used to indicate the number of results you want back.
limit: this parameter when not using deep paging determines number of results to get back. however, when deep paging, this parameter sets the chunk size. (note that the max. value for this parameter is 1000)

For example, cursor=”*” states that you want deep paging, cursor_max states maximum results you want back, and limit determines how many results per request to fetch.

Python

from habanero import Crossref
cr = Crossref()
cr.works(query = "widget", cursor = "*", cursor_max = 500)

Ruby

require 'serrano'
Serrano.works(query: "widget", cursor: "*", cursor_max: 500)

library("rcrossref")
cr_works(query = "widget", cursor = "*", cursor_max = 500)

Text mining clients

Just a quick note that I’ve begun a few text-mining clients for Python and Ruby, focused on using the low level clients discussed above.

Python: https://github.com/sckott/pyminer
Ruby: https://github.com/sckott/textminer

Do try them out!

Scheduled Booth Presentations at the Frankfurt Book Fair

Anna Tolwinska — Tue, 29 Sep 2015 00:00:00 +0000

Oktoberfest is in full swing and that makes me think that it’s almost Frankfurt Book Fair time again!

This year in addition to individual meetings we’ll have scheduled flash presentations on our booth, M91 in Hall 4.2. These short (10-minute) presentations are great for anyone wanting a quick intro to what Crossref is all about. Running on Wednesday, Thursday, and Friday - at the following times each of those days:

10am - Small Publisher Tools
12pm - DOIs & Metadata Basics
3pm - Exploring through APIs

If you’d like to meet with us (Ed Pentz, Ginny Hendricks, Rachael Lammey, or Anna Tolwinska) please contact Rosa Morais Clark to set up a meeting.

We look forward to seeing you there!

Determining the Crossref membership status of a domain

Karl Ward — Tue, 22 Nov 2011 00:00:00 +0000

We’ve been asked a few times if it is possible to determine whether or not a particular domain name belongs to a Crossref member. To address this we’re launching another small service that performs something like a “reverse look-up” of URLs and domain names to DOIs and Crossref member status.

The service provides an API that will attempt to reverse look-up a URL to a DOI and return the membership status (member or non-member) of the root domain of the URL. In practice resolving URLs to DOIs has substantial limitations - many publishers redirect the resolution URL of DOIs to other online content and URLs become clogged up with session IDs and other cruft appearing in their query parameters. All of this means it is unlikely that the URLs that appear to be the end result of DOI resolution are actually the URLs pointed to.

However, it’s also possible to provide only a host name, in which case, as with a URL, the Crossref membership status for the root domain will be returned.

There’s also a downloadable list of hashed domains that belong to Crossref members which will be useful to those who want to determine the membership status of a domain locally. Also, a bookmarklet allows anyone to easily check a web page they are looking at to see if the domain it is hosted on belongs to a Crossref member.

Family Names Service

Karl Ward — Thu, 06 Oct 2011 00:00:00 +0000

Today I’m announcing a small web API that wraps a family name database here at Crossref R&D. The database, built from Crossref’s metadata, lists all unique family names that appear as contributors to articles, books, datasets and so on that are known to Crossref. As such the database likely accounts for the majority of family names represented in the scholarly record.

The web API comes with two services: a family name detector that will pick out potential family names from chunks of text and a family name autocompletion system.

Very brief documentation can be found here along with a jQuery example of autocompletion.

The database is still in development so there may be some oddities and inaccuracies in there. Right now one obvious omission from the name list that I hope to address soon are double-worded names such as “von Neumann”. We’re not proposing this database as an authority but rather something that backs a practical service for family name detection and autocompletion.

Crossref’s OpenURL query interface

Chuck Koscher — Wed, 06 May 2009 00:00:00 +0000

Over the past two weeks we’ve focused on our OpenURL query interface with the goal being to improve its reliability. I’d like to mention some things we’ve done.

We now require an OpenURL account to use this interface (see the registration page) . This account is still free, there are no fixed usage limits, and the terms of use have been greatly simplified.
Resources have been re-arranged dedicating more horse-power to the OpenURL function.
The OpenURL function is now in our advanced monitoring function which means some lucky staff member will be getting phone calls at 3AM (me included!).

I should note that #1 has already reduced inappropriate usage. This also is not the end of planned changes. Crossref has undertaken a major rewrite of parts of our system and this will include the OpenURL interface.

Chuck