Types of Address
An address in the Person Registry is intended to be a US Post Office deliverable address, that is, a fully articulated street, city, state, country, zip location, or foreign equivalent, representing a place a person lives, works or receives mail. Note that the Registry, being an aggregate of data from many sources, cannot restrict addresses to mailable addresses only. The post office won't actually deliver to a dorm address on campus even though that's a valid indication of where a student lives. But the values are intended to be syntactically complete nonetheless.
The Person Registry supports the following types of address:
| Address type | Occ | Source | Description | ||
|---|---|---|---|---|---|
| min:max | reg | ext | user | ||
| permanent | 1:1 | no | yes | yes | Permanent residence |
| local | 1:1 | no | yes | yes | Local address, if different than permanent |
| 1:n | no | yes | yes | Mailing address | |
| home | 0:n | yes | no | no | The "best" residential address |
| homemail | 0:n | yes | no | no | The "best" mailing address |
| office | 0:1 per aff | no | yes | yes | Per-affiliation office/work address |
| work | 0:n | yes | no | no | Single "best" work address |
|
|||||
Permanent Address
| Registry Database: | table=address, type_cd=general, aff_source_cd=(null), aff_source_instance=(null) |
| XML Document: | <address type="permanent"> |
| LDAP Directory: | suPermanentAddress |
Generally speaking, where the person lives. For students this is often a parent's address, not a campus or nearby location. For faculty and staff, this address should be the official residence the University can use to determine your legal residence for health and benefits services.
Local Address
| Registry Database: | table=address, type_cd=local |
| XML Document: | <address type="local"> |
| LDAP Directory: | suLocalAddress |
An optional address where a person can record a more local (to Stanford) address if it differs from their permanent address. Students record their campus dorm address or local house/apartment as a "local" address. Faculty, staff and affiliates will have less occasion to use this, but visitors (short and long term) who might retain a legal residence elsewhere can indicate their local living arrangement here.
Note, in StanfordYou this address is labeled "Temporary address".
Mailing Address
| Registry Database: | table=address, type_cd=mail |
| XML Document: | <address type="mail"> |
| LDAP Directory: | suMailAddress |
An optional mailing address, if different than local or permanent addresses, specifically for US Mail delivery when mail delivery to the residence addresses is not possible or desired. This is often a P.O. Box.
Home Address
| Registry Database: | n/a |
| XML Document: | <address type="home"> |
| LDAP Directory: | n/a |
A derived address, not stored separately in the database, computed as
- local address
- else permanent address
This provides a "best" single value for home residence address as a convenience for downstream systems, such as the directory.
Home Mailing Address
| Registry Database: | n/a |
| XML Document: | <address type="homemail"> |
| LDAP Directory: | homePostalAddress |
A derived address, not stored separately in the database, computed as
- mail address
- else local address
- else permanent address
This provides a "best" single value for a US Post Office delivery address as a convenience for downstream systems, such as the directory.
Office Address
| Registry Database: | table=address, type_cd=general, with aff_source data |
| XML Document: | <address type="office"> |
| LDAP Directory: | suGwAffilAddress[n] |
A per-affiliation work address (the term "office" is used because it can occur for both staff and students, and to semantically distinguish it from the "work" address below).
Work Address
| Registry Database: | n/a |
| XML Document: | <address type="home"> |
| LDAP Directory: | postalAddress |
| street |
A derived address, not stored separately in the database, taken from the highest ranking non-private affiliation. This provides a "best" single value for work address as a convenience for downstream systems, such as the directory.
Parts of an Address
Each address in the registry is stored as a single row in the address table of the Registry database. An address consists of these parts:
| What | Required? | Schema | xml |
|---|---|---|---|
| Type of address | yes | type_cd | <address type="..."> attribute |
| Street(s) | no | line1..line3 | <address>...<line> element |
| City | no | city | <address>...<city> element |
| State code | no | state_cd | <address>...<state> element |
| Province | no | province | <address>...<province> element |
| Country code | yes | country_cd | <address>...<country> element |
| Postal code | no | postalcode | <address>...<postalcode> element |
Type of address
Type of data per above.
Street
One to three lines of street address.
City
Name of a city.
State
Any of the United States state or protectorates (e.g., Puerto Rico) that are recognized by the US Post Office for mail delivery and defined by 2-charactrer US postal code. The value is stored in the database by the 2-character code.
For online sources of state and province code abbreviations see
US state and territories and
Canadian Province Codes
A table of state codes and values is in database pregistry, table state. The name values from this table are used on output to expand state codes to their display value.
Province
An optional, free text equivalent to state code for foreign addresses.
Country
A valid ISO 3166-1, stored as the two-character ISO 3166-1 country code. For the ISO online published short names and codes, see http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html.
A table of ISO country codes (numeric, 2-character aloha and 3-character alpha) and values is in database pregistry, table country. The values from this table are used on output to display all three codes and name value.
Postal Code
Any valid ZIP code or foreign equivalent. When the country is US and there is a valid State code, this value is assumed to be a ZIP code and is edited against a range of valid ZIP codes found in database pregistry, table state.
Data integration rules
Addresses from the source to the registry
- A source may contribute one each of a permanent, local and mail, address.
- A source may not contribute a home address (this is a Registry-derived address).
- A source may contribute one office address for each affiliation.
- A source may not contribute a work address (this is a Registry-derived address).
Addresses in the registry outbound Person XML document
- Addresses of type permanent, local and mail are represented at the root level of the document.
- A single home address is generated from the other personal addresses and represented in the <place> element of type=home, also at the document root level.
- Each office address is inside a <place> element of type=office inside the corresponding <AFFILIATION>affiliation.
- A single work address is generated from the office address in the highest ranked office address and represented in the <place> element of type=work, and found at the document root level.
Events
Registry/Directory synchronization events
The Person Registry posts the following events when specific types of addresses change:
| Type of address | event (domain:topic) | parm1 | parm2 |
|---|---|---|---|
| reconcile | registry_person:reconcile | none | none |
Note: Parms were originally included to optimize slog operations and are no longer needed. While they provide some contextual information for the events, they are no longer needed to help maintain the directory and could be eliminated.
Infrastructure person events
The Person Slog process that maintains the Person data in the Directory posts the following events when these directory attributes change:
| Directory attribute | event (domain:topic) | parm1 |
|---|---|---|
| suPermanentAddress | person:address | permanent |
| suLocalAddress | person:address | local |
| suMailAddress | person:address | |
| homePostalAddress | person:address | homemail |
| street | person:address | work |
| postalAddress | person:address | workmail |
Note: The parms designating the particular address types are part of the design for these public events and should not be omitted. Consumers may be filtering on these values to select only changes needed by their system.
