Place
Artsdata imports the Place class from Schema.org. In Schema.org, a Place is defined as “Entities that have a somewhat fixed, physical extension.”
In Artsdata, the Place class can be used to define any architectural structure (e.g. a building or a room) or outdoor location.
The Artsdata application profile for the Place class draws on core Schema.org properties and is inspired by the Wikidata WikiProject Cultural venues, maintained by CAPACOA and the LODEPA community.
The application profile notably takes advantage of the schema:placeContainedIn to create links between rooms/halls and buildings, as well as between buildings and encompassing places such as city. This automatically situates Places in a city, region, province and country. Linking increases the ability for reconciling places when only a name and postal address is available.
Once a Place entity from an external source is reconciled with an Artsdata minted identifier, it is linked with its Artsdata identifier with the schema:sameAs property.
Here is an overview of properties that have the Place class as a domain or as a range.

Types of Places
Place entities can be categorized with additional types from the Artsdata Place Types controlled vocabulary using the schema:additionalType property.
A full documentation page for the Artsdata Place Types controlled vocabulary is currently under development. Until this page is available, you may consult this Google Sheet version.
Minimal requirements for Place entities
To be minted (i.e. assigned) a new Artsdata unique persistent identifier or to be automatically linked to an existing Artsdata ID, a Place type entity must have a schema:name and compliant geographic information. Here are the three accepted shapes for geographic information.
1. complete schema:PostalAddress object (including streetAddress, locality (city), region (province/territory), postalCode, country)
"address": {
"type": "PostalAddress",
"streetAddress": "580 Rue Maclaren E",
"addressLocality": "Gatineau",
"addressRegion": "QC",
"postalCode": "J8L 2W1",
"addressCountry":"CA"
}
OR
2. schema:longitude + schema:latitude AND schema:PostalAddress object with region (province/territory) and country
"latitude": "45.5873706",
"longitude": "-75.400796",
"address": {
"type": "PostalAddress",
"addressRegion": "QC",
"addressCountry":"CA"
}
"geo": {
"@type": "GeoCoordinates",
"latitude": "40.75",
"longitude": "-73.98"
},
"address": {
"type": "PostalAddress",
"addressRegion": "QC",
"addressCountry":"CA"
}
OR
3. schema:geo with a GeoShape object AND schema:PostalAddress object with region (province/territory) and country
"geo": {
"@type": "GeoShape",
...one of the following properties: "box", "circle", "polygon"
},
"address": {
"type": "PostalAddress",
"addressRegion": "QC",
"addressCountry":"CA"
}
Notes:
- Artsdata uses
nameandaddress.postalCodeto automatically or manually reconcile (i.e. “recognize”) Place entities. When an external Place record has the extact same name and postal code as a Place in the Artsdata core graph (and no other Artsdata place has the same postal code), then the external record and the Artsdata entity are automatically linked. If two or more places in the Artsdata core graph have the same postal codes as an external Place record, then the potential matches have to be reviewed before one of them can be manually linked by an Artsdata steward. - In the absence of compliant geographic information, Artsdata may be able to reconcile a Place entity if an external Place record has a
sameAslink to an Artsdata or Wikidata ID. - Related discussion: Mint/Link Parks and Other Places Without Postal Codes #343
Properties in the Artsdata Ontology
| Property | Range | Status | Description |
|---|---|---|---|
| ado:managedBy | schema:Organization | Optional | Links a Place to the Organization responsible for its day-to-day operations. |
| ado:ownedBy | schema:Organization | Optional | Links a Place to an Organization that owns it. |
| ado:usedBy | schema:Organization | Optional | Links a Place to an Organization that regularly uses this Place as an Event location. A minimum threshold of regularity should be met for this relationship to be true. As a rule of thumb, if an organization regularly holds events every year in a given place, one could deem a usedBy relationship to be present. |
| ado:hasResident | schema:Organization | Optional | Links a Place to an Organization that has a residency status within this Place but does not manage the venue. Resident companies have privileged access to the facilities for creation, production and presentation activities. They may also be provided office space within the venue. |
Selected Schema.org properties
| Property | Status | Description |
|---|---|---|
| schema:name | Required | The name by which the Place is most commonly known. If describing a room within a building (e.g. a performance hall), use the name of that room rather than the name of the building. For more information, see these guidelines. |
| schema:address | Required | The physical address of the item. In the case of a building or an interior space within a building, Artsdata requires a full complete schema:PostalAddress object (including streetAddress, locality (city), region (province/territory), postalCode, country). For open-air spaces, Artstdata requires schema:PostalAddress object with region (province/territory) and country |
| schema:additionalType | Recommended | Enter additional types corresponding to the particular type of place. Refer to the Artsdata controlled vocabulary to identify the most appropriate event type(s). |
| schema:sameAs | Recommended | Enter the URIs of persistent identifiers (ex. Artsdata or Wikidata ID) that unambiguously identify the place entity. Always enter identifiers in full URI format (instead of entering just the ID itself). For more information, see these guidelines. |
| schema:alternateName | Optional | An alias for the place. For more information, see these guidelines. |
| schema:disambiguatingDescription | Optional | A short description of the item used to disambiguate from other, similar items. If left empty, Artsdata generates a disambiguating description based on the locality of the entity. |
| schema:url | Optional | Enter the canonical (aka “official”) URL of the place entity. |
| schema:containedInPlace | Optional | The basic containment relation between a place and one that contains it. This property is useful to define the relationship between a performance hall and the building that contains it. For more information, see these guidelines. |
| schema:containsPlace | Optional | The basic containment relation between a place and another that it contains. |
| schema:geo | Optional | This property is favoured over adding explicit longitude and latitude because the property geo can not only include longitude and latitude in a nested GeoCoordinates, but it can also be defined by a GeoShape object which gives flexibility to define parks and areas that cannot easily be definedd by a single geo coordinates node. |
| schema:latitude | Optional | The latitude of a location. Artsdata recommends nesting latitude and longitude under the geo property. |
| schema:longitude | Optional | The latitude of a location. Artsdata recommends nesting latitude and longitude under the geo property. |
| schema:maximumAttendeeCapacity | Optional | Maximum room capacity. Systems like scenepro.ca and Wikidata can feed this information to Artsdata. When multiple room configurations are available, only the maximum value should be selected. |