Repositories & submitters

Two kinds of record stand a little apart from your tree: a repository is the archive that holds a source, and the submitter is whoever compiled the file. These recipes cover both — building a repository, pointing a source at it with a call number, naming the compiler, and recording address, phone, email, and web details correctly in each version.

New to reading GEDCOM lines? Skim How GEDCOM works first — every recipe shows the underlying lines, but the app writes them for you as you type.

Create a repository (archive) record

The structure. A repository is a REPO record — the institution or person holding a source. The smallest useful one is an id and a name:

0 @R1@ REPO
1 NAME State Archives of Anytown
1 ADDR 12 Record Street
2 CITY Anytown
2 CTRY USA

The address is optional; the name is what every other view keys off.

In the app. Use Add Record (in the Edit menu, or the split button in the toolbar) and choose REPO – Repository. A new tab opens with a starter record. Autocomplete then offers NAME, an address block, and the contact tags valid for your file’s version beneath the record. Look up the record’s full valid structure any time in the spec viewer.

Across versions. The REPO record exists in 5.5, 5.5.1, and 7.0, but one detail tightened over time:

In 5.5, NAME is optional ({0:1}) — a REPO with only an address is technically valid.
In 5.5.1 and 7.0, NAME is required ({1:1}) — a repository with no name is flagged.

The contact tags also differ by version; see Record contact details below for the specifics.

Validation notes. The cross-reference id (@R1@) must be unique in the file — Linea Codex assigns one for you. A nameless REPO is fine in 5.5 but flagged in 5.5.1 and 7.0. A repository that nothing points to is valid but orphaned; the next recipe wires one to a source.

See also: Link a source to the repository that holds it · Add Record (Edit menu and toolbar).

Link a source to the repository that holds it

Goal. Connect a source record to the archive that holds the original, and note the shelf or catalog number you’d quote to retrieve it.

The structure. Inside the SOUR record, a REPO line points to the repository record, and a CALN (call number) records where the item sits in that archive’s holdings:

0 @S1@ SOUR
1 TITL Parish register, 1801–1850
1 REPO @R1@
2 CALN MS 1842/3
3 MEDI book

The REPO value is a pointer (@R1@), not a name — it names the REPO record you created above. CALN is the call number; an optional MEDI under it notes the medium — a value from the standard set (book, fiche, film, electronic, and so on), lowercase in 5.5/5.5.1 and uppercase (BOOK, …) in 7.0. A source may also carry a plain note here alongside the pointer.

In the app. In the source record, add a REPO line; autocomplete offers it, and because the value is a pointer the editor proposes the repository records already in your file. ⌘/Ctrl-click the pointer to jump to the repository it names. From the repository’s side, the inspector’s Sources held panel lists every source that names it — its empty state reads “No sources name this repository.”, which is your cue the link isn’t wired yet.

Across versions. The SOUR → REPO pointer with CALN is structurally the same in all three versions:

The citation is REPO @<XREF:REPO>@, with CALN {0:M} (you may list several call numbers) and a MEDI {0:1} under each.
In 5.5 / 5.5.1, MEDI is the source-media-type value as those versions define it.
In 7.0, MEDI became an enumeration with an optional PHRASE to describe a value outside the list. The 7.0 spec also clarifies that a call number “may contain any character, not just digits” — so MS 1842/3 is fine.

Validation notes. The REPO pointer must resolve to an actual REPO record — a dangling pointer is flagged (the inspector marks it (missing record)). CALN only makes sense beneath a REPO citation; in 7.0 a MEDI value outside the enumeration should carry a PHRASE. The pointer lives in the source, not the repository — repositories don’t list their own holdings inline.

Record who compiled the file

Goal. Name the person or organization who assembled this GEDCOM — the file’s author of record — and link the header to them.

The structure. The compiler is a SUBM (submitter) record with a NAME, plus optional contact details. The file’s HEAD then points at it:

0 HEAD
1 SUBM @U1@
0 @U1@ SUBM
1 NAME Jane Smith
1 ADDR 5 Quill Lane
2 CITY Anytown
2 CTRY USA

HEAD.SUBM is the default author for the whole file. Individual records can carry their own SUBM pointer to credit a different contributor, but most files have just the one.

In the app. Use Add Record and choose SUBM – Submitter to create the record, then add a SUBM pointer under HEAD to wire it as the file’s submitter. The submitter’s NAME and contact block fill in exactly like a repository’s. The inspector surfaces the submitter under its own view; its notes panel uses the phrasing “on this submitter”.

Across versions. This is the most version-sensitive corner of the chapter — the header pointer’s requirement changed:

5.5 — HEAD.SUBM is required ({1:1}). Every 5.5 file must declare a submitter record, and the header must point to it. A 5.5 file with no SUBM is non-conformant.
5.5.1 — HEAD.SUBM is still required ({1:1}).
7.0 — HEAD.SUBM is optional ({0:1}). A 7.0 file may omit the submitter entirely.

The SUBM record itself has NAME as required ({1:1}) in every version. Converting a file up to 7.0 is straightforward; converting down to 5.5 / 5.5.1, the converter will keep an existing submitter and warn if one is missing, since those versions require it — best-effort, and it never invents a person for you.

Validation notes. In a 5.5 or 5.5.1 file, a missing HEAD.SUBM (or a SUBM pointer that doesn’t resolve) is flagged; in 7.0 it isn’t. A SUBM record with no NAME is flagged in all versions. If you need to credit several contributors, add extra SUBM records and point individual records at them rather than overloading one submitter.

See also: How GEDCOM works (the header and HEAD.SUBM) · Record contact details.

Record contact details — address, phone, email, web

Goal. Attach a postal address, phone, email, fax, or web page to a repository or submitter (the same address block also appears under a header’s CORP and under events).

The structure. An address is an ADDR line — the full mailing label — with optional structured pieces beneath it, followed by the other contact tags:

1 NAME State Archives of Anytown
1 ADDR 12 Record Street
2 CITY Anytown
2 STAE Anystate
2 POST 00000
2 CTRY USA
1 PHON +1 555 0100
1 EMAIL archives@example.org
1 WWW https://archive.example.org

ADDR — the formatted address; CONT continues it onto more lines.
ADR1 / ADR2 (and ADR3 from 5.5.1 on) — the street-address lines, broken out.
CITY, STAE, POST, CTRY — city, state/province, postal code, country.
PHON, EMAIL, FAX, WWW — phone, email, fax, web page.

In the app. Autocomplete offers the address pieces beneath ADDR, and offers PHON / EMAIL / FAX / WWW only when the version allows them — so in a 5.5 file you simply won’t be offered email, fax, or web. Type the formatted address on the ADDR line; the editor wraps and continues long values for you.

Across versions. Two things change — which contact tags exist, and where they attach:

5.5 has ADDR (with ADR1, ADR2, CITY, STAE, POST, CTRY) and PHON only. There is no EMAIL, FAX, or WWW in 5.5 — record those in a note if you need them.
5.5.1 added EMAIL, FAX, and WWW (and ADR3) to the address structure. In 5.5 and 5.5.1, PHON / EMAIL / FAX / WWW live inside the address structure, each repeatable up to three times ({0:3}).
7.0 keeps all of ADDR, ADR1–ADR3, CITY, STAE, POST, CTRY, plus PHON, EMAIL, FAX, WWW — but the contact tags moved out of the address structure. In 7.0 they are direct children of the record (the REPO, SUBM, or header CORP), siblings of ADDR rather than nested under it, and each may repeat any number of times ({0:M}). The lines you write look the same; only their parent differs. Conversion rewrites the nesting for you — best-effort.

Validation notes. EMAIL / FAX / WWW in a 5.5 file are flagged — those tags don’t exist there. The structured address pieces (CITY, STAE, …) are valid only beneath an ADDR, and the ADDR payload itself is the authoritative mailing label — the pieces are for indexing and sorting, not a replacement. To clear a tag the whole document doesn’t support — say, stripping EMAIL/WWW before downgrading to 5.5 — reach for Transform Nodes (the transform panel) rather than editing every record by hand; the in-editor quick-fixes are limited spot-fixes, not a sweep.

See also: Notes (for contact info a version can’t structure) · Bulk transforms · The spec viewer.

Next: extending the standard for data it doesn’t cover → When GEDCOM has no tag for it.