This document is simply a corrected version of Appendix B.2 of the LATEX book [2], © 1986, by Addison-Wesley. The basic scheme is the same, only a few details have changed.
[These are the defacto standard for bibliographic data types.
The advise is for the use of the LATEX text processing application but there is some general hints as well. - David Wilson]
When entering a reference in the database, the first thing to decide is what type of entry it is. No fixed classification scheme can be complete, but provides enough entry types to handle almost any reference reasonably well.
References to different types of publications contain different information; a reference to a journal article might include the volume and number of the journal, which is usually not meaningful for a book. Therefore, database entries of different types have different fields. For each entry type, the fields are divided into three classes:
The field is ignored. Ignores any field that is not required or optional, so you can include any fields you want in a bib file entry. It's a good idea to put all relevant information about a reference in its bib file entry--even information that may never appear in the bibliography. For example, if you want to keep an abstract of a paper in a computer file, put it in an abstract field in the paper's bib file entry. The bib file is likely to be as good a place as any for the abstract, and it is possible to design a bibliography style for printing selected abstracts. Note: Misspelling a field name will result in its being ignored, so watch out for typos (especially for optional fields, since won't warn you when those are missing).
The following are the standard entry types, along with their required and optional fields, that are used by the standard bibliography styles. The fields within each class (required or optional) are listed in order of occurrence in the output, except that a few entry types may perturb the order slightly, depending on what fields are missing. These entry types are similar to those adapted by Brian Reid from the classification scheme of van Leunen [4] for use in the Scribe system. The meanings of the individual fields are explained in the next section. Some nonstandard bibliography styles may ignore some optional fields in creating the reference. Remember that, when used in the bib file, the entry-type name is preceded by an @ character.
A document having an author and title, but not formally published. Required fields: author, title, note. Optional fields: month, year.
In addition to the fields listed above, each entry type also has
an optional key field, used in some styles for
alphabetizing, for cross referencing, or for forming a
\bibitem
label. You should include a key
field for any entry whose ``author'' information is missing; the
``author'' information is usually the author field, but
for some entry types it can be the editor or even the
organization field (Section 4 describes this in more detail).
Do not confuse the key field with the key that appears in
the \cite
command and at the beginning of the database
entry; this field is named ``key'' only for compatibility with
Scribe.
Below is a description of all fields recognized by the standard bibliography styles. An entry can also contain other fields, which are ignored by those styles.
\cite
command and at the beginning
of the database entry.The year of publication or, for an unpublished work, the year it was written. Generally it should consist of four numerals, such as 1984, although the standard styles can handle any year whose last four nonpunctuation characters are numerals, such as `(about 1984)'.
This section gives some random tips that aren't documented elsewhere, at least not in this detail. They are, roughly, in order of least esoteric to most. First, however, a brief spiel.
I understand that there's often little choice in choosing a bibliography style--journal says you must use ‘style’ and that's that. If you have a choice, however, I strongly recommend that you choose something like the plain standard style. Such a style, van Leunen [4] argues convincingly, encourages better writing than the alternatives--more concrete, more vivid.
The Chicago Manual of Style [1], on the other hand, espouse the author-date system, in which the citation might appear in the text as `(Jones, 1986)'. I argue that this system, besides cluttering up the text with information that may or may not be relevant, encourages the passive voice and vague writing. Furthermore the strongest arguments for using the author-date system--like ``it's the most practical''--fall flat on their face with the advent of computer-typesetting technology. For instance the Chicago Manual contains, right in the middle of page 401, this anachronism: ``The chief disadvantage of [a style like plain] is that additions or deletions cannot be made after the manuscript is typed without changing numbers in both text references and list.'' LATEX, obviously, sidesteps the disadvantage.
Finally, the logical deficiencies of the author-date style are quite evident once you've written a program to implement it. For example, in a large bibliography, using the standard alphabetizing scheme, the entry for `(Aho et al., 1983b)' might be half a page later than the one for `(Aho et al., 1983a)'. Fixing this problem results in even worse ones. What a mess. (I have, unfortunately, programmed such a style, and if you're saddled with an unenlightened publisher or if you don't buy my propaganda, it's available from the Rochester style collection.)
Ok, so the spiel wasn't very brief; but it made me feel better, and now my blood pressure is back to normal. Here are the tips for using with the standard styles (although many of them hold for nonstandard styles, too).
In general, if you want to keep from changing something to lower case, you enclose it in braces. You might not get the effect you want, however, if the very first character after the left brace is a backslash. The ``special characters'' item later in this section explains.
For Scribe compatibility, the database files allow an @COMMENT command; it's not really needed because
allows in the database files any comment that's not within an entry. If you want to comment out an entry, simply remove the `@' character preceding the entry type.
\bibliography
command (but you should list this argument before the ones that
specify real database entries).It's best to use the three-letter abbreviations for the month, rather than spelling out the month yourself. This lets the bibliography style be consistent. And if you want to include information for the day of the month, the month field is usually the best place. For example
month = jul # "~4,"
will probably produce just what you want.
\nocite{*}
feature (all entries in the database are included), the placement
of the \nocite{*}
command within your document file
will determine the reference order. According to the rule given in
Section 2.1: If the command
is placed at the beginning of the document, the entries will be
listed in exactly the order they occur in the database; if it's
placed at the end, the entries that you explicitly
\cite
or \nocite
will occur in citation
order, and the remaining database entries will be in database
order.Here's yet another suggestion for what to do when an author's name appears slightly differently in two publications. Suppose, for example, two journals articles use these fields.
author = "Donald E. Knuth" . . . author = "D. E. Knuth"
There are two possibilities. You could (1) simply leave them as is, or (2) assuming you know for sure that these authors are one and the same person, you could list both in the form that the author prefers (say, `Donald E. Knuth'). In the first case, the entries might be alphabetized incorrectly, and in the second, the slightly altered name might foul up somebody's electronic library search. But there's a third possibility, which is the one I prefer. You could convert the second journal's field to
author = "D[onald] E. Knuth"
This avoids the pitfalls of the previous two solutions, since alphabetizes this as if the brackets weren't there, and since the brackets clue the reader in that a full first name was missing from the original. Of course it introduces another pitfall--`D[onald] E. Knuth' looks ugly--but in this case I think the increase in accuracy outweighs the loss in aesthetics.
When creating a label, the alpha style uses the ``author'' information described above, but with a slight change--for the MANUAL and PROCEEDINGS entry types, the key field takes precedence over the organization field. Here's a situation where this is useful.
organization = "The Association for Computing Machinery", key = "ACM"
Without the key field, the alpha style would make a label from the first three letters of information in the organization field; alpha knows to strip off the `The ', but it would still form a label like `[Ass86]', which, however intriguing, is uninformative. Including the key field, as above, would yield the better label `[ACM86]'.
You won't always need the key field to override the organization, though: With
organization = "Unilogic, Ltd.",
for instance, the alpha style would form the perfectly reasonable label `[Uni86]'.
Section 2.1 discusses accented characters. To , an accented character is really a special case of a ``special character'', which consists of everything from a left brace at the top-most level, immediately followed by a backslash, up through the matching right brace. For example in the field
author = "\AA{ke} {Jos{\'{e}} {\'{E}douard} G{\"o}del"
there are just two special characters,
`{\'{E}douard}
' and `{\"o}
' (the same
would be true if the pair of double quotes delimiting the field
were braces instead). In general,
will not do any processing of a TEX or LATEX control sequence inside a special character, but it will process other characters. Thus a style that converts all titles to lower case would convert
The {\TeX BOOK\NOOP} Experience
to
The {\TeX book\NOOP} experience
(the `The' is still capitalized because it's the first word of the title). This special-character scheme is useful for handling accented characters, for getting 's alphabetizing to do what you want, and, since counts an entire special character as just one letter, for stuffing extra characters inside labels. The file XAMPL.BIB distributed with gives examples of all three uses.
This final item of the section describes 's names (which appear in the author or editor field) in slightly more detail than what appears in Appendix B of the LATEX book. In what follows, a ``name'' corresponds to a person. (Recall that you separate multiple names in a single field with the word ``and'', surrounded by spaces, and not enclosed in braces. This item concerns itself with the structure of a single name.)
Each name consists of four parts: First, von, Last, and Jr; each part consists of a (possibly empty) list of name-tokens. The Last part will be nonempty if any part is, so if there's just one token, it's always a Last token.
Recall that Per Brinch Hansen's name should be typed
"Brinch Hansen, Per"
The First part of his name has the single token ``Per''; the Last part has two tokens, ``Brinch'' and ``Hansen''; and the von and Jr parts are empty. If you had typed
"Per Brinch Hansen"
instead, would (erroneously) think ``Brinch'' were a First-part token, just as ``Paul'' is a First-part token in ``John Paul Jones'', so this erroneous form would have two First tokens and one Last token.
Here's another example:
"Charles Louis Xavier Joseph de la Vall{\'e}e Poussin"
This name has four tokens in the First part, two in the von, and two in the Last. Here
knows where one part ends and the other begins because the tokens in the von part begin with lower-case letters.
In general, it's a von token if the first letter at brace-level 0 is in lower case. Since technically everything in a ``special character'' is at brace-level 0, you can trick
into thinking that a token is or is not a von token by prepending a dummy special character whose first letter past the TEX control sequence is in the desired case, upper or lower.
To summarize,
allows three possible forms for the name:
"First von Last" "von Last, First" "von Last, Jr, First"
You may almost always use the first form; you shouldn't if either there's a Jr part, or the Last part has multiple tokens but there's no von part.
The Chicago Manual of Style, pages 400-401.
University of Chicago Press, thirteenth edition, 1982.
Leslie Lamport.
LATEX: A Document Preparation System.
Addison-Wesley, 1986.
Oren Patashnik.
Designing styles.
The part of 's documentation that's not meant for general users,
8 February 1988.
Mary-Claire van Leunen.
A Handbook for Scholars.
Knopf, 1979.
This document was generated using the LaTeX2HTML translator Version 2002-1 (1.68)
Copyright © 1993, 1994, 1995, 1996, Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics
Department, Macquarie University, Sydney.