Name

Description

Something a party calls itself. Parties can have various types of names, can have multiple names of each type, and have both current and former names.

Label

:Name

Properties

INFO

This schema for a :Name node is primarily derived from the person schema in the schema.org catalog, however there is generally no need for that complete schema in support of UTA's use cases. In the node properties listed here, descriptions taken from the schema.org schema are quoted.

Property	Description	Type
id	The unique identifier for the node. This is a UUID.	string
name	The full name of the person or organization as it should be displayed in apps and reports. For a person in the US, this will combine the givenName and the familyName, for example.	string
type	The type of name, see values below	string
givenName	"In the US, the first name of a person." Not used for organizations.	string
additionalName	"An additional name for a person, can be used for a middle name"	string
familyName	"In the US, the last name of a person." Not used for organizations.	string
preferredName	A first name that is used to address the person in an informal manner, but is not part of their formal or usual name.	string
honorificPrefix	"An honorific prefix preceding a Person's name such as Dr/Mrs/Mr"	string
honorificSuffix	"An honorific suffix following a Person's name such as M.D. or PhD."	string
createdBy	the person or process that created the node	string
createdDate		dateTime
modifiedBy	the person or process who last modified the node	string
modifiedDate		dateTime

A party can have multiple valid names that are active at any given time. A common use case is a stage name for an artist (which would be recorded with ( { type: "Display"}) versus a full legal name for the same artist( { type: "Legal"}) which might appear on a contract.

Name type	Description
Display	This is the name we would use on rosters, reports, and other materials displayed both internally and externally
Alias	An nickname or alternate name for the person or organization. In some cases this might be a nickname emerging from popular culture, perhaps "AOC" referring to "Alexandria Ocasio-Cortez", or it could be a previous displayName which we now want to keep track of as an alias so we can aid users in finding the name should they not have heard of the change. A nickname for the person or organization, e,g "Yankees" for the New York Yankees
Legal	In the case of an organization, "the official name of the organization, e.g. the registered company name."
FKA	Formerly Known As. This is a prior business or trading name that is no longer used by the party, venue, or event
DBA	Doing Business As. This is an alternate business name used by a party, venue, or event

Patrick McKenzie's warnings about names

On occasion Patrick McKenzie's post Falsehoods Programmers Believe About Names comes up. The UTA model for names is designed to avoid some, but definitely not all, of the name issues he warns about:

Patrick Warning	UTA Mitigation
People have exactly one canonical full name.	The model assumes many types of names are possible, but does restrict to one active display name. However, there can be an unlimited number of active aliases.
People have exactly one full name which they go by.	The model has one active display name but an unlimited number of active aliases.
People have, at this point in time, exactly one canonical full name.	The model assumes names change over time and that is addressed in the standard relationship properties
People have, at this point in time, one full name which they go by.	The model assumes names change over time and that is addressed in the standard relationship properties
People have exactly N names, for any value of N.	The model assumes no limit on names
People’s names fit within a certain defined amount of space.	The names in the model are currently constrained by a Neo4j string parameter. They could be further limited by a UI or an API validation but that's not in the model's scope.
People’s names do not change.	The model assumes names change over time and that is addressed in the standard relationship properties
People’s names change, but only at a certain enumerated set of events.
People’s names are written in ASCII.	Not assumed, but UTF-8 is assumed.
People’s names are written in any single character set.	UTF-8 is assumed.
People’s names are all mapped in Unicode code points.
People’s names are case sensitive.	No enforced case in the model
People’s names are case insensitive.	No enforced case in the model
People’s names sometimes have prefixes or suffixes, but you can safely ignore those.	The name model has prefix and suffix fields
People’s names do not contain numbers.	Numbers are not prohibited.
People’s names are not written in ALL CAPS.	ALL CAPS may be required for some names in the business of show, so no, not assumed in this model
People’s names are not written in all lower case letters.	No case assumptions in this model
People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering.
People’s first names and last names are, by necessity, different.	Not assumed in this model
People have last names, family names, or anything else which is shared by folks recognized as their relatives.
People’s names are globally unique.	Not assumed in this model; an absurdity.
People’s names are almost globally unique.	Not assumed in this model; an absurdity.
Alright alright but surely people’s names are diverse enough such that no million people share the same name.	Patrick is sort of joking
My system will never have to deal with names from China.	We assume we will deal with names from China.
Or Japan.	And Japan.
Or Korea.	And Korea.
Or Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have “weird” naming schemes in common use.	We should be able to handle these names
That Klingon Empire thing was a joke, right?	We understand some people name themselves using Klingon; so not really a joke
Confound your cultural relativism! People in my society, at least, agree on one commonly accepted standard for names.	No such assumption of any such agreement
There exists an algorithm which transforms names and can be reversed losslessly.	We do not transform names in this model
I can safely assume that this dictionary of bad words contains no people’s names in it.
People’s names are assigned at birth.	Never assumed in this model
OK, maybe not at birth, but at least pretty close to birth.	Never assumed in this model
Alright, alright, within a year or so of birth.	Never assumed in this model
Five years?	Never assumed in this model
You’re kidding me, right?	We know he wasn't kidding
Two different systems containing data about the same person will use the same name for that person.	Of course not. This is partially ameloriated by having authoritative data in the first place
Two different data entry operators, given a person’s name, will by necessity enter bitwise equivalent strings.
People whose names break my system are weird outliers. They should have had solid, acceptable names, like 田中太郎.
People have names.	We do assume at least a display name given our business context, but we understand its possible to not have a name in other contexts.

Key

id

Relationships

The HAS_NAME relationship connects parties to names.

Examples

Get a party's active names

MATCH     (p:Party { id: $id })
       -  [r:HAS_NAME {active: true}]
       -> (n:Name) 
RETURN    n{.*}

Get a party's active display name if it exists

MATCH      (p:Party { id: $id })
        -  [r:HAS_NAME {active: true}]
        -> (n:Name { type: "Display"}) 
RETURN     n{.*}

For more examples on working with names, refer to the HAS_NAME relationship documentation.