Sources & citations

A claim in a tree is only as good as the evidence behind it. GEDCOM lets you describe a source once and then cite it from every fact it supports — a birth date, a name, a marriage — attaching the page, the quoted text, and an assessment of how trustworthy it is. These recipes go from creating a source record to deciding when you even need one.

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 source record

The structure. A source is a SOUR record at level 0, with a cross-reference id. The common pieces are a title, an author, and publication facts:

0 @S1@ SOUR
1 TITL Massachusetts Vital Records, 1841–1910
1 AUTH Commonwealth of Massachusetts
1 PUBL Boston: State Archives, 1985
1 ABBR Mass. Vital Records

This describes the whole source. Where in it a particular fact lives — a page, an entry — belongs in the citation, not here (see Add citation detail).

In the app. Use Add Record (in the Edit menu, or the split button in the toolbar) and choose SOUR – Source. A new tab opens with a starter record ready to fill in. Add TITL, AUTH, PUBL, and the rest as child lines; autocomplete offers exactly the tags valid beneath SOUR. The inspector shows a Citations panel on a source record listing every fact that cites it.

Across versions. SOUR records exist in 5.5, 5.5.1, and 7.0 with the same core fields — TITL, AUTH, ABBR, PUBL, TEXT, repository citations, REFN. The differences are small and mostly about text encoding:

5.5 / 5.5.1 wrap long TITL/AUTH/PUBL/TEXT values across CONC/CONT lines and cap a line at 255 characters.
7.0 removed CONC and the line limit, and adds MIME/LANG under TEXT to declare the text’s media type and language. It also folds REFN/UID/EXID into a shared identifier block.

Validation notes. The id (@S1@) must be unique in the file — Linea Codex assigns one. A source with no TITL is valid but unhelpful, since every citation and the inspector key off the title. The checker flags 7.0-only substructures (MIME, LANG, UID) if they appear in a 5.5 / 5.5.1 file.

Cite a source from a fact

The structure. A source citation is a SOUR line that points to a source record by its id. It nests under whatever it supports — a birth, a name, a death:

1 BIRT
2 DATE 12 MAR 1832
2 PLAC Boston, Massachusetts, USA
2 SOUR @S1@

The same citation block has the same shape everywhere it appears — under an event, a name, a place. Learn it once and you can attach it anywhere (this is the reusable-block idea from How GEDCOM works).

In the app. Add a SOUR line beneath the fact in the editor; autocomplete offers it wherever a citation is valid. Type @ and the xref hints suggest existing source records by title, so you point at the right @S1@ without memorising ids. ⌘/Ctrl-click the pointer to jump to the source record it names. On any record, the inspector’s Sources panel lists every citation attached to it.

Across versions. The pointer form — SOUR @S1@ — is identical in 5.5, 5.5.1, and 7.0. What differs is the non-pointer form, covered in Source records vs. inline citations: 5.5 and 5.5.1 let a citation carry a free-text source description instead of a pointer; 7.0 removed that option — a 7.0 citation must point to a source record (or to a deliberate “no record” pointer).

Validation notes. A citation pointing at an id that no record defines is flagged as a broken reference — the inspector marks it (missing source). A citation is permissive about where it sits; the checker warns, it never blocks. To point a citation at “no record on purpose” in 7.0, use the void pointer (SOUR @VOID@) and put the description in PAGE — the inspector labels this (no source — see citation).

Add citation detail (page, quoted text, data)

The structure. A bare pointer says which source; the detail tags say where in it and what it said. PAGE locates the material; a DATA block holds the entry’s DATE and the TEXT quoted from the source:

2 SOUR @S1@
3 PAGE Vol. 4, p. 212, entry 87
3 DATA
4 DATE 14 MAR 1832
4 TEXT Born to John and Mary Smith, a daughter, Jane.

PAGE is free text — a page, a volume and entry, a URL fragment. DATA groups facts about the record entry itself: DATE is when the entry was recorded (not the event date), and TEXT is the verbatim quotation.

In the app. Add PAGE, DATA, DATE, and TEXT as child lines of the citation; autocomplete offers each where it’s valid. The inspector’s Sources panel renders these for you — Page, the Recorded date, and the Source text — so you can read a citation’s detail without expanding the raw lines.

Across versions. The pieces are stable across versions, with one structural change in 7.0:

5.5 / 5.5.1 — PAGE, plus a DATA block containing DATE and TEXT. Long TEXT wraps across CONC/CONT. An EVEN line (what event the material recorded) sits directly under the citation, with ROLE (the person’s role) nested beneath that EVEN.
7.0 — same PAGE and DATA/DATE/TEXT, but TEXT now takes optional MIME and LANG children, EVEN and ROLE became enumerated values (each with an optional PHRASE), and CONC is gone — long text uses CONT only.

Converting between versions rewrites CONC/CONT correctly and carries PAGE/DATA/TEXT across; dropping a 7.0 MIME/LANG when downgrading to 5.5.1 is best-effort, not lossless.

Validation notes. PAGE, DATA, and the DATE/TEXT inside DATA each appear at most once per citation (TEXT may repeat). The DATA-level DATE is the recording date — don’t confuse it with the event’s own DATE. Look up the citation’s valid substructure in the spec viewer (right-click a line → Show in Specification) when you’re unsure what nests where.

See also: Record how reliable a citation is · Dates & places (the DATE formats) · The spec viewer.

Record how reliable a citation is

Goal. Attach your judgement of how trustworthy the evidence is, so conflicting claims can be ranked.

The structure. QUAY (quality of data) holds a single digit, 0–3:

2 SOUR @S1@
3 PAGE Vol. 4, p. 212, entry 87
3 QUAY 3

The four values are a fixed scale:

0 — unreliable or estimated
1 — questionable (interviews, census, oral genealogy, potential bias)
2 — secondary evidence (recorded some time after the event)
3 — direct and primary evidence

In the app. Add a QUAY line under the citation; autocomplete offers exactly 0–3. The inspector’s Sources panel shows this as Confidence, rendered as a three-dot cluster — three filled dots is QUAY 3, all hollow is QUAY 0.

Across versions. QUAY exists in 5.5, 5.5.1, and 7.0, and the four values mean the same thing in each — the scale is stable across all three. The only nuance is how the spec types it: 5.5 / 5.5.1 define the payload as the literal set 0 | 1 | 2 | 3; 7.0 formalises it as an enumeration with the same four members. Although the values look like integers, they carry no numeric meaning — 3 is not “greater than” 1, just a different rank.

Validation notes. QUAY appears at most once per citation, and the value must be one of 0–3 — a QUAY 4 or QUAY high is flagged as an invalid enumerated value in every version. QUAY is your assessment of the citation, not of the source record; it belongs on the citation, not on the SOUR record.

See also: Add citation detail · Validation.

Attach an image or document to a source or citation

Goal. Link a scan — a photographed register page, a PDF of a certificate — to the source it came from, or to the specific citation that used it.

The structure. A multimedia link (OBJE) can point at a multimedia record, or carry the file inline. It attaches under a source record or under a citation:

0 @S1@ SOUR
1 TITL Massachusetts Vital Records, 1841–1910
1 OBJE @O1@

Or inline on a citation, naming the file directly:

5.5.1:

2 SOUR @S1@
3 PAGE Vol. 4, p. 212
3 OBJE
4 FILE images/birth-1832.jpg
5 FORM jpg
6 MEDI photo

5.5 (the inline link is flatter — FORM sits beside FILE, and there is no inline MEDI):

2 SOUR @S1@
3 PAGE Vol. 4, p. 212
3 OBJE
4 FORM jpeg
4 FILE images/birth-1832.jpg

7.0:

2 SOUR @S1@
3 PAGE Vol. 4, p. 212
3 OBJE @O1@

In the app. Create the media with Add Record → OBJE – Multimedia, then add an OBJE @O1@ line under the source or citation; xref hints suggest existing multimedia records. The media files view manages the actual files in your project. The inspector’s Sources panel shows an image-count badge on citations that carry attachments.

Across versions. A multimedia link is {0:M} — any number — under both the source record and the citation in all three versions, but how a file is named differs sharply:

5.5 — OBJE may be a pointer (OBJE @O1@) or inline; inline, FORM and FILE sit side by side under the link (no nested MEDI), and FORM is a short code like jpeg.
5.5.1 — the same pointer-or-inline choice, but the inline link nests FILE ▸ FORM ▸ (optional) MEDI, and FORM is a short code like jpg.
7.0 — the inline form was restructured around a multimedia record; the practical, portable pattern is to point at an OBJE record (OBJE @O1@) and let that record hold the FILE/FORM. The FORM in 7.0 is a media type (e.g. image/jpeg), not a 5.5-style extension code.

Converting a 5.5 inline OBJE to 7.0 reshapes it toward the record-plus-pointer model and maps FORM codes to media types — best-effort, and any embedded binary BLOB is lowered to a FILE reference rather than dropped (see Multimedia).

Validation notes. An OBJE @O1@ pointing at no record is a broken reference. A 5.5-style inline OBJE (a bare FORM extension code) in a 7.0 file is flagged, and a 7.0 media-type FORM in a 5.5 file is too. The full attach mechanics — files, formats, BLOB handling — live in Multimedia.

See also: Multimedia · Managing media files · Create a source record.

Source records vs. inline citations — which to use

Goal. Decide whether to make a reusable SOUR record or describe the source right inside the citation — and know which versions even allow the inline form.

The structure. The record-and-pointer form (preferred everywhere) describes the source once and cites it by id:

0 @S1@ SOUR
1 TITL Massachusetts Vital Records, 1841–1910

0 @I1@ INDI
1 BIRT
2 SOUR @S1@
3 PAGE Vol. 4, p. 212

The inline form — a SOUR whose value is the source description itself, with no pointer — exists only in 5.5 / 5.5.1:

5.5 / 5.5.1 only:

1 BIRT
2 SOUR Massachusetts Vital Records, 1841–1910, Vol. 4, p. 212
3 TEXT Born to John and Mary Smith, a daughter, Jane.

In the app. Linea Codex favours the record-and-pointer form: Add Record → SOUR – Source creates the record, and SOUR @…@ cites it, with xref hints and ⌘/Ctrl-click navigation. If you import a file that uses inline descriptions, they’re preserved; the inspector still surfaces their TEXT under the Sources panel.

Across versions. This is the sharpest version difference in this chapter:

5.5 / 5.5.1 — a citation may be either a pointer (SOUR @S1@) or an inline description (SOUR <text> with its own TEXT, OBJE, NOTE). The spec calls the inline form non-preferred and expects receivers to promote it into a real source record.
7.0 — the inline description form was removed. Every 7.0 citation must point to a source record; for a citation with no underlying record, use the void pointer (SOUR @VOID@) and put the description in PAGE.

Because of this, converting a 5.5 / 5.5.1 file’s inline citations up to 7.0 is best-effort: the converter promotes each inline description into a generated source record (or a void-pointer citation) so the result is valid 7.0 — it can’t keep the inline shape, because 7.0 has no such shape. Converting 7.0 down keeps the pointer form, which both older versions accept.

Validation notes. An inline SOUR <text> citation in a 7.0 file is flagged — the form isn’t valid there. In 5.5 / 5.5.1 it’s accepted but non-preferred. As a rule of thumb: if you cite a source more than once, make it a record; the moment you’d repeat the same description in two citations, the record-and-pointer form pays off. The app never blocks the inline form where a version allows it — it warns, leaving the choice to you.

Next: annotating any record with free text → Notes.