Shared events

[dthaler]

• Are we planning to add witnesses or shared events? This is handled by custom extensions; TMG, RootsMagic, FamilyHistorian support it. Allowing these to be records supports "Event"-like structures that do not have a single owning INDI.

Originally posted by @tychonievich in #747

[dthaler]

This is one piece of issue #663 (2. gedcom-occurrences v0.2.1), split out into this issue to be more granular.

[dthaler]

Discussion in GEDCOM Steering Committee:

• There are many potential examples of shared events, GRAD, or funeral attendees, or CENS, etc.
• Unclear whether this would be breaking or not. If not, it might be an instance where the 8.0 solution would be different from a 7.1 solution, so would want input on whether we would want to change it twice, or just wait until 8.0. (Similar to the _LOC discussion.)
• Is there a desire to store (in GEDCOM) events that have no individuals associated? E.g., historical events. Or is keeping those in external databases and sites sufficient?
• More community input on these topics is welcome.

[Norwegian-Sardines]

The concept of a "shared event" is not new to GEDCOM. In v5.0 of GEDCOM we had a SOURCE_EVENT_RECORD that was defined as:

This structure represents event-oriented information that may be used as evidence for submitter' opinions or conclusions expressed in INDIVIDUAL and FAMILY records.

This concept would/should also incorporate the witness concept so that all participants in the event can have a documented connection!

n @XREF:EVEN@ <EVENT_TAG> <EVENT_DESCRIPTOR>
+1 DATE <DATE_VALUE> {0:1}
+1 PLAC <PLACE_VALUE> {0:1}
+1 <ROLE_TAG> <ROLE_DESCRIPTOR> {0:M}
+2 <<INDIVIDUAL>> {0:1}
+2 AGE <AGE_VALUE> {0:1}

Attributes were, at the time, part of the INDIVIDUAL_RECORD and defined only as a TAG and a "description" not date or place! For example: 1 OCCU Farmer

As far as historical events, the software I use does have these type of events, but they can get complicated/overwelming when historical events get included for multiple countries. If GEDCOM had a "PLAC" record that anchored these events they can be treated more like an individual or family in reports and online displays!

[mother10]

This shared event discussion touches on something I've been working on intensively! 🎯

As I mentioned in a recent conversation, some "problems" actually dissolve when you rethink the fundamental structure - the same is true here for shared events. Instead of treating events as properties of individuals (which creates the duplication/citation nightmare), consider this approach:

The event IS the source document itself - a TEMPLATE record. A graduation ceremony? That's one template record containing what the actual program/certificate/announcement says. A census page? One template record with the document's content exactly as written. 📄

Each participant's data becomes a STICKY record - a snapshot of that person at that moment, extracted from the template. John's graduation data from the ceremony? One sticky pointing to the graduation template. Mary's data from the same ceremony? Another sticky, also pointing to that same template. 👥

One template, multiple stickies. No duplication. No citation scatter. No inconsistency about when/where the event occurred. ✨

This naturally handles everything you're discussing:

• Graduation with 50 students? One template (the ceremony), sticky records only for the people you actually want to document in your GEDCOM file - maybe just your 3 ancestors who attended. 🎓
• Census with entire household? One template (the census page), one sticky per person you're tracking. 📊
• Funeral attendees? One template (funeral record), stickies for whomever you choose to document. ⚰️

The beauty is you're NOT obligated to create stickies for every participant mentioned in the source. You document who matters to YOUR genealogy. That's a user's choice, always.

To @Norwegian-Sardines' point about SOURCE_EVENT_RECORD from v5.0: Yes! That concept was pointing in the right direction - recognizing that events exist independently of individuals. The template/sticky structure takes it further by cleanly separating "what the document says" (template) from "what this means for this person" (sticky). 📜

@dthaler asked: "Is there a desire to store events that have no individuals associated?"

This is where templates show their flexibility! You could absolutely create templates for historical events without any participants - disasters, epidemics, political changes, dynastic periods. Imagine: a template for the Great Fire of London, or the reign of Elizabeth I, or the 1918 flu pandemic. 🌋🏛️

Software could then use these timeline templates to display historical context alongside your family tree - showing your ancestors' lives against the backdrop of the events happening around them. It's entirely optional (user's choice!), but the structure supports it naturally without any special cases or extensions. The same template/sticky pattern works whether you're documenting a family gathering or mapping world history. 🌍

This isn't just a workaround for shared events - it's recognizing that our current individual-centric event structure creates problems that don't exist when you start from the source document itself.

(I've documented this in detail in my GEDCOM-8 proposal, issue #680, if anyone wants to see the complete structure.) 📋

[tychonievich]

Discussed in steering committee

• We agree that 5.0 did have something like a shared event, though they did not appear to be connected to INDI and FAM records by pointers in either direction. Many of the ideas used in GEDCOM today did not appear until 5.3.
• We discussed whether this is in scope for 7.1 or needs to wait for 8.0. While adding a new record could be done in 7.1, we are hesitant to introduce two ways to record the same information (e.g. a 7.0-compatible INDI.GRAD and a new GRAD-like record).
• In the annual update meeting it was mentioned that at least three applications (TMG, RootsMagic, and FamilyHistorian) have shared events. However, we have not yet seen example files exported from those or other applications that have these. If anyone knows how existing applications export shared events that would be helpful in making progress on adding these as a next-minor or next-major addition.

[Norwegian-Sardines]

Shared events in Family Historian are by name only. They call family events like marriage a shared event and personal events like Residence are shared by using the "witness" function and a little magic to report the event as shared. Here is an example where the RESI event is "shared" to individuals that where at a residence at the same time. The _SHAR tag indicates that the event is shared with two individuals (in this case the primary person where the RESI is attached, and their spouse). The magic comes in that when a report is written the _SHAR gets assigned to both individuals and (I1 and I2) in a sentence. Person I1 has the RESI tag but person I2 has no reference to the tag so if I2 is exported without I1 then their GEDCOM does not have a RESI tag.

1 RESI
2 DATE 1 JAN 1930
2 PLAC england
2 _SHAR @I2@
3 ROLE Resident
2 _SHAR @I1@
3 ROLE Resident
3 NOTE Here is the one

Not an optimal solution in my mind, we need to create a separate record type that connects participants (we call this a "junction record") with event information. GEDCOM 5.0 kind of does this but includes INDI information that should not be in the "event record"! Modeling this relationship however should allow for some way to include persons that participated in the event but are not part of the family generalogy, for example a boarder living in the home but not being tracked by the the genealogist as a member of the family.

[mother10]

How to solve the above problems in the new GEDCOM8 way:

In the examples there is a TEMPLATE that can function for this "problem".

As you can see the ROLEs of the individuals can be anything we want, family members, boarders etc. (ROLEs are inside the STICKYs, but for clarity I put them as capitals in comments here)

There is absolutely no need to somehow "plaster", use an extension, define a new tag or type or whatever, or any other "trick" to "make this fit" in GEDCOM.
Everything is defined in a straighforward way.
Everything follows the same logic.
No loose ends, no questions, nothing.

Residence Example:

0 @T1920@ TEMPLATE
1 TYPE RESIDENCE, POPCENSUS   /* PopulationCensus */
1 TITL 1920 US Federal Census – Deduction Household
2 PHRASE Household census, with later annotations in margins.
1 SUBM @B001@
1 TORIGIN ORIGDOC
1 QUAY 3
1 DATE 01 JAN 1920
1 SPLAC @SP1000@              /* Boston, Suffolk County, Massachusetts, USA */
1 CENS                        /* Event of the TEMPLATE */
2 TYPE Population
2 DATE 01 JAN 1920
2 SPLAC @SP1000@              /* Boston, Suffolk County, Massachusetts, USA */
2 ADDR
3 123 Main Street
3 CITY Boston
3 STAE MA
3 CTRY USA
1 FLEX REGNUMBER
2 PHRASE Dwelling Number
2 CONTENTS 17A
1 FLEX REGNUMBER
2 PHRASE Household ID
2 CONTENTS 4
1 FLEX ADDRESS
2 PHRASE Street and number
2 CONTENTS 123 Main Street
1 FLEX DESCRIPT
2 PHRASE Page note
2 CONTENTS "Top margin: 'Subdistrict 7A, Sheet 3A, Supervisor: E. Snoreworthy'"
1 ROLES
2 STICKY @ST0100@             /* Barnabas Deduction –  MAIN, HEAD, RESIDENT */
2 STICKY @ST0101@             /* Penny Deduction – SPOUSE, RESIDENT */
2 STICKY @ST0102@             /* Orville Deduction – Son - CHILD, RESIDENT */
2 STICKY @ST0103@             /* Edwina Deduction – Daughter - CHILD, RESIDENT */
2 STICKY @ST0104@             /* Willa Tinywhistle – Orphaned Niece - NIECE, RESIDENT */
2 STICKY @ST0105@             /* Augustus Deduction – Grandfather */
2 STICKY @ST0106@             /* Mabel Scrubbs – Live-in Maid - MAID, RESIDENT */
2 STICKY @ST0107@             /* Augustus Crumb - BOARDER, RESIDENT */
1 NOTE Census household appears orderly. Marginal note mentions: "Excellent curtains."
1 CITA
2 SOUR @S0374@
2 PAGE 5
2 DATA
~  ~ ~
1 CREA 29 APR 2026
1 CHAN 29 APR 2026

Part of the table that defines all kind of residences.

ICO	TYPE	SUBTYPE	Description	TAG
⚓	RESIDENCE	ADDRESS	Document explicitly listing an individual’s residence; e.g. ID card, driver’s license, or utility bill.
⚓	RESIDENCE	CENSUSOTHER	Residence-based census not falling under household or tax types; e.g. lodging census, institutional census.	CENS
⚓	RESIDENCE	DOMICILIECENSUS	Older or regional term for place-based listing; e.g. French "recensement de domicile" showing household occupancy.	CENS
⚓	RESIDENCE	DWELLINGCERT	Official certificate confirming where a person lives; e.g. municipal residence proof, "Wohnsitzbescheinigung".
⚓	RESIDENCE	FARM-OCCU	Farm residency register; e.g. Scandinavian husmann lists or tenant farmer records.
⚓	RESIDENCE	HOUSINGLIST	Urban housing or rental occupancy listing; e.g. Amsterdam housing ledger or rent control rosters.
⚓	RESIDENCE	HOUSEHOLDREG	Record showing residents at a specific address, often over time; e.g. Swedish “husförhörslängd”, Dutch "Bevolkingsregister". (Household register)
⚓	RESIDENCE	MILCENSUS	(MILITARYCENSUS) Enrollment lists tied to place of residence for conscription; e.g. draft boards, military eligibility censuses.	CENS
⚓	RESIDENCE	POPCENSUS	(POPULATIONCENSUS) General household or population census; e.g. U.S. Federal Census, UK census returns.	CENS
⚓	RESIDENCE	REGISTRATION	Government or institutional registry of residence; e.g. Anmeldung in Germany, civil residence registry.
⚓	RESIDENCE	TAXCENSUS	Census used for tax purposes including residence data; e.g. hearth tax lists, poll tax registers.	CENS
⚓	RESIDENCE	OTHER	Any other residence-related record not listed above; must include a PHRASE.

[Norwegian-Sardines]

An “Event” that is shared by multiple individuals can take two basic approaches. Primary to both approaches the event being shared must become a “top level”, independent and normalized record type, which contains all attributes associated with the event, including but not limited to, Type of, Time of, Location of, “sourcing evidence”, Extended Data about, etc.

If we look back at the GEDCOM v5.0 approach (see SOURCE_EVENT_RECORD) we can potentially draw on that view as it includes many of the Aforementioned contents within the design. However, this concept also includes an “denormalized” (redundant) view of the individual by including elements from the INDI record within the shared event record. This denormalized information with be removed from the final design!

Let’s dive into the two basic design approaches for a “shared event” in GEDCOM. In general terms the two approaches differ in how the event attributes are linked to the participants in that event. The first (1) approach links the individual to the event and the second (2) links the event to the individual.

(1) Each individual links to the event requires every participant in the event to contain a pointer element to the event. This relationship is much like the relationships used to relate an event to its Evidence/Source or the Source record to its Repository record.
(2) Each event links to the individuals participating in the event requires the event record to contain a pointer element to every individual participating in the event. GEDCOM does not specifically have relationships designed like this, but it has one important advantage.

Implementing approach (1) could be easy to implement by creating a new structure that is similar to the ASSOCIATION_STRUCTURE which links to the INDIVIDUAL_RECORDand include a Role or Rela subtag defining how that person participated in the event. A possible structure could be:

SHARED_EVENT_STRUCTURE:=
n SEVEN @<XREF:SEVEN>@
+1 ROLE <Enum> {1:1}
+2 PHRASE <Text> {0:1}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M} 

Approach (1) could probably be implemented in GEDCOM v7.1 alongside the current event implementation because it has some of the same feel as the EVEN tag for adding events that are not listed in the standard event set.

Implementing approach (2) places the linkage to the individual within the SHARED_EVENT_RECORD which allows for events to have participants that are both considered part and not part (e.g. clergy, doctors) of the genealogy to be noted in the event.
Let’s take a look at the base SHARED_EVENT_RECORDby looking at the attributes associated with an event.

1. Core Event Identity Attributes
   a. Type
   b. Title
2. Time Attribute
3. Location Attribute
4. Detail/Metadata (Notes, Media, etc)
5. Evidence/Source Attributes

Expanding into a Record (subject to refinement) could look like this:

n @XREF:SEVEN@ 
+1 <EVENT_TAG> {1:1} 
+1 <EVENT_DESCRIPTOR> {0:1}
+1 DATE <DATE_VALUE> {0:1}
+1 PLAC <<PLACE_STRUCTURE>> {0:1}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<MULTIMEDIA_LINK>> {0:M}

Approach (1) may not need anything more than the base record. Approach (2) would need additional information linking the event to the participants in the event because the INDI record does not have a pointer to the event.

n @XREF:SEVEN@ 
+1 <EVENT_TAG> {1:1} 
+1 <EVENT_DESCRIPTOR> {0:1}
+1 DATE <DATE_VALUE> {0:1}
+1 PLAC <<PLACE_STRUCTURE>> {0:1}
+1 INDI @<XREF:INDI>@   {1:1}
  +2 PHRASE <Text  {0:1}
  +2 ROLE <Enum {1:1}
     +3 PHRASE <Text> {0:1} 
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<MULTIMEDIA_LINK>> {0:M}

This structure would allow for individuals to be included in the event that are not part of the genealogy (e.g. clergy, doctors, boarders, etc.) for example:

0 @SEVEN@
1 EVEN CENS
1 DESC 1930 US Census
1 DATE 1 JAN 1930
1 PLAC 1313 Mockingbird Ln, Any Town, My State, USA
1 INDI @I1@
2 ROLE OTHER
3 PHRASE Head
1 INDI @I2@
2 ROLE WIFE
1 INDI @VOID@
2 PHRASE Ole Johanssen
2 ROLE OTHER
3 PHRASE Boarder

[fisharebest]

In addition to the ROLE, the individual-event link structure should also contain the AGE tag.

[Norwegian-Sardines]

In addition to the ROLE, the individual-event link structure should also contain the AGE tag.

I agree!

[dthaler]

Discussion in GEDCOM Steering Committee:

• When a shared record is done, there could be pointers from other records (especially individuals) to the shared record, or pointers from the shared record to other records, or both. In general the committee does not want to add bidirectional links, so one of the other two approaches would be chosen if standardized.
• Putting the pointers in the shared records allow @VOID@ as noted in others' comments, so that direction is preferred.
• There is at least one other shipping application that supports shared records specific to censuses (using extensions registered in the GEDCOM-registries repository). It used (for GEDCOM 5.5.1) bidirectional pointers, with information about the linkage under the shared record pointer to the individual (rather than under the individual's pointer to the shared record). It does support AGE and ROLE, among other things like FACT etc.
• We appreciate the details of Family Historian presented by @Norwegian-Sardines and look forward to seeing details about other applications.

[mother10]

I'm curious if anyone else noticed the relationship between what @Norwegian-Sardines describes above and what I wrote last year in my template proposal, and if so, can anyone explain what the difference between those approaches might be?

To help explain what I mean:

My proposal (PR #680, submitted August 2025): - Proposed new TEMPLATE records as separate top-level records that connect participants - Explained how to include non-family participants (boarders, clergy, etc.) - Designed pointers FROM template TO participants - Provided complete working examples

@Norwegian-Sardines' post (above): - Proposes new "junction record" as separate top-level record that connects participants - Explains how to include non-family participants (boarders, etc.) - Proposes pointers FROM event TO participants - Similar structure to my TEMPLATE/STICKY design

As this second idea is being discussed in the steering committee, and my proposal was not (that I am aware of), I'm genuinely trying to understand: what makes this proposal different enough to warrant committee discussion?

I want to be clear about how I approach collaboration: If I build on someone else's ideas, I clearly state that I do so, pointing to the original person who first described that idea. That's how I work, and always have worked. I don't want to get credit for the things I did not do myself. This is basic professional courtesy and intellectual honesty in any collaborative field.

I submitted my proposal a year ago with these concepts fully documented. If there are technical reasons why my proposal doesn't work, I'm eager to hear them explained – that would help me improve my thinking.

The similarities between these discussions and my proposal are striking, so I'm curious: is there a relationship between these proposals and my proposal from August last year, or did we arrive at similar solutions independently?

I'm hoping for honest technical feedback and clarity on these connections – both would help me contribute more effectively.

[Norwegian-Sardines]

I guess if you want to say that I fashioned my work based on the work of other people, it has to be the work I did at the consulting firm back in 1980s and 1990s. We did a lot of work converting unnormalized IMS hierarchical databases to the “more normal” network database design of IDMS, then 10 years later taking those data representations and converting them to DB2 relational database tables for SQL consumption! The relationship of a Participant/Event is not unique or ground breaking, but rather a standard design construct similar to the classic Student/Class design I taught back then! The real “art” for designing databases (and in our case data transfer protocols) is knowing what data goes into each representation and using naming conventions that are self documenting and unambiguous to the casual observer.