<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.2 20190208//EN" "http://jats.nlm.nih.gov/publishing/1.2/JATS-journalpublishing1.dtd"><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" article-type="data-paper" dtd-version="1.2" xml:lang="en">
    <front>
        <journal-meta>
            <journal-id journal-id-type="pmc">Gates Open Res</journal-id>
            <journal-title-group>
                <journal-title>Gates Open Research</journal-title>
            </journal-title-group>
            <issn pub-type="epub">2572-4754</issn>
            <publisher>
                <publisher-name>F1000 Research Limited</publisher-name>
                <publisher-loc>London, UK</publisher-loc>
            </publisher>
        </journal-meta>
        <article-meta>
            <article-id pub-id-type="doi">10.12688/gatesopenres.15418.2</article-id>
            <article-categories>
                <subj-group subj-group-type="heading">
                    <subject>Data Note</subject>
                </subj-group>
                <subj-group>
                    <subject>Articles</subject>
                </subj-group>
            </article-categories>
            <title-group>
                <article-title>Simulated data for census-scale entity resolution research without privacy restrictions: a large-scale dataset generated by individual-based modeling</article-title>
                <fn-group content-type="pub-status">
                    <fn>
                        <p>[version 2; peer review: 1 approved, 2 approved with reservations]</p>
                    </fn>
                </fn-group>
            </title-group>
            <contrib-group>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Haddock</surname>
                        <given-names>Beatrix</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Conceptualization</role>
                    <role content-type="http://credit.niso.org/">Investigation</role>
                    <role content-type="http://credit.niso.org/">Methodology</role>
                    <role content-type="http://credit.niso.org/">Software</role>
                    <role content-type="http://credit.niso.org/">Validation</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Pletcher</surname>
                        <given-names>Alix</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Investigation</role>
                    <role content-type="http://credit.niso.org/">Methodology</role>
                    <role content-type="http://credit.niso.org/">Validation</role>
                    <role content-type="http://credit.niso.org/">Visualization</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Original Draft Preparation</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <uri content-type="orcid">https://orcid.org/0009-0009-1585-4766</uri>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Blair-Stahn</surname>
                        <given-names>Nathaniel</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Investigation</role>
                    <role content-type="http://credit.niso.org/">Methodology</role>
                    <role content-type="http://credit.niso.org/">Validation</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Keyes</surname>
                        <given-names>Os</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Methodology</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Kappel</surname>
                        <given-names>Matt</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Software</role>
                    <uri content-type="orcid">https://orcid.org/0000-0003-2430-5661</uri>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Bachmeier</surname>
                        <given-names>Steve</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Supervision</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Lutze</surname>
                        <given-names>Syl</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Investigation</role>
                    <role content-type="http://credit.niso.org/">Methodology</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <uri content-type="orcid">https://orcid.org/0009-0005-7858-0222</uri>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Albright</surname>
                        <given-names>James</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Software</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Bowman</surname>
                        <given-names>Alison</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Investigation</role>
                    <role content-type="http://credit.niso.org/">Methodology</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Kinuthia</surname>
                        <given-names>Caroline</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Project Administration</role>
                    <role content-type="http://credit.niso.org/">Supervision</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Burke-Conte</surname>
                        <given-names>Zeb</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Investigation</role>
                    <role content-type="http://credit.niso.org/">Methodology</role>
                    <role content-type="http://credit.niso.org/">Software</role>
                    <role content-type="http://credit.niso.org/">Validation</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="no">
                    <name>
                        <surname>Mudambi</surname>
                        <given-names>Rajan</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Software</role>
                    <role content-type="http://credit.niso.org/">Supervision</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <contrib contrib-type="author" corresp="yes">
                    <name>
                        <surname>Flaxman</surname>
                        <given-names>Abraham</given-names>
                    </name>
                    <role content-type="http://credit.niso.org/">Conceptualization</role>
                    <role content-type="http://credit.niso.org/">Funding Acquisition</role>
                    <role content-type="http://credit.niso.org/">Investigation</role>
                    <role content-type="http://credit.niso.org/">Methodology</role>
                    <role content-type="http://credit.niso.org/">Supervision</role>
                    <role content-type="http://credit.niso.org/">Writing &#x2013; Review &amp; Editing</role>
                    <uri content-type="orcid">https://orcid.org/0000-0001-6033-4713</uri>
                    <xref ref-type="corresp" rid="c1">a</xref>
                    <xref ref-type="aff" rid="a1">1</xref>
                </contrib>
                <aff id="a1">
                    <label>1</label>Institute for Health Metrics and Evaluation, University of Washington, Seattle, Washington, 98195, USA</aff>
            </contrib-group>
            <author-notes>
                <corresp id="c1">
                    <label>a</label>
                    <email xlink:href="mailto:abie@uw.edu">abie@uw.edu</email>
                </corresp>
                <fn fn-type="conflict">
                    <p>No competing interests were disclosed.</p>
                </fn>
            </author-notes>
            <pub-date pub-type="epub">
                <day>18</day>
                <month>10</month>
                <year>2024</year>
            </pub-date>
            <pub-date pub-type="collection">
                <year>2024</year>
            </pub-date>
            <volume>8</volume>
            <elocation-id>36</elocation-id>
            <history>
                <date date-type="accepted">
                    <day>9</day>
                    <month>10</month>
                    <year>2024</year>
                </date>
            </history>
            <permissions>
                <copyright-statement>Copyright: &#x00a9; 2024 Haddock B et al.</copyright-statement>
                <copyright-year>2024</copyright-year>
                <license xlink:href="https://creativecommons.org/licenses/by/4.0/">
                    <license-p>This is an open access article distributed under the terms of the Creative Commons Attribution Licence, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
                </license>
            </permissions>
            <self-uri content-type="pdf" xlink:href="https://gatesopenresearch.org/articles/8-36/pdf"/>
            <abstract>
                <sec>
                    <title>Background</title>
                    <p>Entity resolution (ER) is the process of identifying and linking records that refer to the same real-world entity. ER is a fundamental challenge in data science, and a common barrier to ER research and development is that the data fields used for this fuzzy matching are personally identifiable information, such as name, address, and date of birth. The necessary restrictions on accessing and sharing these authentic data have slowed the work in developing, testing, and adopting new methods and software for ER. We recently released 
                        <italic toggle="yes">pseudopeople</italic>, a Python package that allows users to generate simulated datasets with configurable noise approaching the scale and complexity of the data on which large organizations and federal agencies, like the US Census Bureau regularly perform ER. With pseudopeople, researchers can develop new algorithms and software for ER of US population data without needing access to personal and confidential information.</p>
                </sec>
                <sec>
                    <title>Methods</title>
                    <p>We created the simulated population data available for noising with pseudopeople using our Vivarium simulation platform. Our model simulates individuals and their families, households, and employment dynamics over time, which we observe through simulated censuses, surveys, and administrative data collection systems.</p>
                </sec>
                <sec>
                    <title>Results</title>
                    <p>Our simulation process produced over 900 gigabytes of simulated censuses, surveys, and administrative data for pseudopeople, representing hundreds of millions of simulants. A sample simulated population of thousands of simulants is now openly available to all users of the pseudopeople package, and large-scale simulated populations of millions and hundreds of millions of simulants are also available by online request through GitHub. These simulated population data are structured for use by the pseudopeople package, which includes additional affordances to add various kinds of noise to the data to provide realistic, sharable challenges for ER researchers.</p>
                </sec>
            </abstract>
            <kwd-group kwd-group-type="author">
                <kwd>Entity resolution (ER)</kwd>
                <kwd>microsimulation</kwd>
            </kwd-group>
            <funding-group>
                <award-group id="fund-1" xlink:href="http://dx.doi.org/10.13039/100000865">
                    <funding-source>Gates Foundation</funding-source>
                    <award-id>INV-060835</award-id>
                </award-group>
                <award-group id="fund-2" xlink:href="http://dx.doi.org/10.13039/100006958">
                    <funding-source>U.S. Census Bureau</funding-source>
                    <award-id>CooperativeAgreementCB21RMD0160001</award-id>
                </award-group>
                <funding-statement>This work was supported by the Gates Foundation [INV-060835] and Cooperative Agreement CB21RMD0160001 with the US Census Bureau. The findings, interpretations, and conclusions expressed in this work are those of the authors and do not necessarily reflect the views of the US Census Bureau.</funding-statement>
                <funding-statement>
                    <italic>The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.</italic>
                </funding-statement>
            </funding-group>
        </article-meta>
        <notes>
            <sec sec-type="version-changes">
                <label>Revised</label>
                <title>Amendments from Version 1</title>
                <p>The text of this manuscript has been revised to make it clearer that the simulated data described in this note is 
                    <italic>input</italic>&#x00a0;to the pseudopeople Python package, and the pseudopeople package adds configurable data corruption algorithms such as noise introduced by typographic errors. &#x00a0;We also edited to provide additional context around our simulated data approach, comparing it to perturbed-data approaches and work conducted in secure data enclaves, as well as adding a reference to another application of simulated data to record linkage that came out recently.&#x00a0; In response to reviewer comments, we have also included additional limitations related to data we use to generate names and household structures for our simulants.</p>
            </sec>
        </notes>
    </front>
    <body>
        <sec sec-type="intro">
            <title>Introduction</title>
            <p>Entity resolution (ER) is a foundational element of data science and has emerged as a crucial research task in a variety of disciplines, from the social sciences to epidemiology to forensics
                <sup>
                    <xref ref-type="bibr" rid="ref-1">1</xref>
                </sup>. Put simply, ER is the process of linking the records corresponding to a single &#x201c;entity&#x201d; (e.g., an individual person) from one or multiple data sources when there is not a unique key on which to join them. In this context, an entity may be anything a row of data corresponds to, for example a person, household, business, or establishment. Record linkage of administrative data can enable the analysis of events across government services and systems
                <sup>
                    <xref ref-type="bibr" rid="ref-2">2</xref>&#x2013;
                    <xref ref-type="bibr" rid="ref-4">4</xref>
                </sup>.</p>
            <p>For researchers who work with large-scale, individual-level data, such as those working with the US Census Bureau, ER typically uses personally identifiable information (PII) such as name, address, date of birth, or government-issued identification numbers. Protecting PII is crucial to safeguarding individuals&#x2019; privacy, security, and personal well-being in an increasingly interconnected and data-driven world. As such, restrictions on access to these data have presented a barrier to developing and testing new methods and software for ER
                <sup>
                    <xref ref-type="bibr" rid="ref-1">1</xref>
                </sup>. Although it is possible for some research to proceed using perturbed or synthetic data or for researchers to work with confidential data in a secure data enclave, it seems that technical barriers inherent in these approaches have prevented them from overcoming these barriers at present.</p>
            <p>In 2021, the US Census Bureau (USCB) awarded a cooperative agreement to the University of Washington&#x2019;s Institute for Health Metrics and Evaluation (IHME) Simulation Science team to expand and improve ER methodological research and technology
                <sup>
                    <xref ref-type="bibr" rid="ref-5">5</xref>
                </sup>. As part of this work, we have used simulation to address the research barrier caused by PII. Through the development of a simulated version of various administrative datasets, including a simulation of the confidential data gathered by the USCB, we hope to help researchers develop new techniques for linking datasets together that are compatible with the privacy protections necessary for such sensitive and consequential information &#x2013; and to do so without needing access to the real data. The goal of the generation of these data is to use them for ER methods research, and the datasets themselves are not intended to replicate or reconstruct protected data for social scientific research. It should be noted that our team is not the first to attempt such a data synthesis project. Prior approaches include the Australian National University&#x2019;s &#x201c;Freely extensible biomedical record linkage&#x201d;
                <sup>
                    <xref ref-type="bibr" rid="ref-6">6</xref>
                </sup> and Data Generator and Corruptor projects
                <sup>
                    <xref ref-type="bibr" rid="ref-7">7</xref>
                </sup>; and from the University of Arkansas Little Rock, the synthetic occupancy generator approach
                <sup>
                    <xref ref-type="bibr" rid="ref-8">8</xref>
                </sup>. There is also relevant work from the University of Edinburgh, which developed an R package for producing synthetic data called synthpop
                <sup>
                    <xref ref-type="bibr" rid="ref-9">9</xref>
                </sup>; and from the United Kingdom Ministry of Justice, which developed synthetic data for testing the Python package Splink
                <sup>
                    <xref ref-type="bibr" rid="ref-10">10</xref>
                </sup>. Recently another group has use simulation specifically to generate data for record linkage, which might be considered the first paper to use microsimulation for generating data for record linkage
                <sup>
                    <xref ref-type="bibr" rid="ref-11">11</xref>
                </sup>. There are certain features of our project, however, that differentiate it from other efforts, most notably the scale of our simulated data: We have simulated a 100% sample of the USA over 20 years.</p>
            <p>We have recently released pseudopeople, a Python software package that allows users to generate realistic simulated data about a fictional United States population over multiple decades. Both the generation and distribution of the dataset are governed by a system of &#x201c;relational governance&#x201d;
                <sup>
                    <xref ref-type="bibr" rid="ref-12">12</xref>
                </sup>, in which data subjects play a central role; a paper on our governance approach is currently under preparation
                <sup>
                    <xref ref-type="bibr" rid="ref-12">12</xref>
                </sup>. The package produces simulated datasets similar to census, survey, and administrative datasets routinely used by USCB in their data linkage practice, and it allows the user to configure the levels of noise in each dataset. This includes noise that leaves fields blank, chooses wrong options, replaces names with nicknames and fake names, swaps months and days in dates, misreports ages, and writes wrong digits in numbers and zip codes, as well as adding phonetic, optical character recognition, and typographical errors, following the approach pioneered by Christen and colleagues
                <sup>
                    <xref ref-type="bibr" rid="ref-6">6</xref>,
                    <xref ref-type="bibr" rid="ref-7">7</xref>,
                    <xref ref-type="bibr" rid="ref-13">13</xref>
                </sup>. Readers interested in more details on how our pseudopeople software adds noise to the data generated by this simulation are referred to the pseudopeople documentation website, 
                <ext-link ext-link-type="uri" xlink:href="https://pseudopeople.readthedocs.io/">pseudopeople.readthedocs.io</ext-link>, which includes implementations and extensions of many of the data corruption approaches listed in the previous paragraph.</p>
            <p>The simulated datasets generated by pseudopeople are based on the results of an individual-based microsimulation built with our Vivarium simulation framework. This simulation is calibrated with real, publicly accessible data about the United States population, including realistic household and family structures, at a large scale. The purpose of this data note is to describe this simulation, which we hope will aid researchers in using our pseudopeople package to develop new algorithms and software. </p>
        </sec>
        <sec sec-type="methods">
            <title>Methods</title>
            <sec>
                <title>Using Vivarium</title>
                <p>Vivarium is a mature, open-source simulation framework
                    <sup>
                        <xref ref-type="bibr" rid="ref-14">14</xref>
                    </sup> that uses standard scientific Python tools, such as NumPy and pandas
                    <sup>
                        <xref ref-type="bibr" rid="ref-15">15</xref>,
                        <xref ref-type="bibr" rid="ref-16">16</xref>
                    </sup>. A simulation in Vivarium consists of user-written components that encapsulate the simulation logic, a machine-readable model specification that describes what components are in the model and how they are configured, and a data file containing all data used in the simulation. The framework provides a set of services to assist users in writing their model components, an engine for executing the simulations from both an interactive Python session and from the command line, and abstractions to help manage and format model input data. Models built in Vivarium are typically individual-based, representing people in a population as agents or &#x201c;simulants,&#x201d; each with their own age, sex, and other characteristics relevant to the specific model. They typically use discrete &#x201c;time steps&#x201d; at which events may occur. In this work, each Vivarium simulant represented a person living in the United States, and each discrete time step included changes relevant to data used in record linkage, such as births, deaths, moving to another address, and changing jobs.</p>
                <p>We use a pre-established workflow when developing a Vivarium simulation, with roles for researchers and software engineers. The researchers lead the model development process through background research, conceptualizing modeling strategies, validating strategies with domain experts, guiding the conceptual development of the modeling software, and generating analytics for simulation inputs and outputs. The software engineers lead the development of simulation code, including model components and outputs, and tools supporting model and input data analytics.</p>
                <p>In the following sections, we will cover the different input data sources and data processing strategies used to inform our simulation of the US population. We describe the Vivarium model components for simulant characteristics including basic demographics, household structure, mortality, fertility, migration, and employment dynamics. We also describe the addition of simulant names, physical addresses, employer names, and other attributes which we implemented as a post-processing step, rather than during the simulation itself. </p>
            </sec>
            <sec>
                <title>Simulation time</title>
                <p>We initialized our simulation to begin on January 1, 2019, and step forward in time with 28-day time steps until the simulation clock exceeded May 1, 2041. We chose this time step duration to balance the complexity of changes in demographics, housing, employment, etc. with the computational demand of running a simulation with over 300 million simulants.</p>
            </sec>
            <sec>
                <title>Concept model</title>
                <p>The concept model diagrams (
                    <xref ref-type="fig" rid="f1">Figure 1</xref> and 
                    <xref ref-type="fig" rid="f2">Figure 2</xref>) provide a visualization of the logical dynamics underlying this simulation and indicate how the various components of the simulation relate. The simulation components can be divided into three overarching categories:</p>
                <list list-type="bullet">
                    <list-item>
                        <label>i) </label>
                        <p>simulation events (i.e., birth, death, migration, and employment change),</p>
                    </list-item>
                    <list-item>
                        <label>ii) </label>
                        <p>simulant attributes (i.e., demographics, household structure, location, and government-issued identification numbers such as SSNs), and</p>
                    </list-item>
                    <list-item>
                        <label>iii) </label>
                        <p>simulated dataset observers (i.e., how the simulants are observed over the course of the simulation, through routinely collected surveys and administrative datasets, such as the Decennial Census, tax forms, household surveys, and government-related social safety programs).</p>
                    </list-item>
                </list>
                <fig fig-type="figure" id="f1" orientation="portrait" position="float">
                    <label>Figure 1. </label>
                    <caption>
                        <title>Simplified version of simulation concept model diagram, denoting the four different overarching simulation events that can occur (migration, employment, mortality, and fertility) and how each of these events are observed during the simulation run.</title>
                    </caption>
                    <graphic orientation="portrait" position="float" xlink:href="https://gatesopenresearch-files.f1000.com/manuscripts/17690/41b73c2f-876d-4298-bca0-36d995630540_figure1.gif"/>
                </fig>
                <fig fig-type="figure" id="f2" orientation="portrait" position="float">
                    <label>Figure 2. </label>
                    <caption>
                        <title>Concept model diagram showing the interaction between different components of the simulation, illustrated at the level of an individual simulant.</title>
                        <p>Each arrow in this diagram represents a dependence between two distinct components of the simulation; an arrow from component X to component Y indicates that X affects Y (for example, the employment component simulates changes in jobs, which leads to a change in income; the basic demographics of a simulant affect the probability of death so that older simulants are realistically more likely to die during a simulation time step).</p>
                    </caption>
                    <graphic orientation="portrait" position="float" xlink:href="https://gatesopenresearch-files.f1000.com/manuscripts/17690/41b73c2f-876d-4298-bca0-36d995630540_figure2.gif"/>
                </fig>
                <p>
                    <xref ref-type="fig" rid="f1">Figure 1</xref> shows what influences the occurrence of each simulation event and how these events are captured in our data collection, while 
                    <xref ref-type="fig" rid="f2">Figure 2</xref> shows how the simulant components interact with one another at the individual level. When a simulant undergoes an event (e.g., gives birth, changes jobs, changes address), the simulant&#x2019;s attributes change accordingly. Those attributes are then captured by the observers.</p>
                <p>
                    <bold>
                        <italic toggle="yes">Input data.</italic>
                    </bold> We informed the simulated datasets we developed for pseudopeople using open-source input data, including data released publicly by the Social Security Administration (SSA) and the USCB. We informed physical addresses from the training data of the Python package libpostal, as repackaged by the deepparse project
                    <sup>
                        <xref ref-type="bibr" rid="ref-17">17</xref>
                    </sup>. In the sections that follow, we elaborate on how we used these data sources, and how our simulation could be extended to be even more realistic in future work.</p>
                <p>
                    <bold>
                        <italic toggle="yes">Basic demographics.</italic>
                    </bold> We initialized the simulated population&#x2019;s demographic characteristics, including age and date of birth, race/ethnicity, sex, nativity (i.e., whether a simulant was born within the US), geographic area, and household structure by sampling from the 2016&#x2013;2020 ACS Public Use Microdata Sample (PUMS)
                    <sup>
                        <xref ref-type="bibr" rid="ref-18">18</xref>
                    </sup>. By sampling from PUMS, we were able to match the univariate distribution of each attribute as well as joint distributions of arbitrary complexity between the attributes at the Public Use Microdata Area level, while also preserving structure within sampled household units. For instance, the PUMS data capture the age distribution of people in America, where more people were born from 1945 to 1965 than from 1965 to 1985. The PUMS data are not without limitations, however. For example, the granularity of the PUMS data is limited by privacy considerations, and specific details that might be crucial for a detailed analysis are sometimes obscured, which could affect the precision of simulations based on these data, especially in socioeconomic and health-related contexts.</p>
                <p>Age is reported in PUMS in floored integer years, but our simulation uses precise ages in fractional years. We assigned simulants a uniformly random precise age consistent with their nominal age as sampled from PUMS. For ER research and development, it was particularly important that we did not generate simulants who are much more similar to one another than would be expected in a real population, which would make linkage unrealistically difficult. Our simulated population is the size of the US population, but every simulant is initialized from a person in PUMS, which is a 5% sample of the US. Therefore, many simulants are created from the same person in PUMS, which could create unrealistic clustering. To decrease similarity without assuming total independence between attributes, we perturbed age values at sampling time. In different components of the simulation, we sampled different entity types from the PUMS: entire households, individuals living in group quarters (GQs), or individuals living in households (non-GQs). For each entity sampled, we added a random age shift taken from a standard normal distribution to that entity&#x2019;s age value(s). When perturbation led to a negative age value, we flipped the negative age value&#x2019;s sign. We then defined each simulant&#x2019;s date of birth to be consistent with their precise age.</p>
                <p>Sex is reported in PUMS as binary (male or female), so we initialized a sex attribute this way as well for each simulant. We mapped separate PUMS indicators of race and ethnicity to a single composite &#x201c;race/ethnicity&#x201d; indicator, with the following exhaustive and mutually exclusive categories: &#x201c;White,&#x201d; &#x201c;Black,&#x201d; &#x201c;Latino,&#x201d; &#x201c;American Indian and Alaskan Native,&#x201d; &#x201c;Asian,&#x201d; &#x201c;Native Hawaiian and Other Pacific Islander,&#x201d; and &#x201c;Multiracial or Some Other Race.&#x201d; We defined these categories in accordance with the guidelines provided by the US Office of Management and Budget (OMB)
                    <sup>
                        <xref ref-type="bibr" rid="ref-19">19</xref>
                    </sup>. Nativity describes whether a simulant was born in the United States or elsewhere, and we modeled this as a binary variable in our simulation. We used this nativity attribute to inform the likelihood that the simulant had a Social Security Number (SSN). 
                    <xref ref-type="table" rid="T1">Table 1</xref> provides a sample of the basic demographics present in the simulated population used in pseudopeople (note that these are entirely simulated data and therefore do 
                    <italic toggle="yes">not</italic> constitute Confidential Unclassified Information under US Code).</p>
                <table-wrap id="T1" orientation="portrait" position="anchor">
                    <label>Table 1. </label>
                    <caption>
                        <title>Sample of basic demographics from simulated population.</title>
                        <p>These are entirely simulated data and therefore do 
                            <italic toggle="yes">not</italic> constitute Confidential Unclassified Information under US Code.</p>
                    </caption>
                    <table content-type="article-table" frame="hsides">
                        <thead>
                            <tr>
                                <th align="left" colspan="1" rowspan="1" valign="top">Simulant ID</th>
                                <th align="left" colspan="1" rowspan="1" valign="top">First name</th>
                                <th align="left" colspan="1" rowspan="1" valign="top">Middle initial</th>
                                <th align="left" colspan="1" rowspan="1" valign="top">Last name</th>
                                <th align="left" colspan="1" rowspan="1" valign="top">Age</th>
                                <th align="left" colspan="1" rowspan="1" valign="top">Date of birth</th>
                                <th align="left" colspan="1" rowspan="1" valign="top">Sex</th>
                                <th align="left" colspan="1" rowspan="1" valign="top">Race/ethnicity</th>
                            </tr>
                        </thead>
                        <tbody>
                            <tr>
                                <td align="left" colspan="1" rowspan="1" valign="top">2</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Melanie</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">L</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Herrod</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">26</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">8/5/1993</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">F</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">White</td>
                            </tr>
                            <tr>
                                <td align="left" colspan="1" rowspan="1" valign="top">3</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Jordan</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">C</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Herrod</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">26</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">12/20/1993</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">M</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">White</td>
                            </tr>
                            <tr>
                                <td align="left" colspan="1" rowspan="1" valign="top">923</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">John</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">E</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Mckeever</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">77</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">6/29/1942</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">M</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Black</td>
                            </tr>
                            <tr>
                                <td align="left" colspan="1" rowspan="1" valign="top">6176</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Gail</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">K</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Durand</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">67</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">1/3/1953</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">F</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Multiracial or Other</td>
                            </tr>
                            <tr>
                                <td align="left" colspan="1" rowspan="1" valign="top">18770</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Ann</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">J</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Molina</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">60</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">10/24/1959</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">F</td>
                                <td align="left" colspan="1" rowspan="1" valign="top">Latino</td>
                            </tr>
                        </tbody>
                    </table>
                </table-wrap>
                <p>
                    <bold>
                        <italic toggle="yes">Household structure.</italic>
                    </bold> Our simulants lived in either residential households or group quarters (GQ). We used the ACS PUMS data to inform the residential household structure regarding how each simulant is related to a reference person in their household. Simulants living in GQ do not have such a relationship and GQs do not have a reference person. Residential households and GQs have geographic locations as well as physical and mailing street addresses, which may be different, because some residential households receive mail at a PO box (we do not simulate other kinds of mailing-only addresses, such as rural route addresses).</p>
                <p>PUMS data were not sufficient to identify precisely which type of GQ each simulant resided in; they only provided information on whether it was an institutional or non-institutional GQ. We subdivided institutional GQ into three mutually exclusive and collectively exhaustive categories of carceral, nursing homes, and other institutional. We also subdivided non-institutional GQ into college, military, and other non-institutional. We chose a GQ type uniformly at random for each simulant out of the three types consistent with their institutional/non-institutional status.</p>
                <p>For simulants living in residential households, we modeled a relationship to the reference person of their household based on the relationship values in the PUMS
                    <sup>
                        <xref ref-type="bibr" rid="ref-20">20</xref>
                    </sup>. Possible relationship values were reference person, biological child, adopted child, stepchild, sibling, parent, grandchild, parent-in-law, child-in-law, other relative, roommate, foster child, other non-relative.</p>
                <p>
                    <bold>
                        <italic toggle="yes">Mortality.</italic>
                    </bold> To model mortality, we used our standard Vivarium approach, informed by data from the age- and sex-specific estimate of all-cause mortality for the US in 2019 as produced by the IHME Global Burden of Disease Study
                    <sup>
                        <xref ref-type="bibr" rid="ref-21">21</xref>
                    </sup>. When a simulant who was the reference person in a non-GQ household died, we made the oldest remaining simulant in that household the new reference person and updated all other relationships (this produces some households with an unrealistically young simulant as the reference person). Unlike many of our past Vivarium simulations, we did not model the underlying cause for any simulant&#x2019;s death. However, we could extend this simulation to model specific causes of death in future iterations of the simulation, such as to facilitate research and development in cancer registry linkage applications.</p>
                <p>
                    <bold>
                        <italic toggle="yes">Fertility.</italic>
                    </bold> We used our standard Vivarium approach to an age-specific fertility model in which each female simulant has a probability of having a birth event at each time step, derived from the age-specific fertility rate for the USA. In the current version of our model, only one female parent is identified, representing the simulant who gave birth. The birth event is considered to occur at a randomly chosen time during the 28-day time step, which informs the date of birth and age of the simulants born. We select a random 4% of birth events to be the birth of twins (two newborn simulants), and for the other birth events we add a single newborn simulant. We expect that the inclusion of twins will create some particularly challenging ER data, where simulants have the same last name, address, and date of birth. We do not include adoption or any other complexities of family structure.</p>
                <p>The newborn simulant inherits certain attributes from their mother simulant, including household, race/ethnicity, and last name (recall that the simulation associates a newborn with only a single parent, so these attributes are inherited from this individual unambiguously). These simplifying assumptions allowed us to avoid modeling the complex dynamics of relationships but precluded us from following the dominant patriarchal naming pattern present in the US. The nativity of children born in the simulation is set to reflect that they were born in the US; therefore, all children born in the simulation are assigned an SSN. Additionally, we assigned newborns a relationship to the reference person in their household (which is also their parent&#x2019;s household) based on the relationship between their parent and the household reference person, using a set of logical business rules.</p>
                <p>
                    <bold>
                        <italic toggle="yes">Migration.</italic>
                    </bold> We attempted to include accurate patterns of migration in our simulation, as migration leads to changing addresses, which constitutes an important challenge in ER. As with basic demographics, all data informing migration in our simulation come from ACS PUMS. We used PUMS to calculate migration by demographics. There are a huge number of attributes that could explain moving behavior, and they may interact in complex ways in the real world. We modeled only some of this complexity and captured three types of household and individual migration events: migration within the simulation (domestic migration), migration into the simulation (in-migration), and migration out of the simulation (out-migration).</p>
                <p>
                    <bold>Domestic migration</bold>
                </p>
                <p>We modeled domestic migration events as happening at a rate determined by age, sex, and race/ethnicity; we held these rates constant across time in the simulation. Individual domestic migration caused a single simulant to move and might reflect an individual moving out of their current living situation (i.e., GQ or residential household) and establishing a new one-person household, moving into GQ, or joining an existing residential household as a non-reference person. For individual migrations in which a simulant establishes a new household, we always classified the simulant as the reference person. For individual migrations in which a simulant joins an existing household, the simulant is always classified as an &#x201c;Other nonrelative.&#x201d; We assumed that simulants have at most a single individual migration event per time step.</p>
                <p>When a simulant who was the reference person in a non-GQ household moved, we assigned the oldest remaining simulant in their household to be the reference person and updated all other relationships in the household according to logical business rules.</p>
                <p>Household domestic migration caused an entire household of more than one simulant to move as a unit. As with individual migration, we calculated the rate of household migration per household-year and stratified by demographics. Because households do not have overall demographic characteristics, we used the demographics of the reference person for this stratification. Unlike individual migration, we did not change any relationships in household migrations.</p>
                <p>We used a simplifying assumption that all simulants who moved and were of working age (which we define as age 18 and older) changed employment.</p>
                <p>
                    <bold>International immigration</bold>
                </p>
                <p>We modeled immigration by adding new simulants to our simulation to represent individuals moving into the US from other countries. We sampled simulants immigrating to the US from the subset of the 2016&#x2013;2020 ACS PUMS who had immigrated to the US in the year before they were surveyed and did not perturb their age. This approach relies on our assumption that the number-per-year and demographic characteristics of recent immigrants in the 2016&#x2013;2020 ACS PUMS will not change substantially for all future years of the simulation.</p>
                <p>We modeled three kinds of immigration events in our simulation: household moves, GQ person moves, and non-reference-person moves. As with domestic migration, a household move is when an entire non-GQ household enters from outside the country as a unit, preserving relationships within the unit. A GQ person move is when a simulant enters from outside the country and joins group quarters. Because simulants who reside in GQs do not have tracked relationships in PUMS or our simulation, these moves have no relationship structure. Lastly, a non-reference-person move is when an individual simulant enters from outside the country and joins an existing non-GQ household with some relationship other than &#x201c;reference person.&#x201d;</p>
                <p>We used the weighted number of last-year immigration events of each type from the ACS PUMS to inform the yearly rate at which immigration events of each move type occurred in our simulation. We simulated constant rates over time and did not model seasonal or temporal fluctuation in immigration. </p>
                <p>
                    <bold>International emigration</bold>
                </p>
                <p>Emigration occurs when a simulant leaves the US to live in another country. We used the Net International Migration (NIM) estimates from the Census Bureau&#x2019;s Population Housing Unit (PopEst) program to determine the number of emigrants per year, by subtracting immigration numbers from ACS to isolate emigration. The NIM estimates are made by the PopEst team by combining information about immigration from ACS with information about emigration from demographic analysis (for those born outside the US) and analysis of foreign censuses (for those born in the US)
                    <sup>
                        <xref ref-type="bibr" rid="ref-22">22</xref>
                    </sup>.</p>
                <p>There are three types of emigration events that can occur in our simulation: household moves, GQ-person moves, and non-reference-person moves. These cause an entire household, a GQ person, or a household member who is not a reference person to leave the US, respectively. We stratified emigration rates by age group, sex, race/ethnicity, nativity, and US state of residence, and we assumed that these stratified rates were constant over time, without a long-term trend or seasonal variation. We stopped tracking households and individuals after an emigration event and assumed that they would not return to the US or appear in any pseudopeople data after they had emigrated.</p>
                <p>
                    <bold>
                        <italic toggle="yes">Employment dynamics.</italic>
                    </bold> We consider all simulants aged 18 years or older to be working age; all such simulants either have an employer or are considered unemployed. We only allow a single employer at a time for each simulant. We initialized the working-age simulants to be unemployed, employed in the military, or employed otherwise, and we considered the military to be a single employer. To employ the rest of the simulants (those with non-military jobs), we generated employers with an initial size attribute chosen from a skewed distribution to ensure that there are a few large employers and many small employers. In order to assign individual simulants to employers such that the size attribute is (roughly) accurate at the population level, we selected each simulant&#x2019;s employer from the categorical distribution where the probability of each employer is proportional to its initial size attribute.</p>
                <p>Working-age simulants (including those who are unemployed) change employment randomly at a rate of 50 changes per 100 person-years (a rate we selected subjectively to provide an appropriate challenge in record linkage). When a simulant changes employment, we sample a new employer with the same procedure used at initialization. This approach to selecting a new employer ensures that at the population level, the number of simulants employed by any given employer will remain roughly proportional to the initial size attribute sampled for that employer.</p>
                <p>We also simulate income, which affected which datasets a simulant appeared in. For instance, the WIC dataset only recorded simulants with household income below a certain threshold. We approximated the income distribution with a log-normal distribution for each age group, sex, and race/ethnicity combination, fit to the ACS PUMS. See Appendix 1 for more detail on the distribution parameters used for each demographic group. We simulated only income earned through wages; unemployed simulants had no income. To simplify our model, we assumed statistical independence between wages and employer for employed simulants.</p>
            </sec>
            <sec>
                <title>Post-processing</title>
                <p>We added some elements to the simulated data after the simulation ran. This includes features that would require additional computing resources to track for the simulation&#x2019;s duration, such as simulant names (first and last), employer names, and government-issued identification numbers (i.e., SSNs and ITINs).</p>
                <p>We developed simulant first and last names based on two distinct data sources: first and middle names are sourced from SSA data, which allowed use to match name frequencies to age and sex; while last names are generated from Census data with hyphens and spaces added to make linking tasks realistically more challenging, which allowed use to match the frequencies by race/ethnicity
                    <sup>
                        <xref ref-type="bibr" rid="ref-23">23</xref>,
                        <xref ref-type="bibr" rid="ref-24">24</xref>
                    </sup>. We generated SSNs in accordance with the current algorithm used to issue unique SSNs. We selected the first three digits uniformly at random from 001 to 899, excluding 666; the next two digits from 01 to 99; and the final four digits from 0001 to 9999
                    <sup>
                        <xref ref-type="bibr" rid="ref-25">25</xref>
                    </sup>. We generated Individual Taxpayer Identification Numbers (ITINs) for simulated 1040 filings by simulants without an SSN using a similar process
                    <sup>
                        <xref ref-type="bibr" rid="ref-26">26</xref>
                    </sup>.</p>
                <p>We based our simulated employer names on a database of 5,321,506 &#x201c;location names&#x201d; from the SafeGraph &#x201c;Core Places of Interest USA&#x201d; dataset released in June 2020
                    <sup>
                        <xref ref-type="bibr" rid="ref-27">27</xref>
                    </sup>. To create a representation of bigrams from this dataset, we constructed a directed multigraph. Each word in a location name was treated as a node, and we included special &lt;start&gt; and &lt;end&gt; nodes. We included a directed multi-edge for each occurrence of a word pair in sequence in each location name. To generate simulated employer names, we performed a random walk through the bigram graph. Starting from the &lt;start&gt; node, we traversed directed edges selected uniformly at random until we reached the &lt;end&gt; node or exceeded a predetermined maximum path length. We then combined the words associated with each node that was encountered along the path to form the simulated employer name. This approach resulted in a diverse range of names that maintained a realistic quality. In the sample data included with the pseudopeople package, the W2 and 1099 employer names in 2020 include 212 distinct names and the three most commons are &#x201c;San Benito Martinez Landscape Supply&#x201d;, &#x201c;Tony's Family Practice Inc&#x201d;, and &#x201c;Pikes Creek Campground&#x201d;.</p>
            </sec>
        </sec>
        <sec>
            <title>Dataset validation</title>
            <p>For dataset validation, we followed the standard workflow used across all of our Vivarium models, using a process often referred to as verification and validation (V&amp;V)
                <sup>
                    <xref ref-type="bibr" rid="ref-28">28</xref>
                </sup>. In this process, model results are verified by the research team by checking that a given model approximately replicates target values it was explicitly designed to replicate (e.g., verifying that the proportion of simulants living in group quarters as opposed to individual households matched the value specified by the research team). Results are also validated by the research team, ensuring that model results are logically viable or sensible (e.g., checking that the US population size and structure does not change drastically over the time period modeled). In the event that model results did not meet verification and validation criteria, model implementation and/or design were iteratively adjusted appropriately until criteria were satisfied.</p>
            <p>We validated pseudopeople datasets through automated testing conducted on the engineering side as well as manual, systematic testing of the simulated population and post-processing data on the research side. In an effort to be as systematic as possible with our user-led data testing processes, we aspired to specify our verification and validation strategies before the synthetic population model was developed by our engineers. For example, we used an interactive simulation in a Jupyter Notebook to verify that simulants were dying at the age- and sex-specific all-cause mortality rates estimated for the USA by the IHME Global Burden of Disease Study.</p>
            <sec>
                <title>Dataset limitations</title>
                <p>There are a variety of limitations to our simulation strategy which may affect its ability to reflect real-world dynamics, including but not limited to those regarding migration, employment, physical or mailing address, guardianship, household structure and simulant relationships, and simulant identification.</p>
                <p>For instance, to make possible the simulation of complex migration dynamics, there are a series of assumptions we made regarding how simulants and households move around, into, and out of the simulation. We assumed that domestic and international migration do not change over time, but rather remain at the average rate from 2016 to 2020 in each future year of the simulation. When a simulant moves, we assume that their mailing address, physical address, and employer all change. In addition, complexities particular to household sub-structure interacting with migration are largely not captured in our simulation. For instance, a child can move out of their household without a parent, or a simulant could move without their spouse into a different household. Additionally, we assume that relationship does not affect emigration rates and that all household types are equally likely to have a simulant move out of or into them. Furthermore, for any individual migration of a simulant from one household into another, we assign the relationship &#x201c;other nonrelative&#x201d; in their new household. Thus, as time passes within the simulation, the proportion of households with irregular relationship structures grows. In the sample data included with the pseudopeople package, the 2020 decennial census has 4% of rows have &#x201c;Other nonrelative&#x201d; as relationship to the reference person, and in 2030 this rises to 16%.  Even in the early years of our simulation, it is possible that there are rare, but challenging, household structures which are not sampled in ACS and therefore not represented in our data either, for example a very small fraction of very large households might present a problem in real-work linkage work that would not be identified when testing with pseudopeople data.</p>
                <p>Similarly, there are several assumptions that we made to simplify our model of employment dynamics in our simulation. We do not model retirement, and each simulant can only have one employer at a time. There is a myriad of business dynamics that we currently do not model, including new businesses opening, existing businesses closing, business name changes, or business mergers and acquisitions. As with household physical and mailing addresses, when a business address is vacated, it is not reused. In effect, this likely makes business record linkage with these data easier than it will be in practice.</p>
                <p>Our age-specific fertility and mortality models do not account for variations related to income or race/ethnicity, and in future iterations of this work, we wish to address more complicated dynamics between the various elements of our simulation.</p>
                <p>There are also limitations in simulant identification because of privacy protections in the name data we have used. The data on first names excludes names with fewer than five occurrences while the data on last names included only names with at least 100 occurrences. Furthermore, we did not model the correlation between first and last names explicitly.  We hope to address these limitations in future refinements of our model.</p>
            </sec>
        </sec>
        <sec sec-type="results">
            <title>Results</title>
            <p>Our simulation process produced over 900 gigabytes of simulated censuses, surveys, and administrative data for pseudopeople, representing hundreds of millions of simulants. A sample simulated population of thousands of simulants is now openly available to all users of the pseudopeople package, and large-scale simulated populations of millions and hundreds of millions of simulants are also available by online request through GitHub (
                <ext-link ext-link-type="uri" xlink:href="https://github.com/ihmeuw/pseudopeople/issues/new?assignees=ironholds%2Caflaxman&amp;labels=data+access&amp;projects=&amp;template=data_access_request.yml&amp;title=%5BData+access+request%5D%3A+">github.com/ihmeuw/pseudopeople/issues</ext-link>). These simulated population data are structured for use by the pseudopeople package, which includes additional affordances to add various kinds of noise to the data to provide realistic, sharable challenges for ER researchers.</p>
            <p>
                <xref ref-type="table" rid="T2">Table 2</xref> shows a sample of the simulated data that might be found in administrative sources on income tax (note that these are entirely simulated data and therefore do 
                <italic toggle="yes">not</italic> constitute Confidential Unclassified Information under US Code).</p>
            <table-wrap id="T2" orientation="portrait" position="anchor">
                <label>Table 2. </label>
                <caption>
                    <title>Sample of tax data from simulated population.</title>
                    <p>These are entirely simulated data and therefore do 
                        <italic toggle="yes">not</italic> constitute Confidential Unclassified Information under US Code.</p>
                </caption>
                <table content-type="article-table" frame="hsides">
                    <thead>
                        <tr>
                            <th align="left" colspan="1" rowspan="1" valign="top">Simulant ID</th>
                            <th align="left" colspan="1" rowspan="1" valign="top">First name</th>
                            <th align="left" colspan="1" rowspan="1" valign="top">Last name</th>
                            <th align="left" colspan="1" rowspan="1" valign="top">SSN</th>
                            <th align="left" colspan="1" rowspan="1" valign="top">Employer</th>
                            <th align="left" colspan="1" rowspan="1" valign="top">Wages</th>
                            <th align="left" colspan="1" rowspan="1" valign="top">Tax Form</th>
                        </tr>
                    </thead>
                    <tbody>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">4</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Eric</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Alonso Tellez</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">584-16-0130</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Pikes Creek Campground</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">$10,192 </td>
                            <td align="left" colspan="1" rowspan="1" valign="top">W2</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">5</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Erin</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Alonso Tellez</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">854-13-6295</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Red&#x2019;s Dairy Queen</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">$28,355 </td>
                            <td align="left" colspan="1" rowspan="1" valign="top">W2</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">5</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Erin</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Alonso Tellez</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">854-13-6295</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Warrensburg</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">$18,243 </td>
                            <td align="left" colspan="1" rowspan="1" valign="top">W2</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">5621</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Derick</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Castillo</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">674-27-1745</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Nashville City Properties</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">$7,704 </td>
                            <td align="left" colspan="1" rowspan="1" valign="top">W2</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">5623</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Heather</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Castillo</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">794-23-1522</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Ecr Whipple Oliver 
                                <break/>Finley Shoe Sensation</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">$3,490 </td>
                            <td align="left" colspan="1" rowspan="1" valign="top">1099</td>
                        </tr>
                    </tbody>
                </table>
            </table-wrap>
        </sec>
        <sec sec-type="conclusions">
            <title>Conclusions</title>
            <p>By generating population data with complexity and scale comparable to that of large organizations and federal agencies, like the US Census Bureau, we hope to circumvent the common data privacy&#x2013; and access-related barriers to ER research and development. We intend for this data note to serve as a comprehensive guide for researchers contemplating the use of pseudopeople to develop and test their fresh theories, algorithms, and software systems.</p>
        </sec>
        <sec>
            <title>Acronyms</title>
            <table-wrap id="T3" orientation="portrait" position="anchor">
                <table content-type="article-table" frame="hsides">
                    <tbody>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">Acronym</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Full Form</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>ACS</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">American Community Survey</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>CPS</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Current Population Survey</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>ER</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Entity Resolution</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>GQ</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Group Quarters</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>IHME</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Institute for Health Metrics and Evaluation</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>ITIN</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Individual Taxpayer Identification Number</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>NIM</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Net International Migration</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>OMB</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Office of Management and Budget</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>PII</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Personally Identifiable Information</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>PUMA</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Public Use Microdata Area</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>PUMS</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Public Use Microdata Sample</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>SSA</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Social Security Administration</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>SSN</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Social Security Number</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>USCB</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">United States Census Bureau</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>V&amp;V</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Verification and Validation</td>
                        </tr>
                        <tr>
                            <td align="left" colspan="1" rowspan="1" valign="top">
			
                                <bold>WIC</bold>
		</td>
                            <td align="left" colspan="1" rowspan="1" valign="top">Special Supplemental Nutrition Program for Women Infant and Children</td>
                        </tr>
                    </tbody>
                </table>
            </table-wrap>
        </sec>
    </body>
    <back>
        <sec sec-type="data-availability">
            <title>Data availability</title>
            <p>While a small amount of pseudopeople data is openly available as part of the Python package, access to the full datasets will require users to be both transparent and accountable to a committee of interested parties, including civil society organizations, privacy experts, and data subject representatives. To read more about how to access the full datasets associated with pseudopeople, please visit our website at 
                <ext-link ext-link-type="uri" xlink:href="https://www.pseudopeople.org/">https://www.pseudopeople.org/</ext-link>.</p>
        </sec>
        <sec>
            <title>Software availability</title>
            <p>
                <bold>Source code available from:</bold> 
                <ext-link ext-link-type="uri" xlink:href="https://github.com/ihmeuw/vivarium_census_prl_synth_pop">https://github.com/ihmeuw/vivarium_census_prl_synth_pop</ext-link>
            </p>
            <p>
                <bold>Archived source code at time of publication:</bold> 
                <ext-link ext-link-type="uri" xlink:href="https://doi.org/10.5281/zenodo.10967291">https://doi.org/10.5281/zenodo.10967291</ext-link>
                <sup>
                    <xref ref-type="bibr" rid="ref-29">29</xref>
                </sup>.</p>
            <p>
                <bold>License:</bold> BSD 3-Clause License.</p>
            <p>The steps to reproduce and run the software are available at the site listed above. Please note that although this software is freely available, running the simulation and post-processing at full-USA scale is a resource-intensive process that requires substantial computational resources. Our approach used parallelization across 334 individual jobs, with each job accommodating an optimal population size estimated to be between 750,000 and 1.5 million individuals. For a run of 1 million individual simulants, we used approximately 55 gigabytes of memory and a runtime of 21.5 hours.</p>
        </sec>
        <ref-list>
            <ref id="ref-1">
                <label>1</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Binette</surname>
                            <given-names>O</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Steorts</surname>
                            <given-names>RC</given-names>
                        </name>
</person-group>:
                    <article-title>(Almost) all of entity resolution.</article-title>
                    <source>

                        <italic toggle="yes">Sci Adv.</italic>
</source>
                    <year>2022</year>;<volume>8</volume>(<issue>12</issue>):
                    <elocation-id>eabi8021</elocation-id>.
                    <pub-id pub-id-type="pmid">35333582</pub-id>
                    <pub-id pub-id-type="doi">10.1126/sciadv.abi8021</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-2">
                <label>2</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Connelly</surname>
                            <given-names>R</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Playford</surname>
                            <given-names>CJ</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Gayle</surname>
                            <given-names>V</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>The role of administrative data in the big data revolution in social science research.</article-title>
                    <source>

                        <italic toggle="yes">Soc Sci Res.</italic>
</source>
                    <year>2016</year>;<volume>59</volume>:<fpage>1</fpage>&#x2013;<lpage>12</lpage>.
                    <pub-id pub-id-type="pmid">27480367</pub-id>
                    <pub-id pub-id-type="doi">10.1016/j.ssresearch.2016.04.015</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-3">
                <label>3</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Fischer</surname>
                            <given-names>RL</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Richter</surname>
                            <given-names>FGC</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Anthony</surname>
                            <given-names>E</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>Leveraging administrative data to better serve children and families.</article-title>
                    <source>

                        <italic toggle="yes">Public Adm Rev.</italic>
</source>
                    <year>2019</year>;<volume>79</volume>(<issue>5</issue>):<fpage>675</fpage>&#x2013;<lpage>83</lpage>.
                    <pub-id pub-id-type="doi">10.1111/puar.13047</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-4">
                <label>4</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Christen</surname>
                            <given-names>P</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Schnell</surname>
                            <given-names>R</given-names>
                        </name>
</person-group>:
                    <article-title>Thirty-three myths and misconceptions about population data: from data capture and processing to linkage.</article-title>
                    <source>

                        <italic toggle="yes">Int J Popul Data Sci.</italic>
</source>
                    <year>2023</year>;<volume>8</volume>(<issue>1</issue>): 2115.
                    <pub-id pub-id-type="pmid">37636835</pub-id>
                    <pub-id pub-id-type="doi">10.23889/ijpds.v8i1.2115</pub-id>
                    <pub-id pub-id-type="pmcid">10454001</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-5">
                <label>5</label>
                <mixed-citation publication-type="web">
                    <collab>United States Census Bureau</collab>:
                    <article-title>Four cooperative agreements: census bureau research on record linkage and entity resolution</article-title>. Census.gov. [cited 2023 Nov 1].
                    <ext-link ext-link-type="uri" xlink:href="https://www.census.gov/newsroom/blogs/research-matters/2021/10/four-cooperative-agreements.html">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-6">
                <label>6</label>
                <mixed-citation publication-type="confproc">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Christen</surname>
                            <given-names>P</given-names>
                        </name>
</person-group>:
                    <article-title>Febrl -: an open source data cleaning, deduplication and record linkage system with a graphical user interface</article-title>. In:
                    <italic toggle="yes">Proceedings of the 14th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining.</italic>New York, NY, USA:  Association for Computing Machinery; (KDD &#x2019; 08),<year>2008</year>;<fpage>1065</fpage>&#x2013;<lpage>8</lpage>.
                    <pub-id pub-id-type="doi">10.1145/1401890.1402020</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-7">
                <label>7</label>
                <mixed-citation publication-type="confproc">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Tran</surname>
                            <given-names>KN</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Vatsalan</surname>
                            <given-names>D</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Christen</surname>
                            <given-names>P</given-names>
                        </name>
</person-group>:
                    <article-title>GeCo: an online personal data generator and corruptor.</article-title>In:
                    <italic toggle="yes">Proceedings of the 22nd ACM International Conference on Information &amp; Knowledge Management</italic>. New York, NY, USA: Association for Computing Machinery; (CIKM &#x2019; 13),<year>2013</year>;<fpage>2473</fpage>&#x2013;<lpage>6</lpage>.
                    <pub-id pub-id-type="doi">10.1145/2505515.2508207</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-8">
                <label>8</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Talburt</surname>
                            <given-names>J</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Zhou</surname>
                            <given-names>Y</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Shivaiah</surname>
                            <given-names>SY</given-names>
                        </name>
</person-group>:
                    <article-title>SOG: a synthetic occupancy generator to support entity resolution instruction and research.</article-title>In:<year>2009</year>.
                    <ext-link ext-link-type="uri" xlink:href="https://www.researchgate.net/publication/215991472_SOG_A_Synthetic_Occupancy_Generator_to_Support_Entity_Resolution_Instruction_and_Research">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-9">
                <label>9</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Nowok</surname>
                            <given-names>B</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Raab</surname>
                            <given-names>GM</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Dibben</surname>
                            <given-names>C</given-names>
                        </name>
</person-group>:
                    <article-title>Synthpop: bespoke creation of synthetic data in R.</article-title>
                    <source>

                        <italic toggle="yes">J Stat Softw.</italic>
</source>
                    <year>2016</year>;<volume>74</volume>(<issue>11</issue>):<fpage>1</fpage>&#x2013;<lpage>26</lpage>.
                    <pub-id pub-id-type="doi">10.18637/jss.v074.i11</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-10">
                <label>10</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Lindsay</surname>
                            <given-names>S</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Kennedy</surname>
                            <given-names>R</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Hepworth</surname>
                            <given-names>T</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>Splink: latest developments and applications.</article-title>
                    <source>

                        <italic toggle="yes">Int J Popul Data Sci.</italic>
</source>
                    <year>2023</year>;<volume>8</volume>(<issue>2</issue>): 2245.
                    <pub-id pub-id-type="doi">10.23889/ijpds.v8i2.2245</pub-id>
                    <pub-id pub-id-type="pmcid">10929522</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-11">
                <label>11</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Schnell</surname>
                            <given-names>R</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Weiand</surname>
                            <given-names>S</given-names>
                        </name>
</person-group>:
                    <article-title>Microsimulation of an educational attainment register to predict future record linkage quality.</article-title>
                    <source>

                        <italic toggle="yes">Int J Popul Data Sci.</italic>
</source>
                    <year>2023</year>;<volume>8</volume>(<issue>1</issue>): 2122.
                    <pub-id pub-id-type="pmid">37649490</pub-id>
                    <pub-id pub-id-type="doi">10.23889/ijpds.v8i1.2122</pub-id>
                    <pub-id pub-id-type="pmcid">10463005</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-12">
                <label>12</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Viljoen</surname>
                            <given-names>S</given-names>
                        </name>
</person-group>:
                    <article-title>A relational theory of data governance.</article-title>
                    <source>

                        <italic toggle="yes">Yale LJ.</italic>
</source>
                    <year>2021</year>;<volume>131</volume>: 573.
                    <ext-link ext-link-type="uri" xlink:href="https://www.private-law-theory.org/2024/01/19/salome-viljoen-a-relational-theory-of-data-governance-2/">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-13">
                <label>13</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Christen</surname>
                            <given-names>P</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Ranbaduge</surname>
                            <given-names>T</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Schnell</surname>
                            <given-names>R</given-names>
                        </name>
</person-group>:
                    <article-title>Linking sensitive data</article-title>.<year>2020</year>.
                    <pub-id pub-id-type="doi">10.1007/978-3-030-59706-1</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-14">
                <label>14</label>
                <mixed-citation publication-type="journal">
                    <article-title>Ihmeuw/vivarium: archival release</article-title>. [cited 2023 Nov 1].
                    <ext-link ext-link-type="uri" xlink:href="https://zenodo.org/records/10038891">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-15">
                <label>15</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Harris</surname>
                            <given-names>CR</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Millman</surname>
                            <given-names>KJ</given-names>
                        </name>

                        <name name-style="western">
                            <surname>van der Walt</surname>
                            <given-names>SJ</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>Array programming with NumPy.</article-title>
                    <source>

                        <italic toggle="yes">Nature.</italic>
</source>
                    <year>2020</year>;<volume>585</volume>(<issue>7825</issue>):<fpage>357</fpage>&#x2013;<lpage>62</lpage>.
                    <pub-id pub-id-type="pmid">32939066</pub-id>
                    <pub-id pub-id-type="doi">10.1038/s41586-020-2649-2</pub-id>
                    <pub-id pub-id-type="pmcid">7759461</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-16">
                <label>16</label>
                <mixed-citation publication-type="confproc">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>McKinney</surname>
                            <given-names>W</given-names>
                        </name>
</person-group>:
                    <article-title>Data structures for statistical computing in python.</article-title>In: Austin, Texas;<year>2010</year>;<fpage>56</fpage>&#x2013;<lpage>61</lpage>.
                    <ext-link ext-link-type="uri" xlink:href="https://conference.scipy.org/proceedings/scipy2010/mckinney.html">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-17">
                <label>17</label>
                <mixed-citation publication-type="confproc">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Yassine</surname>
                            <given-names>M</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Beauchemin</surname>
                            <given-names>D</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Laviolette</surname>
                            <given-names>F</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>Leveraging subword embeddings for multinational address parsing.</article-title>In:
                    <italic toggle="yes">2020 6th IEEE Congress on Information Science and Technology (CiSt)</italic>.<year>2020</year>;<fpage>353</fpage>&#x2013;<lpage>60</lpage>.
                    <pub-id pub-id-type="doi">10.1109/CiSt49399.2021.9357170</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-18">
                <label>18</label>
                <mixed-citation publication-type="web">
                    <collab>United States Census Bureau</collab>:
                    <article-title>Public Use Microdata Sample (PUMS)</article-title>. Census.gov. [cited 2023 Nov 1].
                    <ext-link ext-link-type="uri" xlink:href="https://www.census.gov/programs-surveys/acs/microdata.html">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-19">
                <label>19</label>
                <mixed-citation publication-type="web">
                    <collab>Federal Register</collab>:
                    <article-title>Revisions to the standards for the classification of federal data on race and ethnicity</article-title>.<year>1997</year>; [cited 2023 Nov 1].
                    <ext-link ext-link-type="uri" xlink:href="https://www.federalregister.gov/documents/1997/10/30/97-28653/revisions-to-the-standards-for-the-classification-of-federal-data-on-race-and-ethnicity">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-20">
                <label>20</label>
                <mixed-citation publication-type="journal">
                    <article-title>2016-2020 ACS PUMS Data Dictionary</article-title>.</mixed-citation>
            </ref>
            <ref id="ref-21">
                <label>21</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Wang</surname>
                            <given-names>H</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Abbas</surname>
                            <given-names>KM</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Abbasifard</surname>
                            <given-names>M</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>Global age-sex-specific fertility, mortality, Healthy Life Expectancy (HALE), and population estimates in 204 countries and territories, 1950-2019: a comprehensive demographic analysis for the Global Burden of Disease study 2019.</article-title>
                    <source>

                        <italic toggle="yes">Lancet.</italic>
</source>
                    <year>2020</year>;<volume>396</volume>(<issue>10258</issue>):<fpage>1160</fpage>&#x2013;<lpage>203</lpage>.
                    <pub-id pub-id-type="pmid">33069325</pub-id>
                    <pub-id pub-id-type="doi">10.1016/S0140-6736(20)30977-6</pub-id>
                    <pub-id pub-id-type="pmcid">7566045</pub-id>
                </mixed-citation>
            </ref>
            <ref id="ref-22">
                <label>22</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Bhaskar</surname>
                            <given-names>R</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Cort&#x00e9;s</surname>
                            <given-names>R</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Scopilliti</surname>
                            <given-names>M</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>Estimating net international migration for 2010 demographic analysis: an overview of methods and results</article-title>.
                    <ext-link ext-link-type="uri" xlink:href="https://www.census.gov/content/dam/Census/library/working-papers/2013/demo/POP-twps0097.pdf">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-23">
                <label>23</label>
                <mixed-citation publication-type="web">
                    <article-title>Popular baby names</article-title>. [cited 2023 Nov 1].
                    <ext-link ext-link-type="uri" xlink:href="https://www.ssa.gov/oact/babynames/limits.html">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-24">
                <label>24</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Comenetz</surname>
                            <given-names>J</given-names>
                        </name>
</person-group>:
                    <article-title>Frequently occurring surnames in the 2010 census</article-title>.</mixed-citation>
            </ref>
            <ref id="ref-25">
                <label>25</label>
                <mixed-citation publication-type="web">
                    <article-title>The social security number verification service</article-title>. [cited 2023 Nov 1].
                    <ext-link ext-link-type="uri" xlink:href="https://www.ssa.gov/employer/ssnv.htm#overview">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-26">
                <label>26</label>
                <mixed-citation publication-type="web">
                    <article-title>Individual Taxpayer Identification Number</article-title>. Internal Revenue Service, [cited 2023 Nov 1].
                    <ext-link ext-link-type="uri" xlink:href="https://www.irs.gov/individuals/individual-taxpayer-identification-number">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-27">
                <label>27</label>
                <mixed-citation publication-type="web">
                    <article-title>Places data curated for accurate geospatial analytics.</article-title>SafeGraph, [cited 2023 Nov 1].
                    <ext-link ext-link-type="uri" xlink:href="https://safegraph.com/">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-28">
                <label>28</label>
                <mixed-citation publication-type="web">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Allen</surname>
                            <given-names>C</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Collins</surname>
                            <given-names>J</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Rankin</surname>
                            <given-names>Z</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>Enabling model complexity through an improved workflow.</article-title>In: Washington D.C.;<year>2019</year>.
                    <ext-link ext-link-type="uri" xlink:href="https://www.semanticscholar.org/paper/Enabling-Model-Complexity-Through-an-Improved-Allen-Collins/84eb24b2bda337b3d7971879ef330ac59cb02681">Reference Source</ext-link>
                </mixed-citation>
            </ref>
            <ref id="ref-29">
                <label>29</label>
                <mixed-citation publication-type="journal">
                    <person-group person-group-type="author">

                        <name name-style="western">
                            <surname>Albright</surname>
                            <given-names>J</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Haddock</surname>
                            <given-names>B</given-names>
                        </name>

                        <name name-style="western">
                            <surname>Bachmeier</surname>
                            <given-names>S</given-names>
                        </name>

                        <etal/>
</person-group>:
                    <article-title>ihmeuw/vivarium_census_prl_synth_pop: data release (v2.0.1).</article-title>
                    <source>

                        <italic toggle="yes">Zenodo.</italic>
</source>
                    <year>2024</year>.
                    <ext-link ext-link-type="uri" xlink:href="http://www.doi.org/10.5281/zenodo.10967291">http://www.doi.org/10.5281/zenodo.10967291</ext-link>
                </mixed-citation>
            </ref>
        </ref-list>
    </back>
    <sub-article article-type="reviewer-report" id="report38295">
        <front-stub>
            <article-id pub-id-type="doi">10.21956/gatesopenres.17690.r38295</article-id>
            <title-group>
                <article-title>Reviewer response for version 2</article-title>
            </title-group>
            <contrib-group>
                <contrib contrib-type="author">
                    <name>
                        <surname>Schnell</surname>
                        <given-names>Rainer</given-names>
                    </name>
                    <xref ref-type="aff" rid="r38295a1">1</xref>
                    <role>Referee</role>
                    <uri content-type="orcid">https://orcid.org/0000-0001-7843-4974</uri>
                </contrib>
                <aff id="r38295a1">
                    <label>1</label>University of Duisburg-Essen, Duisburg, Germany</aff>
            </contrib-group>
            <author-notes>
                <fn fn-type="conflict">
                    <p>
                        <bold>Competing interests: </bold>No competing interests were disclosed.</p>
                </fn>
            </author-notes>
            <pub-date pub-type="epub">
                <day>28</day>
                <month>10</month>
                <year>2024</year>
            </pub-date>
            <permissions>
                <copyright-statement>Copyright: &#x00a9; 2024 Schnell R</copyright-statement>
                <copyright-year>2024</copyright-year>
                <license xlink:href="https://creativecommons.org/licenses/by/4.0/">
                    <license-p>This is an open access peer review report distributed under the terms of the Creative Commons Attribution Licence, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
                </license>
            </permissions>
            <related-article ext-link-type="doi" id="relatedArticleReport38295" related-article-type="peer-reviewed-article" xlink:href="10.12688/gatesopenres.15418.2"/>
            <custom-meta-group>
                <custom-meta>
                    <meta-name>recommendation</meta-name>
                    <meta-value>approve-with-reservations</meta-value>
                </custom-meta>
            </custom-meta-group>
        </front-stub>
        <body>
            <p>The paper has improved a lot. 
                <list list-type="order">
                    <list-item>
                        <p>It is now clearer that detailed corruption is done within "pseudopeople".</p>
                    </list-item>
                    <list-item>
                        <p>However, neither the intended workflow nor the relationship between the input generated here, pseudopeople and vivarium is evident from the paper alone.</p>
                    </list-item>
                    <list-item>
                        <p>Since this is a microsimulation, a reference to the standard textbooks (for example, Handbook of Microsimulation,&#x00a0;Practical Microsimulation or Spatial Microsimulation (...)) seems to be required.</p>
                    </list-item>
                    <list-item>
                        <p>Since the aim of the paper seems to generate records for ER, the dependencies of the changes of QIDs due to the simulated processes are essential for an unbiased estimate of successful ER. For example, when does a name change to which variant, caused by marriage, divorce, free will or naturalization? I cannot find a description in the text, although these processes are essential to the problems of ER in practice. If these processes are implemented, they need parameters derived from empirical studies, which should be referenced.</p>
                    </list-item>
                    <list-item>
                        <p>The authors state: "There are certain features of our project, however, that differentiate it from other efforts, most notably the scale of our simulated data: We have simulated a 100% sample of the USA over 20 years." Population microsimulation is common; for example, the UK models and the German Mikrosim project cover a whole nation for 20 years or more (which hardly makes sense in microsimulation). Furthermore, there is a Canadian and a Swedish microsimulation of the population. So, the special feature is that it is a US model. Neither the population covering aspect, the duration, nor the ideas of the main mechanisms of the microsimulation are new.</p>
                    </list-item>
                </list>
            </p>
            <p>Are sufficient details of methods and materials provided to allow replication by others?</p>
            <p>No</p>
            <p>Is the rationale for creating the dataset(s) clearly described?</p>
            <p>Yes</p>
            <p>Are the datasets clearly presented in a useable and accessible format?</p>
            <p>Partly</p>
            <p>Are the protocols appropriate and is the work technically sound?</p>
            <p>Partly</p>
            <p>Reviewer Expertise:</p>
            <p>microsimulation, record linkage, PPRL, census operations</p>
            <p>I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above.</p>
        </body>
    </sub-article>
    <sub-article article-type="reviewer-report" id="report38294">
        <front-stub>
            <article-id pub-id-type="doi">10.21956/gatesopenres.17690.r38294</article-id>
            <title-group>
                <article-title>Reviewer response for version 2</article-title>
            </title-group>
            <contrib-group>
                <contrib contrib-type="author">
                    <name>
                        <surname>D. Gaboardi</surname>
                        <given-names>James</given-names>
                    </name>
                    <xref ref-type="aff" rid="r38294a1">1</xref>
                    <role>Referee</role>
                    <uri content-type="orcid">https://orcid.org/0000-0002-4776-6826</uri>
                </contrib>
                <aff id="r38294a1">
                    <label>1</label>Oak Ridge National Laboratory, Oak Ridge, USA</aff>
            </contrib-group>
            <author-notes>
                <fn fn-type="conflict">
                    <p>
                        <bold>Competing interests: </bold>No competing interests were disclosed.</p>
                </fn>
            </author-notes>
            <pub-date pub-type="epub">
                <day>22</day>
                <month>10</month>
                <year>2024</year>
            </pub-date>
            <permissions>
                <copyright-statement>Copyright: &#x00a9; 2024 D. Gaboardi J</copyright-statement>
                <copyright-year>2024</copyright-year>
                <license xlink:href="https://creativecommons.org/licenses/by/4.0/">
                    <license-p>This is an open access peer review report distributed under the terms of the Creative Commons Attribution Licence, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
                </license>
            </permissions>
            <related-article ext-link-type="doi" id="relatedArticleReport38294" related-article-type="peer-reviewed-article" xlink:href="10.12688/gatesopenres.15418.2"/>
            <custom-meta-group>
                <custom-meta>
                    <meta-name>recommendation</meta-name>
                    <meta-value>approve</meta-value>
                </custom-meta>
            </custom-meta-group>
        </front-stub>
        <body>
            <p>I have no further comments.</p>
            <p>Are sufficient details of methods and materials provided to allow replication by others?</p>
            <p>Yes</p>
            <p>Is the rationale for creating the dataset(s) clearly described?</p>
            <p>Yes</p>
            <p>Are the datasets clearly presented in a useable and accessible format?</p>
            <p>Yes</p>
            <p>Are the protocols appropriate and is the work technically sound?</p>
            <p>Yes</p>
            <p>Reviewer Expertise:</p>
            <p>GIScience, Spatial Optimization, Geocomputation, Research Software Science</p>
            <p>I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.</p>
        </body>
    </sub-article>
    <sub-article article-type="reviewer-report" id="report36776">
        <front-stub>
            <article-id pub-id-type="doi">10.21956/gatesopenres.16769.r36776</article-id>
            <title-group>
                <article-title>Reviewer response for version 1</article-title>
            </title-group>
            <contrib-group>
                <contrib contrib-type="author">
                    <name>
                        <surname>Schnell</surname>
                        <given-names>Rainer</given-names>
                    </name>
                    <xref ref-type="aff" rid="r36776a1">1</xref>
                    <role>Referee</role>
                    <uri content-type="orcid">https://orcid.org/0000-0001-7843-4974</uri>
                </contrib>
                <aff id="r36776a1">
                    <label>1</label>University of Duisburg-Essen, Duisburg, Germany</aff>
            </contrib-group>
            <author-notes>
                <fn fn-type="conflict">
                    <p>
                        <bold>Competing interests: </bold>No competing interests were disclosed.</p>
                </fn>
            </author-notes>
            <pub-date pub-type="epub">
                <day>17</day>
                <month>7</month>
                <year>2024</year>
            </pub-date>
            <permissions>
                <copyright-statement>Copyright: &#x00a9; 2024 Schnell R</copyright-statement>
                <copyright-year>2024</copyright-year>
                <license xlink:href="https://creativecommons.org/licenses/by/4.0/">
                    <license-p>This is an open access peer review report distributed under the terms of the Creative Commons Attribution Licence, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
                </license>
            </permissions>
            <related-article ext-link-type="doi" id="relatedArticleReport36776" related-article-type="peer-reviewed-article" xlink:href="10.12688/gatesopenres.15418.1"/>
            <custom-meta-group>
                <custom-meta>
                    <meta-name>recommendation</meta-name>
                    <meta-value>reject</meta-value>
                </custom-meta>
            </custom-meta-group>
        </front-stub>
        <body>
            <p>This is an interesting project and an interesting article.</p>
            <p> </p>
            <p> My main concerns relate to the assumptions in using the names. The names are from top-lists and therefore do not contain rare names. The entropy of the QIDs is therefore underestimated, and linkage quality will be overestimated,</p>
            <p> Furthermore, first names and last names are used independently and this will also underestimate the entropy in real data sets. Again, linkage quality will be biased.</p>
            <p> </p>
            <p> By inflating ACS data, the same problem will occur. For example, rare household compositions, such as very large households, will be rare or even non-existing in ACS. Exactly these households will cause problems in real-world linkages. For example, similar names and birthdays at the same address are more in census data than in samples of 1 or even 5 % of the population. Furthermore, using name distributions independent of very large household compositions will cover up the main census linkage problem in my experience: Separating very similar persons. These "rare" cases of about very few percent of a population will cause underestimation of subpopulations using a biased sample (given the aim are census estimates).</p>
            <p> </p>
            <p> The terminology is a bit strange. For example, naming the simulated entities "simulants" is unusual in microsimulation (see, for example, O'Donoghue).</p>
            <p> Another example is &#x201c;shards&#x201d;, used a synonym for computational jobs. However, in general, a shard is</p>
            <p> is a horizontal partition of data in a database or search engine (cited from Wikipedia), not a job. There are many more issues like these, and it might be helpful to check the usage of the terminology again.</p>
            <p> </p>
            <p> I miss a clear statement, which parameters of the model are available within the programs provided or as parameter files. The time available for reviews do not permit running these programs for replication, therefore more much more details on what can be done with the data available at the GitHub link is required.</p>
            <p> </p>
            <p> If a corrupter for QIDs is part of the program collection is also unclear to me. If so, the details of the parameters and their dependency on the simulated processes are of prime interest. For example, the text states: "These simulated population data are structured for use by the pseudopeople package, which includes additional affordances to add various kinds of noise to the data to provide realistic, sharable challenges for ER researchers." Thefefore, is this paper describing "pseudopeople", "Vivarium", their joint usage or something else?</p>
            <p> </p>
            <p> Some previous work is not cited. For example, to the best of my knowledge, we have published the first paper on using microsimulation for generating data for record-linkage (Schnell/Weiand 2023).</p>
            <p> </p>
            <p> Furthermore, the book on linking techniques by Christen et al. discusses many previous generators and corrupters systematically.</p>
            <p>Are sufficient details of methods and materials provided to allow replication by others?</p>
            <p>No</p>
            <p>Is the rationale for creating the dataset(s) clearly described?</p>
            <p>Yes</p>
            <p>Are the datasets clearly presented in a useable and accessible format?</p>
            <p>Partly</p>
            <p>Are the protocols appropriate and is the work technically sound?</p>
            <p>Partly</p>
            <p>Reviewer Expertise:</p>
            <p>microsimulation, record linkage, PPRL, census operations</p>
            <p>I confirm that I have read this submission and believe that I have an appropriate level of expertise to state that I do not consider it to be of an acceptable scientific standard, for reasons outlined above.</p>
        </body>
        <back>
            <ref-list>
                <title>References</title>
                <ref id="rep-ref-36776-1">
                    <label>1</label>
                    <mixed-citation publication-type="journal">
                        <person-group person-group-type="author"/>:
                        <article-title>Microsimulation of an educational attainment register to predict future record linkage quality.</article-title>
                        <source>
                            <italic>Int J Popul Data Sci</italic>
                        </source>.<year>2023</year>;<volume>8</volume>(<issue>1</issue>) :
                        <elocation-id>10.23889/ijpds.v8i1.2122</elocation-id>
                        <fpage>2122</fpage>
                        <pub-id pub-id-type="pmid">37649490</pub-id>
                        <pub-id pub-id-type="doi">10.23889/ijpds.v8i1.2122</pub-id>
                    </mixed-citation>
                </ref>
                <ref id="rep-ref-36776-2">
                    <label>2</label>
                    <mixed-citation publication-type="journal">
                        <person-group person-group-type="author"/>:
                        <article-title>Linking Sensitive Data</article-title>.<year>2020</year>;
                        <elocation-id>10.1007/978-3-030-59706-1</elocation-id>
                        <pub-id pub-id-type="doi">10.1007/978-3-030-59706-1</pub-id>
                    </mixed-citation>
                </ref>
                <ref id="rep-ref-36776-3">
                    <label>3</label>
                    <mixed-citation publication-type="journal">
                        <person-group person-group-type="author"/>:
                        <article-title>Practical Microsimulation Modelling</article-title>.<year>2021</year>;
                        <elocation-id>10.1093/oso/9780198852872.001.0001</elocation-id>
                        <pub-id pub-id-type="doi">10.1093/oso/9780198852872.001.0001</pub-id>
                    </mixed-citation>
                </ref>
            </ref-list>
        </back>
        <sub-article article-type="response" id="comment3725-36776">
            <front-stub>
                <contrib-group>
                    <contrib contrib-type="author">
                        <name>
                            <surname>Flaxman</surname>
                            <given-names>Abraham</given-names>
                        </name>
                        <aff>University of Washington, Seattle, USA</aff>
                    </contrib>
                </contrib-group>
                <author-notes>
                    <fn fn-type="conflict">
                        <p>
                            <bold>Competing interests: </bold>No competing interests</p>
                    </fn>
                </author-notes>
                <pub-date pub-type="epub">
                    <day>2</day>
                    <month>10</month>
                    <year>2024</year>
                </pub-date>
            </front-stub>
            <body>
                <p>This is an interesting project and an interesting article.</p>
                <p> </p>
                <p> My main concerns relate to the assumptions in using the names. The names are from top-lists and therefore do not contain rare names. The entropy of the QIDs [ADF1]&#x00a0;is therefore underestimated, and linkage quality will be overestimated, and furthermore, first names and last names are used independently and this will also underestimate the entropy in real data sets. Again, linkage quality will be biased.</p>
                <p> 
                    <italic>Response: We appreciate the reviewer identifying these important limitations, and we have added text to our limitations section to call attention to them.&#x00a0; In future work, we hope to compare entropy from our approach and some of the datasets without such redactions, such as from voter registration data, and also to enhance our approach to have more realistic marginal distributions for first and last names as well as joint distributions over (first name, last name) pairs.</italic>
                </p>
                <p> </p>
                <p> By inflating ACS data, the same problem will occur. For example, rare household compositions, such as very large households, will be rare or even non-existing in ACS. Exactly these households will cause problems in real-world linkages. For example, similar names and birthdays at the same address are more in census data than in samples of 1 or even 5 % of the population. Furthermore, using name distributions independent of very large household compositions will cover up the main census linkage problem in my experience: Separating very similar persons. These "rare" cases of about very few percent of a population will cause underestimation of subpopulations using a biased sample (given the aim are census estimates).</p>
                <p> 
                    <italic>Response: We have added to the limitations section to call attention to this limitation as well, and appreciate the reviewer highlighting it for us.</italic>
                </p>
                <p> </p>
                <p> The terminology is a bit strange. For example, naming the simulated entities "simulants" is unusual in microsimulation (see, for example, O'Donoghue).</p>
                <p> Another example is &#x201c;shards&#x201d;, used a synonym for computational jobs. However, in general, a shard is a horizontal partition of data in a database or search engine (cited from Wikipedia), not a job. There are many more issues like these, and it might be helpful to check the usage of the terminology again.</p>
                <p> 
                    <italic>Response: This is due to some internal jargon that has developed over time in our multidisciplinary group at IHME, and we appreciate the reviewer identifying it.&#x00a0; We can easily can change our terminology to avoid some of the cognitive burden of unfamiliar language, and we have removed the term &#x201c;shard&#x201d; as part of this effort.&#x00a0; We appreciate the precision &#x201c;simulant&#x201d; brings to discussing data fields that would be considered confidential information if they were about a real person, however, and have kept this terminology, which we hope becomes more common over time.</italic>
                </p>
                <p> I miss a clear statement, which parameters of the model are available within the programs provided or as parameter files. The time available for reviews do not permit running these programs for replication, therefore more much more details on what can be done with the data available at the GitHub link is required.</p>
                <p> 
                    <italic>Response: This can be an important limitation for users, and we have added details on the parameters which are inherent to the simulation and cannot be modified in the pseudopeople &#x201c;post processing&#x201d;.</italic>
                </p>
                <p> </p>
                <p> If a corrupter for QIDs is part of the program collection is also unclear to me. If so, the details of the parameters and their dependency on the simulated processes are of prime interest. For example, the text states: "These simulated population data are structured for use by the pseudopeople package, which includes additional affordances to add various kinds of noise to the data to provide realistic, sharable challenges for ER researchers." Thefefore, is this paper describing "pseudopeople", "Vivarium", their joint usage or something else?</p>
                <p> 
                    <italic>Response: Our goal was to describe a specific simulation that we built with our Vivarium framework, to generate data for our pseudopeople package.&#x00a0; Upon reflection, this is sure to be really confusing for anyone outside of our team, and we apologize for not making it clearer!&#x00a0; We have added more detail about what is in pseudopeople and what is in this simulation; this was also confusing to reviewer 1.</italic>
                </p>
                <p> </p>
                <p> Some previous work is not cited. For example, to the best of my knowledge, we have published the first paper on using microsimulation for generating data for record-linkage (Schnell/Weiand 2023).</p>
                <p> 
                    <italic>Response: Thank you for highlighting this relevant literature, to which we have added a citation.</italic>
                </p>
                <p> </p>
                <p> Furthermore, the book on linking techniques by Christen et al. discusses many previous generators and corrupters systematically.</p>
                <p> 
                    <italic>Thank you for highlighting this, which is now even more important for us to refer to, since we have added information on the pseudopeople package that uses the simulated data described in the first draft of our paper, and the data corrupters included therein are substantially influenced by Christen et al&#x2019;s FEBRL and GeCO methods.</italic>
                </p>
            </body>
        </sub-article>
    </sub-article>
    <sub-article article-type="reviewer-report" id="report37051">
        <front-stub>
            <article-id pub-id-type="doi">10.21956/gatesopenres.16769.r37051</article-id>
            <title-group>
                <article-title>Reviewer response for version 1</article-title>
            </title-group>
            <contrib-group>
                <contrib contrib-type="author">
                    <name>
                        <surname>D. Gaboardi</surname>
                        <given-names>James</given-names>
                    </name>
                    <xref ref-type="aff" rid="r37051a1">1</xref>
                    <role>Referee</role>
                    <uri content-type="orcid">https://orcid.org/0000-0002-4776-6826</uri>
                </contrib>
                <aff id="r37051a1">
                    <label>1</label>Oak Ridge National Laboratory, Oak Ridge, USA</aff>
            </contrib-group>
            <author-notes>
                <fn fn-type="conflict">
                    <p>
                        <bold>Competing interests: </bold>No competing interests were disclosed.</p>
                </fn>
            </author-notes>
            <pub-date pub-type="epub">
                <day>17</day>
                <month>7</month>
                <year>2024</year>
            </pub-date>
            <permissions>
                <copyright-statement>Copyright: &#x00a9; 2024 D. Gaboardi J</copyright-statement>
                <copyright-year>2024</copyright-year>
                <license xlink:href="https://creativecommons.org/licenses/by/4.0/">
                    <license-p>This is an open access peer review report distributed under the terms of the Creative Commons Attribution Licence, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
                </license>
            </permissions>
            <related-article ext-link-type="doi" id="relatedArticleReport37051" related-article-type="peer-reviewed-article" xlink:href="10.12688/gatesopenres.15418.1"/>
            <custom-meta-group>
                <custom-meta>
                    <meta-name>recommendation</meta-name>
                    <meta-value>approve</meta-value>
                </custom-meta>
            </custom-meta-group>
        </front-stub>
        <body>
            <p>The authors present a thorough and holistic population simulation procedure with Vivarium &amp; the means to access it with pseudopeople. This framework is operationalized through the use of publicly-available data products from the US Census Bureau, the Social Security Administration, and other auxiliary datasets. The overarching purpose of the framework is synthetic Entity Resolution (ER), and the implementation takes chronology and life events into account (e.g., age, residence change, birth, death). Person- &amp; household-level records are simulated that are also linked to related demographic information, such employment and migration. The authors produce large-scale simulated census information for a span of 20 years into the future, a sample of which is entirely open-sourced while more detailed data is available through request.</p>
            <p> </p>
            <p> I am curious for the authors' insights into the potential of integration into other simulation frameworks, such as ChiSim
                <sup>1</sup> and UrbanPop
                <sup>2,3</sup>. As a full disclosure, I am affiliated with the UrbanPop project.</p>
            <p> &#x00a0; 
                <list list-type="order">
                    <list-item>
                        <p>C.M. Macal, N.T. Collier, J.Ozik, E.R. Tatara, and J.T. Murphy (2018). "Chisim: An agent-based simulation model of social interactions in a large urban area," in 2018 winter simulation conference (WSC), pp. 810820, IEEE. DOI: 10.1109/wsc.2018.8632409.</p>
                    </list-item>
                    <list-item>
                        <p>J.V. Tuccillo, R. Stewart, A. Rose, N. Trombley, J. Moehl, N.N. Nagle, and B. Bhaduri (2023) "UrbanPop: A spatial microsimulation framework for exploring demographic influences on human dynamics," Applied Geography, vol. 151, pp. 102844. DOI: 10.1016/j.apgeog.2022.102844.</p>
                    </list-item>
                    <list-item>
                        <p>J.V. Tuccillo and J.D. Gaboardi (2023) "Spatial Microsimulation and Activity Allocation in Python: An Update on the Likeness Toolkit," Proceedings of the 22nd Python in Science Conference, pp. 93-100. DOI: 10.25080/gerudo-f2bc6f59-00c.</p>
                    </list-item>
                </list>
            </p>
            <p>Are sufficient details of methods and materials provided to allow replication by others?</p>
            <p>Yes</p>
            <p>Is the rationale for creating the dataset(s) clearly described?</p>
            <p>Yes</p>
            <p>Are the datasets clearly presented in a useable and accessible format?</p>
            <p>Yes</p>
            <p>Are the protocols appropriate and is the work technically sound?</p>
            <p>Yes</p>
            <p>Reviewer Expertise:</p>
            <p>GIScience, Spatial Optimization, Geocomputation, Research Software Science</p>
            <p>I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.</p>
        </body>
        <back>
            <ref-list>
                <title>References</title>
                <ref id="rep-ref-37051-1">
                    <label>1</label>
                    <mixed-citation>
                        <article-title>An agent-based simulation model of social interactions in a large urban area</article-title>.
                        <source>
                            <italic>winter simulation conference (WSC)</italic>
                        </source>.<year>2018</year>;</mixed-citation>
                </ref>
                <ref id="rep-ref-37051-2">
                    <label>2</label>
                    <mixed-citation publication-type="journal">
                        <person-group person-group-type="author"/>:
                        <article-title>UrbanPop: A spatial microsimulation framework for exploring demographic influences on human dynamics</article-title>.
                        <source>
                            <italic>Applied Geography</italic>
                        </source>.<year>2023</year>;<volume>151</volume>:
                        <elocation-id>10.1016/j.apgeog.2022.102844</elocation-id>
                        <pub-id pub-id-type="doi">10.1016/j.apgeog.2022.102844</pub-id>
                    </mixed-citation>
                </ref>
                <ref id="rep-ref-37051-3">
                    <label>3</label>
                    <mixed-citation>
                        <article-title>Spatial Microsimulation and Activity Allocation in Python: An Update on the Likeness Toolkit</article-title>.
                        <source>
                            <italic>Python in Science Conference</italic>
                        </source>.<year>2023</year>;</mixed-citation>
                </ref>
            </ref-list>
        </back>
        <sub-article article-type="response" id="comment3724-37051">
            <front-stub>
                <contrib-group>
                    <contrib contrib-type="author">
                        <name>
                            <surname>Flaxman</surname>
                            <given-names>Abraham</given-names>
                        </name>
                        <aff>University of Washington, Seattle, USA</aff>
                    </contrib>
                </contrib-group>
                <author-notes>
                    <fn fn-type="conflict">
                        <p>
                            <bold>Competing interests: </bold>No competing interests</p>
                    </fn>
                </author-notes>
                <pub-date pub-type="epub">
                    <day>2</day>
                    <month>10</month>
                    <year>2024</year>
                </pub-date>
            </front-stub>
            <body>
                <p>
                    <italic>Thank you for this positive assessment and fun opportunity to read up and think about; at a high level, it seems that some integration must be possible!&#x00a0; If I understand correctly, it appears that the time scale of the ChiSim and UrbanPop projects is substantially finer-grained than what we used in pseudopeople --- while they capture patterns of mobility over the course of a day, we have focused on internal migration patterns that might happen only once in a year.&#x00a0; That said, the general area is very similar, and the work in our setting might be useful for this line of research.&#x00a0; And vice versa!&#x00a0; Thank you for calling our attention to this work.</italic>
                </p>
            </body>
        </sub-article>
    </sub-article>
    <sub-article article-type="reviewer-report" id="report36771">
        <front-stub>
            <article-id pub-id-type="doi">10.21956/gatesopenres.16769.r36771</article-id>
            <title-group>
                <article-title>Reviewer response for version 1</article-title>
            </title-group>
            <contrib-group>
                <contrib contrib-type="author">
                    <name>
                        <surname>Kum</surname>
                        <given-names>Hye Chung</given-names>
                    </name>
                    <xref ref-type="aff" rid="r36771a1">1</xref>
                    <role>Referee</role>
                    <uri content-type="orcid">https://orcid.org/0000-0002-6882-8053</uri>
                </contrib>
                <aff id="r36771a1">
                    <label>1</label>Population Informatics Lab, Texas A&amp;M University, College Station, Texas, USA</aff>
            </contrib-group>
            <author-notes>
                <fn fn-type="conflict">
                    <p>
                        <bold>Competing interests: </bold>No competing interests were disclosed.</p>
                </fn>
            </author-notes>
            <pub-date pub-type="epub">
                <day>17</day>
                <month>7</month>
                <year>2024</year>
            </pub-date>
            <permissions>
                <copyright-statement>Copyright: &#x00a9; 2024 Kum HC</copyright-statement>
                <copyright-year>2024</copyright-year>
                <license xlink:href="https://creativecommons.org/licenses/by/4.0/">
                    <license-p>This is an open access peer review report distributed under the terms of the Creative Commons Attribution Licence, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
                </license>
            </permissions>
            <related-article ext-link-type="doi" id="relatedArticleReport36771" related-article-type="peer-reviewed-article" xlink:href="10.12688/gatesopenres.15418.1"/>
            <custom-meta-group>
                <custom-meta>
                    <meta-name>recommendation</meta-name>
                    <meta-value>approve-with-reservations</meta-value>
                </custom-meta>
            </custom-meta-group>
        </front-stub>
        <body>
            <p>This paper describes a python package that can simulate population data based on distributions of various individual and household characteristics in datasets released from the US census Bureau, with an explicit purpose for supporting and facilitating entity resolution (ER) algorithm and software development without accessing real confidential data. ER algorithms require access to personally identifiable information (PII) such as names, SSN, DOB making privacy a major concern in this type of research. Using simulated data, such as the one described in the paper is one approach to dealing with the privacy issues in ER. It relies on using the existing Vivarium simulation platform the same team developed, but attempts to incorporate some of the complexities of the ER problem with real data such as difficulties with twins.</p>
            <p> </p>
            <p> The paper is well written and easy to follow for the most part. Here are some questions/comments to consider for improvement.</p>
            <p> </p>
            <p> [Major comments] 
                <list list-type="bullet">
                    <list-item>
                        <p>Data errors (e.g., typos in names and dob, flipped first/last name in different systems) or variations (e.g., nicknames, change in last name due to marriage, Jr and Sr) are a common source of difficulties in ER using real data which does not seem to be modeled yet. Maybe at least mention it as important future work.</p>
                    </list-item>
                    <list-item>
                        <p>Similarly, duplicate records that exist in almost any real data make ER much more difficult because one cannot assume a one-to-one match unless the tables have been deduplicated first. One of the main difficulties in ER is that a duplicate record for one person cannot be mathematically differentiated from very similar records for 2 people such as twins, father/son, or even totally unrelated people (to date, I have met 2 people who told me after a ER talk that they know &#x201c;of&#x201d; this other person with the EXACT same first/last name and dob because they are in the same city and they have been confused before with the other person. Often it requires an explicit field stating that the person is a twin to be certain.</p>
                    </list-item>
                    <list-item>
                        <p>I highly recommend reading the following paper for ideas for future work to make the simulation more realistic for ER research as well as adding a limitation section to the current paper. Such a section would be very important for potential users to know what the simulated data does not cover, and may need to still consider in their ER algorithm. 
                            <list list-type="bullet">
                                <list-item>
                                    <p>Goth G. Running on EMPI. Health information exchanges and the ONC keep trying to find the secret sauce of patient matching. Health data management. 2014;22(2):52-, 4, 6 passim.</p>
                                </list-item>
                            </list> </p>
                    </list-item>
                    <list-item>
                        <p>Also, consider the following for the limitation section. It seems that this simulated data may be more supportive of ER algorithms that leverage structure (e.g., household structure or based on clustering) without a pair generation. However, many real world applications do not have much structure information to use, and may need to still consider pairwise ER algorithms. Complexities for this type of ER algorithms may not have been well modeled here (see point above).</p>
                    </list-item>
                    <list-item>
                        <p>A few sentences describing and talking about data governance/privacy concerns even for the simulated data in the introduction would be important. To my understanding, at a minimum a simulation of this scale may have simulatants that are too similar to real people, even if the data was all made up which may still give rise to privacy issues. It is very important that everyone becomes more educated on fundamental properties of information privacy. Such as, information privacy is not a binary property but rather a continuous concept that with every use, there is some level of disclosure/risk. There is no way to benefit from using data for social good/research with 0 risk. The more people understand this, the more constructive the conversations about the risk and benefits of using large datasets about people.</p>
                    </list-item>
                    <list-item>
                        <p>A small paragraph on the pros/cons of approaches to privacy protection (e.g., simulated data, perturbed data, using secure data enclaves for access to real data) for ER research will be helpful to frame the paper and better understand when to use the simulated population or other alternatives. Some papers on perturbed data or using data enclaves are below. 
                            <list list-type="bullet">
                                <list-item>
                                    <p>Ramezani M, Ilangovan G, Kum HC. Evaluation of machine learning algorithms in a human-computer hybrid record linkage system. In CEUR workshop proceedings 2021 Jan (Vol. 2846, No. 4).</p>
                                </list-item>
                                <list-item>
                                    <p>Ilangovan, Gurudev (2019). Benchmarking the Effectiveness and Efficiency of Machine Learning Algorithms for Record Linkage. Master's thesis, Texas A&amp;M University. Available electronically from 
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">https</ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390"> </ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">:</ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390"> </ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">/</ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390"> </ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">/hdl</ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390"> </ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">.handle</ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390"> </ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">.net</ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390"> </ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">/1969</ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390"> </ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">.1</ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390"> </ext-link>
                                        <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">/186390</ext-link>.</p>
                                </list-item>
                                <list-item>
                                    <p>P. Christen, &#x201c;Preparation of a real temporal voter data set for record linkage and duplicate detection research,&#x201d; 2013.</p>
                                </list-item>
                                <list-item>
                                    <p>Kum HC, Ahalt S. Privacy-by-design: Understanding data access models for secondary data. AMIA Summits on Translational Science Proceedings. 2013;2013:126.</p>
                                </list-item>
                            </list> </p>
                    </list-item>
                    <list-item>
                        <p>&#x201c;We select a random 4% of birth events to be the birth of twins (two newborn simulants), and same last name, address, and date of birth.&#x201d;: simulating multiple births is one of the key parts of making the simulated data useful for the intended purpose of ER. There is no reference to why 4%, it may be worth using a slightly higher percentage (see comment below). Also, twins often have even more similarity in my experience of real data (e.g., similar first name or same first letter in first name. SSN is only 1 digit off).&#x00a0; I am quoting from my published work in ER on this topic which includes a reference. &#x201c;The most difficult links to resolve involve twins. In this case, much of the identifying information is validly the same or very similar. Often, SSNs are only one digit off, and one system might have assigned the SSN in one way, while another system has it assigned in the other way. These types of data errors make it almost impossible to automatically resolve entities without human intervention. Multiple birth rates have been rising in the United States, with twin birth rates at 29.3 per 1,000 births in 2000 [Reynolds et. al. 2003]. That is approximately six twins in every 103 children born, not including triplets and higher-order births. These are substantial numbers that need to be considered when performing record linkage on people level data. In one system of education data that performs record linkage on a regular basis, we have seen a twin field being regularly collected to differentiate data errors from real twins.&#x201d; [Kum et. al. 2013] 
                            <list list-type="bullet">
                                <list-item>
                                    <p>Kum HC, Ahalt S, Pathak D. Privacy-preserving data integration using decoupled data. Springer New York; 2013.</p>
                                </list-item>
                                <list-item>
                                    <p>Reynolds MA, Schieve LA, Martin JA, Jeng G, Macaluso M (2003) Trends in multiple births conceived using assisted reproductive technology, United States, 19972000. Pediatrics 111 (Supp 1):1159&#x2013;1162</p>
                                </list-item>
                            </list> </p>
                    </list-item>
                    <list-item>
                        <p>Why is marriage or father not modeled in the births? Jr/Sr in the US naming culture do cause complexities in ER. So I am not sure I would agree with the stated hypothesis &#x201c;We hypothesize that this limitation in realistic naming will not lead to substantially harder or easier data for linkage. &#x201c;</p>
                    </list-item>
                    <list-item>
                        <p>&#x201c;In the event that model results did not meet verification and validation criteria, model implementation and/or design were iteratively adjusted appropriately until criteria were satisfied.&#x201d;: it would be helpful to have some sense of how often these adjustments were needed, and how much of an adjustment was needed. This would help readers judge how close or not the final simulated results were before the fine tuning.</p>
                    </list-item>
                    <list-item>
                        <p>&#x201c;Thus, as time passes within the simulation, the proportion of households with irregular relationship structures grows.&#x201d;: it is understandable that this is a limitation of this type of simulation, but a bit more explanation on issues such as the following would be useful.&#x00a0; (1) what are the issues related to this happening for ER; (2) how much is this a problem (e.g., rate of issues); and (3) limits on when the simulation should no longer be used due to this issue.</p>
                    </list-item>
                    <list-item>
                        <p>&#x201c;As with household physical and mailing addresses, when a business address is vacated, it is not reused. In effect, this likely makes business record linkage with these data easier than it will be in practice.&#x201d; It is unclear why the business address is not reused especially given this statement that for ER for businesses it may not be a good choice since this was supposed to target ER usage.</p>
                    </list-item>
                    <list-item>
                        <p>Also, how names for business were generated using graphs was confusing. Some concrete examples would be good to include.</p>
                    </list-item>
                    <list-item>
                        <p>Given that this is based on the Vivarium simulation platform, some brief explanation of what it is would be helpful. Either not refer to it, if readers do not need anything about it or explain a little something about what it is beyond that it was used so that the paper can be somewhat stand alone.</p>
                    </list-item>
                </list> [Clarification questions] 
                <list list-type="bullet">
                    <list-item>
                        <p>&#x201c;28-day time steps&#x201d;: is there a reason not to use 30 days=1 month? 28 days seems to be the smallest days in a month, but unclear why this is good to do. It would seem that 1 year would not model well in this way. 30 days=360 days in a year. Which may be better.</p>
                    </list-item>
                    <list-item>
                        <p>&#x201c;When perturbation led to a negative age value, we flipped the negative age value&#x2019;s sign&#x201d;. Why not just use a perturbation that would not give a negative value? It seems that flipping the negative value would not result in the target distribution.</p>
                    </list-item>
                    <list-item>
                        <p>&#x201c;change employment randomly at a rate of 50 changes per 100 person-years (a rate we selected subjectively to provide an appropriate challenge in record linkage)&#x201d;: It is unclear how employment is directly related to ER except maybe indirectly through change of address which in this particular simulation is tied to employment. Actually, it was unclear if employment change came before move, or the other way, or both. Also, unclear why this rate is appropriate. It maybe better to describe ER in terms of changes in address rather than employment. If not, a bit more clarity on how ER is related to employment would be helpful.</p>
                    </list-item>
                    <list-item>
                        <p>&#x201c;For instance, a child can move out of their household without a parent&#x201d;: I assume this means even an infant can move out on their own. If we consider child adoptions/foster care this may be fine. But move out rates for children under 18, and adults should be quite different. This does not seem too difficult to implement and may be important to consider. Or for simplicity, maybe adoptions are not modeled but an age cutoff is implemented.</p>
                    </list-item>
                </list>
            </p>
            <p>Are sufficient details of methods and materials provided to allow replication by others?</p>
            <p>Partly</p>
            <p>Is the rationale for creating the dataset(s) clearly described?</p>
            <p>Yes</p>
            <p>Are the datasets clearly presented in a useable and accessible format?</p>
            <p>Partly</p>
            <p>Are the protocols appropriate and is the work technically sound?</p>
            <p>Partly</p>
            <p>Reviewer Expertise:</p>
            <p>Entity Resolution; Perturbing data for entity resolution; Privacy issues in and entity resolution</p>
            <p>I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above.</p>
        </body>
        <sub-article article-type="response" id="comment3723-36771">
            <front-stub>
                <contrib-group>
                    <contrib contrib-type="author">
                        <name>
                            <surname>Flaxman</surname>
                            <given-names>Abraham</given-names>
                        </name>
                        <aff>University of Washington, Seattle, USA</aff>
                    </contrib>
                </contrib-group>
                <author-notes>
                    <fn fn-type="conflict">
                        <p>
                            <bold>Competing interests: </bold>No competing interests.</p>
                    </fn>
                </author-notes>
                <pub-date pub-type="epub">
                    <day>2</day>
                    <month>10</month>
                    <year>2024</year>
                </pub-date>
            </front-stub>
            <body>
                <p>
                    <bold>Comment:&#x00a0;</bold>This paper describes a python package that can simulate population data based on distributions of various individual and household characteristics in datasets released from the US census Bureau, with an explicit purpose for supporting and facilitating entity resolution (ER) algorithm and software development without accessing real confidential data. ER algorithms require access to personally identifiable information (PII) such as names, SSN, DOB making privacy a major concern in this type of research. Using simulated data, such as the one described in the paper is one approach to dealing with the privacy issues in ER. It relies on using the existing Vivarium simulation platform the same team developed, but attempts to incorporate some of the complexities of the ER problem with real data such as difficulties with twins.</p>
                <p> The paper is well written and easy to follow for the most part. Here are some questions/comments to consider for improvement.</p>
                <p> 
                    <italic>
                        <bold>Response:</bold> Thank you for this assessment, and for taking the time to offer this valuable feedback.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold>[Major comments] 
                    <list list-type="bullet">
                        <list-item>
                            <p>Data errors (e.g., typos in names and dob, flipped first/last name in different systems) or variations (e.g., nicknames, change in last name due to marriage, Jr and Sr) are a common source of difficulties in ER using real data which does not seem to be modeled yet. Maybe at least mention it as important future work.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>Thank you for calling attention to this. We have developed the pseudopeople Python package (</italic>
                    <ext-link ext-link-type="uri" xlink:href="https://pseudopeople.org/">
                        <italic>https://pseudopeople.org/</italic>
                    </ext-link>
                    <italic>) that includes additional affordances to add various kinds of noise to the simulated data described in this paper to afford a configurable amount of typos and other sources of error including some of those listed above, and we intend to add other noise such as the reviewer has identified in future updates to pseudopeople.&#x00a0; In this paper we hope to complement the pseudopeople documentation with a detailed description of the simulation process.</italic>
                </p>
                <p> 
                    <italic>As we continue to add additional realism to challenge ER algorithms, it will be an interesting challenge to balance what we can make a configurable add-on (like the rate of first/last name flipping) and what we need to include in the simulation itself (e.g. the marriage-related name changes might need to be simulated together with the marriages) and therefore may not be able to make easily configurable.&#x00a0; We have added text to the abstract and introduction to emphasize that this paper is focused on the simulation and not the data errors.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>Similarly, duplicate records that exist in almost any real data make ER much more difficult because one cannot assume a one-to-one match unless the tables have been deduplicated first. One of the main difficulties in ER is that a duplicate record for one person cannot be mathematically differentiated from very similar records for 2 people such as twins, father/son, or even totally unrelated people (to date, I have met 2 people who told me after a ER talk that they know &#x201c;of&#x201d; this other person with the EXACT same first/last name and dob because they are in the same city and they have been confused before with the other person. Often it requires an explicit field stating that the person is a twin to be certain.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>As with our previous comment, this is an important area that we hope to address in more detail in future work, and we appreciate the reviewer calling attention to some of the unique challenges here. In our next round of pseudopeople enhancements, we plan to add &#x201c;simple duplication&#x201d; as an additional configurable type of &#x201c;row_noise&#x201d;. More complex duplication, such as may be caused by individuals who are reported in two distinct households during a decennial census, is something we have a start on in our simulation already and hope to also enhance in future work.&#x00a0; Another area for enhancement that we did not think of until reading this comment is the prospect of including an explicit field stating that the person is a twin --- just such a field is present in the Washington State Drivers License database (and was repurposed to create a twin registry for scientific research in Washington).</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>I highly recommend reading the following paper for ideas for future work to make the simulation more realistic for ER research as well as adding a limitation section to the current paper. Such a section would be very important for potential users to know what the simulated data does not cover, and may need to still consider in their ER algorithm. 
                                <list list-type="bullet">
                                    <list-item>
                                        <p>Goth G. Running on EMPI. Health information exchanges and the ONC keep trying to find the secret sauce of patient matching. Health data management. 2014;22(2):52-, 4, 6 passim.</p>
                                    </list-item>
                                </list> </p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>Thank you for pointing out this reference, and we agree that there are additional future work and limitations that it identifies admirable.&#x00a0; We believe that many (e.g. appending title to surname, as in FLAXMANPHD) which will be worthy additions to pseudopeople, but we did not feel any were so relevant to our simulation as to merit specific additional to the limitations section of this paper.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>Also, consider the following for the limitation section. It seems that this simulated data may be more supportive of ER algorithms that leverage structure (e.g., household structure or based on clustering) without a pair generation. However, many real world applications do not have much structure information to use, and may need to still consider pairwise ER algorithms. Complexities for this type of ER algorithms may not have been well modeled here (see point above).</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>We appreciate the reviewer calling attention to the potential for using household structure in ER, which we agree is an underdeveloped avenue worthy of future research.&#x00a0; We agree that many real-world applications of ER will not be able to use such an approach, because it is not frequently available, and we hope that our sim and our python package will be a help in both developing novel methods and understanding when these methods are more or less applicable.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>A few sentences describing and talking about data governance/privacy concerns even for the simulated data in the introduction would be important. To my understanding, at a minimum a simulation of this scale may have simulatants that are too similar to real people, even if the data was all made up which may still give rise to privacy issues. It is very important that everyone becomes more educated on fundamental properties of information privacy. Such as, information privacy is not a binary property but rather a continuous concept that with every use, there is some level of disclosure/risk. There is no way to benefit from using data for social good/research with 0 risk. The more people understand this, the more constructive the conversations about the risk and benefits of using large datasets about people.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>Thank you for calling attention this important (and subtle) feature of simulated data of this scale. Both the generation and distribution of the dataset are governed by a system of &#x201c;relational governance&#x201d; which we developed for this simulated-but-realistic data together with the data ethicist Os Keyes. In Os&#x2019;s approach, data subjects play a central role; a paper on their approach to data governance is currently under preparation. We have added a sentence to this effect to the introduction section.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>A small paragraph on the pros/cons of approaches to privacy protection (e.g., simulated data, perturbed data, using secure data enclaves for access to real data) for ER research will be helpful to frame the paper and better understand when to use the simulated population or other alternatives. Some papers on perturbed data or using data enclaves are below. 
                                <list list-type="bullet">
                                    <list-item>
                                        <p>Ramezani M, Ilangovan G, Kum HC. Evaluation of machine learning algorithms in a human-computer hybrid record linkage system. In CEUR workshop proceedings 2021 Jan (Vol. 2846, No. 4).</p>
                                    </list-item>
                                    <list-item>
                                        <p>Ilangovan, Gurudev (2019). Benchmarking the Effectiveness and Efficiency of Machine Learning Algorithms for Record Linkage. Master's thesis, Texas A&amp;M University. Available electronically from&#x00a0;
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">https</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">&#x00a0;</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">:</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">&#x00a0;</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">/</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">&#x00a0;</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">/hdl</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">&#x00a0;</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">.handle</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">&#x00a0;</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">.net</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">&#x00a0;</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">/1969</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">&#x00a0;</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">.1</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">&#x00a0;</ext-link>
                                            <ext-link ext-link-type="uri" xlink:href="https://hdl.handle.net/1969.1/186390">/186390</ext-link>.</p>
                                    </list-item>
                                    <list-item>
                                        <p>P. Christen, &#x201c;Preparation of a real temporal voter data set for record linkage and duplicate detection research,&#x201d; 2013.</p>
                                    </list-item>
                                    <list-item>
                                        <p>Kum HC, Ahalt S. Privacy-by-design: Understanding data access models for secondary data. AMIA Summits on Translational Science Proceedings. 2013;2013:126.</p>
                                    </list-item>
                                </list> </p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>We appreciate the reviewer&#x2019;s suggestion and have added a sentence along these lines in the introduction. We will also consider all of these valuable references when framing and positioning our data governance approach in the paper that Os is currently working on.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>&#x201c;We select a random 4% of birth events to be the birth of twins (two newborn simulants), and same last name, address, and date of birth.&#x201d;: simulating multiple births is one of the key parts of making the simulated data useful for the intended purpose of ER. There is no reference to why 4%, it may be worth using a slightly higher percentage (see comment below). Also, twins often have even more similarity in my experience of real data (e.g., similar first name or same first letter in first name. SSN is only 1 digit off).&#x00a0; I am quoting from my published work in ER on this topic which includes a reference. &#x201c;The most difficult links to resolve involve twins. In this case, much of the identifying information is validly the same or very similar. Often, SSNs are only one digit off, and one system might have assigned the SSN in one way, while another system has it assigned in the other way. These types of data errors make it almost impossible to automatically resolve entities without human intervention. Multiple birth rates have been rising in the United States, with twin birth rates at 29.3 per 1,000 births in 2000 [Reynolds et. al. 2003]. That is approximately six twins in every 103 children born, not including triplets and higher-order births. These are substantial numbers that need to be considered when performing record linkage on people level data. In one system of education data that performs record linkage on a regular basis, we have seen a twin field being regularly collected to differentiate data errors from real twins.&#x201d; [Kum et. al. 2013] 
                                <list list-type="bullet">
                                    <list-item>
                                        <p>Kum HC, Ahalt S, Pathak D. Privacy-preserving data integration using decoupled data. Springer New York; 2013.</p>
                                    </list-item>
                                    <list-item>
                                        <p>Reynolds MA, Schieve LA, Martin JA, Jeng G, Macaluso M (2003) Trends in multiple births conceived using assisted reproductive technology, United States, 19972000. Pediatrics 111 (Supp 1):1159&#x2013;1162</p>
                                    </list-item>
                                </list> </p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>Thank you for these valuable references. We use 4% of births without a suitable data source, and plan to enhance this in future work. Fortunately, our ad hoc number is similar to the evidence you shared --- our 4% of births for 2020-2040 is not too much higher than the 3% found in 2000. Your identification of similar SSNs is another challenge that we should incorporate when enhancing our twin generation component.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>Why is marriage or father not modeled in the births? Jr/Sr in the US naming culture do cause complexities in ER. So I am not sure I would agree with the stated hypothesis &#x201c;We hypothesize that this limitation in realistic naming will not lead to substantially harder or easier data for linkage. &#x201c;</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>Good point, we did not consider the challenge of distinguishing between father and son with same names except for Jr and Sr suffixes.&#x00a0; We have removed this hypothesis, and in our next major update to our simulation, we hope to include fathers, as well as Jr/Sr naming practices.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>&#x201c;In the event that model results did not meet verification and validation criteria, model implementation and/or design were iteratively adjusted appropriately until criteria were satisfied.&#x201d;: it would be helpful to have some sense of how often these adjustments were needed, and how much of an adjustment was needed. This would help readers judge how close or not the final simulated results were before the fine tuning.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>This is a very reasonable request that is unfortunately very difficult to meet, due to a lack of careful information keeping.&#x00a0; We do have a complete revision history of the development of our model available publicly on GitHub, which (at the time I write this) shows </italic>
                    <ext-link ext-link-type="uri" xlink:href="https://github.com/ihmeuw/vivarium_census_prl_synth_pop/commits/main/">
                        <italic>640 code commits</italic>
                    </ext-link>
                    <italic> grouped into </italic>
                    <ext-link ext-link-type="uri" xlink:href="https://github.com/ihmeuw/vivarium_census_prl_synth_pop/pulls?q=is%3Apr">
                        <italic>359 pull requests</italic>
                    </ext-link>
                    <italic>, but we do not have a straightforward way to identify which of these were changes in response to verification and validation issues. In the future, I think we can easily incorporate a &#x201c;tagging&#x201d; approach to PRs to identify code changes from V&amp;V.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>&#x201c;Thus, as time passes within the simulation, the proportion of households with irregular relationship structures grows.&#x201d;: it is understandable that this is a limitation of this type of simulation, but a bit more explanation on issues such as the following would be useful.&#x00a0; (1) what are the issues related to this happening for ER; (2) how much is this a problem (e.g., rate of issues); and (3) limits on when the simulation should no longer be used due to this issue.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>We believe that this will not be an issue for most common approaches to ER, and will only be relevant for experimental approaches that use household structure as part of their linkage strategy. In the publicly available sample data, in the 2020 decennial census, 4% of rows have &#x201c;Other nonrelative&#x201d; as their relationship to the reference person.&#x00a0; In 2030, this rises to 16%, and in 2040, it is 20%. We plan to address this by adding more complex logic for relationship changes following migration in a future update. We have added a sentence about this to the limitations section.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>&#x201c;As with household physical and mailing addresses, when a business address is vacated, it is not reused. In effect, this likely makes business record linkage with these data easier than it will be in practice.&#x201d; It is unclear why the business address is not reused especially given this statement that for ER for businesses it may not be a good choice since this was supposed to target ER usage.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>This is a limitation that we plan to address in future update, and we agree with the reviewer that reusing business addresses will make this data more suitable for testing business linkage algorithms.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>Also, how names for business were generated using graphs was confusing. Some concrete examples would be good to include.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>Good idea, we have added a sentence with examples from the sample data distributed openly with the pseudopeople package.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>Given that this is based on the Vivarium simulation platform, some brief explanation of what it is would be helpful. Either not refer to it, if readers do not need anything about it or explain a little something about what it is beyond that it was used so that the paper can be somewhat stand alone.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>We feel that it is valuable to refer to the vivarium software that we used to implement this simulation and agree with the reviewer that it is important to include a brief explanation of what Vivarium is. Since we already attempted such an explanation in our original draft, we have revised it to include additional detail in the first paragraph of the methods section.&#x00a0; Perhaps the reviewer had some additional details in mind, however, and we welcome further feedback about how we can make this somewhat stand alone.</italic>
                </p>
                <p> [Clarification questions]</p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>&#x201c;28-day time steps&#x201d;: is there a reason not to use 30 days=1 month? 28 days seems to be the smallest days in a month, but unclear why this is good to do. It would seem that 1 year would not model well in this way. 30 days=360 days in a year. Which may be better.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>We prefer to work in units of days or weeks, since larger units of time like months and years have annoying variation in length.&#x00a0; So 28 days = 4 weeks is similar in length to one month, but always includes (for example) the same number of weekend days.&#x00a0; This is not particularly important for this simulation but can matter for simulations or data that included day-by-day variation.&#x00a0; We are confident that changing the timestep to 30 days would not lead to any difference in the difficulty of record linkage tasks with this simulated data.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>&#x201c;When perturbation led to a negative age value, we flipped the negative age value&#x2019;s sign&#x201d;. Why not just use a perturbation that would not give a negative value? It seems that flipping the negative value would not result in the target distribution.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>We prefer this approach to obtaining a truncated distribution that does not include an unexpectedly high density at zero (as truncation would) and does not shift the mean as much as a non-negative perturbation (like adding an exponentially distributed offset) would. It is developed in detail in Bernard W. Silverman, Density Estimation for Statistics and Data Analysis, 1986 (p. 30).</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>&#x201c;change employment randomly at a rate of 50 changes per 100 person-years (a rate we selected subjectively to provide an appropriate challenge in record linkage)&#x201d;: It is unclear how employment is directly related to ER except maybe indirectly through change of address which in this particular simulation is tied to employment. Actually, it was unclear if employment change came before move, or the other way, or both. Also, unclear why this rate is appropriate. It maybe better to describe ER in terms of changes in address rather than employment. If not, a bit more clarity on how ER is related to employment would be helpful.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>This particular ER challenge might be a bit niche, but it arises in systems like the US Census Bureau&#x2019;s Person Identification Validation System where a tax id is available in employment records. As the reviewer notes, changes in address represent an important challenge in this setting, but changes in employment when address does not change could potentially be a barrier to high-quality record linkage in this setting as well.</italic>
                </p>
                <p> </p>
                <p> 
                    <bold>Comment:&#x00a0;</bold> 
                    <list list-type="bullet">
                        <list-item>
                            <p>&#x201c;For instance, a child can move out of their household without a parent&#x201d;: I assume this means even an infant can move out on their own. If we consider child adoptions/foster care this may be fine. But move out rates for children under 18, and adults should be quite different. This does not seem too difficult to implement and may be important to consider. Or for simplicity, maybe adoptions are not modeled but an age cutoff is implemented.</p>
                        </list-item>
                    </list> 
                    <italic>
                        <bold>Response:&#x00a0;</bold>We do include some of this complexity in our current simulation, and as we write, &#x201c;We modeled domestic migration events as happening at a rate determined by age, sex, and race/ethnicity&#x201d;, but we also want to note that surprising or even illogical household composition can arise from the limited approach we have taken.&#x00a0; We hope to increase the realism of these dynamics in the future.</italic>
                </p>
            </body>
        </sub-article>
    </sub-article>
</article>
