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.
Conventions
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:
url: the URL associated with a resource. This should be the master URL for a primarily online source, or an additional URL for objects which have a DOI; that is, the url field should not for example include adx.doi.orgmirror of the DOI.lastchecked: it's often recommended that if a URL is cited, there should be a 'lastchecked' note as well, indicating when the URL was last verified to exist; this should be a date, without it being restricted to any particular formatdoi: the DOI associated with a publication; the prefix 'doi:' should not be present, nor should it be expressed as a dx.doi.org URLeprint: there are two possible conventions here. (i) The one represented in the output of ADS haseprintbeing a repository identifier, which relates to 'arXiv' by default, but which can also be an ASCL identifier (others?); the repository is indicated by anarchiveprefixkey, which can be 'arXiv' (no colon) or 'ascl'. (ii) An alternative (and I've implemented this one in an still-unreleased .bst file) is to have a prefix within theeprintkey, thusyymm.nnnn, orarxiv:yymm.nnnnorascl:yymm.nnn(with the default being again arXiv). It doesn't make any sense to have two competing conventions, but there's no way to resolve this other than by guesswork.ORCID: There are no conventions here. I have some ideas (which I should broadcast from this blog), but if some emerge it would be good if they had some community consensus from the start.
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.
Outcomes
A good set of outcomes would be:
A list of acknowledged conventions, so that if you're trying to generate
.biboutput, or if you're trying to implement a.bststyle file, you can see ‘ah, so that's how I should represent DOIs, without thedoi:prefix’.Fewer redundancies: we presumably don't need all of
@webpage,@electronicand@url(since each are presumably just a way of tarting up a reference to a URL), and shifting to a single one would mean less implementation work for everyone. Regardingeprint, for example, I prefer syntax (ii) to syntax (i) above, but I'd switch my code to (i) in a moment if that would stop there ever being an option (iii).Some forum for achieving at least rough consensus around new things like ORCIDs (that same forum would effectively be a way of sharing implementation code, which is a bonus).
Process
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.