Terms
Terms are default contractual terms that can be attached to a party, typically a party with a Buyer, or Client role, or an Event Series.
Default terms are considered authoritative data as they are attributes about a party. They are not considered to be a part of any specific transaction, but are rather used as "helpers" by application programs to pre-populate transaction data defaults to be accepted by the user if the user desires.
There are two types of terms currently modeled:
Text terms. These are simply text strings that can be attached to a party.
Structured terms. These are default terms that have a specific schema that is enforced by the API. Currently, the only structured term supported is the Radius Term.
Text Terms
Text terms are used to store default terms that are not easily modeled in a structured way. For example, a musician party may have a "Set Length" text term that is a free-form text field. Text terms have types and subtypes that can be used to categorize them. For example, a "Set Length" term may have a type of "Touring" and a subtype of "Performance Length". Text terms are expressed as Term nodes in the data model and are connected to parties via the HAS_TERM relationship.
Radius Terms
A radius term (also known as a radius clause) is a default contract term used by a party with role of Buyer or by an EventSeries that customarily wants to prevent a client from performing within a certain distance radius, as well as time window, of a contracted event.
Radius terms can take different forms depending on the type of restriction needed in the term.
Distance and time
A distance and time radius term restricts a client from performing at specific venues or events located within a defined radius of an origin point, typically the venue where the performance is to occur. A time window is specified as days before and days after to further bound the term. Distance and time-based terms are the most common radius term.
Radius terms are attached to a buyer party or an EventSeries via the HAS_RADIUS_TERM relationship.
Distance and time with known origin
Authoritative data models only default terms, intended to be used as suggestions, and not the actual terms of a specific transaction. In most cases, a default radius term has no idea where the event is taking place, so the origin point of the radius term is not known and would be set by the application at the time of the transaction, as the application knows where the event is to occur.
However, there are some use cases where the origin point of the default radius term is always known. Our model assumes this origin point is a known :Address node, usually attached to a :Venue node that represents the venue where the event is to occur.
We will use the HAS_RADIUS_ORIGIN relationship to connect the radius term to the address node that represents the origin point of the radius term.
In the example below, a buyer called XYZ Club sets a default radius term preventing a client from performing withing 120 miles from the club, within a window of 90 days before and 30 days after the contracted booking. In this case, the origin point of the radius term is the address of the club itself, so we'll supply it:
Note that we use the HAPPENS_AT relationship, which means that we will likely only support this "known origin" clause on an event series or EventInstance.
Geography
With a geographical radius term, the Buyer or Event Series restricts a booked artist from performing in a designated GeoArea.
GeoAreas allow flexible constructions of geographic areas, such as areas, countries, states, regions, or continents. The GeoArea anticipated by the default radius clause would be constructed first, then attached to the radius term with a HAS_GEO_AREA relationship.
For more information on GeoAreas, see the Geographic Area documentation.
Prohibited event
Event-based radius terms prevent booked acts from performing at rival events. Normally these events would be specific EventInstance nodes, but as these are defaults they will likely refer to the parent EventSeries party.
The example below illustrates how the Lollapalooza event could restrict a client from performing at either EDC or Coachella:
Combining radius terms
It is possible to combine radius terms to create more complex restrictions. For example, a buyer may want to restrict a client from performing within a certain distance of a venue, but also restrict them from performing at a rival event.
In the example below, the buyer XYZ Club sets a default radius term preventing a client from performing within 120 miles from the club, within a window of 90 days before and 30 days after the contracted booking. In addition, the buyer also restricts the client from performing at the rival event EDC:
If we wanted to construct a radius clause restriction that was both geographical and event-based, we would first create the GeoArea and attach it to the radius term, then attach the prohibited event:
Finally, we need not restrict ourselves to a single radius term. We can attach multiple radius terms to a party, each with its own restrictions. For example, a buyer may want to restrict a client from performing within a certain distance of a venue, but also restrict them from performing at a rival event. In this case, we would attach two radius terms to the party, each with its own restrictions: