Skip to content

Repository Entity

← Back to Entity Types

Overview

A Repository entity represents an institution, archive, library, or organization that holds genealogical sources. Repositories provide the physical or virtual location where evidence is housed and can be accessed.

File Format

All GENEALOGIX files use entity type keys at the top level:

yaml
# Any .glx file (commonly in repositories/ directory)
repositories:
  repository-national-archives:
    name: "The National Archives"
    type: archive
    website: "https://www.nationalarchives.gov.uk"

Key Points:

  • Entity ID is the map key (repository-national-archives)
  • IDs can be descriptive or random, 1-64 alphanumeric/hyphens

Core Concepts

Repository Types

GENEALOGIX supports various repository types:

  • Archive: Government or historical archive (national, regional, local)
  • Library: Public, university, or specialty library
  • Museum: Museum with genealogical collections
  • Registry: Civil registration office or vital records office
  • Database: Online genealogical database service
  • Church: Church or religious organization archives
  • Historical Society: Local historical society
  • University: University special collections or archives
  • Government Agency: Government record-keeping agency
  • Other: Other institution type

See Vocabularies - Repository Types for:

  • Complete list of standard repository types
  • How to add custom repository types
  • Vocabulary file structure and examples

Fields

Required Fields

FieldTypeDescription
Entity ID (map key)stringUnique identifier (alphanumeric/hyphens, 1-64 chars)
namestringName of the repository

Optional Fields

FieldTypeDescription
typestringRepository type (see types above)
addressstringPhysical address
citystringCity/town
state_provincestringState or province
postal_codestringPostal/zip code
countrystringCountry
websitestringURL to repository website
propertiesobjectVocabulary-defined properties (see below)
notesstringFree-form notes

Design note: Address fields (address, city, state_province, postal_code, country) are kept as direct entity fields rather than properties because they are core identifying attributes of a repository, analogous to name. They are not expected to change over time or vary by context, unlike contact details (phones, emails) which are in properties.

Note: Properties defined with multi_value: true in the vocabulary (such as phones, emails, holding_types) accept either a single string value or a YAML array. A single string is treated as a one-element array. Examples below use single strings for brevity; use arrays when multiple values are needed.

Properties

Contact information and access details are stored in the properties field. The following are standard properties from the default vocabulary; archives can define additional properties by extending the vocabulary:

PropertyTypeDescription
phonesstring[]Phone number(s) for the repository
emailsstring[]Email address(es) for the repository
faxstringFax number
access_hoursstringHours of operation/access
access_restrictionsstringAny restrictions on access
holding_typesstring[]Types of materials held
external_idsstring[]External identifiers (FamilySearch, WikiTree, etc.)

See Vocabularies - Repository Properties for the full vocabulary definition.

Usage Patterns

Simple Local Repository

yaml
repositories:
  repository-leeds-library:
    name: "Leeds Library - Local Studies"
    type: library
    address: "Market Street"
    city: "Leeds"
    state_province: "Yorkshire"
    country: "England"
    website: "https://www.leeds.gov.uk/libraries"
    properties:
      phones: "+44 113 247 6000"

National Archive

yaml
repositories:
  repository-tna:
    name: "The National Archives"
    type: archive
    address: "Kew, Richmond"
    city: "London"
    country: "England"
    website: "https://www.nationalarchives.gov.uk"
    properties:
      phones: "+44 20 8876 3444"
      emails: "enquiry@nationalarchives.gov.uk"
      access_hours: "Monday-Friday 9am-5pm"
      holding_types:
        - "government records"
        - "microfilm"
        - "digital images"
      access_restrictions: "Some records require appointment"

Online Database

yaml
repositories:
  repository-ancestry:
    name: "Ancestry.com"
    type: database
    website: "https://www.ancestry.com"
    properties:
      access_hours: "24/7"
      holding_types:
        - "census records"
        - "vital records"
        - "military records"
        - "church records"
        - "newspapers"
      access_restrictions: "Subscription required"

Church Archive

yaml
repositories:
  repository-stpauls:
    name: "St Paul's Cathedral Archive"
    type: church
    address: "St Paul's Churchyard"
    city: "London"
    country: "England"
    properties:
      phones: "+44 20 7246 8348"
      emails: "archive@stpauls.co.uk"
      holding_types:
        - "parish registers"
        - "marriage records"
        - "baptismal records"
        - "manuscripts"
      access_restrictions: "By appointment only"

Repository in Sources

Repositories are referenced from Source entities:

yaml
sources:
  source-tna-wills:
    title: "Wills and Probate Records"
    repository: repository-tna
    description: "Wills proved in the Prerogative Court of Canterbury"

File Organization

Note: File organization is flexible. Entities can be in any .glx file with any directory structure. The example below shows one-entity-per-file organization, which is recommended for collaborative projects (better git diffs) but not required.

Repository files are typically stored in a repositories/ directory:

repositories/
├── archives/
│   ├── repository-tna.glx
│   ├── repository-spa.glx
│   └── repository-local.glx
├── libraries/
│   ├── repository-bm.glx
│   └── repository-leeds.glx
├── churches/
│   ├── repository-stpauls.glx
│   └── repository-westminster.glx
├── online/
│   ├── repository-ancestry.glx
│   ├── repository-familysearch.glx
│   └── repository-findmypast.glx
└── other/
    └── repository-custom.glx

Validation Rules

GEDCOM Mapping

GLX FieldGEDCOM TagNotes
Entity ID (map key)(synthetic)Not in GEDCOM
nameREPO.NAMERepository name
addressREPO.ADDRRepository address
websiteREPO.WWWWebsite (non-standard)
properties.phonesREPO.PHONPhone number(s)
properties.emailsREPO.EMAILEmail address(es)
properties.external_idsREPO.EXIDExternal identifiers (GEDCOM 7.0)

Access Information

Best practices for recording repository access:

  • Include both physical address and website URL if applicable
  • Note any access restrictions in properties.access_restrictions
  • Record hours of operation in properties.access_hours
  • Include contact details in properties.phones and properties.emails
  • Document types of materials held in properties.holding_types
  • Source: References specific collections within repositories
  • Citation: May reference repository location information via Source
  • Holdings: Detailed inventory of materials within repository

Schema Reference

See repository.schema.json for the complete JSON Schema definition.

See Also

Licensed under Apache License 2.0