Proposal: Add an `ADDRPLUS_STRUCTURE`

[mother10]

ADDRPLUS_STRUCTURE :=

An extended address structure containing all relevant information for modern contact records, including physical and digital addresses.
It is introduced to be able to describe addresses, especially on TEMPLATE's, that are not addresses belonging to a person, but, for example, to the institution that issued the TEMPLATE itself.

Design Principle:
ADDRPLUS is introduced not to expand GEDCOM into a general address system, but to provide a minimal, structured way of recording institutional and role-specific contact information that is critical for source validation and long-term research reproducibility.

n ADDRPLUS <Text>                          {1:1}
  +1 <<ADDRESS_STRUCTURE>>                 {0:1}
  +1 PHON <Special>                        {0:M}  g7:PHON
    +2 TITL <Text>                         {1:1}  g7:TITL
  +1 EMAIL <Special>                       {0:M}  g7:EMAIL
    +2 TITL <Text>                         {1:1}  g7:TITL
  +1 FAX <Special>                         {0:M}  g7:FAX
    +2 TITL <Text>                         {1:1}  g7:TITL
  +1 WWW <Special>                         {0:M}  g7:WWW
    +2 TITL <Text>                         {1:1}  g7:TITL
  +1 AGNC <Text>                           {0:1}  g7:AGNC
  +1 NOTE_STRUCTURE                        {0:M}  g8:NOTE

• The top-level ADDRPLUS payload provides a description of what the contact block represents — for example:
  “Contact information of: Genetic Information Research Institute (GIRI)”.
• PHON, EMAIL, FAX, and WWW follow GEDCOM 7 usage and formatting.
• TITL provides a descriptive label for the contact item, such as a person, role, or institution name.
• NOTE, provides the possibility to enter different address formats, as in other countries, in the NOTE.
• There needs to be at least 1 correct line of contact information present in this structure!

:::example
Example: Contact information with titles per entry

1 ADDRPLUS Contact information of: Genetic Information Research Institute (GIRI)
2 ADDR 2020 Alameda de las Pulgas
3 CITY San Mateo
3 STAE CA
3 POST 94403
3 CTRY USA
2 PHON +1-650-212-2220
3 TITL Main research line
2 PHON +1-650-212-2221
3 TITL Fax line for document intake
2 EMAIL contact@girinst.org
3 TITL General correspondence
2 EMAIL submissions@girinst.org
3 TITL Sequence data submission desk
2 WWW https://www.girinst.org
3 TITL Official research website
2 AGNC GIRI – Public communications desk

:::

Why ADDRPLUS_STRUCTURE is needed

1. Institutional Context (not personal)
   Standard ADDRESS_STRUCTURE in GEDCOM is tied historically to people and families.
   ADDRPLUS is required to represent institutions, registries, and offices that appear on TEMPLATEs (e.g., archives, hospitals, churches). Without it, these addresses would be forced into NOTE fields or incorrectly attached to individuals.

2. Separation of Channels
   Modern institutions have multiple communication channels — main line, research desk, submission desk, fax intake, web portals.
   GEDCOM 7 allows PHON, EMAIL, FAX, WWW, but does not provide a way to label them.
   ADDRPLUS introduces TITL precisely for this purpose, to distinguish and clarify each entry (e.g., “Fax line for document intake” vs. “Main office phone”).

3. Clarity for Users and Researchers
   Without TITL, researchers cannot know what a given phone/email belongs to — is it the parish secretary, the archive’s digital submission desk, or the hospital billing department?
   ADDRPLUS removes ambiguity and prevents misuse of free-text NOTEs for this labeling.

4. Consistency Across Records
   Re-using ADDRPLUS across different TEMPLATEs ensures a standardized block for contact data.
   This avoids ad-hoc variations in how archives, research institutes, or government agencies are recorded.

5. Future-proofing GEDCOM
   Research increasingly involves digital-only contact: online portals, submission forms, departmental emails.
   ADDRPLUS explicitly acknowledges this evolution, ensuring contact data is structured, extensible, and clearly attributed.

6. Data Integrity
   By requiring that at least one valid line of contact information must exist inside the structure, ADDRPLUS ensures it is not left as an empty placeholder.
   This maintains quality of data, unlike optional NOTEs that can be skipped or left vague.

---

In short:

• ADDRESS_STRUCTURE alone = too limited, too person-oriented.
• ADDRPLUS = institutional, labeled, multi-channel, and future-ready.

Anticipated Objections and Rebuttals

Objection 1: "GEDCOM is not an address system."
➡ Rebuttal: Correct — GEDCOM is not intended to store postal databases.
However, genealogical sources are often tied to institutions (churches, archives, hospitals, government registries) where reliable contact information is essential for research validation.
ADDRPLUS is minimal and focused, providing only what is necessary to identify and differentiate institutional contact channels, without turning GEDCOM into a general-purpose address book.

---

Objection 2: "We already have ADDRESS_STRUCTURE for this."
➡ Rebuttal: ADDRESS_STRUCTURE covers a single address without phone/email, and the separate tags like WWW, EMAIL etc. lack labels (TITL).
Without TITL, multiple entries (e.g., fax vs. research desk email) cannot be meaningfully distinguished.
ADDRPLUS adds this one crucial layer of descriptive context, while still re-using GEDCOM 7’s familiar PHON, EMAIL, FAX, and WWW.

---

Objection 3: "This could be done with NOTEs instead of a new structure."
➡ Rebuttal: Free-text NOTEs lack enforceable structure, are inconsistent across software, and risk data loss in processing.
By introducing ADDRPLUS, the function of each contact line is explicit and standardized, improving interoperability and software support.

---

Objection 4: "Why mandate at least one valid contact line?"
➡ Rebuttal: This prevents ADDRPLUS from degenerating into a vague container.
Its purpose is to carry actionable contact information (phone, email, web, etc.), not empty placeholders.
Enforcing one valid entry ensures better data integrity across implementations.

[Norwegian-Sardines]

The need for this new structure is for "Institutional Context", and a way to label (Title) the various ways to contact the institution.

As it relates to "Institutional Context" the two (2) places I see this would be used in the current GEDCOM v7.x implementation would be in the:

1. HEADER record under the CORP (corporation) tag denoting the company that provided the software that created the GEDCOM
2. REPO record (Repository record)

In GEDCOM v7.x the HEADER record has the following design:

n HEAD 				{1:1} g7:HEAD
+1 GEDC 			{1:1} g7:GEDC
+2 VERS <Special> 	{1:1} g7:GEDC-VERS
+1 SCHMA 			{0:1} g7:SCHMA
+2 TAG <Special> 	{0:M} g7:TAG
+1 SOUR <Special> 	{0:1} g7:HEAD-SOUR
+2 VERS <Special> 	{0:1} g7:VERS
+2 NAME <Text> 		{0:1} g7:NAME
+2 CORP <Text> 		{0:1} g7:CORP
+3 <<ADDRESS_STRUCTURE>> {0:1}
+3 PHON <Special> 	{0:M} g7:PHON
+3 EMAIL <Special> 	{0:M} g7:EMAIL
+3 FAX <Special> 	{0:M} g7:FAX
+3 WWW <Special> 	{0:M} g7:WWW

The HEADER.CORP structure is the main focus here.

1. The ADDRESS_STRUCTURE itself is separate from other contact points (Phone, email, fax, URL). The corporate address currently can only occur once and is most likely a singular occurring item, and therefore does not need changing in this context.
2. The contact points (Phone, eMail, Fax, URL) are multiple occurring items and could be enhanced by providing some form of contextual identity.

In GEDCOM v7.x the REPO record (Repository) has the following design:

n @XREF:REPO@ REPO 	{1:1} g7:record-REPO
+1 NAME <Text> 		{1:1} g7:NAME
+1 <<ADDRESS_STRUCTURE>> {0:1}
+1 PHON <Special> 	{0:M} g7:PHON
+1 EMAIL <Special> 	{0:M} g7:EMAIL
+1 FAX <Special> 	{0:M} g7:FAX
+1 WWW <Special> 	{0:M} g7:WWW

Repositories have two distinct context for contact information

1. The general location of the library, archive, corporate headquarters, most likely just an address and URL.
2. Contact information pertaining to specific individuals associated with the repository, which may or may not be at the same location in (1).

The ADDRESS_STRUCTURE itself is separate from all other contact information and represents the location of the repository and therefore should remain a singular occurrence in the REPO record. (NOTE: The URL of the repository could also be a singular occurrence directed at the main entry point to the repository)

The remaining contact information including postal address information are most likely targeting specific people or departments (i.e. "Collections") and therefore may occur multiple times and need more specific/directed contact information.

The REPO record could be updated to include these ideas as follows:

n @XREF:REPO@ REPO 		{1:1} g7:record-REPO
+1 NAME <Text> 			{1:1} g7:NAME
+1 <<ADDRESS_STRUCTURE>> {0:1}
+1 WWW <Special> 		{0:M} g7:WWW
+1 CONTACT 				{0:M}
+2 NAME <Text> 			{1:1:} 
+2 <<ADDRESS_STRUCTURE>> {0:1}
+2 PHON <Special>	 	{0:1} g7:PHON
+2 EMAIL <Special>	 	{0:1} g7:EMAIL
+2 FAX <Special> 		{0:1} g7:FAX
+2 WWW <Special> 		{0:1} g7:WWW

Example:

0 @R2@ REPO
1 NAME My Favorite Library
1 ADDR 415 W. Main Street
2 CONT My City, WI 99999-8888
2 WWW MyFavoriteLibrary.org
1 CONTACT
2 NAME John the Archivist
2 ADDR c/o John Doe
3 CONT 415 W. Main Street
3 CONT My City, WI 99999-8888
2 PHON 999.999.9999 x23
2 EMAIL jdoe@myfavoritelibrary.org

NOTE: We could also "Normalize" this by removing the duplicate CONTACT entries and creating a separate record type for "Contacts".

NOTE: In GEDCOM v7.x the ADDRESS_STRUCTURE has the following design:

n ADDR <Special> {1:1} g7:ADDR
+1 ADR1 <Special> {0:1} g7:ADR1
+1 ADR2 <Special> {0:1} g7:ADR2
+1 ADR3 <Special> {0:1} g7:ADR3
+1 CITY <Special> {0:1} g7:CITY
+1 STAE <Special> {0:1} g7:STAE
+1 POST <Special> {0:1} g7:POST
+1 CTRY <Special> {0:1} g7:CTRY

It also contains the following note about use:

A specific building, plot, or location. The payload is the full formatted address as it would appear on a mailing label, including appropriate line breaks (encoded using CONT (p.73) tags). The expected order of address components varies by region; the address should be organized as expected by the addressed region.

This note leads me to understand that as an address label the payload of the ADDR can support all components of a mailing label. For example:

1 ADDR c/o John Doe
2 CONT 415 W. Main Street
2 CONT My City, WI 99999-8888

[mother10]

As you might have seen, all issues I now posted, and will post, are coming from PR #679. That means they are needed there in a couple of situations.

Now you say:

As it relates to "Institutional Context" the two (2) places I see this would be used in the current GEDCOM v7.x implementation would be in the:

So as far as I understand you focus on current GEDCOM.

That whole PR I mentioned, focusses on the future, so not just today, as the future is where GEDCOM needs to go.
That is what I tried to achieve with the new things I proposed in there.

The ADDRPLUS_STRUCTURE is used on many places in that new PR.

Offcourse it can also be used on other places, like you mentioned. So it is good you came up with that example here.

[Norwegian-Sardines]

So as far as I understand you focus on current GEDCOM.

Yes. My points are that the future does not have to change everything just because you don’t understand how to use the current design. You don’t have to create a new structure when augmenting the old accomplishes the same thing! Getting applications to rewrite their software, completely change their databases will not be embraced. I’ve been in those situations in software design and development, many applications have a very limited staff they had enough trouble embracing the modest changes v5.5 to v5.5.1 and very few applications have embraced all of v7.

[jl5000]

I can see the benefit of grouping ADDR and EMAIL/FAX/etc. into a single structure. I would propose a tag like CONTACT rather than ADDRPLUS.

I can also see the benefit of having titles for EMAIL/FAX/etc. when the cardinality is {0,M}, however am not keen on them being mandatory. Instead of TITL I might suggest PHRASE instead.