Use Cases

Below are a set of use cases that describe how to model various relationships in the UTA data model. They are not a complete set, are in no particular order, but they should give you a good idea of how to model the most common relationships.

How would an "industry contact" like Ted Sarandos be built out in this model?

1. Ted Sarandos himself would be modeled as a Party of type Person.
2. Netflix would be modeled as a Party of type Organization.
3. The Sarandos Party would have a HAS_NAME relationship to a Name node with the value "Ted Sarandos", and the type Display.
4. The Sarandos Party would have appropriate HAS_PHONE, HAS_ADDRESS, and HAS_EMAIL relationships to Phone, Address, and Email nodes based on what we know about him.
5. The Sarandos Party would have, for example, a HAS_EXTERNAL_RECORD relationship to an ExternalRecord node with the type "IMDB" and the platformId "nm1848253".
6. The Sarandos Party would have a HAS_ROLE relationship to a Role node with the value "Contact".
7. The Netflix party would have a HAS_NAME relationship to a Name node of type Display with the value "Netflix".
8. The Netflix party would have a HAS_ROLE relationship to a Role node with the value "Buyer".
9. The Sarandos Party would have a HAS_APPOINTMENT relationship to an Appointment node.
10. The Appointment node would have an APPOINTED_TO relationship to the Netflix Party.

In the example above, what if Ted later becomes a client?

1. We would de-activate the HAS_ROLE relationship to the Role node with the value "Contact" while adding a new HAS_ROLE relationship to a Role node with the value "Client".
2. We would add the REPPED_AS relationship between the Sarandos Party and an appropriate RepArea nodes corresponding to the areas in which UTA represents him.

How would I find everyone we know who works at Netflix?

1. Find the Party node for Netflix.
2. Find all Party nodes that have an active HAS_APPOINTMENTand corresponding APPOINTED_TO relationships to the Netflix Party.

We have a client, Seth Rogen. And he owns a production company, Point Grey Pictures. How would we model this?

Assuming Point Grey is not a client itself:

1. Seth Rogen would be modeled as a Party of type Person.
2. Point Grey Pictures would be modeled as a Party of type Organization.
3. Seth Rogen would have a HAS_ROLE relationship to a Role node with the value "Client".
4. Point Grey Pictures would have a HAS_ROLE relationship to a Role node with the value "Contact".
5. Seth Rogen would have an OWNS relationship to the Point Grey Pictures Party, with the subType relationship attribute set to "Production Company".

How would we model a client who is also a buyer?

1. Create a Party node for the client.
2. Attach a HAS_ROLE relationship to a Role node with the value "Client".
3. Attach a HAS_ROLE relationship to a Role node with the value "Buyer".

How do we model an attorney named Marty Singer who is a participant on Lizzo's deals but works for a firm Lavely & Singer?

Rewrite

How do we model a client who is also a talent?

You don't. Talent are people or organizations UTA does not currently represent but they may either pursue or track in some manner. Clients are people or organizations UTA does represent. If a talent becomes a client, we deactivate the talent role and add the client role.

How do we model a client's relationship to their loan-out company?

1. Create a Party node for the client
2. Create a Party node for the loan-out company
3. Attach a HAS_ROLE relationship to the client Party with the value "Client"
4. Attach a HAS_CLIENT_COMPANY relationship with a subType of "Loanout" between the client and the client's loanout company Party

How do we model a client's relationship to their business manager?

Rewrite

We have clients that have "alter ego" names; this is particularly common in the electronic space. How would we model this?

Examples we know about:

Display Name	Alias Name(s)
Deadmau5	TestPilot
Oliver Heldens	Hi-Lo
Lil Texas	Dallas Diamond Tex
Soulwax	2manyDjs, Despacio

1. Create a Party node for the client
2. Create a Name node of type Display for the most common name, and a Name node of type Alias for each alter ego name
3. Attach a HAS_NAME relationship between the client Party and each Name node created above.