A registry of BibTeX conventions


There are a number of informal BibTeX conventions for things like the url field or doi or eprint. They're 'informal' since they're not documented anywhere, but are either obvious, or have some obvious consensus on use. As well, there's at least one fairly common BibTeX entry type – @webpage – which I at least support in the 'urlbst' style.

(Of course, one possible response is to say to hell with BibTeX's psycho-spawn-of-postscript style language – everyone should use biblatex instead. Well, yes, maybe, hmmm; but until then, we might still need to tweak style files.)

My stake in this is that I have some role in the maintenance of a couple of journal BibTeX styles, and I maintain the urlbst package, which is intended to splice support for the @webpage entry type into existing style files, along with support for several of the extended fields listed below.


It would surely be useful to have some sort of registry of these conventions, and the only way that would emerge would be by some sort of ground-up community effort.

There are extensions of two types: extended entry types (that is, additions to the standard list of @article, @book, and so on), and extended fields (that is, extensions to the list title, author, and so on).

Simply looking at the appropriate menu item in a copy of BibDesk, I can see @glossdef, @jurthesis, @periodical, @url (yes, as an entry type), @electronic, and @webpage. There's clear redundancy between those.

The extended fields I can think of are:

Looking at BibDesk, again, I can see a smattering of non-standard fields, some clearly very ad hoc. I'm sure there are other conventions.

Of course, since BibTeX doesn't object to non-standard entry types and fields, there's no real cost to having them. The problem is that they will often be implemented inconsistently, which dilutes much of the value of having them in a sharable bibliographic database.


A good set of outcomes would be:


The obvious technical mechanism would be a wiki page, but a github.io page attached to a github 'organisation' would be a more fashionable alternative. The obvious social mechanism would be to do some quick census of available .bst files looking for the individuals maintaining them, and ping those people. A googlegroup would act as a suitable proxy for a mailing list, unless anyone has better suggestions (where the metric for ‘better’ might reasonably include terms for ‘more fashionable’ or ‘more fun’).

It's my distinct impression that all the people doing .bst file maintenance are doing it in a small fraction of their time, so it would be important that this isn't a heavyweight thing.

If you think this is a good idea, mail me.

Norman, 2015 February 19