Abstract

This document contains an a procedure by which POSC Caesar Association (PCA) shall maintain and update the PCA Reference Data Library (PCA RDL), based on ISO 15926 and hosted by PCA Reference Data Services (PCA RDS).

Project Objective

The goal of this procedure is to describe the criteria and activities required to be performed by the various PCA Special Interest Groups (SIG) when a change request is received by PCA, in order to add, modify and delete Reference Data from the parts of the PCA RDL for which they have been assigned responsibility.

Proposed Scope

The procedure is based on ISO Annex ST "Procedure for the development and maintenance of standards in database format." However, it is limited to maintenance of existing standard items (and does not include development of new standards, nor review and withdrawal of existing standards).

Furthermore, the procedure only deals with maintenance action following the so-called "normal database procedure" which makes use of a Validation Team and a workflow around a dataset for information sharing; and is used by ISO for validation of new items or item combinations that are within the boundary of existing rules.

Procedural steps, actions and responsibility

The procedure is described in a summary fashion, highlighting the action(s) that are required on each step, as well as the associated responsibility.

The sections following subsections describe the various steps associated with the process for proposed maintenance of the PCA RDL.

Step 1. Initiation of Change Request

When a Change request (CR) is received from a Proposer in an RD Update File with the specified RD Input Format, the submitted CR is entered into the PCA RDL Request Log with status identifier "submitted" and the Proposer is automatically notified. The Proposer needs to be a registered user and submit the CR to the RDS Operations Support Ticket system (link). The Proposer must be clearly identified, and can e.g. be an individual, a project, a company. If the Proposer is a group, company or a project, a main person of contact should be identified (by name and email address).

Step 2. Evaluation of the Change Request

The CR is checked for completeness and consistency by the PCA RD Maintenance Team staff, and the CR is given status identifier "for evaluation". This step includes ensuring that all mandatory administrative and meta-data entries are appropriately filled-in and that any necessary accompanying items are sufficient for evaluation. This check is fully automated.

If this initial check is satisfactory the Proposer is notified about the status update. When a CR has passed this initial check, the content will be uploaded to the PCA Development endpoint. If the CR is deemed not to be satisfactory, the Proposer is notified with the reason(s) for rejection.

If the quality of the information in the CR is satisfactory, the PCA RD Maintenance Team Staff sets the status of the Change Request to "for validation" and notifies the Proposer about status update. If the CR is deemed not to be satisfactory, the Proposer is notified with the reason(s) for rejection.

If considered practical, the PCA RD Maintenance Team Staff may decide to combine items under more than one CR into one Work Package, or to separate items submitted under one CR into several Work Packages, in order to assign relevant parts of the CR (database items) to (one or more) relevant PCA SIGs.

Step 3. Validation of the Change Request

The PCA SIG Validation Team Responsible determines whether the Change Request (Work Package) is within the scope of the PCA RDL and valid for evaluation (or should be rejected).

For the validation to be satisfactory (valid) more than half (a simple majority) of the PCA SIG Validation Team members must approve the proposed updates. If the Proposer of a CR is a SIG, then a validation team must be assigned by the PCA TAB. The team must consist of domain experts that has been part of developing the CR, external domain experts and ISO 15926 experts.

Step 4. Resolution of the CR

Given evaluation of the PCA SIG Validation team, the Change Request may be

approved for inclusion in the PCA RDL and uploaded to the PCA staging area

sent back to the Proposer with requests for modification

sent back to the Proposer with requests for modification and resubmittal

rejected

The decision of the PCA SIG Validation Team is communicated back to the PCA RD Maintenance Team after the necessary number of members has completed their validation.

Step 5. Implementation of CR

After a CR is approved (either directly or after required modification), the PCA RD Maintenance Team staff uploads/changes any required in the PCA RDL production endpoint, sets the status identification to "resolved" and notifies the Proposer about planned inclusion of CR to the production endpoint.

Definition and clarification of terms

Terms for general use

PCA

PCA RDS

PCA RDL

PCA RDL Request Log

PCA RDL Update File

PCA RDL Input Format

PCA RD Maintenance Team

PCA SIG RD Validation Team

Proposer

Change Request (CR)

Work Package

Original Procedure

Normal database procedure

Database standard

Item (of a database standard)

Terms for Status Identification of Change Requests (CR)

Submitted

For Evaluation

For Validation

Resolved

These statuses are reflected by the Ticket system, and will be used by RDS Operations to indicate where the CR is in the process.