Mixing data and documents

latest update: 2016-10-25    


Mapping all data presented on documents is not required for lifecycle information integration. Besides that it is a mission impossible.

This topic gives, at a conceptual level, a solution for the integration of data, that are being mapped, and documents.

Document storage

In most cases the software, that has been used for the creation of documents, will not be used throughout the life time of a facility. Then the documents are stored in, for the most, PDF format in an EDMS (Electronic Document Management System). An EDMS  provides a solution for managing the creation, capture, indexing, storage, retrieval, and disposition of records and information assets of the organization.

Essential is, in this context, that each version (revision) of each document has its own URI and a user-extendable set of meta data.


A sketch of a set-up is:


Have a look at an ISA Contol Valve specification:


Mapping all 113 data elements on this document does not really make much sense. So which ones do make sense? The listing below represents the opinion of the author only:

  • Top center block - these data are already available in the Project Fašade
  • Top righthand block - these meta data shall be mapped
  • Service Conditions - shall be mapped, although these data come predominantly from Process Engineering, and it would be better to map at the source rather than in a derived document like this one.
  • Line - already available in the Project Fašade in relation with this valve
  • Valve body/bonnet - should not be mapped, can be re-established from the Service Conditions; Besides, vendor data do in fact not belong in a specification, because specifications are made to define requirements from an engineering point of view; This type of specifications are a relic from the pre-computer days, where documents were in fact a kind of record. So, only map what is a requirement, not what is vendor data. These come in the Lifecycle Activity "Procurement".
  • All other data - See above, only map what is a requirement, not what is vendor data.

Defining which data shall be mapped is up to the plant owner/operator, and is based on business requirements.

Note that the above should be read in the context of lifecycle information integration. For system-to-system interfacing other considerations may apply.

Considering the above one may draw the conclusion that only the meta data should be mapped, and data that have been created when engineering a control valve (provided it is important enough for lifecycle information integration). An example of the latter is the required Cv value (the selected valve has a Cv that is equal or slightly higher). Again, that value may come from some calculation program and, if so, should be mapped there at the source.

Some code

Assume a control valve with tag number FCV-101, defined on specification sheet IN-V-142 rev. 1. It has a Cv = 22.5. This leads to a mapping, in the ISO 15926 Adapter of the EDMS, to an instance of template

and in the ISO 15926 Plant Archive:

Below these four templates are represented in ISO 15926-8 format, in Turtle. Note that the control valve is here considered to be an instance of ClassOfInanimatePhysicalObject, because it is the "requirements class" of which the instance of FunctionalPhysicalObject, that is represented on the P&ID, is a member. That class is tagged CO_FCV-101 (CO = ClassOf).

This code, generated in the ISO 15926 Adapter of the EDMS, has the namespace of the Plant Archive and is sent to and integrated in the latter.

:T2EB9E683FB4A42C6B38FDD31335388F4 rdf:type tpl:ReferenceToIndividualOnDocument ;

    tpl:hasReferred :CO_FCV-101 ;

    tpl:hasDocument :CE648771F0D364032A25CD9BC79894DAF ; # the GUID of IN-V-142 rev.1

    meta:valEffectiveDate "2014-06-22T00:00:00Z"^^xsd:dateTime .

:T6D9BAA7150594C53BAA0ECD1EC76C739 rdf:type tpl:DocumentRevision ;

    tpl:hasUrDocument :C9D5DECD0424E4D35BE80317CA90ADFA7 ; # the GUID of the 'Ur' version of IN-V-142

    tpl:hasRevisedDocument :CE648771F0D364032A25CD9BC79894DAF ; # the GUID of IN-V-142 rev.1

    tpl:hasActivityType rdl:RDS2229211 ; # Revising a Document

    tpl:hasActivity :TE848C095227B44D399550DBFC7137B07 ; # auto-generated

    tpl:valRevisionDate "2014-06-22T00:00:00Z"^^xsd:dateTime ;

    meta:valEffectiveDate "2014-06-22T00:00:00Z"^^xsd:dateTime .

:TAF1C0B9609804B61A1BE7699BE0C569B rdf:type tpl:DocumentPublishing ;

    tpl:hasPublishedDocument :CE648771F0D364032A25CD9BC79894DAF ; # the GUID of IN-V-142 rev.1

    tpl:hasActivityType rdl:RDS2229212; # Publishing a Document

    tpl:hasActivity :TB88C141E8E6B4CD3B08B3E06A9F4B981 ; # auto-generated

    tpl:hasPublicationStatus rdl:RDS2229161 ; # Approved for Procurement

    tpl:valPublishingDate "2014-06-22T00:00:00Z"^^xsd:dateTime ;

    meta:valEffectiveDate "2014-06-22T00:00:00Z"^^xsd:dateTime .

# and already stored in the Plant Archive:

:T7551C7B91B03405ABF1DE9A539E904F6 rdf:type tpl:ClassOfIndividualHasPropertyWithValue ;

    tpl:hasPossessorType :CO_FCV-101 ;

    tpl:hasPropertyType rdl:RDS6549840 ; # Cv-value (fake ID)

    tpl:valPropertyValue "22.5"^^xsd:decimal ;

    tpl:hasScale rdl:RDS1059740901 ; # DIMENSIONLESS SCALE

    meta:valEffectiveDate "2014-06-22T00:00:00Z"^^xsd:dateTime .