Automatically generated DOI's for blog posts

[d33bs]

Thanks for the awesome work on this project! I find it a blast to use for writing blog posts. As I've written these I've wondered about how to best make each post citable. It'd be wonderful if there were a way to create citation information and automatically mint DOI's somehow. This way, if someone wanted to cite a post written in a lab-website-template based site, they could simply grab the DOI and use it where appropriate (leveraging citation tools such as Zotero, etc. to automatically gather the meta about a post).

Maybe the workflow would look something like: blog post gets merged -> post content + meta collected and sent to DOI minter -> DOI returned and automatically is added to the LWT rendered page.

I'm unsure how complicated this might get and recognize it might be out of scope. Just the same, I thought it might be interesting to explore, especially if there's a "low-hanging fruit" path towards accomplishing this.

[cgreene]

This is a very interesting idea. I think the most practical way would probably be to have an optional interaction with zenodo's API. I'm not sure how you'd handle auth at a user level - I could definitely see it at the website level (with github secrets + a zenodo token).

Thinking through this, it's almost an interaction that could be generalizable with manubot (to optionally create an automatically updated version on zenodo). Also, the citation infrastructure from manubot could potentially be usable within the blog posts as well - almost a convergence of publishing / citation infrastructure. Sort of like each lab website template blog could be a bit like a manubot manuscript...

[vincerubinetti]

This is an interesting idea. But my first thought is that it falls outside the scope of this project meant to be more of a website and less of a tool like Manubot. The inner-platform-effect comes to mind; it seems like something that would be more appropriately added to Manubot itself.

It's doable though, of course. I would imagine that it'd most appropriately be integrated into the cite process, so we're not adding a completely new mechanism/pipeline just for this. Like, a user puts an entry like - id: "mint:/blog/intro-to-testing" in their sources.yaml, and the template detects that in the normal cite process and adds an extra minting step to generate a DOI before continuing like normal (generating the full citation details with Manubot afterward). There would be complications to this though, like it would take a while for Manubot to recognize the new DOI (waiting for all the related databases to update). Also it would require authentication, which in my experience, almost none of the template users set up (so this would be significant extra work for potentially not many users).

Have you tried to use manubot cite on a LWT blog post with the cite by url feature? I'm wondering if what that would produce would be good enough, because I've tried to include as much metadata in each page of the template as possible, some of which should be able to be picked up by Manubot:

https://github.com/greenelab/lab-website-template/blob/main/_includes/meta.html

As I've written these I've wondered about how to best make each post citable.

In what exact ways do you want the post to be citable? The impression I'm getting is that you want a more "official" DOI or something like that, but what if there was a little "cite me" button at the top of each blog post that would copy citation text in a standard format to the clipboard?

[d33bs]

Thanks @cgreene and @vincerubinetti for the replies here! Sharing along some options based on what you mentioned and also research on the topic.

• Zenodo could be used if we perhaps package up the article as a PDF and archive there, then circle back to provide a DOI.
• Rogue scholar might be a good way to create DOI's per post and seems to cater to blogs in particular.
• DataCite could be another option if the audience have membership somehow.
• A decentralized solution could involve the use of nanopublications (where we make assertions and provide metadata upfront about a blog post). Maybe this could be uploaded to Zenodo or a nanopub server somehwere to help with the DOI part of things.

Thinking through this, it's almost an interaction that could be generalizable with manubot (to optionally create an automatically updated version on zenodo).

This sounds really interesting! I wonder if a solution for LWT would also apply to Manubot? Maybe once if/when things firm up here we could brainstorm how to transfer that same workflow to Manubot? We could also open a new issue to explore this under that repo in case the path might be different.

In what exact ways do you want the post to be citable?

My personal use case involves using Zotero's "magic wand" button which lets me import from a DOI and gather all metadata for citations in one spot. When it comes time to cite someone I can export those citations in multiple ways (into Google docs, CITATION.cff format, etc) from the same location without having to copy+paste any materials (or second guess that I got things mostly correct). It'd be great to enable this type of functionality for blog posts where someone can easily find the DOI at the top and then be granted the metadata all at once. I think it also provides a feeling of authenticity - that the work is integrated into the DOI ecosystem. Writing all this out now has me wondering how that "magic" occurs - perhaps there's a spec which we could implement to make this happen.

[vincerubinetti]

for blog posts where someone can easily find the DOI at the top and then be granted the metadata all at once.

Aside from the DOI, I think this is already possible. That is, we (the template/user) already have the info we need to generate a citation (title, author, url, date) that could be easily displayed and/or copied from the top of an article.

And if someone needs programmatic access, theoretically Manubot should be able to cite a blog post by URL and gather all the same info. Here's what running manubot cite https://cu-dbmi.github.io/set-website/2024/09/25/Testing-Scientific-Software.html produces:

JSON

[
  {
    "id": "14lTE2b1L",
    "type": "webpage",
    "abstract": "CU Dept. of Biomedical Informatics. The software engineering team of the Department of Biomedical Informatics at the University of Colorado Anschutz",
    "language": "en",
    "title": "Testing Scientific Software: A Practical Guide for Developers",
    "title-short": "Testing Scientific Software",
    "URL": "https://cu-dbmi.github.io/set-website",
    "author": [
      {
        "literal": "dave-bunten"
      }
    ],
    "accessed": {
      "date-parts": [
        [
          "2025",
          5,
          7
        ]
      ]
    },
    "issued": {
      "date-parts": [
        [
          "2024",
          9,
          25
        ]
      ]
    },
    "note": "This CSL Item was generated by Manubot v0.6.1 from its persistent identifier (standard_id).\nstandard_id: url:https://cu-dbmi.github.io/set-website/2024/09/25/Testing-Scientific-Software.html"
  }
]

Definitely room for improvement there, e.g. with the author and abstract, but it proves it's possible.

I think it also provides a feeling of authenticity

I think this is what it comes down to, given the above. An authoritative and recorded ID is better if possible. But I'm not sure the added complexity is worth the value.

I just looked through all the sites in the gallery, and about half of them have a news/blog page, and many of the ones that do only have a "Hello World" or other minor posts. The ones that have more substantial posts are still all "news" focused, and not really using it for making citable works.

I know sometimes people don't know what they want until it is shown to them, but I feel strongly that this doesn't belong in the base template until we get at least a few other users who say they're interested. No one I've seen has tried to use the template for something like this purpose yet, and putting myself in a lab's shoes, if I wanted to publish something more official, I'd do it through established avenues like bioRxiv or something.

I think this should be tested out in https://github.com/CU-DBMI/set-website first, where it makes the most sense.

Regarding the specific possible solutions mentioned:

Zenodo ... article as a PDF ... then circle back to provide a DOI.

This seems the most "correct" and automatable way to do it, and also the most complex. I'm imagining at least 100 lines of code, which is a lot extra maintenance (for us and regular users) for a feature that most users won't use.

Rogue scholar ... seems to cater to blogs in particular.

This is convenient, but seems to require manual action by the user (no API?). This could be as simple as a note at the top of the "blog" page in the docs saying "want to generate a DOI for your blog posts? try rogue scholar". Also, licensing restrictions.

DataCite ... if the audience have membership somehow

Needing a membership would be a hurdle that would reduce participation in the feature even further.

nanopublications ... provide metadata upfront about a blog post

Per above, we already provide metadata about each blog post, though maybe this entails different pieces of info (though what else is there to provide that we're not already?)

[d33bs]

I think this is what it comes down to, given the above. An authoritative and recorded ID is better if possible. But I'm not sure the added complexity is worth the value.

I feel the complexity is worth the value and can understand why you don't want that complexity within this project given what you mentioned about the audience. That said, maybe a spin-off would be nice to explore (if there's an existing tool) or build. I'm envisioning some sort of command-line package which can take a list of articles, pull their metadata, transform that metadata to meet a publisher's spec, and then upload to Zenodo (or perhaps another DOI minter) automatically. This would save a lot of time, decouple the complexity from this project, and help achieve the authoritative ID with linkage into tools like Zotero.