Mapping CFIHOS data

latest update: 2021-01-30


The CFIHOS data model V1.4 has 37 tables that are to be populated by the owner/operator and/or EPC contractor. The remaining 44 tables are for storage of reference data items.

This topic describes how you can handle the mapping from local data to validated CFIHOS hand-over data, and further mapping to ISO 15926-8 exchange files when required.

The “CFIHOS Implementation Guide for Contractor” states: "The definition and implementation of a validation system is crucial for an efficient and successful handover.". That has been a leading factor for this topic.


The source of most life-cycle data is either a relational data base or a number of spreadsheets.
The method for mapping an instance of the CFIHOS relational data model to the format defined in ISO 15926-7/8 as given here consists of the following phases:
  1. using ETL (or in exceptional cases: manually) map the local data to CSV files, one file type per data model table, and convert these to RDF ;
  2. import those converted CSV file sin a predefined RDF triple store, validate the data with SHACL, and, using the query language SPARQL, generate a hand-over file in Turtle, JSON, XML, CSV or TSV ;
  3. using a CSV file, as generated under 1., import the validated data into a mapping tool that converts them into instances of ISO 15926-7 templates in the ISO 15926-8 format;
  4. mapping functional diagrams (e.g. P&ID, One-line Diagram, Loop Diagram) to place the results of 2. in the context of the plant topology, thus achieving integration ;
  5. and in the longer term: map the data directly at the source applications to ISO 15926-7/8, validate them more thoroughly because of that topological context .

Phase 1

The CFIHOS V1.4 data model has been mapped to ISO 15926-ish structures, as detailed in the topic CFIHOS Data Model and Reference Data . This has mainly been done in order to make the contents of all CSV files easily accessible. Where possible the RDL data have been typed with ISO 15926-2 entity types.

The next step a complete RDF rendering by representing all attributes of the data model as either owl:ObjectProperty or owl:DatatypeProperty, where in general:
  • the Primary Keys are DatatypeProperties and owl:HasKey, the latter to indicate the unique identification of the object
  • the Foreign Keys are made an ObjectProperty
  • the rest, with a Literal as range, are made a DatatypeProperty
As an example the SITE, PLANT and AREA table will be mapped. First a summary of the attributes:

SITE cfihos:00000001 Site code cfihos:00000001.10000003 A code that uniquely identifies the site
SITEcfihos:00000001Site namecfihos:00000001.10000004A unique name to identify a geographical location.
SITE cfihos:00000001 Measurement system code cfihos:00000001.10000240 The default measurement system that is used by a site

PLANT cfihos:00000031 Plant code cfihos:00000031.10000005 A code that uniquely identifies the plant
PLANTcfihos:00000031Plant namecfihos:00000031.10000006The full name of the plant
PLANTcfihos:00000031Site codecfihos:00000031.10000003The site at which the plant is located
PLANT cfihos:00000031 ISO language code cfihos:00000031.10000147 The language that should be used by default for all exchange of information related to that plant
PLANT cfihos:00000031 Measurement system code cfihos:00000031.10000240 The default measurement system that is used by a plant

AREAcfihos:00000003Area codecfihos:00000003.10000001A code that uniquely identifies the area within the plant
AREAcfihos:00000003Area namecfihos:00000003.10000002A name describing the location of an area within the plant.
AREA cfihos:00000003 Plant code cfihos:00000003.10000005 The plant the area is a part of

The next step is to define the applicable owl:Properties with their rdfs:domain (always the table) and rdfs:range, as well as a more human-readable property label. That looks like this:

sw:Site sw:sitecode001 xsd:string owl:DatatypeProperty
sw:Site sw:measurementSystemCode001 sw:MeasurementSystem owl:ObjectProperty


sw:Plant sw:plantCode031 xsd:string owl:DatatypeProperty
sw:Plant sw:isoLanguageCode031 sw:IsoLanguage owl:ObjectProperty
sw:Plant sw:measurementSystemCode031 sw:MeasurementSystem owl:ObjectProperty


sw:Area sw:plantCode003 sw:Plant owl:ObjectProperty

The predicates are related to the CFIHOS data model attributes with an rdfs:isDefinedBy the applicable CFIHOS unique code.
The addition of a three-digit code (e.g. 031) is to make attributes that occur multiple times unique by adding the last three digits of the CFIHOS unique code of the table. That is necessary for the definition of each owl:Property, such as that for above sw:plantCode003:
sw:plantCode003 rdf:type owl:ObjectProperty ;
      rdfs:isDefinedBy cfihos:00000003.10000005 ;
      skos:definition "The plant the area is a part of" ;
      rdfs:label  "Plant code"^^xsd:string ;
      rdfs:domain  sw:Area ;
      rdfs:range  sw:Plant .
Table row metamodel

The next step is to turn the above into a metamodel for table rows:

:sw:UUID-001 sw:measurementSystemCode001 sw:MeasurementSystem
sw:UUID-031 sw:isoLanguageCode031 sw:IsoLanguage
:sw:UUID-031 sw:measurementSystemCode031 sw:MeasurementSystem
sw:UUID-003 sw:areaName003 xsd:string

This deserves some explanation: In this set-up, as also followed in this entire website, an occurrence gets a UUID that is globally unique. So information like a "Site code" is just an alternative, human-readable, identifier. That also solves the problem of composite keys. Above sw:UUID-xxx in the first column indicates that when an instance is created that sw:UUID-xxx must be replaced with a, hitherto unused, UUID.

It should be noted that the CFIHOS hand-over data contain the labels of the ObjectProperty instances rather than the referred object. For each instance the applicable UUID needs to be fetched or generated and inserted.

Like always there is a case where different rules apply: the many-to-many tables. Let's take one: DOCUMENT REVISION PURCHASE ORDER REFERENCE
This kind of table has, in the CFIHOS data model, no primary key, but an occurrence does get a UUID:

sw:UUID-085 rdfs:subClassOf sw:DocumentRevisionPurchaseOrderReference
sw:UUID-085 sw:documentNumber sw:DocumentMaster
sw:UUID-085 sw:documentRevisionCode sw:DocumentRevision
sw:UUID-085 sw:purchaseOrderIssuerCompanyName sw:Company
sw:UUID-085 sw:purchaseOrderNumber sw:PurchaseOrder

Assume, as an example, the following small CSV files are in the handed-over data (for readability converted to Excel):

SITE Site code Site name Measurement system code
SITE KAS Kashagan field SI

PLANT Plant code Plant name Site code ISO language code Measurement system code
PLANT 6000 Onshore Processing Facility (OPF) KAS en SI

AREA Area code Area name Plant code
AREA 14 Utility area 6000
then the following instatiated table row metamodels apply:

:58acea04-8cfd-4898-8933-5131fa039c79 rdf:type sw:Site
:58acea04-8cfd-4898-8933-5131fa039c79 sw:siteCode001 "KAS"^^xsd:string
:58acea04-8cfd-4898-8933-5131fa039c79sw:siteName001"Kashagan field"^^xsd:string
:58acea04-8cfd-4898-8933-5131fa039c79 sw:measurementSystemCode001 cfihos:60001649

:b2232870-7950-449a-bc6a-b7f5b14a7c0e rdf:type sw:Plant
:b2232870-7950-449a-bc6a-b7f5b14a7c0e sw:plantCode031 "6000"^^xsd:string
:b2232870-7950-449a-bc6a-b7f5b14a7c0esw:plantName031"Onshore Processing Facility (OPF)"^^xsd:string
:b2232870-7950-449a-bc6a-b7f5b14a7c0e sw:isoLanguageCode031 cfihos:60000443
:b2232870-7950-449a-bc6a-b7f5b14a7c0e sw:measurementSystemCode031 cfihos:60001649

:7286dcc6-c71a-42ff-818e-cb94778dd96d rdf:type sw:Area
:7286dcc6-c71a-42ff-818e-cb94778dd96d sw:areaCode003 "14"^^xsd:string
:7286dcc6-c71a-42ff-818e-cb94778dd96d sw:areaName003 "Utility area"^^xsd:string

where the foreign key input values from the CSV files (e.g. the value 'KAS' of sw:siteCode031) have been replaced with the RDL identifier or UUID (e.g. '
:58acea04-8cfd-4898-8933-5131fa039c79') of the things they are a label of.

Note that in the metamodel we see

an rdfs:subClassOf

and here, in the instantiation:

an rdf:type.

This can be explained with the following diagram:

This results in the following code in the Turtle format:

@prefix : <> .
@prefix xsd: <> .
@prefix rdf: <> .
@prefix rdl: <> .
@prefix cfihos: <> . # local RDL extension
@prefix sw: <> .

:58acea04-8cfd-4898-8933-5131fa039c79  rdf:type  sw:Site ;
001  "KAS" ;
    sw:siteName001  "Kashagan field" ;
    sw:measurementSystemCode001  cfihos:60001649 .

:b2232870-7950-449a-bc6a-b7f5b14a7c0e  rdf:type  sw:Plant ;
031  "6000" ;
    sw:plantName031  "Onshore Processing Facility (OPF)" ;
    sw:siteCode031  :58acea04-8cfd-4898-8933-5131fa039c79 ;
    sw:isoLanguageCode031    cfihos:60001692 ;
    sw:measurementSystemCode031  cfihos:60001649 .

:7286dcc6-c71a-42ff-818e-cb94778dd96d  rdf:type  sw:Area ;

    sw:areaCode003 "14" ;
    sw:areaName003 "Utility area" ;
    sw:plantCode003  :b2232870-7950-449a-bc6a-b7f5b14a7c0e .

and this will result in the following triples:

<> <> <> .
<> <
001> "KAS" .
<> <> "Kashagan field" .
<> <> <> .

<> <> <> .
<> <
031> "6000" .
<> <> "Onshore Processing Facility (OPF)" .
<> <> <> .
<> <> <> .
<> <> <> .

<> <> <> .

<> <
003> "14" .
<> <> "Utility area" .
<> <> <> .

This is represented in the following graph:

Graph for RDF rendering of one CFIHOS Site + Plant + Area instance combination

The above triples are stored in a triple store and can be queried with SPARQL. If, in this example, the value for plantCode003FK in the Area table had been something like 5900 and there is no such plantCode, a referential integrity error message results.

Note that this isn't ISO 15926 but vanilla RDF.

Phase 2

In Phase 2 all 367 data model attributes + 630 RDL properties = 997 CFIHOS properties are to be mapped to ISO 15926-7/8 templates/specialized templates.
To a large extent this has been done in a preparational mode, and the formal code is being prepared, and this topic will be extended with the results.

Many of the CFIHOS attributes and properties are conflated and result in the same template(s) with one or two fixed variables, so the real number mappings is lower.

The input for Phase 2 is made with CSV files again, either the ones used as input for Phase 1 or CSV files generated from the (validated!) data in the triple store of Phase 1.

The (work-in-progress) mapping software that is based on TIPs (explained here) uses so-called TIP "signatures" that serves as the input for the conversion to template instances. When the data of one CSV file are mapped to more than one template the input of one template is, as a consequence, a subset of the CSV data.

The spreadsheet below,
for the AREA table, shows what happens with that input. It is shown for instructional purposes only, the person doing the mapping is not dealing with all that.

In the top, as a reminder, the predicates per table row, and then a representation with an ISO 15926-7 template for each predicate. The meaning of the five columns is as follows:
  • TIP INPUT the signature of the applicable specialized TIP for data entry
  • the signature of the applicable declaration type or base TIP type
  • a name for a SPARQL script that is used as an instruction what to do with the input data
  • the applicable ISO 15926-7 template, taken from the Template Specifications, with its 'roles'
  • a meta model with fixed fields and fill-in-the-blanks fields, where the applicable script defines what happens with the text, for example: in the lowest template, tpl:RelativeLocationOfIndividual, the text that replaces "Plant code" in "tpl:hasLocator :UUID-of-[Plant code]" is "6000" the software will fetch the UUID for Plant code = 6000 and insert that UUID there.

first block represents the RDF version of the CFIHOS data model V1.4
sw:UUID-003 rdf:type sw:Area  
sw:UUID-003 sw:areaCode003 xsd:string area code
sw:UUID-003 sw:plantCode003 xsd:string  plant code
sw:UUID-003 sw:areaName003 xsd:string area name

IND-wholeLifeIndividualDeclaration Declaration of WholeLifeIndividual tip:CFIHOS-IND-AREA-areaDeclaration
tip:IND-wholeLifeIndividualDeclaration_var_Label rdfs:label uuidOf "area code"^^xsd:string
tip:IND-wholeLifeIndividualDeclaration_var_EntityType rdf:type fixed dm:SpatialLocation
tip:IND-wholeLifeIndividualDeclaration_var_WorldType rdf:type select lci:NonActualIndividual | dm:ActualIndividual
tip:IND-wholeLifeIndividualDeclaration_var_EssentialType rdf:type fixed rdl:RDS282689
tip:IND-wholeLifeIndividualDeclaration_var_LifecycleActivity meta:hasLifecycleActivity memberOf cfihos:50000121
tip:IND-wholeLifeIndividualDeclaration_var_EffectiveDate meta:valEffectiveDate effDate "valEffectiveDate"^^xsd:dateTime

IND-isLocatedRelativeTo tpl:RelativeLocationOfIndividual tip:CFIHOS-IND-AREA-plantCode
tip:IND-isLocatedRelativeTo_label [EssentialType] individual [hasLocated] is located [hasRelativeLocationType] [EssentialType] individual [hasLocator] replace "[PLANT AREA] individual  [area code] is located [INSIDE] [PLANT] individual [plant code]"@en
tip:IND-isLocatedRelativeTo_var_Label-1 tpl:hasLocated uuidOf "area code"^^xsd:string
tip:IND-isLocatedRelativeTo_var_Label-2 tpl:hasLocator uuidOf "plant code"^^xsd:string
tip:IND-isLocatedRelativeTo_var_Label-3 tpl:hasRelativeLocationType fixed rdl:RDS2229920
tip:IND-isLocatedRelativeTo_var_LifecycleActivity meta:hasLifecycleActivity memberOf cfihos:50000121
tip:IND-isLocatedRelativeTo_var_EffectiveDate meta:valEffectiveDate effDate "valEffectiveDate"^^xsd:dateTime

IND-isIdentifiedWithString tpl:ClassifiedIdentificationOfIndividual tip:CFIHOS-IND-AREA-areaName
tip:IND-isIdentifiedWithString_label [EssentialType] individual [hasIdentified] has an [hasIdentificationType] [valIdentifier] replace "[PLANT AREA] individual [area code] has an [IDENTIFICATION BY PLANT AREA NAME] [area name]"@en
tip:IND-isIdentifiedWithString_var_Label-1 tpl:hasIdentified uuidOf "area code"^^xsd:string
tip:IND-isIdentifiedWithString_var_Value-1 tpl:valIdentifier replace "area name"^^xsd:string
tip:IND-isIdentifiedWithString_var_Label-2 tpl:hasIdentificationType fixed rdl:RDS2227020
tip:IND-isIdentifiedWithString_var_LifecycleActivity meta:hasLifecycleActivity memberOf cfihos:50000121
tip:IND-isIdentifiedWithString_var_EffectiveDate meta:valEffectiveDate effDate "valEffectiveDate"^^xsd:dateTime

NOTE - The attentive reader may have noted that the predicate codes and predicate names are both used. Their link is defined in the definitions of owl:ObjectProperty and owl:DatatypeProperty.

Visit to see the same kind of mapping spreadsheets for other CFIHOS data model tables.

Using the earlier mentioned CSV files again:

SITE Site code Site name Measurement system code
SITE KAS Kashagan field SI

PLANT  Plant code  Plant name Site code ISO language code Measurement system code
PLANT 6000 Onshore Processing Facility (OPF) KAS  en SI

AREA Area code Area name Plant code
AREA 14 Utility area 6000

the following code would be generated:

@prefix : <> .
@prefix xsd: <> .
@prefix rdf: <> .
@prefix rdfs: <> .
@prefix owl: <> .
@prefix skos: <> .
@prefix dm: <> .
@prefix lci: <> .
@prefix meta: <> .
@prefix tpl: <> .
@prefix rdl: <> .
@prefix cfihos: <> . # local RDL extension
@prefix sw: <> .

# Site 'KAS'
# Declaration - sw:sitecode
:58acea04-8cfd-4898-8933-5131fa039c79 rdf:type dm:SpatialLocation, dm:WholeLifeIndividual, dm:ActualIndividual, rdl:RDS2229881 ;
    rdfs:label "KAS" ;
    meta:hasLifecycleActivity cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# sw:siteName001
:ab2485f6-2462-4689-b56e-2f5f173018b6 rdf:type tpl:ClassifiedIdentificationOfIndividual ;
    rdfs:label "[PLANT SITE] individual [KAS] has an [IDENTIFICATION BY SITE NAME] [Kashagan field]"@en ;
    tpl:hasIdentified  :
58acea04-8cfd-4898-8933-5131fa039c79 ;
    tpl:valIdentifier  "Kashagan field" ;
    tpl:hasIdentificationType  rdl:RDS2226620 ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# sw:measurementSystemCode001
:ffd121e4-ee92-48f9-8f7e-845e4c287c26  rdf:type tpl:ClassificationOfIndividual ;
    rdfs:label "[PLANT SITE] individual [KAS] is classified with [Measurement System] class [SI]"@en ;
    tpl:hasClassified  :58acea04-8cfd-4898-8933-5131fa039c79 ;
    tpl:hasClassifier  cfihos:60001649 ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# Plant 6000
Declaration - sw:plantCode031
:b2232870-7950-449a-bc6a-b7f5b14a7c0e  rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, dm:ActualIndividual, rdl:RDS7151797 ;
    rdfs:label "6000" ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# sw:plantName031
:7352efd9-04e7-4fac-8087-7f12ebdd5789 rdf:type
tpl:ClassifiedIdentificationOfIndividual ;
    rdfs:label "[PLANT] individual [6000] has an [IDENTIFICATION BY PLANT NAME] [Onshore Processing Facility (OPF)]"@en ;
:b2232870-7950-449a-bc6a-b7f5b14a7c0e ;
    tpl:valIdentifier  "Onshore Processing Facility (OPF)" ;
    tpl:hasIdentificationType  rdl:RDS2226621 ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# sw:siteCode031
:5bcbe778-5a75-4f47-863c-ba9cce6b8c7f rdf:type tpl:RelativeLocationOfIndividual ;
    rdfs:label "[PLANT] individual [6000] is located [INSIDE] [PLANT SITE] individual [KAS]"@en ;
:b2232870-7950-449a-bc6a-b7f5b14a7c0e ;
:58acea04-8cfd-4898-8933-5131fa039c799 ;
    tpl:hasRelativeLocationType  rdl:RDS2229920 ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# sw:isoLanguageCode031
:eb4caa20-a3b0-4536-a07d-ec3aa58b73fb rdf:type  tpl:InformationRepresentationOfIndividualInLanguage ;
    rdfs:label "[PLANT] individual [6000] is classified with [Language] class [en]"@en ;
:b2232870-7950-449a-bc6a-b7f5b14a7c0e ;
    tpl:hasLanguage  cfihos:60000443 ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# sw:measurementSystemCode031
:1b98f50b-26ab-475c-bc78-10b7da08c661 rdf:type
tpl:ClassificationOfIndividual ;
    rdfs:label "[PLANT} individual [6000] is classified with [Measurement System] class [SI]"@en ;
:b2232870-7950-449a-bc6a-b7f5b14a7c0e ;
    tpl:hasClassifier  cfihos:60001649 ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# Area '14'
# Declaration - sw:areaCode003
:7286dcc6-c71a-42ff-818e-cb94778dd96d rdf:type dm:SpatialLocation, dm:WholeLifeIndividual, dm:ActualIndividual, rdl:RDS282689  ;
    rdfs:label "14" ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# sw:areaName003
:f36a3be5-9c57-471d-95b6-d38a457645a2  rdf:type
tpl:ClassifiedIdentificationOfIndividual ;
    rdfs:label "[PLANT AREA] individual [14] has an [IDENTIFICATION BY PLANT AREA NAME] [
Utility area]"@en ;
    tpl:hasIdentified  :
7286dcc6-c71a-42ff-818e-cb94778dd96dd ;
    tpl:valIdentifier  "Utility area" ;
    tpl:hasIdentificationType  rdl:RDS2227020 ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

# sw:plantCode003
:ad77c06c-b6a5-475f-a4e2-76c299378e04  rdf:type 
tpl:RelativeLocationOfIndividual ;
    rdfs:label "[PLANT AREA] individual  [14] is located [INSIDE] [PLANT] individual [6000]"@en ;
    tpl:hasLocated  :7286dcc6-c71a-42ff-818e-cb94778dd96d ;
    tpl:hasLocator :b2232870-7950-449a-bc6a-b7f5b14a7c0e ;
rdl:RDS2229920 ;
cfihos:60001657 ;
    meta:valEffectiveDate "2019-04-23T00:00:00Z"^^xsd:dateTime .

This is represented in the following graph, where the metadata are left out for space reasons.
At the lefthand side the declared items are shown and at the righthand side the templates that represent the information about these declared objects.
The circles denote an instance with a UUID as globally unique identifier. The green objects are the template definitions, the blue ones are in some reference data library.
Finally the white objects are for XML Schema Literals.

Note the existence of templates for interrelationship between two declared objects.

Normalized graph for instances of Site + Plant + Area

The plant information is being represented as one large fabric of interrelated,declared, objects and templates, referring to these objects and template instances, and to reference data (which are declared objects as well, but you don't have to declare them yourself).

The W3C standard query language SPARQL can be used to fetch exactly that information that you are interested in. Since every declaration and every template instance has an effective date as metadata, older information is not being physically replaced by newer one, but all information stays in storage infinitively. Compare that with sedimentation of clay in a river, or layers of snow in the ice cap of Antarctica. It is possible to find the information that was valid at a particular date-time in the past, or find time series of events through a given period in time.

Since each declaration and each template is autonomous the use of blockchains is considered.

Phase 2 mapping of CFIHOS Properties

So far we have mapped the data base tables and their attributes. This is, for the most, including cross-referencing objects, relating them to RDL items, and identifying/describing them with strings or Booleans.
But there is still a large swath of mappings to be done, relating to quantitative and qualitative properties, of which the latters often are just some essentially unstructured texts in a spreadsheet.

Quantitative properties

Let us begin with the quantitative properties. These are what they seem to be, and there is a set of templates for them. But a complicating aspect of many of the CFIHOS quantitative properties is that they a conflated, i.e. semantically they include other information, mostly of compositional nature. Elsewhere one of the notorious examples has been given:
"normal operating outlet steam pressure auxiliary driver"
for which the following decomposition applies:
where the following instances will have to be declared:
  • the property possessing device, assume here: PUMP SYSTEM
  • (Stream of) STEAM
Mind you, this is a horrible example, but it illustrates the problem: we need four declarations and six templates to explicitly represent that information. This property is attributed to a pump class and it leaves out information because it assumes that the user knows what is meant. But computers aren't that smart, and besides that you have to ask yourself what happens with the integration of information when later it appears to be necessary to put other information about that implied driver and/or outlet and/or stream on record.

It is understood that CFIHOS considers the creation of composition structures for plant items, and that would be recommendable. But it will take a long time, so for now we have to do analyses like the above on the basis of the properties to be mapped and of common sense.

It might be of interest to see the graph of above decomposition:


Normalized graph for conflated property "normal operating outlet steam pressure auxiliary driver"

Qualitative properties

The qualitative properties have "values" that are collected in a pick-list. In most (not all) cases a mapping can be made per pick-list, with specializations of that mapping for each 'value'.
A complete list of all mappings from qualitative property value to ISO 15926-7 templates is in preparation and will be posted here a.s.a.p.. Some 75% will be tpl:SpecializationOfClassOfIndividual in case the property possessor is a Class or tpl:ClassificationOfIndividual in case it is an Individual.
Whenever the Properties per Class have been published in V1.5 specializations of these templates will be created and published.

To give an example, assume that the pump class of the previous example has a qualitative property called 'explosion protection gas group' with a value 'IIA'. In ISO 15926 terms this means that the pump system has been designed as a GROUP IIA APPARATUS that is suitable for all places with an explosive gas atmosphere as defined for CENELEC Group IIA combusion material, as defined in IEC 60079-0.
The graph then looks like this:

Normalized graph for CFIHOS "qualitative property" value 'explosion protection gas group IIA'

The cfihos:60000631 is, in the CFIHOS RDL, marked as subClassOf the IEC class iec:RDS1084229 . Note that the pump system CO-28-P-101 already existed since the previous example and does not have to be declared again but simply referred to. The software shall check whether the possessor already exists.

Planned End-result

The plan is to create a mapping engine that accepts the CFIHOS hand-over data and converts these to a full ISO 15926-7/8 exchange file.

Phase 1 and Phase 2 compared

As explained elsewhere in this website the differences and (dis)advantages of the Phase 1 results vs Phase 2 results are:

Phase 1 results Phase 2 results
Relatively low effort, accepts data as they are made input (but validated)
More preparational work, also to clear up many semantic vaguenesses
No meta data possible (e.g. status, rules, reliabiltiy, etc)
Any number of meta data possible
For batch snapshot purposes only
Supports integration of life-cycle information
Difficult to change or extend the scope
Fully extendable, for example to human and process activities