Únase al seminario web de CEDIA y DataCite para conocer la propuesta del Consorcio CEDIA–DataCite, que ofrecería a las universidades y organizaciones de investigación de Ecuador una vía sostenible y r...

Are you interested in learning how to register DOIs with DSpace? Join staff from 4Science, DataCite, and the DSpace community for an information session about DSpace’s DOI registration functionality. ...

DataCite is a nonprofit membership association that provides open infrastructure to research organizations worldwide, and both its daily work and its long-term strategy are guided by continuous engagement with and input from its community. Our steering and working groups offer one of the main avenues for community members to take a more active role in what we do. We're pleased to announce that our annual call for nominations is now open for the groups listed below, with terms starting in January 2027.

Turn a DOI list into clean Crossref metadata: title, journal, publisher and date as CSV or JSON, plus a duplicate and error report. $1 per 1,000 results.

DataCite is a nonprofit membership association that provides open infrastructure to research organizations worldwide, and both its daily work and its long-term strategy are guided by continuous engage...

This week I will be traveling to Leiden in the Netherlands (26.-29. October) to attend PIDFest 2026. I will present a poster on Commonmeta, the metadata standard for scholarly metadata that I have worked on over the last nine years. 💡 Commonmeta is a metadata standard for scholarly metadata that is: * based on work on the bolognese library, used for metadata conversion in production at DataCite, * implemented in Python, Rust and other languages, * validated by a v1.0 JSON schema with conformance fixtures, * handling scholarly metadata at scale via a SQLite backend, * real world usage for Crossref DOI registration, citation tracking and content negotiation. **Commonmeta** started out as bolognese, a Ruby library for the conversion of metadata in 2017. I had developed bolognese when I was the DataCite Technical Director, and the library became the foundation for DOI content negotiation to return DOI metadata in schema.org JSON-LD and other formats. And bolognese (in contrast to Crossref) enabled DataCite members to register DOI metadata in JSON rather than XML format. In 2021 I left DataCite to work with the InvenioRDM repository platform, and in January 2023 announced Rogue Scholar, an archive for scholarly blogs that in September 2024 migrated to the InvenioRDM platform. InvenioRDM is open source software with a Python backend and React Frontend, and as metadata format conversion is central for both InvenioRDM and Rogue Scholar, I converted the bolognese Ruby gem to a Python library and released commonmeta-py in March 2023. In contrast to bolognese commonmeta-py doesn't use DataCite JSON as the canonical metadata format, but uses the generic commonmeta format. This made metadata conversion more flexible as I no longer had to work around some of the limitations of the DataCite schema such as references. The commonmeta JSON schema has evolved a lot since 2023 and in September 2026 I finally released a stable version 1.0 version. In parallel I developed commonmeta libraries in other languages. First commonmeta-ruby in March 2023, based on the original bolognese code, then a commonmeta Go library in April 2024, which Rogue Scholar used for DOI registrations until September 2025, and finally commonmeta-rs written in Rust. Maintaining commonmeta in multiple languages is of course hard, so the focus is on the Python and Rust versions. Rust has similar advantages to Go in that commonmeta can be installed as single binary and is faster than Python or Ruby (which is important when converting thousands or millions of metadata records). The big advantage of Rust over Go is that there is a mature library to generate formatted citations using the Citation Style Language. The other advantage is that it is much easier to integrate with Python, which I have started to do with commonmeta-rs for functionality described below. The commonmeta-schema has been released both as Python package and Rust crate to keep the schema and conformance fixtures aligned. InvenioRDM v14 released in August added Crossref DOI registration as a major new feature, and this is implemented via commonmeta-py integration used in Rogue Scholar since September 2025. Also in August 2026 the Rogue Scholar science blog archive integrated with a SQLite database of all Crossref, DataCite, ORCID and ROR metadata (300 million records) hosted on the same server via the commonmeta-rs Python bindings to enable ORCID and ROR metadata lookup for DOI registration and citation tracking. The commonmeta schema 1.0 version made one important change to previous versions: it is now a JSON schema for a list of entities that are either a work, person, organization or container (e.g. journal or repository): mixed collections. This allows commonmeta to describe and convert to various metadata formats, e.g. a publication with its references, and person profile with affiliations and works. This addresses one important use case that was so far only addressed by few scholarly metadata schemata (schema.org is one of the few exceptions). The commonmeta Rust version integrates a SQLite backend to store metadata at scale – the combined annual data files of Crossref, DataCite, ORCID (released last week) and the latest ROR data, and converts all their metadata to commonmeta JSON. The dragoman Rust crate first released in June provides a web server to serve these combined scholarly metadata, my instance is hosted at https://commonmeta.org. This instance addresses the following important persistent identifier (PID) use cases: 1. redirection (similar to what the DOI proxy at doi.org does) https://commonmeta.org/10.1371/journal.pcbi.1000204 2. redirection of other persistent identifiers, e.g. PMID or ORCID https://commonmeta.org/0000-0001-5934-7525 3. content negotation, e.g. metadata for this Crossref DOI in schema.org JSON-LD https://commonmeta.org/10.1038/171737a0?format=schemaorg 4. doi registration, e.g. Crossref metadata as DataCite XML https://commonmeta.org/10.1038/s41597-022-01710-x?format=datacite_xml 5. descriptive metadata, e.g. public information from this ORCID record https://commonmeta.org/0000-0002-0068-716X?noredirect 6. metadata at scale, e.g 173K datasets and other works for this ORCID record https://commonmeta.org/0000-0002-8635-8390?noredirect 7. aggregated metadata, e.g. publications registered with Crossref and DataCite with authors from one university: https://commonmeta.org/02n415q13?noredirect 8. citations of a DataCite DOI found in Crossref or DataCite metadata https://commonmeta.org/10.25490/a97f-egyk?noredirect These and more examples can be shared in dragoman (e.g. at https://commonmeta.org) as bookmarks, exported as browser bookmark file, commonmeta JSON, or QR code (which I will use with my poster): __Commonmeta bookmarks used in my demo at PIDFest__ Commonmeta would not be possible if many things didn't happen, including open scholarly infrastructures with open metadata (including references) share via annual data files, open source software developed by the scholarly community, including InvenioRDM and Citation Style Language, and many people I interacted with over the past more than 10 years. Using openly available data files, SQLite and a single open source Rust binary also means that there can be more than a handful of services that enable this kind of metadata exploration. You only need a fast and large (2 TB) hard drive and a good network connection. And there is often more needed than the service provided at https://commonmeta.org, e.g. * advanced search and filtering, * analytical queries, * disambiguation and matching, e.g. references. But thanks to open scholarly infrastructure you can address these questions in different places with different approaches, e.g. using DuckDB instead of SQLite for analytical queries, and initiatives such as COMET for disambiguation and matching, and Orion-DB for analytical queries. This becomes very important for two reasons: collecting scholarly metadata at scale using REST APIs is increasingly becoming painful and slow with AI agents massively overloading scholarly infrastructures. We need more resilient and distributed infrastructures to handle these challenges. ****Dependency**** https://xkcd.com/2347/ Please reach out via Slack, email, Mastodon, or Bluesky if you have questions about commonmeta. Or speak to me in person if you attend PIDFest this week. ## References 1. Fenner, M. (2017). _Bolognese: A Ruby library for conversion of DOI Metadata_ [Computer software]. DataCite. https://doi.org/10.5438/N138-Z3MK 2. Fenner, M. (2021, August 5). First InvenioRDM Long-Term Support (LTS) version released today – and Front Matter is joining as a participating partner. _Front Matter_. https://doi.org/10.53731/r8c26t1-97aq74v-ag66m 3. Fenner, M. (2023, January 2). Sign up for the science blog archive waitlist. _Front Matter_. https://doi.org/10.53731/cbvm43q-qdk3s1s 4. Fenner, M. (2023, March 9). Announcing Commonmeta. _Front Matter_. https://doi.org/10.53731/cp7apdj-jk5f471 5. Fenner, M. (2024, September 2). Rogue Scholar migrates to InvenioRDM. _Front Matter_. https://doi.org/10.53731/sdazp-kzn55 6. Fenner, M. (2026, July 15). Announcing the commonmeta schema 1.0 release candidate. _Front Matter_. https://doi.org/10.53731/kdqkf-nf052 7. Fenner, M. (2023, March 20). Announcing commonmeta-ruby. _Front Matter_. https://doi.org/10.53731/fawv321-14359c4 8. Fenner, M. (2024, April 23). Rogue Scholar is learning a new language. _Front Matter_. https://doi.org/10.53731/azg9q-3vn50 9. Viger, G. (2026, August 7). InvenioRDM v14.0 released. _Invenio Blog_. https://doi.org/10.63517/kshzw-ay335 10. ORCID, D. & ORCID. (2026). _ORCID Public Data File 2026_ (p. 290958772512 Bytes) [Data set]. ORCID. https://doi.org/10.23640/07243.34697766 11. Fenner, M. (2026, August 20). Rogue Scholar now collects citations with invenio-pidbox. _Front Matter_. https://doi.org/10.53731/1jbsg-kqm79 12. Bilder, G. (2015, February 23). Principles for Open Scholarly Infrastructures. _Science in the Open_. https://doi.org/10.59350/b7mtv-gpn88 13. Kramer, B. (2026, September 1). COMET datasets available on ORION-DBs. _Upstream_. https://doi.org/10.59350/z9n09-6aa44 14. Neylon, C., Kramer, B., Mazoni, A., Costas, R., Jahn, N., & Van Eck, N. J. (2026, February 16). Sharing the load: Building an open research information collective. _Upstream_. https://doi.org/10.59350/exzjg-tbn68

DataCite is a nonprofit membership association that provides open infrastructure to research organizations worldwide, and both its daily work and its long-term strategy are guided by continuous engage...

Becoming a DataCite member organization is not a single milestone; it is a journey shaped by different challenges, opportunities, and lessons learned. In the DataCite Member Stories blog series, we sh...

Becoming a DataCite member organization is not a single milestone; it is a journey shaped by different challenges, opportunities, and lessons learned. In the DataCite Member Stories blog series, we sh...

DataCite Executive Director Matt Buys will participate in the British Library’s Open and Engaged 2026 conference, joining the panel discussion “Sustainable Repositories and Services.” The session will...

Separate fields would be the right fix, and I’d be careful about parsing the comma automatically. Plenty of names don’t split cleanly: single names (common in parts of India and Indonesia), family-name-first order (Chinese, Japanese, Korean, Hungarian), and surnames with particles like “van der Berg” or “de la Cruz”. A “Family, Given” convention also breaks as soon as someone types it the other way round. Two things that help in the DataCite metadata whatever the Hub form ends up looking like: * Set nameType to Personal for people and Organizational for the organisation, so citation styles don’t try to split an organisation’s name. * Add a nameIdentifier (ORCID for people, ROR for organisations). Then the exact name string matters less, because indexers can match the creator by ID. On editing after the DOI is minted, I don’t know how the Hub handles it, so it’s worth waiting for someone from the HF team to confirm. (Disclosure: I work on marketing at Data Galactica, which deals with person and organisation records, so name order comes up for us a lot.)

+1 to this. For what it’s worth, the DataCite schema already supports it on their side: each creator can have a nameType of Personal or Organizational plus optional givenName and familyName fields, and their docs say personal names in creatorName should be formatted as family, given. So it seems like the Hub form would mainly need separate inputs (or parse the comma) and pass those through. Do you know if the DOI metadata can be edited after it’s minted, in case this gets added later?

Mohamad Mostafa will participate in ETD 2026 in person, presenting “Building ETD Visibility, Usage, and Impact with Persistent Identifiers and Open Metadata: Use Cases from Australia, Tunisia, and Côt...

Archive one release, preserve mixed licenses, and verify its version DOI through DataCite, OAI-PMH and OpenAIRE with a tested Python script.