Venues

Venues are locations where a client performs or appears. Within Authoritative Data, they are represented as a :Venue node that can be further described with relationships to :Configuration and :VenueType nodes.

Venue node

Objects with :Venue nodes can make use of some relationships typically used with :Party nodes, such as relationships to :Name, :Address and :OnlineAddress. Note that a venue can only have one address of type "Main". This represents the venue's physical location.

Venue Types and Configurations

Venues can be further described using :VenueTypes and :Configurations. The type described the physical characteristics of the venue itself. For example, this could be used to describe whether the venue is an amphitheater, a bar, a beach, a parking lot, etc. The :VenueType category node contains a wide range of descriptors that can be applied to the ':Venue' using the HAS_VENUE_TYPE relationship. A venue can have multiple descriptions relect its physical characteristics. For example, the Mountain Winery in Saratoga, CA can have HAS_VENUE_TYPE relationships with both the "Winery" and "Amphitheater" nodes.

Venues can be arranged to have different seating/standing configurations that will alter the capacity for a specific event. Example configurations for venues could include (but are not limited to) the following:

1. Standing vs seated arrangement
2. Line of sight seating arrangements (example: 160°, 180°, 200° views)
3. Traditional stage vs in-the-round stage
4. Stadium seating vs Performance stage seating

Information about these variations are captured in :Configuration nodes. The :Configuration node can be used to store names for potential venue configurations and their associated capacities. Capacity configurations can also make use of the outdoor property, which indicates whether a specific configuration is in an outdoor setting.

Subvenues

Multiple venues can be located within a larger property or facility. For example, the Tennessee Performing Arts Center (TPAC) is made of three venues at the same property: Jackson Theater, Polk Theater, and Johnson Theater.

By relating each of the subvenues to the parent TPAC venue using the HAS_SUBVENUE relationship, one can find all the related venues within the facility. Note that the parent itself (TPAC) is not a bookable venue, it is just a container for each of the subvenues, which will have their own venue properties and configurations (see below for more).

Subvenues are not the same as stages. Venues and subvenues are places where you can travel to and see a show. A stage is a performance area. Stages or other areas within a venue (such as a bar, outside grounds, etc) can be specified as configurations within a venue.

INFO

Differences between configurations and subvenues: A :Configuration represents a different capacity/seating arrangement within a venue while subvenues are viewed as distinctly different spaces. For example, Sofi Stadium can have different spaces for shows: (1) Indoor on the field, (2) Indoor on the field and in seats and (3) the stadium parking lot. For the case of modeling, because #1 and #2 are not mutually exclusive- a booking as #1 will conflict with #2- they are considered configurations of the indoor area. However, having an event in the stadium parking lot does not prohibit another event from happening inside. In this case, Sofi Stadium would be represented as the parent venue, with the parking lot and indoor area as two subvenues. The indoor subvenue would then have two configurations attached to it.

Note that as a business rule, a venue that is already a subvenue of an existing venue cannot be the parent of another venue.

Venue Operators and Buyers

A venue is not a party, meaning that it does not represent a person or organization. A "venue" represents additional information about a physical location. Therefore, we use the concept of "buying" and "operating" relationships to connect venues to parties. We use the IS_OPERATOR_OF relationship to designate a party as the operator of a venue, defined as the party responsible for the day-to-day functioning of the space. This could be a property manager, owner, or main point of contact for the venue. We can also use the BUYS_FOR relationship to designate a party that books talent for a specific venue.

Some points about operators and buyers:

1. In some cases, the party that operates the venue is also responsible for booking talent. In this situation, the party would have both a BUYS_FOR and IS_OPERATOR_OF relationship with the venue
2. A party can have BUYS_FOR relationships with multiple venues. An example of this case would be an event promotor that books their events at a variety of venues.
3. A party can also have IS_OPERATOR_OF relationships with multiple venues. An example of this would be a party that owners a chain of venues.
4. A venue can have IS_OPERATOR_OF relationships with multiple parties. This example covers the case of shared ownership of a venue such as where a group of owners operate a single venue

Managing Entites and Subvenues

A managing entity is explicitly connected to a venue using the IS_OPERATOR_OF relationship. However, in some cases, the managing entity is also the name of a larger building containing subvenues. In the example able, TPAC is the holistic name of the collection of subvenues within the property. TPAC itself is not a bookable venue. In this case, the :Venue node for TPAC would have its "bookable" property set to False. Unbookable venues will not require an active HAS_VENUE_TYPE relationship.

Parent venues that are bookable will have their "bookable" property set to TRUE. In additional, bookable venues will have at least one configuaration and will require an active HAS_VENUE_TYPE relationship.