Beacon v2 model: Ethnicity, Ancestry and Race

[M-casado]

Summary

The Beacon-v2 model handles ethnicity in a, sort of, mixed way with race. This issue is to clarify its use and recommend the addition of ancestry.

Details

While traversing the JSON Schemas of a Beacon-v2 individual (json, yaml), I noticed that the definition for ethnicity is as follows (taken from NCIT:C17049 - Race):

A geographic ancestral origin category that is assigned to a population group based mainly on physical characteristics that are thought to be distinct and inherent.

These terms tend to be extremely mixed in research metadata and health records, and sometimes (wrongfully) used interchangeably.

In my opinion, birthplace (geographicOrigin) and genetic ancestry (ancestry) are the most useful, given how ethnicity and race are inferred. Going back to the origin of this GH issue, I would suggest:

• Swapping ethnicity with race, or changing the definition (and associated terms) of the current ethnicity. This is so that ethnicity no longer includes the physical characteristics associated with race.
• Addition of ancestry at root level of individual's model.
• Using the definitions of HANCESTRO: ethnicity category (HANCESTRO:0601) and ancestry category (HANCESTRO:0004).

Comparison table

Aspect	Ancestry	Ethnicity	Race
Scientific focus	Genetic & genealogical lineage	Shared culture & heritage	Socially constructed grouping
Basis	DNA, pedigree, geographic origin	Language, customs, history	Perceived physical traits; categories socially defined
Who defines / assigns	Biological inheritance & family records	Community / self-identification	Society & governments
Primary research use	Population genetics, disease-allele mapping	Sociocultural & health-behavior studies	Monitoring racial inequities and inferring ancestry through visual inspection
Example label	“Filipino”	"Hispanic or Latin"	“Black or African American”

[mbaudis]

@M-casado Thanks for the nice write-up. I totally support HANCESTRO use and have a clear ethnicity definition with a separate definition of the "race" data (which unfortunately is something frequently reported/requested for U.S. based studies, especially) with a clear labeling and (potentially acerbic) comment.

Btw., we also need a composed ancestry definition - we use this e.g. in cancercelllines.org but probably will add this to the Progenetix data:

https://cancercelllines.org/beacon/individuals/?filters=cellosaurus:CVCL_0030

"genomeAncestry": [
    {"id": "HANCESTRO:0010", "label": "African", "percentage": "64.74"},
    {"id": "HANCESTRO:0013", "label": "Native American", "percentage": "0.77"},
    {"id": "HANCESTRO:0009", "label": "East Asian", "percentage": "2.26"},
    {"id": "HANCESTRO:0007", "label": "South East Asian", "percentage": "0"},
    {"id": "HANCESTRO:0006", "label": "South Asian", "percentage": "0"},
    {"id": "HANCESTRO:0005", "label": "European (North)", "percentage": "19.45"},
    {"id": "HANCESTRO:0005", "label": "European (South)", "percentage": "12.78"}
],

[M-casado]

@mbaudis - Sounds like a plan then 🙌

Based on your experience from having ethnicity modelled in Beacon, would you say the three entities (ethnicity, race and ancestry) are needed together?

Also, I'm not finished with it, but here's the snippet from the FEGA schemas I have as an item of ancestry:

        "ancestryComponent": {
            "type": "object",
            "title": "Ancestry component",
            "description": "Population category of a biomaterial. Defined using ancestry informative markers (AIMs) based on genetic/genomic data.",
            "$comment": "Similar to ethnicity, we could want to be restrictive and validate the ontology term IDs and labels, rather than a plain recommendation.",
            "meta:sssomMappings": [
                {
                "predicate_id": "skos:exactMatch",
                "object_id": "HANCESTRO:0004",
                "mapping_justification": "semapv:LexicalMatching",
                "object_match_field": "rdfs:label",
                "subject_match_field": "rdfs:label",
                "match_string": "ancestry",
                "author_id": ["orcid:0000-0002-7747-6256"],
                "creator_id": ["orcid:0000-0002-7747-6256"],
                "reviewer_id": [""],
                "confidence": 1.0,
                "mapping_date": "2025-04-25"
                }
            ],
            "required": ["term"],
            "properties": {
                "term": {
                    "title": "Ancestry term",
                    "description": "Term encoding the ancestry of the biomaterial. Recommended values come from the 'ancestry category' ([HANCESTRO:0004](http://purl.obolibrary.org/obo/HANCESTRO_0004))",
                    "allOf": [
                        {
                            "title": "Inherited ontologyTerm structure of term id and label",
                            "$ref": "./FEGA.common-definitions.json#/$defs/ontologyTerm"
                        }
                    ]
                },
                "method": {
                    "title": "Method of inference",
                    "description": "Technique or information source used to assign the ancestry. Recommended values come from the Evidence & Conclusion Ontology (ECO) (e.g., ECO:0006395 for 'self-reported ancestry evidence') or the Ontology for Biomedical Investigations (OBI) (e.g., OBI:0200051 for 'principal components analysis dimensionality reduction').",
                    "allOf": [
                        {
                            "title": "Inherited ontologyTerm structure of term id and label",
                            "$ref": "./FEGA.common-definitions.json#/$defs/ontologyTerm"
                        }
                    ],
                    "examples": [
                        {
                            "id": "ECO:0006395",
                            "label": "self-reported ancestry evidence"
                        },
                        {
                            "id": "ECO:0007206",
                            "label": "intermethylated site amplification evidence used in automatic assertion"
                        },
                        {
                            "id": "OBI:0200051",
                            "label": "principal components analysis dimensionality reduction"
                        }
                    ]
                },
                "proportion": {
                    "type": "number",
                    "title": "Genomic proportion",
                    "description": "Estimated fraction of the genome assigned to this ancestry category, expressed as a value between 0 and 1.",
                    "minimum": 0,
                    "maximum": 1,
                    "examples": [0.72, 0.1]
                  }
                }
            },
            "examples": [
                {
                    "term": {
                        "id": "HANCESTRO:0498",
                        "label": "Filipino"
                    },
                    "method": {
                        "id": "ECO:0006395",
                        "label": "self-reported ancestry evidence"
                    }
                },
                {
                    "term": {
                        "id": "HANCESTRO:0758",
                        "label": "Basque in France (HGDP)"
                    },
                    "method": {
                        "id": "ECO:0007206"
                    },
                    "portion": 0.4
                }
            ]
        }

[mbaudis]

This looks like an interesting catch-all since one can combine the different assertions in one parameter and then filter by method. So if one has e.g. a 7 ancestries model (like ours above) + some other annotations one could pull out the components (like above) by label.
One question here is if such an object could combine all the ethnicity/race/ancestry assertions since the method could be good enough for labeling; instead of treating them like separate concepts on a parameter level (which is fraught with problems since people will be inconsistent in their bucket use).

[M-casado]

if such an object could combine all the ethnicity/race/ancestry assertions

My personal opinion, based on their definitions, is that they are semantically different concepts. If they were to be merged under one umbrella term, it would require a type field. For example, type: ancestry or type: ethnicity, to differentiate.

since people will be inconsistent in their bucket use

I think people will be inconsistent regardless: if they are separate terms, they'll be used interchangeably if one is not careful with the right constraints; if they are all a single term with a type, the type will be "whatever" from the POV of some submitters.

Therefore, I think the key is to properly document each, and provide meaningful yet simple examples. Furthermore, requesting portion for ancestry will "likely" discourage users from giving "subjective human evaluations" as ancestries. This is to say, one can create constraints that make the user rethink the use of a property if they "missed" its documentation at first glance.

[mbaudis]

I completely agree; it is just the "merge or not". Btw., there was a lively discussion on the Phenopackets / implementers cal yesterday where this was brought up as one of the "better define outside of a single standard & then adopt" issues. IMO, any solution (separate fields or labels by methods/type) which acknowledges the different assessments is file w/ me:

• Single list of objects is more flexible and one can e.g. limit "type" or "method" values; and easier to query, esp. for heterogeneous collections.
• Separate parameters are more verbose and deterministic in I/O.