Procedure for Maintenance of PCA Reference Data Library

Contents

  1. Abstract
  2. Project Objective
  3. Proposed Scope
  4. Procedural steps, actions and responsibility
    1. Step 1. Initiation of Change Request
    2. Step 2. Evaluation of the Change Request
    3. Step 3. Validation of the Change Request
    4. Step 4. Resolution of the CR
    5. Step 5. Implementation of CR
  5. Definition and clarification of terms
    1. Terms for general use
    2. Terms for Status Identification of Change Requests (CR)

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 PCA, various (purpose specific) validation teams (e.g., 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 derived from ISO Annex ST "Procedure for the development and maintenance of standards in database format." However, it is limited to maintenance of existing Reference Data Items (RDI)and addition of new developed RDIs.

Procedural steps, actions and responsibility

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

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

https://www.posccaesar.org/svn/pub/PCA/RDSSupport/PCA_RDL_UpdateProcedure.png

Step 1. Initiation of Change Request

A CR initiator prepares a Change Request (CR) and submits [rdssupport@…] a PCA RDL Update spreadsheet File https://www.posccaesar.org/attachment/wiki/RdsMaintenanceProcedure/PCA%20RDL%20CR%20form.xlsx or owl file (TBD). The received CR is registered in the PCA RDL Request Log with status identifier "submitted" and the Initiator is automatically notified. The Initiator must be clearly identified, and can e.g. be an individual, a project, a company. If the Initiator is a group, company or a project, a main person of contact should be identified (by name and email address).

Information about a CR is available here.

Step 2. Evaluation of the Change Request

The CR is checked for completeness and consistency by the responsible PCA staff members, 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 automated.

If this initial check is satisfactory the Initiator is notified about the status update. When a CR has passed this initial check (syntactic quality), the content will be forwarded to the assigned Validation team for semantic and pragmatic quality evaluation. If the CR is deemed not to be satisfactory, the Initiator is notified with the reason(s).

If the quality of the information in the CR is satisfactory, the responsible PCA staff members set the status of the Change Request to "for validation" and notifies the Initiator about status update.

If considered practical, the responsible PCA staff members 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 Validation teams (e.g., SIGs).

Step 3. Validation of the Change Request

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

For the validation to be satisfactory (valid) more than half (a simple majority) of the PCA Validation Team members must approve the proposed updates. If the Initiator 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 Initiator with requests for modification and resubmission
  • rejected

The decision of the PCA Validation Team is communicated back to the responsible PCA staff members 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 changes are disseminated to the PCA RDL user community. Three months are given for the community to familiarize itself With changes and provide any feedback. Then the responsible PCA staff members upload/change any required in the PCA RDL production endpoint, sets the CR status identification to "resolved" and notifies the Initiator 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 CR spreadsheet
  • PCA staff members
  • PCA Validation Team
  • Initiator
  • 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.

Attachments

Home
About PCA
Reference Data Services
Projects
Workgroups