Introduction
In this topic the difference
between data and information is being discussed, their relationship and
the way they are handled in ISO 15926-7/8.
Discussion
This can be found in Wikipedia:
Data is any sequence of one or more symbols.
Datum is a single symbol of data.
Data requires
interpretation to become information.
Keys in data
provide the context
for values. Regardless of the structure of data, there is always a key
component present. Data keys in data and data-structures are essential
for giving meaning to data values. Without a key that is directly or
indirectly associated with a value, or collection of values in a
structure, the values become meaningless and cease to be data. That is
to say, there has to be at least a key component linked to a value
component in order for it to be considered data. |
This is one definition amidst many, but it catches the essence for this
topic, in which only structured data will be dealt with (unstructured
data, such as in some textual document, can be converted to structured
data, with some limitations).
(Parts of) sets
of data may be required by different parties in different combinations
('views').
So far this is common knowledge, for which you don't need ISO 15926,
but
you can use your relational data base and SQL.
ISO 15926
In ISO 15926-7/8 information
is represented by creating a "template" that combines the required data
for that representation. The semantics of a template are defined using
ISO 15926 Part 2 entity types.
The scope of ISO 15926 is multi-layered:
- internationally
applicable
- integration of all
facility information (no 'silos')
- integration of facility
life-cycle information, so 'cradle to grave'
thus fulfilling the following requirements:
- applications require
input data from other applications and provide input for other
applications, so a neutral format is required
- those input data may come from other domains of expertise, so 'silos' shall be avoided
- these data shall be placed in a context in order to become information, thus integration of information is required
- when this context is also historical by nature it provides the raw material for knowledge gathering (multifaceted 'big data')
This has shaped ISO 15926
Parts 7&8 as follows:
Internationally applicable
This excludes any commercial
system, since no such system will ever dominate the entire global IT
world.
Having said that, ISO 15926 is not meant to be used for transactional
systems. It is meant to serve as a neutral integration information
integration platform in the background.
So it is complementary and enables data sharing between all
applications and systems that are used during the entire life cycle of
a facility.
Integration of
all facility information
All
information representations in ISO 15926 are derived from one and the
same Upper Ontology, a generic data model as defined in ISO
15926-2. That provides the definitions of the fundamental concepts
and their fundamental relationships.
The next extension of that Upper Ontology can be found in a Reference
Data Library, that defines concepts in the real world of the industry
using ISO 15926. For the process industries that RDL can be found here, where the
contents of this RDL are in the process of being subjected to ISO
ballots in order to formalize this as the next version of ISO 15926-4.
For the
International Standard ISO
15926, that has its focus on global interoperability, it is of crucial
importance that the data components, that together define information,
are themselves defined as information to a level that is
well-understood on a global scale, ultimately in the form of a natural
language. As
a consequence all information is defined by those globally accessible
and
understandable reference things and/or one or more literals.
Integration of life-cycle information
This
layer sets ISO 15926-7/8 apart from the rest, because each of its
'templates' is a self-contained representation of some
elementary information with full reference to declared objects and
concepts in the RDL or company extensions thereof. For example: "Pump
P-101 has a capacity of 37.9 m3/h" is represented as:
# declaration of P-101
:f949a224-a9bb-4d4f-8abe-548b0d6071d5
rdf:type lci:InanimatePhysicalObject, lci:NonActualIndividual,
rdl:RDS327239 ; # PUMP
rdfs:label "P-101" ;
meta:valEffectiveDate "2012-07-15T13:24:00Z"^^xsd:dateTime .
:296f4c41-47f9-4120-a3d1-b0cbf661ecf7 rdf:type
tpl:IndividualHasPropertyWithValue ;
tpl:hasPropertyPossessor
:f949a224-a9bb-4d4f-8abe-548b0d6071d5 ; # the UUID of pump P-101
tpl:hasPropertyType rdl:RDS7354248
; # CAPACITY (volume flow rate)
tpl:valPropertyValue "37.9"^^xsd:decimal ;
tpl:hasScale rdl:RDS1321064
; # m3/h
meta:valEffectiveDate
"2013-11-23T14:47:00Z"^^xsd:dateTime .
Each template instance can have as many meta data as required, and one
of those is mandatory: valEffectiveDate, the dateTime at which the
information, represented by the template instance, has become
effective/valid.
This effectiveDate plays a crucial role in the storage and retrieval of
that life-cycle information.
Assume that another impeller is installed in P-101, resulting in a new
capacity of 46.2 m3/h.
This is recorded as:
:b84d262f-e5b1-4a72-aa48-78456198f31c
rdf:type tpl:IndividualHasPropertyWithValue ;
tpl:hasPropertyPossessor
:f949a224-a9bb-4d4f-8abe-548b0d6071d5 ; # the UUID of pump P-101
tpl:hasPropertyType rdl:RDS7354248
; # CAPACITY (volume flow rate)
tpl:valPropertyValue "46.2"^^xsd:decimal ;
tpl:hasScale rdl:RDS1321064
; # m3/h
meta:valEffectiveDate
"2020-08-23T09:33:00Z"^^xsd:dateTime .
When we want to know what the capacity of P-101 was at
2018-05-22T00:00:00Z, the
query looks for the latest dateTime before that date and finds 37.9.
All
information stays on record and kind of "sediments", like clay in a
river or
snow at the Antarctic. We always can find the information valid at
any point in the past, keeping in mind that the present is one
nanosecond after the past.
NOTE - a dateTime in the future, for example a planned date, can also
be represented in ISO 15926, see here.
What about relational
data bases?
A recent
study, conducted by a large EPC contractor, revealed that the above is
practically impossible to achieve with a relational data base, simply
because the number of tables required would be totally unmanageable.
One approach could be to convert the table rows, with a 'permalink' to
RDF, as shown here,
and add an effectiveDate to each row
instance. That dateTime then applies to all data in that row instance.
In order to recreate the history such row instances could be saved,
each with its effectiveDate, as a kind of time slice. But
it goes without say that that is inferior to the ISO 15926 approach and
is only usable in a local setting or a 'tribal' setting like CFIHOS.
|