Intended Audience and Contact Information
Contact | Chief Data Officer, Office of the CIO |
---|---|
UDM Domain | Location |
Intended Audience | Internal UBC |
Change Log
Standard Version Date | Change Log |
---|---|
2022-12-12 |
Mapping of Invalid values From Systems(s) of Record (SoR) to Common Services sub-section of Compliance section added |
2022-03-09 | Reference Data Compliance for Data Integration sub-section of Compliance section added |
Purpose
This standard aims to achieve consistency across the University (Vancouver and Okanagan campuses and Reginal Sites) around the data collected for Sub-Building, and the format in which it is collected and stored.
This standard applies to all UBC applications collecting Sub-Building information. Exceptions are listed in the Dispensation section.
Standard
Definition: A sub-building is a portion of a Building, as defined in the UBC's Building Data Standard.
Note: Building data is comprehensively captured across the University. The sub-building is required when a hierarchical relationship from the sub-building, to the building and to some complexes, is needed as listed in the following guidelines:
- Based on significant named spaces, including blocks, wings, sections (e.g. Buchanan Block B)
- Based on operational needs for a sub-building, including relationships between systems (e.g. Salish House - a significant named space in a building)
- Based on occupants of a building with a unique civic address for emergency response purpose (e.g. UBC Campus Security)
Attribute | Requirement | Definition |
---|---|---|
Sub-Building Name | Required | Name of sub-building |
Sub-Building UID | Required | Unique sub-building identifier |
Sub-Building Status | Required | Status of the sub-building (Complete, Under Construction) |
GBA | Optional | Gross Building Area; Total area of sub-building where it sums to a building (where required) |
Building UID | Required | BLDG_UID of Parent Building as recorded in Building database |
Sub-Building Usage | Required | Primary Usage based on occupancy, see list of accepted values below. |
Form Type | Optional | Describes the form of the structure. (e.g.: section, high-rise, low-rise, wing) |
Grade | Optional | The term used to indicate whether a sub-building is above or below the ground level. |
Construction Material | Optional | Classification of building based on construction material type. As specified in the Development Permit. |
Accepted Data Values for Sub-building Usage:
Accepted Data Value | Definition |
---|---|
Academic | Building used for instruction, education, laboratory, or student services purposes. |
Administrative | Building used for administrative purposes, mainly offices. |
Athletics | Building used for athletics and recreation purposes. |
Commons | Building that is located in the mixed-use (primarily student housing with academic) areas identified in the Vancouver Campus Plan. |
Commercial | Building used for commercial purposes. |
Housing | Building used for residential purposes in neighborhoods. |
Operations | Building used for operational purposes, with limited offices. |
Other | Building used for other purposes that are not defined by the other usages. Examples include Theological colleges. |
Parking | Building used for parking. |
Research | Building used for research purposes. Examples include NRC, TRIUMF. |
Services | Building used for the purposes of providing a service to the UBC Community, including students, faculty, staff and residents. Examples include cultural attractions, hospitals, child care centers, and community centers. |
Student housing | Building used for student housing purposes. |
Accepted Data Values for Sub-building Form Type:
Accepted Data Value | Definition |
---|---|
Section | a specific portion of a building |
Highrise | a structure that is 5 or more storeys |
Low-rise | a structure that is 1-4 storeys |
Wing | a part of a building that may be directly adjoined to other wings/blocks to make up a building. |
Compliance
This standard about Sub-Building must be complied with every stage of the data lifecycle with the exception of any dispensations (see Dispensation section):
- All applications must collect Sub-Building as recommended in this standard.
- Enterprise Data Integration must adopt this standard.
Reference Data Compliance for Data Integration
The use of accepted reference data values in this standard for data integration among applications must comply with the enterprise integration pattern of leveraging the reference data common service API (Application Programming Interface) published in UBC MuleSoft Exchange.
Any application that intends to access real-time, case-level reference data should have the application owner or manager complete and submit a Request API Access form.
MAPPING OF INVALID VALUES FROM SYSTEM(S) OF RECORD (SOR) TO COMMON SERVICES
A common service can only accommodate standard reference data enumerations that are available in the SoR as approved by the Data Governance Steering Committee or Data Trustee.
A reference data value that does not match any of the standard reference data value enumerations is considered ‘invalid’. Any records from a SoR containing an invalid reference data value for a given data element or attribute must be mapped as an ‘empty’ value in common service(s). Where a reference data value may potentially have the same meaning as a standard enumeration but named differently in the system of record can be corrected to match the appropriate standard enumeration. Please consult with the EDG team in such cases.
Additional Reference Data values in a SoR that are not part of the standard reference data enumerations are to be omitted in the common service.
Dispensation
None.
For any compliance questions or requests for a temporary dispensation, please contact the Enterprise Data Governance Team.