Chadwick Baseball Bureau Persons Register

The Chadwick Register is the most comprehensive authority file for identities of people involved in baseball.

License

This dataset is made available under the Open Data Commons Attribution License: http://opendatacommons.org/licenses/by/1.0/

This public version of the Register is an extract of the full Chadwick register:

Revisions and updates are provided at a delay relative to the full version.
These files are all automatically generated.

The two points above imply that pull requests do not make sense and will be deleted without individual acknowledgment (this note is your acknowledgment!)

This public verison is updated only periodically. We offer much more detailed information and daily updates of this data for our clients.

Location

The latest version of the data can always be found at http://github.com/chadwickbureau/register

Updated versions are made available roughly once per week. The repository contains a full history of the public version of the Register from the start of 2016.

File details

People

The index of people is contained in 16 files, data/people-0.csv through data/people-f.csv. The file contains basic name components and dates of birth and death (where known), as the minimal amount of information useful to establish identities. Also provided are year spans for playing, managing, and umpiring. These are given for professional leagues overall, and Major League Baseball specifically. Separate spans are reported for intercollegiate play. Spans may be incomplete at the professional and especially collegiate levels; they are intended to be helpful in disambiguation, especially for records where first names are missing or there are multiple people with the same or similar names.

For more information on how to interpret these records and how they may change over time, see the section on technical details below.

Cross-references are provided against several identifier systems:

key_uuid: The primary key. This is guaranteed not to be re-used to label a different identity.
key_person: The first eight (hex) digits of the key_uuid. It is guaranteed that this is unique at any given time. However, over time the same short key may be re-used for a different identity.
key_retro: The person's Retrosheet identifier
key_mlbam: The person's identifier at MLBAM
key_bbref: The person's identifier on Major League pages on baseball-reference.com
key_bbref_minors: The person's identifier on minor league pages on baseball-reference.com
key_fangraphs: The person's identifier on fangraphs.com
key_npb: The person’s identifier on the NPB official site, npb.or.jp
key_sr_nfl: The person's identifier on pro-football-reference.com
key_sr_nba: The person's identifier on basketball-reference.com
key_sr_nhl: The person's identifier on hockey-reference.com
key_wikidata: The person's identifier on wikidata.org. NEW IN 2024

Names

The table data/names.csv provides a list of alternate or variant names. These may include aliases/assumed names, legal names, birth names, or anglicizations/abbreviations of names. This is a relatively new product and is at present known to be very incomplete, even for people with MLB experience.

Technical details

The Register is the product of record matching and linkage among tens of millions of mentions of people in electronic and print source data. Each entry in the Register is, internally, a cluster of records linked together by matching on one or more data fields in the source records. We refer to an entry as an identity, to distinguish it from a "person". In the perfect world, there would be a one-to-one relationship between identities and people. However, it is frequently not possible to confirm a link between two mentions of a person in different sources; this is especially true when the details in a source record are "sparse", consisting only of a person's name (or solely their surname), possibly not spelled correctly or consistently.

We index and link new records daily, and in this process we are often able to link together records previously contained in separate identities. This creates a practical problem. On the one hand, the contents of clusters change over time, and clusters coalesce (and sometimes split) based on new information. On the other hand, it is desirable for cluster identifiers to have some kind of stability properties.

In our approach, every identity cluster has a UUID. We follow these principles in assigning UUIDs to clusters between releases of the data. Let