1

tl;dr: How to cite a Working Paper that does not / should not have an institution?


The biblatex entry type report should be used for:

A technical report, research report, or white paper published by a university or some other institution.

The required fields for a report are author,title,type,institution,year/date.

In line with this recommendation I usually use the report type for Working Papers. However, for certain Working Paper series, adding an institution seems redundant and produces unnecessarily cluttered bibliography entries. This is the case for all Working Paper series where the name of the institution is part of the series' name. For example, "NBER Working Papers" are (obviously) published by the NBER.

To illustrate the issue, consider the following example:

\documentclass{scrartcl}
\usepackage[backend=biber,bibstyle=authoryear,dashed=false]{biblatex}
\addbibresource{mwe.bib}
\begin{filecontents}{mwe.bib}
@Report{Example1,
  author      = {Author, Sample},
  date        = {2020},
  title       = {A Report},
  type        = {The Institution's Working Paper Series},
  number      = {42}
}
@Report{Example2,
  author      = {Author, Sample},
  date        = {2020},
  title       = {A Report with Redundant Institution},
  type        = {The Institution's Working Paper Series},
  number      = {42},
  institution = {The Institution}
}
\end{filecontents}
\begin{document}
\nocite{*}
\printbibliography
\end{document}

Output

  • Problem: I prefer example 1 (no institution), but the institution field is required.
  • Workarounds / What I've tried:
    1. Just ignore that institution is required and leave it empty. This works (see above), but violates the datamodel specification. But: This generates many annoying warnings when validating the datamodel and moreover, I'm not sure if future versions of biber/biblatex will remain so lenient about missing mandatory fields.
    2. Provide some placeholder institution and then clear the field along the lines of \AtEveryBibitem{\ifentrytype{report}{\clearfield{institution}… but as I don't want to clear institution for all reports, I'd need some constant "magic placeholder" (or keyword) and clear institution only conditional on observing this magic placeholder which is … messy, error prone and clutters my BIB file.
    3. Just use another entry type that does not require an institution. A natural candidate could be misc – but this does not have a number field. As an alternative, I could (ab-) use manual, but this prints the number before the type, whereas I need the opposite order:

      Author, Sample (2020c). A Report with Redundant Institution. 42. The Institution’s Working Paper Series.

    4. Just use another entry type that does not require an institution, again: Using the manual type with series={The Institution's Working Paper Series}, but I do not like using the wrong entry type (manual) and using series where type is more appropriate (IMO).
  • Question: How to cite a Working Paper that does not / should not have an institution? I'm not sure which of my approaches above is the most promising, but I'd definitely prefer a solution with a valid datamodel (unlike (1)), sensible semantics (unlike (4)) and a minimum of things that can go wrong (unlike (2)). So maybe (3) and changing the order of type and number for misc would be best … but I'm open to and grateful for any suggestions.
2
  • comment out %institution = {The Institution} field?
    – Oni
    Sep 21, 2020 at 12:49
  • 1
    @Oni Sure - or delete that line altogether. The problem is that institution is mandatory and I don't want to violate the standard.
    – CL.
    Sep 21, 2020 at 12:51

1 Answer 1

2

tl;dr Go for option 1. If the data model validation warning bothers you that much, define a new data model that does not require institution (see below).


The distinction between 'required' and 'optional' fields in biblatex is a bit less rigid than it may appear at first.

Apart from the datamodel validation code there is nothing in the biblatex code that knows about required or mandatory fields. The biblatex documentation says

Note that the ‘required’ fields are not strictly required in all cases, see §2.3.2 for details. The fields marked as ‘optional’ are optional in a technical sense. Bibliographical formatting rules usually require more than just the ‘required’ fields.

about 'required' and 'optional' fields. And §2.3.2 further explains

§2.3.2 Missing and Omissible Data

The fields marked as ‘required’ in §2.1.1 are not strictly required in all cases. The bibliography styles which come with this package can get by with as little as a title field for most entry types. A book published anonymously, a periodical without an explicit editor, or a software manual without an explicit author should pose no problem as far as the bibliography is concerned. Citation styles, however, may have different requirements. For example, an author-year citation scheme obviously requires an author/editor and a year field.

For me 'required' and 'optional' fields are more of a hint for style developers what they can expect than a hard requirement for users and their .bib databases. Generally speaking I'd say that if your entries have all the fields listed as 'required' in the documentation, you can expect the output to look reasonable. If you don't have all required fields, the output may still be OK (and in many cases it will be), but if you complain in case you aren't happy with the result, you may not have a leg to stand on. Your bibliography isn't automatically going to be bad if you don't have all required fields, but there is no implied guarantee that it should look good.

I think it is important to keep in mind the advice of btxdoc

  1. The standard style’s thirteen entry types do reasonably well at formatting most entries, but no scheme with just thirteen formats can do everything perfectly. Thus, you should feel free to be creative in how you use these entry types (but if you have to be too creative, there’s a good chance you're using the wrong entry type).
  2. Don’t take the field names too seriously. Sometimes, for instance, you might have to include the publisher’s address along with the publisher's name in the publisher field, rather than putting it in the address field. Or sometimes, difficult entries work best when you make judicious use of the note field.
  3. Don’t take the warning messages too seriously. Sometimes, for instance,the year appears in the title, as in The 1966 World Gnus Almanac. In this case it’s best to omit the year field and to ignore BibTeX’s warning message.

I don't think I fully agree with the example in the last point, but the general idea is something I definitely agree with. Anyway, the bottom line is: Don't take the data model too seriously. In the end the printed result is probably what you are most interested in.

I can't say for sure, but it certainly looks like some of the required/optional fields are directly taken from the BibTeX documentation btxdoc. So in this case institution is probably a 'required' field for historical rather than technical reasons.


What's the worst that can happen if you don't include a 'required' field? Loosely speaking I'd say the worst that can happen is that your style expects the field to be present and puts some stuff in or around the institution field that then looks out of place if the field isn't present.

Let's look at this from a more technical angle. As alluded to above, there is actually only one bit of the biblatex code that knows about which fields are required and which are optional: The data model constraint declarations. These constraint declarations are passed on to Biber for the data model verification and are not used anywhere else on the biblatex side. So from a technical point of view biblatex absolutely does not care about the data model constraints. They are just used to issue hints/warnings to users.

The much more important aspect of the whole 'required'/'optional' thing is the implicit assumptions it allows style developers to make. Generally, style developers are expected to write their styles in a way that leaving out optional fields does not make the output look bad. There is an argument to be made that there is no such expectation for required fields. If required fields are missing, that's the user's responsibility. These implicit assumptions are not codified and it is entirely up to developers how much they want to rely on these assumptions.

The overall workings of biblatex and biblatex styles make it extremely easy to guard against missing fields in most situations without any additional effort. Explicit precautions against missing fields need only be taken in a very small minority of edge cases.

I'd expect that in the vast majority of styles @report entries will still look fine even if there is no institution.


Let's discuss your suggested workarounds a bit.

  1. Just don't fill the institution field if you don't want it.

    To me this sounds like the best and simplest course of action. Sure, you're not giving a required field, but if the output looks better that way, who is going to blame you? The data model validation needs to be turned on explicitly and the warnings are of a somewhat artificial nature anyway (as mentioned above), so you should be perfectly in your right to ignore them. The biblatex standard styles are extremely unlikely to change in a way that would mean that entries without institution that look OK now should look worse in the future.

  2. Use a (magic or otherwise) placeholder.

    This would only fool the data model verification. If you later get rid of the field value with \clearfield, the field is still gone as far as the style is concerned. So if you are worried about things looking bad in the output, you're still not on the safe side.

  3. (and 4.) Use a different entry type

    This is certainly possible, but it doesn't really feel much better than the other options. You'd be giving up real semantic connection for the much more artificial aim of getting the required fields right.

It probably won't come as a surprise that I favour option 1.

If you are bothered about the warning you get from the data model verification you can rewrite the data model constraints to drop institution from the required field list (the orginal constraints can be found in blx-dm.def).

\documentclass{article}

\begin{filecontents}{report-wo-institution.bib}
\ResetDatamodelConstraints

\DeclareDatamodelConstraints[
  article,
  book,
  inbook,
  bookinbook,
  suppbook,
  booklet,
  collection,
  incollection,
  suppcollection,
  manual,
  misc,
  mvbook,
  mvcollection,
  online,
  patent,
  periodical,
  suppperiodical,
  proceedings,
  inproceedings,
  reference,
  inreference,
  report,
  set,
  thesis,
  unpublished]{
    \constraint[type=mandatory]{
      \constraintfieldsxor{
        \constraintfield{date}
        \constraintfield{year}
      }
    }
  }

\DeclareDatamodelConstraints[set]{
  \constraint[type=mandatory]{
    \constraintfield{entryset}
  }
}

\DeclareDatamodelConstraints[article]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{journaltitle}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[book,mvbook,mvcollection,mvreference]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[inbook,bookinbook,suppbook]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{booktitle}
  }
}

\DeclareDatamodelConstraints[booklet]{
  \constraint[type=mandatory]{
    \constraintfieldsor{
      \constraintfield{author}
      \constraintfield{editor}
    }
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[collection,reference]{
  \constraint[type=mandatory]{
    \constraintfield{editor}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[incollection,suppcollection,inreference]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{editor}
    \constraintfield{title}
    \constraintfield{booktitle}
  }
}

\DeclareDatamodelConstraints[dataset]{
  \constraint[type=mandatory]{
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[manual]{
  \constraint[type=mandatory]{
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[misc,software]{
  \constraint[type=mandatory]{
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[online]{
  \constraint[type=mandatory]{
    \constraintfield{title}
    \constraintfieldsor{
      \constraintfield{url}
      \constraintfield{doi}
      \constraintfield{eprint}
    }
  }
}

\DeclareDatamodelConstraints[patent]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{number}
  }
}

\DeclareDatamodelConstraints[periodical]{
  \constraint[type=mandatory]{
    \constraintfield{editor}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[proceedings,mvproceedings]{
  \constraint[type=mandatory]{
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints[inproceedings]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{booktitle}
  }
}

\DeclareDatamodelConstraints[report]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{type}
  }
}

\DeclareDatamodelConstraints[thesis]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
    \constraintfield{type}
    \constraintfield{institution}
  }
}

\DeclareDatamodelConstraints[unpublished]{
  \constraint[type=mandatory]{
    \constraintfield{author}
    \constraintfield{title}
  }
}

\DeclareDatamodelConstraints{
  \constraint[type=data, datatype=isbn]{
    \constraintfield{isbn}
  }
  \constraint[type=data, datatype=issn]{
    \constraintfield{issn}
  }
  \constraint[type=data, datatype=ismn]{
    \constraintfield{ismn}
  }
  \constraint[type=data, datatype=date]{
    \constraintfield{date}
    \constraintfield{eventdate}
    \constraintfield{origdate}
    \constraintfield{urldate}
  }
  \constraint[type=data, datatype=pattern, pattern=\regexp{(?:sf|sm|sn|pf|pm|pn|pp)}]{
    \constraintfield{gender}
  }
}
\end{filecontents}

\usepackage[backend=biber,bibstyle=authoryear,dashed=false]{biblatex}

\begin{filecontents}{\jobname.bib}
@Report{Example1,
  author      = {Author, Sample},
  date        = {2020},
  title       = {A Report},
  type        = {The Institution's Working Paper Series},
  number      = {42},
}
@Report{Example2,
  author      = {Author, Sample},
  date        = {2020},
  title       = {A Report with Redundant Institution},
  type        = {The Institution's Working Paper Series},
  number      = {42},
  institution = {The Institution},
}
\end{filecontents}
\addbibresource{\jobname.bib}

\begin{document}
\nocite{*}
\printbibliography
\end{document}

The document output is still the same, but biber -V will be silent about missing institutions.

Of course the institution field is still not given. But I guess it all comes down to if you don't want to give an institution you'll have to live with the consequences of not giving that field. In the standard styles (and I expect most contributed styles) there are basically no consequences to not giving the institution. If you think that possible future consequences are too much of a risk, your only option is to either fill the institution field with a value (that is printed) or take a different entry type. If the first option is out, then your only way is a different type. But a different type is semantically less satisfying and may not be able to properly represent all aspects of @report as accurately as possible.

3
  • Thanks a lot, moewe! I couldn't have hoped for a more elaborate answer and learned a lot. You cleared most of my worries about option 1 (and I'll probably just go for it). Just a quick follow-up question on extending the datamodel: It's not possible to change the constraints in a biber.conf, preferrably without restating all the default definitions, is it?
    – CL.
    Sep 22, 2020 at 6:26
  • @CL. Yes, I think in theory you could also use a biber.conf, but I don't think you can get around restating the entire constraint specifications since there is no natural way to remove a constraint (it is simple to add constraints, but there is no interface for removing them).
    – moewe
    Sep 22, 2020 at 14:39
  • I see, thank you! You're certainly my favorite bird of the week, Möwe!
    – CL.
    Sep 22, 2020 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.