Mapping - introduction

latest update: 2016-10-24   

Introduction

Data that reside in an application program or data base can be added to the integrated plant lifecycle information. To that end that data shall be mapped to the format as defined in ISO 15926-8. This paper describes the process.

Limitation

Since no two applications are the same, the hints for the source side can only be generic.

Implicit and explicit information

All customary data stores contain "implicit" data. This means that much contextual information is left out, because the software and the user "know" (or at least think they do).

"Explicit" information includes, but is not limited to, information about:

  • equipment and piping that contain a stream, where that stream possesses most of the  properties;
  • compositional information, such as:
    • assembly of piping systems;
    • assembly of equipment systems (e.g. a pump system has pump, drive, transmission, motor controls, etc;
    • relationship between piping or equipment and their insulation and heat tracing;
    • relationship between piping or equipment and in-line/on-line instrumentation items;
    • etc.
  • activity-based information (e.g. stress testing, hydrostatic testing, etc);
  • etc

In order to build a completely integrated lifecycle data base, all information must be explicit to the maximum extent, inasmuch that is required by the business needs. An example can be found in the publication Mapping a Line List.

Declaring objects

All objects shall be declared, as described in the publication "Declaring an object". It is advisable to store all such declarations in the Project Façade (see here), so that they can be looked up by all project parties. The responsibility for assigning equipment numbers, line numbers, instrument tag numbers, etc usually is well organized in a project, and doesn't have to change.

Mapping

Mapping involves outgoing mapping and incoming mapping. Outgoing involves data for which one is responsible, incoming for which one is not responsible, but one needs those data for the particular application.

What incoming data shall be mapped?

Incoming data always originates from SPARQL queries, typically in JSON format. What exactly is required is different for each application.

What outgoing data shall be mapped?

Only the data for which the user of the application is responsible shall be mapped. Responsibility means that the user has read/write access to those data, and that it is expected that he/she is the sole person that creates those data and that the data will be of use for others. Obviously this requires some planning.

Mapping target

The target for outgoing mapping is a file in Turtle format, as defined in ISO 15926-8.

NOTE - The format used in Part 8 is RDF/XML, which is also acceptable. Turtle is a new standard and much simpler.

Heading

This file starts with a header that consists of a fixed part and a part that is specific for the target façade:

@prefix : <http://www.p1234.xyz-corp.com/> . # the 'base' URI

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

@prefix dm: <http://data.15926.org/dm/> .

@prefix meta: <http://data.15926.org/meta/> .

@prefix tpl: <http://data.15926.org/tpl/> .

@prefix rdl: <http://data.15926.org/rdl/> .

Example of mapping code

[by Onno]

Planning

It is recommendable to provide software that allows the user, for example in the data dictionary (if available), to indicate different ways of triggering the mapping of a data element. Examples are:

  • automatic whenever the value has changed
  • by asking the user
  • option: immediate or overnight (preferred)

But, as said in the beginning, this depends on the possibilities in the application software.