Intended Audience and Contact Information
| Contact | Chief Data Officer, Office of the CIO |
|---|---|
| UDM Domain | Asset |
| Intended Audience | Internal UBC |
| Metadata Standard ID | DG0068 |
Purpose
This standard aims to achieve consistency in naming and describing Data Access Framework (DAF) enabled Application Programming Interfaces (API). An API is a software intermediary that allows two applications to exchange information.
In supporting teaching, learning, research, and administrative functions at UBC, APIs are expected to be registered consistently in a System of Record (SoR), such as UBC's Metadata Management System for search and discovery, and to enable consolidated reporting for informed decision making. The successful process flow for providing data delivery services requires knowledge about available APIs. The trustworthy inventory of APIs can then be leveraged for both strategic and operational needs, enabling regulatory compliance requirements, data access requests, and enable correlation of data across functions for joint initiatives such as business continuity (e.g. disaster recovery), service management, data design and architecture, incident response, and cybersecurity events.
This standard is to be adhered at all times. Exceptions are listed in the Dispensation section.
Standard
The following metadata elements provide additional information about APIs and have been identified to support UBC data and reporting needs.
| Metadata Element: API Identifier | |
|---|---|
| Description | The Identifier attribute contains a numeric or alphanumeric string that is associated with a single asset within the metadata System of Record (SoR) and external systems. |
| Type | Descriptive |
| Standard | Unique within pool of Ids |
| Use | Required |
| Metadata Element: API Name | |
| Description | A word or set of words referring to a UBC interface. |
| Type | Descriptive |
| Standard | Align with canonical data model such as the UBC University Data Model (UDM) domain structure. See API Names Confluece Page. |
| Use | Required |
| Metadata Element: Authentication | |
| Description | The primary authentication method used to execute the service. |
| Type | Descriptive |
| Standard | Reference List:
|
| Use | Required |
| Metadata Element: Data Steward | |
| Description | The University business official(s) having direct operational-level responsibility for the management of one or more types of Institutional data and have authority to make decisions, including approving access requests. |
| Type | Relationship |
| Content Standard | Full Name, Position, Department |
| Use | Required |
| Metadata Element: Business Responsible | |
| Description | The functional business unit the asset primarily supports. |
| Type | Relationship |
| Standard | Business Unit See Internal Organization Data Standard |
| Use | Required |
| Metadata Element: Data Service [API] Type | |
| Description | The protocol and architecture format the data service uses. |
| Type | Descriptive |
| Standard | Reference List:
|
| Use | Required |
| Metadata Element: Endpoint URL | |
| Description | A digital location (URL) at which an API connects with the software program. |
| Type | Descriptive |
| Standard | hxxps://api.ubc.ca/<API Name>/{version} |
| Use | Required |
| Metadata Element: Version | |
| Description | The version of the service, method, or function as defined in release docs or checked into a code repository. |
| Type | Relationship |
| Standard | Alphanumeric String e.g. v1.0.0 |
| Use | Required |
| Metadata Element: Implemented By | |
| Description | The relation between data service and technology asset which hosts it. |
| Type | Relationship |
| Standard | Business Platform Name See Technology Asset Name & Metadata Standard |
| Use | Required |
| Metadata Element: Purpose | |
| Description | An explanation of the intended purpose. |
| Type | Descriptive |
| Standard | None |
| Use | Required |
| Metadata Element: Technical Owner | |
| Description | The technical person accountable for the asset. |
| Type | Relationship |
| Standard | Full name, Position, Department |
| Use | Required |
| Metadata Element: Technical Responsible | |
| Description | The technical IT unit that supports the asset. |
| Type | Relationship |
| Standard | Business Unit See Internal Organization Data Standard |
| Use | Required |
| Metadata Element: UBC Data Domain | |
| Description | The common overarching data community the API delivers. |
| Type | Descriptive |
| Standard | See List on Collibra |
| Use | Required |
| Metadata Element: is required by Contract | |
| Description | Access is provided under a data access acknowledgement. |
| Type | Relationship |
| Standard | DAF Contract Identifier |
| Use | Optional |
| Metadata Element: Uses Crosswalk | |
| Description | A Data Service that uses a crosswalk to translate data for all or some attributes. |
| Type | Relationship |
| Standard | Link to specific code mapping crosswalk(s) on Collibra |
| Use | Optional |
| Metadata Element: Uses Parameter | |
| Description | A Data Service uses parameters at a high level. |
| Type | Relationship |
| Standard | Valid Attribute Parameter Name |
| Use | Optional |
| Metadata Element: Uses Mapping Specification | |
| Description | A Data Service uses mapping specification at the attribute level (UDM, SOR). |
| Type | Relationship |
| Standard | Link to a specific filed mapping specification on Collibra |
| Use | Optional |
| Metadata Element: Uses/used in Asset | |
| Description | The relation between data service and technology asset which consumes it. |
| Type | Relationship |
| Standard | Business Application Name See Technology Asset Name & Metadata Standard |
| Use | Optional |
Compliance
The above standard must be complied at every stage of the data lifecycle with the exception of any dispensations (see Dispensation section).
- All applications must collect data 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
Legacy systems are exempt from this data standard. As systems are replaced, adoption of this standard is required.
For any compliance questions or requests for a temporary dispensation, please contact the Enterprise Data Governance Team.