Types of Names
These are people's real-world personal names, current and former (where known). All names belong to the person as a whole. Though names can come from multiple sources, the Person Registry does not support "affiliated" names, that is, names bound to the context of just one affiliation.
The Person Registry supports the following types of names:
| Name type | Occ | Source | Description | ||
|---|---|---|---|---|---|
| min:max | reg | ext | user | ||
| registered | 1:1 | yes | no | no | Derived, 'best', full, official name |
| display | 1:1 | yes | no | no | Derived, 'best', preferred form of name |
| full | 1:n | no | yes | no | Source-specific full, official name |
| preferred | 0:n | no | yes | yes | Source-specific preferred name |
| previous | 0:n | yes | no | no | Previous full name values |
| other | 0:n | no | no | yes | Other names for searching |
|
|||||
A person in the registry always has two guaranteed names forms:
Registered Name
| Registry Database: | table=name, type_cd=registered |
| XML Document: | <name type="registered"> |
| LDAP Directory: | suRegisteredName |
| suRegisteredNameLF |
This is a Registry derived name conveying the user's full legal name -- the most complete, most "official" name known from source systems or from the user. It is set to the "full" name value from the highest ranking contributing source. For faculty, staff and students this is the full name as recorded with the PeopleSoft HR and student systems for enrollment, salary and tax reporting, etc. Other sources contribute full names, e.g., Hospital HR and the Campus Card system, as well as the person themselves if they self-registered when requesting a SUNetID.
Display Name
| Registry Database: | table=name, type_cd=display |
| XML Document: | <name type="display"> |
| LDAP Directory: | displayName |
| suDisplayNameLF |
This is the user's preferred form of their name, such as a briefer form (e.g., minus the middle name) or with short forms of names, e.g., Sandy for Sandra. It is derived by the Registry from the "preferred" name of the highest ranking source, or as entered by the user in StanfordYou if later than any source. Since this indicates the name the person actually goes by, it is the most useful name form for identifying users in menus, reports, email salutations, etc. It will be the same as the Registered Name if no other preferred name is expressed.
A person's registered and Display names are not set directly by the user or by any contributing system. Instead they are generated by the Person Registry from a parallel set of name types:
Full Names
| Registry Database: | table=name, type_cd=full |
| XML Document: | n/a |
| LDAP Directory: | n/a |
The person's full official name from a specific source. Full names from the PeopleSoft HR and student systems are the person's legal name as required by those systems for government reporting (e.g., the W-2 name) or student enrollment. There is one full name recorded for each source system that contributes personal identity information, including the users themselves if they self-register when requesting a sponsored sunetid. There should always be at least one full name that is the basis of the Registered Name for each person.
Preferred Names
| Registry Database: | table=name, type_cd=preferred |
| XML Document: | n/a |
| LDAP Directory: | n/a |
This is an optional name form that can be contributed by source systems or managed by qualifying users in StanfordYou. If present, a preferred name will be the basis for the Display Name above. Otherwise the Display Name is set to be the same as the Registered Name. StanfordYou input of a Preferred Name requires a last name that is found in an already recorded Full or Previous name. Preferred Names can be contributed from source systems.
Note that the intent of "preferred name" is to record a value "if different" than one's full name, a name that indicates a personal preference to go by that name independent of official or other names recorded. A preferred name entered by the user directly in StanfordYou is retained even if it matches a the registered name.
Previous Names
| Registry Database: | table=name, type_cd=previous |
| XML Document: | n/a |
| LDAP Directory: | n/a |
This form of name is automatically generated by the Registry whenever a source system updates its full name with a name that has a different last name. First/middle name changes alone do not cause a Previous Name to be created. This information supports two needs, (a) matching processes that will want to know changing forms of name, and (b) policy/rules like SUNet ID name forms and Registry "other" names that might need access to former names to factor into last-name rules.
A Previous Name retains its original source value though it cannot be maintained by that source. There is no support for a source to forward and maintain its own set of previous name values.
Other Names
| Registry Database: | table=name, type_cd=other |
| XML Document: | <name type= |
| LDAP Directory: | suOtherName |
Also known as "Other Name(s) for searching." These are name forms that an individual can record through StanfordYou to augment name searching through StanfordWho/whois or similar registry or directory-based queries. For instance, a user could record a nickname that friends know them by without making that their preferred Display Name. Other Names must have a last name that corresponds to the last name of an already recorded Full or Preferred name.
There is currently no support for a source system contributing "Other Names".
Parts of a Name
Each name in the registry is stored as a single row in the name table of the Registry database. A name consists of these parts:
| What | Required? | Schema | xml |
|---|---|---|---|
| Type of name | yes | type_cd | <name type="..."> attribute |
| Title or form of address | no | title | <name>...<title> element |
| First name | no | firstname | <name>...<first> element |
| Middle name | no | middlename | <name>...<middle> element |
| Last name | yes | lastname | <name>...<last> element |
| Name suffix | no | suffix | <name>...<suffix> element |
Type of name
Type of data per above.
Title or form of address
In theory can be any form of name title the user wishes to appear with their name. This may be social (Mr., Mrs.), professional (Dr., The Reverend) or honorific (Sir). In practice, StanfordYou only offers the user a choice from this set of values: Dr., Miss, Mr., Mrs., Ms. PeopleSoft is the only external contributor of this attribute, and currently limits its users to the same set of values. The values may appear with or without the trailing period.
First name
First portion of name. Will be a single string value and should consist of only a single term. If parsing a full name string it will be the first blank or comma delimited word.
A first name that consists of punctuation only will be accepted but should be corrected through Data Admin.
Middle name
A middle name portion of a name is defined as the value of the name string between the first name and the last name. Thus it can consist of one or more words as a single, space-delimited value.
A middle name that consists of punctuation only will be accepted but should be corrected through Data Admin.
Last name
Last name. Can consist of more than one word, such as multi-word names ("de la cruz"), compound names ("Rodham Clinton") or hyphenated names ("Payton-Miyazaki"). Source systems and StanfordYou solicit/provide the names in articulated parts, so the boundary between middle and last name(s) is clear. Any name that needs to be parsed as a single string will use a comma as a semantic clue -- everything after a comma is the last name, else the last name is the final space-separated token provided in the name.
A last name that consists of punctuation only is considered bad data and should be rejected on input.
Name suffix
One or more familial ("Jr.", "II") and/or professional ("M.D.", "Ph.D.") suffixes. If more than one are present, they are contained in a single, value, generally delimited by a comma or a comma-space. However, this is general practice, not policy. There are currently no controls over a domain of acceptable values or their formatting either coming into the Registry or as entered in StanfordYou
Data integration rules
Names from the source to the registry
- A source must contribute one and only one full name.
- A source may contribute zero or one preferred names.
- A source may not contribute a registered or display name since they are registry-derived names forms.
- Currently a source may not contribute a previous or other name. There is no support to coordinate externally and registry-sourced values in subsequent processes of these types.
Names in the registry outbound Person XML document
- There will be one and only one registered name.
- There will be one and only one display name, which will be the same as the registered name if no other preferred name is recorded.
- There can be zero to three (current StanfordYou limit) other names.
- Source-specific full and preferred names are not exported.
- Previous names are not exported via the person XML. They are used internally to support business rules limiting one's choice of "other names" and sunetid aliases to be based on one's current or former (if recorded) last name.
Events
Registry/Directory synchronization events
The Person Registry posts an registry_person:reconcile for any change in name data.
Infrastructure person events
The person Slog process that maintains Person data in the Directory posts the following events when directory attributes change. The parms designating the specific data type allow consumers to filter the events to select only changes needed by their system.
| Directory attribute | event (domain:topic) | parm1 |
|---|---|---|
| suRegisteredName | person:name | registered |
| displayName | person:name | display |
| suOtherName | person:name | other |
