Identifiers on Crossref

Integrating grant metadata for seamless research interconnectivity at FCCN|FCT

Rocío Gaudioso Pedraza — Wed, 15 Oct 2025 00:00:00 +0000

Click here for the version in Portuguese

Welcome back to our series of case studies of research funders using the Grant Linking System. In this interview, I talk with Cátia Laranjeira, PTCRIS Program Manager at FCCN|FCT, Portugal’s main public funding agency, about the agency’s approach to metadata, persistent identifiers, Open Science and Open Infrastructure. With a holistic approach to the management, production and access to information on science, FCCN|FCT’s decision to implement the Grant Linking System within their processes was not simply a technical upgrade, but a coordinated effort to continue building a strong culture of openness. With the mantra “register once, reuse always”, FCCN|FCT efforts to embrace open funding metadata was only logical.

Could you introduce your organisation?

We are FCCN, the digital services of the FCT, the Foundation for Science and Technology, which is the main public funding agency in Portugal. FCT supports research and innovation in Portugal through multiple funding instruments targeting researchers, projects, institutions and international partnerships. FCCN is focused on providing digital services to the scientific and academic community in Portugal.

I am the manager of a program called PTCRIS, part of the FCCN, within the ‘Scientific Knowledge’ pillar of the unit. PTCRIS is a broad program, whose main goal is to fulfill the mantra ‘register once, reuse always’. We aim to develop an integrated ecosystem of scientific information, so all the projects we run have this main goal and that’s what we work towards. We develop infrastructure and added-value services, such as the scientific curriculum vitae management platform and an indicator system that exposes information of all the funding that supports research and innovation in Portugal.

What motivated you to join Crossref?

We had already adopted ORCID and we also developed a national PID, connected to the citizen card additional to ORCIDs. In 2015 we adopted the ISNI and we also had DOIs for research outputs. So we were clearly missing one piece, which was metadata for funding. At the same time we started developing a national infrastructure on science and technology funding, to have an aggregated and holistic view of the funding that is distributed in Portugal.

Before that the information was scattered across different databases and websites from many different funders, so we organised and aggregated this information into a platform called SciPROJ, which brings together all the information on scientific funding in one place, with quick and flexible access. But we didn’t have persistent identifiers for grants, and this was at the same time that Crossref started to build the Grant Linking System, so we were actually one of the first organisations to join, and in 2023 we had a pilot, where we registered 6000 grants, and we have been registering funding metadata ever since.

Can you tell us about your experience using the Grant Linking System?

The beginning of the pilot was the most critical stage of the process; some effort was needed to map our data models to the Crossref grant metadata schema. FCCN wasn’t in a bad position to do this since we already had all that information in a registry and it was well organised, we just had to map them to make sure that the information we had could be shared following the Crossref metadata schema and best practices. It has been two years since the pilot, which puts us in phase 2 of the implementation of the system. During the pilot we concentrated on registering both historical and current grants’ metadata, in the current phase, we are focusing on current grants’ metadata.

What do you find useful about registering grant metadata with Crossref?

Although this is the very beginning of this journey, we envision a world where we have the ability to link grants to any other object and entity that comprises the ecosystem: people that execute that funding, projects, institutions, outputs. Outputs are something particularly important to us, like for many other funders, because we want to be able to monitor the impact of our funding and that is something that is always at the back of our mind.

We are actually developing more and more services that aim to show how these links can be very useful to retrieve information from the system. For example, we are developing an indicator system that is focusing on the funding but also on the outputs and the links between the two. We are also monitoring OA trends, to see how FCT funding is contributing to Open Science initiatives.

Additionally, our OA policy was recently launched but we currently don’t have any system that allows us to track policy compliance. We are working towards that, but to achieve this it is absolutely fundamental that grants are linked to the outputs through metadata.

What are your hopes for the GLS and greater transparency in funding metadata in general?

The interconnectivity and interoperability of entities and objects, which is something that the field of scientific information management has always wanted to do, but that it’s very difficult to do. There have been attempts in the past to achieve this using information from the acknowledgement sections of publications, but this is fairly inefficient and there needs to be more structure to it. A critical piece of this puzzle would be to influence publishers, manuscript submission platforms to facilitate the systematic sharing of grant IDs and grant metadata by design. I think this is something that is still missing and that I would like to see happening soon.

Has anything surprised you while implementing the Grant Linking System?

Something that we have seen that was surprising was that researchers, who in general are not that concerned about PIDs, when it came to grant IDs, they would ask us proactively what the Crossref grant ID for their award was! It was very refreshing to see that we didn’t need to do any advertising to socialize Crossref grant IDs among our grant holders. I think that tells you about the high level of awareness there is within our community of the importance of the Crossref grant ID, using it and putting it in the acknowledgment section of their publications.

Based on your experience, what would be your advice for colleagues from other research funders?

I would say go for it! The more the merrier! This is like any other similar information system – it only works if there are enough people using it, registering grants metadata that facilitate the links between objects.

It is a very easy process to get into. Once you map the metadata schema to your own data it’s not a technically difficult thing to do. For us it’s an automated process that runs very smoothly, from grant registration to communicating this information to grant holders. We can see this in action in this example: the grantee published an article that acknowledges their funding through Crossref’s grants IDs or funding received being acknowledged in the website of a Research Center.

If you could change something about the GLS or how the grant metadata you register is used, what would it be?

I would love to have access to a visualization of grants’ metadata, how many outputs are linked to, and how they relate to other objects and entities. That would really give us a clearer understanding of the impact that our funding is having. We’d also love to see better integration between Crossref and ORCID for grants—just like it works for publications. Ideally, when a grant is registered and linked to a researcher, they’d be notified and could easily add it to their ORCID record. This would allow the information to flow seamlessly into their national CV via PTCRISsync, ensuring consistency and reducing manual work.

We are grateful to Cátia Laranjeira and FCT|FCCN for sharing their perspective and long-standing experience in this space. Their experience highlights the role that funding metadata plays in an interconnected and complete research and funding ecosystem.

Version in Portuguese

Translation by Edilson Damasio

Integração de metadados de financiamento pela FCCN|FCT para reforçar a interoperabilidade da informação sobre a atividade científica

Bem-vindo(a) de volta à nossa série de estudos de caso sobre instituições financiadoras de investigação que utilizam o Grant Linking System. Nesta entrevista, conversamos com Cátia Laranjeira, gestora do programa PTCRIS na FCCN|FCT, a principal agência pública de financiamento à ciência em Portugal, sobre a abordagem da instituição aos metadados, identificadores persistentes, Ciência Aberta e Infraestruturas Abertas.

Com uma abordagem holística à gestão, produção e acesso à informação científica, a decisão da FCCN|FCT de integrar o Grant Linking System nos seus processos não representou apenas uma evolução técnica, mas sim um esforço coordenado para consolidar uma forte cultura de abertura. Sob o lema “registar uma vez, reutilizar sempre”, a adoção de metadados abertos de financiamento pela FCCN|FCT foi um passo natural e coerente com essa visão.

Poderia apresentar a sua organização?

A FCCN é a unidade de serviços digitais da FCT — Fundação para a Ciência e a Tecnologia, a principal agência pública de financiamento à ciência em Portugal. A FCT apoia a investigação e a inovação através de diversos instrumentos de financiamento dirigidos a investigadores, projetos, instituições e parcerias internacionais. A FCCN dedica-se a disponibilizar serviços digitais à comunidade científica e académica portuguesa.

Na FCCN|FCT, sou gestora do PTCRIS, um programa integrado no pilar do Conhecimento Científico. O PTCRIS é um programa abrangente que tem como objetivo central concretizar o princípio “registar uma vez, reutilizar sempre”. Trabalhamos para desenvolver um ecossistema integrado de informação científica, e todos os projetos que conduzimos convergem nesse propósito. Desenvolvemos infraestruturas e serviços de valor acrescentado, como a plataforma de gestão do currículo científico CIÊNCIAVITAE e um sistema de indicadores que disponibiliza informação sobre todos os financiamentos que apoiam a investigação e a inovação em Portugal.

O que motivou a adesão à Crossref?

A FCCN tinha já adotado o ORCID e desenvolvido um identificador nacional persistente (PID), ligado ao cartão de cidadão, como complemento aos ORCIDs. Em 2015, adotámos o ISNI e também tínhamos DOIs para a produção científica. Ficava claramente em falta um elemento: os metadados de financiamento.

Ao mesmo tempo, iniciámos o desenvolvimento de uma infraestrutura nacional de financiamentos de ciência e tecnologia, com o objetivo de ter uma visão agregada e holística do financiamento que suporta a investigação e inovação em Portugal.

Antes disso, a informação estava dispersa por diferentes bases de dados e websites de múltiplos financiadores. Organizámos e agregámos esta informação numa plataforma chamada SciPROJ, que reúne toda a informação sobre financiamentos científicos num único local, com acesso rápido e flexível. No entanto, ainda não existiam identificadores persistentes para os financiamentos, coincidindo com o momento em que a Crossref começou a desenvolver o Grant Linking System. Fomos, assim, uma das primeiras organizações a aderir. Em 2023, realizámos um piloto com 6.000 financiamentos registados, e desde então temos vindo a registar continuamente os metadados de financiamento.

Pode falar-nos sobre a sua experiência com o Grant Linking System?

A FCCN iniciou a utilização do Grant Linking System com um piloto, que constituiu a fase mais crítica do processo. Foi necessário algum esforço para mapear os nossos modelos de dados para o esquema de metadados de financiamentos da Crossref. A FCCN estava, no entanto, bem posicionada para isso, uma vez que já dispunha de toda a informação num registo organizado; o passo necessário foi apenas assegurar que esta informação pudesse ser partilhada de acordo com o esquema de metadados da Crossref e as melhores práticas.

Já passaram dois anos desde o piloto, o que nos coloca na fase 2 de implementação do sistema. Durante o piloto, focámo-nos no registo de metadados de financiamentos históricos e atuais; na fase atual, estamos focados no registo de metadados de financiamentos atuais.

O que considera útil no registo de metadados de financiamento na Crossref?

Embora este seja ainda o início deste percurso, a FCCN idealiza um ecossistema em que seja possível ligar financiamentos a qualquer outro objeto ou entidade do sistema científico — projetos, pessoas que executam esses financiamentos, instituições onde são executados e produções científicas que dele resultam. Estes últimos são particularmente importantes para nós, como para muitos outros financiadores, pois queremos monitorizar o impacto do financiamento — uma preocupação que está sempre presente no nosso trabalho.

Estamos, de facto, a desenvolver serviços que demonstram o valor dessas ligações para a recuperação de informação no sistema. Um exemplo é o sistema de indicadores em desenvolvimento, que se centra nos financiamentos, nas produções científicas e nas relações entre ambos. Estamos também a acompanhar as tendências de Ciência Aberta, para perceber de que forma o financiamento da FCT está a contribuir para as iniciativas de Open Science.

Além disso, a política de Acesso Aberto da FCT foi recentemente lançada, mas ainda não dispomos de um sistema que permita monitorizar a conformidade com essa política. Estamos a trabalhar nesse sentido, mas para o concretizar é absolutamente essencial que consigamos associar inequivocamente os financiamentos às produções científicas através de metadados.

Quais são as suas expectativas para o GLS e para uma maior transparência dos metadados de financiamento em geral?

A interconectividade e interoperabilidade entre entidades e objetos é algo que a área da gestão de informação científica sempre procurou alcançar — embora seja um objetivo difícil de concretizar. No passado, houve várias tentativas nesse sentido, recorrendo à informação presente nas secções de agradecimentos das publicações, mas esse método revelou-se pouco eficiente e carece de uma estrutura mais sistemática.

Uma peça essencial deste puzzle seria influenciar as editoras e as plataformas de submissão de manuscritos a facilitarem a partilha sistemática de identificadores e metadados de financiamento. Este é um elemento que ainda falta concretizar, mas que gostaríamos de ver implementado em breve.

Algo o surpreendeu durante a implementação do Grant Linking System?

Algo que nos surpreendeu durante a implementação do Grant Linking System foi a reação dos investigadores. Normalmente, os investigadores não demonstram grande preocupação com identificadores persistentes (PIDs), mas, neste caso, começaram a procurar ativamente o identificador Crossref do seu financiamento! Foi muito positivo perceber que não foi necessário fazer qualquer esforço de divulgação para promover o uso dos Grant IDs da Crossref entre os beneficiários dos financiamentos. Isso mostra o nível de consciência existente na comunidade científica sobre a importância destes identificadores — usá-los e incluí-los na secção de agradecimentos das publicações.

Com base na sua experiência, qual seria o seu conselho para colegas de outros financiadores de investigação?

Com base na nossa experiência, o conselho para outros financiadores seria simples: avancem! Quanto mais, melhor! Este tipo de sistema de informação só é verdadeiramente eficaz quando há muitas entidades a utilizá-lo, a registar metadados de financiamento e a criar ligações entre objetos.

É também um processo simples de implementar. Uma vez feito o mapeamento entre o esquema de metadados e os dados internos da instituição, não há grandes desafios técnicos. No nosso caso, o processo é totalmente automatizado e flui de forma eficiente, desde o registo do financiamento até à comunicação dessa informação aos beneficiários. É possível ver isso em prática em vários exemplos — desde artigos que reconhecem o financiamento através dos Grant IDs da Crossref até ao reconhecimento do apoio financeiro nos sites dos centros de investigação.

Se pudesse alterar algo no GLS ou na forma como os metadados dos subsídios que regista são utilizados, o que seria?

Se pudéssemos mudar algo no Grant Linking System ou na forma como os metadados de financiamento são utilizados, gostaríamos de ter acesso a uma visualização interativa que mostrasse quantas produções científicas estão ligadas a cada financiamento e como esses se relacionam com outras entidades e objetos. Isso permitiria compreender de forma muito mais clara o impacto real dos financiamentos.

Gostaríamos também de ver uma melhor integração entre a Crossref e o ORCID no que respeita aos financiamentos — tal como já acontece com as publicações. Idealmente, quando um financiamento fosse registado e associado a um investigador, este seria notificado e poderia adicioná-lo facilmente ao seu registo ORCID. Assim, a informação fluiria automaticamente para o currículo nacional via PTCRISsync, garantindo consistência e reduzindo o trabalho manual.

Agradecemos à Cátia Laranjeira e à FCT|FCCN por partilharem a sua perspetiva e longa experiência neste domínio. A sua experiência destaca o papel que os metadados de financiamento desempenham num ecossistema de investigação e financiamento interligado e completo.

Connecting the dots: FWFs transition to linked grant metadata to support a thriving culture of openness

Rocío Gaudioso Pedraza — Wed, 23 Jul 2025 00:00:00 +0000

Click here for the version in German

As a new Community Engagement Manager at Crossref, dedicated to working with the funders community, I frequently hear requests for examples and case studies of adopting Crossref’s Grant Linking System (GLS) by ‘funders like us’. This has spurred me to start a series of blog posts presenting funders’ perspectives on joining Crossref and using our system – to demonstrate how it’s done.

In the first case study of a series, I speak with Katharina Rieck, Open Science Manager at the Austrian Science Fund (FWF), Austria’s national funding agency for basic research, about the agency’s approach to research metadata, transparency and openness, and the role that the Grant Linking System plays in it.

With a strong track record in Open Access and Open Science, the FWF’s decision to implement grant IDs represents more than a mere technical upgrade. What began as an initiative to enhance the openness and interoperability of grant information illustrates that truly open research infrastructure is not solely a matter of systems, but about people, policies and collaboration.

Katharina was also elected to the Crossref Board at our November 2024 Annual Meeting, and started her three-year term in January 2025.

Could you introduce your organisation? And what is your role?

The Austrian Science Fund (FWF) is Austria’s national funding agency for basic research. The FWF funds all disciplines, from Social Sciences and Humanities to Life Sciences and Natural Sciences and Technology. As Open Science Manager, I am responsible for developing the FWF’s Open Science strategy, including the development of the Open Access Policy for Peer-Reviewed Publications, the Open Access Policy for Research Data as well as the FWF Research Data Management Policy. I am also responsible for the development and implementation of funding instruments such as the FWF Open-Access Block Grant and support for Open Science infrastructures.

What motivated you to join Crossref?

For more than two decades, the FWF has actively promoted and supported various aspects of Open Science. In 2004, it published its first Open Access Policy, making it one of the first funding organizations worldwide to adopt an Open Access policy for publications. In line with the commitment to open research information as a core pillar of Open Science, the FWF has taken further steps to strengthen openness and transparency: it joined Crossref to register grant DOIs and became a signatory of the Barcelona Declaration on Open Research Information and joined Crossref to register grant DOIs.

While funding metadata––information about projects funded by the FWF––has long been freely available on our website, the launch of the Research Radar in 2023 marked a significant step forward. Our goal was not only to maintain accessibility but to ensure that the data published in the Research Radar is interoperable and aligned with the FAIR principles. By implementing the Grant Linking System from Crossref, we assign each FWF funded project a unique, persistent identifier with associated metadata, helping to make FWF grant information open, interoperable and sustainable.

Can you tell us about your experience using the Grant Linking System?

We have been using the Grant Linking System since November 2023. With the launch of the FWF’s new website and the introduction of the Research Radar, we began registering Crossref grant IDs (DOIs) for all grants included in the Research Radar database. As a result, all FWF-funded projects dating back to 1995 are now uniquely identifiable. The process of registering grant metadata with Crossref is straightforward, and we have set up a smooth internal workflow that enables the registration of DOIs after the FWF’s funding decision.

It is important to note that implementing Crossref grant IDs involved more than just a technical setup––it required the development of new internal processes and coordination through a dedicated Crossref grant DOI implementation group. The implementation process also resulted in a revised structure for grant numbers (DOI suffixes) for FWF-funded projects, establishing a sustainable and future-proof system.

How was your journey to socialise the Grant Linking System within your research community? How did you communicate the importance of identifiers and grant metadata to your grant holders?

The introduction of grant DOIs was supported by a comprehensive communication strategy, including dedicated online resources (e.g., New Identification Numbers for FWF Projects –– FWF), updates across multiple pages of the FWF website (such as Carrying out Your Project –– FWF), and presentations at various events. This communication strategy aimed to explain the purpose and value of the “new numbers” ensuring that researchers and stakeholders understood how this contributes to greater visibility, traceability, and openness of funded research.

As a funding organisation, we require grant recipients to acknowledge FWF support in all research outputs resulting from their projects. With the integration of grant DOIs into FWF’s metadata, the standardised acknowledgment text was updated to ensure that the DOIs are now included in outputs. The new required wording is: ‘This research was funded in whole or in part by the Austrian Science Fund (FWF) [grant DOI],’ and is now a requirement in the FWF funding agreement. Including the grant DOI both in the output metadata and the acknowledgment text enhances traceability and supports more effective analysis of FWF-funded outputs.

What do you find useful about registering grant metadata with Crossref?

One of the key benefits of registering grant metadata is the enhanced interconnectivity and the unique identification of FWF’s grant information. By registering our grants with Crossref, funding information becomes more than just information on the FWF website––it becomes interoperable data that is accessible and reusable. This not only increases visibility but also enables us to better analyse the outcomes of funded projects and ensures that the data is accessible as well as (re)usable by the broader research community.

In addition to assigning Crossref Grant IDs and registering grant metadata, the FWF has required ORCID IDs for researchers since 2016 and mandates the use of ROR IDs for institutions. The consistent use of persistent identifiers in metadata ensures the interoperability of FWF grant information and facilitates seamless integration with external data sources.

What are your hopes for the GLS and greater transparency in funding metadata in general?

The FAIRness and openness of research information––including metadata on funding information, research outputs, researchers, and institutions––are fundamental to a well-functioning research ecosystem. I hope to see a broader adoption of persistent identifiers in metadata, particularly in grant information, as well as a broader commitment to openly sharing research information as expressed in the Barcelona Declaration. Moreover, a key objective should be to ensure the highest possible accuracy of metadata at the point of entry. This entails, for instance, that publication metadata accurately includes funding metadata.

What were the key challenges you encountered when embracing the GLS, and how did you overcome them?

One of the key challenges we encountered when adopting the GLS was ensuring seamless integration in our existing IT infrastructure and workflows. Integrating the new number across different systems required considerable coordination. We overcame this challenge by establishing a dedicated implementation team that included IT experts.

Another challenge involved communicating and disseminating information regarding the grant DOI, ensuring that researchers and other relevant stakeholders were adequately informed. This was successfully managed through targeted and comprehensive communication efforts.

Based on your experience, what would be your advice for colleagues from other research funders?

It is important to recognise that registering grant identifers and metadata goes beyond a mere technical implementation. This is an opportunity to engage with diverse stakeholders, rethink processes and highlight the value of open funding metadata for the entire research community.

We are grateful to Katharina Rieck and FWF for generously sharing their insights and know-how. Their experience highlights the importance of seeing metadata not just as information, but as a shared resource that connects and empowers the research community.

Version in German

The title has been changed slightly from the original version. Translation by Lena Stoll.

Connecting the Dots: Wie der FWF durch die Umstellung auf vernetzte Fördermetadaten eine Kultur der Offenheit fördert

Als neue Community-Engagement-Managerin bei Crossref, die sich der Zusammenarbeit mit Fördergebern widmet, werde ich häufig gefragt, ob ich Beispiele und Fallstudien von „Förderern wie uns“ geben kann, die Crossrefs Grant Linking System (GLS) bereits eingeführt haben. Dies hat mich dazu veranlasst, eine Blogreihe zu starten, in der ich die Perspektiven von Fördergebern auf eine Crossref-Mitgliedschaft und die Nutzung unseres Systems vorstelle – um zu zeigen, wie es funktioniert.

In der ersten Fallstudie dieser Reihe spreche ich mit Katharina Rieck, Open-Science-Managerin beim Österreichischen Wissenschaftsfonds FWF, Österreichs nationaler Förderagentur für Grundlagenforschung, über den Ansatz des FWF zu Forschungsmetadaten, Transparenz und Offenheit sowie über die Rolle, die das Grant Linking System dabei spielt.

Mit seiner langjährigen Erfahrung im Bereich Open Access und Open Science stellt die Entscheidung des FWF, Grant-IDs (DOIs für Fördermittel) einzuführen, mehr als nur eine technische Verbesserung dar. Die Initiative begann mit dem Ziel, die Offenheit und Interoperabilität von Förderinformationen zu verbessern, aber schon bald wurde klar, dass eine wirklich offene Forschungsinfrastruktur nicht nur eine Frage der Systeme ist, sondern auch Menschen, Regelwerke, Abläufe und die Zusammenarbeit betrifft.

Katharina Rieck wurde auf unserer Jahresversammlung im November 2024 außerdem in Crossrefs Board of Directors gewählt und ist im Januar 2025 ihre dreijährige Amtszeit angetreten.

Bitte stellen Sie den FWF kurz vor und erklären Sie unseren Leser:innen, was Ihre Rolle dort ist.

Der Österreichische Wissenschaftsfonds FWF ist Österreichs nationale Förderorganisation für Grundlagenforschung. Der FWF fördert alle Disziplinen, von den Sozial- und Geisteswissenschaften über die Lebenswissenschaften bis hin zu Naturwissenschaften und Technik. Als Open-Science-Managerin bin ich für die Entwicklung der Open-Science-Strategie des FWF verantwortlich, einschließlich der Entwicklung der Open-Access-Policy für begutachtete Publikationen, der Open-Access-Policy für Forschungsdaten sowie der FWF-Richtlinie zum Forschungsdatenmanagement. Darüber hinaus bin ich verantwortlich für die Entwicklung und Umsetzung von Förderinstrumenten wie der Open-Access-Pauschale des FWF sowie die Unterstützung von Open-Science-Infrastrukturen.

Was hat Sie dazu bewogen, Crossref beizutreten?

Der FWF fördert und unterstützt seit mehr als zwei Jahrzehnten aktiv verschiedene Aspekte von Open Science. 2004 veröffentlichte er seine erste Open-Access-Policy und war damit eine der ersten Förderorganisationen weltweit, die eine Open-Access-Policy für Publikationen eingeführt haben. Im Einklang mit seinem Engagement für offene Forschungsinformationen als zentrale Säule von Open Science hat der FWF weitere Schritte unternommen, um Offenheit und Transparenz zu stärken: Der FWF ist Crossref beigetreten, um Grant-DOIs zu registrieren, und ist Unterzeichner der Barcelona Declaration on Open Research Information.

Zwar sind Metadaten zur Forschungsförderung – also Informationen über FWF-geförderte Projekte – schon seit Langem über unsere Website frei verfügbar. Doch die Einführung des Research Radar im Jahr 2023 war nochmal ein bedeutender Fortschritt. Unser Ziel war es nicht nur, den offenen Zugang zu den Metadaten aufrechtzuerhalten, sondern auch sicherzustellen, dass die im Forschungsradar veröffentlichten Daten interoperabel und mit den FAIR-Prinzipien vereinbar sind. Durch die Anwendung von Crossrefs Grant Linking System bekommt jetzt jedes vom FWF geförderte Projekt eine eindeutige, unveränderliche ID mit dazugehörigen Metadaten – und die Informationen zu FWF-Fördermitteln sind somit offen, interoperabel und nachhaltig verfügbar.

Können Sie uns mehr über Ihre Erfahrungen mit dem Grant Linking System erzählen?

Wir nutzen das Grant Linking System seit November 2023. Mit dem Launch der neuen FWF-Website und des Research Radar begannen wir damit, Crossref-Grant-IDs (DOIs) für alle in der Forschungsradar-Datenbank enthaltenen Förderungen zu registrieren. Dadurch sind nun alle FWF-geförderten Projekte seit 1995 eindeutig identifizierbar. Die Registrierung von Grant-Metadaten bei Crossref ist unkompliziert, und wir haben einen reibungslosen internen Workflow entwickelt, um DOIs nach der Förderentscheidung des FWF zu registrieren.

Es ist wichtig zu erwähnen, dass es für die Einführung von Crossref-Grant-IDs mehr als nur den Aufbau technischer Prozesse brauchte – wir haben auch neue interne Abläufe entwickelt und eine eigene Arbeitsgruppe für die Koordination von Crossref-Grant-DOIs gebildet. Im Zuge dieses Prozesses haben wir auch die Struktur der Projektnummern für FWF-geförderte Projekte (also der DOI-Suffixe) überarbeitet und somit ein nachhaltiges und zukunftssicheres System aufgebaut.

Welche Erfahrungen haben Sie damit gemacht, das Grant Linking System in Ihrer Forschungscommunity zu bewerben? Wie haben Sie Ihren Fördernehmer:innen die Wichtigkeit von Identifiern und Metadaten vermittelt?

Wir haben die Einführung der Grant-DOIs mit einer umfassenden Kommunikationsstrategie unterstützt, inklusive spezieller Online-Ressourcen (z. B. Neue Identifikationsnummern für FWF-Projekte), der Aktualisierung mehrerer Seiten auf der FWF-Website (z. B. Projekt durchführen) sowie Vorträgen bei diversen Veranstaltungen. Ziel dieser Kommunikationsstrategie war es, Zweck und Nutzen der „neuen Nummern“ zu erläutern und sicherzustellen, dass Forschende und Stakeholder verstehen, wie diese zu mehr Sichtbarkeit, Nachvollziehbarkeit und Offenheit der geförderten Forschung beitragen.

Als Förderorganisation verlangen wir von unseren Fördernehmer:innen, die Unterstützung durch den FWF in allen Forschungsergebnissen zu erwähnen, die aus dem Projekt resultieren. Mit der Integration der Grant-DOIs in die Metadaten des FWF haben wir den standardisierten Acknowledgement-Text aktualisiert, um sicherzustellen, dass die DOIs in den Ergebnissen erwähnt werden. Der neue erforderliche Wortlaut ist: „Diese Forschung wurde gänzlich oder teilweise durch den Wissenschaftsfonds FWF finanziert [Grant-DOI].“ und ist in jedem FWF-Fördervertrag festgeschrieben. Die Angabe von Grant-DOIs sowohl in den Metadaten als auch im Acknowledgement-Text von wissenschaftlichem Output verbessert die Rückverfolgbarkeit und ermöglicht eine genauere Analyse der vom FWF geförderten Ergebnisse.

Was finden Sie an der Registrierung von Fördermetadaten bei Crossref am hilfreichsten?

Einer der Hauptvorteile der Registrierung von Fördermetadaten ist die verbesserte Vernetzung und die eindeutige Identifizierung der Förderinformationen des FWF. Durch die Registrierung unserer Projekte bei Crossref werden Förderinformationen zu mehr als nur Informationen auf unserer Website – sie werden zu interoperablen Daten, die abrufbar und wiederverwendbar sind. Dies erhöht nicht nur die Sichtbarkeit, sondern ermöglicht uns auch eine bessere Analyse der Ergebnisse geförderter Projekte und stellt sicher, dass die Daten für die allgemeine Forschungsgemeinschaft zugänglich und (wieder-)verwendbar sind.

Neben der Vergabe von Crossref-Grant-IDs und der Registrierung von Fördermetadaten schreibt der FWF seit 2016 ORCID für Forschende sowie die Verwendung von ROR IDs für Institutionen vor. Die konsequente Verwendung persistenter IDs in den Metadaten gewährleistet die Interoperabilität der FWF-Förderinformationen und erleichtert die nahtlose Integration mit externen Datenquellen.

Was erhoffen Sie sich vom GLS und von mehr Transparenz bei Fördermetadaten im Allgemeinen?

Die FAIRness und Offenheit von Forschungsinformationen – einschließlich der Metadaten zu Förderinformationen, Forschungsergebnissen, Forschenden und Institutionen – sind für ein gut funktionierendes Forschungsökosystem wesentlich. Ich hoffe auf eine weiterreichende Anwendung von persistenten IDs in Metadaten, insbesondere in Förderinformationen, und auf ein größeres Engagement für den offenen Austausch von Forschungsinformationen, wie es zum Beispiel in der Barcelona Declaration on Open Research Information gefordert wird. Darüber hinaus sollte sichergestellt werden, dass die Metadaten bereits bei der Eingabe und damit bei ihrer Generierung möglichst korrekt sind. Das bedeutet unter anderem, dass die Metadaten von Publikationen die korrekten Fördermetadaten enthalten sollten.

Welche Herausforderungen sind bei der Einführung des GLS aufgetreten und wie haben Sie diese gemeistert?

Eine der größten Herausforderungen bestand darin, das Grant Linking System nahtlos in unsere bestehende IT-Infrastruktur und Arbeitsabläufe zu integrieren. Die „neue Nummer“ in die unterschiedlichen Systeme zu integrieren, bedeutete einen hohen Koordinationsaufwand. Gemeistert haben wir diese Herausforderung durch die Bildung einer eigenen Arbeitsgruppe für die Anwendung von Crossref-Grant-DOIs, in der auch IT-Expert:innen vertreten waren.

Eine weitere Herausforderung bestand in der Kommunikation und Verbreitung von Informationen zu Grant-DOIs, um Forschende und andere Stakeholder angemessen zu informieren. Das haben wir durch gezielte und umfassende Kommunikationsmaßnahmen erreicht.

Basierend auf Ihrer eigenen Erfahrung, welchen Ratschlag würden Sie Kolleg:innen bei anderen Fördergebern mitgeben?

Es ist wichtig zu verstehen, dass die Registrierung von Grant-IDs und Metadaten über eine bloße technische Umsetzung hinausgeht. Der Prozess bietet die Gelegenheit, mit verschiedenen Stakeholdern in Kontakt zu treten, Abläufe zu überdenken und den Wert offener Fördermetadaten für die gesamte Forschungsgemeinschaft zu unterstreichen.

Wir danken Katharina Rieck und dem FWF für ihre Bereitschaft, ihre Erkenntnisse und ihr Know-how so großzügig zu teilen. Ihr Erfahrungsbericht hat uns gezeigt, wie wichtig es ist, Metadaten nicht nur als Informationen zu betrachten, sondern als eine gemeinsame Ressource, die die gesamte Forschungsgemeinschaft vernetzen und stärken kann.

Come ROR with us: Using ROR IDs in place of Funder IDs

Patricia Feeney — Wed, 05 Mar 2025 00:00:00 +0000

Today, we’re delighted to let you know that Crossref members can now use ROR IDs to identify funders in any place where you currently use Funder IDs in your metadata. Funder IDs remain available, but this change allows publishers, service providers, and funders to streamline workflows and introduce efficiencies by using a single open identifier for both researcher affiliations and funding organisations.

As you probably know, the Research Organization Registry (ROR) is a global, community-led, carefully curated registry of open persistent identifiers for research organisations, including funding organisations. It’s a joint initiative led by the California Digital Library, Datacite and Crossref launched in 2019 that fulfills the long-standing need for an open organisation identifier.

In 2023, we shared our plan to transition the Open Funder Registry into ROR. More recently, we announced that we were planning to update our schema so that it is possible to collect ROR IDs where we currently collect Funder IDs such as in the funding metadata section for works and funder section for grants. Now that we have completed this work, Crossref members can start depositing ROR IDs where they would normally deposit Funder IDs. This update also means that the community, including funders, service providers, researchers, and data scientists can retrieve this metadata via our API.

So come and ROR with us and start depositing ROR IDs for both researcher affiliations and funding organisations.

Open Funder Registry-ROR transition

This is of course a significant first step in the Open Funder Registry to ROR transition.

We’ve always said that we would continue supporting Funder IDs in our schema and in our tools and services until the community is ready to transition - and we will. In the last year, Crossref and ROR conducted a series of Open Funder Registry user interviews to help us understand how it was being used and identify practical challenges to this transition in our members’ workflow (thank you to those who took part, it was incredibly useful!).

One major takeaway from this consultation was around the pivotal role that peer review management systems played in the Open Funder Registry-ROR transition. We look forward to seeing more service providers integrating with ROR in the future. If you are a service provider and are ready to integrate with ROR, drop support@ror.org an email.

Including ROR IDs in Crossref metadata

If you are ready to begin including ROR IDs in your funding metadata, you only need to include the ROR itself to identify a funder.

For example:

<fr:program name="fundref">
 <fr:assertion name="ror">https://ror.org/00fq5cm18</fr:assertion>
 <fr:assertion name="award_number">10.3030/725840</fr:assertion>
</fr:program>

Examples of more complex combinations of funding information are available in our documentation. This update has been made across all schema that support funding metadata.

Our grants schema has recently been updated to version 0.2.0 to support ROR IDs in place of funder identifiers as well. As with funding metadata, only the ROR ID needs to be supplied within the record:

<funding amount="750" currency="USD" funding-percentage="75" funding-type="APC">
 <ROR>https://ror.org/02twcfp32https://ror.org/02twcfp32</ROR>
 <funding-scheme>Sofa Lending Programme</funding-scheme>
</funding>

Although previously a funder name was collected with the funder identifier, for both grants records and funding data in an attempt to avoid redundant, incorrect or conflicting metadata, now we’re accepting an identifier only as the ROR ID has an existing metadata record. The organisation name exists within the record in the ROR registry and the ROR record is the authoritative source of the name.

ROR IDs in JSON outputs

We have an existing legacy practice of representing Open Funder Registry IDs as just a DOI, but ROR IDs are represented in the JSON outputs as a full URL with id-type “ROR”, for example:

Funding metadata


 "funder": [
 {
 "award": [
 "10.3030/725840"
 ],
 "id": [
 {
 "id": "https://ror.org/02twcfp32",
 "id-type": "ROR",
 "asserted-by": "publisher"
 }
 ]
 }
 ],

Grant funder information


"funding": [
 {
 "type": "infrastructure",
 "award-amount": {
 "amount": 750.0,
 "currency": "USD",
 "percentage": 75
 },
 "funder": {
 "id": [
 {
 "id": "https://ror.org/02twcfp32",
 "id-type": "ROR",
 "asserted-by": "publisher"
 }
 ]
 }
 }
 ]
 }
 ],

If you have any questions or feedback, get in touch with us support@crossref.org !

Celebrating five years of Grant IDs: where are we with the Crossref Grant Linking System?

Kornelia Korzec — Mon, 01 Jul 2024 00:00:00 +0000

We’re happy to note that this month, we are marking five years since Crossref launched its Grant Linking System. The Grant Linking System (GLS) started life as a joint community effort to create ‘grant identifiers’ and support the needs of funders in the scholarly communications infrastructure.

The system includes a funder-designed metadata schema and a unique link for each award which enables connections with millions of research outputs, better reporting on the research and outcomes of funding, and a contribution to open science infrastructure. Our first activity to highlight the moment was to host a community call last week where around 30 existing and potential funder members joined to discuss the benefits and the steps to take to participate in the Grant Linking System (GLS).

Some organisations at the forefront of adopting Crossref’s Grant Linking System presented their challenges and how they overcame them, shared the benefits they are reaping from participating, and provided some tips about their processes and workflows.

The funding organisations whose experiences were shared included Wellcome, FCT (Foundation for Science and Technology, Portugal), and NWO (Dutch Research Council). They were joined by a new group of foundations, research councils, and private research funders from around the world—from Kenya to Singapore to Estonia—to have a first introduction to the GLS and connect them with colleagues who are further along on their journey.

We also heard about tools such as a new open source Crossref plugin for the Fluxx platform, grant management systems with in-built Crossref integrations such as ProposalCentral, Europe PMC GrantFinder which was first to implement the GLS on Wellcome’s behalf and hosts their grants, and one of the first publishers, eLife to start referencing Crossref grant links in their publications both online and in the open metadata for others to retrieve.

Read on for further information or watch the recording of the event.

What is the Crossref Grant Linking System?

The Crossref Grant Linking System, conceptualised in 2017, and launched in 2019, captures and helps clarify funding relationships for scholarly outputs. Thanks to interconnectedness with the 160 million metadata records collected and curated by Crossref members, it enables funders as well as scholars to track and analyse funding patterns and evaluate programmes, and it supports assertions about the integrity of scholarly records.

Features of the GLS

Globally unique persistent link and identifier for each grant
Connected with 160 million published outputs
Funder-designed metadata schema, including project, investigator, value, and award-type information
Programmatic or no-code methods to send metadata
- Thanks to the Gordon and Betty Moore Foundation who funded development of the online grant registration form
Open search and API for all to discover funding outcomes; all metadata is distributed openly to thousands of tools and services
Crossref-hosted landing pages
A global community of ~50 funder advisors and 35+ funders already in the Grant Linking System
Membership of Crossref; influence the foundational infrastructure powering open research

The last five years has seen the GLS grow through membership, metadata, and community contributions.

The momentum for this programme is building - as illustrated by increasing numbers of metadata records (and related relationships we’re seeing). The 35 funder members represent over 100 funding programmes and have created 125,000 grant records already.

During last week’s call, it was helpful to hear from the community what they see as key benefits of the Crossref Grant Linking System:

Meaningfully delivering on and supporting Open Science policies and mandates, and contributing ‘their bit’ to the transparency of the evidence trail in the scholarly ecosystem.
Reporting and evaluating the funding programmes, essential for the public funders who need to demonstrate the value for money in allocating their funds and other support.
Supporting a more holistic assessment of scholarship and scholars, especially as and when metadata becomes included with a full array of outputs, not limited to books and articles.

How the Crossref Grant Linking System supports Open Science policy

Since 2020, all the grant records are openly available through our REST API which is queried more than 1.8 billion times every month so these metadata records are distributed to thousands of systems across the research enteprise. In a 2022 blog, Ed Pentz and Ginny Hendricks laid out guidelines for research funders to meet open science guidelines using existing open infrastructure such as Crossref, ORCID, and ROR. Syman Stevens, a grantmaking and private philanthropy consultant, highlighted on the call that the funders he works with are increasingly interested in ways to deliver on their open science policy and that participation in the GLS is a tangible thing they can do to meet this goal.

As part of its open science policy, NWO will start participating in the Crossref Grant Linking System from July 2025. Research funders are a part of the scholarly communications system; we not only provide the funding to do the actual research but can also be the authoritative source of data about the projects we have funded and the outputs arising from that funding. Increasingly, all these elements – grants, researchers, outputs - are linked with metadata and unique identifiers to ensure that research is findable and accessible.

– Hans de Jonge, Director of Open Science NL, part of the Dutch Research Council (NWO)

How funders leverage the Grant Linking System in their reporting and assessment

Looking back to the origins of the system, it’s important to recognise the work of the initial working groups. Through their contribution, funders helped design the initial metadata schema for grants as well as establish the governance and fees for this service, and our Advisory Group continues to inform further developments. In this way, the Grant Linking System enables the needs and wishes of funders to contribute and see their data as part of the wider ecosystem.

An excellent example of that synergy in action is the use case presented by Cátia Laranjeira, manager of the PTCRIS programme at the Foundation for Science and Technology, Portugal (FCT). PTCRIS is the Foundation’s integrated national information ecosystem that supports scientific activity management. Cátia reflected on the relative fragmentation of spaces where the scientific outputs are found, and PTCRIS’s ambition for aggregating metadata in one place to be able to trace and evaluate programmes in light of the related outputs. At the start of the programme, they identified lack of a persistent identifier for grants as a major shortcoming of the system. Crossref GLS naturally fits in with their goals.

The initiative by FCT to assign unique DOIs to national public funding through Crossref is a game-changer for open science, linking funding directly to scientific outcomes and boosting transparency. Join us in this effort—let’s make every grant count and ensure open access to research information!"

– Cátia Laranjeira, PTCRIS Program Manager at Fundacao para a Ciencia e a Tecnologis (FCT Portugal)

FCT initially piloted a small subset of their grants (approximately 6,000 recent awards) at the end of 2023. Cátia pointed to researchers’ keen participation in this programme as one of its successes – and thanks to the word of mouth, FCT has already been approached by researchers requesting unique Crossref links for their grants! This appetite for grant IDs will soon be more fully satisfied, as FCT is readying to register all of their grants with Crossref, to enable further insights into funding and outcome flows, supporting them in demonstrating the value for money for the public resources they manage. Via interfaces for grant management and standardised online CVs, the system is also enabling researchers to use the system in their own future reporting and career development.

In the ensuing discussion, Rachel Bruce of UKRI mentioned that she’s hopeful that GLS will help funders ‘close the loop’ on more holistic reward and recognition, allowing for inclusion of evidence for a broader set of outputs in those processes.

How the community is working to integrate open infrastructure

Melissa Harrison, Team Leader at EMBL-EBI, manages Europe PMC and a complementary data science team, who were part of the initial FREYA project – supporting infrastructure delivery for unique identifiers for grants. The team has been adding grant records to Crossref on Wellcome’s behalf since 2019. Melissa highlighted the shortcomings of internal award numbers, which don’t tend to be understood outside of the ecosystem where they are produced (that is the funder’s administrative system), are almost certainly not unique, and don’t resolve to or connect with anything in the wider ecosystem. Therefore internal award numbers can’t signify relationships with other outputs or assets in the wider world. By contrast, Crossref’s Grant IDs are unique, persistent, resolvable, and interrelated with other Crossref metadata, whilst being retrievable for other systems to link to too.

Persistent identifiers for grants was the next logical step after identifiers for funders - open metadata registered with a PID in a central service like Crossref is invaluable to build the full picture of the research enterprise.

– Melissa Harrison, Team Leader, Literature Services at EMBL-EBI)

Ease of execution is important for scaling the Grant Linking System, and enabling its use in a diverse set of circumstances in the open science ecosystem. Altum was the trailblazer, first integrating its grant management platform Proposal Central with GLS. It was good to hear that others are now joining the integration efforts. Syman Stevens talked about the recent work initiated by Joe McArthur at OA Works, to develop a simple, open-source plug-in for any of the major grant management systems, to enable funders to deposit their grant metadata with Crossref GLS with a click of the button. Syman demonstrated the resulting interface in Fluxx, that allows for creating a record and sending grant metadata to Crossref as part of the regular grant management within the platform. He pointed out that, while this integration was developed for Fluxx, all code and documentation is openly available on GitHub and this can potentially be forked or adapted as necessary for reuse in other grant management systems.

It is heartening that others in the community are seeing such a need for this that they’re funding and creating their own tools to advance participation and use of the GLS.

Finally, Fred Atherden, Head of Production Operations at eLife, presented how they include Crossref grant identifiers in publication metadata for the version of record of the works published on their platform. eLife is the first publisher to fully integrate Crossref grant identifiers both within the article display and in the metadata. Fred shared that in addition to collecting the data from the authors, eLife also attempts matching, albeit using very restrictive methodology, to enable more grant metadata in their publication records. They recognise that so far there are very few publishers including persistent links for grants in this way, and talked about plans to start collecting and including this data further upstream, and including them in the future for reviewed preprints.

Acknowledgements and how to participate in the GLS

Reflecting on the last five years, thanks must go to the >35 funders who are already participating (see logo mashup below), to our current volunteers and to those partners working to promote and make use of the Grant Linking System. We also acknowledge that the GLS would not have been possible without the Crossref board members at the time, our staff including alumni Josh Brown, Jennifer Kemp, Rachael Lammey, and Geoffrey Bilder, or without the early dedicated time and input from the following people and organisations on our working groups for governance and fees, and for metadata modelling:

Yasushi Ogasaka and Ritsuko Nakajima, Japan Science & Technology Agency
Neil Thakur and Brian Haugen, US National Institutes of Health
Jo McEntyre and Michael Parkin, Europe PMC
Robert Kiley and Nina Frentop, Wellcome
Alexis-Michel Mugabushaka and Diego Chialva, European Research Council
Lance Vowell and Carly Robinson, OSTI/US Dept of Energy
Ashley Moore and Kevin Dolby, UKRI (Research Councils UK / Medical Research Council)
Salvo da Rosa, Children’s Tumor Foundation
Trisha Cruse, DataCite

To learn more about the Crossref Grant Linking System, the best place to start is our service page. And for the next step, please reach out to us for a conversation about any questions specific to your organisation and any questions that may need to be addressed in order to enable your full participation.

Grant DOIs enhance the discovery and accessibility of funded project information and are one of the important links in a connected research ecosystem. I’m grateful and proud to contribute to the robustness and interconnectedness of the research infrastructure. Few funders are currently participating in the Crossref Grant Linking System, and I encourage others to consider doing so. This adoption follows the “network effect,” where the value and utility increase as more people participate, encouraging even wider adoption.

– Kristin Eldon Whylly, Senior Grants Manager and Change Management Lead at Templeton World Charity Fund (TWCF)

You can email me via feedback@crossref.org or set up a call with me when it suits you (you can overlay your own calendar using the toggle at the top right). We look forward to welcoming even more funders and to see those relationships in the open science infrastructure grow even further in the coming years.

Open Funder Registry to transition into Research Organization Registry (ROR)

Amanda French — Thu, 07 Sep 2023 00:00:00 +0000

There is some overlap between the Open Funder Registry and the Research Organization Registry (ROR), and funders and publishers have been asking us whether they should use Open Funder Registry IDs or ROR IDs to identify funders when they appear in both registries. We aim to merge the two registries over time. We will ensure Crossref members can use ROR to simplify persistent identifier integrations, to register better metadata, and to help connect research outputs to research funders.

Just yesterday, we published a summary of a recent workshop between funders and publishers on funding metadata workflows that we convened with the Dutch Research Council (NWO) and Sesame Open Science. As the report notes, “open funding metadata is arguably the next big thing” [in Open Science]. That being the case, we think this is the ideal time to strengthen our support of open funding metadata by beginning the transition to ROR.

Comparing the features of ROR and the Open Funder Registry

Let’s look at some of the similarities and differences between the two registries, including their history, features, scope, and usage, since there are important nuances and distinctions that are helpful to understand.

Overview

ROR	Open Funder Registry
Launched in 2019	Launched in 2013
Primary use case is contributor affiliation	Primary use case is funding acknowledgement
105k+ records	35k+ records
CC0 data	CC0 data
REST API	REST API
Free to use	Free to use
Entire registry downloadable as JSON and CSV	Entire registry downloadable as RDF; funder names and IDs downloadable as CSV
Records contain mappings to other IDs	Records do not contain mappings to other IDs
few organisation relationships and hierarchy	multiple organisation relationships and hierarchy
organisation level with no funding programs/schemes	organisation level with some funding programs/schemes
8 organisation types	2 funder types, 8 funder subtypes
Open source code and multiple open-source tools available	Open source code
Web-based registry search	Web-based search for works in Crossref associated with each Open Funder Registry ID
Web-based landing pages for each ROR record	JSON landing pages for each Open Funder Registry record
Updated monthly	Updated bimonthly
Public curation process	Private curation process
Anyone can request changes and additions	Anyone can request changes and additions
Stable financial support (Crossref, DataCite, CDL)	Stable financial support (Crossref, Elsevier)
Beginning to be supported in funding and publishing workflows	Well supported in most funding and publishing workflows
Currently used by 260+ Crossref members ¹	Currently used by 2100+ Crossref members ²

History

The Open Funder Registry was launched as FundRef over a decade ago to enable the community to cite research funding and support and assert it within the scholarly record, acknowledging the organisations granting their support. Elsevier generously donated the seed data for the Open Funder Registry and has managed its curation for the last ten years, while we have maintained the technical operations and promoted community adoption of the Open Funder Registry.

The Research Organization Registry (ROR) was introduced in 2019 by the California Digital Library, DataCite, and Crossref to enable the community to cite contributor affiliations and assert them within the scholarly record, acknowledging the organisations that housed or performed the research. Digital Science generously donated the seed data for the Research Organization Registry from its Global Research Identifier Database (GRID) initiative, and Crossref, DataCite, and the California Digital Library have contributed labour and resources to turn ROR into a mature, independent, freely available service.

Scope

One key difference between the registries is that ROR has always included funding organisations, and ROR records have always included mappings to Funder IDs where available, while the reverse is not true: the Open Funder Registry includes only funding organisations, not other kinds of organisations, and Open Funder Registry records do not currently include mappings to ROR IDs or other identifiers. It therefore makes sense to expand our initial contributor affiliation use case for ROR to include the identification of organisations that fund and support research.

Usage

More Crossref members use Funder IDs than use ROR IDs, to be sure. You can see from the table above that the number of Crossref members using Funder IDs in Crossref records is higher by almost a factor of 10 than the number of Crossref members using ROR IDs in Crossref records. But note too that the current rate of adoption is far higher for ROR than it is for the Open Funder Registry. Since January of 2022, we’ve seen a gratifying number of publishers and service providers beginning to use ROR identifiers for contributor affiliations in Crossref. In the last year, the number of Crossref members depositing ROR IDs has increased by 356%, while the number depositing Funder IDs has increased only by 12%. As evidenced by its ballooning API traffic, too, with more than 20 million requests last month,³ ROR is clearly being used by many scholarly research systems for many purposes. The more systems that use an identifier, the more valuable that identifier becomes as a vehicle for exchanging information.

ROR’s primary use case is to identify contributor affiliations and is already being used by funders. Nineteen funding organisations are depositing ROR IDs in their grant records with Crossref to denote principal investigator affiliations,⁴ and, following a meeting of the our Funder Advisory Group last month, all eighty funder members are primed to start using ROR IDs to identify themselves in grant records.

Tools and services

Both the Open Funder Registry and ROR have open data and open source code, but we think that our suite of free and open source utilities for ROR gives it an advantage. We know that publishers and their service providers have ongoing challenges in collecting and matching funding information from authors and in validating Funder IDs. With our extensive ROR toolkit, publishers and their technology providers who adopt ROR will be in a better position to improve the accuracy of funding acknowledgements in metadata, which can in turn enable the development of reliable analytics, tools, and services for funders, regulators, research facilities, and the public.

Crossref has built tools based on OpenRefine for both the Open Funder Registry and ROR: the Open Funder Registry Reconciliation Service and the ROR Reconciler are both useful ways to clean messy data. ROR, however, also offers a much-used API endpoint that helps match organisation names to ROR IDs, and several third parties have also developed and shared open source matching tools and services for ROR. Crossref is also collaborating on new strategies for affiliation matching that will improve connections for funding acknowledgements.

Community engagement models

The Open Funder Registry has been curated for over a decade through time and expertise generously donated by Elsevier and is community-governed by Crossref and it’s membership and board. ROR offers more transparent community involvement and is jointly governed by Crossref, DataCite, and the California Digital Library. ROR is openly curated and is aided by a global Curation Advisory Board of volunteers.

What will this mean for you?

The many organisations whose tools, services, and workflows have been architected to use Open Funder Registry (OFR) IDs will find this transition a challenge, and we don’t want to make light of that issue. Over the last ten years, we have encouraged the community to adopt Funder IDs, and the community has demonstrably recognized the benefits of doing so. Publishers have put a great deal of time, thought, and effort into collecting funder data and including it in Crossref metadata, and they have built internal reports and workflows around the Open Funder Registry. Crossref is committed to making the transition from the Open Funder Registry to the Research Organization Registry as simple as possible for the community.

If you are not already using the Open Funder Registry and are planning to begin standardizing funding data, we recommend that you use ROR to identify funders. If you are currently using the Open Funder Registry in your systems and workflows, don’t worry! In the medium term, Open Funder Registry IDs aren’t going away. Eventually, however, the Open Funder Registry may cease to be updated. Funder IDs and their mapping to ROR IDs will be maintained, so if Crossref members submit a Funder ID, it will get mapped to a ROR ID automatically. Note, too, that Crossref is committed to maintaining the current funder API endpoints.

In short, if you are already using Funder IDs, you can and should continue to do so. However, we do recommend that you begin looking at what it will take to integrate ROR into your systems and workflows for identifying funders as well as affiliations.

We face challenges in this transition, too. Of these, we think the largest will be (1) completing the reconciliation work involved in mapping Funder IDs to ROR IDs, and (2) updating Crossref’s schemas, APIs, and deposit tools to support ROR IDs in many the ways we currently support Funder IDs. We’ll discuss both of these challenges in future blog posts.

Tell us what you need?

We want to hear from you. You can use our Community Forum talk to us about the Crossref Open Funder Registry or contact ROR staff at Crossref via our request form. You can attend online Crossref events, including ROR-specific webinars to get updates from us and ask us your questions.

One of the major messages we’re already hearing from funders and publishers is expressed in yesterday’s post on open funding metadata: “While many concluded that there was still a long way to go to solve the many technical challenges related to funding metadata, attendees were unanimous on its importance.” We look forward to beginning this important work together.

How funding agencies can meet OSTP (and Open Science) guidance using existing open infrastructure

Ed Pentz — Thu, 17 Nov 2022 00:00:00 +0000

In August 2022, the United States Office of Science and Technology Policy (OSTP) issued a memo (PDF) on ensuring free, immediate, and equitable access to federally funded research (a.k.a. the “Nelson memo”). Crossref is particularly interested in and relevant for the areas of this guidance that cover metadata and persistent identifiers—and the infrastructure and services that make them useful.

Funding bodies worldwide are increasingly involved in research infrastructure for dissemination and discovery. While this post does respond to the OSTP guidelines point-by-point, the information here applies to all funding bodies in all countries. It will be equally useful for publishers and other systems that operate in the scholarly research ecosystem.

In response to calls from our community for more specifics, this post:

Provides an overview of the specific ways that Crossref (along with organisations and initiatives like DataCite, ORCID, and ROR) helps U.S. federal agencies—and indeed any other funder—meet critical aspects of the recommendations.
Restates our intent to collaborate with all stakeholders in the scholarly research ecosystem, including the OSTP, the US federal agencies, our existing funder, publisher, and university members, to support the recommendation as plans develop.
References the work and adoption of Crossref Grant DOIs, including analyses of existing metadata matching funding to outputs.
Highlights that what’s outlined in the memo aligns with our longstanding mission to capture and maintain the scholarly record and our vision of the Research Nexus, as we describe in our current blog series, regarding our role in preserving the integrity of the scholarly record (ISR).

Infrastructure already exists to support funder goals; it just needs more adoption

Ensuring free, immediate, and equitable access to metadata that captures the scholarly record is an essential part of meeting the aims of the memo but also supporting Open Science globally.

In September, Crossref ORCID, DataCite, and ROR participated in the 2022 Forum on Global Grants Management run by Altum and the summary provides a good example of the importance of open infrastructure and open metadata to the goals of Open Science:

Open Science begins with open infrastructure: Attendees agreed that Open Science relies on many other ‘opens’ – most notably, open metadata, open infrastructure, and open governance. Metadata and DOIs (digital object identifiers) for publications, grants, and research outputs, are essential to illuminate the connections that exist between funding and outcomes. That metadata runs on infrastructure powered by organisations such as Crossref, ORCID, ROR, and DataCite.

As a foundational scholarly infrastructure committed to meeting the Principles of Open Scholarly Infrastructure (POSI) of governance, insurance, and sustainability, Crossref plays an essential role in implementing and supporting key aspects of the guidance. For many years, we have been focused on the integrity of the scholarly record (ISR), and the shared vision to collectively achieve what we call the Research Nexus, which is described as

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

Metadata—including persistent identifiers and relationships between different research objects—is the foundation of the Research Nexus and is critical to openly and sustainably fulfilling the OSTP memo’s recommendations.

This topic of open metadata and identifiers isn’t just an issue for research resulting from US federal funding. We are working to implement open scholarly infrastructure globally, bringing significant benefits to the whole scholarly research ecosystem.

The current situation brings to mind the William Gibson quote, “The future is already here - it’s just not evenly distributed yet”. Much of the open infrastructure to support the identifier, metadata and reporting requirements of the OSTP memo already exists, but it is unevenly implemented. Increased collaboration and effort will be needed to bring this all to fruition.

We set out below some steps that all stakeholders can take to meet not just the OSTP guidelines, but Open Science goals more broadly, and globally.

What does ‘adoption’ look like? How exactly do funders and other stakeholders work with this infrastructure?

The OSTP memo calls for specific actions concerning metadata and identifiers where, fortunately, open and global solutions already exist.

For example, item 4 a) says, “Collect and make publicly available appropriate metadata associated with scholarly publications and data resulting from federally funded research.” Crossref and DataCite make metadata, including persistent identifiers (DOIs to be specific), openly available for a broad range of research objects from publications to data. Item 4 b) reads, “Assign unique digital persistent identifiers to all scientific research and development awards and intramural research protocols”. Again, federal agencies and other funders are already joining to register awards and grants and distribute these records openly through Crossref. However, this is an example of uneven adoption as registering awards and grants with DOIs is only being done by a few funders so far, which needs to increase.

Here is an ideal workflow that funders and publishers can already follow

Funders join Crossref to register grants and awards (or indeed any other object such as reports). They apply on our website, accept our terms, and provide key information such as contact details. An annual membership fee ranges from $200-$1200 USD.
Funders and publishers collect ROR IDs and authenticated ORCID iDs for all authors/awardees and their affiliations.
Funders register a Crossref DOI for the award/grant, including awardees’ ORCID iDs and ROR IDs. They send us XML information about the grant (note that we will imminently release an online form to make it easier for the less technical funders). Many funder members register the metadata through a third party, such as Altum (if they use ProposalCentral) or Europe PMC.
At the same time, funders update the awardees’ ORCID record directly with the Crossref Grant DOI and metadata.
Grantees produce research objects and outputs such as data, protocols, code, preprints, articles, conference papers, book chapters, etc.
These objects are registered with Crossref or DataCite, and DOIs are created by the publisher or repository members who include ORCID iDs, Crossref Grant DOIs (gathered from the author), ROR IDs for affiliations for all contributors, and other key metadata such as licensing information, and in the case of publications - references and abstracts. Note that the publisher works its magic (actually, publishers do a lot of editorial and production work, such as including data citations in the references using DataCite DOIs for the data in data repositories).
On the Crossref side, we do a bunch of processing and matching and are planning to refine this and do more. Sometimes relationships are notified and added, such as data citation, preprints related to articles or funding acknowledgements converted from free text to Open Funder Registry IDs and names.
Grant records with Crossref DOIs are now part of the scholarly record. All stakeholders may retrieve the open metadata and relationships through our public APIs. Crossref and DataCite will always provide open metadata, as safeguarded by our respective commitments to POSI.

Anyone can use the open metadata registered with Crossref, DataCite and ORCID as connections have been established between (ideally all) research objects and entities through open metadata and identifiers. This means that:

Funding agencies can monitor compliance with their policies
Publishers can identify the funder and meet their requirements
Funding agencies can assess and report on the reach and return of their funding programs
The provenance and integrity of the scholarly record is preserved and discoverable, benefitting all stakeholders.

Suggestions for meeting OSTP and Open Science guidance, point by point

OSTP Recommendation	Publishers should…	Funding agencies should…
4 a) Collect and make publicly available appropriate metadata associated with scholarly publications and data resulting from federally funded research	For scholarly publications: register comprehensive metadata & DOIs with Crossref. For scholarly data: register comprehensive metadata and DOIs with DataCite.	Use Crossref’s API to retrieve publication and other metadata. Use DataCite’s API to retrieve data/repository metadata.
i) all author and co-author names, affiliations, and sources of funding, referencing digital persistent identifiers, as appropriate;	Collect and validate the following from authors at manuscript submission: ROR & ORCiD IDs, Crossref Grant DOIs. Include data citations in reference lists, preferably with DataCite DOIs.	Register awards and grants with Crossref and create DOI records for them. Use ORCID’s API to retrieve validated contributor metadata. Update contributors’ ORCID records with Crossref Grant DOIs and metadata. Use ROR API to retrieve and verify affiliation metadata. Recommend data citations be included in published outputs.
ii) the date of publication; and,	Include acceptance and publication dates in Crossref metadata.	Use Crossref’s API to retrieve publication dates.
iii) a unique digital persistent identifier for the research output;	For scholarly publications and research outputs: register full metadata & DOIs with Crossref. For scholarly data: register full metadata and DOIs with DataCite.	Use Crossref and DataCite APIs to retrieve DOIs for research outputs.
4 b) Instruct federally funded researchers to obtain a digital persistent identifier that meets the common/core standards of a digital persistent identifier service defined in the NSPM-33 Implementation Guidance, include it in published research outputs when available, and provide federal agencies with the metadata associated with all published research outputs they produce, consistent with the law, privacy, and security considerations.	Collect ORCID iDs on manuscript submission for all authors. Register Crossref and DataCite DOIs and metadata for research outputs, including data.	Recommend that researchers applying for funding obtain an ORCID iD and collect them upon grant application for all applicants. Prepopulate grant applications with CV and publication information from applicants’ ORCID records. ORCID iDs should be included in the grants registered by the agencies with Crossref. Agencies can use our open APIs to retrieve the metadata on publications and data rather than ask researchers to do it, saving time and effort.
4 c) Assign unique digital persistent identifiers to all scientific research and development awards and intramural research protocols that have appropriate metadata linking the funding agency and their awardees through their digital persistent identifiers.		Join Crossref to register Crossref Grant DOIs, including ROR IDs and ORCID iDs Ensure grant proposal and assessment systems integrate with Crossref, ROR for affiliations and with ORCID for applicants/awardees.
5 a) coordinate between federal science agencies to enhance efficiency and reduce redundancy in public access plans and policies, including as it relates to digital repository access;	Work with agencies to ensure a smooth, automated workflow.	Using and supporting existing open scholarly infrastructure and using open identifiers will avoid duplication of effort and make the overall ecosystem more efficient .
5 b) improve awareness of federally funded research results by all potential users and communities;	Collect Crossref Grant DOIs from authors and use them to link from publications to grant information.	Communicate your Crossref Grant DOIs and open grant metadata widely via human and machine interfaces. Inclusion in the Crossref API will enhance dissemination and discoverability Update contributors’ ORCID records with Crossref Grant DOIs and metadata
5 c) consider measures to reduce inequities in the publishing of, and access to, federally funded research and data, especially among individuals from underserved backgrounds and those who are early in their careers;		Registering grants and sharing metadata through Crossref means it’s part of the world’s largest open community-governed metadata exchange and makes it available to the entire world without restriction.
5 d) develop procedures and practices to reduce the burden on federally funded researchers in complying with public access requirements;	Ensure your systems and those you work with make it as easy as possible for authors to provide the necessary metadata and persistent identifiers - work towards as much automation as possible and pulling from other systems rather than asking for data to be re-keyed.	Ensure the platforms you work with, such as grant proposal or assessment systems, retrieve and prepopulate ROR IDs, ORCID iDs, and Crossref and DataCite DOIs and associated metadata whenever possible so that the researchers don’t have to manually rekey or reformat data.
5 e) recommend standard consistent benchmarks and metrics to monitor and assess implementation and iterative improvement of public access policies over time;		Ensure that platforms and systems integrate with ROR, ORCID, Crossref, and DataCite so that this open metadata can lead to the creation of benchmarks and metrics.
5 f) improve monitoring and encourage compliance with public access policies and plans;	Use open infrastructure to help authors easily comply with public access and funder/institution policies. Automate systems as much as possible.	Using the open infrastructure, metadata, and identifiers outlined in this post will make monitoring more straightforward and compliance easier for all stakeholders. The community can build services on open infrastructure and metadata.
5 g) coordinate engagement with stakeholders, including but not limited to publishers, libraries, museums, professional societies, researchers, and other interested non-governmental parties on federal agency public access efforts;	Work with the global open infrastructure organisations (Crossref, DataCite and ORCID) whose members include funding agencies, societies, publishers, universities, libraries, repositories, museums, NGOs, and many other stakeholders - all looking to improve the efficiency of the research ecosystem.	Work with the global open infrastructure organisations (Crossref, DataCite and ORCID) whose members include funding agencies, societies, publishers, universities, libraries, repositories, museums, NGOs, and many other stakeholders - all looking to improve the efficiency of the research ecosystem.
5 h) develop guidance on desirable characteristics of—and best practices for sharing in—online digital publication repositories;	Support automated systems that use metadata and identifiers to populate repositories automatically.	Collaborate with publishers, Crossref and others to develop automated systems to populate repositories.
5 j) develop strategies to make federally funded publications, data, and other such research outputs and their metadata are findable, accessible, interoperable, and re-useable, to the American public and the scientific community in an equitable and secure manner.	Provide and support a range of discovery services based on open infrastructure.	Encourage discovery services - and develop services - that use the open infrastructure, metadata and persistent identifiers to enable.

Everybody needs to play their part

A lot of the work on making the above happen is already underway, and there is widespread adoption of open identifiers and metadata, but as noted above, funders are still early in the adoption journey, and implementation among all stakeholders is patchy.

Critical parts of the infrastructure rely on third-party platforms that supply tools and systems to authors, funders, and publishers - so coordinating the support for the appropriate metadata and identifiers in these systems and tools is very important.

We are emphasising how our existing open scholarly infrastructure systems are helping. But we also know that it’s not all perfect yet. Infrastructure is always evolving, metadata is never complete, refactoring workflows and systems can be costly, and integration can always be smoother. But our existing open infrastructure has already delivered significant benefits, and broader adoption will bring additional benefits to the whole scholarly research and communications ecosystem and help achieve the promise of Open Science in advancing human knowledge.

While working on this coordination and integration, we all try to remember that it should minimise work for researchers, and processes should be as automated as possible.

Collaboration is key to making this all work.

We already work with many funders through our Advisory Group, our 30 funder members, 25 of whom have so far collectively registered around 40,000 Crossref Grant DOIs, retrievable from our open API. Some grants are even matched to resulting outputs already, and some funders have recently dug into Crossref metadata to analyse outcomes from their investments, such as the Dutch Research Council (NWO) which presents findings and makes a case for greater emphasis on Crossref funding metadata.

We also work closely with partners Europe PMC and Altum, and we engage in community research and discussion, for example, through the Open Research Funders Group.

Alongside our fellow infrastructures and open identifier registries ORCID, DataCite, and ROR, we integrate with and support each other operationally and out in the community.

We will continue focusing our resources and efforts on engaging with funders, including US federal agencies responding by the OSTP guidelines, and all stakeholders to support the entire global scholarly research ecosystem.

Everyone has a part to play, and we must all pull together to prioritize this work.

Who’s in?

Please get in touch with Ed, Ginny, or Jennifer (or indeed DataCite or ORCID or ROR) if you’d like to have a discussion about the workflows described here, or just to make sure you’re up to date on the latest developments and opportunities we describe. We look forward to working with all funding agencies to support them as they develop their plans.

Event Data: A Plan of Action

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

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

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

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

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

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

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

The Plan

Stability

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

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

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

Consolidation

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

Future roadmap

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

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

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

Staying in touch

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

Fast, citable feedback: Peer reviews for preprints and other record types

Martyn Rittman — Wed, 09 Dec 2020 00:00:00 +0000

Crossref has supported depositing metadata for preprints since 2016 and peer reviews since 2018. Now we are putting the two together, in fact we will permit peer reviews to be registered for any record type.

Currently, peer reviews can be registered for journal articles, but that means that they can only be related to some of the content our members deposit. Preprints, books, chapters, working papers, dissertations, and a host of other works can also be registered with Crossref. A number of these frequently undergo some form of review and many of our members and voices in the community have called for us to widen the net on peer reviews, including journal publishers, book publishers, review platforms, and preprint servers. We’ve listened and taken action, and from now on Crossref members can add relationship metadata that links peer reviews to any record type. The metadata will also contain the type of review, stating whether it is a referee report, author response, or community comment, etc. This allows accurate reporting on whether the peer review is happening within a traditional editorial process or elsewhere.

Reviews for preprints

In the last decade there has been an increase in the number of disciplines using preprints. Since enabling registration of preprint metadata, it has become our fastest-growing record type. Preprints, working papers, and other forms of early publication help to accelerate dissemination of the latest research and discovery. They can also promote discussion on important topics, and help authors to improve papers before an editorial decision for journal publication. During the COVID-19 pandemic, preprints have become invaluable for speeding the publication of vital research and case studies.

On the other hand, preprints do not undergo formal review and editorial approval, leading to concerns about the dissemination of false information. While the issue of misinformation in preprints has been discussed for some time, the COVID-19 pandemic has brought it more sharply into focus. organisations that post preprints need to balance the benefits of rapid dissemination with promoting their responsible use.

To support the feedback process, preprint servers along with a growing number of other platforms and services offer scholars the opportunity to post public comments on preprints. By doing this, they give extra context for readers, provide suggestions for authors, and raise awareness of work that could be flawed or too preliminary.

Another growing trend is journal publishers adopting editorial processes that involve preprint-first options and open peer review. As Dr. Stephanie Dawson from ScienceOpen says:

“We have long believed in rewarding reviewers by assigning Crossref DOIs to their open reviews to make them citable objects and we were one of the first users of Crossref’s peer review schema. However, a large percentage of the articles reviewed on ScienceOpen are publicly available preprints. The UCL Open: Environment journal hosted on the platform, for example, is based on a workflow of open peer review of preprints. Our customers, editors, reviewers and authors are therefore extremely happy that these reviews can now also be assigned a Crossref peer review DOI for more accountability and transparency in scholarly publishing.”

At Crossref, we’re continually looking to support more record types and relations between them to build trust, support reproducibility and increase discoverability of content. This is another small step in building the research nexus and we look forward to working with members depositing peer reviews of preprints.

Calling all 24-hour (PID) party people!

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

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

Send us your ideas for #PIDapalooza21

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

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

Theme 1. PIDs 101

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

Theme 2. PID Communities International

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

Theme 3. PID Success Stories

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

Theme 4. PID Party!

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

Propose a session now!

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

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

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

Publishers, are you ready to ROR?

Maria Gould — Tue, 25 Aug 2020 00:00:00 +0000

If you manage a publishing system or workflow, you know how crucial—and how challenging!—it is to have clean, consistent, and comprehensive affiliation metadata. Author affiliations, and the ability to link them to publications and other scholarly outputs, are vital for numerous stakeholders across the research landscape. Institutions need to monitor and measure their research output by the articles their researchers have published. Funders need to be able to discover and track the research and researchers they have supported. Academic librarians need to easily find all of the publications associated with their campus. Journals need to know where authors are affiliated so they can determine eligibility for institutionally sponsored publishing agreements.

Until recently, an open, unambiguous, and persistent identifier for research organisation affiliations has been a missing layer of the scholarly ecosystem. DOIs could identify articles and datasets and other research outputs, and ORCID IDs could identify researchers, but no equivalent solution was available to identify institutions. With the launch of the Research Organization Registry (ROR) in 2019 (which Crossref has helped to develop), the landscape is changing. ROR IDs are an opportunity to make affiliation details easier for publishers to use and easier for those who rely on this data.

Affiliations are a key piece of Crossref metadata that has been missing, but will soon be supported in the Crossref metadata schema. This means that content registered with Crossref can be associated with a ROR IDs to enable better tracking and discovery of research and other publication outputs by institution.

What is ROR?

ROR is the Research Organization Registry––open, noncommercial, community-led infrastructure for research organisation identifiers. The registry currently includes globally unique persistent identifiers and associated metadata for more than 98,000 research organisations (as of August 2020).

ROR IDs are specifically designed to be implemented in any system that captures institutional affiliations and to enable connections (via persistent identifiers and networked research infrastructure) between research organisations, research outputs, and researchers.

ROR IDs are interoperable with those in other identifier registries, including GRID (which provided the seed data that ROR launched with), Crossref Funder Registry, ISNI, and Wikidata. ROR data is available under a CC0 waiver and can be accessed via a public API and data dump.

ROR is not the first organisation identifier to exist. But ROR is distinct because it is completely open, specifically focused on identifying affiliations, and collaboratively developed by, with, and for key stakeholders in scholarly communications. ROR is operated as a joint initiative by Crossref, DataCite, and California Digital Library, and was launched with seed data from GRID in collaboration with Digital Science. These organisations have invested resources into building an open registry of research organisation identifiers that can be embedded in scholarly infrastructure to effectively link research to organisations.

Why care about ROR IDs in Crossref metadata?

Ed Pentz, Crossref’s Executive Director, explains the key role ROR can play in enriching Crossref metadata:

“Over the years Crossref has expanded the metadata it collects (for example, ORCID IDs and license URLs) based on the changing needs of our members and the scholarly research community. A key type of metadata that is missing from Crossref is affiliations. We’ve had a lot of feedback from members that adding affiliations should be a priority. At Crossref LIVE19 in Amsterdam, ROR was ranked joint first place for Crossref by the 100 plus attendees at the meeting. For the last few years we’ve been diligently working on the initiative and are very happy that ROR is now coming to fruition.”

Crossref metadata does include some affiliations already. But this data is not comprehensive or consistent, and appears as free-text strings only (even if originally sourced from a list of institutions). A search for UC Berkeley, for instance, returns multiple variants of the university’s name:

University of California, Berkeley
University of California-Berkeley
University of California Berkeley
UC Berkeley
And likely more…

While it isn’t too difficult for a human to guess that “UC Berkeley,” “University of California, Berkeley,” and “University of California at Berkeley” are all referring to the same university, a machine interpreting this information wouldn’t necessarily make the same connections. If you are trying to easily find all of the publications associated with UC Berkeley, you would need to run and reconcile multiple searches at best, or miss data completely at worst. This is where an affiliation identifier comes in: a single, unambiguous, standardized identifier that will always stay the same (for UC Berkeley, that would be https://ror.org/01an7q238).

ROR IDs for affiliations can transform the usability of Crossref metadata. While it’s crucial to have IDs for affiliations, it’s equally important that the affiliation data can be easily used. The ROR dataset is CC0, so ROR IDs and associated affiliation data can be freely and openly used and reused without any restrictions.

What does this mean for publishers?

As the Crossref schema update is being cleared for takeoff, this is a good time for publishers and publishing service providers to be thinking about adopting ROR.

ROR IDs can be useful in publishing workflows in a variety of ways. They can easily be implemented into manuscript tracking systems to identify the affiliations of submitting authors and co-authors. This can be done via a simple institution lookup that connects to the ROR API. Authors choose their affiliation from a dropdown list populated from ROR; they do not have to provide a ROR ID or even know that a ROR ID is being collected.

Upon publication, ROR affiliation data can be included when content is registered with Crossref. ROR IDs are also supported in the JATS XML format that many publishers use. Crossref metadata can be searched and crawled, and the Crossref API will make ROR IDs available so affiliation data can be captured by tools and services and fed into downstream reporting and tracking systems.

Get ready to ROR!

ROR is already working with a number of publishers and service providers that are planning to integrate ROR in their systems, map their affiliation data to ROR IDs, and/or include ROR IDs in publication metadata.

For example: Rockefeller University Press has already added the collection of ROR IDs to their publication workflow. Upon submission, the author selects an institutional affiliation from a dropdown list of options that comes from ROR. Rockefeller University Press also relies on this affiliation data for billing and licensing purposes to coordinate Gold Open Access publishing agreements.

In addition to publishers, libraries and repositories and other stakeholders are building in support for ROR. You can also see the list of active and in-progress ROR integrations here.

We know decisions about identifier adoption aren’t easy or immediate, so get in touch with ROR if you have questions or want to be more involved in the project. ROR holds regular community meetings and webinars and supports several community working groups for those interested in implementing ROR IDs and working with ROR data. This is a community-driven effort so we want to hear from you!

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

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

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

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

Motive: ridding the world of bad metadata

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

Means: XML deposits

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

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

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

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

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

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

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

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

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

The usual suspects

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

Timestamps

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

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

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

Titles

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

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

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

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

Title level DOIs

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

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

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

Errors in the xml

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

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

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

Forensics

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

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

Calling for backup

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

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

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

Events got the better of us

Bryan Vickery — Fri, 27 Mar 2020 00:00:00 +0000

Publisher metadata is one side of the story surrounding research outputs, but conversations, connections and activities that build further around scholarly research, takes place all over the web. We built Event Data to capture, record and make available these ‘Events’ –– providing open, transparent, and traceable information about the provenance and context of every Event. Events are comments, links, shares, bookmarks, references, etc.

In September 2018 we said Event Data was ‘production ready.’ What we meant was development of the service had reached a point where we expected no further major changes to the code, and we encouraged you to use it. What normally would have followed was a detailed handover to our operations team, for monitoring and performance management, and for Product Management to expand Event Data by adding new Crossref member domains and evaluating additional event sources.

Why so quiet?

But many things changed on the staff front, meaning 2019 was a year of reinvention for the Technical and Product teams and of critical knowledge sharing and learning –– Event Data had to take a back seat as we focused resources on other key projects (more on that later). From a technical perspective, we’ve found the Elasticsearch index is not performing well and the approach taken to specifically support data citations through Scholix has not really scaled.

When things go wrong, whether in ways you can or can’t anticipate, the most important thing is communication –– in dealing with the challenges we forgot to do that. We understand how frustrating that can be and we’re extremely sorry to have gone so quiet.

So, where are we today?

Event Data is important to us and clearly important to you too as you’ve contacted us about your use-cases and the reliability of the service. Event Data remains available and you’re welcome to use it, but you should expect instability to continue and be aware that it does not find events for DOIs/domains of our newer members (who joined Crossref since 2019) –– so we’re conscious it might be hard to say whether it’s a good fit for your project at this point.

What are we doing?

We have brought in additional expert Elasticsearch resources to assist with a separate project to migrate our REST API from SOLR to Elasticsearch. We’re making fantastic progress on this. As soon as we’re confident we can make this switch, we will move those same Elasticsearch resources to shoring up Event Data. The REST API takes priority over Event Data because we need to add support for important new record types (like research grants) that aren’t yet available via the API.

We’re also concluding the process of hiring two new Product Managers which means we’ll be in a position to assign someone to head up the product management of Event Data. When we do return to Event Data in the coming months, our initial priority will be increased support for data citation and Scholix. If that means radical changes to the rest of the service, we’ll let you know.

Opening up the discussion

We will have more news on Event Data in mid-2020. We’d love you to join the Crossref Community Forum; we’ve created a new Category for Event Data where you can post details of how you are using, or plan to use Event Data; post questions to the group; suggestions for future development and provide general feedback on the Event Data service.

Metadata Manager Update

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

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

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

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

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

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

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

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

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

Metadata Corrections, Updates, and Additions in Metadata Manager

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

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

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

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

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

Correcting Errors

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

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

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

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

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

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

For articles originally registered using Metadata Manager

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

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

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

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

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

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

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

Adding additional metadata

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

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

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

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

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

We'll be rocking your world again at PIDapalooza 2020

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

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

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

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

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

Theme 1: Putting Principles into Practice

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

Theme 2: PID Communities

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

Theme 3: PID Success Stories

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

Theme 4: Achieving Persistence through Sustainability

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

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

Theme 6: PID Party!

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

PIDapalooza: the essentials

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

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

Big things have small beginnings: the growth of the Open Funder Registry

Kirsty Meddings — Sun, 21 Jul 2019 00:00:00 +0000

The Open Funder Registry plays a critical role in making sure that our members correctly identify the funding sources behind the research that they are publishing. It addresses a similar problem to the one that led to the creation of ORCID: researchers’ names are hard to disambiguate and are rarely unique; they get abbreviated, have spelling variations and change over time.

The same is true of organisations. You don’t have to read all that many papers to see authors acknowledge funding from the US National Institutes of Health as NIH, National Institutes for Health, National Institute of Health, etc. And wait, are you sure they didn’t mean National Institute for Health Research? (An entirely separate UK-based funder).

And a lot of countries have a National Science Foundation…

If each funder has a unique identifier, our members can include it in the metadata that they register with us, giving a clear and accurate link between the funder of the research and the published outcomes. And we can make that information available to everyone via our API, and build human interfaces so that you can look it up.

Many types of funding bodies are represented in the Funder Registry, from government agencies and large international foundations to small single-mission charities, and everything in between. As well as a unique DOI for each institution, the Registry contains additional metadata that can help to identify the funder such as country, abbreviated or alternate names, translated names, and so on.

The Registry also supports relationships between different funders. These can be hierarchical parent/child relationships for larger organisations, or connections between archival and current entries in instances where a funder has changed its name or become part of another body (to tell us about these kinds of changes you just need to get in touch).

The Registry was donated to Crossref by Elsevier when we first introduced funding information as part of our Content Registration schema back in 2012. We started out with a list of just over 4000 funders. Through an ongoing partnership the list has been - and continues to be - updated on a monthly basis by Elsevier, and sent to Crossref as a formatted XML file that we process and release.

In return, Crossref sends Elsevier a feed of funder names that our members have registered with us that are not present in the Registry, which a team at Elsevier validates and adds to their databases, and then puts those newly-identified funders in to the next iteration of the list they send to us. It’s nice and circular and benefits both parties.

We released v1.27 of the Funder Registry last week, and it contains entries for an impressive 21,356 funders.

I’ve been involved in this project since its inception, and have enjoyed a productive and cooperative working relationship with the team at Elsevier, headed by Peter Berkvens (Senior Product Manager) and Paul Mostert (Director Product Management). I asked them to explain a little about the process from their side:

“Our team maintains a workflow in which Acknowledgement and Funding sections from articles are scanned for appearances of funding organisations using Natural Language Processing techniques. External Elsevier vendors then edit the data and add the validated names of the funders to what is called the Funding Bodies Taxonomy. The latter feeds Crossref’s Open Funder Registry.

Currently, the Taxonomy is nearing 22,000 Funders. It is expected it will grow to 25,000 Funders eventually. When this stage is reached, Elsevier believes that all existing Funders will be covered in the Funder Registry. Elsevier will continue to maintain the list adding new Funders as soon as they appear in scientific papers.

Elsevier’s Primary Articles production workflow for ScienceDirect uses the Funder Registry during the copyediting process, validating and tagging the Funders that appear in the accepted articles for Elsevier journals hosted by ScienceDirect. We then send the funder names and IDs to Crossref as part of our metadata.”

Thanks to everyone involved for getting us ever-closer to a truly comprehensive list of funders.

And if you’re a member who’s not already registering funding information, why not look into getting started? It all leads to richer metadata which means more people can find, cite and re-use research – and we all know that’s a good thing…

Quarterly deposit invoices: avoiding surprises

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

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

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

About current and backlist Content Registration fees

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

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

Determining whether content is current or backlist

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

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

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

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

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

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

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

Prepping your title transfer

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

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

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

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

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

Top tips for a pain-free title transfer

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

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

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

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

On the other side

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

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

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

Work through your PID problems on the PID Forum

Rachael Lammey — Thu, 21 Feb 2019 00:00:00 +0000

As self-confessed PID nerds, we’re big fans of a persistent identifier. However, we’re also conscious that the uptake and use of PIDs isn’t a done deal, and there are things that challenge how broadly these are adopted by the community.

At PIDapalooza (an annual festival of PIDs) in January, ORCID, DataCite and Crossref ran an interactive session to chat about the cool things that PIDs allow us to do, what’s working well and, just as importantly, what isn’t, so that we can find ways to improve and approaches that work.

We titled the session the Yin & Yang of PIDs and challenged attendees to put down on paper (post-its) their thoughts about what’s good about PIDs (the Yin) and what’s not so good (the Yang). Attendees could also upvote other’s comments by adding a smiley face sticker to the concept(s) they supported.

So what came out of the session? Lots of things!

Limits to PID uptake are often more cultural than technical
Yay for auto-update!
Slow adoption of new PID types
Trust issues (I don’t want my information in another system)
“I’m the only Erik, I don’t need an ORCID”
User stories work!

We know we only scratched the surface in the session, but fortunately PIDapalooza also brought a good way to continue the conversation: pidforum.org! The PIDforum was launched at PIDapalooza and is a global discussion platform for all things PID-related. Many PID providers and PID users are already on there, so help us understand more about the yin and yang of PIDs by sharing your own PID problems!

ROR announces the first Org ID prototype

Maria Gould — Sun, 10 Feb 2019 00:00:00 +0000

What has hundreds of heads, 91,000 affiliations, and roars like a lion? If you guessed the Research Organization Registry community, you’d be absolutely right!

Last month was a big and busy one for the ROR project team: we released a working API and search interface for the registry, we held our first ROR community meeting, and we showcased the initial prototypes at PIDapalooza in Dublin.

We’re energized by the positive reception and response we’ve received and we wanted to take a moment to share information with the community. Here are the links to our latest work, a recap of everything that happened in Dublin, some of the next steps for the project, and how the community can continue to be involved.

🎉 Ta da! The first ROR prototype

The Research Organization Registry (ROR) is finally here! We’re thrilled to officially announce the launch of our ROR MVR (minimum viable registry). The MVR consists of the following components, which are ready for anyone to use right now.

ROR IDs: Starting with seed data from GRID, ROR has begun assigning unique identifiers to approximately 91,000 organisations in its registry. ROR IDs include a random, unique, and opaque 9-character string and are expressed as URLs that resolve to the organisation’s record. For instance, here is the ROR ID for California Digital Library: https://ror.org/03yrm5c26
Search: We also built a search interface to look up organisations in the registry: https://ror.org/search.

ROR records: ROR IDs are stored with additional metadata about the organisation, such as alternate names/abbreviations, external URLs (e.g., an organisation’s official website), and other identifiers, such as Wikidata, ISNI, and the Open Funder Registry. This metadata will allow ROR to be interoperable with other identifiers and across different systems. The current schema is based on GRID’s dataset and we plan to incorporate other metadata fields over time and according to community needs.

API: The ROR API is now public. You can access the JSON files at https://api.ror.org/organisations.
OpenRefine reconciler: We’ve released an OpenRefine reconciler that can map your internal identifiers to ROR identifiers: https://github.com/ror-community/ror-reconciler.
Documentation: We have begun storing documentation on Github and will be adding more as we go along. Please feel free to follow and contribute: https://github.com/ror-community.

Community meeting recap

On January 22, 60+ representatives from across the research and publishing community gathered in Dublin to see what the ROR project team has been up to, demo the first prototypes in action, and discuss where we want to go next - and, of course, to practice ROR-ing together.

In the second half of the meeting, attendees split into discussion groups to identify specific aspirations for ROR and brainstorm concrete actions needed to achieve these goals, focusing on the main use case of exposing and capturing all research outputs of a given institution. The proposed ideas covered a spectrum of possibilities for ROR, highlighting the following themes:

ROR as seamlessly-integrated and sometimes invisible infrastructure

Integration between and within existing systems (and in new ones!)
Auto-detection of ROR IDs for example in manuscript tracking and funding application platforms
As such, researchers don’t ever have to be responsible for knowing what a ROR is and using it appropriately - the systems they use will do this for them.

ROR as a critical piece of funder workflows and infrastructure

Demonstrate to funders how ROR can help them analyze impact of research they fund
Conduct outreach with key international funders, especially those interested in open infrastructure
Make funders aware of ROR and encourage them to adopt and mandate use of ROR IDs - involve funders at the beginning to collaborate on technology
Integrate ROR with existing systems and identifiers already in use by funders and other stakeholders

ROR as a trusted registry, collaborative partner, and responsible steward

Culturally sensitive, inclusive, and respectful of what countries are already doing with regard to organisational identifiers, partnering with national bodies working on this and mapping ROR IDs to locally used identifiers.
Involve the institutions listed in the registry early on as well as CRIS systems
Interoperability with existing communities and governance bodies
Workflows to support trust and responsible management of organisational metadata, with policies and procedures for long-term curation and maintenance of records

What we’re hearing

Now that the ROR MVR is here, we’re hearing some really good questions about the data we’re capturing, how it can be used, and how we’ll be maintaining the registry going forward. We wanted to take a moment to respond to some of these questions.

What is the criteria for being listed in ROR? What is a “research organisation”?

We define the notion of “research organisation” quite broadly as any organisation that conducts, produces, manages, or touches research. This is in line with ROR’s stated scope, which is to address the affiliation use case and be able to identify which organisations are associated with which research outputs. We use “affiliation” to describe any formal relationship between a researcher and an organisation associated with researchers, including but not limited to their employer, educator, funder, or scholarly society.

Will ROR map organisational hierarchies?

No - ROR is focused on being a top-level registry of organisations so we can address the fundamental affiliation use case, and provide a critical source of metadata that can interoperate with other institutional identifiers.

ROR IDs are cool - what can I do with them?

Now that we have built our MVR, we will be working to incorporate ROR IDs into relevant pieces of the scholarly communication infrastructure. If you are a publisher, funder, metadata provider, research office, or anyone else interested in capturing affiliations, please get in touch with us to discuss how we might coordinate. If you are a developer, you are welcome to start playing around with the API: https://api.ror.org/organisations.

There’s an error in my organisation’s ROR record — can you fix it?

For the time being, please email info@ror.org to request an update to an existing record in ROR or request that a new record be added. We will formalize our data management policies and procedures in the next stage of the project.

What is ROR’s relationship to other organisational identifiers?

For ROR to be useful, it needs to augment the current offerings in a way that is open, trusted, complementary, and collaborative, and not intentionally competitive. We are committed to providing a service that the community finds helpful and not duplicative, and enables as many connections as possible between organisation records across systems.

I have my own dataset of institutional affiliations — can I give it to ROR?

We are always happy to hear about other efforts to capture affiliation data. Please get in touch with us to discuss how we might coordinate.

Can ROR support multiple languages and character sets?

GRID already supports multiple languages and character sets, so by extension ROR will have this enabled as well. Here is one example: https://ror.org/01k4yrm29.

How will ROR handle curation, i.e., updating records if an organisation changes its name or ceases to exist?

The curation and long-term management of records will be a cornerstone of our efforts in 2019 and we hope to release a working set of policies and procedures soon.

What’s next for ROR

Now that we have our MVR, what happens next for ROR? We’re eager to sustain the momentum from January’s stakeholder meeting at the same time we know there are some longer-term plans to put in place, and so we’re looking at both some immediate tasks as well as bigger-picture questions.

Product development

We have a few to-do items on our list following the launch of the MVR to keep everything running smoothly while we develop a comprehensive long-term product roadmap.

Rewrite some of the code for both the API and the OpenRefine reconciler
Address a few bugs in our repos
Provide guidance for troubleshooting issues
Communicate our processes for users to request changes, report bugs, and suggest features

As a reminder, you can access the existing code in Github: https://github.com/ror-community

Policy development

We’ve been emphasizing here and in community conversations that our primary focus now turns to formulating policies and procedures to ensure the successful management of ROR data over the long term. This is something we can’t (and shouldn’t) do on our own — we want to work with community stakeholders to develop the right solutions and establish the right frameworks. We understand the urgency of firming up these policies, but we are also aware that something this important can take time to complete and is not something to rush into lightly.

Community development

To help guide the next stages of the project, we are putting out an open call for participation in the ROR community advisory group. Advisory group members will be involved in giving input on data management, testing out new features, giving feedback on the product roadmap, and discussing ideas for events and outreach. We plan to convene this advisory group through bimonthly calls and asynchronous communication channels through the end of the year. We hope you will consider joining us! Please email info@ror.org if you are interested.

For those who want to stay informed about the project but not necessarily be part of the advisory group, you have other options!

Sign up for our mailing list (via the footer at ror.org)
Join our community on Slack (www.tinyurl.com/ror-community),
Follow us on Twitter (@ResearchOrgs).

You can also always drop us a line at info@ror.org, and let us know if you’d ever like to set up a meeting or conference call to talk about the project in more detail.

Final thoughts

Community engagement has been vital to ROR’s beginnings and will likewise be critically important for the next steps that we take. As both a registry of identifiers and a community of stakeholders involved in building open scholarly infrastructure, ROR depends on guidance and involvement at multiple levels. Thank you for being part of the journey thus far, and for joining us on the road that lies ahead. 🦁

Request for feedback on grant identifier metadata

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

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

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

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

The details

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

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

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

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

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

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

What can often change, but always stays the same?

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

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

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

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

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

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

Title transfers

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

Organisation transfers

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

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

It’s now easier to transfer titles

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

Improved processes, and more via Metadata Manager

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

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

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

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

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

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

Easily import journals, or add new ones

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

Adding a Journal DOI

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

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

Adding new articles

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

Save your work as you go

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

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

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

Adding references

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

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

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

Edit mistakes without having to re-enter all your metadata

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

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

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

Find out immediately if your registration was successful

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

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

Resolutions 2019: Journal Title Transfers = Metadata Manager

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

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

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

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

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

Transferring your journal in five easy steps using Metadata Manager:

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

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

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

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

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

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

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

Metadata Manager: Members, represent!

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

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

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

Metadata Manager is here to help

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

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

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

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

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

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

Features

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

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

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

Members, represent!

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

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

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.

Event Data is production ready

Christine Buske — Wed, 12 Sep 2018 00:00:00 +0000

We’ve been working on Event Data for some time now, and in the spirit of openness, much of that story has already been shared with the community. In fact, when I recently joined as Crossref’s Product Manager for Event Data, I jumped onto an already fast moving train—headed for a bright horizon.

What’s on the horizon? Well, the reality is you never really reach the horizon. Good product development—in my opinion—is like that train. You keep aiming for the horizon and passing all the stations (milestones) along the way, but the horizon keeps moving as you add features, improve the service, and maybe even review where you are headed. However, for Event Data we are pleased to say we have now arrived at a rather important station.

Technical readiness

Thank you to all the beta testers who have journeyed with us this far—we’ve listened and learned, refined and rebuilt with the help of your feedback. We are now thrilled to say that we are service production ready. We’ve reached the station called ‘technical readiness’, and are eager to see more users board our train!

During this time of building and refining, Event Data has grown to include at least 66,7 million events from sources like (in order of magnitude): Wikipedia, Cambia Lens, Twitter, Datacite, F1000, Newfeeds, Reddit links, Wordpress.com, Crossref, Reddit, Hypothesis, and Stackexchange. Wikipedia alone accounts for 50 million events (and counting).

What does this mean?

Event Data is production ready.

Being production ready means we are not going to make any breaking changes to the code, and we are excited to see more people jump on board to explore where you can go with Event Data, and what product or service you might want to build with it.

Getting started

Having a look at Event Data, and using it, is easy. While the user guide outlines everything you need to know to get fully engrossed, you can get your feet wet with a few sample queries:

Above I mentioned Event Data has about 50 million Wikipedia events, you can check if that has grown by looking at a query that lists all distinct events by source (your browser will need a JSON viewer extension):

https://api.eventdata.crossref.org/v1/events/distinct?facet=source/:*&rows=0

You can also see a live stream of events going through Event Data.

For all events registered for a specific content item, you simply query http://api.eventdata.crossref.org/v1/events?obj-id=https://doi.org/XXX, where XXX is replaced with the DOI.

What next?

We are now focusing on the final stretch towards the official roll-out. Beyond this, we will continue to add sources and features and have a healthy roadmap to keep us on track. We value any feedback you have for us about your own journey with Event Data. Your feedback may help shape the direction we take in the future. Most of all, we are all excited to see what people build with it!

We look forward to continuing on our Event Data journey and we welcome you all aboard the train! Please contact me with your ideas.

Presenting PIDapalooza 2019

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

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

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

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

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

As a reminder, the regular themes are:

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

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

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

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

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.

Org ID: a recap and a hint of things to come

John Chodacki — Thu, 02 Aug 2018 00:00:00 +0000

Cross-posted on the blogs of University of California (UC3), ORCID, and DataCite: https://doi.org/10.5438/67sj-4y05.

Over the past couple of years, a group of organisations with a shared purpose—California Digital Library, Crossref, DataCite, and ORCID—invested our time and energy into launching the Org ID initiative, with the goal of defining requirements for an open, community-led organisation identifier registry. The goal of our initiative has been to offer a transparent, accessible process that builds a better system for all of our communities. As the working group chair, I wanted to provide an update on this initiative and let you know where our efforts are headed.

Community-led effort

First, I would like to summarize all of the work that has gone into this project, a truly community-driven initiative, over the last two years:

A series of collaborative workshops were held at the Coalition for Networked Information (CNI) meeting in San Antonio TX (2016), the FORCE11 conference in Portland OR (2016), and at PIDapalooza in Reykjavik (2016).
Findings from these workshops were summarized in three documents, which we made openly available to the community for public comment:
organisation Identifier Project: A Way Forward (PDF)
organisation Identifier Provider Landscape (PDF)
Technical Considerations for an organisation Identifier Registry (PDF)
A Working Group worked throughout 2017 and voted to approve a set of recommendations and principles for ‘governance’ and ‘product’:
Governance Recommendations
Product Principles and Recommendations
We then put out a Request for Information that sought expressions of interest from organisations to be involved in implementing and running an organisation identifier registry.
There was a really good response to the RFI; reviewing the responses and thinking about next steps led to our most recent stakeholder meeting in Girona in January 2018, where ORCID, DataCite, and Crossref were tasked with drafting a proposal that meets the Working Group’s requirements for a community-led, organisational identifier registry.

Thank you

I want to take this opportunity to thank everyone who has contributed to this effort so far. We’ve been able to make good progress with the initiative because of the time and expertise many of you have volunteered. We have truly benefited from the support of the community, with representatives from Alfred P. Sloan Foundation; American Physical Society, California Digital Library, Cornell University, Crossref, DataCite, Digital Science, Editeur, Elsevier, Foundation for Earth Sciences, Hindawi, Jisc, ORCID, Ringgold, Springer Nature, The IP Registry, and U.S. Geological Survey involved throughout this initiative. And we couldn’t have done any of it without the help and guidance of our consultants, Helen Szigeti and Kristen Ratan.

The way forward

The recommendations from our initiative have been converted into a concrete plan for building a registry for research organisations. This plan will be posted in the coming weeks.

The initiative’s leadership group has already secured start-up resourcing and is getting ready to announce the launch plan—more details coming soon.

We hope that all stakeholders will continue to support the next phase of our work – look for announcements in the coming weeks about how to get involved.

As always, we welcome your feedback and involvement as this effort continues. Please contact me directly with any questions or comments at john.chodacki@ucop.edu. And thanks again for your help bringing an open organisation identifier registry to fruition!

References

Bilder, G., Brown, J., & Demeranville, T. (2016). Organisation identifiers: current provider survey. ORCID. https://doi.org/10.5438/4716

Cruse, P., Haak, L., & Pentz, E. (2016). organisation Identifier Project: A Way Forward. ORCID. https://doi.org/10.5438/2906

Fenner, M., Paglione, L., Demeranville, T., & Bilder, G. (2016). Technical Considerations for an organisation Identifier Registry. https://doi.org/10.5438/7885

Laurel, H., Bilder, G., Brown, C., Cruse, P., Devenport, T., Fenner, M., … Smith, A. (2017). ORG ID WG Product Principles and Recommendations. https://doi.org/10.23640/07243.5402047

Laurel, H., Pentz, E., Cruse, P., & Chodacki, J. (2017). organisation Identifier Project: Request for Information. https://doi.org/10.23640/07243.5458162

Pentz, E., Cruse, P., Laurel, H., & Warner, S. (2017). ORG ID WG Governance Principles and Recommendations. https://doi.org/10.23640/07243.5402002

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 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.

Redirecting redirection

Geoffrey Bilder — Tue, 24 Apr 2018 00:00:00 +0000

Crossref has decided to change the HTTP redirect code used by our DOIs from 303 back to the more commonly used 302. Our implementation of 303 redirects back in 2010 was based on recommended best practice for supporting linked data identifiers. Unfortunately, very few other parties have adopted this practice.

What’s more, because using a 303 redirect is still unusual, it tends to throw SEO tools into a tizzy- and we spend a lot of time fielding SEO questions from our members about our use of 303s.

TL;DR

At this point, we need to emphasise that we have never seen our use of 303s actually affect page rankings. But at the same time, use of 303 redirects has not had wider uptake. Maintaining this quixotic behaviour just isn’t worth the effort. We hope that, in the future, we can use other techniques (e.g. signposting & cite-as) to achieve some of the things that 303 was supposed to do.

Note that these changes will not affect users or machines using DOIs. The change should be entirely transparent.

Below we provide some background to our decision and after that we provide some detailed technical notes from Jonathan Rees and Henry Thompson who have been very kind in helping to provide Crossref technical guidance on how we can help DOIs best support linked open data and adhere to HTTP best practice.

Background

Back in 2010, Crossref, DataCite (and later, several other RAs) responded to concerns that DOIs were not “linked-data friendly.” There were three problems with DOIs at that time:

It was not clear that DOIs could be used and expressed as HTTP URIs.
There was no standard way to ask a DOI to return a machine-readable representation of the data.
It wasn’t always clear if the DOI resolved to “the thing” (e.g. an article) or “something about the thing” (e.g. a landing page).

On the advice of several people in the linked data community, we proposed some options for fixing this. And we finally settled on:

Recommending that Crossref DOIs be expressed and displayed as HTTP (now HTTPS) URIs. This made it clear that DOIs could be used with HTTP applications.
Enabling DOI registration agencies to support content negotiation. This allowed RAs to support providing machine-readable representations of the data associated with a DOI.
Changing the underlying redirect code from the normal 302 to 303. This was designed to clarify what, at the time, was true- that most DOIs resolved to a landing page, not the article itself.

By any practical measure, machine use of DOIs has exploded since we made these decisions back in 2010. Crossref’s APIs and content negotiation handle over 800 million requests for machine readable data a month. Our sibling organisation, DataCite, has also seen a huge growth in machine use of DOIs. Many applications, from bibliographic management tools, to authoring systems and CRIS systems, make use of machine actionable DOIs all the time. So clearly our work to promote DOIs as machine actionable identifiers is working, but we are certain that our current use of 303 redirects has nothing to do with this growth.

First of all, as we said, very few parties have actually subscribed to the notion of using 303s to help distinguish “the thing” from “something about the thing”.

Secondly, even if they did try to rely on 303s to make this distinction, they would quickly get confused because the DOI is so often just the first in a chain of redirects which do not implement the same semantic distinction. At this point we should be clear - Crossref thinks these kinds of long redirect chains are a bad idea for two main reasons:

They slow down resolution.
They increase the number of potential failure points between the DOI and the item it resolves to.

But we also cannot legislate them away. They exist. And in the real world you will find plenty of DOIs that do a 303 redirect to a system that, in turn, does a 302 redirect to a system that does a 301 redirect and…eventually ends up someplace returning a 200. You get the picture. How on earth is a machine supposed to interpret a 303->302->301->302 redirect chain?

Furthermore - nowadays, after following this chain of redirects, you will often find yourself on a “page” that is both a landing page and the article itself. Dynamic, one-page applications can simply morph the one into the other without the use of additional HTTP requests.

In other words, using 303s is not helping machines interpret what the DOI is pointing at. And yet, people seem to be making good use of machine actionable DOIs and they are not complaining much about it.

Personally, I’d might have just been happy to switch back to using 302s simply so that I could cut down on my conversations with SEO hacks. But that wouldn’t be a principled approach. In 2010 we spent a lot of time considering the initial switch to 303s- we needed to consult with the LOD community on a potential switch back to 302s. At the January 2018 PIDapalooza I had a chance to talk to Henry Thomson about the 302/303 dilemma we faced, and he along with Jonathan Rees very generously provided the following feedback.

Best practices for HTTP redirection by persistent identifier resolvers: 302 vs. 303

Jonathan Rees (MIT CSAIL, https://orcid.org/0000-0001-7694-8250)
Henry Thompson (University of Edinburgh, School of Informatics, https://orcid.org/0000-0001-5490-1347)

If one goes to the trouble to organize an identifier system, then the desire that such a system should last as long as possible leads one to aspirationally say it’s a persistent identifier (PID) system. The unwillingness of the major browser suppliers to implement new URI schemes for PIDs initially hindered their use on the Web and this in turn inhibited widespread adoption. More recently a number of PID approaches have enjoyed very rapid growth as a result of a compromise: these PIDs participate in the World Wide Web by defining simple conversion rules mapping identifiers to actionable (‘http:’ and/or ‘https:’) forms and providing resolution servers that redirect requests for such forms to the appropriate destination.This approach has been widely adopted and is very successful, because it is so useful. An identifier’s actionable form leads, via the HTTP protocol and one or more redirections, to a web page that bears on the ground identity of the associated entity – or perhaps even directly to the entity itself, if the system is one for document entities that are naturally provided as web pages. The nature of the retrieved web page varies from one system to the next.

A confusion arose, however, over claims in various technical specifications (URIs, HTTP, Web Architecture) that the normal case is for the protocol to yield a “representation” of the “resource” “identified” by the URI. None of these terms is adequately defined by the specifications, and initially the language was not taken as normative. Those deploying identifier systems took the HTTP “resource” to be the entity associated with an identifier, and understood the “resource” as being “identified” by the URI, but it was never clear what was, or wasn’t, a “representation” of a given entity/resource: a description of the resource, the resource itself, a version of the resource, instructions on how to find the resource, etc. Sixteen years ago, in an attempt to clarify the intent of this part of the theory of URIs, and to allow applications to usefully and uniformly exploit the idea that an HTTP 200 response must deliver a “representation” of the “resource”, Tim Berners-Lee asked the W3C Technical Architecture Group to consider what came to be known as the httpRange-14 issue. It’s now 13 years after the TAG gave advice which almost no one was happy with, and 5 years after work on issue httpRedirections-57 (which superseded httpRange-14) ground to a halt. There’s still no consensus on whether it’s OK to return landing pages with a 200 status in response to requests for pictures or publications, but the Web seems to be working nonetheless, and no one seems to be bothered much anymore.

The provision of HTTP-based resolution services has stimulated widespread support for the use of identifier systems with Web resolution, particularly in the scholarly journal publication context. Those setting up HTTP resolvers responsible for identifier systems must decide which HTTP response code should be used. The TAG’s advice sows doubt on the use of the 200 response code when the response would have been a landing page, and many resolvers avoid 200 regardless and use redirection for administrative purposes, for example

‘https://dx.doi.org/10.1109/5.771073’ to

‘http://ieeexplore.ieee.org/document/771073/?reload=true’ for the DOI

‘10.1109/5.771073’, or ‘https://identifiers.org/uniprot/A0A022YWF9’ to

‘http://www.uniprot.org/uniprot/A0A022YWF9’ for the Uniprot identifier

‘A0A022YWF9’.

So the response should be a redirection, but what kind, 301, 302, or 303? (Or 307, which is almost the same as 302.) A 301 redirect seems to say that the URI is not persistent (since its target is deemed “more persistent”). A 302 redirect seems to say that the response could have come via a 200, and so suffers the same fate as 200. That leaves 303, as hinted at in the TAG’s advice. This idea got some traction: Ten years ago a Semantic Web interest group promoted the TAG’s advice in a published note, and seven years ago one of us wrote a blog post giving the same advice for resolvers for PIDs in publishing.

However, not only is there neither consensus nor general utility around this strict understanding of the use of the various response codes – that is, that resolution to a landing page is inconsistent with a 200 (and a posteriori therefore with a 302) – but also the range of usage patterns for redirection of HTTP requests has grown and ramified over time as the Web has grown and become more complex. It’s on the face of it unlikely that a mere three response codes can capture all the resulting complexity or cover the space of outcomes (in terms of e.g. what ends up in the browser address bar or what search engines index a page under) that a page owner might like to signal.

We find in practice that some PID redirections are ending up (usually after further publisher-local redirects) at the “identified” document, some at landing pages, and some at one or the other depending on the requesting site, for example in the case of paywalled material.

In the absence of a rethinking of the whole 3xx space, it seems to us that only the 301 vs. 302 distinct ion (roughly, 301 = permanent = please fix the link, and 302 = temporary = don’t change the link) is well understood and more or less consistently treated, whereas for 303, web servers are not very consistent and both search engine and citation crawler behaviours are at best inconsistent and at worst downright unhelpful.

So, we believe it is in both users’ and publishers’ interests for resolvers of actionable-form PIDs to use 302 redirects, not 303.

If we want to help machines better understand the resource that a DOI points at, we have to explore using more nuanced mechanisms.

Just using 302 for the first redirect doesn’t do everything necessary to effectively support the emerging PID+redirection architecture. It’s at the end of the redirect chains that we need more: a standardised way to find the PID back at the start of the chain. The ‘cite-as’ proposal does exactly this, and we hope it’s quickly approved and widely adopted. Once that happens a proposal for augmenting browser (and API) behaviour to prefer, or at least offer, the ‘cite-as’ link for bookmarking and copying will be needed.

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.

PIDs for conferences - your comments are welcome!

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

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

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

Why are conferences important?

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

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

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

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

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

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

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

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

Next steps

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

Hello, meet Event Data Version 1, and new Product Manager

Christine Buske — Thu, 29 Mar 2018 00:00:00 +0000

I joined Crossref only a few weeks ago, and have happily thrown myself into the world of Event Data as the service’s new product manager. In my first week, a lot of time was spent discussing the ins and outs of Event Data. This learning process made me very much feel like you might when you’ve just bought a house, and you’re studying the blueprints while also planning the house-warming party.

If Event Data is like a house, it’s been built and we’ve recently been putting on a last coat of paint. We’re very happy to announce version 1 of the API today. This is bringing us closer to the launch (house warming party), which will officially present Event Data to the world. Further to that analogy, while I bought into the house, I wasn’t around to see it being built. That’s both incredibly exciting and a little daunting.

Version 1 contains fixes for some challenges we came up against. Like scalability, data modeling for Wikipedia, and polishing. Version 1 is a new release of the data, but it is the same data set you already know and love. It should solve some of the recent stability issues, for which we apologize.

Moving forward, we expect the data model in V1 to persist and are not planning to make further large scale, fundamental changes to the Event Data API. As such, the version 1 release of the API is exceptional and a big step forward. It is important that we address these fixes before we go into production as it affects everyone who uses the service.

Same Event Data, new address

In setting up for the upcoming production service rollout, we have updated the Event Data API domain so that it is in line with Crossref’s suite of APIs. The Query API can now be found at a new URL. Here is an example query: https://api.eventdata.crossref.org/v1/events?rows=1

We have also simplified the standard query parameters in favor of a cleaner filter syntax.

Lastly, we have added a new “Mailto” parameter, just like in our REST API. It is encouraged but optional, so you are not obliged to supply it. We’ll only use it to contact you if there’s a problem.

Changes to the Wikipedia data structure

We’ve done a lot of work to use the canonical URLs for web pages to represent content as consistently as possible. This has entailed updating previously collected Events across data sources. As such, we’ve updated our Wikipedia data model to align with this. Because this update has impacted every Wikipedia Event in the system, we recommend those who have used or saved existing data from the deprecated Query API version to pull a new copy of the data. Read more about the rationale for changing the Wikipedia data model.

Updated data

This then brings me to how we now handle updated data. Sometimes we edit Events to add new features, or we may edit Events if there is an issue processing and/or representing the data when we provision it to the community. And sometimes we must remove Events to comply with a particular data source’s terms and conditions (ex: deleted Tweets). You can read about how updates work in the user guide.

To make life easier moving forward, we’ve split updated Events into two API endpoints. If you are already using Event Data, you will need to make some small updates to your client(s) to align with this. The new endpoints are further described in the documentation.

Event Data beta group

With the version 1 release we are making solid progress towards an official launch (the house-warming party!), we are quite excited to hear how you are using Event Data. Please consider [joining our beta group] (https://groups.google.com/forum/#!forum/crossref-event-data-beta-testers), if you are using the Event Data API or want to hear about updates.

This is also where you can read about these updates in more detail.

For more information and to get started with Crossref Event Data, please refer to the user guide.

I am looking forward to seeing how Event Data is being used, and working with the community to continuously improve what we can offer through this service. Feedback is always welcome, feel free to get in touch with me at eventdata@crossref.org.

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

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

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

Introduction

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

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

Benefits of an open & global grant identifier system

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

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

How would it work?

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

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

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

Next steps

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

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

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

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

Thanks to guest authors:

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

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

Meet the members, Part 2 (with protocols.io)

Christine Cormack Wood — Wed, 31 Jan 2018 00:00:00 +0000

Second in our Meet the members blog series is Lenny Teytelman, co-founder and CEO of protocols.io, who gives us a bit of insight into his background and why he started protocols.io, what the future plans for protocols.io are, and how they use and benefit from being a Crossref member.

Can you tell us a little bit about yourself, and why you started protocols.io?

I am a computational and experimental biologist, and it was my struggle with correcting a published research method as a postdoctoral researcher at MIT that led me to co-found protocols.io. I spent a year and a half correcting a single step of a research recipe. Instead of 1ul of a chemical, it needed 5, instead of a 15-minute incubation, it needed an hour. But this was a correction of something previously published, not a new method, so absurdly, it was not a result that I could publish. That means I got no credit for this year and a half, and more importantly, every other scientist using this recipe is either getting misleading results or has to waste 1-2 years rediscovering what I know—rediscovering something that I’d love to share, but have no easy way of doing so.

So, I became obsessed with creating a central place where scientists can easily share and discover detailed research recipes. We’re open access, free-to-read and free-to-publish, with web & mobile apps that make these protocols dynamic and interactive.

What problem is your service trying to solve?

Currently, methods sections of research papers are full of things like “we used a slightly modified version of the method reported in paperX”. Here are two examples:

We are working to increase reproducibility, by encouraging precise detailing of methods and then making it easy to keep these methods up-to-date, long after the paper is published. More broadly, our mission is to accelerate science by getting the detailed knowledge out of paper notebooks, and getting it out in months, instead of years.

Tell us a little bit about what you publish and for whom.

Both the content, and the audience for it, has been expanding recently. When we launched in 2014, the protocols were almost exclusively wetlab biology recipes. In 2015, we added support for computational workflows and began to see bioinformatics methods. More recently, thanks to the referrals from PLOS ONE, we’ve started to see protocols for human trials, medical devices, psychology, and more. About half a year ago, we changed our landing page form “Open Access Repository of Life Science Methods” to the more general “Open Access Repository of Research Methods”.

The readership is also broadening, it’s no longer just professional researchers—we now have protocols and guidelines for undergraduate and high school students, instructions for citizen science projects, and even standard operating procedures for lab management. We’ve also been seeing more off-the-shelf use, with people sharing actual cooking recipes, and we recently began asking authors to classify whether they are sharing “research” or “non-research” instructions.

How would you describe the value of being a Crossref member?

Without a doubt, we would be nowhere close to the adoption and sharing that we have now if we were not members of Crossref, registering DOIs for all public protocols. This is an absolute prerequisite for being included in author guidelines of journals, and we wouldn’t have grown in 2017 from two to over 200 journals that encourage authors to detail their recipes on protocols.io.

In addition to the benefit to protocols.io, there is a benefit to the scientists in terms of the quality control that Crossref ensures among the members. Much of this is behind the scenes and invisible to the researchers visiting protocols.io.

For example, in the beginning, we used to simply delete spam protocols. However, once we started issuing DOIs, we realized that we would be violating the Crossref requirements for minted DOIs if we simply trashed these. As a result, we had to build “retraction” functionality that allows us to take down content, put up a notice explaining the reason for removal, and keep the record so that the respective DOI continues to resolve. This is the correct way to handle removals of scientific content and it is Crossref that made us mature and improve the platform. (We’ve since had to use the retraction functionality at the request of scientists, and we’re glad we implemented it to comply with the Crossref requirements.)

Another example is the resolution report that we routinely get from Crossref, showing us which DOIs are broken. It highlights errors for us and helps us to investigate, identify, and prevent problems with the journal partners.

What do you see as the value of Crossref, beyond protocols.io?

As I argued in my talk at the annual Crossref conference, we are finally in a position to connect scientists with the knowledge they need, automatically. Almost every scientist uses a reference manager such as Mendeley, Zotero, Paperpile, etc. to manage their literature bibliography. In turn, that means that in theory, when something happens to a paper or research objects connected to the paper (retraction, correction, update to the dataset accompanying the manuscript), the reference management platforms could notify every scientist who has that paper in their library.

The problem is that it isn’t feasible for every service like Mendeley to connect to every repository and publisher to track events connected to every paper. This is where Crossref is positioned so powerfully. By collecting the metadata linking papers to the research objects, Crossref can be the single source that the platforms need to query to see if there is news for their users related to any specific published paper. (More of this from my talk was captured really nicely in this blog post by the SMU librarian Aaron Tay.

What are the future plans for protocols.io?

Expanding protocols.io content to include chemistry workflows is an important goal for 2018-19.

We are also eager to start on connecting the protocols directly to the devices that the scientists use. Imagine you need to spin your cells for 30 seconds, but the centrifuge is accidentally set for 3 minutes. Our app should be able to connect to the equipment and alert the researcher to the wrong setting, asking if they are sure they want to proceed.

Global Persistent Identifiers for grants, awards, and facilities

Ginny Hendricks — Wed, 13 Dec 2017 00:00:00 +0000

Crossref’s Open Funder Registry (neé FundRef) now includes over 15 thousand entries. Crossref has over 2 million metadata records that include funding information - 1.7 million of which include an Open Funder Identifier. The uptake of funder identifiers is already making it easier and more efficient for the scholarly community to directly link funding to research outputs, but lately we’ve been hearing from a number of people that the time is ripe for a global grant identifier as well.

To that end, Crossref convened its funder advisory group along with representatives from our collaborator organisations, ORCID and DataCite, to explore the creation of a global grant identifier system.

We thought you might like to know about what we’ve been discussing…

The First Rule of Grant Identifiers

The first rule of grant identifiers is that they probably should not be called “grant identifiers”. Research is supported in a variety of ways—through grants, endowments, secondments, loans, use of facilities/equipment and even crowd-funding. In any of these cases, it is important to be able to link researchers and research outputs to details about the sources of support. This is true for prosaic reasons—to understand ROI, to map the competitive landscape, to ensure that mandates are fulfilled, to avoid double payment. But it is also true for epistemic reasons; understanding how research was funded can help contextualise that research, and help expose potential conflicts of interest or specific agendas.

The Open Funder Registry which provides a coarse mapping between research outputs and funders, but it is becoming clear that we need more fine-grained mapping directly to information about the kind of support that was provided.

Awkwardly, none of us had any great ideas about alternative nomenclature, so we’ve made the eminently practical decision to continue to use the term “grant identifier” whilst being aware that our aim is to define a system that applies more broadly to any form of funding or support of research. So +1 for practicality.

Why do we need an open, global, grant identifier?

With the steady increase in research outputs, and the growing number of active researchers from both academia and industry, research stakeholders find they need to be able to automate workflows in order to scale their systems efficiently. Funders want to be able to track the outputs that arise from research they have funded. As a result, institutions find themselves having to regularly analyse and summarise the research their faculty produces. Faculty, in turn, face increasing accounting bureaucracy in order to meet all the reporting requirements that are cascading through the system. And finally, publishers are seeking to make the manuscript submission and evaluation process more efficient as well as to increase the discoverability and contextual richness of their publications.

Most funders already have local, internal grant identifiers. But there are over 15K funders currently listed in the aforementioned Open Funder Registry. The problem is that each funder has its own identifier scheme and (sometimes) API. It is very difficult for third parties to integrate with so many different systems. Open, global, persistent and machine-actionable identifiers are key to scaling these activities.

We already have a sophisticated open, global, interoperable infrastructure of persistent identifier systems for some key elements of scholarly communications. We have persistent identifiers for researchers and contributors (ORCID iDs), for data and software (DataCite DOIs), for journal articles, preprints, conference proceedings, peer reviews, monographs and standards (Crossref DOIs), and for Funders (Open Funder Registry IDs).

And there are similar systems under active development for research organisations, conferences, projects and resources reported in the biomedical literature (e.g. antibodies, model organisms). At a minimum, open, persistent identifiers address the inherent difficulty in disambiguating entities based on textual strings (structured or otherwise). This precision, in turn, allows automated cross-walking of linked identifiers through APIs and metadata which enable advanced applications.

For example, the use of identifiers can simplify user interfaces and save users time. Almost everybody in scholarly communications spends a frustrating portion of their lives copying information from one system to another. This process is not just tedious, it is also error-prone. But we are increasingly seeing systems make use of identifiers to eliminate the need for a lot of this manual copying. For example, researchers using an ORCID iD when they submit a manuscript can start to expect that their relevant ORCID biographical data will simply be imported into the manuscript tracking system so that it doesn’t have to be manually copied over. And if said researcher has their manuscript accepted, they can also expect that their ORCID record will automatically be updated with the publication information and that their institution and/or their funder can be automatically notified of the impending publication so that relevant repositories and CRIS systems can be populated automatically.

Additionally, there is a growing list of services that have been built on top of these standard identifiers. Profile systems (e.g. VIVO, Impact Story, Kudos) can automatically retrieve the latest information from a researcher’s ORCID record. Bibliographic management tools (EasyBib, Zotero, Papers) allow researchers to cite content with the latest metadata. And similarity checking services can harvest and index the latest scholarly literature for inclusion in the tools they have developed for detecting plagiarism and fraud. Funder identifiers are already playing an important role in this metadata workflow. As of November 2017, there are 1.7 million Crossref publication DOIs that are explicitly linked to an Open Funder Registry ID. These linkages serve as a foundation for initiatives like SHARE, CHORUS, and the Jisc Publications Router. But there are another 1+ million records that have funding information without an associated ID and, of course, 90+ million records that have no funding information at all.

So If we have global funder identifiers and they are already working, why do we need global grant identifiers as well? Don’t we just need to increase uptake of funder identifiers? How will grant identifiers help?

First, global grant identifiers could greatly reduce the UX complexity of gathering funder information. This, in turn, would boost the collection of funding information from researchers and ensure that the information that they provide to publishers, institutions and other funders is accurate and complete.

Second, the introduction of global grant identifiers would further increase the utility of links between research outputs and funding information. A grant identifier provides more granular information about the funding. Instead of just linking to information about the funder, a grant identifier would allow linking research outputs to particular research programs along with the information relating to those programs, such as grant durations, award amounts, etc. It would also allow analysis of relationships between multiple co-funding bodies.

To DOI or not to DOI?

Clearly, we think DOIs are pretty good things. But we also aren’t zealots. Sometimes DOIs are appropriate and sometimes they are not. For example, we were instrumental in defining the structure of the ORCID identifier and, in that case, we decided that DOIs were not appropriate.

But in the case of a global grant identifier system, we think there are a number of reasons adopting DOIs would be useful:

It is easy to “overlay” the global DOI system onto existing local identifier systems. An organisation does not need to abandon their internal identifier scheme in order to use DOIs. They can instead incorporate their local scheme into the DOI structure via the simple mechanism of prepending their existing identifiers with an assigned DOI prefix and registering relevant metadata with a DOI registration agency like Crossref or DataCite.
DOI links are “persist-able”. That is they can resolve to different online locations even if domain names change and/or the DNS system itself is replaced. This characteristic is important for a grant identifier because funding agencies - particularly government funding agencies - tend to undergo frequent reorganisations (e.g. splitting, merging, restructuring) and renaming. An indirectly resolvable identifier like a DOI (or ARK, Handle, etc.) is critical to ensure the long-term integrity of identifiers in these situations.
There are 15K+ funders currently listed in the Open funder Registry. Each has their own grant identifier scheme and different levels of technical support for them (APIs, etc.). This makes it very difficult for 3rd parties to build tools that work “generically” with grant identifiers. But once a local identifier scheme had been “globalised” by making it a DOI, third parties can build tools without having to worry about the differences between individual funder systems.
Crossref and DataCite DOIs are deeply embedded in the tools and workflows of scholarly communications. Manuscript tracking systems, bibliographic management systems, metrics systems, CRIS systems, profile systems, etc. often have built-in mechanisms for consuming and making use of DOIs and their associated metadata.
Crossref and DataCite DOIs are cross-disciplinary. They are used in the humanities, social sciences, sciences and in a host of communities that frequently interact with the scholarly literature for example- NGOs, IGOs, patent systems, and standards bodies.
Crossref and DataCite provide a variety of APIs (e.g. REST, OAI-PMH) and services (e.g. search, Crossmark, Similarity Check, Scholix) built around DOIs.
DOI’s have a useful characteristic, which is that the “prefix” of a DOI can be used to determine who originally created the record with which the DOI is associated. In the case of grant identifiers, this means that the prefix of a DOI-based grant identifier could be used to automatically determine the correct funder responsible for the initial grant. This means that the UIs for entering funder/grant information could be both simplified and made more robust—which would likely increase the number of parties that collect and propagate id-based funder information.

But the use of DOIs as the basis for grant identifiers also introduces some potential barriers to adopting a standard funding identifier. For example:

Funders would need to be able to join a suitable DOI registration agency (e.g. Crossref, DataCite). Some funders (e.g. government agencies) may be restricted in their ability to “join” external organisations.
Funders would need to be able to create new DOIs and register associated metadata with their chosen registration agency in a timely manner. Some funders may be unable to generate metadata or may not have the technical capacity to automatically register metadata.
Funders would need to be able to provide an openly available (e.g. not behind access control) online resource to which the DOI would resolve. For example, a landing page describing the grant or a digital copy of the grant itself. Again, some funders may face technical barriers to providing an online resource to resolve to. In other cases there may be privacy or security reasons for not providing an open resource to which a DOI can resolve.

Still, the advisory group consensus has been that these barriers are generally surmountable. Most of the questions they had revolved around understanding what a DOI-based workflow would look like from the funder’s perspective, and so we outlined the steps a funder would need to take in order to adopt DOI-based global identifiers.

The DOI-based grant identifiers workflow

A funder registering metadata and creating DOIs for grants would need to support the following workflow:

When a grant is submitted, the funder would assign their own internal identifier for tracking, etc. For example 00-00-05-67-89.
If the grant is accepted, the funder would:

generate a global public identifier for the grant based on the DOI. For example, assuming their prefix was 10.4440, then the global public identifier might become https://doi.org/10.4440/00-00-05-67-89.
create a “landing page” on their website (or wherever they make their grants available online) to which the global public identifier will resolve. The landing page would display a TBD set of metadata describing the grant, as well as a link to the grant itself.
register the generated DOI and a TBD set of metadata with their registration agency (RA) (e.g. Crossref or DataCite). This metadata would include the URL of the landing page defined above.

Once metadata and DOIs are registered with an RA, the funder would have a series of ongoing obligations:

Update locations: If the location of the landing page changes (for example, because of a site restructuring, merger of split of the funding organisation, etc.), the funder would need to update their metadata records to point the DOI to the new location.
Update metadata: If metadata becomes out-of-date (e.g. the status of a grant changes, additional grant-related metadata is added, etc.), the funder would update the relevant records.
Promote the use of the the DOI as the preferred global, public identifier for the grant. That is - the one that people should use when referring to or citing the grant (the funder can continue to use the original local identifier for their internal systems, etc.).

Again, the advisory group thought that this workflow seemed tractable and agreed that the best way to ensure that would be to proceed to creating a working pilot of a global grant identifier system based on the DOI.

Next steps

Crossref is starting a grant identifier pilot. We will create two sub-groups of the funder advisory group.

Group for “Governance, membership, and fees”

This group will look at governance and financial issues raised by the introduction of grant identifiers. For example, it will look at whether Crossref’s membership model works as is or might need to be adjusted in order to accommodate a new constituency. We know, for example, that some funders find it hard to become “members” of organisations. We might need to create other participation categories in order to accommodate these restrictions. Similarly the group will look design a pricing model of DOIs for grants in order to make sure that they cover the costs of modifying and sustaining the system for them, as well as to ensure that the pricing incentivises funders to participate. This sub-group will work closely with Crossref’s membership and fees committee.

Group for “Technical and metadata”

This group will look at any technical changes that need to be made to registration process in order to accommodate the new participants. If there are, they are likely to center around specific metadata requirements for grants. As such, the group will likely spend most of its time agreeing to a practical metadata schema for capturing relevant information about the myriad of ways in which organisations support research. This group will also liaise with other relevant technical working groups, such as those who are looking at organisational identifiers and conference identifiers.

The two sub-groups will first meet in January and, after a few meetings, will report back the advisory group with recommendations. Using these recommendations, we will develop an implementation plan which will include testing the infrastructure, testing metadata deposits, fee modelling, etc, with a small group of participants.

If you are a funder, and you would like to have somebody from your origanization participate in one of these working groups, please contact Ginny Hendricks. Note that joining the above groups does not commit you to anything other than engaging in the discussion. We want to make sure we create a system that works for a range of funders, not just those who can start testing something right away.

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

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

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

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

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

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

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

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

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

Full lineup

View the Crossref LIVE17 agenda.

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.

Meet the members, Part 1 (with Oxfam)

Christine Cormack Wood — Mon, 30 Oct 2017 00:00:00 +0000

Introducing our new blog series Meet the members; where we talk to some of our members and find out a little bit more about them, ask them to share how they use our services, and discuss what their plans for the future are. To start the series we talk to Liam Finnis of Oxfam.

Can you tell us a little bit about Oxfam?

Around the globe, Oxfam works to find practical, innovative ways for people to lift themselves out of poverty and thrive. We save lives and help rebuild livelihoods when crisis strikes. And we campaign so that the voices of the poor influence the local and global decisions that affect them.

Oxfam’s Policy & Practice platform is the gateway to Oxfam’s knowledge, experience, and thinking. Policy & Practice aims to influence, enable and learn from others by sharing and collaborating online with professionals and practitioners.

What’s your role within Oxfam?

My name is Liam Finnis and I am the Website Manager for Oxfam GB’s Policy & Practice site and the Oxfam Digital Repository. In addition to maintenance and development of our platforms, my role focuses on raising the visibility of our programme work including approach and methodology, while also ensuring the availability and accessibility of our publications and resources.

What’s your participation level?

We joined Crossref in 2016, but only really began fully implementing DOIs this year. We have registered 139 content items as of October, with the majority assigned in 2017. While this only constitutes a small number of our total publications (roughly 6%), we’ve focused on current and future publications rather than retroactive application (with a handful of exceptions).

Tell us a bit about what you publish and for whom

We produce roughly 220 publications each year, with a library of 4,450 spanning 40 years. Roughly half of this would be considered grey literature and includes: research reports; evaluations; briefing papers; technical briefings; case studies; guidelines and toolkits. We also publish the Gender & Development Journal with Routledge/Taylor & Francis.

While our organisational focus is on inequalities and the eradication of poverty, this isn’t something we can achieve by looking solely at economic models. Our publications span a range of subject areas including: climate change; food and livelihoods; economics; gender; conflicts and disasters; land rights; and Water, Sanitation and Hygiene (WASH).

Our audience ranges from humanitarian and development practitioners to policy makers to researchers and academics. We publish the research that underpins our campaigns advocacy work; the evaluations of our emergency response efforts; reports outlining the methodologies we’ve applied; briefings on policy and recommendations; and, toolkits and guidelines for research, programme quality and responsible data management.

What do you think makes your publications unique?

Oxfam is one of the only NGOs that is actively sharing an extensive body of knowledge and experience. With 75 years of experience working on a global scale, our publications help to share learning and encourage best practice. Further to that, they showcase the changes (gradual or sudden) that we’ve seen in how development and humanitarian aid is defined and approached through the decades.

The Oxfam Gender Training Manual, published in 1991, remains one of our most frequently accessed resources; still widely regarded as a relevant, unique and valuable resource within the sector. Another of our key publications, Wealth: Having it all and wanting more, was published in 2015, outlining the methodology and data sources for Oxfam’s frequently cited fact ‘85 billionaires have the same wealth as the bottom half of the world’s population’.

The diversity in subject and format of our publications isn’t necessarily unique, but I’m reasonably confident that there is something in our publications that will relate to everyone.

What trends are you seeing in your part of the scholarly publishing community?

This is difficult to quantify as, while we have been lightly engaged with the scholarly publishing community in the past, we’ve been significantly more active in the past year. In addition to more actively applying DOIs, early in 2017 we were included in EBSCO Discovery and in March we made efforts to improve the visibility of our Digital Repository. Previously, the key route was through the Policy & Practice website, which brought together publications with blogs and pages focused on programmes, projects, approaches and methodology.

Since making these two changes we’ve seen a significant increase in access of our resources directly from the repository. This has come in addition to the general usage through Policy & Practice. We are also working with Research4Life, INASP and TEEAL to improve visibility and accessibility of our publications more widely.

How would you describe the value of being a Crossref member?

In the past two years, we’ve been looking into how we can ensure that our publications are visible and accessible to a wider audience. Becoming a member of Crossref and registering content with Crossref is a big part of that. It helps to give us a place in the discussions and events as well as enabling us to better understand and meeting scholarly publishing standards and implement best practice.

What are Oxfam’s plans for the future?

In terms of our work with Crossref and an active role in the scholarly publishing community, we’re still fairly new to it and we’re starting to see some of the benefits of our efforts. In the future, we’re looking to get a better idea of the opportunities available and build on our recent work.

Personally, I’m really interested in exploring Crossref Event Data in greater detail and seeing how it can help us map the impact of our work more effectively.

Thanks, Liam!

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.

Publishers, help us capture Events for your content

Madeleine Watson — Mon, 02 Oct 2017 00:00:00 +0000

The day I received my learner driver permit, I remember being handed three things: a plastic thermosealed reminder that age sixteen was not a good look on me; a yellow L-plate sign as flimsy as my driving ability; and a weighty ‘how to drive’ guide listing all the things that I absolutely must not, under any circumstances, even-if-it-seems-like-a-really-swell-idea-at-the-time, never, ever do.

The margin space dedicated to finger-wagging left little room for championing any driving-do’s. And as each page delivered a fresh new warning, my enthusiasm for hitting the road sunk to levels usually reserved for activities like trigonometry and visits to my orthodontist.

Many years (and an excellent driving record) later, I’m reminded of this again now when thinking about our own Event Data User Guide. Because it contains a chapter with some really important don’ts for our members. Really good, we’d-love-you-to-consider-not-doing-these-things type of advice. But despite our intent to encourage, I feel the ghost of finger-waggers past. So in the spirit of championing enthusiasm over ennui, I thought I’d attempt to contextualise our Event Data Best Practices Guide for Publishers and show you why there’s a lot of good reasons for publishers to be enthusiastic about these rules.

So if you’re a publisher, I encourage you to read on to learn more about how you can help us have the best chance possible of capturing Events for your content.

What’s in it for you? Well, collecting this data helps to give everyone (Crossref, yourself, and others) a better picture of how your content is being used, including for altmetrics.

1. Please let us in

Please do open the door when we come knocking, we promise not to stay long. You can do this by allowing the User Agent CrossrefEventDataBot to visit your site, and whitelisting it if necessary. The bot is how we visit URLs to confirm if they are for an item of content registered with us. The reason why we’re visiting your site could include:

someone tweeted an article landing page
someone discussed it on Reddit
it was linked to from a blog post

The Bot has only one job: to work out the DOI. No information beyond this is stored. Whenever we become aware of a link that we think points to a DOI or an Article Landing Page, we follow it so we can collect the required metadata. Everything in Crossref Event Data is linked via its DOI, so it’s important that we can collect this information.

The bot will identify itself using the standard method. It sets two headers:

Referer: https://eventdata.crossref.org
User-Agent: CrossrefEventDataBot (eventdata@crossref.org)

Once we confirm that a link points to registered content, we then log an Event for the DOI. You should expect our bot to visit no more than once or twice per second, although if there is a period of activity around your articles, you may see higher rates. The bot also takes a sample of DOIs and visits them to work out which domain names belong to our members, so it can maintain a list. This can happen every few weeks. You may see a small number of requests from the bot, but limited to one per second.

If we can’t enter your site to look for metadata though, then we won’t be able to collect Events for your DOIs. So by allowing our bot, you will be helping us to collect Event Data for your registered content.

If you’re worried about traffic on your site, consider sending us your mapping of article landing pages to DOIs. Because Resource URLs aren’t the same as article landing pages, we need more information than the DOI Resource URLs that you already send us.

If you’re running a blog or website (and you’re not a member of Crossref), you may also see our bot visiting, to look for links that comprise Events. Please allow us to visit, so we can record in our Event Data service the fact that your website links to registered content.

2. We ❤️ robots.txt

Robots.txt files are important and we ensure our Event Data Bot respects yours. If we are instructed not to visit a site, we won’t. So if you want us to visit your site in order to check the metadata of your article landing page, please ensure you provide an exception for our Bot, or make sure that you’re not blocking it. Check the restrictions in your file to see if we’re allowed to visit. This is just another way you can help us work for you.

3. Include the DC Identifier

Including good metadata is general best practice for scholarly publishing. When we visit a publisher’s site, we look for metadata embedded in the HTML document (such as DC.Identifier tags that, amongst other things, enable Crossmark to work).

By ensuring you include a Dublin Core identifier meta tag in each of your articles pages, our system can match your landing pages back to DOIs.

Here’s an example:

4. Let us in, even if we don’t bring cookies

We’re like that friend who turns up for dinner without bringing a bottle of wine. And we hope that you’ll be ok with that. Some Publisher sites don’t allow browsers to visit unless cookies are enabled and they block visitors that don’t accept them. If your site does this, we will be unable to collect Events for your DOIs. Allowing your site to be accessed without cookies will help give us the best chance of successfully reading your metadata.

5. We may not speak your language

Sometimes we come across a publisher’s site that won’t render unless JavaScript is enabled. This means that the site won’t show any content to browsers that don’t execute JavaScript. The Event Data Bot does not execute JavaScript when looking for a DOI. This means that if your site requires JavaScript, then we will be unable to collect DOIs for your Events. Consider allowing your site to be accessed without JavaScript. And if this is not possible, then if you ensure you include the tag in the HTML header, then we’ll do our best to collect Events for your registered content.

If you want to pass this on to your friendly system administrator, the best practice is documented in full here: https://www.eventdata.crossref.org/guide/best-practice/publishers-best-practice/. And sorry about all the don’ts you’ll find on that page…. don’t let them curb your enthusiasm for taking Event Data out for a spin!

PIDapalooza is back and wants your PID stories

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

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

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

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

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

Joe Wass reflects:

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

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

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

Ed Pentz on plans for the new organisation IDs

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

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

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

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

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!

Event Data enters Beta

Jennifer Kemp — Wed, 05 Jul 2017 00:00:00 +0000

We’ve been talking about it at events, blogging about it on our site, living it, breathing it, and even sometimes dreaming about it, and now we are delighted to announce that Crossref Event Data has entered Beta.

A collaborative initiative by Crossref and DataCite, Event Data offers transparency around the way interactions with scholarly research occur online, allowing you to discover where it’s bookmarked, linked, liked, shared, referenced, commented on etc., across the web, and beyond publisher platforms.

The name Event Data reflects the nature of the service, as it collects and stores digital actions that occur on the web, from the quick and simple, such as bookmarking and referencing, through to deeper interconnectivity such as exposing the links between research artifacts. Each individual action is timestamped and recorded in our system as an Event, and made available to the community via an API.

Event Data will be available for absolutely anyone to use; publishers, third party vendors, editors, bibliometricans, researchers, authors, funders etc., and with tens of thousands of events occurring every day, there’s a wealth of insight to be gained for those interested in analyzing and interpreting the data.

It’s important to note that Event Data does not provide metrics. What is does provide is the raw data to help you facilitate your own analysis, giving you the freedom to integrate the data into your own systems.

We are currently working very closely with a few organisations with specific use cases who are helping us to test and refine Beta before we launch our production service later this year. If you decide to take a look at Beta yourself, all the data you collect from Event Data is licensed for public sharing and reuse according to our Terms of Use.

Until Event Data is in production mode, we do not recommend building any commercial or customer-based tools off the data. If you are not in the Beta test group but are interested in participating, please contact me below. For more information about Event Data, please see our user guide.

Please contact me, Jennifer Kemp—Outreach Manager for Event Data—with any questions.

The OI Project gets underway planning an open organisation identifier registry

Ed Pentz — Tue, 28 Mar 2017 00:00:00 +0000

At the end of October 2016, Crossref, DataCite, and ORCID reported on collaboration in the area of organisation identifiers. We issued three papers for community comment and after input we subsequently announced the formation of The OI Project, along with a call for expressions of interest from people interested in serving on the working group.

We had a great response and are happy to report that the Working Group has now been established, and is already underway with work to develop a plan for an open, independent, not-for-profit, sustainable, organisation identifier registry.

There is information about the OI Project Working Group on the ORCID website including a list of the 17 working group members. They represent a broad range of scholarly communications stakeholders. Our scope of work includes three separate but interdependent areas:

Governance;
Registry Product Definition; and
Business Model & Funding.

The initial goal of the Working Group is to create a thorough and robust implementation plan by the end of 2017.

Please take a look at the website for more information and we’ll provide updates as things progress throughout the course of the year.

Please contact us with any questions.

Revised Crossref DOI display guidelines are now active

Ed Pentz — Wed, 15 Mar 2017 00:00:00 +0000

We have updated our DOI display guidelines as of March 2017, this month! I described the what and the why in my previous blog post New Crossref DOI display guidelines are on the way and in an email I wrote to all our members in September 2016. I’m pleased to say that the updated Crossref DOI display guidelines are available via this fantastic new website and are now active. Here is the URL of the full set of guidelines in case you want to bookmark it (https://doi.org/10.13003/5jchdy) and a shareable image to spread the word on social media.

This blog is a quick reminder that all Crossref members should now be displaying DOIs in the recommended new format from this month, on any new content you publish online. Please note these guidelines are for Crossref DOIs only, we have nearly 90 million registered but there are others, and not all DOIs are made equal.

The main changes are to display the DOI as a full, linked URL using HTTPS:

https://doi.org/10.xxxx/xxxxx

For background on the HTTPS issue please read Geoffrey Bilder’s blog post, Linking DOIs using HTTPS.

What will happen if you don’t update your Crossref DOI display?

We tell members that they should be working towards making the change even if they can’t do it until later - we recognize that it is not always an easy change to make.

However, if members don’t make the change, nothing immediate will happen (Crossref won’t fine you!) although as more members make the change your display will look odd and out of place compared with other members’ content.

If you have any questions please do not hesitate to contact us.

Taking the "con" out of conferences

Geoffrey Bilder — Wed, 15 Feb 2017 00:00:00 +0000

TL;DR

Crossref and DataCite are forming a working group to explore conference identifiers and project identifiers. If you are interested in joining this working group and in doing some actual work for it, please contact us at community@crossref.org and include the text conference identifiers WG in the subject heading.

All the times I could have gone to Walt Disney World…

Back around 2010 I added a filter to my email settings that automatically flagged and binned any email that contained the word “Orlando.” Back then this was a remarkably effective way of detecting and ignoring spam from the numerous fake technology conferences that all seemed to advertise the city of Orlando, Florida as the location for their non-events. I suspected they all chose Orlando as it would provide the punter that little bit of extra motivation to pay and register for the conference as they simultaneously plotted how they could tag-on some holiday time at Walt Disney World. I finally had to remove the filter last year when I realised that the scammers had moved on to advertising more realistically gritty cities in their calls for submissions and that meanwhile I had managed to miss all the mail informing me of the ALA’s summer 2016 meeting held in, you guessed it… Orlando.

Clearly we need better mechanisms to flag dubious conferences.

Late last year Crossref’s Strategic initiatives group was approached by “CounterMock,” a group of Crossref members (including major proceedings publishers like Springer Nature, Elsevier, IEEE, ACM, IET, etc) who were actively exploring the establishment of an identifier system and registry for scholarly conferences.

The long term goal of the group is to make it easier for publishers, researchers and other stakeholders to identify fraudulent and/or low-quality conferences. There has recently been a proliferation of conferences that seem to have been developed specifically to dupe international and early-career researchers into paying substantial conference and publication fees. Sometimes these conferences are intentionally named after long-standing and well-respected conferences. At worst these conferences are entirely fake - no meetings are held and no publications are issued. At best they produce subpar publications of questionable academic integrity. Members of the group are concerned that these “mock conferences” (Hence “COUNTERMOCK”) will:

Waste researcher time.
Waste publisher time.
Undermine academic trust in conferences and conference proceedings as a trustworthy means of scholarly communication.

The group understands that the “evaluation of a conference quality” and the “unambiguous identification of conferences” are separate concerns (as they are with publications, contributors, etc). But they also realise that it will be hard to address the quality issue without an infrastructure for unambiguously identifying conferences and providing meaningful provenance metadata about those conferences. Moreover, having unique identifiers for conference series would enable a number of other applications. Examples include conference-level metrics, better and more structured info about forthcoming conferences on a certain topic, and more visibility of conferences in research evaluation.

Springer Nature has built a POC prototype of a conference identifier system and shown it to a number of other parties. The feedback has been that there is interest in the project, but that the consensus is that it should be managed a run by a neutral industry group. They have approached us to form a working group and explore how this project can be advanced.

This is all good. Crossref itself doesn’t make value judgements on the quality of content registered with us. Crossref DOIs are not quality marks. But we do believe that unambiguous identification of research artifacts is a perquisite to building effective trust and reputation tools.

It is possible that the issue of conference identifiers can be folded into the work we are doing with DataCite and ORCID on organisation identifiers. For example, some have argued that organisation identifiers should include identifiers for projects or other less formal and more ephemeral corporate entities that are often included in affiliation and/or bibliographic data. It is possible to make the similar arguments in the case of conferences.

On the other hand we have also been interested in the issue of “project identifiers.” Martin Fenner and Tom Demeranville have made a strong argument that ‘projects’ can be thought of as containers for collections of project outputs, project members and project funders. Again, it seems plausible that one could make the same case for conferences.

At the very least it is important to coordinate any work that is done on conference, project and organisation identifiers. This why we have decided to form a joint Crossref/DataCite working group to specifically explore conference and project identifiers and determine how they relate both to each other and to our already ongoing work with ORCID on organisation identifiers.

Additionally, it is likely that the working group will discuss and explore how conference/project identifiers might be used for increasing the transparency of peer review at conferences, better attribution for programme chairs and program committee members, and how they might be incorporated into other services like Crossref Metadata Search, DataCite search, CrossMark, etc.

If you are interested in doing some work on this- then please indicate your interest in joining a working group by sending email to community@crossref.org and include the text conference identifiers WG in the subject heading.

We will update this blog as the group convenes and makes progress.

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!

URLs and DOIs: a complicated relationship

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

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

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

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

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

Full circle

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP redirects

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

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

Extraordinary diversity

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

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

Experiment 1: Does Crossref know all Landing Pages?

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

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

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

We need to tighten up the terminology at this stage:

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

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

So let’s re-word our hypothesis:

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

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

Observations:

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

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

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

Interlude

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

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

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

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

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

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

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

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

Why do we care about identifying publishers anyway?

A Fair Test

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

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

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

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

Why all the redirects?

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

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

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

Internal DOI resolvers

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

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

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

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

Another example from JAMA Surgery:

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

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

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

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

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

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

Hypothesis: Some publishers run their own DOI resolvers.

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

Observations:

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

Conclusions: Some publishers run their own DOI resolvers.

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

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

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

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

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

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

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

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

Assumption 4: Every DOI points somewhere unique

Stop me when you find the deliberate mistake:

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

Two things immediately suggest themselves:

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

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

Experiment 4: Aliased DOIs

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

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

Observations:

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

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

Experiment 5: Duplicate Resource URLs

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

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

Observations:

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

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

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

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

Cookies

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

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

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

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

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

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

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

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

Observations:

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

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

Cookies Required

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

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

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

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

Bring in the Browser

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

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

I have split the ‘destination’ concept into two:

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

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

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

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

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

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

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

Observations:

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

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

Other gnarly things

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

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

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

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

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

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

Interpreting the results

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

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

I have created histograms of domains by their various proportions.

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

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

Our second chart is a histogram of Resource URLs where the Browser-based redirect = the Naive URL. Each domain is given a proportion which represents how many DOIs sampled on that domain require us to fire up a browser.

Overwhelmingly, the Browser Redirect URL is the same as the Naïve Redirect URL, meaning that we don’t need to fire up the browser, we can just use the Naïve URL, which is much easier to compute. There are some resource URL domains which require every DOI to be followed in a browser rather than just following links.

We know from this that we don’t have to use the browser most of the time. There is a small number of domains where we’re unsure (under 500) and a small number of domains where we know that we have to use a browser. This means we can focus our efforts.

There are lots of DOIs and they all behave differently.

There are thousands of publishers out there registering DOIs. There are thousands of domains. Some publishers have lots of domains. This makes it impossible to make many general observations about DOIs.

You can’t tell anything by looking at the DOI

Just by looking at the DOI you can’t tell who published it, or which publisher’s system is hosting it. Therefore you can’t tell how it’s going to behave.

We’ve looked at five kinds of URLs:

The DOI itself
The Resource URL
The “naïve” redirect URL
The “browser” redirect URL
The Article Landing Page

In some cases, the Resource URL, naïve redirect URL, browser redirect and Article Landing Page are the same. In some cases they aren’t. Of these, the fifth is somewhat mythical.

DOIs fall into classifications

Each DOI falls into a category, most preferable first:

The Resource URL is the same as the Landing Page.
The Landing Page can be discovered by following HTTP redirects.
The Landing Page can be discovered by firing up a web browser to follow redirects.
The Landing Page can’t be determined.

We can predictively group DOIs

We can group DOIs by their Resource URLs and take a sample per Resource URL Domain. If all samples for a domain behave a certain way, we can place the DOIs into one of the above four groups with a probability.

We’ll never know the full story.

Because of the diversity of Publisher Systems and the long history of Crossref DOIs, we’ll never be able to describe exactly what’s going on for all DOIs.

What next?

We’re continuing to develop Crossref Event Data. The part of the system that handles turning URLs back into DOIs will never be perfect, but we know from this research that we can at least work with a subset.

I’m also working on another project which will attempt to reverse a Landing Page URL back into a DOI by looking at the metadata on the Landing Page. You can read about it here. Ultimately we’re going to have to take a blended approach. Building a useful set of Landing Page URL to DOI mappings will be part of the mix.

As Event Data matures we’ll be sharing all the datasets automatically as part of our infrastructure, including our DOI-to-URL mapping.

And any members reading, please make your DOIs as easy to follow as possible! Please don’t require JavaScript or cookies when resolving DOIs.

If you’re read this far, perhaps you’re as interested in DOIs as we are. There’s a lot more to say on the subject, but that’s enough for now. See you at PIDapalooza!

Image Credits

All images from Wikipedia Commons. Click or hover on the image to see the attribution.

The Organisation Identifier Project: a way forward

Ed Pentz — Mon, 31 Oct 2016 00:00:00 +0000

The scholarly communications sector has built and adopted a series of open identifier and metadata infrastructure systems to great success. Content identifiers (through Crossref and DataCite) and contributor identifiers (through ORCID) have become foundational infrastructure to the industry.

But there still seems to be one piece of the infrastructure that is missing. There is as yet no open, stakeholder-governed infrastructure for organisation identifiers and associated metadata.

In order to understand this gap, Crossref, DataCite and ORCID have been collaborating to:

Explore the current landscape of organisational identifiers;
Collect the use-cases that would benefit our respective stakeholders in scholarly communications industry;
Identify those use-cases that can be more feasibly addressed in the near term; and
Explore how the three organisations can collaborate (with each other and with others) to practically address this key missing piece of scholarly infrastructure.

The result of this work is in three related papers being released by Crossref, DataCite and ORCID for community review and feedback. The three papers are:

organisation Identifier Project: A Way Forward (PDF; GDoc)
organisation Identifier Provider Landscape (PDF; GDoc)
Technical Considerations for an organisation Identifier Registry (PDF; GDoc)

We invite the community to comment on these papers both via email (oi-project@orcid.org) and at PIDapalooza on November 9th and 10th and at Crossref LIVE16 on November 1st and 2nd. To move The OI Project forward, we will be forming a Community Working Group with the goal of holding an initial meeting before the end of 2016. The Working Group’s main charge is to develop a plan to launch and sustain an open, independent, non-profit organisation identifier registry to facilitate the disambiguation of researcher affiliations.

Crossref Use Cases

Crossref has also been discussing the needs of its members over the last year and there is value in focusing on the affiliation name ambiguity problem with research outputs and contributors. In terms of the metadata that Crossref collects, something that is missing has been affiliations for the authors of publications. Over the last couple of years, Crossref has been expanding what it collects - for example, funding and licensing data and ORCID iDs - and this enables a fuller picture of what we are calling the article nexus. In order to continue to fill out the metadata we collect - and for our members to use in their own systems and publications - we need an organisation identifier.

Another use case for Crossref is identifying funders as part of collecting funder data to enable connecting funding sources with the published scholarly literature. In order to enable the reliable identification of funders in the Crossref system we created the Open Funder Registry that now has over 15,000 funders available as Open Data under a CC0 waiver. While this has been very successful, it is a very narrowly focused registry and is not suitable for a broad, community-run organisation identifier registry that addresses the affiliation use case. In future, our goal will be to merge the Open Funder Registry into the identifier registry that the organisation Identifier Working Group will work on.

By working collaboratively we can define a pragmatic and cost-effective service that will meet a fundamental need of all scholarly communication stakeholders.

Geoffrey Bilder will be focusing his talk at Crossref LIVE16 this week on this initiative, dubbed The OI Project. The talk is scheduled for 2pm UK time and will be live streamed along with the rest of that day’s program.

New Crossref DOI display guidelines are on the way

Ed Pentz — Tue, 27 Sep 2016 00:00:00 +0000

TL;DR

Crossref will be updating its DOI Display Guidelines within the next couple of weeks. This is a big deal. We last made a change in 2011 so it’s not something that happens often or that we take lightly. In short, the changes are to drop “dx” from DOI links and to use “https:” rather than “http:”. An example of the new best practice in displaying a Crossref DOI link is: https://doi.org/10.1629/22161

Hey Ho, “doi:” and “dx” have got to go

The updated Crossref DOI Display guidelines recommend that https://doi.org/ be used and not http://dx.doi.org/ in DOI links. Originally the “dx” separated the DOI resolver from the International DOI Foundation (IDF) website but this has changed and the IDF has already updated its recommendations so we are bringing ours in line with theirs.

We are also recommending the use of HTTPS because it makes for more secure browsing. When you use an HTTPS link, the connection between the person who clicks the DOI and the DOI resolver is secure. This means it can’t be tampered with or eavesdropped on. The DOI resolver will redirect to both HTTP and HTTPS URLs.

Timing and backwards compatibility

We are requesting all Crossref member publishers and anyone using Crossref DOIs to start following the updated guidelines as soon as possible. But realistically we are setting a goal of six months for implementation; we realize that updating systems and websites can take time. We at Crossref will also be updating our systems within six months - we already use HTTPS for some of our services and our new website (coming very soon!) will use HTTPS.

An important point about backwards compatibility is that “http://dx.doi.org/” and “http://doi.org/” are valid and will continue to work forever-or as long as Crossref DOIs continue to work-and we plan to be around a long time.

We need to do better

Reflecting on the 2011 update to the display guidelines it’s fair to say that we have been disappointed. It is still much too common to see unlinked DOIs in the form doi:10.1063/1.3599050 or DOI: 10.1629/22161 or even unlinked in this form: http://dx.doi.org/10.1002/poc.3551

What’s so wrong with this approach? To demonstrate, please click on this DOI doi:10.1063/1.3599050 - oh, you can’t click on it? How about I send you to a real example of a publisher page. What I’d like you to do is click the following link and then copy the DOI you find there and come back - http://dx.doi.org/10.1002/poc.3551.

Are you back? I expect you had to carefully highlight the “10.1063/1.3599050” and then do “edit”, “copy”. That wasn’t too bad but the next step is to put the DOI into an email and send it to someone. But wait - what are they going to do with “10.1063/1.3599050”? It’s useless. If you want it to be useful you’ll have to add “http://doi.org” or https://doi.org/ in the front.

When publishers follow the guidelines it makes things easier - if you go to https://doi.org/10.1063/1.3599050 you’ll note that you can just right click on the full DOI link on the page and get a full menu of options of what to do with it. One of which is to copy the link and then you can easily paste into an email or anywhere else.

However-putting a positive spin on the spotty adherence to the 2011 update to the DOI display guidelines-everyone has another chance with the latest set of updates to make all the changes at once!

More on HTTPS (future-proofing scholarly linking)

We take providing the central linking infrastructure for scholarly publishing seriously. Because we form the link between publisher sites all over the web, it’s important that we do our bit to enable secure browsing from start to finish. In addition, HTTPS is now a ranking signal for Google who gives sites using HTTPS a small ranking boost.

The process of enabling HTTPS on publisher sites will be a long one and, given the number of members we have, it may a while before everyone’s made the transition. But by using HTTPS we are future-proofing scholarly linking on the web.

Some years ago we started the process of making our new services available exclusively over HTTPS. The Crossref Metadata API is HTTPS enabled, and Crossmark and our Assets CDN use HTTPS exclusively. Last year we collaborated with Wikipedia to make all of their DOI links HTTPS. We hope that we’ll start to see more of the scholarly publishing industry doing the same.

So-it’s simple-always make the DOI a full link - https://doi.org/10.1006/jmbi.1995.0238 - even when it’s on the abstract or full text page of the content that the DOI identifies - and use “https://doi.org/”.

Announcing PIDapalooza - a festival of identifiers

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

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

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

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

Register to attend

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

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

Looking forward to seeing you in November!

DOI-like strings and fake DOIs

Geoffrey Bilder — Wed, 29 Jun 2016 00:00:00 +0000

TL;DR

Crossref discourages our members from using DOI-like strings or fake DOIs.

Details

Recently we have seen quite a bit of debate around the use of so-called “fake-DOIs.” We have also been quoted as saying that we discourage the use of “fake DOIs” or “DOI-like strings”. This post outlines some of the cases in which we’ve seen fake DOIs used and why we recommend against doing so.

Using DOI-like strings as internal identifiers

Some of our members use DOI-like strings as internal identifiers for their manuscript tracking systems. These only get registered as real DOIs with Crossref once an article is published. This seems relatively harmless, except that, frequently, the unregistered DOI-like strings for unpublished (e.g. under review or rejected manuscripts) content ‘escape’ into the public as well. People attempting to use these DOI-like strings get understandably confused and angry when they don’t resolve or otherwise work as DOIs. After years of experiencing the frustration that these DOI-like things cause, we have taken to recommending that our members not use DOI-like strings as their internal identifiers.

Using DOI-like strings in access control compliance applications

We’ve also had members use DOI-like strings as the basis for systems that they use to detect and block tools designed to bypass the member’s access control system and bulk-download content. The methods employed by our members have fallen into two broad categories:

Spider (or robot) traps.
Proxy bait.

Spider traps

A “spider trap” is essentially a tripwire that allows a site owner to detect when a spider/robot is crawling their site to download content. The technique involves embedding a special trigger URL in a public page on a web site. The URL is embedded such that a normal user should not be able see it or follow it, but an automated bot (aka “spider”) will detect it and follow it. The theory is that when one of these trap URLs is followed, the website owner can then conclude that the ip address from which it was followed harbours a bot and take action. Usually the action is to inform the organisation from which the bot is connecting and to ask them to block it. But sometimes triggering a spider trap has resulted in the IP address associated with it being instantly cut off. This, in turn, can affect an entire university’s access to said member’s content.

When a spider/bot trap includes a DOI-like string, then we have seen some particularly pernicious problems as they can trip-up legitimate tools and activities as well. For example, a bibliographic management browser plugin might automatically extract DOIs and retrieve metadata on pages visited by a researcher. If the plugin were to pick up one of these spider traps DOI-like strings, it might inadvertently trigger the researcher being blocked- or worse- the researcher’s entire university being blocked. In the past, this has even been a problem for Crossref itself. We periodically run tools to test DOI resolution and to ensure that our members are properly displaying DOIs, Crossmarks, and metadata as per their member obligations. We’ve occasionally been blocked when we ran across the spider traps as well.

Proxy bait

Using proxy bait is similar to using a spider trap, but it has an important difference. It does not involve embedding specially crafted DOI like strings on the member’s website itself. The DOI-like strings are instead fed directly to tools designed to subvert the member’s access control systems. These tools, in turn, use proxies on a subscriber’s network to retrieve the “bait” DOI-like string. When the member sees one of these special DOI-like strings being requested from a particular institution, they then know that said institution’s network harbours a proxy. In theory this technique never exposes the DOI-like strings to the public and automated tools should not be able to stumble upon them. However, recently one of our members had some of these DOI-like strings “escape” into the public and at least one of them was indexed by Google. The problem was compounded because people clicking on these DOI-like strings sometimes ended having their university’s IP address banned from the member’s web site. As you can imagine, there has been a lot of gnashing of teeth. We are convinced, in this case, that the member was doing their best to make sure the DOI-like strings never entered the public. But they did nonetheless. We think this just underscores how hard it is to ensure DOI-like strings remain private and why we recommend our members not use them.

Pedantry and terminology

Notice that we have not used the phrase “fake DOI” yet. This is because, internally, at least, we have distinguished between “DOI-like strings” and “fake DOIs.” The terminology might be daft, but it is what we’ve used in the past and some of our members at least will be familiar with it. We don’t expect anybody outside of Crossref to know this.

To us, the following is not a DOI:

10.5454/JPSv1i220161014

It is simply a string of alphanumeric characters that copy the DOI syntax. We call them “DOI-like strings.” It is not registered with any DOI registration agency and one cannot lookup metadata for it. If you try to “resolve” it, you will simply get an error. Here, you can try it. Don’t worry- clicking on it will not disable access for your university.

http://doi.org/10.5454/JPSv1i220161014

The following is what we have sometimes called a “fake DOI”

10.5555/12345678

It is registered with Crossref, resolves to a fake article in a fake journal called The Journal of Psychoceramics (the study of Cracked Pots) run by a fictitious author (Josiah Carberry) who has a fake ORCID (http://orcid.org/0000-0002-1825-0097) but who is affiliated with a real university (Brown University).

Again, you can try it.

http://doi.org/10.5555/12345678

And you can even look up metadata for it.

https://api.crossref.org/v1/works/10.5555/12345678

Our dirty little secret is that this “fake DOI” was registered and is controlled by Crossref.

Why does this exist? Aren’t we subverting the scholarly record? Isn’t this awful? Aren’t we at the very least hypocrites? And how does a real university feel about having this fake author and journal associated with them?

Well- the DOI is using a prefix that we use for testing. It follows a long tradition of test identifiers starting with “5”. Fake phone numbers in the US start with “555”. Many credit card companies reserve fake numbers starting with “5”. For example, Mastercard’s are “5555555555554444” and “5105105105105100.”

We have created this fake DOI, the fake journal and the fake ORCID so that we can test our systems and demonstrate interoperable features and tools. The fake author, Josiah Carberry, is a long-running joke at Brown University. He even has a Wikipedia entry. There are also a lot of other DOIs under the test prefix “5555.”

We acknowledge that the term “fake DOI” might not be the best in this case- but it is a term we’ve used internally at least and it is worth distinguishing it from the case of DOI-like strings mentioned above.

But back to the important stuff….

As far as we know, none of our members has ever registered a “fake DOI” (as defined above) in order to detect and prevent the circumvention of their access control systems. If they had, we would consider it much more serious than the mere creation of DOI-like strings. The information associated with registered DOIs becomes part of the persistent scholarly citation record. Many, many third party systems and tools make use of our API and metadata including bibliographic management tools, TDM tools, CRIS systems, altmetrics services, etc. It would be a very bad thing if people started to worry that the legitimate use of registered DOIs could inadvertently block them from accessing content. Crossref DOIs are designed to encourage discovery and access- not block it.

And again, we have absolutely no evidence that any of our members has registered fake DOIs.

But just in case, we will continue to discourage our members from using DOI-like strings and/or registering fake DOIs.

This has been a public service announcement from the identifier dweebs at Crossref.

Image Credits

Unless otherwise noted, included images purchased from The Noun Project

Linked Clinical Trials initiative gathers momentum

Kirsty Meddings — Tue, 21 Jun 2016 00:00:00 +0000

We now have linked clinical trials deposits coming in from five publishers: BioMedCentral, BMJ, Elsevier, National Institute for Health Research and PLOS. It’s still a relatively small pool of metadata - around 4000 DOIs with associated clinical trial numbers - but we’re delighted to see that “threads” of publications are already starting to form.

If you look at this article in The Lancet and click on the Crossmark button you will see that in the Clinical Trials section there are links to three other articles reporting on the same trial: two from the American Heart Journal and one from BMJ’s Heart. Readers can navigate between these four articles in three separate journals using the Crossmark functionality- a new set of links and routes for discovery have appeared.

In another example, three articles from PLOS ONE are threaded together around a trial for the treatment of Type 1 diabetes. And here another PLOS journal, Neglected Tropical Diseases links through to a PLOS ONE article about the same trial.

If you publish in the health sciences please do consider joining this exciting initiative so that we can expand these threads and build up the metadata. Read the tech specs here or drop me an email if you have questions.

Where do DOI clicks come from?

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

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

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

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

Top 10 DOI referrals from websites in 2015

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

The top 10 referring domains for the period:

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

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

HTTP vs HTTPS in 2015

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

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

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

Chronograph

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

Getting Started with Crossref DOIs, courtesy of Scholastica

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

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

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

Crossref Event Data: early preview now available

Madeleine Watson — Mon, 18 Apr 2016 00:00:00 +0000

Test out the early preview of Event Data while we continue to develop it. Share your thoughts. And be warned: we may break a few eggs from time to time!

Chicken by anbileru adaleru from the The Noun Project

Want to discover which research works are being shared, liked and commented on? What about the number of times a scholarly item is referenced? Starting today, you can whet your appetite with an early preview of the forthcoming Crossref Event Data service. We invite you to start exploring the activity of DOIs as they permeate and interact with the world after publication.

But first, a bit of background

Discussion around scholarly research increasingly occurs online after publication, for example on blogs, sharing services, social media, and wikis. These ‘events’ occur across the web on numerous platforms and are a critical part of the scholarly enterprise. We are developing an infrastructure service (Crossref Event Data) that collects, stores, and delivers raw data of the events occurring with Crossref DOIs. We will store the data in an open, auditable and portable form for the community to access. Publishers, platforms, funders, bibliometricians and service providers may benefit from access to this raw data, and it can be used to feed into research records or proprietary tools and services that offer aggregation and analysis.

For more information, see our pilot blog post and description of potential use cases.

Collaborative, transparent development

Developers Martin Fenner (DataCite) and Joe Wass (Crossref) enjoy a tofu break

Lagotto, the software originally developed at PLOS, has been extended and improved in a joint effort between DataCite and Crossref. The two DOI Registration Agencies have partnered to envision, build and release the service. On the 13th of April, after a year of collaboration, we jointly released Lagotto 5.0. You can read about the collaboration on the DataCite blog post.

Crossref and DataCite will continue to work closely together to develop Lagotto and the Event Data service. Although Crossref Event Data has mostly Crossref DOIs at launch, you will be able to find DataCite DOIs if they are cited in Crossref or Wikipedia.

All of the software that runs Event Data, including Lagotto, is developed in the open and is open source. Please refer to the Crossref Event Data Technical User Guide for full details.

Preview the data

This service is currently under development with a full launch expected the second half of 2016. Before it is launched however, we invite you to take a look around and preview a subset of the data sources we plan to include. You may experience occasional hiccups while we continue building the service.

At this stage, we are working with data from three sources although we will greatly expand the variety of platforms from which we collect data as development progresses. At this stage, you can view Mendeley bookmarks, Wikipedia references, and Crossref to DataCite links.

Mendeley

Mendeley is a reference manager and academic social network for scholars. View the number of social bookmarks from scholars or groups on Mendeley.

For example, doi.org/10.1016/J.JIP.2016.03.007 currently has 8 readers on Mendeley to date.

Wikipedia

Wikipedia is an online encyclopaedia, the Internet’s largest and most popular general reference work. View references in Wikipedia of Crossref publications in Wikipedia articles in all languages.

For example, doi.org/10.3897/ZOOKEYS.565.7185 was referenced in the Russian Wikipedia page on Oxyscelio

Crossref to DataCite links

DataCite is a global consortium that assigns DOIs to research data. This enables people to find, share, use, and cite data. You can view all the data citations to DataCite research outputs found in Crossref publications (work is underway to make the links found in DataCite metadata available in Event Data).

For example, Global, Regional, and National Fossil-Fuel CO2 Emissions (doi.org/10.3334/CDIAC/00001) dataset has been referenced by six Crossref publications to date. Software links are also included. Another example is PGOPHER (doi.org/10.5523/bris.huflggvpcuc1zvliqed497r2), a general purpose software for simulating and fitting rotational, vibrational and electronic spectra, which has been referenced by seven Crossref publications to date.

Ready to take a spin?

You can explore the Crossref Event Data early preview by visiting http://eventdata.crossref.org and following the links to featured examples within our interim application for inspecting the data, technical documentation, and our Quick Start guide.

This service is currently under development and as such we welcome your thoughts and feedback on the data we are collecting currently from our three active sources. As a reminder, we expect to include the following sources as part of our full service launch later this year (pending confirmation):

[table id=1 /]

We’re also on the lookout for new data sources to investigate for future inclusion in the Event Data service so please do get in touch with requests and recommendations. As we continue to build the service throughout 2016, we will be committing to a model of continuous development so that we can make new sources available as they are completed.

Watch this blog for regular updates on our progress, or subscribe to receive new blog posts by email (just add your details to the upper right side of this page).

The Wikipedia Library: A Partnership of Wikipedia and Publishers to Enhance Research and Discovery

Rachael Lammey — Mon, 04 Apr 2016 00:00:00 +0000

Back in 2014, Geoffrey Bilder blogged about the kick-off of an initiative between Crossref and Wikimedia to better integrate scholarly literature into the world’s largest knowledge space, Wikipedia. Since then, Crossref has been working to coordinate activities with Wikimedia: Joe Wass has worked with them to create a live stream of content being cited in Wikipedia; and we’re including Wikipedia in Event Data, a new service to launch later this year. In that time, we’ve also seen Wikipedia importance grow in terms of the volume of DOI referrals.

Alex Stinson, Project Manager for the Wikipedia Library, and our guest blogger! This file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license (Source: Myleen Hollero Photography)

Alex Stinson, Project Manager for the Wikipedia Library, and guest blogger! This file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license (Source: Myleen Hollero Photography)

How can we keep this momentum going and continue to improve the way we link Wikipedia articles with the formal literature? We invited Alex Stinson, a project manager at The Wikipedia Library (and one of our first guest bloggers) to explain more:

Wikipedia provides the most public gateway to academic and scholarly research. With millions of citations to academic as well as non-academic but reliable sources, like those produced by newspapers, its ecosystem of 5 million English Wikipedia articles and 35 million articles in hundreds of languages provides the first stop for researchers in both scholarly and informal research situations. The practice of “checking Wikipedia” has become ubiquitous in a number of fields; for example, Wikipedia is the most visited source of medical information online, even providing the first stop for many medical students and medical practitioners when looking for medical literature.

The Wikipedia Library program helps Wikipedia’s volunteer editors access and use the best sources in their research and citations. Through partnerships with over fifty leading publishers and aggregators, like JSTOR, Project Muse, Elsevier, Newspapers.com, Highbeam, Oxford University Press and others, we have been able to give over 3000 of our most prolific volunteers access to over 5500 accounts. These are clear, win-win relationships where Wikipedia editors get to use these databases to improve Wikipedia, while in turn linking to authoritative resources and enhancing their discovery.

JSTOR has been working with us since 2012, providing over 500 accounts to our editors. Kristen Garlock at JSTOR writes:

“We’re very happy to collaborate with the Wikipedia Library to provide JSTOR access to Wikipedia editors. Supporting the initiative to increase editor access to scholarly resources and improve the quality of information and sources on Wikipedia has the potential to help all Wikipedia readers. In addition to providing more discoverability for our institutional subscribers, introducing new audiences to the scholarship on JSTOR them discover access opportunities like our Register & Read program.”

There are strong signals that Wikipedia’s role in the citation ecosystem helps ensure the best materials reach the public through its over 400 million monthly readers:

The latest estimates by Crossref show that Wikipedia has risen from the 8th most prolific referrer to DOIs to the 5th.

Two of our access partners have found that around half of the referrals arriving from Wikipedia were able to authenticate into their subscription resources, suggesting that a large portion of our readers can take advantage of subscriptions provided by scholarly institutions.

Wikipedia is highly influential in the open access ecosystem as well, with a recent study showing higher citation rates for OA materials than those behind a paywall.

Altmetrics tools (such as Altmetric.com, ImpactStory or Plum Analytics) are recognizing Wikipedia’s importance by including Wikipedia citations in their impact metrics.

Despite these advances, we think this is only the beginning of Wikipedia’s impact on the landscape of scholarly research and discovery. Wikipedia can become a highly integrated research platform within the broader research ecosystem, where the best scholarship is summarized and discoverable-where Wikipedia effectively becomes the front matter to all research.

However, there are some clear barriers to fulfilling this vision. Currently, most citations on Wikipedia are stored in free-text and not readily available in machine-readable formats; our community is working to fix this. Wikipedia also has major systematic gaps in topics where either we lack volunteer interest or Wikipedia reflects larger systemic biases within society or scholarship.We need the help of volunteers, experts, industry partners, and information technologists to grow Wikipedia’s collection of citations, especially around key missing areas, and to transform existing citations into structured formats.

WikiData, Wikipedia’s sister project which crowdsources structured metadata, offers an excellent opportunity for improving the impact of Wikipedia in research. Having Wikipedia citations stored in this structured ecosystem, connecting metadata with semantic meaning, would allow the citations in Wikipedia to become the backbone for discovery tools which emphasize the hand-curated interrelationships between authoritative sources and the knowledge collected by Wikipedia and Wikidata editors.

We need more collaborators to realize the full vision of Wikipedia supporting research in the most effective ways:

We need help from publishers with subscription databases, to help us give our editors access to the databases through The Wikipedia Library’s access partnership program. These high-quality source materials allow our editors to expose that research in a number of languages and for millions of readers.

We need help from the open access community, to figure out how to better support increased citation and strategic use of open access materials within Wikipedia and other Wikimedia projects. Our community has some ideas, but we need your input and collaboration.

We need your expertise to build our structured metadata ecosystem, by helping Wikidata map and collect citation data.

We need the larger research community to promote Wikipedia as a scholarly communications tool and make contributing to Wikipedia an important part of the social responsibility of experts. Wider citation of sources in Wikipedia ensures widespread discovery and dissemination of that research.

If you think you can help, we invite you to contact us at wikipedialibrary@wikimedia.org or via Twitter @WikiLibrary.

Event Data: open for your interpretation

Madeleine Watson — Thu, 25 Feb 2016 00:00:00 +0000

What happens to a research work outside of the formal literature? That’s what Event Data will aim to answer when the service launches later this year.

Following the successful DOI Event Tracker pilot in Spring 2014, development has been underway to build our new service, newly re-named Crossref Event Data. It’s an open data service that registers online activity (specifically, events) associated with Crossref metadata. Event Data will collect and store a record of any activity surrounding a research work from a defined set of web sources. The data will be made available as part of our metadata search service or via our Metadata API and normalised across a diverse set of sources. Data will be open, audit-able and replicable.

We expect to include the following sources at the launch of the clearinghouse in Q3 (pending final confirmation):

[table id=1 /]

What could you achieve?

Anyone interested in metrics and analytics will have direct and open access to a single collection of DOI activity data of events occurring outside of the formal literature. As Event Data records are time-stamped, you can be assured that the data you receive is both auditable and replicable. Collected and stored by Crossref in the one location, we invite researchers, publishers, funders and altmetrics providers to consider the possibilities Event Data offers to enrich and expand your work.

With such a corpus of open, transferable and auditable raw data at your fingertips, what could you achieve?

General and altmetrics service providers

Crossref Event Data is a centrally-managed resource, therefore as a third party vendor you will have the ability to collect real-time data from a central location to enrich, analyze, interpret and report via your own tools. Using our API, you will gain regular access to our collection of raw, auditable data to feed into your own tools and services ready for aggregation and analysis. Additionally, the optional benefit of an SLA with Crossref will ensure that your clients have access to a reliable and flexible source of event data.

Journal editors

Using the data collected in our service, as an editor you can attract authors by offering data on the audience’s research interest, track the full-scope of article dissemination and gain a better understanding of how the publications you manage compare to each other. By analysing the Event Data records, you can quickly find reviewers based on publication network analysis, identify new areas to grow author submissions and track the reach of submissions selected for publication.

Funders

As a Funder, you can use Event Data to isolate and track the dissemination and usage of the research you funded outside of the scholarly literature. As the data is portable, you can be assured that should a journal move, your ability to track its dissemination moves with it. Using the Event Data records collection, you can:

Efficiently track progress of the research impact of grant awardees in an automated fashion, with the signals most relevant to your organisation

Develop measurements of research engagement at the article level which reflect your mission and current funding priorities

Gain visibility into the potent success stories highlighting the impact of your work for your development campaigns

Analyze trends of past and future funding programs

More effectively pursue your funding strategy and manage your portfolio based on data-driven decision making.

Publishers and publishing platforms

By analyzing and interpreting the Event Data collection, as a publisher or content distributor you can use the records to undertake the following metric-lead analysis to help drive your business needs:

Conduct more robust publication growth analysis across titles, subject areas, or all published literature

Gain a balanced understanding of the engagement on your publications across subject areas, titles, or managing editors

Enhance author services (personalization, content discovery, profile management, etc.)

Focused and data-driven product development of tools and services to drive audience engagement

Provide content distributors data on downstream reach of publications.

Bibliometricians

Event Data heavily supports Bibliometric research by facilitating the tracking of DOI-related research activity across different platforms and channels. As a Bibliometrician, use trusted raw data as the underlying data for your research, which you can easily obtain from Crossref in a single, normalized format across a variety of sources. Additionally, as Event Data data is replicable, portable and auditable, you will be assured of high quality results in your research projects.

Research institutions

All of the stakeholders in your institution, from the research, development and marketing offices to the researchers themselves, will benefit from access to data about where and how your research is being discussed in mainstream and social media. As a research institution, Event Data can help you:

Track dissemination of publications (types of channels, rate of growth, etc.) by members of the institution

Access up-to-date information on the research progress of faculty members, useful for tenure and promotion decisions

View data on downstream impact of publications

Roll up data for custom reporting of department’s research activities

Stay tuned, testing begins soon!

With development work on the MVP (Minimum Viable Product) scheduled to complete shortly, we will soon be releasing a small subset of data sources that are collecting event data as well as a testing environment for interested parties to explore a very preliminary version of the software as we continue to work towards implementation of the full Event Data clearinghouse release in Q3. Look out for our MVP announcement, with full technical specifications and confirmation of the selected initial pull and push sources, over the coming weeks.

Linking clinical trials = enriched metadata and increased transparency

Kirsty Meddings — Mon, 18 Jan 2016 00:00:00 +0000

We will shortly be adding a new feature to Crossmark. In a section called “Clinical Trials” we will be using new metadata fields to link together all of the publications we know about that reference a particular clinical trial.

Most medical journals make clinical trial registration a prerequisite for publication. Trials should be registered with one of the fifteen WHO-approved public trial registries , or with clinicaltrials.gov which is run by the US National Library of Medicine. Once registered, a trial is assigned a clinical trial number (CTN) which is subsequently used to identify that trial in any publications that report on it.

Publications that result from any one trial are likely to be released in multiple journals from different publishers and at different times, for example secondary analyses coming some time after the publication of the initial results. Cross-publisher collaboration is paramount to linking all of these publications together so that researchers, funders, and regulatory agencies can understand the whole set of results from clinical trials. With this in mind, a group of medical publishers, led by BioMedCentral, approached Crossref to establish a working group, and here, they designed an approach to address this problem: “thread” all the various documents together surrounding a clinical trial.

Updated upstream

To implement threaded publications, publishers extract clinical trial numbers from papers, or ask authors to submit those numbers to them. Publishers add the CTNs to the Crossref DOI metadata via three new fields: clinical trial number, clinical trial registry where trial is registered, and trial stage (pre-results, results or post-results of the trial). Crossref has assigned unique IDs to each trial registry (much the same as we have done for funders in our Funder Registry and for the same reason - trial registry names and URIs can change over time and we need a persistent identifier). Using a combination of trial registry ID and clinical trial number, we can easily identify other content in the Crossref database that cites the same trial. Finally, Crossref displays the clinical trial metadata on the respective papers for all participating Crossmark publishers. Crossmark is a convenient place for readers to access the clinical trial information and is readily accessible directly from the journal article (online and PDF versions). And of course all of the data also goes into our open API so that anyone can make use of it.

The reporting of clinical trial results is notoriously inconsistent, something that the AllTrials initiative is also seeking to address. Publishers can help by collecting this information upstream and disseminating it using the existing Crossref infrastructure.

We ask all publishers to deposit the clinical trial data which is so critical to transparency in this area of research, and have already had the first data in from Crossref member the National Institute of Health Research. Once we launch the initial set of linked clinical trials, we will expand coverage of the threaded publications to include all content that reports on or references a clinical trial, from protocol to results to supporting data and systematic reviews.

Stay tuned and watch this space as threaded publications rolls out to journal articles across publishers!

Crossref & the Art of Cartography: an Open Map for Scholarly Communications

Jennifer Lin — Fri, 08 Jan 2016 00:00:00 +0000

In the 2015 Crossref Annual Meeting, I introduced a metaphor for the work that we do at Crossref. I re-present it here for broader discussion as this narrative continues to play a guiding role in the development of products and services this year.

Metadata enable connections

At Crossref, we make research outputs easy to find, cite, link, and assess through DOIs. Publishers register their publications and deposit metadata through a variety of channels (XML, CSV, PDF, manual entry), which we process and transform into Crossref XML for inclusion into our corpus. This data infrastructure which makes possible scholarly communications without restrictions on publisher, subject area, geography, etc. is far more than a reference list, index or directory.

If research builds on what came before, one could claim that the process of knowledge production is partly the story of the very relationships between results disseminated (i.e., publications). So let’s consider each publication as a node in a graph where each has a coordinate and is connected by its citations to other publications (as well those that cite it). Additionally, each is associated with a set of people and places, along with a whole host of elements involved in the research and dissemination process.

But take a wider berth, and we begin to capture relationships between all such contributing agents and objects involved in the research process. Here we find an array of entities belonging to the scholarly graph, including different types of research artifacts, publisher and journal, funders, ORCIDs, peer reviews, publication status updates (corrections, retractions, etc.), citations, license information, additional URLs (machine destinations, hosting platforms, etc.), underlying data, software and protocols, materials, discussions and blog posts, recommendations, reference work mentions, etc. The entities on the graph multiply at an even higher rate as researchers share more outputs across more channels. And over time, the graph expands exponentially, producing a webbing that is far more dense and far more vast than we can currently imagine. Perhaps even to the point we realize Borges’ story where a cartographer builds a map so large it replicates the territory itself (On Exactitude in Science)!

From graph to cartography

At the heart of Borges’s poignant story is the map. Crossref’s graph of scholarly communications could be seen in the same light. It has a representational aspect, which is not purely abstract and can be visualized. Here, a map becomes an incredibly potent metaphor. Each link enabled by publisher-deposited metadata is a new street, bridge, or highway that takes us to a particular place (i.e., entity) of interest. These roads lead to articles, researchers, funders, institutions, etc., and in doing so, make them discoverable. They tell a story about the roles of each in the broader research in the landscape dotted with a plethora of places.

The scholarly web has a growing corpus of more than 78 million publications at this very moment registered with Crossref. On average ten to fifteen thousand new objects appear every day. Maps are all the more essential for getting around in a bewildering environment of new and unfamiliar places, even for known ones in areas of exploding growth. They are critical for orienteering, discovering relationships, identifying sets of associated objects, naming new neighborhoods that emerge (i.e., new research specialties), etc. And if each connection on the map is seen as an event, maps can also represent micro-narratives about the research process and the agents involved. A multi-dimensional map containing all these entities, which serves as an evolving representation of spacetime that is constantly updated and always available, would finally begin to depict the process of scholarly activity as a dynamic, evolving, almost living system.

An open map for scholarly communication

Crossref builds such a scholarly map of the research enterprise and makes it openly available for the entire research ecosystem. Call this a meta map or, more recently, call it metastructure. No matter what name it goes by we call it infrastructure at Crossref.

Crossref’s open map for scholarly communications is a core part of the open information infrastructure for scholarly research. Crossref map data are open, portable, as well as licensed and provisioned for maximum reuse to serve the whole community. This open resource has two entrances: one for humans, another for machines. The Crossref REST API enables machines to traverse this environment and mine it in equal measure to the humans behind them. It is configured so that a robot can learn, a phone can access, and platforms can be built.

OpenStreetMap and Google Maps, both widely used and mature infrastructure maps, are instructive examples when we consider a map of this kind for scholarly communications. Map data can be represented in unlimited ways, depending on any variety of needs and users. Third parties can add content via interactive layers that tell different stories such as health expenditure by country based on GDP and coral reefs at risk. They have a broad base of users across business models from philanthropic services aimed at disaster relief (Refugeemaps.eu) to commercial entities providing drivers with locations on open parking spaces (AppyParking on Google Map, PocketParker on OpenStreetMap). They power platforms and services that build maps for others (MapQuest, MapBox). They have applications far beyond the business of maps. For example, Place picker is a Google Maps widget that supports easy auto-complete the entry of any place or location on a mobile app where typing is a chore. And as far use cases close to home, the two have served as raw data for academic research (ex: workflow for generating multi-agent traffic simulation scenarios, automatic classification of GPS trajectories for transportation modes, etc.).

In kind, the Crossref infrastructure map also supports: the development of any variety of new maps which re-present the data, the makers of map platforms that power the research enterprise, tools that use map data, as well as academic research (bibliometrics). We extract slices of data of common interest from the map and add them as additional layers by which anyone can access and create applications on or across these bands of data:

Contributors (authors, editors, reviewers)
Funding information (funding body, grant number)
Trial & study information (clinical trials registry number, registered report, replication study)
Publication history (versions, updates, revisions, corrections, retractions, dates received/accepted/published)
Peer review (status, type, reviews)
Access indicators (publication license for text & data mining, machine mining URLs)
Resources & associated research artifacts (preprints, figures & tables, datasets, software, protocols, research resource IDs)
Activity surrounding the publication (peer reviews, comments & discussions, bookmarks, social shares, recommendations).

Today, the map powers a host of public and commercial organisations alike for a wide range of scholarly and non-scholarly purposes:

<td style="border: 1px solid #ffffff;">
<ul>
<li>
<span >Indexing services</span>
</li>
<li>
<span >Publishing vendors</span>
</li>
<li>
<span >Peer review systems</span>
</li>
<li>
<span >Reference manager systems</span>
</li>
<li>
<span >Lab & diagnostics suppliers</span>
</li>
<li>
<span >Info management systems</span>
</li>
<li>
<span >Educational tools</span>
</li>
<li>
<span >Data analytics systems</span>
</li>
<li>
<span >Literature discovery services</span>
</li>
</ul>
</td>

Publishers
Funders
Research institutions
Archives & repositories
Research councils
Data centres
Professional networks
Patent offices
Registration Agencies

We will follow up this post to highlight a cross-section of these consumers in the Crossref map ecosystem and elaborate on what & how they have built from our data. An infrastructure map offers endless potential to third parties across publishers, funders, research institutions, and vendors working to serve the scholarly research enterprise.

The art of cartography

In the Crossref Product Management team, we have ambitious plans for map enhancements this year. They focus on expanding information density and ease of access to the data. In the former case, we will introduce a new class of locations where activity surrounding the publications are occurring when we launch the DOI Event Tracker. We will also initiate an extensive publisher campaign to achieve full metadata deposit completeness across our membership. No one can keep pace with the sheer volume of research activity happening online nor wander the Lonely Web of research alone. The more metadata publishers provide for a publication, the more roads lead to its map location. After all, discoverability is closely associated with connectedness on a map. And finally, in the latter case, we will refresh and enhance the user interface to make it more powerful for humans to traverse the ever-changing landscape (as easily as the REST API enables machines!).

I gratefully acknowledge the feedback received from the following who served as generous and insightful sounding boards: Virginia Barbour, Theo Bloom, Martin Eve, Daniel S. Katz, Amye Kenall, Catriona MacCullum, Cameron Neylon, Mark Patterson, Kristen Ratan, Carly Strasser, and Kaitlin Thaney.

Distributed Usage Logging: A private channel for private data

Jennifer Lin — Fri, 04 Dec 2015 00:00:00 +0000

Forty wire telephone switchboard, 1907, Author unknown, Popular Science Monthly Vol 70, Wikimedia Commons.

A few months ago Crossref announced that we will be launching a new service for the community in 2016 that tracks activities around DOIs recording user content interactions. These “events” cover a broad spectrum of online activities including publication usage, links to datasets, social bookmarks, blog mentions, social shares, comments, recommendations, etc. The Event Data service collects the data and make it available to all in an open clearinghouse so that data are open, comparable, audit-able, and portable. These data are all publicly available from external platform partners, and they meet the terms of distribution from each partner.

But Crossref and its members are also concerned about privacy. We recognise that not all data can be made open and public. Particularly if it is sensitive, personally identifiable data about usage. With this in mind, we are also launching an affiliated service, Distributed Usage Logging (DUL), for external parties to transmit sensitive data on user content interactions directly to authorized end points. As researchers are increasingly using “alternative” (non-publisher) platforms to store, access and share literature, publishers are correspondingly interested in incorporating the activity on their publications into their COUNTER reports.

Interested third-party sites might include the following:

Institutional and subject repositories
Aggregator platforms (EBSCOhost, IngentaConnect)
Researcher-oriented social-networking sites (e.g. Academia.edu, ResearchGate, Mendeley)
Reading environments and tools (e.g. ReadCube, Utopia Documents)

For publishers to process such events via their COUNTER-compliant usage reporting streams, they need private usage information and a secure channel by which to receive the data from the external platforms. Crossref will provide a switchboard that will enable these non-publisher platforms can safely transmit private data directly to the publisher.

The work ahead entails close collaboration between Crossref, COUNTER, and the partners who will be sending and receiving the private data. The cross-organisational team will be working towards the following before launch: technical infrastructure development for production service, semantic definition of the usage logging message, assignment and validation of credentials to participants in the scheme, participant integration of the DUL API, and incorporation of this data type into the COUNTER Code of Practice. We will also continue to consult with data privacy and security authorities to ensure that the scheme respects all governmental obligations and community best practice regarding the processing of personal data.

We will share more about the launch of the service as we make progress along the way. Please contact Jennifer Lin for more information.

Auto-Update Has Arrived! ORCID Records Move to the Next Level

Rachael Lammey — Mon, 26 Oct 2015 00:00:00 +0000

Crossref goes live in tandem with DataCite to push both publication and dataset information to ORCID profiles automatically. All organisations that deposit ORCID iDs with Crossref and/or DataCite will see this information going further, automatically updating author records.

We’re cross-posting ORCID’s blog below with all the details:

Since ORCID’s inception, our key goal has been to unambiguously identify researchers and provide tools to automate the connection between researchers and their creative works. We are taking a big step towards achieving this goal today, with the launch of Auto-Update functionality in collaboration with Crossref and [DataCite](https://www.datacite.org/.

There’s already been a lot of excitement about Auto-Update: Crossref’s recent announcement about the imminent launch generated a flurry of discussion and celebration on social media. Our own tweet on the topic was viewed over 10,500 times and retweeted by 60 other accounts.

So why all the fuss? We think Auto-Update will transform the way researchers manage their scholarly record. Until now, researchers have had to manually maintain their record, connecting new activities as they are made public. In ORCID, that meant using Search & Link tools developed by our member organisations to claim works manually. Researchers frequently ask, “Why, if I include my ORCID iD when I submit a manuscript or dataset, isn’t my ORCID record “automagically” updated when the work is published?”

With the launch of Auto-Update, that is just what will happen.

It might seem like magic but there are a few steps to make it work:

Researchers. You need to do two things: (1) use your ORCID iD when submitting a paper or dataset, and (2) authorize Crossref and DataCite to update your ORCID record. In keeping with our commitment to ensuring that researchers maintain full control of their ORCID record, you may revoke this permission at any time, and may also choose privacy settings for the information posted on your record.

Publishers and data centers. These organisations also have two things to do: (1) collect ORCID identifiers during the submission workflow, using a process that involves authentication (not a type-in field!), and (2) embed the iD in the published paper and include the iD when submitting information to Crossref or DataCite.

Crossref and DataCite. Upon receipt of data from a publisher or data center with a valid identifier, Crossref or DataCite can automatically push that information to the researcher’s ORCID record.

More information about how to opt out of this service can be found here: the ORCID Inbox.

Why is this so revolutionary?

A bit of background, first. Crossref and DataCite, both non-profit organisations, are leaders in minting DOIs (Digital Object Identifiers) for research publications and datasets. A DOI is a unique alphanumeric string assigned to a digital object – in this case, an electronic journal article, book chapter, or a dataset. Each DOI is associated with a set of basic metadata and a URL pointer to the full text, so that it uniquely identifies the content item and provides a persistent link to its location on the internet.

Crossref, working with over a thousand scholarly publishers, has generated well over 75 million DOIs for journal articles and book chapters. DataCite works with nearly 600 data centers worldwide and has generated over 6.5 million DOIs to date. Between them, Crossref and DataCite have already received almost a half a million works from publishers and data centers that include an ORCID iD validated by the author/contributor. With Auto-Update functionality in place, information about these articles can transit (with the author’s permission) to the author’s ORCID record.

Auto-Update doesn’t stop at a researcher’s ORCID record. Systems that have integrated ORCID APIs and have a researcher’s ORCID record connected to that system — their faculty profile system, library repository, webpage, funder reporting system — can receive alerts from ORCID. Information can move easily and unambiguously across systems.

This is the beginning of the end for the endless rekeying of information that plagues researchers — and anyone involved in research reporting. Surely something to celebrate!

Questions you may have:

Q. What do I need to do to sign up for auto-update?

You need to grant permission to Crossref and DataCite to post information to your ORCID record. You can do this today by using the Search and Link wizard for DataCite available through the ORCID Registry or the DataCite Metadata Search page. We also have added a new ORCID Inbox, so that you can receive a message from Crossref or DataCite if they receive a datafile with your iD, and you can grant permission directly. See More on the ORCID Inbox.

Q. Will Crossref and DataCite be able to update my ORCID record with already published works for which I did not use my ORCID iD?

No. The auto-update process only applies to those works that these organisations receive that include your ORCID iD. For previous works that did not include your ORCID iD, you will need to use the DataCite and Crossref Search and Link wizards to connect information with your iD.

Q. What information will be posted to my record?

With your permission, basic information about the article (such as title, list of contributors, journal or publisher) or dataset (such as data center name and date of publication) will be posted, along with a DOI that allows users to navigate to the source paper or dataset landing page.

Q. What if my journal or data center doesn’t collect ORCID iDs?

Ask them to! This simple step can be accomplished using either the Public or Member ORCID APIs. Information about integrating ORCID iDs in publishing and repository workflows is publicly available.

DOIs in Reddit

Joe Wass — Wed, 30 Sep 2015 00:00:00 +0000

Skimming the headlines on Hacker News yesterday morning, I noticed something exciting. A dump of all the submissions to Reddit since 2006. “How many of those are DOIs?”, I thought. Reddit is a very broad community, but has some very interesting parts, including some great science communication. How much are DOIs used in Reddit?

(There has since been a discussion about this blog post on Hacker News)

We have a whole strategy for DOI Event Tracking, but nothing beats a quick hack or is more irresistible than a data dump.

What is a DOI?

If you know what a DOI is, skip this! The DOI system (Digital Object Identifier) is a link redirection service. When a publisher puts some content online they could just hand out the URL. But the URL can change, and within a very short space of time, link-rot happens. DOIs are designed to fight link rot. When a publisher mints a DOI to an article they just published, they can change the article’s URL and then update the DOI to point to the new place. DOIs are persistent. They are URLs. They’re also identifiers (kind of like ISBNs), and they’re used in scholarly publishing as to do citations.

Crossref is the DOI registration agency for scholarly publishing. That means mostly things like journal articles. There are other registration agencies, for example, DataCite, who do DOIs for research datasets. But at this point in time, most DOIs are Crossref’s.

What does finding DOIs in Reddit mean?

It means someone used a DOI to cite something! DOIs can be used for any kind of content, but because of the sheer volume of scientific publishing, lots of DOIs are for science. Having a DOI doesn’t say anything about quality or content. But it does indicate that the person who created the DOI probably intended it to be cited. We care because it means that every time a DOI is used a tiny bit of link-rot doesn’t have the opportunity to take hold. Every time something is discussed on Reddit and the DOI is used, it means that archaeologists using the data dump in 100 years will have identifiers to find the things being discussed, even if the web and URLs have long since crumbled to dust.

Or, more likely, in five year’s time when a few URLs will have shuffled around.

The results

DOIs have been used on Reddit since 2008 (the logs start in 2006). After a rocky start, we see hundreds being used per year.

That’s dozens per month.

The best subreddit to find DOIs is /r/Scholar, followed by /r/science. And then a lot of others with one or two per year.

Opportunities

It’s great to see DOIs being used in Reddit. But let’s be honest, it’s not a massive amount.

We have a list of domains that our DOIs point to. They mostly belong to publishers, so every time we see a link to a domain on the list, there’s a chance (not a certainty) that the link could have been made using a DOI. We found a large number of these, orders of magnitude more than DOIs. We’re still crunching the data.

The data

The data is quite large. It’s a 40 Gigabyte download compressed, which comes to about 170 GB that uncompressed. It contains the submissions to reddit between 2006 and 2015, not the comments, so each data point represents a thread of conversation about a DOI.

Reproducibility (updated)

You can find the source code and reproduce the figures at http://github.com/crossref/reddit-dump-experiment. We use Apache Spark for this kind of thing.

The data and methodology are very experimental. You can download all results here:

https://s3-eu-west-1.amazonaws.com/crossref-labs-data/2015-10-06/reddit-dump-experiment.zip

It includes all data for charts in this post, as well as the full list of DOIs, the full list of URLs that could possibly have DOIs, and the full JSON input line for each of these.

More info

Read about our DOI Event Tracking strategy, including our live stream of Wikipedia citations.

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.

DOIs and matching regular expressions

Andrew Gilmartin — Tue, 11 Aug 2015 00:00:00 +0000

We regularly see developers using regular expressions to validate or scrape for DOIs. For modern Crossref DOIs the regular expression is short

/^10.\d{4,9}/[-._;()/:A-Z0-9]+$/i

For the 74.9M DOIs we have seen this matches 74.4M of them. If you need to use only one pattern then use this one.

The other 500K are mostly from Crossref’s early days when the battle between “human-readable” identifiers and “opaque” identifiers was still being fought, the web was still new, and it was expected that “doi” would become as well a supported URI schema name as “gopher”, “wais”, …. Ok, that didn’t go so well.

An early Crossref’s member was John Wiley & Sons. They faced the need to design DOIs without much prior work to lean on. Many of those early DOIs are not expression friendly. Nevertheless, they are still valid and valuable permanent links to the work’s version of record. You can catch 300K more DOIs with

/^10.1002/[^\s]+$/i

While the DOI caught is likely to be the DOI within the text it may also contain trailing characters that, due to the lack of a space, are caught up with the DOI. Even the recommended expression catches DOIs ending with periods, colons, semicolons, hyphens, and underscores. Most DOIs found in the wild are presented within some visual design program. While pleasant to look at the visual design can misdirect machines. Is the period at the end of the line part of the DOI or part of the design? Is that endash actually a hyphen? These issues lead to a DOI bycatch.

Adding the following 3 expressions with the previous 2 leaves only 72K DOIs uncaught. To catch these 72K would require a dozen or more additional patterns. Each additional pattern, unfortunately, weakens the overall precision of the catch. More bycatch.

/^10.\d{4}/\d+-\d+X?(\d+)\d+<[\d\w]+:[\d\w]*>\d+.\d+.\w+;\d$/i

/^10.1021/\w\w\d++$/i

/^10.1207/[\w\d]+\&\d+_\d+$/i

Crossref is not the only DOI Registration Agency and while our members account for 65-75% of all registered DOIs this means there are tens of millions of DOIs that we have not seen. Luckily, the newer RAs and their publishers can copy our successes and avoid our mistakes.

Rehashing PIDs without stabbing myself in the eyeball

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

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

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

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

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

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

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

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

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

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

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

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

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

January 2015 DOI Outage: Followup Report

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

Background

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

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

The Gory Details

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

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

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

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

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

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

What do we mean by “persistent?”

@kaythaney tweets on definition of “persistent”

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

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

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

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

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

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

What do we mean by “persistent identifiers?”

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

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

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

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

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

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

Turtles all the way down*

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

@iainh_z tweets to Crossref enquiring about failed DOI resoluton

@LibSkrat tweets at Crossref about DOI outage

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

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

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

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

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

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

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

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

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

10.5555/12345678

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Protecting ourselves

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

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

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

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

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

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

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

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

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

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

@kevingashley tweets asking for followup analysis

@WilliamKilbride tweets asking for followup and lessons learned

Image Credits

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

Crossref’s DOI Event Tracker Pilot

Geoffrey Bilder — Mon, 02 Mar 2015 00:00:00 +0000

TL;DR

Crossref’s “DOI Event Tracker Pilot”- 11 million+ DOIs & 64 million+ events. You can play with it at: http://goo.gl/OxImJa

Tracking DOI Events

So have you been wondering what we’ve been doing since we posted about the experiments we were conducting using PLOS’s open source ALM code? A lot, it turns out. About a week after our post, we were contacted by a group of our members from OASPA who expressed an interest in working with the system. Apparently they were all about to conduct similar experiments using the ALM code, and they thought that it might be more efficient and interesting if they did so together using our installation. Yippee. Publishers working together. That’s what we’re all about.

So we convened the interested parties and had a meeting to discuss what problems they were trying to solve and how Crossref might be able to help them. That early meeting came to a consensus on a number of issues:

The group was interested in exploring the role Crossref could play in providing an open, common infrastructure to track activities around DOIs, they were not interested in having Crossref play a role in the value-add services of reporting on an interpreting the meaning of said activities.
The working group needed representatives from multiple stakeholders in the industry. Not just open access publishers from OASPA, but from subscription based publishers, funders, researchers and third party service providers as well.
That it was desirable to conduct a pilot to see if the proposed approach was both technically feasible and financially sustainable.

And so after that meeting, the “experiment” graduated to becoming a “pilot.” This Crossref pilot is based on the premise that the infrastructure involved in tracking common information about “DOI events” can be usefully separated from the value-added services of analysing and presenting these events in the form of qualitative indicators. There are many forms of events and interactions which may be of interest. Service providers will wish to analyse, aggregate and present those in a range of different ways depending on the customer and their problem. The capture of the underlying events can be kept separate from those services.

In order to ensure that the Crossref pilot is not mistaken for some sub rosa attempt to establish new metrics for evaluating scholarly output, we also decided eschew any moniker that includes the word “metrics” or synonyms. So the “ALM Experiment” is dead. Long live the “”DOI Event Tracker” (DET) pilot. Similarly PLOS’s open source “ALM software” has been resurrected under the name “Lagotto.”

The Technical Issues

Crossref members are interested in knowing about “events” relating to the DOIs that identify their content. But our members face a now-classic problem. There are a large number of sources for scholarly publications (3k+ Crossref members) and that list is still growing. Similarly, there are an unbounded number of potential sources for usage information. For example:

Supplemental and grey literature (e.g. data, software, working papers)
Orthogonal professional literature (e.g. patents, legal documents, governmental/NGO/IGO reports, consultation reports, professional trade literature).
Scholarly tools (e.g. citation management systems, text and data mining applications).
Secondary outlets for scholarly literature (institutional and disciplinary repositories, A&I services).
Mainstream media (e.g. BBC, New York Times).
Social media (e.g. Wikipedia, Twitter, Facebook, Blogs, Yo).

Finally, there is a broad and growing audience of stakeholders who are interested in seeing how the literature is being used. The audience includes publishers themselves as well as funders, researchers, institutions, policy makers and citizens.

Publishers (or other stakeholders) could conceivably each choose to run their own system to collect this information and redistribute it to interested parties. Or they can work with a vendor to do the same. But either case, they would face the following problems:

The N sources will change. New ones will emerge. Old ones will vanish.
The N audiences will change. New ones will emerge. Old ones will vanish.
Each publisher/vendor will need to deal with N source’s different APIs, rate limits, T&Cs, data licenses, etc. This is a logistical headache for both the publishers/vendors and for the sources.
Each audience will need to deal with N publisher/vendor APIs, rate limits, T&Cs, data licenses, etc. This is a logistical headache for both the audiences and for the publishers.
If publishers/vendors use different systems which in turn look at different sources, it will be difficult to compare or audit results across publishers/vendors.
If a journal moves from one publisher to another, then how are the metrics for that journal’s articles going to follow the journal?

And then there is the simple issue of scale. Most parties will be interested in comparing the data that they collect for their own content, with data about their competitors. Hence, if they all run their own system, they will each be querying much more than their own data. If, for example, just the commercial third-party providers were interested in collecting data covering the formal scholarly literature, they would each find themselves querying the same sources for the same 80 million DOIs. To put this into perspective, to refresh the data for 10 million DOIs once a month, would require sources to support ~ 14K API calls an hour. 60 million DOIs would require 100K API calls an hour. Current standard API caps for many of the sources that people are interested in querying hover around 2K per hour. We may see these sources lift that cap for exceptional cases, but they are unlikely to do so for many different clients all of whom are querying essentially the same thing.

These issues typify the “multiple bilateral relationships” problem that Crossref was founded to try and ameliorate. When we have many organisations trying to access the exact same APIs to process the exact same data (albeit to different ends), then it seems likely that Crossref could help make the process more efficient.

Piloting A Proposed Solution

The Crossref DET pilot aims to show the feasibility of providing a hub for the collection, storage and propagation of DOI events from multiple sources to multiple audiences.

Data Collection

Pull: DET will collect DOI event data from sources that are of common interest to the membership, but which are unlikely to make special efforts to accommodate the scholarly communications industry. Examples of this class of source include large, broadly popular services like FaceBook, Twitter, VK, Sina Weibo, etc.
Push: DET will allow sources to send DOI event data directly to Crossref in one of three ways:
- Standard Linkback: Using standards that are widely used on the web. This will automatically enable linkback-aware systems like WordPress, Moveable Type, etc. to alert DET to DOI events.
- Scholarly Linkback: A to-be-defined augmented linkback-style API which will be optimized to work with scholarly resources and which will allow for more sophisticated payloads including other identifiers (e.g. ORCIDs, FundRefs), metadata, provenance information and authorization information. This system could be used by tools designed for scholarly communications. So, for example, it could be used by publisher platforms to distribute events related to downloads or comments within their discussion forums. It could also be used by third party scholarly apps like Zotero, Mendeley, Papers, Authorea, IRUS-UK, etc. in order to alert interested parties in events related to specific DOIs.
- Redirect: DET will also be able to serve as a service discovery layer that will allow sources to push DOI event data directly to an appropriate publisher-controlled endpoint using the above scholarly linkback mechanism. This can be used by sources like repositories in order to send sensitive usage data directly to the relevant publishers.

Data Propagation

Parties may want to use the DET in order to propagate information about DOI events. The system will support two broad data propagation patterns:

one-to-many: DOI events that are commonly harvested (pulled) by the DET system from a single source will be distributed freely to anybody who queries the DET API. Similarly, sources that push DOI events via the standard or scholarly linkback mechanisms, will also propagate their DOI events openly to anybody who queries the DET API. DOI events that are propagated in either of these cases will be kept and logged by the DET system along with appropriate provenance information. This will be the most common, default propagation model for the DET system.
one-to-one: Sources of DOI events can also report (push) DOI event data directly to owner of the relevant DOI if the DOI owner provides & registers a suitable end-point with the DET system. In these cases, data sources seeking to report information relating to a DOI, will be redirected (with a suitable 30X HTTP status and relevant headers) to the end-point specified by the DOI owner. The DET system will not keep the request or provenance information. One-to-one propagation model is designed to handle use cases where the source of the DOI event has put restrictions on the data and will only share the DOI events with the owner (registrant) of the DOI. This use case may be used, for example, by aggregators or A&I services that want to report confidential data directly back to a publisher. The advantage of the redirect mechanism is that Crossref is not put into the position of having to secure sensitive data as said data will never reside on Crossref systems.

Note that the two patterns can be combined. So, for example, a publisher might want to have public social media events reported to the DET and propagated accordingly, but to also to private third parties report confidential information directly to the publisher.

So Where Are We?

So to start with, the DET Working Group has grown substantially since the early days and we have representatives from a wide variety of stakeholders. The group includes:

Cameron Neylon, PLOS
Chris Shillum, Elsevier
Dom Mitchell, Co-action Publishing
Euan Adie, Altmetric
Jennifer Lin, PLOS
Juan Pablo Alperin, PKP
Kevin Dolby, Wellcome Trust
Liz Ferguson, Wiley
Maciej Rymarz, Mendeley
Mark Patterson, eLife
Martin Fenner, PLOS
Mike Thelwell, U Wolverhampton
Rachel Craven, BMC
Richard O’Beirne, OUP
Ruth Ivimey-Cook, eLife
Victoria Rao, Elsevier

As well as the usual contingent of Crossref cat-herders including: Geoffrey Bilder, Rachael Lammey & Joe Wass.

When we announced the then-DET experiment, we said that one of the biggest challenges would be to create something that scaled to industry levels. At launch, we only loaded in about 317,500+ Crossref DOIs representing publications from 2014 and we could see the system was going to struggle. Since then Martin Fenner and Jennifer Lin at PLOS have been focusing on making sure that the Lagotto code scales appropriately and now it is currently humming along with just over 11.5 million DOIs for which we’ve gathered over 64 million “events.” We aren’t worried about scalability on that front any more.

We’ve also shown that third parties should be able to access the API to provide value added reporting and metrics. As a demonstration of this, PLOS configured a copy of its reporting software “Parascope” to point at the Crossref DET instance. The next step we’re taking is to start testing the “push” API mechanism and the “point-to-point redirect” API mechanism. For the push API, we should have a really exciting demo available to show within the next few days. And on the point-to-point redirect, we have a sub-group exploring how the point-to-point redirect mechanism could potentially be used for reporting COUNTER stats as a compliment to the Sushi initiative.

The other major outstanding task we have before us is to calculate what the costs will be of running the DET system as a production service. In this case we expect to have some pretty accurate data to go on as we will have had close to half a year of running the pilot with a non-trivial number of DOIs and sources. Note that the work group is concerned to ensure that the underlying data from the system remains open to all. Keeping this raw data open as seen as critical to establishing trust in the metrics and reporting systems that third parties build on the data. The group has also committed to leaving the creation of value-add services to third parties. As such we have been focusing on exploring business models based around service-level-agreement backed versions of the API to complement the free version of the same API. The free API will come with no guarantees of uptime, performance characteristics or support. For those users that depend on the API in order to deliver their services, we will offer paid-for SLA-backed versions of the free APIs. We can then configure our systems so that we can independently scale these SLA-backed APIs in order to meet SLA agreements.

Our goal is to have these calculations complete in time for the working group to make a recommendation to the Crossref board meeting in July 2015.

Until then, we’ll use CrossTech as a venue for notifying people when we’ve hit new milestones or added new capabilities to the DET Pilot system.

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

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

Hell’s teeth.

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

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

Now for the embarrassing stuff…

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

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

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

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

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

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

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

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

CNRI Statement

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

♫ Researchers just wanna have funds ♫

Geoffrey Bilder — Thu, 10 Apr 2014 00:00:00 +0000

photo credit

Summary

You can use a new Crossref API to query all sorts of interesting things about who funded the research behind the content Crossref members publish.

Background

Back in May 2013 we launched Crossref’s FundRef service. It can be summarized like this:

Crossref keeps and manages a canonical list of Funder Names (ephemeral) and associated identifiers (persistent).
We encourage our members (or anybody, really- the list is available under A CC-Zero license waiver) to use this list for collecting information on who funded the research behind the content that our members publish.
We then ask that our members deposit this data in their normal Crossref metadata deposits.

And that was cool.

But then people started asking us awkward questions. Questions like “what can I do with the funder data?” and “how do I query it?”.

Stoopit people.

Can’t you just let us bask for a few minutes in the sunny glow of actually conceiving of and launching a project within a year?

But seriously, funders, were interested to see how they could use the funder metadata being collected in Crossref. In particular, some funding agencies were interested in being able to measure Key Performance Indicators (“KPIs” to management wonks) related to recent mandates such as the February 22nd 2013 OSTP memo, Public Access to the Results of Federally Funded Research. Two groups also approached us, CHORUS and SHARE. Both are interested in exploring how to build reporting tools for funders, institutions and researchers and each brought us a gigantic hairball of use-cases they were hoping we would be able to meet.

Conveniently, we were in the process of creating a revised, modern Crossref API that is entirely buzzword-compliant, and so we set to work…

We thought people might be interested in seeing what you can do with the Crossref REST API in relation to funding information and the expectations that are increasingly being attached to them. CHORUS is already using the Crossref REST API heavily and we expect that SHARE will soon start making use of it as well. The feedback from both groups has been very useful, but we are looking for broader feedback as well. The API is still in development, so now is your chance to help us shape it.

Brief Examples

Please note, the following are APIs calls, although you can copy and paste the URIs into your browser, the data is returned in a machine readable representation called JSON. If you want the results to look a little more presentable, we advise you install the JSONView plugin:

Firefox Users: JSONView
Chrome Users: JSONView

Also note that publishers have only just started to deposit the metadata needed for these APIs to work, so the data is currently sparse. We know that many of our members are working feverishly to populate more of the needed metadata, but this requires updates to the their manuscript tracking systems, production systems and hosting systems. It takes time.

But for now you can paste the relevant URIs below into your browser and see the results that we do have. Expect these numbers to increase sharply over the next few months

To start with, you might want to know how many articles in Crossref have FundRef metadata:

https://api.crossref.org/v1/works?filter=has-funder:true&rows=0

You could then be interested in knowing how many works in Crossref use FundRef to credit the United States’ National Science Foundation (NSF) for funding their research? First you need to find out what the FundRef identifier is for the NSF:

https://api.crossref.org/v1/funders?query=NSF

You can see that there are several entries that match “NSF”, and that the one we are looking for has the identifier http://dx.doi.org/10.13039/100000001. Remember, funding agency names can change frequently, the ID provides a persistent link to the funder even if their name changes.

If you are curious, you can see the details for the NSF entry, including its location, parent and child organisations:

https://api.crossref.org/v1/funders/10.13039/100000001

Notice that the results also lists the work-count. This is the number of works in the Crossref metadata that list the US NSF as having funded the research.

So perhaps you would like to see the list of works. The following will list the first twenty:

https://api.crossref.org/v1/funders/10.13039/100000001/works

You can page through the results with the offset argument:

https://api.crossref.org/v1/funders/10.13039/100000001/works?offset=20
https://api.crossref.org/v1/funders/10.13039/100000001/works?offset=40
...

How many works that have listed the NSF as a funder have license information:

https://api.crossref.org/v1/funders/10.13039/100000001/works?filter=has-license:true&rows=0

Lets see the first batch that have license information:

https://api.crossref.org/v1/funders/10.13039/100000001/works?filter=has-license:true

Lets look at the metadata for one of the DOIs returned:

https://api.crossref.org/v1/works/10.1063/1.3593378

Interesting, the metadata shows an article published by AIP. It includes license information (CC-BY 3.0) as well as a link to the full text. If you follow the link to the full text, you can retrieve it:

http://link.aip.org/link/applab/v98/i21/p216101/pdf/CHORUS

Wow- A pretty short article. But you can see that it does credit the NSF and that the award number recorded in the text is the same as the award number recorded in the FundRef section of the Crossref metadata. Yay.

You can see in the brief examples above that there is a lot of other metadata you may want to query on and explore. It can include ORCIDS, information about archiving arrangements- even abstracts. It all depends on what the Crossref member has decided to provide.

You can get a simple overview of what a Crossref member has provided by looking at a member summary. Here is an example for Hindawi:

https://api.crossref.org/v1/members?query=hindawi

Note again that names are fickle, so the above query can also be accomplished using the member identifier like this:

https://api.crossref.org/v1/members/98

Groovy init?

If you want more pointers on where you can learn how to use the API, read on…

The Future of the Crossref REST API.

Our aim is for the Crossref REST API to go into production this Summer (2014). As with most of our newer APIs, there will be a free API for public use and a paid for API for professional use. The only difference between the two will be that the professional version will come with a service level agreement (SLA) covering uptime, response time and support. Naturally, this also means that the professional one will be on dedicated hosting equipment so that we can meet these SLAs, whereas the performance of the free version will be subject to the vicissitudes inherent in using a shared, constrained resource (i.e. the server and network it is running on).

Again, the basics of the API are in place. It should be fairly stable, but we do reserve the right to make changes to it over the next few months. Please send us feedback.

— The Weasel

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/10.5240/B1FA-0EEC-C316-3316-3A73-L

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

b) http://dx.doi.org/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/10.6084/m9.figshare.93964

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

d) http://dx.doi.org/10.2307/466856

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

e) http://dx.doi.org/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/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/10.6084/m9.figshare.91541

i) http://dx.doi.org/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/10.1364/AO.39.005477

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

These journals assigned DOIs, but not through Crossref:

l) http://dx.doi.org/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/10.3205/cto000081

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

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

p) http://dx.doi.org/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/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/

https://ui.eidr.org/search

https://www.medra.org/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.

DataCite supporting content negotiation

Geoffrey Bilder — Mon, 10 Oct 2011 00:00:00 +0000

In April In April for its DOIs. At the time I cheekily called-out DataCite to start supporting content negotiation as well.

Edward Zukowski (DataCite’s resident propellor-head) took up the challenge with gusto and, as of September 22nd DataCite has also been supporting content negotiation for its DOIs. This means that one million more DOIs are now linked-data friendly. Congratulations to Ed and the rest of the team at DataCite.

We hope this is a trend. Back in June Knowledge Exchange organized a seminar on Persistent Object Identifiers. One of the outcomes of the meeting was “Den Haag Manifesto” a document outlining five relatively simple steps that different persistent identifier systems could take in order to increase interoperability. Most of these steps involved adopting linked data principles including support for content negotiation. We look forward to hearing about other persistent identifiers adopting these principles over the next year.

Having said that, this time I will refrain from calling-out anybody specifically…

Content Negotiation for Crossref DOIs

Geoffrey Bilder — Tue, 19 Apr 2011 00:00:00 +0000

So does anybody remember the posting DOIs and Linked Data: Some Concrete Proposals?

Well, we went with option “D.”

From now on, DOIs, expressed as HTTP URIs, can be used with content-negotiation.

Let’s get straight to the point. If you have curl installed, you can start playing with content-negotiation and Crossref DOIs right away:

curl -D - -L -H   “Accept: application/rdf+xml” “http://dx.doi.org/10.1126/science.1157784”

curl -D - -L -H   “Accept: text/turtle” “http://dx.doi.org/10.1126/science.1157784”

curl -D - -L -H   “Accept: application/atom+xml” “http://dx.doi.org/10.1126/science.1157784”

Or if you are already using Crossref’s “unixref” format:

curl -D - -L -H “Accept: application/unixref+xml” “http://dx.doi.org/10.1126/science.1157784&#8221;

This will work with over 46 million Crossref DOIs as of today, but the beauty of the setup is that from now on, any DOI registration agency can enable content negotiation for their constituencies as well. DataCite- we’re looking at you 😉 .

It also means that, as registration agency members (Crossref publishers, for instance) start providing more complete and richer representations of their content, we can simply redirect content-negotiated requests directly to them.

We expect that that this development will round-out Crossref’s efforts to support standard APIs including OpenURL and OAI_PMH and we look forward to seeing DOIs increasingly used in linked data applications.

Finally, Crossref would just like to thank the IDF and CNRI for their hard work on this as well as Tony Hammond and Leigh Dodds for their valuable advice and persistent goading.

XMP in RSC PDFs

Crossref — Tue, 03 Aug 2010 00:00:00 +0000

Just a quick heads-up to say that we’ve had a go at incorporating InChIs and ontology terms into our PDFs with XMP. There isn’t a lot of room in an XMP packet so we’ve had to be a bit particular about what we include.

InChIs: the bigger the molecule the longer the InChI, so we’ve standardized on the fixed-length InChIKey. This doesn’t mean anything on its own, so we’ve gone the Semantic Web route of including an InChI resolver HTTP URI. Alternatively you can extract the InChIKeys with a regular expression.
Ontology terms: we’re using HTTP URIs again and pointing to either Open Biomedical Ontology URIs (biology, biomedicine; slashy) or RSC ontology terms (chemistry; hashy). Often the OBO URIs resolve to a specific web page, but for the moment the RSC URIs just point to a large OWL file. Slashy URIs are quite a bit more involved so we’ll have to see what the demand is like.

There’s only about 4K to play with, so it’s only ever going to be a best-of. More detailed article metadata has to go in either a sidecar file, as Tony has pointed out before, or ideally on the article landing page. The example files are here and I’ve posted something with a different slant on the RSC technical blog.

DOIs and Linked Data: Some Concrete Proposals

Geoffrey Bilder — Thu, 25 Mar 2010 00:00:00 +0000

Since last month’s threads (here, here, here and here) talking about the issues involved in making the DOI a first-class identifier for linked data applications, I’ve had the chance to actually sit down with some of the thread’s participants (Tony Hammond, Leigh Dodds, Norman Paskin) and we’ve been able sketch-out some possible scenarios for migrating the DOI into a linked data world.

I think that several of us were struck by how little actually needs to be done in order to fully address virtually all of the concerns that the linked data community has expressed about DOIs. Not only that- but in some of these scenarios we would put ourselves in a position to be able to semantically-enable over 40 million DOIs with what amounts to the flick of a switch.

Given the huge interest in linked data on the part of researchers and Crossref members- it seems like it would be a fantastic boon to both the IDF (International DOI Foundation) and Crossref if we were able to do something quickly here.

Anyway- The following are notes outlining several concrete proposals for addressing the limitations of DOIs as identifiers in linked data applications. They range in complexity/effort involved- with the simplest scenario providing minimal (yet functional) LD capabilities for just one RA’s members (Crossref’s) and the most complex providing per-RA and per-RA-member configurability on how DOIs would behave for LD applications.

We’d appreciate comments, questions, suggestions, corrections, etc.

A: Simplest Scenario

What would need to be done?

Crossref implements a linked data service. For example, hosted at rdf.crossref.org.
Crossref recommends that any member publisher who wants to add rudimentary linked data capabilities to their site could simply insert some simple link elements into their landing Pages. So, for instance, for the article with the DOI 10.5555/1234567 in the Journal of Psychoceramics, the publisher would put the following in the landing page for the article:

<link rel="primarytopic" href="http://doi.crossref.org/10.5555/1234567" /> <link rel="alternate" type="application/rdf+xml" href="http://rdf.crossref.org/metadata/10.5555/1234567.rdf" title="RDF/XML version of this document"/> <link rel="alternate" type="text/html" href="http://www.journalofpsychoceramics.org/10.5555/1234567.html" title="HTML version of this document"/> <link rel="alternate" type="application/json" href="http://rdf.crossref.org/metadata/10.5555/1234567.json" title="RDF/JSON version of this document"/> <link rel="alternate" type="text/turtle" href="http://rdf.crossref.org/metadata/10.5555/1234567.ttl" title="Turtle version of this document"/>

In the above snippet the HTML version of the document is the publisher’s existing landing page.

How it would work

A sem-web-enabled browser would query dx.doi.org/10.5555/1234567 and get a normal 302 redirect to the publisher’s landing page.
The sem-web-enabled browser would sniff the page for the link elements and retrieve the representations it wanted from rdf.crossref.org
The returned document would contain an appropriate representation of the metadata that the publisher has deposited with Crossref. It would also assert that:

doi.crossref.org/10.5555/12334567 owl:sameAs dx.doi.org/10.5555/1234567 . dx.doi.org/10.5555/12334567 owl:sameAs info:doi/10.5555/12334567</p> info:doi/10.5555/12334567 owl:sameAs doi:10.5555/1234567

Alternatively, the publisher could implement their own linked data support on their own domain using whatever appropriate method they want. So, for instance, a larger publisher could support content negotiation at their site and return different/enhanced metadata, etc.

Pros

Doesn’t require changes at DOI/Handle levels
Is easy for publisher to opt-in or opt-out
Requires minimal development on the part of Crossref.

Cons

Only applies to Crossref DOIs.
It depends on publishers taking action. Might be a long time before publishers add the needed links to their landing pages or support content negotiation.
DOI system is still not strictly LD compliant (e.g. it is returning 302 redirects. Naive sem-web browsers might ‘stop’ after getting a 302. Should ideally use 303s, content negotiation, etc.)
Doesn’t work for DOIs that currently bypass landing pages and which go directly to content.

B: Simple + IDF Global Semantic Compliance

What would need to be done?

Same as “Simplest Scenario”
IDF globally changes dx.doi.org to return 303 redirect

How would it work?

Same as Simplest Scenario, except that, because sem-web-enabled browser had been told it was being redirected to a NIR (via the 303), it would presumably be more likely to continue.

Pros

All DOIs conform to expectations for LD identifiers
Easy for publisher to opt-in or opt-out
Requires minimal development on part of Crossref
Requires minimal work (?) on part of IDF

Cons

Requires global change on part of IDF. Global change might conflict with requirements of other RAs.
It depends on publishers taking action. Might be a long time before publishers add needed links to their landing pages or support content negotiation.
Doesn’t work for DOIs that currently bypass landing pages (e.g. OECD spreadhseets, UICR datasets, etc.)

C: Simple + IDF Global Semantic Compliance + RA CN Intercept

What would need to be done?

Same as “B: Simple + IDF Global Semantic Compliance” Scenario
IDF changes dx.doi.org to redirect content-negotiated dx.doi.org queries to RA-controlled resolver depending on the preferences of the RA.
RA implements DOI resolver (e.g. dx.crossref.org) that supports content negotiation. RA allows its members to specify to the RA that they want either: <ol type=a>
RA to forward all requests to the member’s site.
RA to “intercept” content-negotiations for non-HTML representations and direct them appropriately (e.g. return appropriate representation from rdf.crossref.org)

How would it work?

Pros

All DOIs conform to expectations for LD identifiers
Allows RA to potentially LD-enable its members very quickly.
Easy for ra-members to opt-in or opt-out
Requires minimal development on part of Crossref
Would even work for DOIs that bypass landing pages

Cons

Requires global change on part of IDF. Global change might conflict with requirements of other RAs.
Requires change to add decision logic implementation on part of IDF.
Requires development of RA resolvers that implement per-member resolution logic (note- this would probably actually be done at DOI level)

D: Simple + IDF Selective Semantic Compliance + RA CN Intercept

What would need to be done?

Same as Simplest Scenario
IDF changes dx.doi.org to return either 302 or 303 redirect depending on the preferences of the RA.
IDF changes dx.doi.org to redirect content-negotiated dx.doi.org queries to RA-controlled resolver depending on the preferences of the RA.
RA implements DOI resolver (e.g. dx.crossref.org) that supports content negotiation. RA allows its members to specify to the RA that they want either:
1. RA to forward all requests to the member’s site.
2. RA to “intercept” content-negotiations for non-HTML representations and direct them appropriately (e.g. return appropriate representation from rdf.crossref.org)

How would it work?

Pros

Allows RA to potentially LD-enable its members very quickly.
Easy for ra-members to opt-in or opt-out
Requires minimal development on part of Crossref
Would even work for DOIs that bypass landing pages

Cons

Only some DOIs conform to expectations for LD identifiers
Requires change to add decision logic implementation on part of IDF.
Requires development of RA resolvers that implement per-member resolution logic (note- this would probably actually be done at DOI level)

Does a Crossref DOI identify a "work?"

Geoffrey Bilder — Thu, 11 Feb 2010 00:00:00 +0000

Tony’s recent thread on making DOIs play nicely in a linked data world has raised an issue I’ve meant to discuss here for some time- a lot of the thread is predicated on the idea that Crossref DOIs are applied at the abstract “work” level. Indeed, that it what it currently says in our guidelines. Unfortunately, this is a case where theory, practice and documentation all diverge.

When the Crossref linking system was developed it was focused primarily on facilitating persistent linking amongst journals and conference proceedings. The system was quickly adapted to handle books and more recently to handle working papers, technical reports, standards and “components”- a catchall term used to refer to everything from individual article images to database records.

In practice the content outside of the core journals and conference proceedings has accounted for relatively low volume. However, we expect that over the next few years this will change and that books and databases will increasingly drive the future growth in Crossref’s citation linking services. Interestingly, these record types all share characteristics that make them substantially different from the journals and conference proceedings that we have hitherto focused on.

Both books and databases introduce new challenges to technology and policies of our citation linking service. The challenges revolved around two areas:

Structure: Both books and databases can have complex structures and the publishers of this content are likely to require granular identification of these content substructures along with a mechanism for documenting the relationship between these substructures (e.g. this section is part of this chapter which is part of this monograph which is part of this series)
Versioning: Unlike typical journals and conference proceedings, books and database records sometimes change over time.

When confronted with the issues of structure and versioning publishers are often tempted to take shortcuts and decide to simply assign DOIs at the highest level structure and to the “work” instead of a particular “manifestation” or version of that work. Indeed, section 5.5 of Crossref’s [DOI Name Information and Guidelines][2] recommends this. But this approach could have a negative impact on the integrity of the scholarly citation record that Crossref is attempting to maintain.

Fundamentally, Crossref DOIs are aimed at providing a persistent online citation infrastructure for scholarly and professional publishers. Consequently, decisions about where to apply Crossref DOIs should be guided by common expectations about the way in which citations work. Citations are typically used to credit ideas or provide evidence. A reader follows a citation in order to obtain more detail or to verify that an author is accurately representing the item cited. A rule of thumb is that a reader has a reasonable expectation that when they follow a citation, they will be taken to what the author saw when creating the citation. Any divergent behavior could result in the reader concluding that the author was misrepresenting the item cited. A further implication of this is that any changes to content that are likely to effect the crediting or interpretation of the content should result in that changed content getting a new Crossref DOI.

Typically, this means that Crossref DOIs should be probably assigned at the expression level and different expressions should be assigned different Crossref DOIs. This is because assigning a Crossref DOI at the higher “work” level is generally not granular enough to guarantee that a reader following the citation will see what the author saw when creating the citation. For example, one translation of a work might be substantially different from another translation of the same work. Similarly a draft version of a work might be substantially different from the final published version of the work. In each case, resolving a citation to a different expression of the work than the expression that was originally cited might result in the reader interpreting the content differently than the citing author.

In general, different “equivalent manifestations” of the same work can safely be assigned the same Crossref DOI. So, for instance, the HTML formatted version an article and the PDF formatted version of an article can almost always be assigned the same Crossref DOI. Any differences between the two are unlikely to affect the crediting of, or reader’s interpretation of, the work. But sometimes it is even possible that different manifestations of an expression will differ enough to merit different Crossref DOIs. For instance, a semantically enhanced version of an article might require new crediting (e.g. the parties responsible for adding the semantic information) and the resulting semantic enhancement may conceivably alter the reader’s interpretation of the article.

Unfortunately, there is no hard and fast rule about where and when to assign new Crossref DOIs. Instead there is only a guideline, namely:

“Assign new Crossref DOIs to content in a way that will ensure that a reader following the citation will see something as close to what the original author cited as is possible.”

The implications of this to publishers are important, especially when they are assigning DOIs to protean records types. For instance, it may mean that:

Book publishers should be expected to keep old editions of books available for link resolution purposes.
Publishers of content that can change rapidly (e.g. by the second) should provide facilities for creating frozen, archived snapshots of content for citation purposes.
All publishers of protean content should issue guidelines instructing researchers on when it is appropriate to cite a work, manifestation or version.

Crossref needs to actively consider these issues as publishers start assigning Crossref DOIs to more dynamic types of content. Minimally, we should be able to provide publishers with recommendations on how to make dynamic content citable. We may even want to consider enshrining certain types of behavior in our terms and conditions so as to ensure the future integrity of the scholarly citation record.

In short, we need to update our guidelines.

[2]: Crossref DOI display guidelines

Crossref: the first ten years

Crossref team — Tue, 19 Jan 2010 00:00:00 +0000

Crossref: the first ten years

When Crossref was incorporated on 19 January 2000, the founders set out a simple promise: persistent, cross-publisher links between scholarly works. Ten years later, this booklet reflected on what that decision had built — the members who had joined, the DOIs registered, and the infrastructure that had taken shape.

Published in 2010 in English and Japanese editions, both reproduced below.

English edition

Loading…

Download the English edition (PDF)

Japanese edition / 日本語版

Loading…

Download the Japanese edition / 日本語版をダウンロード (PDF)

What the booklet covers

The founding — how a group of competing publishers agreed in 1999–2000 to run shared linking infrastructure, and why the not-for-profit, membership model was chosen from the start
First DOIs — the publishers, journals, and reference lists that made up the first wave of registered content
Membership growth — how participation expanded across publisher sizes, regions, and disciplines through the decade
Cross-publisher reference linking — the practical workflows that made citations work between members
Looking ahead from 2010 — what the founders and early members saw on the horizon for the second decade

For the Crossref at 25 short film (2025), see the 25th-anniversary video that picks up where this booklet left off.

A Christmas Reading List… with DOIs

Geoffrey Bilder — Sun, 13 Dec 2009 00:00:00 +0000

Was outraged (outraged, I tell you) that one of my favorite online comics, PhD, didn’t include DOIs in their recent bibliography of Christmas-related citations.. So I’ve compiled them below.

We care about these things so that you don’t have to. Bet you will sleep better at night knowing this.

Or perhaps not…

A Christmas Reading List… with DOIs.

Citation: Biggs, R, Douglas, A, Macfarlane, R, Dacie, J, Pitney, W, Merskey, C & O’Brien, J, 1952, ‘Christmas Disease’, BMJ, vol. 2, no. 4799, pp. 1378-1382.

Crossref DOI: http://dx.doi.org/10.1136/bmj.2.4799.1378

Title: More Than a Labor of Love: Gender Roles and Christmas Gift Shopping

Citation: Fischer, E & Arnold, S, 1990, ‘More Than a Labor of Love: Gender Roles and Christmas Gift Shopping’, Journal of Consumer Research, vol. 17, no. 3, p. 333.

Crossref DOI: http://dx.doi.org/10.1086/208561

Title: Looking at Christmas trees in the nucleolus

Citation: Scheer, U, Xia, B, Merkert, H & Weisenberger, D, 1997, ‘Looking at Christmas trees in the nucleolus’, Chromosoma, vol. 105, no. 7-8, pp. 470-480.

Crossref DOI: http://dx.doi.org/10.1007/s004120050209

Title: The Vela glitch of Christmas 1988

Citation: McCulloch, P, Hamilton, P, McConnell, D & King, E, 1990, ‘The Vela glitch of Christmas 1988’, Nature, vol. 346, no. 6287, pp. 822-824.

Crossref DOI: http://dx.doi.org/10.1038/346822a0

Title: Cardiac Mortality Is Higher Around Christmas and New Year’s Than at Any Other Time: The Holidays as a Risk Factor for Death

Citation: Phillips, D, 2004, ‘Cardiac Mortality Is Higher Around Christmas and New Year’s Than at Any Other Time: The Holidays as a Risk Factor for Death’, Circulation, vol. 110, no. 25, pp. 3781-3788.

Crossref DOI: http://dx.doi.org/10.1161/01.CIR.0000151424.02045.F7

Title: Red Crabs in Rain Forest, Christmas Island: Biotic Resistance to Invasion by an Exotic Snail

Citation: Lake, P & O’Dowd, D, 1991, ‘Red Crabs in Rain Forest, Christmas Island: Biotic Resistance to Invasion by an Exotic Snail’, Oikos, vol. 62, no. 1, p. 25.

Crossref DOI: http://dx.doi.org/10.2307/3545442

Title: The Carvedilol Hibernation Reversible Ischaemia Trial, Marker of Success (CHRISTMAS) study Methodology of a randomised, placebo controlled, multicentre study of carvedilol in hibernation and heart failure

Citation: Pennell, D, 2000, ‘The Carvedilol Hibernation Reversible Ischaemia Trial, Marker of Success (CHRISTMAS) study Methodology of a randomised, placebo controlled, multicentre study of carvedilol in hibernation and heart failure’, International Journal of Cardiology, vol. 72, no. 3, pp. 265-274.

Crossref DOI: http://dx.doi.org/10.1016/S0167-5273(99)00198-9

Citation Typing Ontology

Geoffrey Bilder — Fri, 20 Mar 2009 00:00:00 +0000

I was happy to read David Shotton’s recent Learned Publishing article, Semantic Publishing: The Coming Revolution in scientific journal publishing, and see that he and his team have drafted a Citation Typing Ontology.^*

Anybody who has seen me speak at conferences knows that I often like to proselytize about the concept of the “typed link”, a notion that hypertext pioneer, Randy Trigg, discussed extensively in his 1983 Ph.D. thesis.. Basically, Trigg points out something that should be fairly obvious- a citation (i.e. “a link”) is not always a “vote” in favor of the thing being cited.
In fact, there are all sorts of reasons that an author might want to cite something. They might be elaborating on the item cited, they might be critiquing the item cited, they might even be trying to refute the item cited (For an exhaustive and entertaining survey of the use and abuse of citations in the humanities, Anthony Grafton‘s, The Footnote: A Curious History, is a rich source of examples)
Unfortunately, the naive assumption that a citation is tantamount to a vote of confidence has become inshrined in everything from the way in which we measure scholarly reputation, to the way in which we fund universities and the way in which search engines rank their results. The distorting affect of this assumption is profound. If nothing else, it leads to a perverse situation in which people will often discuss books, articles, and blog postings that they disagree with without actually citing the relevant content, just so that they can avoid inadvertently conferring “wuffie” on the item being discussed. This can’t be right.
Having said that, there has been a half-hearted attempt to introduce a gross level of link typology with the introduction of the “nofollow” link attribute- an initiative started by Google in order to try to address the increasing problem of “Spamdexing”. But this is a pretty ham-fisted form of link typing- particularly in the way it is implemented by the Wikipedia where Crossref DOI links to formally published scholarly literature have a “nofollow” attribute attached to them but, inexplicably, items with a PMID are not so hobbled (view the HTML source of this page, for example). Essentially, this means that, the Wikipedia is a black-hole of reputation. That is, it absorbs reputation (through links too the Wikipedia), but it doesn’t let reputation back out again. Hell, I feel dirty for even linking to it here ;-).
Anyway, scholarly publishers should certainly read Shotton’s article because it is full of good, and practical ideas about what can can be done with today’s technology in order to help us move beyond the “digital incunabula” that the industry is currently churning out. The sample semantic article that Shotton’s team created is inspirational and I particularly encourage people to look at the source file for the ontology-enhanced bibliography which reveals just how much more useful metadata can be associated with the humble citation.
And now I wonder whether CiteULike, Connotea, 2Collab or Zotero will consider adding support for the CItation Typing Ontology into their respective services?
* Disclosure:
a) I am on the editorial board of Learned Publishing
b) Crossref has consulted with David Shotton on the subject of semantically enhancing journal articles

An interview about “Author IDs”

Geoffrey Bilder — Thu, 19 Feb 2009 00:00:00 +0000

Over the past few months there seems to have been a sharp upturn in general interest around implementing an “author identifier” system for the scholarly community. This, in turn, has meant that more people have been getting in touch with us about our nascent “Contributor ID” project. The other day, after seeing my comments in the above thread, Martin Fenner asked if he could interview me about the issue of author identifiers for his blog on Nature Networks, Gobbledygook. I agreed and he posted the interview the other day.

I warn you ahead of time, I did ramble on a bit and the interview is long. There is a lot of stuff at the beginning about the DOI and it might seem off-topic, but I do think that there is a lot that we can learn from our DOI experiences which would apply to any author identifier. Just be thankful I didn’t start talking about the privacy issues that will inevitably arise from any author identifier system. If I had, the interview would have probably gone on for another six pages ;-).

Anyway, as most of our membership knows, we have a pilot project underway to explore what it would take to launch a “Crossref Contributor ID” system. We still haven’t concluded whether it makes sense for us to do it, but one thing is clear from the recent discussions we’ve had and that is that, if we don’t do it, somebody else almost certainly will.

CURIE Syntax 1.0

Tony Hammond — Mon, 19 Jan 2009 00:00:00 +0000

The W3C has recently (Jan. 16) released CURIE Syntax 1.0 as a Candidate Recommendation and is inviting implementations.

(Note that I made a fuller post here on CURIEs and erroneously confused the Editor’s Draft (Oct. 23, ’08) as being a Candidate Recommendation. Well, at least it’s got there now.)

Standard InChI Defined

Tony Hammond — Sat, 17 Jan 2009 00:00:00 +0000

IUPAC has just released the final version (1.02) of its InChI software, which generates Standard InChIs and Standard InChIKeys. (InChI is the IUPAC International Chemical Identifier.)

The Standard InChI “removes options for properties such as tautomerism and stereoconfiguration”, so that a molecule will always generate the same stable identifier - a unique InChI - which facilitates “interoperability/compatibility between large databases/web searching and information exchange”. Note also that any “shortcomings in Standard InChI may be addressed using non-Standard InChI (currently obtainable using InChI version 1.02beta)”.

On a practical level this means that the 27-character length InChIKeys (a hashed form of the InChI), with the following generic form

AAAAAAAAAAAAAA-BBBBBBBBFV-P

can now be readily and reliably generated and will start to be used in search indexing and linking applications.

CURIEs - A Cure for URIs

Tony Hammond — Wed, 03 Dec 2008 00:00:00 +0000

A quick straw poll of a few folks at London Online yesterday revealed that they had not heard of CURIE’s. And there was I thinking that most everybody must have heard of them by now. 🙂 So anyway here’s something brief by way of explanation.

CURIE stands for Compact URI and does the signal job or rendering long and difficult to read URI strings into something more manageable. (URIs do have the particular gift of being “human transcribable” but in practice their length and the actual characters used in the URI strings tend to muddy things for the reader.) So given that the Web is built upon a bedrock of URIs, anything that then makes URIs easier to handle is going to be an important contributor to our overall ease of interaction with the Web.

(Continues)

Ten years back (in February 1998) when XML was first introduced it presented a flat naming system for document markup. For purposes of modularity and markup reuse the XML Namespaces specification released the following year allowed for element and attribute names to be replaced by expanded names in which the hitherto simple names would be replaced by name pairs consisting of a namespace name and a local name. The use of URIs for the namespace name thus opened the doors to assigning globally unique names for XML element/attribute names. As a practical point (both to keep the names short and to deal with URI characters), the notion of a qualified name (or QName) was introduced, whereby the local name would be qualified by a prefix which stood in for the namespace name.

This was such a successful device that over time it was applied to URIs in general as a mechanism for abbreviation. Especially in RDF/XML schema elements were referenced by QName. And the practice has spilled over into non-XML syntaxes (e.g. the N3 and Turtle RDF grammars which use a “@prefix” directive). But there were problems since the device was grounded in XML the local names were constrained by allowable characters for XML elements and attributes (e.g. names cannot start with a digit character), as well as there being no specification for applying this same device to non-XML grammars.

CURIE is an initiative to generalize this notion of qualified names for URIs beyond the immediate XML context for naming elements and attributes (which would also allow their use in attribute values), to a more general use in applications beyond XML. The development of CURIE is based upon work done in the definition of XHTML2, and upon work done by the RDF-in-HTML Task Force, a joint task force of the Semantic Web Best Practices and Deployment Working Group and XHTML 2 Working Group. The Editor’s draft CURIE Syntax 1.0 is currently a W3C Candidate Recommendation which is receiving comments through Jan 15, 2009, at which time it is intended to put it forward as a W3C Proposed Recommendation. Meantime, though, the new W3C Recommendation RDFa Syntax in XHTML (published Oct 14, 2008) has a normative section on CURIEs (see Sect. 7).

So, what do CURIEs look like? Taking a simple RDFa example for DOI we might have a fragment such as:

<div xmlns:doi="https://doi.org/" xmlns:dcterms="http://purl.org/dc/terms/">
  <div about="doi:10.1038/nature07184">
    <span property="dcterms:hasPart" resource="[doi:10.1038/nature07184]"/>
  </div>
</div>

This would be processed by an RDFa processor to yield the RDF triple (in N3/Turtle):

<doi:10.1038/nature07184> dcterms:hasPart <https://doi.org/10.1038/nature07184> .

This triple (or fact) says that the resource identified by DOI 10.1038/nature07184 has as a component part (cf. DCTERMS vocabulary) the resource identified by https://doi.org/10.1038/nature07184. (The abstract work identified by the DOI has as a component part the splash page identified by the proxy URL.)

OK, so what’s going on? The “property” attribute takes a CURIE as value where the prefix “dcterms” is standing in for the XML namespace URI. The “about” and “resource” attributes both take a URI or CURIE as value, but because of any potential confusion a (so-called) “Safe CURIE” must be used which is a CURIE wrapped in brackets. The above example does not use brackets for the “about” attribute and therefore an RDFa processor would read this as being a full URI, i.e. &lt’doi:10.1038/nature07184>, whereas it does use brackets for the “resource” attribute and therefore this would be read as being a (Safe) CURIE, i.e. https://doi.org/10.1038/nature07184.

We can turn this around as follows:

<div xmlns:doi="https://doi.org/" xmlns:dcterms="http://purl.org/dc/terms/">
  <div about="[doi:10.1038/nature07184]">
    <span property="dcterms:isPartOf" resource="doi:10.1038/nature07184"/>
  </div>
</div>

This would be processed by an RDFa processor to yield the RDF triple (in N3/Turtle):

<https://doi.org/10.1038/nature07184> dcterms:isPartOf <doi:10.1038/nature07184> .

This triple (or fact) says that the resource identified by https://doi.org/10.1038/nature07184 is a component part (cf. DCTERMS vocabulary) of the resource identified by DOI 10.1038/nature07184. (The splash page identified by the proxy URL is a component part of the abstract work identified by the DOI.)

So what do CURIEs give us? Nothing more than a generic means to be able to make human-friendly statements such as

<doi:10.1038/nature07184> dcterms:hasPart doi:10.1038/nature07184 .

instead of having to spell it out in full triples form using long-winded URIs:

<doi:10.1038/nature07184>
  <http://http://purl.org/dc/terms/hasPart>
    <https://doi.org/10.1038/nature07184> .

Five Years

Tony Hammond — Mon, 28 Jul 2008 00:00:00 +0000

Oh wow! A rather remarkable plea here from Dan Brickley on the public-lod mailing list which calls for the registrant of the dbpedia.org DNS entry to top it up with another 5+ years worth of clocktime. Some quotes:

_“The idea of such a cool RDF namespace having only 6 months left on the DNS registration gives me the worries.”

“If you could add another 5-10 years to the DNS registration I’d sleep easier at night.”

“Let me stress I’m not suggesting that this domain is actually at risk. Just that the not-at-risk-ness isn’t readily evident from a quick look in the DNS.”

“Those in the know are probably confident this is all in hand, but as the SW gets bigger I suspect we ought to establish practices such as “vocabularies that seek global adoption should always have 5+ years on their DNS registries”.”_

Yes, and maybe those cool URIs should have kite marks, too. 😉

(Btw, for those who may not already know the maximum length of time that any DNS name may be leased out in a single registration is 10 years, see the FAQ put out by ICANN.)

So, pity the poor user of a given semantic web application who may not know what the expectancy is behind the nodes in an RDF graph of assertions. Shifting sands, indeed.

Tombstone

Tony Hammond — Fri, 23 May 2008 00:00:00 +0000

So, the big guns have decided that XRI is out. In a message from the TAG yesterday, variously noted as being “categorical” (Andy Powell, eFoundations) and a “proclamation” (Edd Dumbill, XML.com), the co-chairs (Tim Berners-Lee and Stuart Williams) had this to say:

“We are not satisfied that XRIs provide functionality not readily available from http: URIs. Accordingly the TAG recommends against taking the XRI specifications forward, or supporting the use of XRIs as identifiers in other specifications.”

Alas, poor XRI. But what might this also mean for other URI schemes (note the reference above to “http: URIs)? Well, the message starts out with this:

“In The Architecture of the World Wide Web 1 the TAG sets out the reasons why http: URIs are the foundation of the value proposition for the Web, and should be used for naming on the Web. “

Now I’m not sure that this is quite what AWWW actually says. I don’t find it to be that insistent that “http” URIs … should be used for naming on the Web” but I would need to read it more carefully. Certainly, “http: URIs” fit the bill and are top of the class. But there is also a general recognition that other schemes than “http:” do exist.

Interesting times anyway with a “winner takes all” approach to identification. I wonder what this all means for DOI.

NIH Mandate and PMCIDs

Ed Pentz — Tue, 15 Apr 2008 00:00:00 +0000

The NIH Public Access Policy says “When citing their NIH-funded articles in NIH applications, proposals or progress reports, authors must include the PubMed Central reference number for each article” and the FAQ provides some examples of this:

Examples:

Varmus H, Klausner R, Zerhouni E, Acharya T, Daar A, Singer P. 2003. PUBLIC HEALTH: Grand Challenges in Global Health. Science 302(5644): 398-399. PMCID: 243493

Zerhouni, EA. (2003) A New Vision for the National Institutes of Health. Journal of Biomedicine and Biotechnology (3), 159-160. PMCID: 400215

It’s interesting to note that on PMC itself both the [The NIH Public Access Policy says “When citing their NIH-funded articles in NIH applications, proposals or progress reports, authors must include the PubMed Central reference number for each article” and the FAQ provides some examples of this:

Examples:

Varmus H, Klausner R, Zerhouni E, Acharya T, Daar A, Singer P. 2003. PUBLIC HEALTH: Grand Challenges in Global Health. Science 302(5644): 398-399. PMCID: 243493

Zerhouni, EA. (2003) A New Vision for the National Institutes of Health. Journal of Biomedicine and Biotechnology (3), 159-160. PMCID: 400215

It’s interesting to note that on PMC itself both the][3] - but the DOI isn’t linked. Two things occur to me - 1) should Crossref map DOIs to PMCIDs and vice versa and make PMCIDs available in it’s query interfaces and 2) shouldn’t publishers ask that the PMC copy of the article link back to the publisher version? It would be very easy with the DOI.

ISO/CD 26324 (DOI)

Tony Hammond — Fri, 22 Feb 2008 00:00:00 +0000

Following on from my previous post about prism:doi I didn’t mention, or reference, the ongoing ISO work on DOI, Indeed I hadn’t realized that the DOI site now has a status update on the ISO work:

_“The DOI® System is currently being standardised through ISO. It is expected that the process will be finalised during 2008. In December 2007 the Working Group for this project approved a final draft as a Committee Draft (standard for voting) which is now being processed by ISO. Copies of the Committee Draft (SC9N475) and an accompanying explanatory document detailing issues dealt with during the standards process (SC9N474) are provided here for information.

Committee Draft 26324 is subject to ISO’s copyright and is for information only to those interested in the project; it may not be re-distributed. This is currently undergoing the formal ISO voting process; the deadline for comments on CD 26324 from TC46/SC9’s national bodies is April 25, 2008: please contact your national member of ISO TC46/SC9 if you would like it contribute to comments on this draft standard. Other documents for the ISO DOI Working Group are available on a DOI Project Register.”_

BISG Paper on Identifying Digital Book Content

Ed Pentz — Mon, 14 Jan 2008 00:00:00 +0000

BISG and BIC have published a discussion paper called “The identification of digital book content” - https://web.archive.org/web/20090920075334/http://www.bisg.org/docs/DigitalIdentifiers_07Jan08.pdf. The paper discusses ISBN, ISTC and DOI amongst other things and makes a series of recommendations which basically say to consider applying DOI, ISBN and ISTC to digital book content. The paper highlights in a positive way that DOI and ISBN are different but can work together (the idea of the “actionable ISBN” and aiding discovery of content). However, it doesn’t go into much depth on any of the issues or really explain how all these identifiers would work together and the critical role that metadata plays.

Nevertheless it’s great that the paper has been put forward as a discussion document - Crossref plans to respond and be part of the ongoing discussion in this area.

Zotero and the IA

Ed Pentz — Fri, 14 Dec 2007 00:00:00 +0000

Dan Cohen at Zotero reports (Zotero and the Internet Archive Join Forces) on a very interesting tie up that will allow researchers using Zotero to deposit content in the Internet Archive and have OCR done on scanned material for free under a two year Mellon grant. Each piece of content will be given a “permanent URI that includes a time and date stamp in addition to the URL” ( would Handle or DOI add value here?) and be part of Zotero Commons (things can also be kept private within a group).

Zotero Commons is related to but different from Nature Precedings and WebCite in that it’s intended focus is on public domain stuff on researchers hard drives rather than someone else’s material or website that is cited (WebCite) or preprints, datasets, technical reports that are given at least an initial screening (Nature Precedings).

DCMI Identifiers Community

Tony Hammond — Wed, 17 Oct 2007 00:00:00 +0000

Another DCMI invitation. And a list. Lovely.

See this message (copied below) from Douglas Campbell, National Library of New Zealand, to the dc-general mailing list.

(Continues)

_“Hi all,

I would like to alert members of this list to the new DCMI Identifiers Community established at the recent Dublin Core Metadata Initiative (DCMI) Advisory Board meeting in Singapore. It is moderated by Douglas Campbell (National Library of New Zealand).

The community is a forum for individuals and organisations with an interest in the design and use of identifiers in metadata. It also serves as a liaison channel for those involved in identifier efforts in other domains.

There was a lot of interest in identifiers at the recent DCMI conference. Identifiers are fundamental to the Web and for managing digital content, but most of us don’t know where to begin in designing and assigning them. The level of confusion can be seen in the number of meetings and workshops held just about identifiers. DCMI is in a unique position to bring together the thinking (and doing) around identifiers from multiple domains.

I would like to encourage you to share your identifier efforts and thinking amongst the DCMI community on our Identifiers wiki at:

http://dublincore.org/identifierswiki

You can join the community by signing up to our JISCMAIL list, linked from our community homepage at:

http://www.dublincore.org/groups/identifiers/

or by going direct to jiscmail:

http://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=dc-identifiers&A=1

Thanx,

Douglas”_

NLM Blog Citation Guidelines

Geoffrey Bilder — Mon, 15 Oct 2007 00:00:00 +0000

I’ve just returned from Frankfurt Book fair and noticed that there has been some recent in the The NLM Style Guide for Authors, Editors and Publishers recommendations concerning citing blogs.

Which reminds me of an issue that has periodically been raised here at Crossref- should we be doing something to try and provide a service for reliably citing more ephemeral content such as blogs, wikis, etc.?

Personally, I cringe when I see people include plain old URLs (POUs?) in citations. What’s the point? They are almost guaranteed to fail to resolve after a few years. In citing them, you are hardly helping to preserve the scholarly record. You might as well just record the metadata associated with the content.

So why don’t we simply allow individuals to assign DOIs to their content?

As Chuck Koscher says, “Crossref DOIs are only as persistent as Crossref staff.” Crossref depends on its ability to chase down and berate member publishers when they fail to update their DOI records. Its hard enough doing this with publishers, so just imagine what it would be like trying to chase down individuals. In short, it just wouldn’t scale.

But what if we provided a different service for more informal content? Recently we have been in talking with Gunther Eysenbach, the creator of the very cool WebCite service about whether Crossref could/should operate a citation caching service for ephemera.

As I said, I think WebCite is wonderful, but I do see a few problems with it in its current incarnation.

The first is that, the way it works now, it seems to effectively leech usage statistics away from the source of the content. If I have a blog entry that gets cited frequently, I certainly don’t want all the links (and their associated Google-juice) redirected away from my blog. As long as my blog is working, I want traffic coming to my copy of the content, not some cached copy of the content (gee- the same problem publishers face, no?). I would also, ideally, like that traffic to continue to come to to my blog if I move hosting providers, platforms (WordPress, Moveable Type) , blog conglomerates (Gawker, Weblogs, Inc.), etc.

The second issue I have with WebCite is simpler. I don’t really fancy having to actually recreate and run a web-caching infrastructure when there is already a formidable one in existence.

So what if we ran a service for individuals that worked like this:

For a fee, you can assign DOIs to your ephemeral, CC-licensed content.
When you assign a DOI to an item of content (or update an existing DOI), we will immediately archive said content with the Internet Archive (who, incidentally, charges for this service)
We will direct those DOIs to your web site as long as you are both:
Paying the fee
Updating your URLs to point to the correct content
If you fail in either “a” or “b”, we will then redirect said DOIs to the cached version of the content on the Internet Archive (after having warned you repeatedly via automated e-mail).

(Note, as an aside, that we could in theory provide a similar dark-archive service for publishers with non free content using something like JStore as the archive)

This approach would help to ensure that a blogger’s version of content was always linked to as long it was available. It would also preserve the “persistence” of Crossref DOIs by making sure that we could always resolve the DOI even if we were not able to get the owner of said DOI to update it.

So back to the NLM guidelines… On the one hand, I’m delighted to see that the NLM has issued guidelines on citing blogs. It seems glaringly obvious that informal (and ephemeral) content such as blogs and wikis are increasingly becoming vital parts of the scholarly record. On the other hand, it also seems to me that recommending that somebody “cite” with a broken pointer (i.e. a URL) to content verges on tokenism. This isn’t the NLM’s fault- there just isn’t a reliable mechanism for citing informal content in a manner that ensures you can then retrieve and look at said content in the future.

And this is no longer a problem confined to the Scholarly/Professional publishing space. As Jon Udell has occasionally pointed out, citation is increasingly an important currency for *any* professional writer on the web. It seems to me that a system for reliably citing blogs and wikis would benefit many communities. I could easily see commercial hosted Blog services (Blogger, WordPress) offering a “Cached-DOI” feature as a premium service to their clients.

So what do you think? What am I missing? is this something we should be looking at?

InChIKey

Tony Hammond — Tue, 02 Oct 2007 00:00:00 +0000

The InChI (International Chemical Identifier from IUPAC) has been blogged earlier here. RSC have especially taken this on board in their Project Prospect and now routinely syndicate InChI identifiers in their RSS feeds as blogged here.

As reported variously last month (see here for one such review) IUPAC have now released a new (1.02beta) version of their software which allows hashed versions (fixed length 25-character) of the InChI, so-called InChIKey’s, to be generated which are much more search engine friendly. Compare a regular InChI identifier:

InChI=1/C49H70N14O11/c1-26(2)39(61-42(67)33(12-8-18-55 -49(52)53)57-41(66)32(50)23-38(51)65)45(70)58-34(20-29-1 4-16-31(64)17-15-29)43(68)62-40(27(3)4)46(71)59-35(22-30 -24-54-25-56-30)47(72)63-19-9-13-37(63)44(69)60-36(48(7 3)74)21-28-10-6-5-7-11-28/h5-7,10-11,14-17,24-27,32-3 7,39-40,64H,8-9,12-13,18-23,50H2,1-4H3,(H2,51,65)(H,54,56 )(H,57,66)(H,58,70)(H,59,71)(H,60,69)(H,61,67)(H,62,68)(H,73,74) (H4,52,53,55)/f/h56-62,73H,51-53H2

with its InChIKey counterpart:

InChIKey=JYPVVOOBQVVUQV-UHFFFAOYAR

That’s some saving.

Oh No, Not You Again!

Tony Hammond — Tue, 02 Oct 2007 00:00:00 +0000

Oh dear. Yesterday’s post “Using ISO URNs” was way off the mark. I don’t know. I thought that walk after lunch had cleared my mind. But apparently not. I guess I was fixing on eyeballing the result in RDF/N3 rather than the logic to arrive at that result.

(Continues.)

There are three namespace cases (and I was only wrong in two out of the three, I think):

“pdf:”

I was originally going to suggest the use of “data:” for the PDF information dictionary terms here but then lunged at using an HTTP URI (the URI of the page for the PDF Reference manual on the Adobe site) for regular orthodox conformancy and good churchgoing:

@prefix pdf: <http://www.adobe.com/devnet/pdf/pdf_reference.html> .

This was wrong on two counts:

a) Afaik no such use for this URI as a namespace has ever been made by Adobe. And it is in the gift of the DNS tenant (elsewhere called “owner”) to mint URIs under that namespace and to ascribe meanings to those URIs.

b) Also the URI is not best suited to a role as namespace URI since RDF namespaces typically end in “/” or “#” to make the division between namespace and term clearer. (In XML it doesn’t make a blind bit of difference as XML namespaces are just a scoping mechanism.) So to have a property URI as

http://www.adobe.com/devnet/pdf/pdf_reference.htmlAuthor

does the job but looks pretty rough and more importantly precludes (at least, complicates) the possibility of dereferencing the URI to return a page with human or machine readable semantics. Better in RDF terms is one of the following:

a) http://www.adobe.com/devnet/pdf/pdf_reference/Author
b) http://www.adobe.com/devnet/pdf/pdf_reference#Author
c) http://www.adobe.com/devnet/pdf/pdf_reference.html#Author

In the absence of any published namespace from Adobe for these terms, I think it would have been more prudent to fall back on “data:” URIs. So

@prefix pdf: <data:,> .

leading to

data:,Author
data:,CreationDate
data:,Creator
etc.

This is correct (afaict) and merely provides a URI representation for bare strings.

Had we wanted to relate those terms to the PDF Reference we might have tried something like:

data:,PDF%20Reference:Author
data:,PDF%20Reference:CreationDate
data:,PDF%20Reference:Creator
etc.

And if we had wanted to make those truly secondary RDF resources related to a primary RDF resource for the “namespace” we could have attempted something like:

data:,PDF%20Reference#Author
data:,PDF%20Reference#CreationDate
data:,PDF%20Reference#Creator
etc.

Note though that the “data:” specification is not clear about the implications of using “#”. (Is it allowed, or isn;t it?) We must suspect that it is not allowed, but see this mail from Chris Lilley (W3C) which is most insightful.

“pdfx:”

The example was just for demo purposes, but (as per 1a above) it is incumbent on the namespace authority (here ISO) to publish a URI for the term to be used. Anyhow, the namespace URI I cited

@prefix pdfx: <urn:iso:std:iso-iec:15930:-1:2001> .

would not have been correct and would have led to these mangled URIs:

urn:iso:std:iso-iec:15930:-1:2001GTS_PDFXVersion
urn:iso:std:iso-iec:15930:-1:2001GTS_PDFXConformance

It should have been something closer to

@prefix pdfx: <urn:iso:std:iso-iec:15930:-1:2001:> .

leading to

urn:iso:std:iso-iec:15930:-1:2001:GTS_PDFXVersion
urn:iso:std:iso-iec:15930:-1:2001:GTS_PDFXConformance

“_usr:”

This was the one correct call in yesterday’s post.

@prefix _usr: <data:,> .

The only problem here would be to differentiate these terms from the terms listed in the PDF Reference manual, although the PDF information dictionary makes no such distinction itself.

To sum up, perhaps the best way of rendering the PDF information dictionary keys in RDF would be to use “data:” URIs for all (i.e. a methodology for URI-ifying strings) and to bear in mind that at some point ISO might publish URNs for the PDF/X mandated keys: ‘GTS_PDFXVersion‘ and ‘GTS_PDFXConformance‘. So,

# document infodict (object 58: 476983):
@prefix: pdfx: <data:,> .
@prefix: pdf: <data:,> .
@prefix: _usr: <data:,> .
<> _usr:Apag_PDFX_Checkup "1.3";
pdf:Author "Scott B. Tully";
pdf:CreationDate "D:20020320135641Z";
pdf:Creator "Unknown";
pdfx:GTS_PDFXConformance "PDF/X-1a:2001";
pdfx:GTS_PDFXVersion "PDF/X-1:2001";
pdf:Keywords "PDF/X-1";
pdf:ModDate "D:20041014121049+10'00'";
pdf:Producer "Acrobat Distiller 4.05 for Macintosh";
pdf:Subject "A document from our PDF archive. ";
pdf:Title "Tully Talk November 2001";
pdf:Trapped "False" .

Using ISO URNs

Tony Hammond — Mon, 01 Oct 2007 00:00:00 +0000

(Update - 2007.10.02: Just realized that there were some serious flaws in the post below regarding publication and form of namespace URIs which I’ve now addressed in a subsequent post here.)

By way of experimenting with a use case for ISO URNs, below is a listing of the document metadata for an arbitrary PDF. (You can judge for yourselves whether the metadata disclosed here is sufficient to describe the document.) Here, the metadata is taken from the information dictionary and from the document metadata stream (XMP packet).

The metadata is expressed in RDF/N3. That may not be a surprise for the XMP packet which is serialized in RDF/XML, as it’s just a hop, skip and a jump to render it as RDF/N3 with properties taken from schema whose namespaces are identified by URI. What may be more unusual is to see the document information dictionary metadata (the “normal” metadata in a PDF) rendered as RDF/N3 since the information dictionary is not nodelled on RDF, not expressed in XML, and not namespaced. Here, in addition to the trusty HTTP URI scheme, I’ve made use of two particular URI schemes: “iso:” URN namespaces, and “data:” URIs.

(Continues.)

As far as I am aware, there is no formal identifier for entries in the document information dictionary as specified by the PDF Reference from Adobe Systems, so it may be appropriate to use the HTTP URI for the Adobe homepage for the PDF Reference manual, from which specific editions are available.

For the PDF/X keys which are specified in the ISO standard ISO 15930-1 2001, I have used an ISO URN. (I don’t expect this to be correct in all details but it should give some idea of how it might be used. It may be that the URI should express the term itself, rather than the document from which the term was defined.) And finally, for the one additional user-supplied key here I have made use of a “data:” URI with no body (i.e. I’m speechless). One could have provided some text within the body of the “data:” URI if one wanted to differentiate between alternate user keys or to otherwise annotate these keys.

Note that the prefixes used in the information dictionary and in the metadata stream are unrelated, as are the mappings of property elements to schemas.

Well, that’s all really just for fun but it may show two things: 1) how a general description might be described with RDF and how general properties can be mapped to URIs (with possibly limited machine utility), and 2) how an ISO URN might be used.

# document infodict (object 58: 476983):
@prefix: pdfx: <urn:iso:std:iso-iec:15930:-1:2001> .
@prefix: pdf: <http://www.adobe.com/devnet/pdf/pdf_reference.html> .
@prefix: _usr: <data:,> .
<> _usr:Apag_PDFX_Checkup "1.3";
pdf:Author "Scott B. Tully";
pdf:CreationDate "D:20020320135641Z";
pdf:Creator "Unknown";
pdfx:GTS_PDFXConformance "PDF/X-1a:2001";
pdfx:GTS_PDFXVersion "PDF/X-1:2001";
pdf:Keywords "PDF/X-1";
pdf:ModDate "D:20041014121049+10'00'";
pdf:Producer "Acrobat Distiller 4.05 for Macintosh";
pdf:Subject "A document from our PDF archive. ";
pdf:Title "Tully Talk November 2001";
pdf:Trapped "False" .
# document metadata stream (object 41: 472418):
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix pdf: <http://ns.adobe.com/pdf/1.3/> .
@prefix pdfx: <http://ns.adobe.com/pdfx/1.3/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpMM: <http://ns.adobe.com/xap/1.0/mm/> .
<> pdf:Keywords "PDF/X-1";
pdf:Producer "Acrobat Distiller 4.05 for Macintosh";
pdfx:Apag_PDFX_Checkup "1.3";
pdfx:GTS_PDFXConformance "PDF/X-1a:2001";
pdfx:GTS_PDFXVersion "PDF/X-1:2001";
xmp:CreateDate "2002-03-20T13:56:41Z";
xmp:CreatorTool "Unknown";
xmp:MetadataDate "2004-10-14T12:10:49+10:00";
xmp:ModifyDate "2004-10-14T12:10:49+10:00";
xmpMM:DocumentID "uuid:bd7ae9a1-1110-43c0-8e84-632f2dbb55ab";
dc:creator [
a rdf:Seq;
rdf:_1 "Scott B. Tully" ];
dc:description [
a rdf:Alt;
rdf:_1 "A document from our PDF archive. "@x-default ];
dc:format "application/pdf";
dc:title [
a rdf:Alt;
rdf:_1 "Tully Talk November 2001"@x-default ] .

Whole Lotta ID

Tony Hammond — Mon, 01 Oct 2007 00:00:00 +0000

ISO has registered with the IANA a URN namespace identifier (“iso:”) for ISO persistent resources. From the Internet-Draft:

“This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources).”

The toplevel grammar rules (ABNF) give some indication of scope:

NSS = std-nss

std-nss = “std:” docidentifier *supplement *docelement [addition]

Just wanted to quote here one of the funkier examples cited in the document:

urn:iso:std:iso:9999:-1:ed-1:v1-amd1.v1:en,fr:amd:2:v2:en:clause:3.1,a.2-b.9

“refers to (sub)clauses 3.1 and A.2 to B.9 in the corrected version of Amendment 2, in English, which amends the document comprising the 1st version of edition 1 of ISO 9999-1 incorporating the 1st version of Amendment 1, in English/French (bilingual document)”

Wow! That’s some ID. That’s something else.

As far as DOI is concerned there is nothing obvious to be learned. It is interesting to see such a level of granularity supported though. And since all these documents issue from a central publisher they can be prescriptive about the identifier syntax. Something which cannot be mandated for the many Crossref publishers with their own commercial arrangements. Hence DOI is generally agnostic about suffix strings.

Seems to be a little confusion about the registration though. The NID was approved Jan. 15, ’07 by the IESG and the IANA Registry of URN Namespaces (last updated Aug. 22, ’07) lists the namespace “iso” with the provisional (unnumbered) RFC labelled “RFC-goodwin-iso-urn-01.txt” (being the -01 draft). However, the IETF I-D Tracker reports this status for draft-goodwin-iso-urn, which shows that a new I-D (an -02 draft) was submitted in Sept. 7, ’07:

“A Uniform Resource Name (URN) Namespace for the International organisation for Standardization (ISO), draft-goodwin-iso-urn-02.txt“

URI Template Republished

Tony Hammond — Sat, 28 Jul 2007 00:00:00 +0000

Well, it all went very quiet for a while but glad to see that the URI Template Internet-Draft has just been republished:

_“A New Internet-Draft is available from the on-line Internet-Drafts

directories.

Title : URI Template

Author(s) : J. Gregorio, et al.

Filename : draft-gregorio-uritemplate-01.txt

Pages : 9

Date : 2007-7-23

URI Templates are strings that can be transformed into URIs after

embedded variables are substituted. This document defines the

syntax and processing of URI Templates.

A URL for this Internet-Draft is:

https://github.com/jcgregorio/uri-templates/blob/master/draft-gregorio-uritemplate-01.txt”

_

URI templates should be a very useful publishing tool. Templates are already used by technologies such as OpenSearch - see here.

PURL Redux

Tony Hammond — Thu, 12 Jul 2007 00:00:00 +0000

Seems that there’s life in the old dog yet. :~) See this post about PURL from Thom Hickey, OCLC, This extract:

OCLC has contracted with Zepheira to reimplement the PURL code which has become a bit out of date over the years. The new code will be in written in Java and released under the Apache 2.0 license.

Identifiers on Crossref

Integrating grant metadata for seamless research interconnectivity at FCCN|FCT

Could you introduce your organisation?

What motivated you to join Crossref?

Can you tell us about your experience using the Grant Linking System?

What do you find useful about registering grant metadata with Crossref?

What are your hopes for the GLS and greater transparency in funding metadata in general?

Has anything surprised you while implementing the Grant Linking System?

Based on your experience, what would be your advice for colleagues from other research funders?

If you could change something about the GLS or how the grant metadata you register is used, what would it be?

Version in Portuguese

Integração de metadados de financiamento pela FCCN|FCT para reforçar a interoperabilidade da informação sobre a atividade científica

Poderia apresentar a sua organização?

O que motivou a adesão à Crossref?

Pode falar-nos sobre a sua experiência com o Grant Linking System?

O que considera útil no registo de metadados de financiamento na Crossref?

Quais são as suas expectativas para o GLS e para uma maior transparência dos metadados de financiamento em geral?

Algo o surpreendeu durante a implementação do Grant Linking System?

Com base na sua experiência, qual seria o seu conselho para colegas de outros financiadores de investigação?

​​Se pudesse alterar algo no GLS ou na forma como os metadados dos subsídios que regista são utilizados, o que seria?

Connecting the dots: FWFs transition to linked grant metadata to support a thriving culture of openness

Could you introduce your organisation? And what is your role?

What motivated you to join Crossref?

Can you tell us about your experience using the Grant Linking System?

How was your journey to socialise the Grant Linking System within your research community? How did you communicate the importance of identifiers and grant metadata to your grant holders?

What do you find useful about registering grant metadata with Crossref?

What are your hopes for the GLS and greater transparency in funding metadata in general?

What were the key challenges you encountered when embracing the GLS, and how did you overcome them?

Based on your experience, what would be your advice for colleagues from other research funders?

Version in German

Connecting the Dots: Wie der FWF durch die Umstellung auf vernetzte Fördermetadaten eine Kultur der Offenheit fördert

Bitte stellen Sie den FWF kurz vor und erklären Sie unseren Leser:innen, was Ihre Rolle dort ist.

Was hat Sie dazu bewogen, Crossref beizutreten?

Können Sie uns mehr über Ihre Erfahrungen mit dem Grant Linking System erzählen?

Welche Erfahrungen haben Sie damit gemacht, das Grant Linking System in Ihrer Forschungscommunity zu bewerben? Wie haben Sie Ihren Fördernehmer:innen die Wichtigkeit von Identifiern und Metadaten vermittelt?

Was finden Sie an der Registrierung von Fördermetadaten bei Crossref am hilfreichsten?

Was erhoffen Sie sich vom GLS und von mehr Transparenz bei Fördermetadaten im Allgemeinen?

Welche Herausforderungen sind bei der Einführung des GLS aufgetreten und wie haben Sie diese gemeistert?

Basierend auf Ihrer eigenen Erfahrung, welchen Ratschlag würden Sie Kolleg:innen bei anderen Fördergebern mitgeben?

Come ROR with us: Using ROR IDs in place of Funder IDs

Open Funder Registry-ROR transition

Including ROR IDs in Crossref metadata

ROR IDs in JSON outputs

Celebrating five years of Grant IDs: where are we with the Crossref Grant Linking System?

What is the Crossref Grant Linking System?

Features of the GLS

How the Crossref Grant Linking System supports Open Science policy

How funders leverage the Grant Linking System in their reporting and assessment

How the community is working to integrate open infrastructure

Acknowledgements and how to participate in the GLS

Open Funder Registry to transition into Research Organization Registry (ROR)

Comparing the features of ROR and the Open Funder Registry

Overview

History

Scope

Usage

Tools and services

Community engagement models

What will this mean for you?

Tell us what you need?

How funding agencies can meet OSTP (and Open Science) guidance using existing open infrastructure

Infrastructure already exists to support funder goals; it just needs more adoption

What does ‘adoption’ look like? How exactly do funders and other stakeholders work with this infrastructure?

Here is an ideal workflow that funders and publishers can already follow

Suggestions for meeting OSTP and Open Science guidance, point by point

Everybody needs to play their part

Everyone has a part to play, and we must all pull together to prioritize this work.

Event Data: A Plan of Action

The Plan

Stability

Consolidation

Future roadmap

Staying in touch

Fast, citable feedback: Peer reviews for preprints and other record types

Reviews for preprints

Calling all 24-hour (PID) party people!

Send us your ideas for #PIDapalooza21

Theme 1. PIDs 101

Theme 2. PID Communities International

Theme 3. PID Success Stories

Se pudesse alterar algo no GLS ou na forma como os metadados dos subsídios que regista são utilizados, o que seria?