Interoperability on Crossref

Schema 5.5 now available: adding CRediT, new record types for blogs and posters, and more

Patricia Feeney — Thu, 09 Jul 2026 00:00:00 +0000

Research is rarely limited to a single contributor performing a single role. Behind every research output are people contributing in various ways: software development, data analyses, methodology design, and much more. Often, the same person contributes in several of these ways. Until now, Crossref metadata could only capture part of that picture, but this is changing with Schema 5.5.

Crossref Schema 5.5 includes several improvements across different content types, but its most significant enhancement is the expanded support for contributor roles through the introduction of multiple roles per contributor, option to specify the corresponding author, and compatibility with the CRediT (Contributor Roles Taxonomy): a community-owned taxonomy of 14 contributor roles, which has been adopted and made available in multiple languages.

These enhancements allow members to describe research contributions in much greater detail, creating richer metadata that better reflects how research is actually produced, and supporting greater accountability and more comprehensive research assessment.

If your workflow already distinguishes between different kinds of contributions, Schema 5.5 gives you a way to record that detail more accurately using the CRediT taxonomy values. CRediT can be adopted gradually, where it fits your editorial or production workflow.

Figure 1: Until now, contributors could be assigned a single contributor role using Crossref’s existing contributor role vocabulary. In Schema 5.5, members can indicate that the same contributor was responsible for different roles, such as corresponding author; writing: reviewing and editing; and data curation.

Existing deposits remain fully supported, and members can continue using the current contributor role attribute while planning implementation of the new repeatable role type element. For our members, who have been using CRediT in their workflows already, as ever – we encourage updating your metadata when practicable.

Why this update is kind of a big deal

This update gives more accurate credit to all of the people behind research outputs. Crossref vocabulary includes roles that aren’t recognised in CRediT, and vice versa. Capturing richer contributor metadata recognises contributions that may not be visible in a single author line and improves transparency around how research is produced, thereby enabling downstream systems to interpret that information more reliably. The update also offers better interoperability with CRediT, which is well recognised across the scholarly ecosystem.

Figure 2: Schema 5.5 is an expansion of Crossref contributor metadata. Members can describe contributors using Crossref’s existing contributor role vocabulary, as well as the internationally recognised CRediT taxonomy.

In turn, this strengthens metadata reuse across repositories, discovery services, funders, institutions and other infrastructure providers; and supports evaluation, reporting and discovery workflows. Better contributor metadata strengthens the connections that make up the Research Nexus.

What else is included in Schema 5.5?

Beyond the expanded contributor support, Schema 5.5 includes several additional enhancements across the metadata schema.

1. Updates to report series metadata

Support has been added for metadata elements that were previously missing from report series records, including Crossmark, funding, and licence information.

2. Posted content improvements: now including blogs and posters

Posted content includes preprints, eprints, and other types of content that have been posted to a stewarded host platform. We’re all about persistence, so it’s vital that everything registered with us be maintained. Note that accepted manuscripts are not considered posted content. Schema 5.5 refreshes posted content sub-types by introducing blog and poster.

At the same time, we are “retiring” working paper, dissertation, and report from posted-content sub-types. Over time, these have been developed into separate record types that benefit from richer, dedicated schemas.

Finally, archive locations can now also be included for posted content records.

3. Expanded archive support

A new archive location, CINES, has been added to the list of supported archive providers.

4. Clinical trial metadata across more record types

Clinical trial information is no longer limited to journal articles and conference papers. Schema 5.5 extends support across additional content types, including books, datasets, dissertations, reports, posted content, standards, and pending publications.

Schema adoption

Taken together, the updates in our latest schema support more holistic recognition of contributions to the research and its communication, as well as greater accountability and integrity in related processes.

To support gradual adoption, Schema 5.5 maintains backwards compatibility with existing deposits. Members can continue using the current contributor_role attribute while preparing to implement the new repeatable role element. We have prepared a migration guide to help members transition to Schema 5.5.

As you prepare to adopt Schema 5.5, we encourage members to include contributor roles whenever they are available from editorial workflows and to use recognised vocabularies consistently, including CRediT roles where appropriate.

Building better connections: the story of Crossref's metadata development

Patricia Feeney — Thu, 18 Jun 2026 00:00:00 +0000

Three years ago, we asked our members what they needed from Crossref’s metadata. We received confirmation that we were going in the right direction, as well as some new ideas to explore. This helped set the course for our metadata development work since then, and continues to guide where we’re headed next.

Every metadata update we make is driven by the same set of priorities: supporting metadata that reflects our organizational truths, focusing on what metadata our members can actually provide, and aligning with best practices, vocabularies, and standards that our wider scholarly community has established. More recently our Metadata Advisory Group has helped us explore both the minutia of working with metadata as well as larger ideas around the value and impact of the metadata we support.

What We’ve Accomplished

Our schema 5.4 update included several new or expanded types of metadata. First, citation metadata can now be labelled with a publication type. This means when a work cites an article, a preprint, a dataset, or software, that distinction is clear, helping make citations without an accompanying DOI metadata record easier to identify. Second, version information is now supported across all record types, giving the scholarly record a more precise handle on exactly which version of a work is being described.

We’ve also made two meaningful improvements to how funding relationships are captured. ROR IDs are now supported as funder identifiers in both our standard metadata schema and our grants-specific schema. Also, Grant DOIs can now be explicitly identified within funding metadata, making it possible to draw clearer lines between research outputs and the grants that supported them.

What’s happening now

A significant update is nearly here. Schema 5.5 will expand contributor metadata to support multiple roles per contributor, and will introduce support for CRediT — the ANSI/NISO taxonomy for contributor roles. This means that an individual’s complete contribution to a research output can finally be described in our metadata, rather than flattened into a single role or omitted entirely. The schema isn’t released yet, but the final version of the XML schema is available in our GitLab repository for those who want to get a head start.

We’ll next begin implementation work for a new Grants schema (0.3.0). This update will remodel investigator names to include a new role (beneficiary) as well as an organizational grant recipient, making it possible to include recipient info for grants given to organizations. Grant records include project metadata, so this update will also include support for RAiD, a persistent identifier for projects. The XML schema for this update is also available in a GitLab repository.

What’s up next

Our next planned major update will build substantially on the contributor work in version 5.5. In the next version (6.0) we will remodel names to expand our current limited structure to support a variety of name types as well as alternate names. We’ll also expand the contributor identifiers we collect to include ISNI and Wikidata identifiers, better supporting contributors for whom an ORCID is not possible. Our organizational contributor will be remodelled as well to include organization-level identifiers like ROR.

We’ll also introduce statements to Crossref metadata. Statements will allow members to include free-text statements including funding acknowledgements, ethics declarations, AI usage disclosures, and other important contextual information that doesn’t fit neatly into structured fields.

Other updates include expanding our support for abstracts encoding beyond JATS to include ONIX, BITS, and a generic markup option, and implementing better in-schema validation to avoid surprises at the time of deposit.

Progress means letting go of the past. We’re planning to deprecate all schemas prior to version 5.3.1 by the end of 2027, to be carried out in phases as outlined in our deprecation blog post. This is a necessary step to keep our infrastructure sustainable and to ensure members are working with schemas that reflect current capabilities and standards.

Looking further ahead

Beyond 6.0, we’re exploring further support for provenance in metadata (to establish who is doing what to a metadata record), a rethinking of how we handle dates so that they better capture the lifecycle of a research object, better support for research objects we don’t yet fully support, and making our metadata inputs more consistent. The Metadata Development roadmap has full details on what’s being explored and prioritized.

Each of these updates contributes to Crossref’s research nexus vision: strengthening connections between funders and research, more accurately capturing and recognizing contributor roles in the scholarly record, and collecting free-text content to fill in the gaps that structured metadata alone can’t address. Better metadata means better research integrity and more trustworthy infrastructure for everyone who depends on it.

Enhancing repository integration with Crossref

Johanssen Obanda — Mon, 13 Oct 2025 00:00:00 +0000

Repositories are home to a wide range of scholarly content; they often archive theses, dissertations, preprints, datasets, and other valuable outputs. These records are an important part of the research ecosystem and should be connected to the broader scholarly record. But to truly serve their purpose, repository records need to be connected to each other, to the broader research ecosystem, and to the people behind the research. Metadata is what makes that possible. Enhancing metadata is a way to tell a fuller, more accurate story of research. It helps surface relationships between works, people, funders, and institutions, and allows us as a community to build and use a more connected, more useful network of knowledge - what Crossref calls the ‘Research Nexus’.

The challenge many repositories face is that metadata can be incomplete, inconsistent, or disconnected. Think of references without DOIs, authors without ORCID iDs, or research outputs that aren’t linked to funding. To address this, Crossref provides a range of services that repositories can use to improve the quality and interoperability of their metadata. Our REST API, which is openly and publicly accessible, allows repositories to retrieve structured metadata, such as DOIs, references, abstracts, contributors, ORCID iDs, and funder information, that can be used to enrich and update their local records. For repository members, with the Cited-by service and reference linking, repositories can also show how works are being cited and interconnect related content. The Grant Linking System (GLS) enables the clear indication of which research outputs are linked to specific grants, and funding bodies themselves are connected using Open Funder Registry and ROR, adding another layer of context. With Crossmark, repositories can flag updates, corrections, or retractions to ensure transparency and trust in the scholarly content they host.

Enriching repository metadata using Crossref is a practical and empowering step toward making your records more discoverable, complete, and connected. The process is simple, and you don’t need to be a developer to get started. Repositories can query the Crossref REST API using a DOI or basic metadata like a title or author name, and receive structured, reliable information. This can include full author lists, ORCID iDs, reference lists, funding data, and licensing terms. You can then match and merge this data into your repository records. Adding Crossref DOIs to your metadata enables persistent linking, helping users trace research outputs back to their stewards. It also helps create rich relationships between articles, datasets, software, grants, and other research objects. All of this supports the FAIR principles and contributes to a more connected and reusable scholarly record. And because Crossref’s infrastructure is open, any repository can access and use this metadata to improve the quality, visibility, and long-term value of their collections.

Steps to enrich repository metadata with Crossref:

Query the REST API using DOIs or basic metadata (visit our API learning hub to learn how to use the Crossref API)
Retrieve structured metadata like authors, ORCID iDs, funders, affiliations, ROR IDs, licenses, grants, and references
Map and merge with your local records
Display persistent links to all kinds of research objects using Crossref DOIs
Support FAIR by including open, structured, and complete metadata

Across the repository community, several institutions are already integrating Crossref metadata in meaningful ways to enrich their records and improve discoverability. DSpace users can enrich their deposits by using the platform’s “Live Import” feature, which allows them to pull in Crossref metadata, such as titles, authors, and DOIs, directly into items during the submission process. A deeper integration between DSpace and Crossref is currently in development. HAL in France uses the Crossref API to complete and standardise references, making its content more consistent and connected (hal.archives-ouvertes.fr). SciELO, a key open access platform in Latin America, leverages Crossref DOI links and citation metadata to strengthen the visibility of its journals (scielo.org). In Canada, the University of Saskatchewan’s eCommons repository queries the Crossref API to enhance metadata accuracy and link records to the broader scholarly graph (ecommons.usask.ca). The Apollo repository at the University of Cambridge uses Crossref to connect theses and articles to their published versions, creating a clearer picture of research outcomes (repository.cam.ac.uk). Zenodo, hosted by CERN, draws on Crossref metadata to link deposited datasets and software with related publications, supporting transparency and reuse (zenodo.org).

These examples show how even modest integrations with Crossref can lead to substantial gains in metadata quality, interoperability, and global discoverability. Altogether, these activities and organisations are enhancing the Research Nexus, enriching a scholarly graph for the benefit of all.

Want to learn more? You can explore the presentation slides (PDF) from Open Repositories 2025, which cover the Crossref API and its capabilities, how repositories can use it to query and enrich metadata, the benefits for repository managers, researchers, and funders, as well as recent updates to our metadata schema.

Forming new relationships: contributing to open source

Patrick Vale — Wed, 19 Oct 2022 00:00:00 +0000

TL;DR

One of the things that makes me glad to work at Crossref is the principles to which we hold ourselves, and the most public and measurable of those must be the Principles of Open Scholarly Infrastructure, or POSI, for short. These ambitions lay out how we want to operate - to be open in our governance, in our membership and also in our source code and data. And it’s that openness of source code that’s the reason for my post today - on 26th September 2022, our first collaboration with the JSON Forms open-source project was released into the wild.

Like most organisations, we depend heavily on open-source software for our operations - the software is universally available, generally high quality and ‘free’. And it’s easy to take that dependency, and the associated dependency on free time and effort on the part of the maintainers, for granted - but that’s not very sustainable. In fact, we believe relying on open-source software without helping to sustain it is an anti-pattern, and this project marks the start of our efforts to make funding open-source software a standard part of our technology budget.

This isn’t the first time we’ve supported or released open-source software. Indeed for the past few years, all our new software is open source, and we’re in the process of replacing old closed code with new, so that eventually all our code will be open source. But this is the first time we’ve contributed extensively to something that isn’t focussed primarily on us, and our services. This is a project that we will find very useful, but it is a general purpose tool, and it’s already gaining traction in the community.

Background and motivations

A while back, I was tasked to do a quick spike of work on testing the theory that we could use automated form generation tools to bring new interfaces to our users more quickly, and make them easier for “people who aren’t devs” to adapt and manage. We wanted to build a new user interface for registering content, and especially we wanted to make it easier for funders to register the grants they were awarding. As well as being more approachable by a less-technical audience, we also wanted these forms to be accessible (in terms of a11y and users of assistive technology) and localisable - we wanted a solution that would cater to the needs of our rapidly diversifying membership.

Enter JSON Schema

We were clear about one side of the puzzle - we knew that we had to look beyond the XML ecosystem upon which much of our existing system is built - and landed on JSON Schema. JSON Schema is a ‘vocabulary that allows you to annotate and validate JSON documents’. This means you can describe the shape you expect your data to take, and apply constraints-based validation to that. Which means, in terms of a form library, that you can infer the structure of the form and test that the data entered into it matches what you expect. More than that, you can use that built-in validation to provide error messages to help people get the data right, first time.

Working backwards from the outcome, the argument for adopting JSON Schema is compelling. It provides a mechanism for checking that data you are handling (for example, receiving input from a form) conforms to the constraints that you declare, but also allows you to tell people up-front, in a human and machine-readable way, what structure and format you will accept. This closed-loop of data annotation and validation gets more appealing when you look at the wide adoption of JSON Schema across languages and libraries. You can pretty much guarantee that for whatever client or server -side technology you are using, there will be a JSON Schema validator for it. Being able to share schemas across your systems (and equally importantly, with third parties) moves JSON schema from ‘just’ being about data validation, to a key supportive technology.

Building a form derived from a JSON Schema is an equally attractive prospect. JSON Schema was conceived during the AjaxWorld conference in 2007 as a ‘JSON-based format for defining the structure of JSON data’, and its use as a form-generation tool is relatively new, but there is growing community interest. There is even a discussion about how to best create a JSON Schema vocabulary, specifically geared towards addressing some of the needs of form generation users. However, even in its current form, a JSON Schema can be passed to a library, and a very serviceable user interface appears. The devil is always in the detail, and the client-side libraries differ in their abilities to customise areas such as layout (you may not always want your form fields to appear in exactly the same order as they do in your JSON Schema), custom elements (you might want something that wasn’t a form input, or that changes based on user input) and localisation. The ability to flexibly customise the appearance and behaviour of the interface was a key factor in our selection of a client-side form generation library.

Choosing a library

The other side of the puzzle was less clear - choosing a UI library that would take this JSON Schema, and turn it into a useful, and usable, form. I made the prototype using the venerable React JSON Schema form. This worked well as a proof of concept, but veered dramatically off our chosen Frontend stack of VueJS and Vuetify, and had some architectural constraints that would limit the scope of customisations we could make to our forms. So I went off looking for libraries that would work with our stack and came up with Vuetify JSON Schema Form, and JSON Forms.

Vuetify JSON Schema Form matched our stack perfectly, but made some interesting decisions about the layout of data within the form, and that wouldn’t suit our purposes without dramatic modification.

JSON Forms was an abstracted library, with a core handling the JSON Schema transformation and validation, and separate rendering libraries to handle the form generation. This was great - they had renderers for Angular, React, and even some support for VueJS. But not Vuetify.

Clearly, we were going to have to make something.

We made contact with the maintainers of both short-listed libraries to see how we could collaborate in creating a tool that would meet all of our (and hopefully, much of the wider community’s) requirements. Both maintainers were very helpful, and we had constructive discussions in both cases. In the end, we decided that the abstracted nature of the JSON Forms project was a better fit for our needs, providing a flexible platform on which we - and others - could extend. We were fortunate to receive funding from the Gordon and Betty Moore Foundation (Grant Agreement #10485) in order to accelerate this work, so we could provide a Grant Registration UI more quickly. We paid a large portion of that funding to the library maintainers, and Crossref contributed a portion of my time on the project. This allowed us to enter into an agreement with EclipseSource, the maintainers of JSON Forms, to collaboratively develop the new VueJS and Vuetify renderer library. Stefan Dirix, the lead maintainer, worked with me to build it.

We didn’t forget about Vuetify JSON Schema Form though, and by way of appreciation for their help in the early stages, Crossref made a contribution towards the continued development of that library.

JSON Forms - now with Vuetify

Work started on the JSON Forms Vuetify renderer set in September 2021 - Stefan quickly created the first early prototypes of the new form renderers - but then we had a stroke of luck. Our repository received more input from the community. The one that made us sit up and take real notice was the news that someone else had already ported the JSON Forms React renderer set to Vue/Vuetify - and was offering this as a contribution. Krasimir Chobantonov’s fantastic first contribution got merged in at the end of the month. This propelled the project forward massively, and was an early validation of the value of working in the open. Needless to say, we were very grateful. Another example of the open source value chain was that Stefan - as the maintainer - could take the time to carefully review and tidy up the incoming code, so what was merged was the product of two great developers.

Having this great head start meant we could turn our attention to one of the other big areas we wanted to get right - localisation. Traditionally, JSON Schema -generated forms have handled localisation (translation of text and adjustment of date and numerical formats) by wholesale duplication and translation of the schema. This is cumbersome, and doesn’t integrate very well with custom error messages, nor external sources of interface messages (think form labels, descriptions, placeholders). So Stefan came up with a proposal, which we accepted, to add complete i18n support to the library. We now have a mechanism by which you can hook up a translation engine of your choice, and JSON forms will use that to lookup messages, before falling back to the validator (also localised!) and finally, the JSON Schema’s defaults. This gives much stronger integration and allows the community to plug in their existing localisation methods - no wasted effort.

Since the localisation addition, we’ve been working on fine-tuning the layout engine, making bug fixes, and integrating more closely with the underlying Vuetify library. This allows developers to more easily use the existing Vuetify parameters to change the style and behaviour of their form widgets. Again, no wasted effort.

We’re lucky to have an active community - @kchobantonov continues to make great contributions and push the library forward in unexpected ways - and the library is gaining popularity, with an average of a few hundred downloads per day.

Some of our funder members have already seen this work in action, and given their feedback on early iterations of the user interface that supports registering grant records. We’ll be releasing this publicly very soon to get feedback from members - and then using that feedback to iterate on the grants registration form, and look towards extending it to other record types.

Open source POSItivity

A continuous theme throughout this project has been the willingness of people working on these open source projects to be generous with their time and experience. Whether it has been form generation libraries, the JSON Schema project or maintainers of localisation plug-ins - help, advice and encouragement have never been far away. And that’s appreciated. But it’s not something that we, or any other organisation who relies on the software they produce, should take for granted. Open source software helps everyone who uses it, and there’s a real opportunity within our community to make meaningful steps towards supporting its sustainability. Ironically, it’s often the most-used general purpose tools that get the least attention. We can change that.

Look out for more

Look out for more posts from the engineering team, coming soon!

References

JSON Binpack: A space-efficient schema-driven and schema-less binary serialization specification based on JSON Schema (Chapter 3.2.1 History and Relevance)

https://web.archive.org/web/20071026190426/http://www.json.com/2007/09/27/json-schema-proposal-collaboration/

Accessibility for Crossref DOI Links: Call for comments on proposed new guidelines

Jennifer Kemp — Tue, 06 Sep 2022 00:00:00 +0000

Our entire community – members, metadata users, service providers, community organisations and researchers – create and/or use DOIs in some way so making them more accessible is a worthy and overdue effort.

For the first time in five years and only the second time ever, we are recommending some changes to our DOI display guidelines (the changes aren’t really for display but more on that below). We don’t take such changes lightly, because we know it means updating established workflows. We appreciate the questions that prompted us to make this recommendation and we know it’s critical that we get community input on the proposed updates.

TL;DR

Here is a quick overview:

DOIs and URLs themselves don’t really tell readers much. People with visual impairments rely on screen readers to read out loud the contents of a page. We’re asking for the title of each DOI to be added, in an ARIA (Accessible Rich Internet Applications) attribute, so these users understand what these links are for.
Accessible text, as this kind of description is known, should be included for all links, but at this time, we’re specifically recommending it for landing pages of newly registered records.
It’s not required, yet. We’re proposing a 2 year recommendation period and we want your feedback on the particulars, including timing and how we can help. Please take a short survey and/or get in touch and share your thoughts.
We’ll finalize these recommendations after assessing the feedback. Please check back for updates.

What is changing, when and why

The proposed updates are meant to improve overall usability, particularly for people with visual impairments, by aligning our guidelines with modern accessibility requirements such as the new W3C recommendations and the European Accessibility Act. This means that assistive technologies such as screen readers can interpret DOI links.

Why are changes being recommended?

DOIs are unique and persistent links to items in the scholarly record so it makes sense that they link to the full URLs for the associated content –for example, a journal article. The issue for people who rely on screen readers is that a DOI link doesn’t provide title or other information to give that link context. Users of screen readers need to know what the destination of a link is.

These users often lack the context that other users have; in fact, they may be presented with links in a document as a list. That’s why all links, not just DOI links, need what is called “accessible text.” Providing additional information for links requires ARIA (Accessible Rich Internet Applications) techniques. This speaks to the Web Content Accessibility Guidelines (WCAG), the standard guidelines for accessibility across the web, specifically success criterion 2.4.4 - Link Purpose (In Context), which aims to ‘help users understand the purpose of each link so they can decide whether they want to follow the link.’

For your feedback: recommended draft changes

We recommend the addition of an aria-label attribute for DOI links, containing as its value the descriptive title of the content represented by the DOI, so that screen readers can interpret DOI links. This means that, while the DOI display itself doesn’t actually change, the link is enhanced with additional, contextual information for the user of assistive technology, in one of two ways, either:

an aria-label attribute, described as ‘a way to place a descriptive text label on an object,’ identifying the destination, or
an aria-describedby attribute pointing to where the destination is identified in the surrounding text.

The updated HTML for a journal article*, for example, would be:

<a href="https://doi-org.pluma.sjfc.edu/10.5555/12345678" aria-label="DOI for Toward a Unified Theory of High-Energy Metaphysics: Silly String Theory">https://doi-org.pluma.sjfc.edu/10.5555/12345678</a>

Here the aria-label has been set to the value of the ‘title’ property as retrieved from the Crossref REST API at https://api-crossref-org.pluma.sjfc.edu/v1/works/10.5555/12345678.

*Note that fields may vary slightly for different record types.

This proposed solution allows screen readers to read aloud to users the value of the aria-label attribute, instead of the full DOI in the link text.

At this time, we are recommending the change for landing pages in particular, but it can and should be applied to wherever DOI links appear, whenever feasible (more on this below).

Our guidelines will continue to state that the DOI should always be displayed as a full URL link–that will not change. Neither will content registration–we are not asking for additional information in your deposits.

It’s not perfect, but it’s very worthwhile

This recommendation has some limitations worth noting but it must be said that there is no perfect solution.

DOI links appear in lots of places - PDFs for one notable example. We reviewed and tested the recommendation with Bill Kasdorf, Principal, Kasdorf & Associates, LLC, Richard Orme, CEO, DAISY Consortium, and George Kerscher, Chief Innovations Officer, DAISY Consortium-Senior Officer, Global Literacy, Benetech, who graciously provided their time and expertise. EPUBs and websites proved to be easy to update; other formats, notably PDFs, less so. Widespread adoption of accessible DOIs is so important and we don’t want confusion or frustration to get in the way of making progress. We support and welcome efforts to include an ARIA attribute wherever DOI links appear, but we recommend focusing on landing pages, for now.

Patrick Vale, Crossref Senior Front End Developer, explains that:

”DOI links serve a very specific purpose: to provide the persistent link to an item in the scholarly record. And as such, they present an unusual set of requirements when balancing accurately presenting the information they encode - the persistent link - and making that link accessible, and understandable. With these proposed changes, we hope to strike this balance.“

We know it will be a challenge (more on that below) but we think it’s absolutely a worthwhile effort. Indeed, we are undertaking a project to update our own website to meet these recommendations and to review overall accessibility.

As Bill Kasdorf notes:

“Most people have no idea how many people with visual impairments there are. Not only is it unfair to those people not to provide accessible text for links, the authors and publishers of the linked resource are missing a lot of readers. This update is a great move by Crossref, and every bit aligned with its mission to make scholarly content discoverable and consumable.”

We propose the following timeline, also for your feedback

Once finalized, following community feedback, the updated guidelines will be issued as a recommendation for a suggested period of two years starting next year, 2023. Beginning in 2025, the changes will be required for landing pages of newly registered content (and strongly recommended for existing registered content). Feedback on this approach and timeline is also encouraged.

Help us help you

We are conscious that adding descriptive information to DOI links places a significant responsibility on the members and Service Providers creating and hosting these links. Therefore, we are also considering the creation of a tool to help with implementation. Initial discussions suggest this could be a JavaScript helper tool, which could be included on member websites. We also welcome feedback as to how such a tool might be implemented, and how it would best integrate with existing sites and workflows.

Call for comments - by 1st November

We hope that this proposal is a welcome one and that the timing is good for moving forward together toward greater accessibility of the scholarly record. We welcome questions, feedback and suggestions through 1st November via the survey below or by email to feedback@crossref.org

Small changes, big impact

We’re excited to make changes that improve accessibility and we look forward to the community’s response to our proposal. We will share aggregated feedback in an updated post later this year.

A note on language

Multiple sources were consulted to find the most appropriate and inclusive term(s) for users of screen readers in this context. “Print disabled,” for example, seemed to be a good candidate but was ultimately deemed likely to be confusing to a very global publishing audience, who often don’t physically print anything. Sources differ slightly, for example between the US and UK and of course, this English text may well be translated into other languages. Feedback on the terms used here is also very welcome.

Additional resources

The Inclusive Publishing Hub (DAISY Consortium)
National Center on Disability and Journalism (Arizona State University, US)
Inclusive Language guidance (UK government)
The American Psychological Association (APA) Bias-Free Language Disability Guide
The Open Access Books Network (OABN)

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.

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.

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.

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!

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.

Clinical trial data and articles linked for the first time

Daniel Shanahan — Tue, 17 May 2016 00:00:00 +0000

It’s here. After years of hard work and with a huge cast of characters involved, I am delighted to announce that you will now be able to instantly link to all published articles related to an individual clinical trial through the Crossmark dialogue box. Linked Clinical Trials are here!

In practice, this means that anyone reading an article will be able to pull a list of both clinical trials relating to that article and all other articles related to those clinical trials – be it the protocol, statistical analysis plan, results articles or others – all at the click of a button.

Linked Clinical Trials interface

Now I’m sure you’ll agree that this sounds nifty. It’s definitely a ‘nice-to-have’. But why was it worth all the effort? Well, simply put: “to move a mountain, you begin by carrying away the small stones”.

Science communication in its current form is an anachronism, or at the very least somewhat redundant.

You may have read about the ‘crisis in reproducibility’. Good science, at its heart, should be testable, falsifiable and reproducible, but an historical over-emphasis on results has led to a huge number of problems that seriously undermine the integrity of the scientific literature.

Issues such as publication bias, selective reporting of outcome and analyses, hypothesising after the results are known (HARKing) and p-hacking are widespread, and can seriously distort the literature base (unless anyone seriously considers Nicholas Cage to be causally related to people drowning in swimming pools).

This is, of course, nothing new. Calls for prospective registration of clinical trials date back to the 1980s and it is now becoming increasingly commonplace, recognising that the quality of research lies in the questions it asks and the methods it uses, not the results observed.

Uptake of trial registration year-on-year since 2000

Building on this, a number of journals and funders – starting with BioMed Central’s Trials over 10 years ago – have also pushed for the prospective publication of a study’s protocol and, more recently, statistical analysis plan. The idea that null and non-confirmatory results have value and should be published has also gained increasing support.

Over the last ten years, there has been a general trend towards increasing transparency. So what is the problem? Well, to borrow an analogy from Jeremy Grimshaw, co-Editor-in-Chief of Trials – we’ve gone from Miró to Pollock.

Although a results paper may reference a published study protocol, there is nothing to link that report to subsequent published articles; and no link from the protocol itself to the results article.

A single clinical trial can result in multiple publications: the study protocol and traditional results paper or papers, as well as commentaries, secondary analyses and, eventually, systematic reviews, among others, many published in different journals, years apart. This situation is further complicated by an ever-growing body of literature.

Researchers need access to all of these articles if they are to reliably evaluate bias or selective reporting in a research object, but – as any systematic reviewer can tell you – actually finding them all is like looking for a needle in a haystack. When you don’t know how many needles there are. With the haystack still growing.

That’s where we come in. The advent of trial registration means that there is a unique identifier associated with every clinical trial, at the study-level, rather than the article level. Building on this, the Linked Clinical Trials project set out to connect all articles relating to an individual trial together using its trial registration number (TRN).

By adapting the existing Crossmark standard, we have captured additional metadata about an article, namely the TRN and the trial registry, with this information then associated with the article’s DOI on publication. This means that you will be able to pull all articles related to an individual clinical trial from the Crossmark dialogue box on any relevant article.

This obviously has huge implications for the way science is reported and used. By quickly and easily linking to related published articles, it will enable editors, reviewers and researchers to evaluate any selective reporting in the study, and help to provide far greater context for the results.

As all the metadata will be open access (CC0), with no copyright, it will also be possible to access this article ‘thread’ through the Crossref Metadata Search, or independently through an application programming interface (API). This provides a platform for others to build on, with many already looking to take the next step, such as Ben Goldacre’s new Open Trials initiative.

However, in order for this to work, we must capture as many articles and trials as possible to create a truly comprehensive thread of publications. We currently have data from the NIHR Libraries, PLoS and, of course, BioMed Central, but need more publishers and journals to join us in depositing clinical trial metadata. After all, without metadata, this is all merely wishful thinking.

Let’s hope we’re the pebble that starts the landslide.

DOI Event Tracker (DET): Pilot progresses and is poised for launch

Jennifer Lin — Tue, 15 Sep 2015 00:00:00 +0000

Publishers, researchers, funders, institutions and technology providers are all interested in better understanding how scholarly research is used. Scholarly content has always been discussed by scholars outside the formal literature and by others beyond the academic community. We need a way to monitor and distribute this valuable information.

The Crossref DOI Event Tracker (DET)

To meet this need, Crossref will be introducing a new service that tracks activity surrounding a research work from potentially any web source where an event is associated with a DOI. Following a successful pilot run started Spring 2014, the service has been approved to move toward production and is expected to launch in 2016. Any party wishing to join this phase is welcome to contact Jennifer Lin. The DOI Event Tracker (DET) registers a wide variety of events such as bookmarks, comments, social shares, citations, and links to other research entities, from a growing list of online sources. DET aggregates them, and stores and delivers the data in many ways.

Open, portable, and licensed for maximum reuse

Crossref has long served as the citation linking and metadata infrastructure provider for scholarly communication; the new DOI Event Tracker is a natural next step, providing a practical solution as a resource for the whole community. The tracker offers the following features:

Data on event activity across a common pool of online channels.
Near real-time alerting for select sources with push notifications to the system.
Cross-publisher monitoring to enable benchmarking and provide context to the data.
Common format for normalizing data results across the diverse set of sources via modern REST API.
Secure and regularly refreshed backups of critical data for long term data preservation.
Transparency of data collection so as to ensure auditable, replicable, and trustworthy results.
Query-initiated retrieval or real-time alerts when an event of interest occurs.
CC-0 license for open and flexible propagation of data.

A number of platforms are already confirmed and more parties are welcomed at any stage. So far we have confirmation to track DOI events on the following platforms:

[table id=1 /]

This set of sources reflects our initial focus on parties willing to allow their data to be redistributed in the common pool. Efforts are underway to expand the source list to include Twitter and MyScienceWork, among others. Publishers can also act as sources by publishing and distributing DOI event data via the DET when an event occurs on its platform (for example, when a PDF is downloaded, or when a comment mentions a DOI in a locally hosted discussion forum, etc.). This would make local DOI activity globally available to funders, researchers, institutions, etc.

DET provides benefits of scale and ease of access as a central point for collecting and propagating data to the community. As a single point of access, it overcomes the business and technical hurdles that are a part of managing multiple online sources where scholarly activity occurs, in a rapidly changing landscape of online channels. This resource covers content across publishers and serves as a strong foundation to support the development of tools and services by any party. DET users will always be able to combine the DET data with those individually collected via negotiated or paid access. DET remains a utility separate from any value-added amenities, such as analytics, presentation, and reporting.

DET Service-Level Agreement

For those who seek the highest level of service and a more flexible range of access options, Crossref will provide a Service-Level Agreement (SLA) service for the DOI Event Tracker. The DET SLA includes the following additional features on top of the common data offering:

Access to the complete suite of sources, which includes restricted and/or paid sources in addition to common data, providing the fullest picture of DOI usage activity possible.
Guaranteed uptime and response time to the latest raw data on the aggregate activity surrounding a DOI.
Guaranteed support response time to questions and issues surrounding data and data delivery.
Flexible data access options: on-demand real time data access and scheduled bulk downloads for processing batch analytics.
Optimum retrieval rates and accelerated delivery speeds with the dedicated SLA API.
Access to a webhook API for events of interest as an alternative to polling DET.
Standardized and enhanced linkback service for the difficult-to-track, grey literature.

The DET SLA service has a simple, value-based pricing model based on subscriber size. Register your interest in Crossref’s DOI Event Tracker and the DET SLA service if you would like stay informed of the upcoming launch. Please contact Jennifer Lin for more information.

Image modified from “Radar” icon by Karsten Barnett from the Noun Project.

Many Metrics. Such Data. Wow.

Geoffrey Bilder — Mon, 24 Feb 2014 00:00:00 +0000

[

Crossref Labs loves to be the last to jump on an internet trend, so what better than than to combine the Doge meme with altmetrics?

Note: The API calls below have been superceeded with the development of the Event Data project. See the latest API documentation for equivalent functionality

Want to know how many times a Crossref DOI is cited by the Wikipedia?

http://det.labs.crossref.org.pluma.sjfc.edu/works/doi/10.1371/journal.pone.0086859

Or how many times one has been mentioned in Europe PubMed Central?

http://det.labs.crossref.org.pluma.sjfc.edu/works/doi/10.1016/j.neuropsychologia.2013.10.021

Or DataCite?

http://det.labs.crossref.org.pluma.sjfc.edu/works/doi/10.1111/jeb.12289

Background

Back in 2011 PLOS released its awesome ALM system as open source software (OSS). At Crossref Labs, we thought it might be interesting to see what would happen if we ran our own instance of the system and loaded it up with a few Crossref DOIs. So we did. And the code fell over. Oops. Somehow it didn’t like dealing with 10 million DOIs. Funny that.

But the beauty of OSS is that we were able to work with PLOS to scale the code to handle our volume of data. Crossref contracted with Cottage Labs and we both worked with PLOS to make changes to the system. These eventually got fed back into the main ALM source on Github. Now everybody benefits from our work. Yay for OSS.

So if you want to know technical details, skip to Details for Propellerheads. But if you want to know why we did this, and what we plan to do with it, read on.

Why?

There are (cough) some problems in our industry that we can best solve with shared infrastructure. When publishers first put scholarly content online, they used to make bilateral reference linking agreements. These agreements allowed them to link citations using each other’s proprietary reference linking APIs. But this system didn’t scale. It was too time-consuming to negotiate all the agreements needed to link to other publishers. And linking through many proprietary citation APIs was too complex and too fragile. So the industry founded Crossref to create a common, cross-publisher citation linking API. Crossref has since obviated the need for bilateral linking arrangements.

So-called altmetrics look like they might have similar characteristics. You have ~4000 Crossref member publishers and N sources (e.g. Twitter, Mendeley, Facebook, CiteULike, etc.) where people use (e.g. discuss, bookmark, annotate, etc.) scholarly publications. Publishers could conceivably each choose to run their own system to collect this information. But if they did, they would face the following problems:

The N sources will be volatile. New ones will emerge. Old ones will vanish.
Each publisher will need to deal with each source’s different APIs, rate limits, T&Cs, data licenses, etc. This is a logistical headache for both the publishers and for the sources.
If publishers use different systems which in turn look at different sources, it will be difficult to compare results across publishers.
If a journal moves from one publisher to another, then how are the metrics for that journal’s articles going to follow the journal? This isn’t a complete list, but it shows that there might be some virtue in publishers sharing an infrastructure for collecting this data. But what about commercial providers? Couldn’t they provide these ALM services? Of course - and some of them currently do. But normally they look on the actual collection of this data as a means to an end. The real value they provide is in the analysis, reporting and tools that they build on top of the data. Crossref has no interest in building front-ends to this data. If there is a role for us to play here, it is simply in the collection and distribution of the data.

No, really, WHY?

Aren’t these altmetrics an ill-conceived and meretricious idea? By providing this kind of information, isn’t Crossref just encouraging feckless, neoliberal university administrators to hasten academia’s slide into a Stakhanovite dystopia? Can’t these systems be gamed?

FOR THE LOVE OF FSM, WHY IS CROSSREF DABBLING IN SOMETHING OF SUCH QUESTIONABLE VALUE?

takes deep breath. wipes spittle from beard

These are all serious concerns. Goodhart’s Law and all that… If a university’s appointments and promotion committee is largely swayed by Impact Factor, it won’t improve a thing if they substitute or supplement Impact Factor with altmetrics. Amy Brand has repeatedly pointed out, the best institutions simply don’t use metrics this way at all (PowerPoint presentation). They know better.

But yes, it is still likely that some powerful people will come to lazy conclusions based on altmetrics. And following that, other lazy, unscrupulous and opportunistic people will attempt to game said metrics. We may even see an industry emerge to exploit this mess and provide the scholarly equivalent of SEO. Feh. Now I’m depressed and I need a drink.

So again, why is Crossref doing this? Though we have our doubts about how effective altmetrics will be in evaluating the quality of content, we do believe that they are a useful tool for understanding how scholarly content is used and interpreted. The most eloquent arguments against altmetrics for measuring quality, inadvertently make the case for altmetrics as a tool for monitoring attention.

Critics of altmetrics point out that much of the attention that research receives outside of formal scholarly communications channels can be ascribed to:

Puffery. Researchers and/or university/publisher “PR wonks” over-promoting research results.
Innocent misinterpretation. A lay audience simply doesn’t understand the research results.
Deliberate misinterpretation. Ideologues misrepresent research results to support their agendas.
Salaciousness. The research appears to be about sex, drugs, crime, video games or other popular bogeymen.
Neurobollocks. A category unto itself these days.

In short, scholarly research might be misinterpreted. Shock horror. Ban all metrics. Whew. That won’t happen again.

Scholarly research has always been discussed outside of formal scholarly venues. Both by scholars themselves and by interested laity. Sometimes these discussions advance the scientific cause. Sometimes they undermine it. The University of Utah didn’t depend on widespread Internet access or social networks to promote yet-to-be peer-reviewed claims about cold fusion. That was just old-fashioned analogue puffery. And the Internet played no role in the Laetrile or DMSO crazes of the 1980s. You see, there were once these things called “newspapers.” And another thing called “television.” And a sophisticated meatspace-based social network called a “town square.”

But there are critical differences between then and now. As citizens get more access to the scholarly literature, it is far more likely that research is going to be discussed outside of formal scholarly venues. Now we can build tools to help researchers track these discussions. Now researchers can, if they need to, engage in the conversations as well. One would think that conscientious researchers would see it as their responsibility to remain engaged, to know how their research is being used. And especially to know when it is being misused.

That isn’t to say that we expect researchers will welcome this task. We are no Pollyannas. Researchers are already famously overstretched. They barely have time to keep up with the formally published literature. It seems cruel to expect them to keep up with the firehose of the Internet as well.

Which gets us back to the value of altmetrics tools. Our hope is that, as altmetrics tools evolve, they will provide publishers and researchers with an efficient mechanism for monitoring the use of their content in non-traditional venues. Just in the way that citations were used before they were distorted into proxies for credit and kudos.

We don’t think altmetrics are there yet. Partly because some parties are still tantalized by the prospect of usurping one metric for another. But mostly because the entire field is still nascent. People don’t yet know how the information can be combined and used effectively. So we still make naive assumptions such as “link=like” and “more=better.” Surely it will eventually occur to somebody that, instead, there may be a connection between repeated headline-grabbing research and academic fraud. A neuroscientist might be interested in a tool that alerts them if the MRI scans in their research paper are being misinterpreted on the web to promote neurobollocks. An immunologist may want to know if their research is being misused by the anti-vaccination movement. Perhaps the real value in gathering this data will be seen when somebody builds tools to help researchers DETECT puffery, social-citation cabals, and misinterpretation of research results?

But Crossref won’t be building those tools. What we might be able to do is help others overcome another hurdle that blocks the development of more sophisticated tools; getting hold of the needed data in the first place. This is why we are dabbling in altmetrics.

Wikipedia is already the 8th largest referrer of Crossref DOIs. Note that this doesn’t just mean that the Wikipedia cites lots of Crossref DOIs, it means that people actually click on and follow those DOIs to the scholarly literature. As scholarly communication transcends traditional outlets and as the audience for scholarly research broadens, we think that it will be more important for publishers and researcher to be aware of how their research is being discussed and used. They may even need to engage more with non-scholarly audiences. In order to do this, they need to be aware of the conversations. Crossref is providing this experimental data source in the hope that we can spur the development of more sophisticated tools for detecting and analyzing these conversations. Thankfully, this is an inexpensive experiment to conduct - largely thanks to the decision on the part of PLOS to open source its ALM code.

What Now?

Crossref’s instance of PLOS’s ALM code is an experiment. We mentioned that we had encountered scalability problems and that we had resolved some of them. But there are still big scalability issues to address. For example, assuming a response time of 1 second, if we wanted to poll the English-language version of the Wikipedia to see what had cited each of the 65 million DOIs held in Crossref, the process would take years to complete. But this is how the system is designed to work at the moment. It polls various source APIs to see if a particular DOI is “mentioned”. Parallelizing the queries might reduce the amount of time it takes to poll the Wikipedia, but it doesn’t reduce the work. Another obvious way in which we could improve the scalability of the system is to add a push mechanism to supplement the pull mechanism. Instead of going out and polling the Wikipedia 65 million times, we could establish a “scholarly linkback” mechanism that would allow third parties to alert us when DOIs and other scholarly identifiers are referenced (e.g. cited, bookmarked, shared). If the Wikipedia used this, then even in an extreme case scenario (i.e. everything in Wikipedia cites at least one Crossref DOI), this would mean that we would only need to process ~ 4 million trackbacks.

The other significant advantage of adding a push API is that it would take the burden off of Crossref to know what sources we want to poll. At the moment, if a new source comes online, we’d need to know about it and build a custom plugin to poll their data. This needlessly disadvantages new tools and services as it means that their data will not be gathered until they are big enough for us to pay attention to. If the service in question addresses a niche of the scholarly ecosystem, they may never become big enough. But if we allow sources to push data to us using a common infrastructure, then new sources do not need to wait for us to take notice before they can participate in the system.

Supporting (potentially) many new sources will raise another technical issue- tracking and maintaining the provenance of the data that we gather. The current ALM system does a pretty good job of keeping data, but if we ever want third parties to be able to rely on the system, we probably need to extend the provenance information so that the data is cheaply and easily auditable.

Perhaps the most important thing we want to learn from running this experimental ALM instance is: what it would take to run the system as a production service? What technical resources would it require? How could they be supported? And from this we hope to gain enough information to decide whether the service is worth running and, if so, by whom. Crossref is just one of several organisations that could run such a service, but it is not clear if it would be the best one. We hope that as we work with PLOS, our members and the rest of the scholarly community, we’ll get a better idea of how such a service should be governed and sustained.

Details for Propellerheads

Warning, Caveats and Weasel Words

The Crossref ALM instance is a Crossref Labs project. It is running on R&D equipment in a non-production environment administered by an orangutang on a diet of Redbulls and vodka.

So what is working?

The system has been initially loaded with 317,500+ Crossref DOIs representing publications from 2014. We will load more DOIs in reverse chronological order until we get bored or until the system falls over again.

We have activated the following sources:

PubMed

DataCite

PubMedCentral Europe Citations and Usage

We have data from the following sources but will need some work to achieve stability:

Facebook

Wikipedia

CiteULike

Twitter

Some of them are faster than others. Some are more temperamental than others. WordPress, for example, seems to go into a sulk and shut itself off after approximately 1,300 API calls.

In any case, we will be monitoring and tweaking the sources as we gather data. We will also add new sources as we get requested API keys. We will probably even create one or two new sources ourselves. Watch this blog and we’ll update you as we add/tweak sources.

Dammit, shut up already and tell me how to query stuff.

You can login to the Crossref ALM instance simply using a Mozilla Persona (yes, we’d eventually like to support ORCID too). Once logged-in, your account page will list an API key. Using the API key, you can do things like:

http://det.labs.crossref.org.pluma.sjfc.edu/api/v5/articles?ids=10.1038/nature12990

And you will see that (as of this writing), said Nature article has been cited by the Wikipedia article here:

https://en.wikipedia.org/wiki/HE0107-5240#cite_ref-Keller2014_4-0;

PLOS has provided lovely detailed instructions for using the API- So, please, play with the API and see what you make of it. On our side we will be looking at how we can improve performance and expand coverage. We don’t promise much- the logistics here are formidable. As we said above, once you start working with millions of documents, the polling process starts to hit API walls quickly. But that is all part of the experiment. We appreciate your helping us and would like your feedback. We can be contacted at:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

These journals assigned DOIs, but not through Crossref:

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

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

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

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

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

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

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

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

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

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

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

https://ui.eidr.org/search

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

https://search.datacite.org/

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

Background

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

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

DOIs are just identifiers

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

Multiple DOIs can be assigned to the same object

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DOI Interoperability matters more for some registration agencies than others

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

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

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

Summary and closing thoughts

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

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

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

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

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

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

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

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

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

PatentCite

Geoffrey Bilder — Mon, 13 Aug 2012 00:00:00 +0000

If you’ve ever thought that scholarly citation practice was antediluvian and perverse- you should check-out patents some day.

Over the past year of so Crossref has been working with Cambia and the The Lens to explore how we can better link scholarly literature to and from the patent literature. The first object of our collaboration was to attempt to link patents hosted on the new, beta version of The Lens to the Scholarly literature. To do this, Crossref and Cambia been enhancing Crossref’s citation matching mechanisms in order to better resolve the wide variety of eclectic and terse patent citation styles to Crossref DOIs.

You can see the results of these ongoing attempts on the The Lens beta site where all of The Len’s ~~8 million+~~ 80 million+ patents and applications (obtained through subscriptions with WIPO, USPTO, EPO and IP Australia) are starting to be linked directly to the scholarly literature. See, for example:

http://beta.lens.org/lens/patent/US\_RE42150\_E1/citations
[Editor’s update: Link is broken. Removed January 2021]

Crossref has taken this matched data and has now released a Crossref Labs *experimental* service , called PatentCite, that allows you to take any Crossref DOI and see what Patents in the The Lens system cite it.

As with all Crossref Labs services- this one is likely to be:

a) As stable as the global economy

c) As reliable as a UK train

ii) Out-of-date. It is based on a snapshot of Crossref /Lens data.

As accurate as my list ordering

Howzat for an SLA?

As we get feedback from Crossref’s membership and as we gain more experience linking Patents to and from the scholarly literature, we will explore including this functionality in our production Cited-by service. But until then- please send us your feedback on this experimental service.

OpenSearch/SRU Integration Paper

Tony Hammond — Mon, 19 Jul 2010 00:00:00 +0000

Since I’ve already blogged about this a number of times before here, I thought I ought to include a link to a fuller writeup in this month’s D-Lib Magazine of our nature.com OpenSearch service which serves as a case study in OpenSearch and SRU integration:

doi:10.1045/july2010-hammond

Recommendations on RSS Feeds for Scholarly Publishers

Geoffrey Bilder — Mon, 19 Oct 2009 00:00:00 +0000

We’re pleased to announce that a Crossref working group has released a set of best practice recommendations for scholarly publishers producing RSS feeds.

Variations in practice amongst publisher feeds can be irritating for end-users, but they can be insurmountable for automated processes. RSS feeds are increasingly being consumed by knowledge discovery and data mining services. In these cases, variations in date formats, the practice of lumping all authors together in one <dc:creator> element, or generating invalid XML can render the RSS feed useless to the service accessing it.

The recommendations intended to facilitate good practice in the production and provision of TOC RSS Feeds. The guidelines include general recommendations for good practice, specific recommendations on the use of RSS Modules and an example RSS TOC feed. Ultimately, we expect that industry wide adoption of these best practices will help drive more traffic to publisher web sites. Note that most of these recommendation can also be applied to non-TOC RSS feeds such as thematic feeds, automated search result feeds, etc.

OAI-ORE: Workshop Slides

Tony Hammond — Tue, 26 May 2009 00:00:00 +0000

An Overview of the OAI Object Reuse and Exchange Interoperability Framework

View more Microsoft Word documents from hvdsomp.

This is a very slick presentation by Herbert Van de Sompel on OAI-ORE which he’s due to give today for a workshop at the INFORUM 2009 15th Conference on Prrofessional Information Resources in Prague. It’s on the long side at 167 slides but even if you just flip though or sample it selectively you’ll be bound to come away with something.

Describing aggregations of resources is a subject that really has to be of interest to Crossref publishers.

PRISM Aggregator Message

Tony Hammond — Fri, 08 May 2009 00:00:00 +0000

The new OAI-PMH interface to Nature.com sports one particular novelty which may well be of interest here: it makes use of the PRISM Aggregator Message. (For an announcement of this service see the post on our web publishing blog Nascent.)

As a protocol for the harvesting of metadata records within a digital repository, OAI-PMH records may be expressed in a variety of different metadata formats. For reasons of interoperability a base metadata format (‘Dublin Core’) is mandated for all OAI-PMH implementations. The expectation is that this base format would be augmented by community-specific vocabularies.

Our natural inclination was to mirror the article descriptions which we already circulate in our RSS feeds and within our HTML pages (as META tags) and PDF files (as XMP packets). In these cases we have used open data models (e.g. RDF) with simple properties cherry-picked from the DC and PRISM namespaces. But OAI-PMH has a special ‘gotcha’ in this regard: any metadata format must allow for W3C XML Schema validation. That is, the properties need to be constrained by an XSD data model. Enter PRISM Aggregator Message (PAM).

(Continues)

For the longest time I must confess I did not ‘get’ what PAM was about. PRISM was clearly a metadata vocabulary and yet with PAM there was all this wrangling with content, which as an academic publisher we frankly had no interest in as we already had our own journal article DTD and for interop we were beginning to look at NLM DTD. And then it dawned on me (albeit slowly) that the PAM DTD is the equivalent to NLM DTD but for trade magazine publishing, where there might not be such a strong practice of XML. And since the release of PRISM 2.0 (February 2008) there was now also an W3C XML Schema defined for PAM. (Note that the latest revision of PRISM 2.1 is about to be published, although the changes there do not have any bearing on this implementation.)

So, PAM defines PRISM elements to be used with XML content markup. Examining further reveals that within a PAM message there are one or more articles with metadata packaged into a head section, and content (if present) in a body section.

Section 4.3 in the PAM 2.0 specification lists the allowable head elements by logical grouping, 11 in all: key elements, title, creative origin, publication, publication date, additional article ID, positional, topic, length, related content, rights & usage. Note that not all PRISM elements are supported; in fact only 43 of the 57 PRISM 2.0 elements are supported. Among the missing are ‘prism:endingPage‘. Also only 7 of the 15 DC elements are supported. Nevertheless we found that the bulk of the article descriptions could easily be accommodated within the PAM format. And because this is W3C XML Schema constrained there is an element ordering prescribed, and hence there is an interleaving of DC and PRISM elements.

The Nature.com OAI-PMH service has two access points:

User interface:: http://www.nature.com.pluma.sjfc.edu/oai
Service endpoint:: http://www.nature.com.pluma.sjfc.edu/oai/request

So, to work an example, if we want to get the record for doi:10.1038/nature01234 (which has an OAI-PMH identifier of oai:nature.com:10.1038/nature01234) we could use this call to get the description in PAM format:

http://www.nature.com.pluma.sjfc.edu/oai/request?verb=GetRecord&identifier=10.1038/nature01234&metadataPrefix=pam

(Note that as a convenience for the user we also allow a DOI to be used directly in place of the full OAI-PMH identifier as there is a one-to-one correspondence between the two within our repository. Simplifies cut and paste operations.)

This returns the following properties (shown in document order and by PAM logical grouping):

With PAM we are thus able to replicate in OAI-PMH the same journal article descriptions that we are currently disseminating through other service/content channels.

Crossref Citation Plugin (for WordPress)

Crossref — Sat, 09 Feb 2008 00:00:00 +0000

OK, after a number of delays due to everything from indexing slowness to router problems, I’m happy to say that the first public beta of our WordPress citation plugin is available for download via SourceForge. A Movable Type version is in the works.

And congratulations to Trey at OpenHelix who became laudably impatient, found the SourceForge entry for the plugin back on February 8th and seems to have been testing it since. He has a nice description of how it works (along with screenshots), so I won’t repeat the effort here.

Having said that, I do include the text of the README after the jump. Please have a look at it before you install, because it might save you some mystification.

Description

A WordPress plugin that allows you to search Crossref metadata using citations or partial citations. When you find the reference that you want, insert the formatted and DOI-linked citation into your blog posting along with supporting COINs metadata. The plugin supports both a long citation format and a short (op. cit.) format.

Warnings, Caveats and Weasel Words

Please note the following about this plugin:

We are releasing this as a test. It is running on R&D equipment in a non-production environment and so it may disappear without warning or perform erratically. If it isn’t working for some reason, come back later and try again. If it seems to be broken for a prolonged period of time, then please report the problem to us via sourceforge.
There is currently a 20 item limit on the number of hits returned per query. This might seem arbitrary and stingy, but please remember- we are not trying to create a fully blown search engine- we’re just trying to create a citation lookup service. Of course, if, after looking at how the service is used, it looks like we need to up this limit, we will.
If you look in the plugin options (or at the code), you will see that the system includes an API key. At the moment we have no restrictions on use of this service, but have included this in case we need to protect the system from abuse.
The bulk of the functionality we have developed is actually at the back-end. This plugin is just a lightweight interface to that back-end. You can examine the guts of the plugin in order to easily figure out how to create similar functionality for your favorite blog platform, wiki, etc. If you do create something, please let us know. We’d love to see what people are building.
We are continuing to experiment with the metadata search function in order to increase its accuracy and flexibility. Again, this might result in seemingly inconsistent behavior. Did we mention that this is a test?
Please note that this API is not meant for bulk harvesting of Crossref metadata. If you need such facilities, then please look at our web site for information about our metadata services.
The data currently behind the plugin is *just* a December 2007 snapshot of our our complete journal article metadata. We have not added books or proceedings yet. We will do so soon and we will start updating the metadata weekly.

We welcome your ideas for tools that we can provide to help researchers. Please, please, please send comments, requests, queries and ideas to us at:

citation-plugin@crossref.org

connecting things: bioGUID, iSpiders and DOI

Ed Pentz — Fri, 07 Sep 2007 00:00:00 +0000

David Shorthouse and Rod Page have developed some great tools for linking references by tying together a number of services and using the Crossref OpenURL interface amongst other things. See David’s post - Gimme That Scientific Paper Part III and Rod’s post on OpenURL and using ParaTools - “OpenURL and Spiders“.

Unfortunately our planned changes to the Crossref OpenURL interface (the 100 queries per day limit in particular) caused some concern for David (“Crossref Takes a Step Back“) - but make sure you read the comments to see my response!

We decided to drop the 100 per day query limit for the OpenURL interface and there will be no charges for non-commercial use of the interface - https://apps-crossref-org.pluma.sjfc.edu/requestaccount/

We want to encourage innovative uses of Crossref services and disseminate DOIs as effectively as possible so we appreciate feedback and encourage the type of development David and Rod are doing. It will be interesting to see if what they are doing has wider applicability. Maybe Crossref could host a webpage to point to tools like this and encourage more development?

Microsoft to Support OpenID

Crossref — Thu, 08 Feb 2007 00:00:00 +0000

Kim Cameron, Microsoft’s Identity Czar and member of the Identity Gang, comments on Microsoft’s announcement that they will support OpenID. Another sign that federated identity schemes are gaining traction and OpenID is likely to emerge as a standard the publishers are going to want to grapple with soon.

This follows Doc Searl’s comments on the notion of “Creator Relationship Management” where he speculates that the techniques being used in federated identity schemes and the Creative Commons can be combined to create a new “silo-free” value chain amongst creators, producers and distributors.