The Vector Institute bibtex Repository
The files in this repository determine the list of publications that appear on the Vector Institute website. The website uses the same BiBTeX reference management system that Vector researchers use daily in their own research to produce bibliographies. By hosting these files in a git repository, we maintain a complete history of every change made to these files, including metadata that tells us who made each change. Further, changes to certain files in this repository automatically trigger the website to update itself.
Structure of the repository
There are four key files/directories at the root of the repository:
-
all.bib
: The publications on the website are, at any moment, determined by the contents of this BiBTeX database file. This file is automatically generated and should not be modified directly, as these changes will be overwritten. Indeed, in the future,all.bib
will likely not be stored in the repository at all. -
flatten.sh
: This file is a bash shell script that can be executed on any unix-based system which has bib2bib program (part of most bibtex2html packages). Those wishing to understand how the .bib files are combined should study this script. -
bibtex/
: This directory contains BiBTeX database files, organized into a hierarchy of subdirectories. BiBTeX database files use a text-based file format to produce lists of bibliography items, such as articles, books, and theses. Our scripts assume BibTeX database files end with the usual .bib suffix. -
thumbnails/
: The directory contains image files in JPG and PNG formats, organized into a hierarchy of subdirectories. The files below this directory are made visible on the web athttp://vectorinstitute.ai/thumbnails
. The BiBTeX database files may make reference to these images in order to add thumbnail images to individual publications.
all.bib
with flatten.sh
Instructions for recreating These instructions are for administrators. Individual users/groups should read the next section.
The all.bib
file is a created from the .bib files inside bibtex/
by running the flatten.sh
shell script. The flatten.sh
shell script uses the bib2bib program to combine all the .bib files in bibtex/
into one large .bib file, while also compiling away cross references and string substitutions to produce self-contained bibtex entries for each publication in the database.
It is not possible to run flatten.sh
on github at this moment. Instead, one can clone the repository to their own unix-based system, and then run flatten.sh
, provided the bib2bib program is in the PATH. The bib2bib program can be found in the bibtex2html package in most package management systems. The output of flatten.sh
is temp.all.bib
, which should be inspected for errors. If successful, one can copy temp.all.bib
over all.bib
. One would then commit and push these changes back to github.
Instructions for Vector groups and individuals
Each group should maintain its own .bib file inside the bibtex/
directory. (The exception are groups that frequently publish together, as discussed in the next section.) Groups are encouraged to create their own subdirectory to store their .bib files. Publications can be stored in a single .bib file or split across multiple .bib files. If a group (or individual) has administrator access, the groups can add, remove, and update these files in the github bibtex repository directly. Otherwise, groups can fork the bibtex repository, make changes in their own fork, and make pull requests that a bibtex administrator will process.
Publications that involve multiple groups
Publications should only be entered into one .bib file. Repeated entries, within one file or across multiple .bib files, will end up producing multiple copies of the same publication on the Vector website. We're looking for nice solutions to this, but at the moment, ask that groups that coauthor papers decide on one location for these files. One option is to create a .bib file for these coauthored publications that cross groups.
Guidelines on which publications to list
Here are few guidelines on which publications to add:
- Publications should ideally have Vector Institute listed among affiliations.
- Each bibtex entry should have a URL entry, where visitors can download the paper, potentially, but ideally not, behind a paywall. Publications should only be added if there is an associated URL. It is not appropriate to add articles before they are available. Preprints on arXiv intended for publication are fine to add.
- It is not appropriate to upload extended abstracts for unrefereed conferences.
Formatting rules for bibtex
The following guidelines are aimed to improve the quality of the publication page. Users should familiarize themselves with BiBTeX (https://en.wikipedia.org/wiki/BibTeX#Bibliographic_information_file) before attempting to add entries.
Choosing key values
Every entry begins with a key. These keys must be unique. In order to minimize clashes, please use the following formatting
[author summary][YYYY][acronym of venue][keyword or one-two word summary of title]
The [author summary]
might be
[last name of first author in lowercase]etal
[ListOfLastNamesInCamelCase]
[INITIALSOFLASTNAMESINORDER]
Cross references for major conferences
We want our bibtex to be clean and consistent. For this reason, we will use cross referencing when making citations to proceedings, such an NeurIPS, ICML, CVPR, etc. Every major conference has a @proceedings
entry in proceedings.bib. When making an @inproceedings
entry, simply add, e.g., crossref={NeurIPS2019}
, in order to import all the fields relevant to that year's proceedings. In particular, the @inproceedings
entry for individal papers should NOT specify information that is general to the conference/venue: year, booktitle, volume, etc. specified. It should specify the paper specific information: pages, title, authors, etc.
@strings
Standardized The proceedings.bib file makes use of @string
's to standardize booktitles. In addition, @string
's should be used also for the names of journals.
Links to arXiv
We encourage authors to list arXiv preprint information, even for published articles. Every article that appears also on the arXiv should specify
archivePrefix = {arXiv},
eprint = {nnnn.nnnnn},
primaryClass = {mm.LL},
where mm.LL should be replaced by the primary class, such as cs.LG or cs.AI.