This dataset is a research outcome of a European Research Council, Starting Grant funded (Grant Number 679097, Industrialisation and Urban Growth from the mid-nineteenth century Ottoman Empire to Contemporary Turkey in a Comparative Perspective, 1850-2000, UrbanOccupationsOETR) project. It contains a mid-nineteenth-century urban Ottoman population micro dataset for the city of Bursa.
In recent decades, a “big microdata revolution” has revolutionized access to transcribed historical census data for social science research. Despite this, the population records of the Ottoman Empire, spanning Southeastern Europe, Western Asia, and Northern Africa, remained absent from the big microdata ecosystem due to their prolonged inaccessibility. In fact, like other modernizing states in the nineteenth century, the Ottoman Empire started to enumerate its population in population registers (nüfus defterleri) in 1830, which recorded only males of all ages for conscription and taxation purposes. These registers were completed and updated in two waves, one in 1830-1838 and the other in the 1839-1865 period. Following this experience, the Empire implemented its first modern census, which included females, in 1881/1882 for more comprehensive statistical and governance reasons to converge with European census-taking practices and account for the increasing participation of females in economic and social spheres.
The pre-census population registers were opened to researchers in 2011. There are around 11.000 registers today. The microdata of the late Ottoman censuses is still not available. Still, unfortunately, the majority of the existing literature using the population registers superficially utilized and failed to tabulate the microdata. Most works using these valuable sources contented with transcribing the microdata from Ottoman to Latin script and presenting their data in raw and unstyled fashion without publishing them in a separate repository.
Our dataset marks the inaugural release of complete population data for an Ottoman urban center, the city of Bursa, derived from the 1839 population registers. It presents originally non-tabulated register data in a tabular format integrated into a relational Microsoft Access database. To ensure that our dataset is more accessible, we are also releasing the dataset in Microsoft Excel format.
The city of Bursa, a major cosmopolitan commercial hub in modern northwestern Turkey, is selected from the larger UrbanOccupationsOETR project database as an exemplary case to represent the volume, value, variety, and veracity of the population data. Furthermore, since urban areas are usually the most densely populated locations that attract the most migration in any country, they are attractive locations for multifold reasons in historical demography. Bursa is not the only urban location in the UrbanOccupationsOETR database. As it focused on urbanization and occupational structural change, it collected the population microdata on major urban centers (chosen as primary locations) and towns (denoted as secondary locations), which pioneered the economic development of post-Ottoman nation-states. What makes the city of Bursa’s data more advantageous than other cities is that it has been cleaned and validated multiple times and used elsewhere for demographic and economic analyses.
The Ottoman population registers of 1830 and 1839 classified the population under the commonly and officially recognized ethnoreligious identities- Muslim, Orthodox Christian, Armenian, Catholic, Jewish, and (Muslim and non-Muslim) Roma. Muslim and non-Muslim populations were counted in separate registers. The registers were organized along spatial and temporal lines. The standard unit of the register was the quarter (mahalle) in urban and village (karye) in rural settings. Within these register units, populated public and non-household spaces such as inns, dervish lodges, monasteries, madrasas, coffeehouses, bakeries, mills, pastures (of nomads), and large private farms (çiftlik) were recorded separately.
The household (menzil/hane) was the unit of entry, which sometimes took different forms depending on the context, such as the room for inns and the tent for nomads. Each household recorded its members on a horizontal line. The variables of male individuals inhabiting them were self-reported biographical information (names, titles/family names, ages, and occupations), physical description (height and facial hair), relationships with other household members (kinship, tenancy, and employment ties), infirmities, and military and poll tax status, including the reasons for exemption, military post, and poll tax category (high-ala, medium-evsat, and small-edna). Households with no inhabitants were differentiated. At the same time, if a resident was known to be absent during registration due to reasons such as military service or migration, he was recorded in his household with a note stating that reason. If he was missing and appeared later, he was added to the household during updates with a note like “not recorded previously” (e.g., hin-i tahrirde taşrada olub) or “newly recorded” (tahrir-mande).
In addition to the permanent residents of a given location, migrant/temporary non-local (yabancı) residents such as laborers, inn-stayers, and unskilled bachelors (bî-kâr) were recorded along with their place of origin and for how long they had been in the migrated place. Non-Muslim migrants were registered with information regarding the last location where they got their poll tax certificate and if they would make their next poll tax payment in the migrated location.
Updates were made mainly to births, deaths, migrations, and military and poll tax status. No other variables, such as age, were renewed except for occupations in a limited number of cases. Updates are easily identifiable since they were written in siyakat, a special Ottoman chancery shorthand script, and occasionally in red ink. Births were specified with newborns’ names added next to the father’s entry. Deaths were updated by crossing out the deceased person’s record. Migrations were added with a description of the migrated place (including the military branch if the person was conscripted). Military and poll tax status was updated by crossing out the old category and adding the new one next to it. Updates were usually expressed in hijri years, sometimes in month-year, and rarely in day-month-year fashion. It is important to note that since updates were made once every few months, these dates may reflect their registration date rather than giving the exact time of the events. Equally crucial is that many events, especially births, were not reported, so their quality is limited.
Modeled after the way information was contained in the population registers, this relational database has two tables, “tblHouse” and “tblIndividual.” Each table categorizes and standardizes the register variables. To make the data easier to use, the dataset also includes a query “Query_InnerJoin” that combines all the variables from each table in a separate sheet.
Given Bursa’s important place in Ottoman history, our dataset serves as a large and crucial resource for comprehending historical societal, economic, and demographic trends within the Empire in the early stages of globalization. The dataset has 8391 household entries (HouseID) and 19,186 individual (IndivID) entries. This data includes the population registered in all of Bursa’s quarters and other location categories in 1839 and the updates until and including 1843 (Figure 2). The ethno-religious breakdown of the total population is 12462 Muslims (65%), 3315 Armenians (17%), 2466 Orthodox Christians (13%), 749 Jews (4%), and 194 Catholics (1%).
To broaden access and use of our data and bring it more in line with findability, accessibility, interoperability, and reusability (FAIR) data guidelines, the variables of “tblHouse” and “tblIndividual” are sorted into general categories and described in detail in the following tables. As the variables indicate, the dataset and population registers, in general, could serve to formulate unprecedented, hitherto impossible research questions related to major demographic dynamics, i.e., household size and composition, ethnoreligious differences, population density, occupational structure, intergenerational mobility and status transfer, mortality, fertility, migration, age-heaping/human capital, conscription, settlement patterns within and across urban locations, onomastics, toponymy, etc.
Table 1: Categories and descriptions of the variables of tblHouse
tblHouse | ||
Category | Variable | Description |
Unique key/ID | “HouseID” | Unique and consecutive ID belonging to a specific household, automatically generatead by Microsoft Access |
Geographic unit of entry | “Province” & “District” & “SubDistrict” & “Village” & “Quarter” | Geographic unit of entry from province to quarter as it appears in the register |
Register specifics | “DefterNo” | Archival code of the register whose data is being entered |
“FileNo” | JPEG number of the register page of the household being entered | |
“Menzil” | Number of the household (specified by the registers as Menzil, Persian word for house), as appears in the register | |
“Note” | When a household is annotated with a note, e.g. it is empty | |
“LocationCtg” | Specifies if the household refers to a dwelling like inn or madrasa |
Table 2: Categories and descriptions of the variables of tblIndividual
tblIndividual | ||
Category | Variable | Description |
Unique key/ID | “HouseID” | Unique ID belonging to a specific household, automatically generated by Microsoft Access, which links the individuals to households and connects the “tblHouse” and “tblIndividual” |
“IndivID” | Unique ID belonging to a specific individual, automatically generated by Microsoft Access | |
Ethno-religious identity | “ER” | Ethnoreligious identity of the individual as given in the register |
Tax information | “Cizye” (Poll tax / jizya) | Poll tax category of the individual when it was first recorded |
“DateToPayCizyeDay” & “DateToPayCizyeMonth” & “DateToPayCizyeYear” & “DateToPayCizyeCtg” | When the individual will be eligible for poll tax in hijri dates and the tax category to be paid | |
Occupation | “EmploymentStatus” | Specific references to one’s non-working status such as retirement [tekaüd, amelmande] |
“OccupationIRegistered” | Occupation as registered in the record [e.g., barber’s apprentice in someone’s shop] | |
“OccupationI” | Standardized version of the occupation [e.g.,barber] | |
“OccupationIStatus” | Status of the occupation [e.g., apprentice]. If an occupation did not have a status, then “statüsüz” (no status) was entered. | |
“OccupationIIRegistered” & “OccupationII” & “OccupationIIStatus” & “OccupationIIIRegistered” & “OccupationIII” & “OccupationIIIStatus” | Versions of the descriptors above if the individual is employed in multiple occupations | |
Individual interrelationships | “RelTo” | Short for “Related To,” and shows the individual’s relationship or lack thereof to the first recorded male within the household. If he was the “_firstRegisteredMale,” then he is recorded as such. The type of relationship to the “_firstRegisteredMale”, such as son (oğlu), grandson (hafidi/torunu), tenant (kiracı), or slave (gulamı/kölesi), or lack of it (in the case of a new individual moved to the household) are specified. |
“ILTAFM” | Short for “Is Linked to Another Family Member.” When the individual is related to someone other than the “_firstRegisteredMale,” only “Yes” or “No” is chosen here | |
“LTW” | Short for “Linked to Whom.” If the “ILTAFM” is “Yes,” “LTW” specifies the “IndivID” of the household member an individual is related to | |
“RelToFM” | Short for “Relationship to the Family Member,” and shows the relationship of the person to the “LTW” | |
Individual data | “PersonNumberRegistered” | Number assigned to an individual that is automatically generated and can be manipulated by the data entry person if needed (e.g., if the number does not match the one in the register) |
“FamilyName” | The individual’s family name, in the rare occasion before the official introduction of family names (not to be confused with title) | |
“Title1” | Title(s) appearing before an individual’s name | |
“NameI” | The individual’s name(s) | |
“Title2” | Title(s) appearing after an individual’s name | |
“Conjunction” | Arabic patronymic ibn, bin, and veled (equivalent to the “-son” suffix in English, meaning the son of “NameII”) and Turkish patronymic oğlu (the opposite, meaning the son of “NameI”, appearing rarely), that links “NameI” and “NameII” | |
“FathersTitle1″ | Title(s) appearing before the father’s name (if the conjunction is “oğlu”, then the title of the son (the individual himself) | |
“NameII” | The father’s name(s) (if the conjunction is “oğlu”, then the name of the son (the individual himself) | |
“FathersTitle2” | Title(s) appearing after the father’s name (if the conjunction is “oğlu”, then the title of the son (the individual himself) | |
“FatherOccupation” | The father’s occupational information | |
“FatherOccupationStatus” | The father’s occupational status | |
“Age” | Ages expressed in years. If the ages are given in months or days for under-one age children in the register, they are converted to years and shown in fractional form (e.g. 6/12 for a six-months-old child and 2/354 for two-days-old baby) | |
“PlaceOfBirth” | The individual’s birthplace or place of origin | |
“Note” | If the individual is annotated with a note, or a data entry person needs to highlight an issue regarding an individual’s data, they are entered to this column | |
Birth Updates | “BirthDay” & “BirthMonth” & “BirthYear” | A newborn’s birth date as expressed in hijri dates, in the available detail |
Death Updates | “DeathDay” & “DeathMonth” & “DeathYear” | The individual’s death date as expressed in hijri dates |
Migration Updates | “Transfer” | Specified by the registers as nakil (Arabic word for “transfer”) and refers to the movement destination within a location, like from one household to another |
“TransferDay” & “TransferMonth” & “TransferYear” | The individual’s “Transfer” date as expressed in hijri dates | |
“Reft” | Destination of emigration (specified by the registers as reft, Persian word for “going”) | |
“ReftDay” & “ReftMonth” & “ReftYear” | The individual’s “Reft” date as expressed in hijri dates | |
“Amed” | Where an individual came from (specified by the registers as amed – Persian word for “coming”). If an individual is exempted from military service and returned home, this information was entered here. | |
“AmedDay” & “AmedMonth” & “AmedYear” | The individual’s “Amed” date as expressed in hijri dates | |
Note: If there were multiple migration events for an individual, multiple “Transfer,” “Reft,” and Amed” data and their dates were separated by a slash (“/”). | ||
Military updates | “Askerlik” (Turkish word for military service) | The individual’s military status, including eligibility (recorded as tuvana, meaning strong, and shortened as “t” when presented along with other information), and/or reasons for exemption e.g., old age (recorded as müsin, meaning aged, and shortened as “m” when presented along with other information), infirmities (e.g, yekçeşm meaning one-eyed), and retirement (tekaüd, mütekaid) |
“AskerlikDay” & “AskerlikMonth” & “AskerlikYear” | Specifies data such as when an individual’s service started, when an eligible (“t”) male was to be conscripted, and when a male was exempted or would be exempt (“m”) as expressed in hijri dates | |
Note: If there were multiple military data for an individual, they are given together (e.g. “yekçeşm m” [one-eyed and (m)üsin/exempt]). | ||
Special day, month, and year abbreviations | “Evail” & “Evasıt” & “Evahir” & “Gurre” & “Selh” | Hijri dates are sometimes shown with special abbreviations. For days, “Evail” refers to the first ten days of a month; “Evasıt” to the middle ten days and “Evahir” to the last ten days of a month. “Gurre(-i)” is used for the first day of a hijri month and “Selh(-i)” is for the last day. |
(M) & (S) & (RA) & (CA.) & (C) & (B) & (Ş) & (N) & (L) & (ZA) & (Z) | Months can be shown in Latin letters referring to the hijri month: Muharrem: (M), Safer: (S), Rebiül-evvel: (RA), Rebiül-ahir: (R) Cemaziyel-evvel: (CA), Cemaziyel-ahir: (C), Receb: (B), Şaban: (Ş), Ramazan: (N), Şevval: (L), Zilkade: (ZA), Zilhicce: (Z). | |
Two and three-digit years | Years are sometimes expressed in two or three digits instead of four by ignoring the millennium or the century when the registers were completed. In this case, for example, year “58” should be read as 1258 and “259” as 1259 | |
Special terms | “_undeciphered” | If a variable could not be read, “_undeciphered” was entered |
“_unspecified” | If a variable was not given, such as the age of the newborn, “_unspecified” was entered | |
“2000” | If one part of a variable could not be read, then “2000” was entered in its place (e.g., “2000oğlu” [“2000son”] in place of a family name where only “oğlu” part is legible) | |
“kz” & “nh” & “ks” & “kr” & “h” & “mdrs” & “m” | In “Birthplace,” “Reft,” “Amed,” and “Transfer,” the following codes were used if they were specified in these sections in the registers: “kz” or kaza (subdistrict), “nh” for nahiye (township), “ks” for kasaba (little town/borough), “kr” for karye (village), “h” for han (inn), “mdrs” for madrasa, and “m” for mahalle (quarter). If these variables could not be read, then “_undeciphered_” was entered before these codes, and if they were not specified, then “_unspecified_” was entered before them (e.g., “_undeciphered_kz”) |
We would like to mention all researchers who contributed to the urban Bursa population dataset, Tuna Başıbek, Sinan Kaya, and Zeynep Arslan, and especially thank Dzenaida Gicic, the computer scientist, who took over from Mehmet Can Yavuz and further developed the data entry template and maintained a controlled construction of the datasets.
Lastly, if you encounter a pop-up message stating, “The active content in this file is blocked. Review your Trust Center settings or contact your IT administrator,” please be assured that this is a standard security feature in Microsoft Office applications, triggered by security settings on your local machine or the platform. Microsoft Access uses these measures to protect users from potential risks associated with macros or active content within databases. To resolve this issue promptly, kindly click “OK” on the pop-up message. This action will allow you to proceed and access the database without any interruption.
If you would like to use the dataset, please use the credentials specified below:
M. Erdem Kabadayi and Efe Erünal, “UrbanOccupationsOETR_1840s_Ottoman_Bursa_pop_micro_dataset” (Zenodo, December 29, 2023), https://doi.org/10.5281/zenodo.10441019.