![\"\"](\"https://storage.ghost.io/c/c5/33/c533c955-b5f3-4ff1-ae2d-6b52a212e602/content/images/2026/06/Bildschirmfoto-2026-06-15-um-12.14.56-1.png\")
The science blogging archive Rogue Scholar launched a new feature this week: author profile pages. This feature is similar to functionality common to blogging platforms, but integrates all blog posts by a given author that were archived in Rogue Scholar.
The functionality depends on an ORCID assigned to the blog post author (currently 34% of all Rogue Scholar posts), and uses information from the authors public profile page, including given and family names, affiliations with start dates, and the optional biography. Below this information you find some basic numbers similar to what Rogue Scholar blog communities show, and a searchable listing of all blog posts by that author.
Given and family names are important because blog feeds (Atom, RSS or JSONFeed, used by Rogue Scholar to extract blog post metadata) only know full names, but some Rogue Scholar authors have more complex names, including multiple given and/or family names.
The affiliation with start dates is important to assign an affiliation to a blog post author, as this depends on the public date and affiliations may change over time. My Rogue Scholar profile lists my four affiliations since starting blogging in 2007 and allows filtering of blog posts by affiliation. Multiple affiliations in parallel are currently not supported by Rogue Scholar, but luckily that is currently uncommon. This feature uses the ROR affiliation identifier, and this affiliation information is included in all blog posts archived in Rogue Scholar and registered with Crossref. ROR unfortunately doesn't assigned identifiers to single-person organizations such as Front Matter, I hope to address this in the future (either ROR relaxes its policy and/or I am able to hire more Front Matter staff).
The biography field in ORCID metadata is a nice way to have a brief publicly available summary that you can share, but this field is currently not widely used - maybe Rogue Scholar can change this for blog authors.
Author names and affiliations are functionalities that have been built-in into the Rogue Scholar backend for a while, but have now been made available to the new Rogue Scholar profiles as part of a larger ongoing refactoring effort.
Author metadata are the biggest metadata pain point when working with science blog posts in Rogue Scholar. My hope is that these new Rogue Scholar author profiles not only help increase the visibility of science blog authors, but also help with metadata quality, including more authors providing their ORCIDs. One continuing challenge is a mismatch of author names in the blog feed with what is published in the blog web page. The three main reasons are lack of support for multiple authors in RSS feeds and WordPress (without using plugins), and blogs using group authors as a proxy. While group authorship may sometimes makes sense, it is often blurring authorship, in particular when artificial intelligence increasingly is generating content instead of humans.
For these reasons Rogue Scholar is strongly encouraging individual authorship, and can help science blogs support that. In this context Rogue Scholar is also supporting contributor roles \u2013 which Crossref will support in its next metadata schema update \u2013 which might be helpful for multi-author content. In the future Rogue Scholar might stop supporting group authorship for the same reasons.
Author profile pages are of course not limited to science blogs, but make sense for many digital researcher platforms. For DataCite Commons I helped implement similar functionality in 2020, and in 2011 (before ORCID was launched) I implemented ScienceCard as a author-focussed fork of the PLOS Article-Level Metrics service.
The Rogue Scholar author profile pages are a customization of the InvenioRDM repository platform and may also be of interest to other InvenioRDM instances. Currently the profile pages use a semi-manual workflow with author metadata obtained from ORCID and stored in a yaml vocabulary, in the future this should be automated to better keep author information in sync, ideally with ORCID more consistently using ROR affiliation metadata in its profile pages.
The best and quickest discussions of a scientific paper now sometimes happen in science blogs rather than in the peer-reviewed literature. Whereas we have a number of scholarly databases that track citations between papers, we don't have the same tools for science blogs. Following all science blogs manually has simply become impossible (unless your first name is Bora). This makes it difficult to find all blog posts about a particular paper - either for proper discussion of an article or for doing automated article-level metrics.
Aggregation can help solve this problem. ResearchBlogging aggregates blog posts about peer-reviewed research. ScienceSeeker aggregates all science blog posts (currently aggregating over 400 blogs) and was announced in February. Nature Blogs also aggregates science blogs but doesn't seem to be up-to-date.
Microformats are an alternative \u2013 but of course complimentary \u2013 strategy. Microformats are small snippets of HTML that represent commonly published things. A good example is Rel-License, a microformat indicating licensed content:
<a href=\"http://creativecommons.org/licenses/by/2.0/\" rel=\"license\">cc by 2.0</a>In February Google launched a new Recipe view feature based on the hRecipe microformat, demonstrating how microformats can help discover content. There is currently no standard microformat for scholarly citations. The simplest format would again use the rel tag \u2013 together with the Citation Typing Ontology (CiTO):
<a href=\"http://dx.doi.org/10.1126/science.1197258\" rel=\"cito:discusses\">this paper</a>There are more than 20 CiTO tags for describing what we think about a particular paper or science blog post \u2013 many science bloggers would probably have used cito:critiques for the above paper. I suggest cito:discusses as the standard CiTO relationship for most papers and blog posts. You can add this tag manually, or use a tool such as the Link to Link WordPress plugin (I added cito:discusses to version 1.1.2).
We refactored the R-universe CI workflows to make it possible to run the exact same workflow from your own GitHub repository. This allows you to test or debug the build and check process on your R package, exactly as it will happen on R-universe, but without actually deploying to https://r-universe.dev.
The instructions on r-universe-org/workflows explain how it works: simply create a file /.github/workflows/r-universe-test.yml in your R package git repo with the following config:
name: Test R-universeon: push: pull_request:jobs: build: name: R-universe testing uses: r-universe-org/workflows/.github/workflows/build.yml@v3 with: universe: ${{ github.repository_owner }}That is everything. The workflow will use the fully automated R-universe setup to build and check the package on a range of R versions on Linux, Windows, and MacOS configurations very similar to CRAN.
It is possible to use this workflow in your R package for pushes and/or pull requests alongside those from r-lib/actions. Both will check your R package, but note that the purpose is very different: workflows from r-lib/actions are highly configurable and can test R packages using countless options and environments. The R-universe workflow on the other hand is, just like CRAN, not customizable at all: it uses the exact setup and process as it happens on R-universe, nothing else.
The ability to test-run the build workflow has been recurring feature request, and I hope that it will indeed help package maintainers with debugging problems. I also hope the refactoring might make it a little bit easier to understand the R-universe build process, and enable the community to hack on the workflows and actions to contribute improvements.
","doi":"https://doi.org/10.53731/gvb08-7kc16","guid":"https://doi.org/","language":"en","license":"https://creativecommons.org/licenses/by/4.0/legalcode","published_at":1767398400,"rid":"ysr3r-7dq70","summary":"We refactored the R-universe CI workflows to make it possible to run the exact same workflow from your own GitHub repository. This allows you to test or debug the build and check process on your R package, exactly as it will happen on R-universe, but without actually deploying to https://r-universe.dev.","tags":["R-universe","Infrastructure"],"title":"Testing the R-universe build workflow from your own GitHub repository","updated_at":1780984847,"url":"https://ropensci.org/blog/2026/01/03/r-universe-workflows/","version":"v1"}},{"document":{"authors":[{"affiliation":[{"name":"Front Matter"}],"contributor_roles":[],"family":"Fenner","given":"Martin","url":"https://orcid.org/0000-0003-1419-2405"}],"blog":{"authors":[{"name":"Martin Fenner","url":"https://orcid.org/0000-0003-1419-2405"}],"community_id":"15a362ea-8138-42b8-917f-1840a92addf8","created":1672531200,"current_feed_url":null,"description":"The Front Matter Blog covers the intersection of science and technology since 2007.","favicon":"https://rogue-scholar.org/api/communities/15a362ea-8138-42b8-917f-1840a92addf8/logo","feed_format":"application/atom+xml","feed_url":"https://blog.front-matter.de/atom","filter":null,"generator":"Ghost","home_page_url":"https://blog.front-matter.de/","issn":"2749-9952","language":"eng","license":"https://creativecommons.org/licenses/by/4.0/legalcode","prefix":"10.53731","relative_url":null,"secure":true,"slug":"front_matter","status":"active","subfield":"1710","title":"Front Matter","updated":1783171960,"use_api":true},"blog_name":"Front Matter","blog_slug":"front_matter","content_html":"Personal names remain among the hardest scholarly metadata to capture properly, including for science blog posts. This week, the Rogue Scholar science blog archive therefore changed how it stores blog post author names: no longer as name, which is the standard in RSS, Atom, and JSON Feeds, but as name only for an organizational author, and as given and family name for personal authors.
This follows the best practices established by ORCID, Crossref, and the Citation Style Language. DataCite and InvenioRDM (the repository platform powering Rogue Scholar and based on the DataCite metadata model) use an implementation that was good for transitioning from names to given and family names (keeping the name field for personal names), but created confusion \u2013 personal names should be stored as family name, given name (Doe, John) in the name field, but that is not trivial to enforce and led to many organizations still submitting DataCite metadata with given name family name (e.g. John Doe) as name. For this reason, Rogue Scholar is following the Crossref model and is dropping name for personal names, even if it is a breaking change.
Extracting the given and family name from a name can not be fully automated, as there are important edge cases: a) organization names that look like personal names (Alfred P. Sloan Foundation) and b) personal names with multiple family names (Bastian Greshake Tsovaras) vs. multiple given names (Martin Paul Eve) vs. names with propositions (Wilma van Weezenbeck). More background info and additional edge cases (e.g. given name without family name) can be found in a 2011 W3C document.
To handle these special cases, Rogue Scholar has started a curated list of author names that fall into one of these categories and can correctly split names into given and family names, or not split the name as it is an organizational name. The transition of the more than 40K blog posts into the new format will take some time, but is only urgent for the edge cases mentioned above.
There are further issues with personal names and metadata for scholarly blogs, including handling multiple authors (which not all blogging platforms support), author identifiers (ORCID, etc.), and author affiliations (using identifiers such as ROR, etc., affiliation changes over time) \u2013 but that is material for another blog post.
Rogue Scholar archives the content of currently more than 150 science blogs with more than 40,000 blog posts. In this blog post, I want to clarify the guidelines that Rogue Scholar tries to follow regarding authorship.
Rogue Scholar blog posts are scholarly content and thus follow the same basic guidelines as other scholarly outputs, such as journal articles, preprints, or book chapters.
All authors are expected to have made substantial contributions to the submitted work and to be accountable for the work both before and after publication. Those who contributed to the work but do not meet the criteria for authorship can be mentioned in the Acknowledgments.
AI tools cannot meet the requirements for authorship, as explained by the Committee on Publication Ethics (COPE):
AI tools cannot meet the requirements for authorship as they cannot take responsibility for the submitted work. As non-legal entities, they cannot assert the presence or absence of conflicts of interest nor manage copyright and license agreements.
And COPE recommends that:
Authors who use AI tools in the writing of a manuscript, production of images or graphical elements of the paper, or in the collection and analysis of data, must be transparent in disclosing in the Materials and Methods (or similar section) of the paper how the AI tool was used and which tool was used.
Rogue Scholar blogger Mark Dingemanse recently made a strong case for why synthetic text is incompatible with science blogging.
For blog posts with multiple authors, Rogue Scholar plans to add support for the Contributor Role Taxonomy (CRediT). And for blog posts handled by an editor or undergoing peer review, Rogue Scholar also wants to add those roles.
Rogue Scholar is an archive of science blog posts, the content is originally published elsewhere, and the decision for publication was taken by the blog authors. In rare cases, blog authors might retract a blog post or post a correction, and that information should also be communicated by Rogue Scholar and via the DOI metadata. When blog posts don't follow the above guidelines, e.g. when inappropriately using AI Tools, Rogue Scholar staff, after consultation with the Rogue Scholar Advisory Board, will decide on appropriate actions, including retraction.
Last week I released updated Python, and Go versions of the commonmeta library that can now read metadata from OpenAlex. OpenAlex is an open index of over 250 million scholarly works from 250k sources. OpenAlex uses its own identifier for works, people, organizations, sources, and concepts, but also understands common identifiers for works (e.g. DOI or PMID), people (e.g. ORCID), or organizations, including funders (e.g. ROR). Commonmeta can now fetch metadata from the OpenAlex API and convert them into the commonmeta or any other supported format.
An example command-line call would look like this:
commonmeta convert https://pubmed.ncbi.nlm.nih.gov/17160063 --from openalexOr you could fetch a random sample of 100 preprints:
commonmeta list --sample --type preprint -n 100 --from openalexOpenAlex is an impressive service for the scholarly community, launched three years ago when the Microsoft Academic Graph database stopped being updated. I particularly like the following features:
When working on integrating OpenAlex into commonmeta, I noticed some areas where the service (still only three years old) could be improved upon:
The initial OpenAlex support in commonmeta is the result of a wonderful pull request for the Python version. I mainly added test coverage and added the same functionality to the Go version. Please provide feedback via email, Slack, or GitHub if you discover bugs or missing functionality of the OpenAlex support in commonmeta.
Today I released a new version of the commonmeta-py Python library with major improvements in Crossref DOI registration, including refactoring to use the Python marshmallow library, XML schema validation, and API calls to Crossref and InvenioRDM instances via the commonmeta-py command-line interface.
Marshmallow is a popular Python library for converting complex objects to and from simple Python datatypes. The InvenioRDM repository software heavily uses marshmallow to convert metadata from and to JSON. Marshmallow is not specific to JSON, and writing Crossref metadata in XML requires an additional serialization step. commonmeta-py uses xmltodict to convert XML to Python data structures, and now also uses xmltodict for writing XML. This replaces lxml and the ElementTree API for XML writing. This worked well but didn't integrate with the rest of commonmeta-py, as the Crossref XML writer is the only place where commonmeta-py currently writes XML. More importantly, this change will make integrating commonmeta-py into InvenioRDM easier for Crossref DOI registration.
Crossref metadata are fairly complex and have different requirements depending on content type, e.g. International Standard Serial Numbers (ISSN) are only supported for some content types, or the order of metadata elements might be different. For this reason, XML schema validation before submission is critical, and commonmeta-py now supports this, using the recently released schema 5.4.0. A large part of the work for this update was generating and validating XML for the various Crossref content types. I could not cover all use cases, so feedback is appreciated, e.g., by sending me DOIs registered with Crossref but not validating in commonmeta-py.
Commonmeta (both the Python and Go versions) relies heavily on JSON schema validation, which I greatly prefer over XML Schema Definition (XSD) validation. But until Crossref allows content registration via JSON metadata (similarly to the change DataCite made a few years ago), XML schema validation remains important. The commonmeta Go library does not yet use XML schema validation.
The Rogue Scholar science blogging archive switched to the InvenioRDM repository platform in October 2024 and uses the commonmeta Go library and GitHub Actions for Crossref DOI registration. GitHub Actions are wonderful, but for more complex workflows it is easier to have the logic built into the application running in the GitHub Action. Since May 2024 that was the commonmeta Go library, and commonmeta-py now has similar functionality, including calling the Crossref and InvenioRDM APIs directly.
Starting today, the GitHub Actions for Rogue Scholar DOI registrations and updates use commonmeta-py instead of the commonmeta Go library. The next two weeks I will carefully monitor them for any issues that might have escaped testing.
The next major milestone is integrating Crossref DOI registration directly into InvenioRDM. This will not only simplify the workflows for Rogue Scholar, but makes InvenioRDM a more interesting option for repositories with original textual content, e.g. preprints, reports or dissertations.
This is the May issue of the monthly newsletter from the Rogue Scholar science blog archive. The newsletter reports on new blogs that have joined the platform, important technical updates in Rogue Scholar infrastructure, community updates, and other news relevant to Rogue Scholar users.
No new blogs were added in May, but the processing of two blog submissions is being worked on.
On May 6, the Rogue Scholar registration workflow received a major update in how personal names are handled to better accommodate edge cases such as multiple family names.
Starting on May 15, new DOI registrations for all WordPress blogs use a new scheme for the DOI suffix, using the Rogue Scholar blog identifier and WordPress post_id, e.g. https://doi.org/10.59350/rzepa.28773 for the latest post on Henry Rzepa's Blog. This allows WordPress blog authors to know the DOI for their blog posts before publication.
On May 27, Rogue Scholar switched the DOI registration workflow to the commonmeta-py Python library. This was an important step towards integrating Crossref DOI registration directly into the InvenioRDM repository platform. Since that switch, several smaller issues have been fixed, and in June, the work on Crossref DOI registration in InvenioRDM can begin.
On May 15, I published the Rogue Scholar authorship guidelines to clarify the rights and responsibilities of Rogue Scholar blog post authors, following the same basic guidelines that apply to other scholarly outputs. One particular focus was on the limitations and transparency in reporting when using the help of Artificial Intelligence in writing scholarly blog posts.
Please use Slack, email, Mastodon, or Bluesky if you have any questions or comments regarding this monthly newsletter.
This week the Rogue Scholar science blog archive experienced major upgrade pains, and Rogue Scholar search became unavailable from Tuesday until Thursday. I tried to upgrade to a pre-release version (13.0.0b4.dev0) of the InvenioRDM repository software, and ran into multiple issues. Going back to the previously installed v12.1.0 took longer than anticipated, mainly because of issues with the Opensearch index.
This morning Rogue Scholar is almost working normally again, except for the blog communities, which will take until Monday to be fixed.
The primary reason for upgrading the InvenioRDM software was so that I could integrate Crossref DOI registration, based on work I completed last week. The experience with installing a pre-release version of InvenioRDM told me a few things:
Integrating Crossref DOI registration into InvenioRDM requires a current development version of InvenioRDM, which is currently v13.x, ahead of the last released version v12.1. As InvenioRDM v13.0 will be released in a few weeks, I will wait with that work until v13.0 is released and Rogue Scholar is updated to that version. There is additional DOI registration work needed, as Rogue Scholar not only registers DOIs with Crossref, but uses multiple DOI prefixes (not yet supported in InvenioRDM) and also accepts blog posts with DOIs registered externally with DataCite.
After growing to more than 40,000 blog posts in recent months, the Rogue Scholar infrastructure, particularly the Opensearch search index, needs a hardware upgrade. I will take this opportunity to also change my deployment strategy and tooling, and will start to use Kamal to deploy the InvenioRDM software to a dedicated server (provided by Hetzner).
Rogue Scholar uses metrics and logging provided by Prometheus/Grafana and error reporting provided by Sentry. More work is needed to improve this observability to better handle incidents such as this week's upgrade issues.
Fenner, M. (2025, May 27). Major update on Commonmeta Crossref DOI registration. Front Matter. https://doi.org/10.53731/69k7z-w7030
","doi":"https://doi.org/10.53731/9nam9-w9k29","guid":"https://doi.org/10.53731/9nam9-w9k29","image":"https://images.unsplash.com/photo-1695345132969-172357b69b87?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDJ8fHN0b255JTIwcGF0aHxlbnwwfHx8fDE3NDkyMDMwNDV8MA&ixlib=rb-4.1.0&q=80&w=2000","language":"en","license":"https://creativecommons.org/licenses/by/4.0/legalcode","published_at":1749168000,"reference":[{"id":"https://doi.org/10.53731/69k7z-w7030","unstructured":"Fenner, M. (2025, May 27). Major update on Commonmeta Crossref DOI registration. Front Matter."}],"rid":"at4y3-vg902","summary":"This week the Rogue Scholar science blog archive experienced major upgrade pains, and Rogue Scholar search became unavailable from Tuesday until Thursday. I tried to upgrade to a pre-release version (13.0.0b4.dev0) of the InvenioRDM repository software, and ran into multiple issues. Going back to the previously installed v12.1.0 took longer than anticipated, mainly because of issues with the Opensearch index.","tags":["Rogue Scholar"],"title":"Rogue Scholar upgrade pains","updated_at":1780857141,"url":"https://blog.front-matter.de/posts/rogue-scholar-upgrade-pains/","version":"v1"}},{"document":{"authors":[{"affiliation":[{"name":"Front Matter"}],"contributor_roles":[],"family":"Fenner","given":"Martin","url":"https://orcid.org/0000-0003-1419-2405"}],"blog":{"authors":[{"name":"Martin Fenner","url":"https://orcid.org/0000-0003-1419-2405"}],"community_id":"15a362ea-8138-42b8-917f-1840a92addf8","created":1672531200,"current_feed_url":null,"description":"The Front Matter Blog covers the intersection of science and technology since 2007.","favicon":"https://rogue-scholar.org/api/communities/15a362ea-8138-42b8-917f-1840a92addf8/logo","feed_format":"application/atom+xml","feed_url":"https://blog.front-matter.de/atom","filter":null,"generator":"Ghost","home_page_url":"https://blog.front-matter.de/","issn":"2749-9952","language":"eng","license":"https://creativecommons.org/licenses/by/4.0/legalcode","prefix":"10.53731","relative_url":null,"secure":true,"slug":"front_matter","status":"active","subfield":"1710","title":"Front Matter","updated":1783171960,"use_api":true},"blog_name":"Front Matter","blog_slug":"front_matter","content_html":"InvenioRDM is the open source turn-key research data management platform, with detailed documentation available here. InvenioRDM Starter facilitates deployment and configuration of InvenioRDM, allowing you to run InvenioRDM on your local computer within 15 min. This is achieved by providing a) a prebuilt Invenio-App-RDM Docker image, and b) a Docker Compose configuration file with sensible defaults.
Starting this week, InvenioRDM starter can also be used to deploy InvenioRDM to production, using the Kamal tool. Kamal is similar to Docker Compose, but adds important functionality, including automatic remote builds, zero-downtime deployments, and deployments to multiple servers. Kamal is a command-line utility with a YAML configuration file, and much simpler to use than Kubernetes or commercial Docker container orchestration services such as Amazon Elastic Container Service (Amazon ECS).
Kamal can deploy InvenioRDM to your hardware or to a virtual machine provided by your organization or a cloud provider. Whereas Kubernetes is a good option for large InvenioRDM installations, smaller InvenioRDM instances benefit from simpler deployment tools both in terms of cost and required maintenance.
The science blog archive Rogue Scholar managed by Front Matter is a good example of an InvenioRDM repository that can benefit from simpler deployment options. As the next major release of InvenioRDM (v13.0) will happen in the next few weeks, Rogue Scholar needs to prepare for the upgrade, and I have this week launched a Rogue Scholar staging instance at https://staging.rogue-scholar.org using Kamal and a virtual machine provisioned by Hetzner and located in Germany.
The setup was mostly straightforward, except for the integration with the Kamal proxy server, which turned out to be very painful. In the end I had to set the InvenioRDMAPP_ALLOWED_HOSTS ENV variable to None and patch the REST API cross site request forgery (CRSF) check to not check the request host. This needs more discussion but appears safe, as all requests must go through the Kamal proxy, where the host header is already checked.
More work is needed on the staging server, including regular automatic backups of the database, and setting up monitoring (logs and metrics). The instance is running the latest stable release (v12.1.0), but I will soon be able to install the latest v13 release candidate \u2013 v13.0.0rc2 was released three days ago.
Kamal was released in 2023 by 37signals, the company behind the Basecamp and Hey services, and one of the major contributors to the Rails platform. Kamal is installed as a Ruby gem, but is not specific to Rails or Ruby. Kamal can be seen as the successor to the Capistrano deployment tool, also originally written by 37signals, but Kamal is working with Docker containers. When I was the technical lead of the Article Level Metrics project at the publisher PLOS 2012-2015 (at the time Docker was not yet adopted for production deployments), I made heavy use of Capistrano.
InvenioRDM Starter now includes a Kamal configuration option, and I deployed an InvenioRDM instance to https://demo.front-matter.io using Kamal.
![\"\"](\"https://storage.ghost.io/c/c5/33/c533c955-b5f3-4ff1-ae2d-6b52a212e602/content/images/2025/06/Bildschirmfoto-2025-06-27-um-17.49.37.png\")
Feel free to play around, but only admin accounts can create records \u2013 use the official InvenioRDM demo instance (also linked in the footer) if you want to create and/or update records. I will spend the next few weeks refining the Kamal setup and documentation, so that InvenioRDM Starter is ready for Kamal deployments when InvenioRDM v13.0 is officially released.
The science blogging archive Rogue Scholar launched a new feature this week: author profile pages. This feature is similar to functionality common to blogging platforms, but integrates all blog posts by a given author that were archived in Rogue Scholar.
The functionality depends on an ORCID assigned to the blog post author (currently 34% of all Rogue Scholar posts), and uses information from the authors public profile page, including given and family names, affiliations with start dates, and the optional biography. Below this information you find some basic numbers similar to what Rogue Scholar blog communities show, and a searchable listing of all blog posts by that author.
Given and family names are important because blog feeds (Atom, RSS or JSONFeed, used by Rogue Scholar to extract blog post metadata) only know full names, but some Rogue Scholar authors have more complex names, including multiple given and/or family names.
The affiliation with start dates is important to assign an affiliation to a blog post author, as this depends on the public date and affiliations may change over time. My Rogue Scholar profile lists my four affiliations since starting blogging in 2007 and allows filtering of blog posts by affiliation. Multiple affiliations in parallel are currently not supported by Rogue Scholar, but luckily that is currently uncommon. This feature uses the ROR affiliation identifier, and this affiliation information is included in all blog posts archived in Rogue Scholar and registered with Crossref. ROR unfortunately doesn't assigned identifiers to single-person organizations such as Front Matter, I hope to address this in the future (either ROR relaxes its policy and/or I am able to hire more Front Matter staff).
The biography field in ORCID metadata is a nice way to have a brief publicly available summary that you can share, but this field is currently not widely used - maybe Rogue Scholar can change this for blog authors.
Author names and affiliations are functionalities that have been built-in into the Rogue Scholar backend for a while, but have now been made available to the new Rogue Scholar profiles as part of a larger ongoing refactoring effort.
Author metadata are the biggest metadata pain point when working with science blog posts in Rogue Scholar. My hope is that these new Rogue Scholar author profiles not only help increase the visibility of science blog authors, but also help with metadata quality, including more authors providing their ORCIDs. One continuing challenge is a mismatch of author names in the blog feed with what is published in the blog web page. The three main reasons are lack of support for multiple authors in RSS feeds and WordPress (without using plugins), and blogs using group authors as a proxy. While group authorship may sometimes makes sense, it is often blurring authorship, in particular when artificial intelligence increasingly is generating content instead of humans.
For these reasons Rogue Scholar is strongly encouraging individual authorship, and can help science blogs support that. In this context Rogue Scholar is also supporting contributor roles \u2013 which Crossref will support in its next metadata schema update \u2013 which might be helpful for multi-author content. In the future Rogue Scholar might stop supporting group authorship for the same reasons.
Author profile pages are of course not limited to science blogs, but make sense for many digital researcher platforms. For DataCite Commons I helped implement similar functionality in 2020, and in 2011 (before ORCID was launched) I implemented ScienceCard as a author-focussed fork of the PLOS Article-Level Metrics service.
The Rogue Scholar author profile pages are a customization of the InvenioRDM repository platform and may also be of interest to other InvenioRDM instances. Currently the profile pages use a semi-manual workflow with author metadata obtained from ORCID and stored in a yaml vocabulary, in the future this should be automated to better keep author information in sync, ideally with ORCID more consistently using ROR affiliation metadata in its profile pages.
The best and quickest discussions of a scientific paper now sometimes happen in science blogs rather than in the peer-reviewed literature. Whereas we have a number of scholarly databases that track citations between papers, we don't have the same tools for science blogs. Following all science blogs manually has simply become impossible (unless your first name is Bora). This makes it difficult to find all blog posts about a particular paper - either for proper discussion of an article or for doing automated article-level metrics.
Aggregation can help solve this problem. ResearchBlogging aggregates blog posts about peer-reviewed research. ScienceSeeker aggregates all science blog posts (currently aggregating over 400 blogs) and was announced in February. Nature Blogs also aggregates science blogs but doesn't seem to be up-to-date.
Microformats are an alternative \u2013 but of course complimentary \u2013 strategy. Microformats are small snippets of HTML that represent commonly published things. A good example is Rel-License, a microformat indicating licensed content:
<a href=\"http://creativecommons.org/licenses/by/2.0/\" rel=\"license\">cc by 2.0</a>In February Google launched a new Recipe view feature based on the hRecipe microformat, demonstrating how microformats can help discover content. There is currently no standard microformat for scholarly citations. The simplest format would again use the rel tag \u2013 together with the Citation Typing Ontology (CiTO):
<a href=\"http://dx.doi.org/10.1126/science.1197258\" rel=\"cito:discusses\">this paper</a>There are more than 20 CiTO tags for describing what we think about a particular paper or science blog post \u2013 many science bloggers would probably have used cito:critiques for the above paper. I suggest cito:discusses as the standard CiTO relationship for most papers and blog posts. You can add this tag manually, or use a tool such as the Link to Link WordPress plugin (I added cito:discusses to version 1.1.2).
We refactored the R-universe CI workflows to make it possible to run the exact same workflow from your own GitHub repository. This allows you to test or debug the build and check process on your R package, exactly as it will happen on R-universe, but without actually deploying to https://r-universe.dev.
The instructions on r-universe-org/workflows explain how it works: simply create a file /.github/workflows/r-universe-test.yml in your R package git repo with the following config:
name: Test R-universeon: push: pull_request:jobs: build: name: R-universe testing uses: r-universe-org/workflows/.github/workflows/build.yml@v3 with: universe: ${{ github.repository_owner }}That is everything. The workflow will use the fully automated R-universe setup to build and check the package on a range of R versions on Linux, Windows, and MacOS configurations very similar to CRAN.
It is possible to use this workflow in your R package for pushes and/or pull requests alongside those from r-lib/actions. Both will check your R package, but note that the purpose is very different: workflows from r-lib/actions are highly configurable and can test R packages using countless options and environments. The R-universe workflow on the other hand is, just like CRAN, not customizable at all: it uses the exact setup and process as it happens on R-universe, nothing else.
The ability to test-run the build workflow has been recurring feature request, and I hope that it will indeed help package maintainers with debugging problems. I also hope the refactoring might make it a little bit easier to understand the R-universe build process, and enable the community to hack on the workflows and actions to contribute improvements.
","doi":"https://doi.org/10.53731/gvb08-7kc16","guid":"https://doi.org/","language":"en","license":"https://creativecommons.org/licenses/by/4.0/legalcode","published_at":1767398400,"rid":"ysr3r-7dq70","summary":"We refactored the R-universe CI workflows to make it possible to run the exact same workflow from your own GitHub repository. This allows you to test or debug the build and check process on your R package, exactly as it will happen on R-universe, but without actually deploying to https://r-universe.dev.","tags":["R-universe","Infrastructure"],"title":"Testing the R-universe build workflow from your own GitHub repository","updated_at":1780984847,"url":"https://ropensci.org/blog/2026/01/03/r-universe-workflows/","version":"v1"},{"authors":[{"affiliation":[{"name":"Front Matter"}],"contributor_roles":[],"family":"Fenner","given":"Martin","url":"https://orcid.org/0000-0003-1419-2405"}],"blog":{"authors":[{"name":"Martin Fenner","url":"https://orcid.org/0000-0003-1419-2405"}],"community_id":"15a362ea-8138-42b8-917f-1840a92addf8","created":1672531200,"current_feed_url":null,"description":"The Front Matter Blog covers the intersection of science and technology since 2007.","favicon":"https://rogue-scholar.org/api/communities/15a362ea-8138-42b8-917f-1840a92addf8/logo","feed_format":"application/atom+xml","feed_url":"https://blog.front-matter.de/atom","filter":null,"generator":"Ghost","home_page_url":"https://blog.front-matter.de/","issn":"2749-9952","language":"eng","license":"https://creativecommons.org/licenses/by/4.0/legalcode","prefix":"10.53731","relative_url":null,"secure":true,"slug":"front_matter","status":"active","subfield":"1710","title":"Front Matter","updated":1783171960,"use_api":true},"blog_name":"Front Matter","blog_slug":"front_matter","content_html":"Personal names remain among the hardest scholarly metadata to capture properly, including for science blog posts. This week, the Rogue Scholar science blog archive therefore changed how it stores blog post author names: no longer as name, which is the standard in RSS, Atom, and JSON Feeds, but as name only for an organizational author, and as given and family name for personal authors.
This follows the best practices established by ORCID, Crossref, and the Citation Style Language. DataCite and InvenioRDM (the repository platform powering Rogue Scholar and based on the DataCite metadata model) use an implementation that was good for transitioning from names to given and family names (keeping the name field for personal names), but created confusion \u2013 personal names should be stored as family name, given name (Doe, John) in the name field, but that is not trivial to enforce and led to many organizations still submitting DataCite metadata with given name family name (e.g. John Doe) as name. For this reason, Rogue Scholar is following the Crossref model and is dropping name for personal names, even if it is a breaking change.
Extracting the given and family name from a name can not be fully automated, as there are important edge cases: a) organization names that look like personal names (Alfred P. Sloan Foundation) and b) personal names with multiple family names (Bastian Greshake Tsovaras) vs. multiple given names (Martin Paul Eve) vs. names with propositions (Wilma van Weezenbeck). More background info and additional edge cases (e.g. given name without family name) can be found in a 2011 W3C document.
To handle these special cases, Rogue Scholar has started a curated list of author names that fall into one of these categories and can correctly split names into given and family names, or not split the name as it is an organizational name. The transition of the more than 40K blog posts into the new format will take some time, but is only urgent for the edge cases mentioned above.
There are further issues with personal names and metadata for scholarly blogs, including handling multiple authors (which not all blogging platforms support), author identifiers (ORCID, etc.), and author affiliations (using identifiers such as ROR, etc., affiliation changes over time) \u2013 but that is material for another blog post.
Rogue Scholar archives the content of currently more than 150 science blogs with more than 40,000 blog posts. In this blog post, I want to clarify the guidelines that Rogue Scholar tries to follow regarding authorship.
Rogue Scholar blog posts are scholarly content and thus follow the same basic guidelines as other scholarly outputs, such as journal articles, preprints, or book chapters.
All authors are expected to have made substantial contributions to the submitted work and to be accountable for the work both before and after publication. Those who contributed to the work but do not meet the criteria for authorship can be mentioned in the Acknowledgments.
AI tools cannot meet the requirements for authorship, as explained by the Committee on Publication Ethics (COPE):
AI tools cannot meet the requirements for authorship as they cannot take responsibility for the submitted work. As non-legal entities, they cannot assert the presence or absence of conflicts of interest nor manage copyright and license agreements.
And COPE recommends that:
Authors who use AI tools in the writing of a manuscript, production of images or graphical elements of the paper, or in the collection and analysis of data, must be transparent in disclosing in the Materials and Methods (or similar section) of the paper how the AI tool was used and which tool was used.
Rogue Scholar blogger Mark Dingemanse recently made a strong case for why synthetic text is incompatible with science blogging.
For blog posts with multiple authors, Rogue Scholar plans to add support for the Contributor Role Taxonomy (CRediT). And for blog posts handled by an editor or undergoing peer review, Rogue Scholar also wants to add those roles.
Rogue Scholar is an archive of science blog posts, the content is originally published elsewhere, and the decision for publication was taken by the blog authors. In rare cases, blog authors might retract a blog post or post a correction, and that information should also be communicated by Rogue Scholar and via the DOI metadata. When blog posts don't follow the above guidelines, e.g. when inappropriately using AI Tools, Rogue Scholar staff, after consultation with the Rogue Scholar Advisory Board, will decide on appropriate actions, including retraction.
Last week I released updated Python, and Go versions of the commonmeta library that can now read metadata from OpenAlex. OpenAlex is an open index of over 250 million scholarly works from 250k sources. OpenAlex uses its own identifier for works, people, organizations, sources, and concepts, but also understands common identifiers for works (e.g. DOI or PMID), people (e.g. ORCID), or organizations, including funders (e.g. ROR). Commonmeta can now fetch metadata from the OpenAlex API and convert them into the commonmeta or any other supported format.
An example command-line call would look like this:
commonmeta convert https://pubmed.ncbi.nlm.nih.gov/17160063 --from openalexOr you could fetch a random sample of 100 preprints:
commonmeta list --sample --type preprint -n 100 --from openalexOpenAlex is an impressive service for the scholarly community, launched three years ago when the Microsoft Academic Graph database stopped being updated. I particularly like the following features:
When working on integrating OpenAlex into commonmeta, I noticed some areas where the service (still only three years old) could be improved upon:
The initial OpenAlex support in commonmeta is the result of a wonderful pull request for the Python version. I mainly added test coverage and added the same functionality to the Go version. Please provide feedback via email, Slack, or GitHub if you discover bugs or missing functionality of the OpenAlex support in commonmeta.
Today I released a new version of the commonmeta-py Python library with major improvements in Crossref DOI registration, including refactoring to use the Python marshmallow library, XML schema validation, and API calls to Crossref and InvenioRDM instances via the commonmeta-py command-line interface.
Marshmallow is a popular Python library for converting complex objects to and from simple Python datatypes. The InvenioRDM repository software heavily uses marshmallow to convert metadata from and to JSON. Marshmallow is not specific to JSON, and writing Crossref metadata in XML requires an additional serialization step. commonmeta-py uses xmltodict to convert XML to Python data structures, and now also uses xmltodict for writing XML. This replaces lxml and the ElementTree API for XML writing. This worked well but didn't integrate with the rest of commonmeta-py, as the Crossref XML writer is the only place where commonmeta-py currently writes XML. More importantly, this change will make integrating commonmeta-py into InvenioRDM easier for Crossref DOI registration.
Crossref metadata are fairly complex and have different requirements depending on content type, e.g. International Standard Serial Numbers (ISSN) are only supported for some content types, or the order of metadata elements might be different. For this reason, XML schema validation before submission is critical, and commonmeta-py now supports this, using the recently released schema 5.4.0. A large part of the work for this update was generating and validating XML for the various Crossref content types. I could not cover all use cases, so feedback is appreciated, e.g., by sending me DOIs registered with Crossref but not validating in commonmeta-py.
Commonmeta (both the Python and Go versions) relies heavily on JSON schema validation, which I greatly prefer over XML Schema Definition (XSD) validation. But until Crossref allows content registration via JSON metadata (similarly to the change DataCite made a few years ago), XML schema validation remains important. The commonmeta Go library does not yet use XML schema validation.
The Rogue Scholar science blogging archive switched to the InvenioRDM repository platform in October 2024 and uses the commonmeta Go library and GitHub Actions for Crossref DOI registration. GitHub Actions are wonderful, but for more complex workflows it is easier to have the logic built into the application running in the GitHub Action. Since May 2024 that was the commonmeta Go library, and commonmeta-py now has similar functionality, including calling the Crossref and InvenioRDM APIs directly.
Starting today, the GitHub Actions for Rogue Scholar DOI registrations and updates use commonmeta-py instead of the commonmeta Go library. The next two weeks I will carefully monitor them for any issues that might have escaped testing.
The next major milestone is integrating Crossref DOI registration directly into InvenioRDM. This will not only simplify the workflows for Rogue Scholar, but makes InvenioRDM a more interesting option for repositories with original textual content, e.g. preprints, reports or dissertations.
This is the May issue of the monthly newsletter from the Rogue Scholar science blog archive. The newsletter reports on new blogs that have joined the platform, important technical updates in Rogue Scholar infrastructure, community updates, and other news relevant to Rogue Scholar users.
No new blogs were added in May, but the processing of two blog submissions is being worked on.
On May 6, the Rogue Scholar registration workflow received a major update in how personal names are handled to better accommodate edge cases such as multiple family names.
Starting on May 15, new DOI registrations for all WordPress blogs use a new scheme for the DOI suffix, using the Rogue Scholar blog identifier and WordPress post_id, e.g. https://doi.org/10.59350/rzepa.28773 for the latest post on Henry Rzepa's Blog. This allows WordPress blog authors to know the DOI for their blog posts before publication.
On May 27, Rogue Scholar switched the DOI registration workflow to the commonmeta-py Python library. This was an important step towards integrating Crossref DOI registration directly into the InvenioRDM repository platform. Since that switch, several smaller issues have been fixed, and in June, the work on Crossref DOI registration in InvenioRDM can begin.
On May 15, I published the Rogue Scholar authorship guidelines to clarify the rights and responsibilities of Rogue Scholar blog post authors, following the same basic guidelines that apply to other scholarly outputs. One particular focus was on the limitations and transparency in reporting when using the help of Artificial Intelligence in writing scholarly blog posts.
Please use Slack, email, Mastodon, or Bluesky if you have any questions or comments regarding this monthly newsletter.
This week the Rogue Scholar science blog archive experienced major upgrade pains, and Rogue Scholar search became unavailable from Tuesday until Thursday. I tried to upgrade to a pre-release version (13.0.0b4.dev0) of the InvenioRDM repository software, and ran into multiple issues. Going back to the previously installed v12.1.0 took longer than anticipated, mainly because of issues with the Opensearch index.
This morning Rogue Scholar is almost working normally again, except for the blog communities, which will take until Monday to be fixed.
The primary reason for upgrading the InvenioRDM software was so that I could integrate Crossref DOI registration, based on work I completed last week. The experience with installing a pre-release version of InvenioRDM told me a few things:
Integrating Crossref DOI registration into InvenioRDM requires a current development version of InvenioRDM, which is currently v13.x, ahead of the last released version v12.1. As InvenioRDM v13.0 will be released in a few weeks, I will wait with that work until v13.0 is released and Rogue Scholar is updated to that version. There is additional DOI registration work needed, as Rogue Scholar not only registers DOIs with Crossref, but uses multiple DOI prefixes (not yet supported in InvenioRDM) and also accepts blog posts with DOIs registered externally with DataCite.
After growing to more than 40,000 blog posts in recent months, the Rogue Scholar infrastructure, particularly the Opensearch search index, needs a hardware upgrade. I will take this opportunity to also change my deployment strategy and tooling, and will start to use Kamal to deploy the InvenioRDM software to a dedicated server (provided by Hetzner).
Rogue Scholar uses metrics and logging provided by Prometheus/Grafana and error reporting provided by Sentry. More work is needed to improve this observability to better handle incidents such as this week's upgrade issues.
Fenner, M. (2025, May 27). Major update on Commonmeta Crossref DOI registration. Front Matter. https://doi.org/10.53731/69k7z-w7030
","doi":"https://doi.org/10.53731/9nam9-w9k29","guid":"https://doi.org/10.53731/9nam9-w9k29","image":"https://images.unsplash.com/photo-1695345132969-172357b69b87?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDJ8fHN0b255JTIwcGF0aHxlbnwwfHx8fDE3NDkyMDMwNDV8MA&ixlib=rb-4.1.0&q=80&w=2000","language":"en","license":"https://creativecommons.org/licenses/by/4.0/legalcode","published_at":1749168000,"reference":[{"id":"https://doi.org/10.53731/69k7z-w7030","unstructured":"Fenner, M. (2025, May 27). Major update on Commonmeta Crossref DOI registration. Front Matter."}],"rid":"at4y3-vg902","summary":"This week the Rogue Scholar science blog archive experienced major upgrade pains, and Rogue Scholar search became unavailable from Tuesday until Thursday. I tried to upgrade to a pre-release version (13.0.0b4.dev0) of the InvenioRDM repository software, and ran into multiple issues. Going back to the previously installed v12.1.0 took longer than anticipated, mainly because of issues with the Opensearch index.","tags":["Rogue Scholar"],"title":"Rogue Scholar upgrade pains","updated_at":1780857141,"url":"https://blog.front-matter.de/posts/rogue-scholar-upgrade-pains/","version":"v1"},{"authors":[{"affiliation":[{"name":"Front Matter"}],"contributor_roles":[],"family":"Fenner","given":"Martin","url":"https://orcid.org/0000-0003-1419-2405"}],"blog":{"authors":[{"name":"Martin Fenner","url":"https://orcid.org/0000-0003-1419-2405"}],"community_id":"15a362ea-8138-42b8-917f-1840a92addf8","created":1672531200,"current_feed_url":null,"description":"The Front Matter Blog covers the intersection of science and technology since 2007.","favicon":"https://rogue-scholar.org/api/communities/15a362ea-8138-42b8-917f-1840a92addf8/logo","feed_format":"application/atom+xml","feed_url":"https://blog.front-matter.de/atom","filter":null,"generator":"Ghost","home_page_url":"https://blog.front-matter.de/","issn":"2749-9952","language":"eng","license":"https://creativecommons.org/licenses/by/4.0/legalcode","prefix":"10.53731","relative_url":null,"secure":true,"slug":"front_matter","status":"active","subfield":"1710","title":"Front Matter","updated":1783171960,"use_api":true},"blog_name":"Front Matter","blog_slug":"front_matter","content_html":"InvenioRDM is the open source turn-key research data management platform, with detailed documentation available here. InvenioRDM Starter facilitates deployment and configuration of InvenioRDM, allowing you to run InvenioRDM on your local computer within 15 min. This is achieved by providing a) a prebuilt Invenio-App-RDM Docker image, and b) a Docker Compose configuration file with sensible defaults.
Starting this week, InvenioRDM starter can also be used to deploy InvenioRDM to production, using the Kamal tool. Kamal is similar to Docker Compose, but adds important functionality, including automatic remote builds, zero-downtime deployments, and deployments to multiple servers. Kamal is a command-line utility with a YAML configuration file, and much simpler to use than Kubernetes or commercial Docker container orchestration services such as Amazon Elastic Container Service (Amazon ECS).
Kamal can deploy InvenioRDM to your hardware or to a virtual machine provided by your organization or a cloud provider. Whereas Kubernetes is a good option for large InvenioRDM installations, smaller InvenioRDM instances benefit from simpler deployment tools both in terms of cost and required maintenance.
The science blog archive Rogue Scholar managed by Front Matter is a good example of an InvenioRDM repository that can benefit from simpler deployment options. As the next major release of InvenioRDM (v13.0) will happen in the next few weeks, Rogue Scholar needs to prepare for the upgrade, and I have this week launched a Rogue Scholar staging instance at https://staging.rogue-scholar.org using Kamal and a virtual machine provisioned by Hetzner and located in Germany.
The setup was mostly straightforward, except for the integration with the Kamal proxy server, which turned out to be very painful. In the end I had to set the InvenioRDMAPP_ALLOWED_HOSTS ENV variable to None and patch the REST API cross site request forgery (CRSF) check to not check the request host. This needs more discussion but appears safe, as all requests must go through the Kamal proxy, where the host header is already checked.
More work is needed on the staging server, including regular automatic backups of the database, and setting up monitoring (logs and metrics). The instance is running the latest stable release (v12.1.0), but I will soon be able to install the latest v13 release candidate \u2013 v13.0.0rc2 was released three days ago.
Kamal was released in 2023 by 37signals, the company behind the Basecamp and Hey services, and one of the major contributors to the Rails platform. Kamal is installed as a Ruby gem, but is not specific to Rails or Ruby. Kamal can be seen as the successor to the Capistrano deployment tool, also originally written by 37signals, but Kamal is working with Docker containers. When I was the technical lead of the Article Level Metrics project at the publisher PLOS 2012-2015 (at the time Docker was not yet adopted for production deployments), I made heavy use of Capistrano.
InvenioRDM Starter now includes a Kamal configuration option, and I deployed an InvenioRDM instance to https://demo.front-matter.io using Kamal.
Feel free to play around, but only admin accounts can create records \u2013 use the official InvenioRDM demo instance (also linked in the footer) if you want to create and/or update records. I will spend the next few weeks refining the Kamal setup and documentation, so that InvenioRDM Starter is ready for Kamal deployments when InvenioRDM v13.0 is officially released.