<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.0 20040830//EN" "http://dtd.nlm.nih.gov/publishing/2.0/journalpublishing.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" article-type="research-article" dtd-version="2.0">
  <front>
    <journal-meta>
      <journal-id journal-id-type="publisher-id">JMIR</journal-id>
      <journal-id journal-id-type="nlm-ta">J Med Internet Res</journal-id>
      <journal-title>Journal of Medical Internet Research</journal-title>
      <issn pub-type="epub">1438-8871</issn>
      <publisher>
        <publisher-name>JMIR Publications</publisher-name>
        <publisher-loc>Toronto, Canada</publisher-loc>
      </publisher>
    </journal-meta>
    <article-meta>
      <article-id pub-id-type="publisher-id">v23i8e25670</article-id>
      <article-id pub-id-type="pmid">34346903</article-id>
      <article-id pub-id-type="doi">10.2196/25670</article-id>
      <article-categories>
        <subj-group subj-group-type="heading">
          <subject>Original Paper</subject>
        </subj-group>
        <subj-group subj-group-type="article-type">
          <subject>Original Paper</subject>
        </subj-group>
      </article-categories>
      <title-group>
        <article-title>Construction of Genealogical Knowledge Graphs From Obituaries: Multitask Neural Network Extraction System</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="editor">
          <name>
            <surname>Kukafka</surname>
            <given-names>Rita</given-names>
          </name>
        </contrib>
      </contrib-group>
      <contrib-group>
        <contrib contrib-type="reviewer">
          <name>
            <surname>Ben-Miled</surname>
            <given-names>Zina</given-names>
          </name>
        </contrib>
        <contrib contrib-type="reviewer">
          <name>
            <surname>Salmasian</surname>
            <given-names>Hojjat</given-names>
          </name>
        </contrib>
        <contrib contrib-type="reviewer">
          <name>
            <surname>Torii</surname>
            <given-names>Manabu</given-names>
          </name>
        </contrib>
      </contrib-group>
      <contrib-group>
        <contrib id="contrib1" contrib-type="author" equal-contrib="yes">
          <name name-style="western">
            <surname>He</surname>
            <given-names>Kai</given-names>
          </name>
          <degrees>PhD</degrees>
          <xref rid="aff1" ref-type="aff">1</xref>
          <xref rid="aff2" ref-type="aff">2</xref>
          <xref rid="aff3" ref-type="aff">3</xref>
          <ext-link ext-link-type="orcid">https://orcid.org/0000-0003-2639-1532</ext-link>
        </contrib>
        <contrib id="contrib2" contrib-type="author" equal-contrib="yes">
          <name name-style="western">
            <surname>Yao</surname>
            <given-names>Lixia</given-names>
          </name>
          <degrees>PhD</degrees>
          <xref rid="aff4" ref-type="aff">4</xref>
          <ext-link ext-link-type="orcid">https://orcid.org/0000-0002-5187-6120</ext-link>
        </contrib>
        <contrib id="contrib3" contrib-type="author">
          <name name-style="western">
            <surname>Zhang</surname>
            <given-names>JiaWei</given-names>
          </name>
          <degrees>MSc</degrees>
          <xref rid="aff1" ref-type="aff">1</xref>
          <xref rid="aff2" ref-type="aff">2</xref>
          <xref rid="aff3" ref-type="aff">3</xref>
          <ext-link ext-link-type="orcid">https://orcid.org/0000-0003-4057-9400</ext-link>
        </contrib>
        <contrib id="contrib4" contrib-type="author">
          <name name-style="western">
            <surname>Li</surname>
            <given-names>Yufei</given-names>
          </name>
          <degrees>PhD</degrees>
          <xref rid="aff1" ref-type="aff">1</xref>
          <xref rid="aff2" ref-type="aff">2</xref>
          <xref rid="aff3" ref-type="aff">3</xref>
          <ext-link ext-link-type="orcid">https://orcid.org/0000-0001-5207-5336</ext-link>
        </contrib>
        <contrib id="contrib5" contrib-type="author" corresp="yes">
          <name name-style="western">
            <surname>Li</surname>
            <given-names>Chen</given-names>
          </name>
          <degrees>PhD</degrees>
          <xref rid="aff1" ref-type="aff">1</xref>
          <address>
            <institution>School of Computer Science and Technology</institution>
            <institution>Xi’an Jiaotong University</institution>
            <addr-line>Xianning West Road, 27th</addr-line>
            <addr-line>Xi’an, 0086 710049</addr-line>
            <country>China</country>
            <phone>86 158 0290 2703</phone>
            <email>cli@xjtu.edu.cn</email>
          </address>
          <xref rid="aff2" ref-type="aff">2</xref>
          <xref rid="aff3" ref-type="aff">3</xref>
          <ext-link ext-link-type="orcid">https://orcid.org/0000-0002-0079-3106</ext-link>
        </contrib>
      </contrib-group>
      <aff id="aff1">
        <label>1</label>
        <institution>School of Computer Science and Technology</institution>
        <institution>Xi’an Jiaotong University</institution>
        <addr-line>Xi’an</addr-line>
        <country>China</country>
      </aff>
      <aff id="aff2">
        <label>2</label>
        <institution>National Engineering Lab for Big Data Analytics</institution>
        <institution>Xi’an Jiaotong University</institution>
        <addr-line>Xi’an</addr-line>
        <country>China</country>
      </aff>
      <aff id="aff3">
        <label>3</label>
        <institution>Shanxi Province Key Laboratory of Satellite and Terrestrial Network Technology Research and Development</institution>
        <addr-line>Xian</addr-line>
        <country>China</country>
      </aff>
      <aff id="aff4">
        <label>4</label>
        <institution>Department of Health Sciences Research</institution>
        <institution>Mayo Clinic</institution>
        <addr-line>Rochester, MN</addr-line>
        <country>United States</country>
      </aff>
      <author-notes>
        <corresp>Corresponding Author: Chen Li <email>cli@xjtu.edu.cn</email></corresp>
      </author-notes>
      <pub-date pub-type="collection">
        <month>8</month>
        <year>2021</year>
      </pub-date>
      <pub-date pub-type="epub">
        <day>4</day>
        <month>8</month>
        <year>2021</year>
      </pub-date>
      <volume>23</volume>
      <issue>8</issue>
      <elocation-id>e25670</elocation-id>
      <history>
        <date date-type="received">
          <day>11</day>
          <month>11</month>
          <year>2020</year>
        </date>
        <date date-type="rev-request">
          <day>15</day>
          <month>12</month>
          <year>2020</year>
        </date>
        <date date-type="rev-recd">
          <day>26</day>
          <month>1</month>
          <year>2021</year>
        </date>
        <date date-type="accepted">
          <day>21</day>
          <month>6</month>
          <year>2021</year>
        </date>
      </history>
      <copyright-statement>©Kai He, Lixia Yao, JiaWei Zhang, Yufei Li, Chen Li. Originally published in the Journal of Medical Internet Research (https://www.jmir.org), 04.08.2021.</copyright-statement>
      <copyright-year>2021</copyright-year>
      <license license-type="open-access" xlink:href="https://creativecommons.org/licenses/by/4.0/">
        <p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in the Journal of Medical Internet Research, is properly cited. The complete bibliographic information, a link to the original publication on https://www.jmir.org/, as well as this copyright and license information must be included.</p>
      </license>
      <self-uri xlink:href="https://www.jmir.org/2021/8/e25670" xlink:type="simple"/>
      <abstract>
        <sec sec-type="background">
          <title>Background</title>
          <p>Genealogical information, such as that found in family trees, is imperative for biomedical research such as disease heritability and risk prediction. Researchers have used policyholder and their dependent information in medical claims data and emergency contacts in electronic health records (EHRs) to infer family relationships at a large scale. We have previously demonstrated that online obituaries can be a novel data source for building more complete and accurate family trees.</p>
        </sec>
        <sec sec-type="objective">
          <title>Objective</title>
          <p>Aiming at supplementing EHR data with family relationships for biomedical research, we built an end-to-end information extraction system using a multitask-based artificial neural network model to construct genealogical knowledge graphs (GKGs) from online obituaries. GKGs are enriched family trees with detailed information including age, gender, death and birth dates, and residence.</p>
        </sec>
        <sec sec-type="methods">
          <title>Methods</title>
          <p>Built on a predefined family relationship map consisting of 4 types of entities (eg, people’s name, residence, birth date, and death date) and 71 types of relationships, we curated a corpus containing 1700 online obituaries from the metropolitan area of Minneapolis and St Paul in Minnesota. We also adopted data augmentation technology to generate additional synthetic data to alleviate the issue of data scarcity for rare family relationships. A multitask-based artificial neural network model was then built to simultaneously detect names, extract relationships between them, and assign attributes (eg, birth dates and death dates, residence, age, and gender) to each individual. In the end, we assemble related GKGs into larger ones by identifying people appearing in multiple obituaries.</p>
        </sec>
        <sec sec-type="results">
          <title>Results</title>
          <p>Our system achieved satisfying precision (94.79%), recall (91.45%), and F-1 measures (93.09%) on 10-fold cross-validation. We also constructed 12,407 GKGs, with the largest one made up of 4 generations and 30 people.</p>
        </sec>
        <sec sec-type="conclusions">
          <title>Conclusions</title>
          <p>In this work, we discussed the meaning of GKGs for biomedical research, presented a new version of a corpus with a predefined family relationship map and augmented training data, and proposed a multitask deep neural system to construct and assemble GKGs. The results show our system can extract and demonstrate the potential of enriching EHR data for more genetic research. We share the source codes and system with the entire scientific community on GitHub without the corpus for privacy protection.</p>
        </sec>
      </abstract>
      <kwd-group>
        <kwd>genealogical knowledge graph</kwd>
        <kwd>EHR</kwd>
        <kwd>information extraction</kwd>
        <kwd>genealogy</kwd>
        <kwd>neural network</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec sec-type="introduction">
      <title>Introduction</title>
      <p>Anthropologists often use oral interviews, historical records, genetic analysis, and other means to obtain genealogical information and draw family trees. When combined with a detailed medical history and social and economic relationships, family trees are considered the x-ray of the family and have been used by clinicians to assess disease risk, suggest treatments, recommend changes in diet and other lifestyle habits, and determine a diagnosis. In the United States, the Medicare Access and CHIP Reauthorization Act of 2015 [<xref ref-type="bibr" rid="ref1">1</xref>] and Meaningful Use program [<xref ref-type="bibr" rid="ref2">2</xref>] have incentivized the growing adoption of electronic health records (EHR) with the goal to improve the quality of health care delivery systems. Consequently, a vast amount of EHR data has become available for research purposes in the past decade. However, most EHR systems today do not capture the family relationships between patients by design. Nor do they capture the death information unless patients die in the health care system or the EHR system is linked to external death registries. Constructing family trees for patients becomes an urgent need to unlock the full potential of EHR data in understanding disease and trait heritability, evaluating individuals’ health risks, and exploring environmental effects on human health.</p>
      <p>Early exploratory works have combined EHR data and family trees for biomedical research. For instance, Mayer et al [<xref ref-type="bibr" rid="ref3">3</xref>] used twin or multiple relationships to assess the concordance rates for muscular dystrophy and fragile X syndrome in the twin cohort. Schalkwyk et al [<xref ref-type="bibr" rid="ref4">4</xref>] conducted interviews with family members to build 3-generation family trees with medical chronologies and demonstrated their use in deciding the services required for the psychological well-being of all family members. Wang et al [<xref ref-type="bibr" rid="ref5">5</xref>] combined diagnosis codes and dependent coverage under medical plans to estimate the heritability and familial environmental patterns of 149 diseases and inferred the genetic and environmental correlations between 29 complex diseases [<xref ref-type="bibr" rid="ref5">5</xref>]. Similarly, Polubriaginof et al [<xref ref-type="bibr" rid="ref6">6</xref>] built more than 595,000 family trees from emergency contact information in a large EHR system and then estimated the heritability of 500 traits.</p>
      <p>Constructing high-quality large family trees has been challenging. Historically, only famous politicians, philosophers, scientists, religious groups, or royal families were tracked elaborately by genealogists. For such reason, large databases of family trees rarely existed, despite their research value. Recently, a few studies automated family tree collection using innovative informatics approaches. For instance, Mayer and colleagues [<xref ref-type="bibr" rid="ref3">3</xref>] used shared dates of birth and last names, in addition to home addresses, billing accounts, and keywords of “twin” and “triplet” in unstructured clinical notes to identify a cohort of 19,226 twins or multiples in an extensive health care delivery system. Wang et al [<xref ref-type="bibr" rid="ref5">5</xref>] inferred 128,989 nuclear families from a large medical claims database covering one-third of the US population based on dependent coverage. Polubriaginof et al [<xref ref-type="bibr" rid="ref6">6</xref>] used the emergency contact information of 3,550,598 patients from three large EHR systems in New York City to build 595,000 pedigrees. However, these indirect sources, like dependent coverage and emergency contact, have inherent limitations for inferring genealogical information: they do not differentiate biological from nonbiological relationships and they cover only limited types and numbers of family relationships. More specifically, medical insurance in the United States is limited to a beneficiary’s spouse and dependents up to age 26 years. Most patients only provided one or two emergency contacts rather than their whole families in their medical records. Missing relationships could be substantial.</p>
      <p>Inspired by the work of Tourassi et al [<xref ref-type="bibr" rid="ref7">7</xref>] and Yoon et al [<xref ref-type="bibr" rid="ref8">8</xref>], we began to explore online obituaries as a novel data source for the automatic extraction of genealogical information. Obituaries generally cover many more family members with more detailed and accurate descriptions of their family relationships. Nowadays, local newspaper and funeral service companies often publish obituaries on internet, making the cost of obtaining obituaries minimal. In our previous work, we developed and evaluated a new method of name entity recognition (NER) for extracting family members’ names and relation classifications (RCs) for classing the pairs of names among family members mentioned in online obituaries [<xref ref-type="bibr" rid="ref9">9</xref>]. In this work, we advanced our previous work in the following 5 aspects: (1) for the NER task, we processed more entity types, including people’s name, age, residence, and dates of birth and death; (2) for RC, we also matched residence entity and related people (in the previous work, we only extracted the family relationships among people entity); (3) we parsed two kinds of special language patterns in obituaries, last name distributive and name with parentheses; (4) all the triplets of family relationships were integrated to build the enriched family trees with additional rule-based inference; and (5) in terms of training data, we normalized the family relationships (see details in Data section).</p>
      <p>Traditionally, NER and RC were considered two separate tasks for information extraction. NER sought to extract named entities mentioned in unstructured text into predefined categories, whereas RC classified the relations between those extracted entity mentions. Researchers built natural language processing (NLP) pipelines with multiple modules to accomplish specific tasks. However, such modular separation suffered from 3 major issues leading to suboptimal results: (1) errors from the NER propagated to RC, (2) it was computationally redundant and time-consuming as the system had to pair up every two named entities to classify their relations, and (3) the pipeline model could not take full advantage of the knowledge inhabitant in the relationships of 2 or more named entities. For instance, if the system detected a <italic>live in</italic> relationship between two named entities in obituaries, the first entity is likely to be a person’s name and the second entity is likely to be a location.</p>
      <p>Thus, we look at multitask models that can simultaneously handle multiple related tasks and optimize their learning abilities by sharing the knowledge learned in all or some of the tasks [<xref ref-type="bibr" rid="ref10">10</xref>]. In 2008, Collobert [<xref ref-type="bibr" rid="ref11">11</xref>] introduced a single neural network architecture that solved NLP tasks such as part-of-speech tagging, chunking, named entity recognition, semantic role identification, and semantically similar word grouping using one language model. Recently, there are 3 prevailing solutions for multitask NLP models. The most popular solution establishes a common neural network presentation space for all tasks followed by task-specific classifiers [<xref ref-type="bibr" rid="ref12">12</xref>,<xref ref-type="bibr" rid="ref13">13</xref>]. The second proposes novel neural network architecture for multiple tasks. Sun et al [<xref ref-type="bibr" rid="ref14">14</xref>] used graph convolutional networks to enhance interaction between entity and relation. Bhatia et al [<xref ref-type="bibr" rid="ref15">15</xref>] proposed a hierarchical encoder-decoder NER model and adopt a shared encoder followed by separate decoders for NER and RC tasks. The third focuses on customized tagging schema. For instance, Zheng et al [<xref ref-type="bibr" rid="ref16">16</xref>] proposed a novel tagging schema for long short-term memory (LSTM) models that simultaneously identified named entities and extracted relationships in a corpus of New York Times news. In addition, Dixit et al [<xref ref-type="bibr" rid="ref17">17</xref>] introduced a span-level solution to handle NER and RC together. Zheng et al [<xref ref-type="bibr" rid="ref18">18</xref>] introduced a hierarchical solution that combines an encoder-decoder LSTM module for NER with a convolution neural network for RC.</p>
      <p>In this work, we first updated our annotated corpus by defining a family relationship map to normalize various family relations (see details in Data section). We also used data augmentation technology to generate more synthetic data (sentences), in order to address the imbalanced training data issue and boost the performance on rare classes [<xref ref-type="bibr" rid="ref19">19</xref>]. After that, we proposed an end-to-end information extraction system based on a multitasking solution. The end-to-end system included a knowledge inference layer for gender inference based on name and relationship mentioning. In the end, we constructed family trees centered on the deceased. These family trees contained many family members with detailed information, including age, gender, death date, birth date, and residence. We named such enriched family trees genealogical knowledge graphs (GKGs). These GKGs could be linked to external EHR data in Minnesota by personally identifiable information (PII), in a similar way as Sauver et al [<xref ref-type="bibr" rid="ref20">20</xref>] did. We empirically estimated the upper bound of the mapping precision could be around 80% to 90%. It would significantly enhance the power of EHR data to study disease and trait heritability, evaluate an individual’s health risks, and explore environmental effects on the human health.</p>
    </sec>
    <sec sec-type="methods">
      <title>Methods</title>
      <sec>
        <title>Data</title>
        <p>We collected 12,407 obituaries published from October 2008 to September 2018 from 3 funeral services websites and 1 local newspaper in the Twin Cities area, metropolitan Minneapolis–Saint Paul. Our data sources were limited to openly available obituaries. Considering the PII embedded in online obituaries, we decided to take a cautious and conservative position in our work by marking up the last name of any real people with the symbol XX (see more details on privacy protection in the Discussion section). After data cleaning, we randomly sampled 1700 obituaries for annotation. We developed the annotation guideline and trained 3 annotators to annotate each of the 1700 obituaries independently. The interannotator agreement measured by F-1 was 82.80% [<xref ref-type="bibr" rid="ref9">9</xref>]. <xref ref-type="table" rid="table1">Table 1</xref> shows the summary statistics of the annotated corpus. There were two unique language patterns in obituaries, namely last name distributive and name with parentheses (see <xref ref-type="table" rid="table2">Table 2</xref> for examples). These patterns might be due to the word limitation when the family paid for publishing an obituary in printed newspapers. They required special treatment, as described in the next session of end-to-end system.</p>
        <table-wrap position="float" id="table1">
          <label>Table 1</label>
          <caption>
            <p>Summary statistics of the annotated corpus.<sup>a</sup></p>
          </caption>
          <table width="1000" cellpadding="5" cellspacing="0" border="1" rules="groups" frame="hsides">
            <col width="290"/>
            <col width="100"/>
            <col width="170"/>
            <col width="120"/>
            <col width="200"/>
            <col width="120"/>
            <thead>
              <tr valign="top">
                <td>Corpus</td>
                <td>Count</td>
                <td>Deceased person</td>
                <td>Count</td>
                <td>Special language patterns</td>
                <td>Count</td>
              </tr>
            </thead>
            <tbody>
              <tr valign="top">
                <td>Sentences</td>
                <td>28,317</td>
                <td>Full name</td>
                <td>1551</td>
                <td>Last name distributive</td>
                <td>4954</td>
              </tr>
              <tr valign="top">
                <td>Names</td>
                <td>27,108</td>
                <td>Age</td>
                <td>1379</td>
                <td>Name with parentheses</td>
                <td>7504</td>
              </tr>
              <tr valign="top">
                <td>Family relationship</td>
                <td>25,557</td>
                <td>Death date</td>
                <td>1557</td>
                <td>Spouse’s name</td>
                <td>5993</td>
              </tr>
              <tr valign="top">
                <td>Residence</td>
                <td>7161</td>
                <td>Birth date</td>
                <td>1368</td>
                <td>Previous last name</td>
                <td>1511</td>
              </tr>
              <tr valign="bottom">
                <td>Name-residence pair</td>
                <td>7954</td>
                <td>—<sup>b</sup></td>
                <td>—</td>
                <td>—</td>
                <td>—</td>
              </tr>
            </tbody>
          </table>
          <table-wrap-foot>
            <fn id="table1fn1">
              <p><sup>a</sup>All counts are the number of occurrences except for the full name of the deceased. Considering all obituaries have structured metadata giving the full names of the deceased more precisely, we only annotate and extract the first-time mention of a full name of the deceased in an obituary. Spouse’s name and previous last name are 2 categories in the content name with parentheses.</p>
            </fn>
            <fn id="table1fn2">
              <p><sup>b</sup>Not applicable.</p>
            </fn>
          </table-wrap-foot>
        </table-wrap>
        <table-wrap position="float" id="table2">
          <label>Table 2</label>
          <caption>
            <p>Examples of unique language patterns in obituaries.</p>
          </caption>
          <table width="1000" cellpadding="5" cellspacing="0" border="1" rules="groups" frame="hsides">
            <col width="30"/>
            <col width="170"/>
            <col width="400"/>
            <col width="400"/>
            <thead>
              <tr valign="top">
                <td colspan="2">Language pattern</td>
                <td>Example</td>
                <td>Explanation</td>
              </tr>
            </thead>
            <tbody>
              <tr valign="top">
                <td colspan="2">Last name distributive</td>
                <td>He is survived by grandsons Addison and Owen XX.</td>
                <td>XX is also the last name for Addison.</td>
              </tr>
              <tr valign="top">
                <td colspan="4">
                  <bold>Names with parentheses</bold>
                </td>
              </tr>
              <tr valign="top">
                <td>
                  <break/>
                </td>
                <td>Previous last name</td>
                <td>Anne was born March 20, 1952, to William and Isabel (Starr) XX.</td>
                <td>Starr is the maiden name for Isabel XX.</td>
              </tr>
              <tr valign="top">
                <td>
                  <break/>
                </td>
                <td>Spouse’s name</td>
                <td>Survived by her sons, Dale (Mary) and Bruce (Diana).</td>
                <td>Dale’s wife is Mary, and Bruce’s wife is Diana.</td>
              </tr>
            </tbody>
          </table>
        </table-wrap>
        <p>In this work, we made two improvements in the corpus annotations. First, we created a family relationship map that normalized various family relationship mentions to 71 family relationship groups. For example, there were many mentions of “born to (name),” “daughter of (name),” and “son of (name)” in obituaries, which were equivalent to express the parent of the deceased. We grouped them into the “parent” relation. Similarly, we treated “married to” the same way as the “spouse (of)” relation. <xref rid="figure1" ref-type="fig">Figure 1</xref> shows the family relationship map, consisting of 8 generations and 71 normalized family relationships. The numbers in parentheses were the number of occurrences of a specific family relationship in our corpus.</p>
        <fig id="figure1" position="float">
          <label>Figure 1</label>
          <caption>
            <p>Family relationship map in the obituary corpus.</p>
          </caption>
          <graphic xlink:href="jmir_v23i8e25670_fig1.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
        </fig>
        <p>It was observed that some family relationships, such as granduncle, uncle-in-law, and half-sister had small numbers of cases that was not sufficient to train a high-performance neural network model. Therefore, we used data augmentation technology [<xref ref-type="bibr" rid="ref19">19</xref>] to expand the corpus and alleviate the imbalanced data issue. We first introduced <italic>w<sub>i</sub></italic>, the weight of relation <italic>i</italic>:</p>
        <disp-formula>
          <graphic xlink:href="jmir_v23i8e25670_fig8.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
        </disp-formula>
        <p>Where <italic>c<sub>i</sub></italic> stood for the count of annotated sentences with relation <italic>i</italic>, and <italic>n</italic> was 71, the count of all family relationship groups defined in the family relationship map. For each family relationship <italic>i</italic>, the number of training sentences to be generated, <italic>g<sub>i</sub></italic><sub>,</sub> was computed as follows:</p>
        <disp-formula>
          <graphic xlink:href="jmir_v23i8e25670_fig9.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
        </disp-formula>
        <p>Where <italic>N</italic> was the total number of all human annotated sentences and 𝛼 was the user-defined ratio for data augmentation. Essentially we generated more synthetic sentences to ensure each family relationship had no less than 200 examples, with the constraint that the count ratios of all family relationships remain as close as possible to those in the original training data.</p>
        <p>After deciding <italic>g<sub>i</sub></italic>, 2 steps were performed to generate extra sentences. First, we randomly chose <italic>g<sub>i</sub></italic> sentences from the raw corpus and replaced one of the raw family relationship tokens in these sentences with relationship word <italic>i</italic>. Second, we randomly chose one of the following operations introduced by Wei and Zou [<xref ref-type="bibr" rid="ref19">19</xref>] to generate the final augmented sentences:</p>
        <list list-type="bullet">
          <list-item>
            <p>Synonym replacement: randomly replace <italic>n</italic> non–stop words with their synonyms in the sentence</p>
          </list-item>
          <list-item>
            <p>Random insertion: randomly insert a word’s synonym before or after the chosen non–stop word in the sentence</p>
          </list-item>
          <list-item>
            <p>Random swap: randomly swap 2 non–stop words in the sentence</p>
          </list-item>
          <list-item>
            <p>Random deletion: randomly remove a non–stop word in the sentence</p>
          </list-item>
        </list>
        <p>The 4 entity types of interest in this work, name, residence, birth date and death date, are exempt from the changes. It should also be noted that the generated sentences could not be guaranteed to be grammatically and semantically correct. However, for neural network models, such sentences, when created with appropriate <italic>α</italic>, were demonstrated to improve models’ generalizability as noisy training data.</p>
      </sec>
      <sec>
        <title>End-to-End System</title>
        <p><xref rid="figure2" ref-type="fig">Figure 2</xref> illustrates our end-to-end system. It took a list of segmented sentences in an obituary as the input and generated a GKG centered around a deceased person. Its core was a multitask system that combined common parameter sharing across different modules and custom tagging schemes. The multitask solution promised better performance, as it used more supervision information and understood data from different views [<xref ref-type="bibr" rid="ref21">21</xref>]. The 4 modules were (1) named entity recognition and relation classification through a joint training model and customized tagging scheme, (2) matching locations to people’s name, (3) a parser for resolving last name distributive, and (4) a parser for resolving names with parentheses. These 4 modules shared the same model parameters, as they were trained jointly using one common weighted loss function. Among these modules, module 2 needed the extracted names and locations from module 1 as inputs. Module 5 was added as an independent rule-based layer for gender inference and age, date of death, and birth inference. Eventually, the results of these modules were combined to construct the GKGs.</p>
        <fig id="figure2" position="float">
          <label>Figure 2</label>
          <caption>
            <p>End-to-end extraction system to parse obituaries and generate genealogical knowledge graphs.</p>
          </caption>
          <graphic xlink:href="jmir_v23i8e25670_fig2.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
        </fig>
        <sec>
          <title>Module 1: Joint NER and RC</title>
          <p>This module aimed to extract family members’ names, relationships, and additional attributes of people (residence, age, death date, birth date). Gender was usually not explicitly mentioned in the obituaries, so we inferred the gender in module 5. We adopted a customized tagging scheme (shown in <xref rid="figure3" ref-type="fig">Figure 3</xref>) when annotating the training data. Each tag consisted of 2 parts. The first part indicated the type of an entity, and the second part illustrated the position of the word in the entity. As shown in <xref rid="figure3" ref-type="fig">Figure 3</xref>, “sister_B,” “sister_I,” “sister_E,” and “Age_S” indicated the beginning, the inside, and the end of a sister entity and a single-word entity of age, respectively. In the system, the deceased was the default baseline entity for all family relationship triplets. In the sentence shown in <xref rid="figure3" ref-type="fig">Figure 3</xref>, for example, “Robert” was the name of the deceased person (we knew it from the obituary metadata and the context of the entire obituary). After annotation, we obtained three triplets (Robert, sister, Eva Katherine XX), (Robert, brother, Stanley), and (Robert, brother, Terry XX). The calculating process was as follows:</p>
          <disp-formula>
            <graphic xlink:href="jmir_v23i8e25670_fig10.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
          </disp-formula>
          <p>For each input token <italic>x<sub>i</sub></italic>, we used BERT [<xref ref-type="bibr" rid="ref22">22</xref>] as a common encoder to obtain each hidden representation <italic>h<sub>i</sub><sup>common</sup></italic>. Then <italic>h<sub>i</sub><sup>common</sup></italic> were sent into one LSTM classifier to obtain each tag <italic>T<sub>1i</sub></italic> ∈ <italic>T</italic><sub>1</sub>, where <italic>T<sub>1</sub></italic> was the result set of module 1, and <italic>w<sub>1</sub></italic> and <italic>b<sub>1</sub></italic> were parameters for training.</p>
          <fig id="figure3" position="float">
            <label>Figure 3</label>
            <caption>
              <p>Tagging scheme for simultaneously extracting entities and kinship. S: single; B: begin; I: inside; E: end.</p>
            </caption>
            <graphic xlink:href="jmir_v23i8e25670_fig3.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
          </fig>
        </sec>
        <sec>
          <title>Module 2: Matching Locations to People</title>
          <p>After identifying the residence entities (eg, Rochester in <xref rid="figure3" ref-type="fig">Figure 3</xref>), we need to match them with specific people. To do so, we used 3 inputs, all extracted names <italic>T</italic><sub>1</sub><sup>name</sup> ∈ <italic>T</italic><sub>1</sub>, all extracted residences <italic>T</italic><sub>1</sub><sup>residence</sup> ∈ <italic>T</italic><sub>1</sub>, and common representation <italic>h<sub>i</sub><sup>common</sup></italic>. This module followed by a co-reference solution [<xref ref-type="bibr" rid="ref23">23</xref>]. We defined the process as follows:</p>
          <graphic xlink:href="jmir_v23i8e25670_fig11.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
          <p>where <italic>v</italic><sub>1i</sub><italic><sup>name</sup></italic> denoted the vector of one name entity <italic>t</italic><sub>1</sub><italic><sub>i</sub></italic><sup>name</sup> ∈ <italic>T</italic><sub>1</sub><italic><sup>name</sup></italic>, <italic>v</italic><sub>1</sub><italic><sub>j</sub><sup>residence</sup></italic> denoted the vector of one residence entity <italic>t</italic><sub>1</sub><italic><sub>j</sub></italic><sup>residence</sup> ∈ <italic>T</italic><sub>1</sub><italic><sup>residence</sup></italic>, [] denoted concatenate, * denoted dot product, <italic>w<sub>2</sub></italic> and <italic>b<sub>2</sub></italic> were one linear layer parameters for training, <italic>T</italic><sub>2k</sub> ∈ <italic>T</italic><sub>2</sub> was the matching result for each pair of name and residence, and <italic>T<sub>2</sub></italic> was the final selected pair of name and residence.</p>
        </sec>
        <sec>
          <title>Module 3: Judging Last Name Distributive</title>
          <p>We identified 2 special language patterns in obituaries, last name distributive and names with parentheses, as shown in <xref ref-type="table" rid="table2">Table 2</xref>. Resolving these language patterns was helpful for extracting and constructing high-quality GKGs. The task of module 3 was to decide for each token in an input sentence if the last name distributive existed by assigning each token with a binary tag of yes OR no. When we cotrained module 3 with other modules, these tags would concatenate with other modules’ tags for joint training. In the sentence in <xref rid="figure3" ref-type="fig">Figure 3</xref>, for example, “Stanley” and “Terry” shared the same last name of “Johnson.” Therefore, in module 3, “Stanley” was assigned a label “brother_S_yes” and “Terry Johnson” was given 2 tags “brother_B_yes” and “brother_E_yes.” This way, the module would extract 2 full names, <italic>Stanley Johnson</italic> and <italic>Terry Johnson</italic>, instead of <italic>Stanley</italic> and <italic>Terry Johnson</italic>. The detailed computing process was as follows:</p>
          <disp-formula>
            <graphic xlink:href="jmir_v23i8e25670_fig12.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
          </disp-formula>
          <p>where <italic>w<sub>4</sub></italic> and <italic>b<sub>4</sub></italic> were parameters for training, <italic>T</italic><sub>4i</sub> ∈ <italic>T</italic><sub>4</sub> was the result for each name, and <italic>T<sub>4</sub></italic> was the result set of module 3.</p>
        </sec>
        <sec>
          <title>Module 4: Recognizing Names With Parentheses</title>
          <p>Module 4 was a 3-class classifier to determine whether there was a parenthesis in a name, and if so, whether it referred to a previous last name or the name of spouse. The computing process was the same as module 3, which took the input of <italic>h<sub>i</sub><sup>common</sup></italic> and output the tags of 3 classes (“no parenthesis,” “previous last name,” and “spouse’s name”).</p>
        </sec>
        <sec>
          <title>Module 5: Rule-Based Inference Layer</title>
          <p>This module aimed to infer age, death date, and birth date for the deceased and gender for both the deceased and their family members. First, if an obituary mentioned any 2 attributes out of age, birth date, and death date for the deceased, we calculated the third one. Second, we used both family relationship keyword and name to infer gender. If a family relationship keyword (eg, son, daughter, nephew) suggested gender, we would add the gender tag accordingly. Otherwise, when the family relationship keyword (eg, spouse and parent) did not tell the gender, we used an external human name knowledge base to match the most likely gender with names. For instance, “Tom” and “Emily” indicated male and female, separately.</p>
          <p>After constructing the GKGs from each obituary by modules 1 to 5, we assembled the extracted GKGs into bigger ones by matching PII, including people’s names, residence, birth date, death date, and family relationship.</p>
        </sec>
        <sec>
          <title>Joint Training Loss</title>
          <p>We minimized the negative log likelihood loss of the generated tags for the first 4 modules (module 5 is a rule-based inference layer that did not require training). For module <italic>k</italic> (<italic>k</italic>=1, 2, 3, 4), the loss function was defined as follows:</p>
          <disp-formula>
            <graphic xlink:href="jmir_v23i8e25670_fig13.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
          </disp-formula>
          <p>Where <italic>B</italic> was the batch size, <italic>l<sub>s</sub></italic> was the length of input sentence sentences, <italic>y<sup>s</sup><sub>i</sub></italic> and <italic>p<sup>s</sup><sub>i</sub></italic> were the true tag and the normalized probability of the predicted tag for an input token <italic>I</italic>, and 𝜕 was a hyperparameter. <italic>P(O)</italic> was the indicator function that determined which part of equation 10 was used to calculate the loss. If the current tag was not “O” (other), the hyperparameter 𝜕 would decide the weight of the loss function. It was defined as follows:</p>
          <disp-formula>
            <graphic xlink:href="jmir_v23i8e25670_fig14.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
          </disp-formula>
          <p>In the end, we combined all four loss functions <italic>L<sub>1</sub></italic>, <italic>L<sub>2</sub></italic>, <italic>L<sub>3</sub></italic> and <italic>L<sub>4</sub></italic> together, using different weighting parameters <italic>λ<sub>k</sub></italic> into the final loss function, which was optimized for the entire training as follows:</p>
          <disp-formula>
            <graphic xlink:href="jmir_v23i8e25670_fig15.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
          </disp-formula>
        </sec>
        <sec>
          <title>Evaluation Metrics</title>
          <p>We performed 10-fold cross-validation by randomly selecting 10% of the annotated data for validation and the remaining for training. It is worth noting that the augmented data were only used for training models. Extracted GKGs consists of outputs from modules 1 to 5. They were measured by averaged performance of all modules except module 5 due to this rule-based inference module lacking a gold standard. For modules 1 to 4, we used precision, recall, and F-1 measure for evaluation, which were computed as follows:</p>
          <disp-formula>
            <graphic xlink:href="jmir_v23i8e25670_fig16.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
          </disp-formula>
          <p>In module 1, the outputs were entity mentions with extra entity and relation types. We defined an extracted mention as true positive instances only if the mention’s boundary, entity type, and relation tags were exactly matched with the gold annotation. The instances of false positive were predicted mentions that do not precisely match with gold annotation boundaries, entity, or relation types. False negative instances were those existing in the gold annotation but not recognized by the model.</p>
          <p>In module 2, true positive instances were defined as pairs of name and location that matched exactly. If either name or location was wrong, the pair would be considered a false positive. False negative referred to the name-location pairs missed by our system.</p>
          <p>Module 3 and module 4 were formulated as generic classification tasks, so we used common definitions of false negative, false positive, and true positive. For all modules, evaluation metrics were precision, recall, and F-1 measure.</p>
        </sec>
      </sec>
    </sec>
    <sec sec-type="results">
      <title>Results</title>
      <p><xref ref-type="table" rid="table3">Table 3</xref> illustrates the performance of modules 1 to 4 with ablation experiments in terms of macroaveraged and microaveraged precision, recall, and F-1 measure (without data augmentation). A macroaverage is the arithmetic average of the computed metrics for all classes and a microaverage sums up all true positive, true negative, false positive, and false negative instances before computing the final precision, recall, or F-1 measure for all classes. Macroaveraged metrics are often used for evaluation, particularly when there are extremely imbalanced classes, as no single class should largely dominate the results.</p>
      <p>As shown in <xref ref-type="table" rid="table3">Table 3</xref>, we can see that module 1, which constructed the nodes and edges of the GKGs, achieved macroaveraged precision, recall, and F-1 measure of 83.85%, 83.05%, and 83.44%, respectively (see the third row of the macroaveraged performance). If we did not consider the effects of imbalanced data, the microaveraged precision, recall, and F-1 measure were even better, reaching 95.42%, 93.52%, and 94.46%, respectively (see the third row of the microaveraged performance). The macroaveraged results were much worse than the microaveraged results because the dominating classes had above-average performance. The minority classes, although having below-average performance, did not affect the microaveraged results much due to their small count numbers. For example, uncle-in-law, granduncle, and cousin-in-law had just 1 case in our corpus (see <xref rid="figure1" ref-type="fig">Figure 1</xref>). These relations affected the macroaveraged metrics more negatively. The performances for modules 2, 3, and 4 had similar patterns.</p>
      <p>We also observed the benefits of multitask models through ablation experiments. Extra information gained from modules 3 and 4 seemed to improve module 1 in both macroaveraged precision, recall, and F-1 measure (2.17%, 3.12%, 2.64%, respectively) and microaveraged precision, recall, and F-1 measure (1.27%, 1.12%, and 1.19%, respectively). Modules 1 and 3 improved the performance of module 4 by 2.76%, 1.32%, 2.08% for macroaveraged precision, recall, and F-1 measure, respectively, and 2.51%, 1.7%, 2.13% for microaveraged precision, recall, and F-1 measure, respectively. Similarly, modules 1 and 4 helped to improve the macro/micro precision, recall, and F-1 of module 3 by 2.74%, 1.00%, 1.88%, respectively. And modules 1, 3, and 4 improved module 2 by 1.10%, 5.17%, and 3.49% in macro/micro averaged precision, recall, and F-1 measure.</p>
      <p>It should be noticed that module 2 seemed not helpful in improving the overall performance of each module. For module 1, the macroaveraged and microaveraged F-1 measure dropped by 1.41% (compare the first and third row of the macroaverage section of <xref ref-type="table" rid="table3">Table 3</xref>) and 1.03% (compare the third and third row of the microaverage section) after introducing module 2 into the end-to-end system . Other modules had similar effects when included in module 2. This phenomenon was named negative transfer. It meant that although module 2 significantly benefited (F-1 measure raised from 75.08% to 78.57%), other modules were negatively affected. Liu et al [<xref ref-type="bibr" rid="ref24">24</xref>] and Wang et al [<xref ref-type="bibr" rid="ref25">25</xref>] also observed and discussed similar negative transfer effects. We talk about negative transfer further in the Discussion section. In our system, the solution for avoiding the negative transfer was that module 1, 3, 4 would be cotrained and module 2 would be separated from the whole system for training. In such a way, each module could benefit the most from the joint training method.</p>
      <table-wrap position="float" id="table3">
        <label>Table 3</label>
        <caption>
          <p>Model performance of each module with ablation experiments.</p>
        </caption>
        <table width="1000" cellpadding="5" cellspacing="0" border="1" rules="groups" frame="hsides">
          <col width="30"/>
          <col width="430"/>
          <col width="90"/>
          <col width="90"/>
          <col width="90"/>
          <col width="90"/>
          <col width="90"/>
          <col width="90"/>
          <thead>
            <tr valign="top">
              <td colspan="2">Module and ablation test</td>
              <td colspan="3">Macroaveraged performance</td>
              <td colspan="3">Microaveraged performance</td>
            </tr>
            <tr valign="bottom">
              <td colspan="2">
                <break/>
              </td>
              <td>P<sup>a</sup> (%)</td>
              <td>R<sup>b</sup> (%)</td>
              <td>F1<sup>c</sup> (%)</td>
              <td>P (%)</td>
              <td>R (%)</td>
              <td>F1(%)</td>
            </tr>
          </thead>
          <tbody>
            <tr valign="top">
              <td colspan="8">
                <bold>Module 1</bold>
              </td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Baseline</td>
              <td>81.68</td>
              <td>79.93</td>
              <td>80.80</td>
              <td>94.15</td>
              <td>92.40</td>
              <td>93.27</td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Joint training (module 2, 3, &#38; 4) + negative transfer</td>
              <td>82.07</td>
              <td>81.99</td>
              <td>82.03</td>
              <td>94.08</td>
              <td>92.79</td>
              <td>93.43</td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Joint training (module 3 &#38; 4)</td>
              <td>83.85</td>
              <td>83.05</td>
              <td>83.44</td>
              <td>95.42</td>
              <td>93.52</td>
              <td>94.46</td>
            </tr>
            <tr valign="top">
              <td colspan="8">
                <bold>Module 2</bold>
              </td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Baseline</td>
              <td>83.17</td>
              <td>68.43</td>
              <td>75.08</td>
              <td>—<sup>d</sup></td>
              <td>—</td>
              <td>—</td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Joint training (module 1, 3, &#38; 4)</td>
              <td>84.27</td>
              <td>73.60</td>
              <td>78.57</td>
              <td>—</td>
              <td>—</td>
              <td>—</td>
            </tr>
            <tr valign="top">
              <td colspan="8">
                <bold>Module 3</bold>
              </td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Baseline</td>
              <td>89.64</td>
              <td>92.01</td>
              <td>90.81</td>
              <td>—</td>
              <td>—</td>
              <td>—</td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Joint training (module 1, 2, &#38; 4) + negative transfer</td>
              <td>91.48</td>
              <td>91.12</td>
              <td>91.30</td>
              <td>—</td>
              <td>—</td>
              <td>—</td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Joint training (module 1 &#38; 4)</td>
              <td>92.38</td>
              <td>93.01</td>
              <td>92.69</td>
              <td>—</td>
              <td>—</td>
              <td>—</td>
            </tr>
            <tr valign="top">
              <td colspan="8">
                <bold>Module 4</bold>
              </td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Baseline</td>
              <td>90.65</td>
              <td>94.74</td>
              <td>92.64</td>
              <td>90.96</td>
              <td>95.21</td>
              <td>93.03</td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Joint training (module 1, 2, &#38; 3) + negative transfer</td>
              <td>92.34</td>
              <td>95.76</td>
              <td>94.02</td>
              <td>92.37</td>
              <td>96.31</td>
              <td>94.30</td>
            </tr>
            <tr valign="top">
              <td>
                <break/>
              </td>
              <td>Joint training (module 1 &#38; 3)</td>
              <td>93.41</td>
              <td>96.06</td>
              <td>94.72</td>
              <td>93.47</td>
              <td>96.91</td>
              <td>95.16</td>
            </tr>
          </tbody>
        </table>
        <table-wrap-foot>
          <fn id="table3fn1">
            <p><sup>a</sup>P: precision.</p>
          </fn>
          <fn id="table3fn2">
            <p><sup>b</sup>R: recall.</p>
          </fn>
          <fn id="table3fn3">
            <p><sup>c</sup>F1: F-1 measure.</p>
          </fn>
          <fn id="table3fn4">
            <p><sup>d</sup>The microaveraged and macroaveraged performances are the same for module 2 and module 3 because they are both binary classification tasks. All results shown are from the curated corpus without data augmentation.</p>
          </fn>
        </table-wrap-foot>
      </table-wrap>
      <p>We also adopted data augmentation technology to expand our corpus, aiming to improve the relation extraction performance for family relations (module 1) with too few training examples. By synonym replacement, random insertion, random swap, and random deletion, we augmented the training data to ensure every relation had no less than 200 training examples. However, the automated data augmentation method introduced new noise. We tested a different augmentation ratio (<italic>α</italic>) to find the best balance. As shown in <xref rid="figure4" ref-type="fig">Figure 4</xref>, when the augmentation ratio was set to 40%, the extra synthetic data in training benefited our model most. It was worth noting that the augmentation data were only used in training for module 1, and we still evaluated our system with real, nonsynthetic test data. <xref rid="figure4" ref-type="fig">Figure 4</xref> shown that the best macroaveraged and microaveraged F-1 measures achieved 89.14% and 95.55%, respectively, for module 1. With augmented module 1, our whole system achieved the best macroaveraged performances, 92.59% (precision), 90.05% (recall), and 91.30% (F-1 measure), and the best microaveraged metrics were 94.79% (precision), 91.45% (recall), and 93.09% (F-1 measure). These results confirmed that data augmentation technology can alleviate the problem of imbalanced data.</p>
      <p>After extracting GKGs from all obituaries, we assembled them into bigger ones by matching available PII, including name, gender, age, residence, and birth date. Considering obituaries usually provide detailed PII for the deceased but not for their family members and relatives, we did fuzzy matching for the relatives. That is, if the mentioning of 2 people in 2 different obituaries are likely to refer to the same person based on 1 or more shared piece of PII, we would assemble 2 GKGs into 1. In the end, we had 319 GKGs assembled into 149 bigger GKGs after processing all 12,407 downloaded obituaries. Among those 319 obituaries, 22.3% (71/319) had 1 shared PII item, 8.5% (27/319) had 2, and 69.3% (221/319) had more than 2. We manually evaluated those 149 assembled GKGs and confirmed that 71.8% (107/149) were correct, 12.1% (18/149) were wrong, and 16.1% (24/149) were uncertain. We acknowledge that this rule-based matching method is limitedly useful for the selected geographic location of the Twin Cities area in Minnesota. It might be more error prone to apply to the entire country or other densely populated areas with high population mobility. So we did not include the assembly function in the end-to-end system but kept it as an additional resource for cautious users.</p>
      <fig id="figure4" position="float">
        <label>Figure 4</label>
        <caption>
          <p>Comparing the F-1 measures of raw corpus and augmented corpus.</p>
        </caption>
        <graphic xlink:href="jmir_v23i8e25670_fig4.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
      </fig>
      <p><xref rid="figure5" ref-type="fig">Figure 5</xref> shows one example of assembled GKG from 3 obituaries. It contained 4 generations and 30 people. <xref rid="figure6" ref-type="fig">Figure 6</xref> is the corresponding gold standard result conducted from manual validation. It can be seen that the assembled GKG missed the state name Minnesota for Dorothy and Patrick’s residences and one family member, Joe, who was Lynne’s husband (missing parts are shown in dashed boxes). In the original obituary, the sentence mentioning Lynne and Joe’s relation was “...he proposed...they began 54 years of happy life,” and our system failed to capture this subtle language. The successful assembly of multiple obituaries also demonstrated the feasibility of linking family relations extracted from obituaries to EHRs to support genetic research like linkage analysis and disease risk prediction. Meanwhile, it should be noticed that even though obituaries inherently contained rich genealogical information and the system extracts the GKGs with high accuracy, the GKGs should not always be equated to pedigrees used by genealogists. Although it is common to declare blood or nonblood relationships in obituaries due to data specialty (detail analysis for the slippery slope of genealogy issue shown in the Discussion section), we cannot guarantee people always declare the difference of blood or nonblood and always list all of their family members for various reasons.</p>
      <fig id="figure5" position="float">
        <label>Figure 5</label>
        <caption>
          <p>An example of an assembled genealogical knowledge graph. We removed last names for privacy protection. The symbol ? means we are not sure which children nodes belong to which parent nodes.</p>
        </caption>
        <graphic xlink:href="jmir_v23i8e25670_fig5.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
      </fig>
      <fig id="figure6" position="float">
        <label>Figure 6</label>
        <caption>
          <p>The gold standard family tree constructed from manual curation corresponding to Figure 5.</p>
        </caption>
        <graphic xlink:href="jmir_v23i8e25670_fig6.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
      </fig>
    </sec>
    <sec>
      <title>Discussion</title>
      <sec>
        <title>Principal Findings</title>
        <p>In this work, we proposed an end-to-end system to construct GKGs from online obituaries, aiming at supplementing EHR data for genetic research. This system achieves microaveraged precision of 94.79%, recall of 91.45%, and F-1 measure of 93.09% after data augmentation technology. The work exploits the large availability of obituaries on the internet, which are consistent with the vital records and census records and more reliable and comprehensive than dependent information from medical insurance and emergency contact in EHR systems [<xref ref-type="bibr" rid="ref5">5</xref>,<xref ref-type="bibr" rid="ref6">6</xref>]. We demonstrate an efficient system to automatically build large GKGs from 10 years’ online obituaries in the Twin City area, Minnesota. Furthermore, by identifying individuals, we explore integrating related GKGs into bigger GKGs and manually validating the integrated results. The results show the feasibility of identifying individuals by extracted information, including residence, age, gender, birth, and death dates. We compute similarities between GKGs to further merge them into more complete GKGs. In the future, the similarity computing techniques could assist mapping the GKGs to the EHRs.</p>
        <p>In this work, we use publicly available obituaries. The Association of Internet Researchers, in partnership with their Ethical Working Committee, formulated general principals to guide online research [<xref ref-type="bibr" rid="ref26">26</xref>]. While this document presents the overarching ethical considerations relevant to social media–based research, a comprehensive determination of ethical principles and best practices has yet to be developed. Furthermore, debate continues as to whether some forms of social media–based research, namely analysis of existing textual archives (strictly speaking, online obituaries are not social media, but they have similar characteristics as a data source for biomedical research), fall within the parameters of human subject research or constitute an alternative form of humanistic inquiry [<xref ref-type="bibr" rid="ref27">27</xref>]. Considering the PII embedded in online obituaries, we decided to take a cautious and conservative position in our work by marking up the last name of any real people mentioned in the paper.</p>
        <p>As a novel data source, obituaries are informative for constructing family trees. It is hard to obtain such rich genealogical information from other data sources, but there are caveats to their use as genealogical data. First, semantic ambiguity occurs in obituaries as it occurs in many other types of human writing. For example, it is not uncommon to see statements like “...survived by two sons, Marshal and Paul XX and daughter Daisy, and four grandchildren Denny, Gary, Cecil, and Alina.” In this case, it is impossible to tell the exact parents for each of the 4 grandchildren Denny, Gary, Cecil, and Alina. All we know is that their parents are Marshal XX, Paul XX, and Daisy. Additional data sources like birth certificate registries can be helpful in this case.</p>
        <p>A second point worth discussing is the slippery slope of genealogy. Compared with medical insurance and emergency contact information [<xref ref-type="bibr" rid="ref5">5</xref>,<xref ref-type="bibr" rid="ref6">6</xref>], a statement of nonblood relationship is more common in obituary data due to their specificity. As shown in <xref rid="figure1" ref-type="fig">Figure 1</xref>, for child relationship the ratio for nonblood versus blood is 483:5472 (there are 25 mentions of child-in-law, 99 of daughter-in-law, 105 of son-in-law, 151 of stepchild, 48 of stepdaughter, and 55 of stepson compared with 2489 cases of child, 1399 of daughter, and 1584 of son). A similar ratio can be observed in nonblood parent relationship. This advantage could be helpful for alleviating the problem of the slippery slope of genealogy. However, it is still worth mentioning that not all people make such distinctions in obituaries.</p>
        <p>In addition, <xref rid="figure7" ref-type="fig">Figure 7</xref> displayed the related statistics aimed at showing potential data bias. We plotted the distribution of age (at death), average number of mentioned family members, and marital status of the deceased for all GKGs extracted from 12,407 downloaded obituaries. As shown in <xref rid="figure7" ref-type="fig">Figure 7</xref>, the age distribution of the deceased is consistent with public health data (73.9% of the deceased died at the ages of 70 to 100 years). The average numbers of mentioned family members seem similar for different age groups; only those died in the 0 to 10 and 100 to 110 age groups had relatively smaller family size (≤15); 87.6% of the GKGs indicated that the deceased was married at least once. We did not interpret the results too deeply because we did not have a good understanding of the sample bias. Meanwhile, it was noticed that people who had complete and/or affluent families tended to publish obituaries. Although these data biases would not affect the performance of our extraction system, the fact that extracted GKGs may be biased should be considered when researchers are using them in other research.</p>
        <fig id="figure7" position="float">
          <label>Figure 7</label>
          <caption>
            <p>Left: distribution of average numbers of mentioned family members. Right: age and marital status of the deceased person in 12,407 extracted genealogical knowledge graphs.</p>
          </caption>
          <graphic xlink:href="jmir_v23i8e25670_fig7.png" alt-version="no" mimetype="image" position="float" xlink:type="simple"/>
        </fig>
        <p>Technically, the data used in the research are very imbalanced, in which 14 rare relationships have fewer than 10 instances. We adopted the augmentation technology to enhance system performance. For example, in the relationships half-sister, grandchild-in-law, and grandson-in-law, their F-1 measures increased from 20.0%, 30.0%, and 35.71% to 66.67%, 50.0%, and 71.43%, respectively. Next step, we plan to experiment with additional few-shot (extremely imbalanced)–based information extraction and mate learning to improve the system [<xref ref-type="bibr" rid="ref28">28</xref>,<xref ref-type="bibr" rid="ref29">29</xref>].</p>
        <p>In our end-to-end solution, the performance of module 2 was obviously inferior to the other modules. Besides the error propagation problem (module 2 need the results from module 1), the task of module 2 was a semantic matching resolution problem, which is still challenging in the NLP community. In addition, we currently have curated an obituary corpus in English to train the neural network models. To expand to other languages, a new corpus in those specific languages and new gender inference rules would need to be curated. There is some cross-language transfer research in the NLP community which suggests neural models trained on an English corpus can help to build NLP models in other languages by reducing training data and training time. Sometimes such transfers even provide more robust models with better performance [<xref ref-type="bibr" rid="ref30">30</xref>,<xref ref-type="bibr" rid="ref31">31</xref>].</p>
        <p>In our end-to-end solution, module 2 currently is the bottleneck. This module suffered significantly from negative transfer. Generally speaking, when a task or domain was joined with data of no relatedness or similarity, the added data would become noise rather than useful information. It remains challenging to quantitatively measure the relatedness or similarity among different tasks or domains [<xref ref-type="bibr" rid="ref32">32</xref>]. Therefore, most transfer learning solutions rely on empirical methods and do not account for negative transfer effects. In this work, we considered module 2, which matched locations to people, as strongly related to other modules that extracted locations or people and paired them. Unfortunately, the experiment results showed negative transfer still occurred. One possible explanation was about the different natures of tasks in modules 1, 2, 3, and 4. Module 2 was a classification task with 2 entity mentions as the input and a class tag as the output. All other modules were sequence tagging tasks, where the whole sentence was the input and tags for all tokens of an input sentence were output. Another possible reason was that the task of module 2 was much more challenging than the others. Modules 1, 3, and 4 all had a higher than 90% microaveraged F-1 measure when we tested them individually, while module 2 had a 75.08% microaveraged F-1 measure. In addition, module 2 needed inputs from module 1. The errors of module 1 would propagate to module 2. How to improve module 2 and alleviate its negative transfer and error propagation is what we plan to focus on methodologically in the future.</p>
        <p>Besides the performance benefits shown in the Result section, the multitask solution is also faster to train. We use a single V100 GPU in this study. For the traditional pipeline model, one round 10-fold cross-validation experiment costs about 240 hours in total. However, the multitask model with all 4 modules together takes only 150 hours. For module 1, the training process took about 70 epochs to achieve an F-1 measure of 80% when being trained independently. The multitask method takes less than 5 epochs to achieve the same level of F-1 measure.</p>
      </sec>
      <sec>
        <title>Limitations</title>
        <p>The first limitation of our work is the existing potential data bias. Our data are collected from online obituary websites. In such conditions, people who had intact and/or affluent families tended to publish obituaries. The second limitation is that our system is mainly for English obituaries. Modules 2 and 3 are designed for 2 English writing patterns.</p>
      </sec>
      <sec>
        <title>Conclusions</title>
        <p>GKGs have great potential to enhance many medical research fields, especially combined with EHR data. We believe a high-quality, large-scale genealogical information database will have significant research meaning. In this work, we presented a new corpus with a predefined family relationship map and augmented training data and proposed a multitask deep neural system to construct and assemble GKGs. With the data augmentation technology, the system achieved microaveraged precision, recall, and F-1 measure of 94.79%, 91.45%, and 93.09%, respectively, and macroaveraged precision, recall, and F-1 measure of 92.59%, 90.05%, 91.30%, respectively. Based on such promising results, we developed PII-matching rules to assemble large GKGs, demonstrating the potential of linking GKGs to EHRs. The system is capable of generating a large number of GKGs to support related research, like genetic research, linkage analysis, and disease risk prediction. We share the source codes and system with the entire scientific community on GitHub, without the corpus for privacy protection [<xref ref-type="bibr" rid="ref33">33</xref>].</p>
        <p>In the future, we will improve the performance of our system further and match GKGs with more medical information, like EHR databases. With the massive obituary data freely available on the internet or other textual data that contain genealogical information, our ultimate goal is to accelerate large-scale disease heritability research and clinical genetics research.</p>
      </sec>
    </sec>
  </body>
  <back>
    <app-group/>
    <glossary>
      <title>Abbreviations</title>
      <def-list>
        <def-item>
          <term id="abb1">EHR</term>
          <def>
            <p>electronic health records</p>
          </def>
        </def-item>
        <def-item>
          <term id="abb2">GKG</term>
          <def>
            <p>genealogical knowledge graph</p>
          </def>
        </def-item>
        <def-item>
          <term id="abb3">LSTM</term>
          <def>
            <p>long short-term memory</p>
          </def>
        </def-item>
        <def-item>
          <term id="abb4">NER</term>
          <def>
            <p>name entity recognition</p>
          </def>
        </def-item>
        <def-item>
          <term id="abb5">NLP</term>
          <def>
            <p>natural language processing</p>
          </def>
        </def-item>
        <def-item>
          <term id="abb6">PII</term>
          <def>
            <p>personally identifiable information</p>
          </def>
        </def-item>
        <def-item>
          <term id="abb7">RC</term>
          <def>
            <p>relation classification</p>
          </def>
        </def-item>
      </def-list>
    </glossary>
    <ack>
      <p>This work has been supported by grant 2018YFC0910404 from the National Key Research and Development Program of China, grant 61772409 from the National Natural Science Foundation of China; grant 61721002 from the Innovative Research Group of the National Natural Science Foundation of China, and grant IRT_17R86 from the Innovation Research Team of the Ministry of Education, Project of China Knowledge Centre for Engineering Science and Technology.</p>
    </ack>
    <fn-group>
      <fn fn-type="conflict">
        <p>None declared.</p>
      </fn>
    </fn-group>
    <ref-list>
      <ref id="ref1">
        <label>1</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Casalino</surname>
              <given-names>LP</given-names>
            </name>
          </person-group>
          <article-title>The Medicare Access And CHIP Reauthorization Act and The corporate transformation of American medicine</article-title>
          <source>Health Aff (Millwood)</source>
          <year>2017</year>
          <month>05</month>
          <day>01</day>
          <volume>36</volume>
          <issue>5</issue>
          <fpage>865</fpage>
          <lpage>869</lpage>
          <pub-id pub-id-type="doi">10.1377/hlthaff.2016.1536</pub-id>
          <pub-id pub-id-type="medline">28461353</pub-id>
          <pub-id pub-id-type="pii">36/5/865</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref2">
        <label>2</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Blumenthal</surname>
              <given-names>D</given-names>
            </name>
            <name name-style="western">
              <surname>Tavenner</surname>
              <given-names>M</given-names>
            </name>
          </person-group>
          <article-title>The "meaningful use" regulation for electronic health records</article-title>
          <source>N Engl J Med</source>
          <year>2010</year>
          <month>08</month>
          <day>5</day>
          <volume>363</volume>
          <issue>6</issue>
          <fpage>501</fpage>
          <lpage>504</lpage>
          <pub-id pub-id-type="doi">10.1056/NEJMp1006114</pub-id>
          <pub-id pub-id-type="medline">20647183</pub-id>
          <pub-id pub-id-type="pii">NEJMp1006114</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref3">
        <label>3</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Mayer</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Kitchner</surname>
              <given-names>T</given-names>
            </name>
            <name name-style="western">
              <surname>Ye</surname>
              <given-names>Z</given-names>
            </name>
            <name name-style="western">
              <surname>Zhou</surname>
              <given-names>Z</given-names>
            </name>
            <name name-style="western">
              <surname>He</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Schrodi</surname>
              <given-names>SJ</given-names>
            </name>
            <name name-style="western">
              <surname>Hebbring</surname>
              <given-names>SJ</given-names>
            </name>
          </person-group>
          <article-title>Use of an electronic medical record to create the marshfield clinic twin/multiple birth cohort</article-title>
          <source>Genet Epidemiol</source>
          <year>2014</year>
          <month>12</month>
          <day>22</day>
          <volume>38</volume>
          <issue>8</issue>
          <fpage>692</fpage>
          <lpage>698</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="http://europepmc.org/abstract/MED/25250975"/>
          </comment>
          <pub-id pub-id-type="doi">10.1002/gepi.21855</pub-id>
          <pub-id pub-id-type="medline">25250975</pub-id>
          <pub-id pub-id-type="pmcid">PMC4384889</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref4">
        <label>4</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Van Schalkwyk</surname>
              <given-names>GJ</given-names>
            </name>
            <name name-style="western">
              <surname>Tran</surname>
              <given-names>E</given-names>
            </name>
            <name name-style="western">
              <surname>Chang</surname>
              <given-names>K</given-names>
            </name>
          </person-group>
          <article-title>The impact of Macao’s gaming industry on family life</article-title>
          <source>China Perspectives</source>
          <year>2006</year>
          <month>04</month>
          <day>01</day>
          <fpage>1</fpage>
          <pub-id pub-id-type="doi">10.4000/chinaperspectives.603</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref5">
        <label>5</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Wang</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>Gaitsch</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Poon</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Cox</surname>
              <given-names>NJ</given-names>
            </name>
            <name name-style="western">
              <surname>Rzhetsky</surname>
              <given-names>A</given-names>
            </name>
          </person-group>
          <article-title>Classification of common human diseases derived from shared genetic and environmental determinants</article-title>
          <source>Nat Genet</source>
          <year>2017</year>
          <month>09</month>
          <volume>49</volume>
          <issue>9</issue>
          <fpage>1319</fpage>
          <lpage>1325</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="http://europepmc.org/abstract/MED/28783162"/>
          </comment>
          <pub-id pub-id-type="doi">10.1038/ng.3931</pub-id>
          <pub-id pub-id-type="medline">28783162</pub-id>
          <pub-id pub-id-type="pii">ng.3931</pub-id>
          <pub-id pub-id-type="pmcid">PMC5577363</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref6">
        <label>6</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Polubriaginof</surname>
              <given-names>FCG</given-names>
            </name>
            <name name-style="western">
              <surname>Vanguri</surname>
              <given-names>R</given-names>
            </name>
            <name name-style="western">
              <surname>Quinnies</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>Belbin</surname>
              <given-names>GM</given-names>
            </name>
            <name name-style="western">
              <surname>Yahi</surname>
              <given-names>A</given-names>
            </name>
            <name name-style="western">
              <surname>Salmasian</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Lorberbaum</surname>
              <given-names>T</given-names>
            </name>
            <name name-style="western">
              <surname>Nwankwo</surname>
              <given-names>V</given-names>
            </name>
            <name name-style="western">
              <surname>Li</surname>
              <given-names>L</given-names>
            </name>
            <name name-style="western">
              <surname>Shervey</surname>
              <given-names>MM</given-names>
            </name>
            <name name-style="western">
              <surname>Glowe</surname>
              <given-names>P</given-names>
            </name>
            <name name-style="western">
              <surname>Ionita-Laza</surname>
              <given-names>I</given-names>
            </name>
            <name name-style="western">
              <surname>Simmerling</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Hripcsak</surname>
              <given-names>G</given-names>
            </name>
            <name name-style="western">
              <surname>Bakken</surname>
              <given-names>S</given-names>
            </name>
            <name name-style="western">
              <surname>Goldstein</surname>
              <given-names>D</given-names>
            </name>
            <name name-style="western">
              <surname>Kiryluk</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>Kenny</surname>
              <given-names>EE</given-names>
            </name>
            <name name-style="western">
              <surname>Dudley</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Vawdrey</surname>
              <given-names>DK</given-names>
            </name>
            <name name-style="western">
              <surname>Tatonetti</surname>
              <given-names>NP</given-names>
            </name>
          </person-group>
          <article-title>Disease heritability inferred from familial relationships reported in medical records</article-title>
          <source>Cell</source>
          <year>2018</year>
          <month>06</month>
          <day>14</day>
          <volume>173</volume>
          <issue>7</issue>
          <fpage>1692</fpage>
          <lpage>1704</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://linkinghub.elsevier.com/retrieve/pii/S0092-8674(18)30525-7"/>
          </comment>
          <pub-id pub-id-type="doi">10.1016/j.cell.2018.04.032</pub-id>
          <pub-id pub-id-type="medline">29779949</pub-id>
          <pub-id pub-id-type="pii">S0092-8674(18)30525-7</pub-id>
          <pub-id pub-id-type="pmcid">PMC6015747</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref7">
        <label>7</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Tourassi</surname>
              <given-names>G</given-names>
            </name>
            <name name-style="western">
              <surname>Yoon</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Xu</surname>
              <given-names>S</given-names>
            </name>
          </person-group>
          <article-title>A novel web informatics approach for automated surveillance of cancer mortality trends</article-title>
          <source>J Biomed Inform</source>
          <year>2016</year>
          <month>06</month>
          <volume>61</volume>
          <fpage>110</fpage>
          <lpage>118</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://linkinghub.elsevier.com/retrieve/pii/S1532-0464(16)30018-1"/>
          </comment>
          <pub-id pub-id-type="doi">10.1016/j.jbi.2016.03.027</pub-id>
          <pub-id pub-id-type="medline">27044930</pub-id>
          <pub-id pub-id-type="pii">S1532-0464(16)30018-1</pub-id>
          <pub-id pub-id-type="pmcid">PMC5048742</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref8">
        <label>8</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Yoon</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Tourassi</surname>
              <given-names>G</given-names>
            </name>
            <name name-style="western">
              <surname>Xu</surname>
              <given-names>S</given-names>
            </name>
          </person-group>
          <article-title>Residential mobility and lung cancer risk: data-driven exploration using internet sources</article-title>
          <source>Lect Notes Comput Sci (including Subser Lect Notes Artif Intell Lect Notes Bioinformatics)</source>
          <year>2015</year>
          <volume>9021</volume>
          <fpage>464</fpage>
          <lpage>469</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="http://europepmc.org/abstract/MED/26618206"/>
          </comment>
          <pub-id pub-id-type="doi">10.1007/978-3-319-16268-3_60</pub-id>
          <pub-id pub-id-type="medline">26618206</pub-id>
          <pub-id pub-id-type="pmcid">PMC4662563</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref9">
        <label>9</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>He</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>Wu</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Ma</surname>
              <given-names>X</given-names>
            </name>
            <name name-style="western">
              <surname>Zhang</surname>
              <given-names>C</given-names>
            </name>
            <name name-style="western">
              <surname>Huang</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Li</surname>
              <given-names>C</given-names>
            </name>
            <name name-style="western">
              <surname>Yao</surname>
              <given-names>L</given-names>
            </name>
          </person-group>
          <article-title>Extracting kinship from obituary to enhance electronic health records for genetic research</article-title>
          <year>2019</year>
          <conf-name>Proceedings of the Fourth Social Media Mining for Health Applications (#SMM4H) Workshop &#38; Shared Task</conf-name>
          <conf-date>2019</conf-date>
          <conf-loc>Florence</conf-loc>
          <fpage>1</fpage>
          <lpage>10</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://aclanthology.org/W19-3201.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.18653/v1/w19-3201</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref10">
        <label>10</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Caruana</surname>
              <given-names>R</given-names>
            </name>
          </person-group>
          <article-title>Multitask learning</article-title>
          <source>Mach Learn</source>
          <year>1997</year>
          <volume>28</volume>
          <issue>1</issue>
          <fpage>41</fpage>
          <lpage>75</lpage>
          <pub-id pub-id-type="doi">10.1007/978-1-4615-5529-2_5</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref11">
        <label>11</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Collobert</surname>
              <given-names>R</given-names>
            </name>
            <name name-style="western">
              <surname>Weston</surname>
              <given-names>J</given-names>
            </name>
          </person-group>
          <article-title>A unified architecture for natural language processing</article-title>
          <source>Proc 25th Int Conf Mach Learn</source>
          <year>2008</year>
          <fpage>160</fpage>
          <lpage>167</lpage>
          <pub-id pub-id-type="doi">10.1145/1390156.1390177</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref12">
        <label>12</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Li</surname>
              <given-names>F</given-names>
            </name>
            <name name-style="western">
              <surname>Zhang</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Fu</surname>
              <given-names>G</given-names>
            </name>
            <name name-style="western">
              <surname>Ji</surname>
              <given-names>D</given-names>
            </name>
          </person-group>
          <article-title>A neural joint model for entity and relation extraction from biomedical text</article-title>
          <source>BMC Bioinformatics</source>
          <year>2017</year>
          <month>03</month>
          <day>31</day>
          <volume>18</volume>
          <issue>1</issue>
          <fpage>198</fpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-017-1609-9"/>
          </comment>
          <pub-id pub-id-type="doi">10.1186/s12859-017-1609-9</pub-id>
          <pub-id pub-id-type="medline">28359255</pub-id>
          <pub-id pub-id-type="pii">10.1186/s12859-017-1609-9</pub-id>
          <pub-id pub-id-type="pmcid">PMC5374588</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref13">
        <label>13</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Verga</surname>
              <given-names>P</given-names>
            </name>
            <name name-style="western">
              <surname>Strubell</surname>
              <given-names>E</given-names>
            </name>
            <name name-style="western">
              <surname>McCallum</surname>
              <given-names>A</given-names>
            </name>
          </person-group>
          <article-title>Simultaneously self-attending to all mentions for full-abstract biological relation extraction</article-title>
          <year>2018</year>
          <conf-name>Proc 2018 Conf North Am Chap Assoc Comput Linguist</conf-name>
          <conf-date>2018</conf-date>
          <conf-loc>New Orleans</conf-loc>
          <fpage>872</fpage>
          <lpage>884</lpage>
          <pub-id pub-id-type="doi">10.18653/v1/n18-1080</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref14">
        <label>14</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Sun</surname>
              <given-names>C</given-names>
            </name>
            <name name-style="western">
              <surname>Gong</surname>
              <given-names>Y</given-names>
            </name>
            <name name-style="western">
              <surname>Wu</surname>
              <given-names>Y</given-names>
            </name>
            <name name-style="western">
              <surname>Gong</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Jiang</surname>
              <given-names>D</given-names>
            </name>
            <name name-style="western">
              <surname>Lan</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Sun</surname>
              <given-names>S</given-names>
            </name>
            <name name-style="western">
              <surname>Duan</surname>
              <given-names>N</given-names>
            </name>
          </person-group>
          <article-title>Joint type inference on entities and relations via graph convolutional networks</article-title>
          <year>2020</year>
          <conf-name>Proc 57th Ann Mtg Assoc Comput Linguist</conf-name>
          <conf-date>2020</conf-date>
          <conf-loc>Florence</conf-loc>
          <fpage>1361</fpage>
          <lpage>1370</lpage>
          <pub-id pub-id-type="doi">10.18653/v1/p19-1131</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref15">
        <label>15</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Bhatia</surname>
              <given-names>P</given-names>
            </name>
            <name name-style="western">
              <surname>Celikkaya</surname>
              <given-names>B</given-names>
            </name>
            <name name-style="western">
              <surname>Khalilia</surname>
              <given-names>M</given-names>
            </name>
          </person-group>
          <article-title>Joint entity extraction and assertion detection for clinical text</article-title>
          <year>2019</year>
          <conf-name>Proc 57th Ann Mtg Assoc Comput Linguist</conf-name>
          <conf-date>2019</conf-date>
          <conf-loc>Florence</conf-loc>
          <fpage>954</fpage>
          <lpage>959</lpage>
          <pub-id pub-id-type="doi">10.18653/v1/p19-1091</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref16">
        <label>16</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Zheng</surname>
              <given-names>S</given-names>
            </name>
            <name name-style="western">
              <surname>Wang</surname>
              <given-names>F</given-names>
            </name>
            <name name-style="western">
              <surname>Bao</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Hao</surname>
              <given-names>Y</given-names>
            </name>
            <name name-style="western">
              <surname>Zhou</surname>
              <given-names>P</given-names>
            </name>
            <name name-style="western">
              <surname>Xu</surname>
              <given-names>B</given-names>
            </name>
          </person-group>
          <article-title>Joint extraction of entities and relations based on a novel tagging scheme</article-title>
          <year>2017</year>
          <conf-name>Proc 55th Ann Mtg Assoc Comput Linguist</conf-name>
          <conf-date>2017</conf-date>
          <conf-loc>Vancouver</conf-loc>
          <fpage>1227</fpage>
          <lpage>1236</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://aclanthology.org/P17-1113.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.18653/v1/p17-1113</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref17">
        <label>17</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Dixit</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>Al-Onaizan</surname>
              <given-names>Y</given-names>
            </name>
          </person-group>
          <article-title>Span-level model for relation extraction</article-title>
          <year>2019</year>
          <conf-name>Proc 57th Ann Mtg Assoc Comput Linguist</conf-name>
          <conf-date>2019</conf-date>
          <conf-loc>Florence</conf-loc>
          <fpage>5308</fpage>
          <lpage>5314</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://aclanthology.org/P19-1525.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.18653/v1/p19-1525</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref18">
        <label>18</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Zheng</surname>
              <given-names>S</given-names>
            </name>
            <name name-style="western">
              <surname>Hao</surname>
              <given-names>Y</given-names>
            </name>
            <name name-style="western">
              <surname>Lu</surname>
              <given-names>D</given-names>
            </name>
            <name name-style="western">
              <surname>Bao</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Xu</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Hao</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Xu</surname>
              <given-names>B</given-names>
            </name>
          </person-group>
          <article-title>Joint entity and relation extraction based on a hybrid neural network</article-title>
          <source>Neurocomputing</source>
          <year>2017</year>
          <month>09</month>
          <volume>257</volume>
          <fpage>59</fpage>
          <lpage>66</lpage>
          <pub-id pub-id-type="doi">10.1016/j.neucom.2016.12.075</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref19">
        <label>19</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Wei</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Zou</surname>
              <given-names>K</given-names>
            </name>
          </person-group>
          <article-title>EDA: easy data augmentation techniques for boosting performance on text classification tasks</article-title>
          <source>2019 Conf Empir Methods Nat Lang Process 9th Int Jt Conf Nat Lang Process Proc Conf Association for Computational Linguistics</source>
          <year>2020</year>
          <fpage>6382</fpage>
          <lpage>6388</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://arxiv.org/abs/1901.11196"/>
          </comment>
          <pub-id pub-id-type="doi">10.18653/v1/d19-1670</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref20">
        <label>20</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>St Sauver</surname>
              <given-names>JL</given-names>
            </name>
            <name name-style="western">
              <surname>Grossardt</surname>
              <given-names>BR</given-names>
            </name>
            <name name-style="western">
              <surname>Yawn</surname>
              <given-names>BP</given-names>
            </name>
            <name name-style="western">
              <surname>Melton</surname>
              <given-names>LJ</given-names>
            </name>
            <name name-style="western">
              <surname>Rocca</surname>
              <given-names>WA</given-names>
            </name>
          </person-group>
          <article-title>Use of a medical records linkage system to enumerate a dynamic population over time: the Rochester epidemiology project</article-title>
          <source>Am J Epidemiol</source>
          <year>2011</year>
          <month>05</month>
          <day>01</day>
          <volume>173</volume>
          <issue>9</issue>
          <fpage>1059</fpage>
          <lpage>1068</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="http://europepmc.org/abstract/MED/21430193"/>
          </comment>
          <pub-id pub-id-type="doi">10.1093/aje/kwq482</pub-id>
          <pub-id pub-id-type="medline">21430193</pub-id>
          <pub-id pub-id-type="pii">kwq482</pub-id>
          <pub-id pub-id-type="pmcid">PMC3105274</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref21">
        <label>21</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Clark</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>Luong</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Manning</surname>
              <given-names>C</given-names>
            </name>
            <name name-style="western">
              <surname>Le</surname>
              <given-names>QV</given-names>
            </name>
          </person-group>
          <article-title>Semi-supervised sequence modeling with cross-view training</article-title>
          <year>2018</year>
          <conf-name>Proc 2018 Conf Empir Methods Nat Lang Proc</conf-name>
          <conf-date>2018</conf-date>
          <conf-loc>Brussels</conf-loc>
          <fpage>1914</fpage>
          <lpage>1925</lpage>
          <pub-id pub-id-type="doi">10.18653/v1/d18-1217</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref22">
        <label>22</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Devlin</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Chang</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Lee</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>Toutanova</surname>
              <given-names>K</given-names>
            </name>
          </person-group>
          <article-title>BERT: pre-training of deep bidirectional transformers for language understanding (bidirectional encoder representations from transformers)</article-title>
          <year>2019</year>
          <conf-name>NAACL-HLT</conf-name>
          <conf-date>2019</conf-date>
          <conf-loc>North Stroudsburg</conf-loc>
          <fpage>4171</fpage>
          <lpage>4186</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://nlp.stanford.edu/seminar/details/jdevlin.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.18653/v1/N19-1423</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref23">
        <label>23</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Lee</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>He</surname>
              <given-names>L</given-names>
            </name>
            <name name-style="western">
              <surname>Lewis</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Zettlemoyer</surname>
              <given-names>L</given-names>
            </name>
          </person-group>
          <article-title>End-to-end neural coreference resolution</article-title>
          <year>2017</year>
          <conf-name>EMNLP 2017 Proc 2017 Conf Empir Methods Nat Lang Proc</conf-name>
          <conf-date>2017</conf-date>
          <conf-loc>Copenhagen</conf-loc>
          <fpage>188</fpage>
          <lpage>197</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://aclanthology.org/D17-1018.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.18653/v1/d17-1018</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref24">
        <label>24</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Liu</surname>
              <given-names>S</given-names>
            </name>
            <name name-style="western">
              <surname>Liang</surname>
              <given-names>Y</given-names>
            </name>
            <name name-style="western">
              <surname>Gitter</surname>
              <given-names>A</given-names>
            </name>
          </person-group>
          <article-title>Loss-balanced task weighting to reduce negative transfer in multi-task learning</article-title>
          <source>Proc AAAI Conf Artific Intell</source>
          <year>2019</year>
          <month>07</month>
          <day>17</day>
          <volume>33</volume>
          <issue>01</issue>
          <fpage>9977</fpage>
          <lpage>9978</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://ojs.aaai.org/index.php/AAAI/article/view/5125/4998"/>
          </comment>
          <pub-id pub-id-type="doi">10.1609/aaai.v33i01.33019977</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref25">
        <label>25</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Wang</surname>
              <given-names>Z</given-names>
            </name>
            <name name-style="western">
              <surname>Dai</surname>
              <given-names>Z</given-names>
            </name>
            <name name-style="western">
              <surname>Poczos</surname>
              <given-names>B</given-names>
            </name>
            <name name-style="western">
              <surname>Carbonell</surname>
              <given-names>J</given-names>
            </name>
          </person-group>
          <article-title>Characterizing and avoiding negative transfer</article-title>
          <year>2019</year>
          <conf-name>Proc IEEE Comput Soc Conf Comput Vis Pattern Recognit IEEE Computer Society; .?11294</conf-name>
          <conf-date>2019</conf-date>
          <conf-loc>Long Beach</conf-loc>
          <fpage>11285</fpage>
          <lpage>11294</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://openaccess.thecvf.com/content_CVPR_2019/papers/Wang_Characterizing_and_Avoiding_Negative_Transfer_CVPR_2019_paper.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.1109/cvpr.2019.01155</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref26">
        <label>26</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Bender</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Cyr</surname>
              <given-names>AB</given-names>
            </name>
            <name name-style="western">
              <surname>Arbuckle</surname>
              <given-names>L</given-names>
            </name>
            <name name-style="western">
              <surname>Ferris</surname>
              <given-names>LE</given-names>
            </name>
          </person-group>
          <article-title>Ethics and privacy implications of using the internet and social media to recruit participants for health research: a privacy-by-design framework for online recruitment</article-title>
          <source>J Med Internet Res</source>
          <year>2017</year>
          <month>04</month>
          <day>06</day>
          <volume>19</volume>
          <issue>4</issue>
          <fpage>e104</fpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://www.jmir.org/2017/4/e104/"/>
          </comment>
          <pub-id pub-id-type="doi">10.2196/jmir.7029</pub-id>
          <pub-id pub-id-type="medline">28385682</pub-id>
          <pub-id pub-id-type="pii">v19i4e104</pub-id>
          <pub-id pub-id-type="pmcid">PMC5399223</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref27">
        <label>27</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Denecke</surname>
              <given-names>K</given-names>
            </name>
            <name name-style="western">
              <surname>Bamidis</surname>
              <given-names>P</given-names>
            </name>
            <name name-style="western">
              <surname>Bond</surname>
              <given-names>C</given-names>
            </name>
            <name name-style="western">
              <surname>Gabarron</surname>
              <given-names>E</given-names>
            </name>
            <name name-style="western">
              <surname>Househ</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Lau</surname>
              <given-names>AYS</given-names>
            </name>
            <name name-style="western">
              <surname>Mayer</surname>
              <given-names>MA</given-names>
            </name>
            <name name-style="western">
              <surname>Merolli</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Hansen</surname>
              <given-names>M</given-names>
            </name>
          </person-group>
          <article-title>Ethical issues of social media usage in healthcare</article-title>
          <source>Yearb Med Inform</source>
          <year>2015</year>
          <month>08</month>
          <day>13</day>
          <volume>10</volume>
          <issue>1</issue>
          <fpage>137</fpage>
          <lpage>147</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="http://www.thieme-connect.com/DOI/DOI?10.15265/IY-2015-001"/>
          </comment>
          <pub-id pub-id-type="doi">10.15265/IY-2015-001</pub-id>
          <pub-id pub-id-type="medline">26293861</pub-id>
          <pub-id pub-id-type="pii">me2015-001</pub-id>
          <pub-id pub-id-type="pmcid">PMC4587037</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref28">
        <label>28</label>
        <nlm-citation citation-type="web">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Jamal</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Qi</surname>
              <given-names>G</given-names>
            </name>
          </person-group>
          <article-title>Task agnostic meta-learning for few-shot learning</article-title>
          <source>Proc IEEE Comput Soc Conf Comput Vis Pattern Recognit</source>
          <year>2019</year>
          <access-date>2021-07-13</access-date>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://openaccess.thecvf.com/content_CVPR_2019/papers/Jamal_Task_Agnostic_Meta-Learning_for_Few-Shot_Learning_CVPR_2019_paper.pdf">https://openaccess.thecvf.com/content_CVPR_2019/papers/Jamal_Task_Agnostic_Meta-Learning_for_Few-Shot_Learning_CVPR_2019_paper.pdf</ext-link>
          </comment>
        </nlm-citation>
      </ref>
      <ref id="ref29">
        <label>29</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Gao</surname>
              <given-names>T</given-names>
            </name>
            <name name-style="western">
              <surname>Han</surname>
              <given-names>X</given-names>
            </name>
            <name name-style="western">
              <surname>Zhu</surname>
              <given-names>H</given-names>
            </name>
            <name name-style="western">
              <surname>Liu</surname>
              <given-names>Z</given-names>
            </name>
            <name name-style="western">
              <surname>Li</surname>
              <given-names>P</given-names>
            </name>
            <name name-style="western">
              <surname>Sun</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Zhou</surname>
              <given-names>J</given-names>
            </name>
          </person-group>
          <article-title>FewRel 2.0: towards more challenging few-shot relation classification</article-title>
          <year>2019</year>
          <conf-name>Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP)</conf-name>
          <conf-date>2019</conf-date>
          <conf-loc>Hong Kong</conf-loc>
          <fpage>6251</fpage>
          <lpage>6256</lpage>
          <pub-id pub-id-type="doi">10.18653/v1/d19-1649</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref30">
        <label>30</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Lin</surname>
              <given-names>Y</given-names>
            </name>
            <name name-style="western">
              <surname>Chen</surname>
              <given-names>C</given-names>
            </name>
            <name name-style="western">
              <surname>Lee</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Li</surname>
              <given-names>Z</given-names>
            </name>
            <name name-style="western">
              <surname>Zhang</surname>
              <given-names>Y</given-names>
            </name>
            <name name-style="western">
              <surname>Xia</surname>
              <given-names>M</given-names>
            </name>
            <name name-style="western">
              <surname>Shruti</surname>
              <given-names>R</given-names>
            </name>
            <name name-style="western">
              <surname>He</surname>
              <given-names>J</given-names>
            </name>
            <name name-style="western">
              <surname>Zhang</surname>
              <given-names>Z</given-names>
            </name>
            <name name-style="western">
              <surname>Ma</surname>
              <given-names>X</given-names>
            </name>
          </person-group>
          <article-title>Choosing transfer languages for cross-lingual learning</article-title>
          <year>2019</year>
          <conf-name>Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics</conf-name>
          <conf-date>2019</conf-date>
          <conf-loc>Florence</conf-loc>
          <fpage>3125</fpage>
          <lpage>3135</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://aclanthology.org/P19-1301.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.18653/v1/p19-1301</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref31">
        <label>31</label>
        <nlm-citation citation-type="confproc">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Ruder</surname>
              <given-names>S</given-names>
            </name>
            <name name-style="western">
              <surname>Søgaard</surname>
              <given-names>A</given-names>
            </name>
            <name name-style="western">
              <surname>Vuli</surname>
              <given-names>I</given-names>
            </name>
          </person-group>
          <article-title>Unsupervised cross-lingual representation learning</article-title>
          <year>2019</year>
          <conf-name>Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics: Tutorial Abstracts</conf-name>
          <conf-date>2019</conf-date>
          <conf-loc>Florence</conf-loc>
          <fpage>31</fpage>
          <lpage>38</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://aclanthology.org/P19-4007.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.18653/v1/p19-4007</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref32">
        <label>32</label>
        <nlm-citation citation-type="journal">
          <person-group person-group-type="author">
            <name name-style="western">
              <surname>Pan</surname>
              <given-names>SJ</given-names>
            </name>
            <name name-style="western">
              <surname>Yang</surname>
              <given-names>Q</given-names>
            </name>
          </person-group>
          <article-title>A survey on transfer learning</article-title>
          <source>IEEE Trans Knowl Data Eng</source>
          <year>2010</year>
          <month>10</month>
          <volume>22</volume>
          <issue>10</issue>
          <fpage>1345</fpage>
          <lpage>1359</lpage>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="http://www-edlab.cs.umass.edu/cs689/reading/transfer-learning.pdf"/>
          </comment>
          <pub-id pub-id-type="doi">10.1109/tkde.2009.191</pub-id>
        </nlm-citation>
      </ref>
      <ref id="ref33">
        <label>33</label>
        <nlm-citation citation-type="web">
          <source>Genealogical knowledge graph</source>
          <access-date>2021-07-19</access-date>
          <comment>
            <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://github.com/KaiHe-better/Genealogical-Knowledge-Graph">https://github.com/KaiHe-better/Genealogical-Knowledge-Graph</ext-link>
          </comment>
        </nlm-citation>
      </ref>
    </ref-list>
  </back>
</article>
