👩‍🔬 Add more frontmatter fields for different venue types

[fwkoch]

This just adds a few fields to frontmatter.venue and frontmatter.biblio.

• biblio contains volume/issue info - these may now have a title and subject
• venue is a bit more flexible - it may be a journal, a conference, an entry in a conference proceedings series, etc... location, date, number may apply to a conference; issn and publisher may apply to a journal; series may apply to a series of publications (JATS has a similar field: https://jats.nlm.nih.gov/archiving/tag-library/1.3/element/series.html)

[changeset-bot]

🦋 Changeset detected

Latest commit: 21b8611

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
myst-frontmatter	Patch
myst-common	Patch
myst-config	Patch
myst-spec-ext	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[fwkoch]

As usual, when writing this up, I realize I need to add the comment I made in this PR to the docs 📚

[fwkoch]

Docs are now updated!

[rowanc1]

I think there are some naming / location updates for the frontmatter that could be done. Especially around the issue/volume side? Maybe volume/issue should be objects each with their own metadata in biblio?

Maybe this is just prefixing issue_ to things in biblio?

[rowanc1]

I think make changing this to issue_doi might be better. Unlike the venue, this isn't totally clear that the biblio.doi is for the issue?

[rowanc1]

Similar to doi, the title/subject here could maybe just be expanded to issue_subject and issue_title?

[fwkoch]

Yeah - that makes sense. We adopted biblio from OpenAlex - https://docs.openalex.org/api-entities/works/work-object#biblio - which they describe cheekily as an "old-timey" thing. I don't necessarily think it should be treated that dismissively; even modern web-first (or web-only) journals like JOSS still have volumes and issues. We've already extended the OpenAlex biblio spec by adding doi, prior to this PR. Maybe we should just do away with biblio and instead have top-level volume and issue objects.

This would allow us to grow, even beyond this current PR. For example volumes and issues may each have their own doi (and probably title and subject too). We could also pull first/last_page up to the top level; this makes more sense when sharing frontmatter - you can share the issue without accidentally sharing page numbers. Mapping other fields from biblio to volume/issue would also be very straightforward for backwards compatibility.

So, something like:

biblio:
  first_page: 1
  last_page: 5
  volume: '4'
  issue: 'Spring'
  doi: 10.0000/abc123
  title: '...'
  subject: '...'

becomes:

first_page: 1
last_page: 5
volume:
  number: '4'
  doi: 10.0000/abc123
  title: '...'
  subject: '...'
issue:
  number: 'Spring'
  doi: '...'
  title: '...'
  subject: '...'

[rowanc1]

I like that approach @fwkoch. It would be nice to support biblio in the parsing and have some test coverage for it (with deprecation warnings). I don't expect this to be used widely at all yet.