Feature Request: Citing of chapters within books with crossref

[andrewdbate]

This issue:

1. Describes the current behaviour when citing a chapter within a book.
2. Provides two possible "workarounds".
3. Details what the "correct" behaviour should be.

Current Behaviour Sometimes I need to cite a particular chapter within a book. The bibtex that I obtain from the author's personal website often looks something like this (references.bib):

@incollection{ChapterNineTestKey,
  author    = {Joe Blogs},  
  title     = {The Interesting Chapter Title},
  chapter   = {9},
  pages     = {100--207},
  crossref  = {BookKey}
}
@incollection{ChapterTenTestKey,
  author    = {Joe Blogs},  
  title     = {Another Interesting Chapter Title},
  chapter   = {10},
  pages     = {208--301},
  crossref  = {BookKey}
}
@book{BookKey,
  title     = {The Best Book Title},
  editor    = {John Mann and Peter Person},
  publisher = {Some University Press},
  year      = {1997}
}

There is one @book and multiple @incollection with crossrefs to that book. (This might not be the best way to cite a chapter when using biblatex and biber, but these are the kind of bibtex entries that people distribute on their personal webpages.)

Given a tex document such as

\documentclass{article}
\usepackage[backend=biber,style=trad-alpha]{biblatex}
\addbibresource{references.bib}
\begin{document}
\cite{ChapterNineTestKey}
\printbibliography
\end{document}

the biblograph is then printed as:

Note that the title of the book is missing.

As it stands, there are two workarounds for this:

Workaround 1 Change @incollection to @inbook since we are using biblatex. This results in the following output:

Workaround 2 Keep the references.bib file unchanged as at the begining of this issue, and in the preamble, add the following lines:

\DeclareDataInheritance{book}{incollection}{%
  \inherit{title}{booktitle}
  \inherit{subtitle}{booksubtitle}
  \inherit{titleaddon}{booktitleaddon}
  \noinherit{shorttitle}
  \noinherit{sorttitle}
  \noinherit{indextitle}
  \noinherit{indexsorttitle}
}

This results in the following output:

This post from the TeX Stack Exchange says that the above \DeclareDataInheritance was added this the biblatex-chicago package to handle cases such as this one.

Note that the outputs from Workaround 1 and Workaround 2 both now correctly include the title of the book as well as the title of the chapter, but the formatting is different in both cases.

Expected Output We compare the output with bibtex alpha. Take the references.bib file at the begining of this issue, and replace the @book entry with the following:

@book{BookKey,
  title     = {The Best Book Title},
  booktitle = {The Best Book Title},
  editor    = {John Mann and Peter Person},
  publisher = {Some University Press},
  year      = {1997}
}

Note that we have to duplicate the title into booktitle. This is the correct thing to do to get fields to be inherited according to the bibtex manual. Remember that entries used in crossrefs have to appear after the crossref mention (e.g. at the end of the file).

With the input file:

\documentclass{article}
\begin{document}
\bibliographystyle{alpha}
\cite{ChapterNineTestKey}
\bibliography{references}
\end{document}

We get the following output:

We can see this corresponds to Workaround 2 given above.

Therefore, would it be possible to include "Workaround 2" as part of the style, since this was the decision taken by biblatex-chicargo.

The behaviours that I found in the above examples were somewhat unexpected (although not a 'bug' per se)... and it would be good to have some helpful defaults.

[moewew]

Mhhhh.

Workaround 1 is semantically unsound; we are indeed talking about a collection and not a monograph. So I would like to offer Workaround 3 Use @collection instead of @book. This works in this example, but might not work if you cite BookKey directly, since biblatex-trad does not support @collections at the moment.

I'm not really keen on going for workaround 2. I appreciate that the output with the original BibTeX styles is as expected even without any workarounds, but I would much rather not provide fixes for BibTeX behaviour that is not compatible or at odds with the way biblatex does things. This is already documented for field names

Since the styles are based on biblatex standard styles, the fields retain the meaning they have in biblatex even if that may be at odds with how the traditional .bst files handle those fields.

If you feel this is a major deal breaker I might have to reconsider this. I took over maintenance of this style when it became necessary to change a few bits for biblatex >= 3.3. So I'm not entirely sure about the exact design decisions that this project is based on.

I have thought for quite a while that it would be a good idea to re-implement the styles using some of the new features that have come available over the time. Trying to gingerly modernise the old code does not seem to be working awfully well. But then again on the detail level there are quite some differences between biblatex and BibTeX and decisions need to be taken on whether to go with the (often cleaner) biblatex way or go for full emulation of the BibTeX styles. Interest in the styles doesn't seem to be too high, so I never got around to it.

[andrewdbate]

I do not have enough experience to really be sure what the best solution is, but I will comment that:

1. The current default behaviour meant that I had an erroneous bibliography and I didn't realise until I scrutinised the output manually (I didn't get any warnings etc.)
2. I would very much like to keep using @book since (in my actual usage) it really is a book that is printed and that you can buy, and I might cite the entire book somewhere.

[moewew]

Mhhh.

Ad 1. With the setup from the MWE you will get erroneous bibliography entries in all biblatex standard styles and all custom styles that do not take the precautions biblatex-chicago is taking (and I have the suspicion that biblatex-chicago is the only style doing that). You can run Biber with the --validate-datamodel flag to check for entries that are missing fields. In that case a warning is issued.

Ad 2. A @collection is also an actual book you can buy. The only difference in semantic between the two is that a @book is written in its entirety by the same set of authors and is associated with its authors, while a @collection is a, well ..., collection or articles, essays, chapters, ... contributed by different authors, the entire work is associated with its editors. The only problem at the moment with @collection is that biblatex-trad probably does the wrong thing for it and that BibTeX styles in general normally don't support that type.

That brings us back to the all important question. Should biblatex-trad keep the underlying data model, entry types and field names of biblatex, or should it try to emulate the largely compatible but subtly different BibTeX data model of entry types and fields exactly at the cost of giving up principles of the biblatex data model?

At the moment my stance towards this question is as follows: biblatex-trad should emulate the traditional styles as closely as possible, but it should not do that in a way that is at odds with the general data model of biblatex. For one biblatex-trad is a collection of biblatex styles and as such I would expect it to be compatible and comparable to other biblatex styles. If biblatex-trad changes the meaning of certain entry types and fields to comply with the .bst styles it becomes "incompatible" with all other biblatex styles, so the change from style=trad-plain to style=numeric might cause fields to change meaning (essentially requiring changes in the .bib file for proper output). Secondly, I feel that people who use biblatex-trad actually want to use the biblatex data model and enjoy its new features and possibilities; if they wanted to stick with the data model of BibTeX they would probably keep using the .bst styles.

Take one example. In biblatex there are the fields maintitle+volume and series+number. maintitle+volume are for volumes of one multi-volume set of books (by the same set of authors), e.g. https://en.wikipedia.org/wiki/Computers_and_Typesetting, or multi-volume collected works, .... But series+number are for book series with many books often by different authors overseen by series editors, e.g. https://www.cambridge.org/core/series/cambridge-series-in-statistical-and-probabilistic-mathematics/8278B98D68B759B9185B2C6E6611A054.

Now the traditional BibTeX styles don't have a maintitle field, series is used for that purpose as well. They differentiate between multi-volume books and series by checking for the presence of volume and number. So the equivalent combinations to biblatex's maintitle+volume and series+number are series+volume and series+number (If both volume and number are present precedence is given to the series+volume pairing.).

You see that a .bib file that wants to refer to a volume of a multi-volume work must use the fields specific to the underlying data model, either maintitle+volume for biblatex or series+volume for BibTeX. Using the other approach will lead to undesired output. In that case again I would argue that biblatex-trad should behave like all other biblatex styles instead of emulating the biblatex-incompatible behaviour of BibTeX. For the simple reason that people using a traditional BibTeX style at the moment and who don't want to change their .bib files at all have no real incentive to switch to biblatex anyway. I see the user base of biblatex-trad (if there is any) as users who would like to use some of the new biblatex features - to which the biblatex data model is vital -, but have grown to like the bibliography styles of BibTeX or are required to present a document that almost looks like it used these styles. I appreciate that at the moment biblatex-trad mimics the BibTeX behaviour with regards to this example and is thus at odds with all other biblatex styles. But as I say, that was not my decision to make.

[andrewdbate]

Thank you for your detailed and thoughtful reply.

I do particularly agree with your comment that “biblatex-trad should emulate the traditional styles as closely as possible, but it should not do that in a way that is at odds with the general data model of biblatex”.

If nothing else, then at least this serves as an example of my typical usage of the package.