23

I'm in the process of writing a biblatex style file to support the on-line journal Theory of Computing. The journal has been using BibTeX for years, and I am looking forward to the flexibility biblatex offers.

The difficulty: Our bibliographic entries typically need to refer to multiple dois, urls, or eprint entries. (Why? We often link to "preliminary" versions of an article, typically a conference article or an arXiv preprint.) My first question is a bit of a meta-question: what's the nicest approach?

Two approaches come to mind; I don't have enough experience with biblatex to decide which one to pursue.

Approach 1

Arrange for biblatex to "natively" handle multiple dois, urls, eprints, etc. Specifically, it would be nice to permit a record to have several fields of the form

doi = {first-doi},
doi = {second-doi},
...

and

url = {first-url},
url = {second-url},
...

The idea would be that each of these produces its own output: DOI: first-doi, DOI: second-doi, etc. Is this within easy reach?

Of course, the idea of processing multiple eprint entries seems problematic, since an eprint field is typically coupled with other "helper" fields such as eprinttype. (Incidentally, supporting two eprint fields seems like something that one might wish to do in many other natural circumstances, such as where a paper has both a MathSciNet entry and a DOI).

Approach 2

Given the problem with even parsing multiple eprint fields, another possibility would be to add a number of new fields:

  • prelim-doi
  • prelim-eprint
  • prelim-url
  • prelim-manuscript

These are to be printed right after the regular doi, eprint, and url entries (for a journal, say). Specifically, I would like output along the lines of:

Preliminary versions: DOI: ..., eprint: ..., URL: ..., Manuscript: ... .

Handling of DOI, eprint, and URL should be just like the corresponding "regular" fields (in particular, I would like prelim-eprint to inherit the same eprint handlers that exist for eprint). Manuscript should be handled just like eprint as well (again with the same handlers). (If you are wondering why we need both prelim-eprint and prelim-manuscript, this is because we often need to cite both a preliminary conference version, using eprint, and also a preliminary arXiv version.)

My first attempt (for approach 2)

To get my feet wet, I tried the following (in a .bbx file):

\DeclareFieldFormat{prelim-doi}{%
  \mkbibacro{DOI}\addcolon\space
  \ifhyperref
    {\href{http://dx.doi.org/#1}{\nolinkurl{#1}}}
    {\nolinkurl{#1}}}

\newbibmacro*{prelim-doi+eprint+manuscript+url}{%
  \iftoggle{bbx:doi}
  {\printfield{prelim-doi}}
  {}}

\renewbibmacro*{doi+eprint+url}{%
  \iftoggle{bbx:doi}
  {\printfield{doi}}
  {}%
  \newunit\newblock
  \iftoggle{bbx:eprint}
  {\usebibmacro{eprint}}
  {}%
  \newunit\newblock
  \iftoggle{bbx:url}
  {\usebibmacro{url+urldate}}
  {}%
  \iftoggle{bbx:preliminary}
  {\usebibmacro{prelim-doi+eprint+manuscript+url}}
  {}}

This uses a toggle called bbx:preliminary and was just intended to handle printing preliminary dois (to get started). However, it never seems to print anything (even for a record with a prelim-doi field). Is there something fancy I need to do to tell biblatex about the new fields? (Incidentally, this little .bbx file is essentially just loaded over Marco Daniel's trad-plain style (see How to emulate the traditional BibTeX styles (plain, abbrv, unsrt, alpha) as closely as possible with biblatex?), since our traditional bibliography style is not far from BibTeX's plain style.)

4
  • The problem is that BibLaTeX does not know the field prelim-doi, and the it ignores it. See the solution by PLK to the question tex.stackexchange.com/q/76275/16895 for how to modify the data model. You have to define a new entry type (in your case prelim-doi). Also, for approach 1 you can change the data model for the field and define them as lists, and parse them as lists.
    – Guido
    Oct 14, 2012 at 20:50
  • Thanks very much for the pointer: I'll look into modifying the data model as you suggest. As the "first approach" would be much slicker, I am interested in your proposal to parse these fields as lists. For entries such as doi and url, that seems--in principle--straightforward. Parsing eprint entries as lists, however, seems trickier because of the helper fields.
    – acr
    Oct 14, 2012 at 22:09
  • For eprint the parsing could be done by checking whether the value is a full URL (check whether it starts with http:// or ftp:// or similar, in that case you output the current value of eprint) otherwise you use eprintype to add the appropriate prefix.
    – Guido
    Oct 14, 2012 at 22:45
  • I'm a little confused: Do you mean that you can somehow embed the eprinttype information directly in the eprint string? I couldn't find a mention of this in the biblatex manual--could you explain how this convention works?
    – acr
    Oct 15, 2012 at 18:10

1 Answer 1

18

If you use biber, this might be best handled with the related entries feature supported by biblatex 2.0+.

The preamble below defines a new type of related entry: prelim. This key specifies the localization string, formatting directive and bibliography macro used to set the entries given in the related field.

\documentclass{article}
\usepackage[american]{babel}
\usepackage{csquotes}
\usepackage[backend=biber]{biblatex}
\usepackage[colorlinks]{hyperref}

\renewcommand*{\relatedpunct}{\addcolon\space}
\renewcommand*{\relateddelim}{\addcomma\space}

\newbibmacro*{related:prelim}[1]{%
  \renewcommand*{\newunitpunct}{\addcomma\space}%
  \entrydata{#1}{\usebibmacro{doi+eprint+url}}}

\NewBibliographyString{prelim,prelims}
\DefineBibliographyStrings{american}{%
  prelim = {Preliminary version},
  prelims = {Preliminary versions}}

\begin{filecontents}{\jobname.bib}
@article{v008a021,
  author = {Roy Kasher and Julia Kempe},
  title = {Two-Source Extractors Secure Against Quantum Adversaries},
  year = {2012},
  pages = {461-486},
  doi = {10.4086/toc.2012.v008a021},
  journal = {Theory of Computing},
  volume = {8},
  number = {1},
  related = {kasher/arxiv,kasher/approx},
  relatedtype = {prelim}}
@online{kasher/arxiv,
  author = {Kasher, Roy and Kempe, Julia},
  title = {Two-Source Extractors Secure Against Quantum Adversaries},
  eprinttype = {arxiv},
  eprintclass = {quant-ph},
  eprint = {1005.0512},
  month = may,
  year = {2010}}
@inproceedings{kasher/approx,
  author = {Kasher, Roy and Kempe, Julia},
  title = {Two-source extractors secure against quantum adversaries},
  booktitle = {Proceedings of the 13th international conference on Approximation,
    and the 14th International conference on Randomization, and combinatorial
    optimization: algorithms and techniques},
  series = {APPROX/RANDOM'10},
  year = {2010},
  venue = {Barcelona, Spain},
  pages = {656--669},
  url = {http://dl.acm.org/citation.cfm?id=1886521.1886572},
  publisher = {Springer-Verlag},
  location = {Berlin, Heidelberg}}
\end{filecontents}

\addbibresource{\jobname.bib}
\begin{document}
\cite{v008a021}
\printbibliography
\end{document}

enter image description here

Here biber accesses data for every entry indicated in the related field. Each related entry is assigned a hash key and is marked dataonly. This avoids extraneous entries in the bibliography. It also allows you to cite related works directly and create "circular" relationships between entries.

Since you probably won't be citing preliminary works you could get by without biber, using some additional code to access related entry data and a few more LaTeX/BibTeX runs.

\documentclass{article}
\usepackage[american]{babel}
\usepackage{csquotes}
\usepackage[backend=bibtex,defernumbers]{biblatex}
\usepackage[colorlinks]{hyperref}

\DeclareBibliographyCategory{related}

\newrobustcmd*{\getrelated}[1]{%
  \nocite{#1}\addtocategory{related}{#1}}

\AtDataInput{%
  \iffieldundef{usera}{}{\forcsvfield{\getrelated}{usera}}}

\AtEveryBibitem{%
  \iffieldundef{usera}{}{%
    \edef\bbxusera{\thefield{usera}}%
    \edef\bbxuserb{\thefield{userb}}%
    \restorefield{related}{\bbxusera}%
    \restorefield{relatedtype}{\bbxuserb}}}

\renewcommand*{\relatedpunct}{\addcolon\space}
\renewcommand*{\relateddelim}{\addcomma\space}

\newbibmacro*{related:prelim}[1]{%
  \renewcommand*{\newunitpunct}{\addcomma\space}%
  \entrydata{#1}{\usebibmacro{doi+eprint+url}}}

\NewBibliographyString{prelim,prelims}
\DefineBibliographyStrings{american}{%
  prelim = {Preliminary version},
  prelims = {Preliminary versions}}

\begin{filecontents}{\jobname.bib}
@article{v008a021,
  author = {Roy Kasher and Julia Kempe},
  title = {Two-Source Extractors Secure Against Quantum Adversaries},
  year = {2012},
  pages = {461-486},
  doi = {10.4086/toc.2012.v008a021},
  journal = {Theory of Computing},
  volume = {8},
  number = {1},
  usera = {kasher/arxiv,kasher/approx},
  userb = {prelim}}
@online{kasher/arxiv,
  author = {Kasher, Roy and Kempe, Julia},
  title = {Two-Source Extractors Secure Against Quantum Adversaries},
  eprinttype = {arxiv},
  eprintclass = {quant-ph},
  eprint = {1005.0512},
  month = may,
  year = {2010}}
@inproceedings{kasher/approx,
  author = {Kasher, Roy and Kempe, Julia},
  title = {Two-source extractors secure against quantum adversaries},
  booktitle = {Proceedings of the 13th international conference on Approximation,
    and the 14th International conference on Randomization, and combinatorial
    optimization: algorithms and techniques},
  series = {APPROX/RANDOM'10},
  year = {2010},
  venue = {Barcelona, Spain},
  pages = {656--669},
  url = {http://dl.acm.org/citation.cfm?id=1886521.1886572},
  publisher = {Springer-Verlag},
  address = {Berlin, Heidelberg}}
\end{filecontents}

\addbibresource{\jobname.bib}
\begin{document}
\cite{v008a021}
\printbibliography[notcategory=related]
\end{document}
7
  • That is extremely impressive--you implemented my favorite version of the solution with about 9 lines of code! We don't currently use biber; this seems like a good reason to migrate.
    – acr
    Oct 16, 2012 at 18:47
  • 1
    Biber accesses data for related entries and marks them "data only" unless they are cited directly. You could probably do this manually with BibTeX, but it's relatively messy and would require multiple BibTeX/LaTeX runs. I should find some time to incorporate automatic use of plural strings. I'll update this solution when I get around to it.
    – Audrey
    Oct 16, 2012 at 19:10
  • An update to handle the singular/plural case would be terrific!
    – acr
    Oct 17, 2012 at 13:25
  • I am a little confused about what features of biber are relevant here (or, equivalently, what will go wrong if I use bibtex as the back end); could you explain? Additionally, if it isn't too much trouble, I would be grateful if you could indicate the streamlined version using the built-in handling of plural strings.
    – acr
    Oct 31, 2012 at 17:18
  • 1
    @acr I've updated the solution to address use of BibTeX and plural strings.
    – Audrey
    Nov 3, 2012 at 21:15

You must log in to answer this question.

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