Party

Description

The party is the central node in this model. A party can be a person or an organization, but each person and organization in the authoritative data system will be a single party with a unique identifier (a uuid). The term party ID should hereafter become ubiquitious in UTA system discussions and designs.

It is critical that we avoid creating multiple identifiers for the same person or organization. While automation can help trap some of these errors before they make it into the database, the only reliable way to do this for a database as relatively manageable as UTA's is through human stewards trained to understand the roles and relationships between parties at UTA. For more information, refer to the Data Management section of the documentation.

Note that a party of type organization may or may not be a formal company, such as a corporation or LLC in the USA. It could also be a band, a writing team, a duo, or any other group of people who are contracted together.

Label

:Party

Properties

Property	Description	Type
id	The party's unique identifier	uuid
name	The default name for the party, rolled up from a Name node	string
friendlyName	A slugged version of the party name, unique, used for URLs	string
type	organization or person	string
note	Information about the party	string
active	active or inactive	boolean
inactivatedDate	Date at which EventSeries was marked as inactive	dateTime
verified	DMO Flag for Backcompat withen importing	boolean
createdBy	the person or process that created the party	string
createdDate		dateTime
modifiedBy	the person or process who last modified the party	string
modifiedDate		dateTime

INFO

The only reason to hoist the name up from a :Name node into :Party is for convenience and performance; many applications require attaching the party ID and current name to some sort of query. We will look for simpler options.

WARNING

Sensitive information such as birth dates, gender, sexual orientation, or ethnicity should not be casually placed into the root party properties. We will first address policy issues with UTA before doing any implementation, but the likely model will be a :PersonalInfo node with an item to which access is carefully controlled.

Key

id

Relationships

Almost all of our catalogued relationships are connected to parties.

Examples

Get all parties

MATCH   (party:Party { active: true })
RETURN  party{.*}

Get a specific party

MATCH   (party:Party { id: $id})
RETURN  party{.*}

Create fulltext index on names

CREATE    FULLTEXT INDEX partyNames
FOR       (p:Party)
ON EACH   [p.name]

Search by name using fulltext index

CALL    db.index.fulltext.queryNodes("partyNames", $name ) 
YIELD   node, score
RETURN  node.id as id, 
        node.name as name, 
        score as score

Create a new party

// Normally a new party should not be created without a 
// relationship to a corresponding name node, and an 
// active relationship to a role node. This is just an example.

CREATE  (party:Party { 
          id: randomUUID(),
          name: "Client 3",
          type: "Person",
          active: true,
          verified: false,
          friendlyName: "client-3",
          createdBy: "Glenn Scott",
          createdDate: date(),
          modifiedBy: "Glenn Scott",
          modifiedDate: date()
        })
RETURN  party{.*}