5

A very common scheme for bibtexkeys is FirstauthornameYYYY like Bohr1922.

This scheme is not well suited for collaborating in teams because of collisions (Bohr1922a vs. Bohr1922b if there were many papers published by Bohr in 1922)

Digital Object Identifier (doi) might help here, if the user finds a rule for documents without doi.

Are there any other pitfalls when using doi as bibtexkey?

(For example will bib related packages claim illegal characters or too long identifiers?)

8
  • 7
    Apart from remembering them...?
    – Alan Munn
    Mar 1, 2015 at 18:36
  • 4
    I'm not sure if BibTeX/Biber would like a comma or curly brace in DOIs, the "normal" characters one sees most often should be fine - the biggest problem I see though is that DOIs are too long to comfortably type and to remember (plus they have almost no meaning, whereas Bohr1922 carries quite some).
    – moewe
    Mar 1, 2015 at 18:42
  • If collaboration is the issue, make a commonly accessible .bib file using Dropbox or equivalent and just reconcile the duplicates/inconsistencies as people add entries to the bib file. This seems far more practical than adopting a cumbersome key scheme for all your bib entries.
    – Alan Munn
    Mar 1, 2015 at 19:06
  • 4
    A pretty good system, I think, is the following: lastname + year + "the first letter of the first four words of the title". So if John Smith wrote an article entitled "The 10 Do's and 500 Don'ts of Knife Safety" in 1993, the BibTeX key would be smith1993ttda (i.e., don't ignore the "small" words). It is an easy "rule" to remember and explain to others, and is unlikely to produce (m)any conflicts.
    – jon
    Mar 2, 2015 at 4:25
  • 2
    You could use the short DOI as bibtexkey: shortdoi.org These come in the form ` 10/abcde`
    – matth
    Apr 16, 2015 at 13:22

1 Answer 1

7

Technical Limitations

The technical limitations of using the DOI as bibkey are that they should not contain a character that has special meaning in the .bib file syntax, that is you cannot have a comma , or curly braces {/} because that will make Biber/BibTeX think the bibkey has ended when it hasn't.

Additionally one should be wary of special UTF8 characters in bibkeys (see How to have special characters (e.g. german umlauts) inside bibkeys?) which are certainly possible by the DOI standard (see DOI handbook)

DOI names may incorporate any printable characters from the Universal Character Set (UCS-2), of ISO/IEC 10646, which is the character set defined by Unicode v2.0. The UCS-2 character set encompasses most characters used in every major language written today.

[...]

The Handle System at its core uses UTF-8, which is a Unicode implementation and so in its pure form has no character set constraints at all: any character can be sent to, stored in, and retrieved from a handle server. The IDF imposes no additional character set constraints. In practice, though, there are many character set constraints enforced by the current web environment, depending on the individual user's context — for example, what kind of browser is being used.

[...]

Except for the specific requirements imposed by this standard (such as use of Unicode and reserved characters), no restrictions are imposed or assumptions made about the characters used in DOIs.

So you cannot be sure that you can actually support all possible DOIs in bibkeys because of LaTeX/biblatex's technical restrictions.

In real life, however, you will probably struggle a bit to find a malicious DOI - a major part is benign and only contains digits, lower case letters, dots and slashes; but then there are beauties such as

10.1002/(SICI)1096-987X(199803)19:4<377::AID-JCC1>3.0.CO;2-P

where Biber refused to compile because of the parentheses, BibTeX ploughed on happily, though.

In a nutshell, the DOI standard does not prohibit problematic DOIs that might cause havoc in the file, and while most DOIs out there today are totally fine there are already some that are troublesome.

"Human Factors and Ergonomics (and Mnemonics)"

In an ideal world bibkeys are easy to remember and recognise such that someone who sees the bibkey immediately knows what work it refers to - or at least has a rough idea. Bibkeys containing the author name, a year, some leads on the title in the form of the most important word or initials are arguably easier to remember and give a better primer of what the work might be about - a DOI will be helpful in this regard only to very, very few people (but there are auto-complete features and bibliography integrations for editors so that this can be remedied up to some point).

In a nutshell, DOIs are very abstract and (almost) devoid of any meaning for humans thus inhibiting an easy grasp of the works cited from seeing just the bibkeys.

Alternative Approaches

The undeniable plus side of using DOIs is that we are guaranteed to be collision free. Most other (more human readable) formats have a risk of suffering from some form of collision.

You could either go down the route of choosing one of the following formats suggested by egreg and jon

  • <name>+<year>+<prominent word in the title/important concept of the article>
  • <name>+<year>+<journal/volume>
  • <name>+<year>+<letter>
  • <name>+<year>+<first letter of the first n words>

Of course none of these are guaranteed to be unique, but they come close. (Some editors provide facilities to auto-generate some forms of keys and check uniqueness in the database.)

3
  • 1
    I've got examples with # in the DOI: good luck with those!
    – Joseph Wright
    Mar 12, 2015 at 10:42
  • 1
    Instead of the DOI one could use a hash of it, solving the problem with special characters, but adding another obfuscation layer.
    – egreg
    Mar 12, 2015 at 11:13
  • 2
    I think the short DOIs generated by shortdoi.org come very close to a hash. And they can still be resolved.
    – matth
    Dec 23, 2015 at 8:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .