**ISO TC184/SC4/WG10 N85**

**Date: 12 November, 2023 Supersedes SC4/WG10 N71**

PRODUCT DATA REPRESENTATION AND EXCHANGE

  ---------------- ------------ ----- -------- ------------ ---------------- --------------- ------------- ---------------- --------- --------------------------- ------------- ----- -------------
  **Part:**                     n/a            **Title:**                    **Integration                                                                                            
                                                                             of Industrial                                                                                            
                                                                             Data for                                                                                                 
                                                                             Exchange,                                                                                                
                                                                             Access and                                                                                               
                                                                             Sharing                                                                                                  
                                                                             (IIDEAS)**                                                                                               

  **Purpose of                                                                                                                                                                        
  this document as                                                                                                                                                                    
  it relates to                                                                                                                                                                       
  the target                                                                                                                                                                          
  document is:**                                                                                                                                                                      

                   Primary                                                                                                  Current                                                   
                   content                                                                                                  status:                                                   

                   Issue                       x                                                                            Version                                             2.0   
                   discussion                                                                                                                                                         

                   Alternate                                                                                                                                                          
                   proposal                                                                                                                                                           

                   Partial                                                                                                                                                            
                   content                                                                                                                                                            

  **ABSTRACT:**                                                                                                                                                                       

  This paper                                                                                                                                                                          
  identifies                                                                                                                                                                          
  requirements for                                                                                                                                                                    
  integration and                                                                                                                                                                     
  sharing of                                                                                                                                                                          
  industrial data,                                                                                                                                                                    
  and discusses a                                                                                                                                                                     
  number of issues                                                                                                                                                                    
  that are key to                                                                                                                                                                     
  satisfying the                                                                                                                                                                      
  requirements.                                                                                                                                                                       

  **KEYWORDS**                                              **Document                                                                                                                
                                                            status/dates**                                                                                                            
                                                            (dd/mm/yy)                                                                                                                

                                                            **Part                                                                                                **Other SC4         
                                                            Documents**                                                                                           Documents**         

                                                                                             Working draft                                                        9/12/96             Working

                                                                                             Project draft                                                                            Released

                                                                                             Released                                                                                 Confirmed
                                                                                             draft                                                                                    

                                                                                             Technically                                                                              Released
                                                                                             complete                                                                                 

                                                                                             Editorially                                                                              
                                                                                             complete                                                                                 

                                                                                             ISO Committee                                                                            
                                                                                             Draft                                                                                    

                                                                                                                                                                                      

  **Project                                                                                                **Editor:**                Matthew West - ISCL/4                           
  leader:**                                                                                                                                                                           

  **Address:**                                                                                             **Address:**               Shell International Ltd                         

                                                                                                                                      Shell Centre                                    

                                                                                                                                      London SE1 7NA                                  

                                                                                                                                      United Kingdom                                  

  **Telephone:**                                                                                           **Telephone:**             +44 171 934 4490                                

  **Fax:**                                                                                                 **Fax:**                   +44 171 934 6649                                

  **E-mail:**                                                                                              **E-mail:**                100070.670@compuserve.com                       

  **Comments to                                                                                                                                                                       
  Reader:**                                                                                                                                                                           

  Comments and                                                                                                                                                                        
  questions on                                                                                                                                                                        
  this document                                                                                                                                                                       
  are welcomed.                                                                                                                                                                       
  Please direct                                                                                                                                                                       
  them to the                                                                                                                                                                         
  editor, or the                                                                                                                                                                      
  WG10 exploder.                                                                                                                                                                      
  ---------------- ------------ ----- -------- ------------ ---------------- --------------- ------------- ---------------- --------- --------------------------- ------------- ----- -------------

Table of Contents

***Introduction***

Problem Statement

Requirements

Discussion

Data Integration

Partial Integration

Ontologies

Formal mappings between data models

Identification

Internal Identification

External Identification

Record Identifiers

Data Consolidation

Implementation

Types of Application

Types of layer

Types of Database

Principles

Relationship to other standards

STEP

Parts Library

CDIF

IRDS

CSMF

Basic Semantic Repository

Examples of Use

Example 1: Standardising the integration of several APs

Example 2: Ensuring commonality between APs

Example 3: Interoperability between S88 and STEP

Alternative Approaches

Improve STEP

Introduce a Companion Standard to STEP

Next Steps

Annex A: An Ontologically driven data model

Introduction

EXPRESS G Diagrams

EXPRESS

Annex B: A Part 21 File.

# Introduction

This paper has been developed as part of WG10's work to review and
improve the architecture of the SC4 standards. It identifies
requirements for standards to support industry for the integration and
sharing of industrial data, within the SC4 standards, between the SC4
standards, and with other standards, and discusses key concepts relevant
to the effective and efficient satisfaction of these requirements.

This work may result in specific proposals for improvement to existing
SC4 standards and/or new standards.

# Problem Statement

The current focus of STEP is the exchange of Product Data, ensuring that
it is meaningful in a particular context to a receiving application.
However, rather than being used directly by some receiving application,
the data may be integrated with data from other sources, stored, and the
whole, or some subset of it, may then be used by an application. This is
illustrated below.

![](media/image1.emf)

Figure 1: The Problem

In addition, the data may not come from a STEP AP, but from some other
standard such as PLib, EDIF, POSC, or something SGML based. It is also
not necessarily product data, but about some other aspect of the
business. Thus it is not possible even to assume that the data model is
defined in EXPRESS.

# Requirements

To solve the above problem in a standardised way, the following
requirements need to be satisfied:

1.  There is a requirement for a data model able to hold data from
    different sources independent of the usage of the data.

2.  There is a requirement to be able to integrate product data with
    other industrial and business data.

3.  In order to have the minimum number of data models for integrating
    data from different sources, these models are required to be
    extensible and modular.

4.  There a requirement to create two way mappings between the
    application level data models and the integration level data models,
    for both the creation and exchange of data sets, and for being able
    to view and update the data directly.

5.  There is a requirement to handle data models in languages other than
    EXPRESS.

6.  There is a requirement to identify the commonality between different
    data models in a consistent and manageable manner.

7.  There is a requirement to consolidate data sets that contain data
    about the same objects. In particular this means being able to
    define when you are satisfied two records are about the same object.

# Discussion

This section discusses a number of key concepts that are relevant to
satisfying the requirements stated above.

## Data Integration

The primary requirement is to support the integration of industrial data
from different data sets, according to different data models, into a
single data set, and a single data model. The data in this model might
then need to be viewed from a perspective defined by yet another data
model.

![](media/image2.emf)

Figure 2: The ANSII/SPARC Architecture

ANSII/SPARC introduced the idea that a data model that could support the
data for a number of data models was a conceptual data model, see figure
4.1 above. This term will be used here, but to describe the relationship
between one data model and another. Thus one data model might be
conceptual relative to two or more others, i.e. it can support all of
their data requirements (but not necessarily constraints).

Whilst it is well understood how to develop a conceptual data model from
some predefined set of external models, this could give rise to a large
number of conceptual data models for the different combinations that
arise. It would be desirable to have only one, or a few conceptual data
models.

However, since all the data models that need to be integrated will not
be known at the start of the process, it is important that any
conceptual data model is extensible in the face of additional
information requirements.

![](media/image3.emf){width="4.502083333333333in"
height="2.2777777777777777in"}

Figure 3: Extending a Conceptual Data Model

This will be particularly important to be able to integrate product data
models with data models of other parts of a business. Product data is a
small, but important part of an enterprises data, and is part of the
basis for the integration of an enterprises information, as shown below.

![](media/image4.emf)

Figure 4: Enterprise Information Architecture.

Development of such an extensible conceptual data model is expected to
be a technical objective. Such data models are called here Generic Data
Models. Generic Data Models should:

-   meet the data requirement,

-   be clear and unambiguous to all (not just the authors),

-   be stable in the face of changing data requirements,

-   be flexible in the face of changing business practices,

-   be reusable by others,

-   be consistent with other generic data models covering the same
    scope, and

-   be able to integrate data from different data models.

Fortunately, principles exist which, if followed, allow these
requirements to be met. They are:

1.  *Candidate attributes should be treated as representing
    relationships to other entity types.*

2.  *Entities should have a local identifier within a database or
    exchange file. These should be artificial and managed to be unique.
    Relationships should not be used as part of the local identifier.
    (External, or global, identifiers are objects in their own right,
    see principle 1.)*

3.  *Activities, associations and event-effects should be represented by
    entity types (not relationships or attributes).*

4.  *Relationships (in the entity/relationship sense) should only be
    used to express the involvement of entity types with activities or
    associations.*

5.  *Entity types should represent, and be named after, the underlying
    nature of an object, not the role it plays in a particular context.*

6.  *Entity types should be part of a subtype/ super type hierarchy of
    generic entity types in order to define a universal context for the
    model.*

Developing data models that follow these principles has been found to
lead to data models that satisfy the above requirements.

## Partial Integration

Another form of integration is partial integration of two data models
where they overlap. Here a single data set is not achieved, but the
overlap data is mapped/viewed in both data models. This might be
appropriate when some data was only ever relevant in a particular
environment. Full integration can always be achieved at a later date.
This is equivalent to the qualified external resource approach proposed
by Guy Pierra.

## Ontologies

When you develop Generic Data Models, much of the semantic information
is taken out of the data model. If this is not to be lost then it needs
to be held somewhere else. An appropriate place to hold this information
is in an ontology.

An ontology here is taken to be a classification scheme, and the
relationships between classification schemes that represent our
knowledge about some part of the universe. Two types of ontologies are
recognised:

![](media/image5.emf){width="4.941666666666666in"
height="3.5520833333333335in"}

Figure 5: An example of a Pure Ontology.

1.  Pure ontologies, here the basis for classification is the same
    throughout the classification hierarchy. Such ontologies can be
    expected to be orthogonal. Here orthogonal means that membership of
    a class in one hierarchy is independent of membership of another
    hierarchy, and that classes at any level will be mutually exclusive.
    Figure 4.4 gives an example.

2.  Mixed ontologies, these are the combinations of classes of thing we
    are interested in for a purpose. They are generally of more
    practical use, but can easily overlap with each other. The overlaps
    can be managed through the elements that make up the mixed
    ontologies coming from pure ontologies.

![](media/image6.emf){width="3.5694444444444446in"
height="2.622916666666667in"}

Figure 6: A mixed ontology and its pure elements.

Pure ontologies tend to be concise, whereas the mixed ontologies that
can be derived from them are relatively large. This means that pure
ontologies can be a useful tool for managing the mapping between data
models. An entity type in a data model can be positioned (or not) within
each of the pure ontologies. Doing so defines very precisely the meaning
of an entity type, in a way that is consistent. Thus if the pure
ontologies are considered to be an adjunct to the generic data model,
then a consistent and extensible basis exists for integrating data from
different data models. Further, if a data model is developed that can be
driven by ontologies, then the data model no longer needs to be
extensible, only the ontologies (using the same principles). Thus
extensibility becomes a matter of managing additions to data rather than
data models.

Alternatively, the ontologies can be used to specialise the data model
to make greater detail explicit, should this be required. It is
important to understand that declaring something as a member of an
entity type is semantically identical to classifying it as being a
member of a class, where the definition of the class and the entity type
are the same. They are just different representations/presentations of
the same information.

A data model designed to be driven by ontologies and to hold any data
about any thing, is given in Annex A.

## Formal mappings between data models

Mapping involves two things:

1.  it takes the (implicit) context of an external data model, and maps
    it to/from explicit elements in the conceptual data model,

2.  it takes the explicit elements in the external data model and maps
    them to/from equivalent elements in the conceptual data model.

This gives the basis for mapping data elements according to the external
data model to and from the conceptual data model.

This process can also be adopted privately for mapping application data
structures to standardised data models.

Below is given an example of mapping two data models. The examples are
for products taken from an oil industry context.

![](media/image7.emf){width="5.331944444444445in"
height="3.667361111111111in"}

Figure 7: A mapping example.

Figure 4.6 shows two data models that need to be mapped. First let me
describe the two data models.

The top data model is one which is used in a particular context to
identify the *product* *type* which represents the primary specification
a *batch* of hydrocarbons is made to. The model is annotated with an
example which is given in partial part 21 file format (the entity type
names have been omitted because you can see them on the diagram). So
*product type* #2, Kerosene, classifies *batch* #1. However, a *batch*
can never have more than one *product type*, and must be classified by
at least one *product type* if you are to record any information about
it in this context.

The bottom data model is designed to be conceptual i.e. able to hold
*classification* data by *product type* about *batches* in any context.
The *classification* association indicates that a *batch* is classified
as being of a *product type*. *Batches* do not have to be classified,
and may be classified as many times as is desired. So, for example,
*classification* #3, classifies *batch* #1 as *product type* #2,
kerosene.

When we compare the two models we discover that *batch* means something
different in the two data models. In the top data model it means
*batches* that are classified, in the bottom data model it means any
*batch*.

For the purposes of this example, the names of entity types will be
changed to reflect the difference in semantics. However, this is not to
suggest that this is necessary to map two data models. It is only
necessary to discover and record the relationship between the two
models. The result of this is shown in figure 4.7 below.

![](media/image8.emf){width="4.427777777777778in"
height="3.015972222222222in"}

Figure 8: Recognising different semantics.

If there is a difference in the *batch* entity types, perhaps there is
also a difference in the *product types*. This is quite likely, since
the *batches* in the top model can only have one *product type* so any
others it might have are not relevant in this context. There is no
evidence just from the model to guide us, so we will assume that in the
top model it is the *primary product type* that is of interest (in real
life don't assume, ask!). This will also mean that *batches* that are
classified, but not by a *primary product type* will not be of interest.
If we incorporate this into the model then the result is shown in Figure
4.8 below.

![](media/image9.emf){width="4.384027777777778in"
height="3.029861111111111in"}

Figure 9: Recognising further semantics.

The problem now is that when I populate the top model from instances of
the bottom model, I don't know which of several classifications of a
batch is the primary one. Thus we need to add something to the bottom
data model to capture these semantics. Here we take a simple approach
and add a further *classification* association, and introduce a *class
of product type* entity type. This is illustrated in Figure 4.9 below.
(Note: other approaches are possible.)

![](media/image10.emf){width="4.551388888888889in"
height="3.3006944444444444in"}

Figure 10: Classifying product type.

Now we know which *product types* are primary, so we can pick up the
relevant *classification* associations. If we assume that the *primary
product types* are mutually exclusive, then there will only be one
*classification* that is current. However, the *primary product type*
may change over time, in this case there will be more than one
*classification* association with a *product type* that has a
*classification* association with the *class of product type* primary.
So we need to know which one is current. One way to do this is to hold
the date effectivity of the association. A simple way to do this is to
have the start and end date of the association as attributes. Of course
this also adds to the semantics of the top model, which becomes a
*currently classified batch*. This is shown in Figure 4.10 below.

![](media/image11.emf){width="4.435416666666667in"
height="3.120138888888889in"}

Figure 11: Adding information to determine the current classification.

Whether this is the end, depends on the other models to be integrated
and their context. Perhaps, for example, a different department has a
different primary classification used in a different application model.

The key point here is that for a two way mapping, at least all the
relative semantics must be discovered, and this assumes that the usage
of the model conforms to the semantics. If not the semantics of the
usage must be discovered too.

## Identification

One of the biggest problems when combining data from different data sets
is identifying which data is about the same thing, and needs to be
consolidated.

This is not a matter of \"yet another global identifier\". There are
enough of these already!

So how do we identify things in real life? Do we go around saying "Oh I
can't tell you which one this is, it doesn't have a global unique
identifier!" I think not. We habitually identify things by relationships
they have to other things around it, and its characteristics. So if
there are three chairs in the room (none of which has any identifier).
One is in the corner, the other two are in the middle of the room. One
is red, one is green, one is white. I can easily identify them by saying
"the chair in the corner of the room", or "the red chair in the room".
The key question is what constitutes sufficient relationships to other
things to be confident we have identified what we are talking about. For
example, for material objects, it is usually enough to identify where it
was at a point in time (preferably now) to identify a particular object.

However, this is not to say that identifiers are not useful, because
when a thing has an identifier, it is a very convenient and sure way to
be sure what is being identified.

There are two levels at which identification of things is important:

1.  internal, within a file or database, and

2.  external, across a number of independently managed files, databases,
    or organisations.

### Internal Identification

The purpose of an internal identifier is for the efficient and effective
management of data about something by computer systems. Within a
database or file it is important that each object represented has a
surrogate, so that information about the object can be grouped together.
In a database this might be provided by an attribute. In a STEP Part 21
file, this is provided automatically by the #Number.

Relationships should not be used as part of the internal identifier
because this makes the existence of the object dependent on the
relationship, and hence it makes existence of information about the
object dependent on knowledge of information about the object it is
related to. Even where there is real world dependence, it is unusual for
it to translate into data dependence, e.g. because I must have two
parents does not mean that you must know who my parents are to know me.

### External Identification

The purpose of external identification is so that computer systems,
people, and organisations can know what information is about in a
broader context than the local computer system or organisation. This is
particularly important for the integration of data from different
systems. Take for example the unit of measure kg. If one system calls it
\"kg\", and another \"kilograms\", then they will not be able to
exchange data. A weight of 30 kg in the first system would be
meaningless to the second system.

The first thing to understand about external identifiers is that there
can be many of them. For example, I have an employee number, a driving
license no, a National Insurance number, a National Health Number etc.
The next thing is to understand that each of these identifiers is issued
by an authority, which optionally manages them so that an identifier is
only issued for one person, and that a person only has one identifier
(at a time). Peoples names would be an example where identifiers are not
managed to be unique. Passport numbers would be an example where they
were managed to be unique.

The consequence of this is that external identification is best dealt
with as part of the overall data model, since the identifier itself has
relationships to, for example, the issuing authority and the
identification scheme used. An outline data model for external
identifiers is given below.

![](media/image12.emf)

Figure 12: Outline identification scheme.

### Record Identifiers

We sometimes forget that records are things too, which we may wish to
manage, or authorise for a particular use. Some DBMS\'s give each record
a record identifier, which is not seen by the user. This identifies a
particular record (within the DBMS instance) and is not a surrogate for
the object itself. Both are needed for proper management of data. In
part 21 files, the object identifier doubles as a record identifier.
This is because the membership of an object to any entity types it is a
member of is constrained to be in one record.

## Data Consolidation

Having developed the conceptual data model, and the mappings from (say)
two external data models to the conceptual data model, it is now
possible to migrate target data sets from the external models to the
conceptual data model. The meaning of the data set 1 and 1' is the same,
but it is being said using a different data model. I can do the same
with data set 2.

![](media/image13.emf){width="4.509722222222222in"
height="1.8923611111111112in"}

Figure 13: Getting two overlapping data sets into the same data model.

However, just because the two data sets are data sets according to the
same data model, does not mean that the data is integrated. It is
necessary to go through a process of consolidation. In this step it is
necessary to identify what data is about the same thing. External
identifiers, and other relationships that can be used for identification
will be helpful in this. However, it is possible that situations will
arise when it is uncertain whether two pieces of data are about the same
thing or not, because insufficient care has been taken. In this case
human intervention is necessary. The result is shown below.

![](media/image14.emf){width="4.865972222222222in"
height="2.696527777777778in"}

Figure 14: Consolidation.

It should be noted, that in this process, the same object will probably
have had different local object identifiers in the different data sets,
and that the consolidation process is largely about ensuring that each
object has only one internal identifier.

## Implementation

The implementation requirements for IIDEAS are for a data access
interface, and for an exchange file format. Whilst this can (and should)
build on the work done in STEP, the requirements are more demanding.

The data access interface will need to support multi-user,
multi-application access. In addition this may be accessed through one
data model to data held in another. Data integration services will also
need to be provided, as well as the usual access control services. This
outline architecture is shown in Figure 4.14 below.

![](media/image15.emf)

Figure 15: Outline Architecture to support IIDEAS.

The file exchange format may need to be more of a batch command
interface, so that operations as well as data can be exchanged in a
file. Source and destination information may also be necessary.

There is much existing work that may contribute to meeting these
requirements, including CORBA and SQL3.

However, the main area of interest is the Data and Applications
Architecture. This is illustrated below in Figure 4.15.

![](media/image16.emf){width="5.820833333333334in"
height="4.424305555555556in"}

Figure 16: Data and Applications Architecture.

### Types of Application

Three types of application are recognised here:

1.  **Legacy applications**. These are applications that have their own
    internal data structures developed to satisfy the requirements of
    the application without regard for data sharing. A legacy
    application can be fitted with a wrapper layer that redirects calls
    to its database.

2.  **Object based applications**. These are applications that have been
    designed to be able to share data, and perhaps behaviour between
    applications within a domain through a domain model, e.g. design,
    maintenance. However, the same object might be viewed from more than
    one domain model, with different behaviour or attributes.

3.  **Generic applications.** These are applications that are designed
    to work directly off a generic data model. Experience has shown that
    applications designed to work off a generic data model directly have
    better performance characteristics than traditional legacy or object
    based applications working off integrated data through a view or
    mapping. However, generic applications require a very different
    approach to application development.

### Types of layer

There are four layers of different types of model, each of which will
have an API and offer services. These are:

1.  **Business Object Layer.** This layer presents to the user or user
    application the view of the world they wish to see, however specific
    or generic that may be. Behaviour may be included.

2.  **Data Integration Layer.** This layer contains a data model
    designed to be able to integrate data from different sources, and
    services to integrate data from different sources. In principle,
    there is more than one data model that could be used as the data
    integration model. However, data will only be truly integrated if it
    is contained in a single data model.

3.  **Data Storage Layer.** This layer provides a physical storage
    model. Experimental work has shown that it is possible to develop
    storage models that are independent of the data model that data is
    being stored against. This means that data and data models can be
    added without having to change the implemented data structures.

4.  **Meta Data Layer.** This layer provides data models and services
    for managing the meta data. That is the data about data models,
    mappings, data model languages, mapping languages etc. and the
    services to support them.

### Types of Database

Three types of database are shown:

1.  **Specific databases** that directly implement the requirements of
    an application. Performance is good, but flexibility is poor.

2.  **Generic based databases** that can store a wide range of data with
    good flexibility. Performance is sometimes poor when data has to be
    transformed into another format, but applications designed to work
    with a generic database perform well.

3.  **Flexible databases**. These can hold the same data according to
    different data models to give the best of both the above types of
    database with the minimum of penalties.

You will notice that the data and applications architecture shown here
(taken from the PIPPIN project) bears a striking, but unsurprising
resemblance to the ANSI/SPARC architecture, where the Business Object
Layer is equivalent to the external schema layer, the data integration
layer is equivalent to the conceptual schema layer, and the data storage
layer is equivalent to the physical storage schema layer. The difference
is, that the layers here contain not only the schema, but also the
services required to support calls to the layer through an API. Some of
the services identified include:

-   data migration,

-   data merge and consolidation,

-   import/export,

-   context and view management,

-   version control,

-   work flow,

-   constraint management,

-   derivation and parametric services,

-   simulation services,

-   measurement data capture,

-   transaction services,

-   text based browsers and editors, e.g. hierarchy, form, report,

-   Graphical browsers and editors, e.g. 2D, schematic, 3D

-   meta data management tools for mappings and models etc.

# Principles

1.  The primary principle of the structure of this proposal is not to
    assume we know all the answers, but enable the standard to progress
    gracefully.

2.  Management of data independent of application, rather than exchange
    of data between applications.

3.  Data about a product needs to be managed and maintained throughout
    the life of the product.

# Relationship to other standards

## STEP

IIDEAS differs from STEP in having a broader scope than Product Data,
and having an emphasis on sharing and integration, rather than exchange
in the STEP sense. STEP is a potential source of data models that might
require data from them integrating, and that might want to use
ontologies standardised in IIDEAS.

IIDEAS would use much of what STEP has developed, including at least
EXPRESS as a way of defining data models, and the proposed EXPRESS-X for
defining mappings between data models.

## Parts Library

Like STEP, Parts Library has a limited scope and intent. Thus IIDEAS
would be able to support the data requirements of a Parts Library, and
an IIDEAS implementation might choose to provide a Parts Library
conformant implementation.

## CDIF

CDIF provides a meta model for the exchange of meta data. This could be
used, together with the EXPRESS meta-model as a basis for the data
dictionary for this standard, although account would need to be taken of
the need for history, configuration control, and version control. This
standard treats meta data in the same way as other industrial data.

## IRDS

This standard might identify some of the services required by an
implementation.

## CSMF

Theoretical but useful stuff to reference or build on.

## Basic Semantic Repository

This seems to have some ideas similar to those presented here for
ontologies. It would need investigating to see how it could contribute.

# Examples of Use

Examples of the use of IIDEAS are given from the process industry. They
are currently being pursued in industry.

## Example 1: Standardising the integration of several APs

The design of a process plant involves a number of disciplines, and the
hand over of the complete design data for a plant would involve the use
of a number of APs. In particular: 221, 227, 231, 212, 225, 230.
However, a plant owner does not want a number of separate files of data,
which would have significant overlap in data content. What is desired is
a single integrated database to act as a reference database to support
operations and maintenance activities and data.

Using IIDEAS, a conceptual data model and set of ontologies can be
developed from the APs involved. The APs can then be explicitly mapped
to the conceptual model and ontologies. This then enables the batch
implementation form to integrate the data into a single database. This
can be accessed by operations and maintenance applications by the data
access interface to provide the necessary reference data. The operations
and maintenance applications could also store their data through the
data access interface, using a suitable data model for their needs,
integrated with the model for plant design.

## Example 2: Ensuring commonality between APs

AP221 has developed a set of standard classes of equipment (about 2000
of them) that are commonly used in the process industry. AP227 wishes to
use them in their AP as a way of achieving both utility and commonality.
Rather than make a reference from one AP to another it is preferred to
standardise the standard classes (an ontology) externally, and make
reference to it from both APs, so that the content of the ontology can
be managed independent of the data models that use it. IIDEAS provides a
place to do this.

## Example 3: Interoperability between S88 and STEP

S88 is a standard for the control of batch processes. It includes data
models to support the information requirements of batch control which
are already implemented. They would like S88 to be able to
share/exchange data with STEP, in particular AP221 and AP231. In order
to achieve this they wish to perform a mapping from their model (using
OMT) to the STEP APs so that (parts of) their model can be a
standardised view on the relevant STEP APs.

# Alternative Approaches

In looking at how to satisfy the requirements identified above, there
are basically two approaches that can be taken. The first is to change
and improve what we have in STEP to satisfy the needs for data
integration and sharing across an enterprises and between enterprises.
The second is to establish a companion standard to STEP that provides
the same capability. However, whichever approach is taken, there is
considerable development outlined above which will need to be
undertaken. Only the key differences are outlined below.

## Improve STEP

The STEP Generic and Integrated Resources would need considerable
change. These changes would need to:

-   move from a product data focus to an enterprise data focus,

-   move from a data exchange focus, to a data exchange and sharing
    focus,

-   move from being part conceptual model and part a set of templates,
    to a fully instantiable conceptual model,

-   move from identifying the context, to the context being the role
    some things play relative to others.

A separate paper is being prepared by Julian Fowler to identify the
extent of the changes necessary.

The advantage of taking this approach is that all the work is carried
forward. The disadvantage is that considerable change, and hence cost,
would be required by those who had already implemented STEP. On the
other hand considerable change seems to be necessary at present anyway.

## Introduce a Companion Standard to STEP

This route involves introducing a companion standard to STEP that deals
specifically with data sharing and data integration, including
integrating STEP with other standards.

The advantage here is not being constrained by what has gone before, and
equally not requiring change to what has gone before. The disadvantage
is that if it is not STEP, then STEP will have to be accommodated too.

# Next Steps

1.  Identify projects that want to establish a data sharing and data
    integration standard.

2.  Initiate a New Work Item to provide a focus for work on satisfying
    requirements for data integration and data sharing as a project
    under WG10.

3.  Establish which strategy is best for achieving data integration and
    data sharing, extending STEP or developing a companion standard.

4.  Develop, and standardise where appropriate, a methodology and
    architecture for data integration and data sharing standards.

# Annex A: An Ontologically driven data model

## Introduction

The data model given below is based on work done by EPISTLE (European
Process Industries STEP Technical Liaison Executive). It aims to provide
the minimum number of entity types to enable any information to be held
as data. In order to achieve this, the data model is designed to be
driven by ontologies that define the specific semantics of the
information held. The semantics of the ontologies used are then an
integral part of the overall definition of the meaning of the data.

This annex contains:

-   a data model documented as a number of EXPRESS-G diagrams, with

-   a text description of the diagrams,

-   a formal EXPRESS model together with definitions of the entity
    types,

-   an example Part 21 file.

## EXPRESS G Diagrams

Below are the EXPRESS-G diagrams of the data model, together with
descriptive text. Formal definitions are given in a later section
together with the EXPRESS specification.

![](media/image17.emf){width="3.265277777777778in" height="2.375in"}

Figure 17: Things, Activities, and Associations.

Everything is a *thing*, whether it is real or imagined, an activity or
a physical object. In particular some *things* are *activities* or
*associations* (but not both). An *activity* is something happening,
such as the transfer of an object from one place to another.

On the other hand an *association* is something passive, and is what
something has to do with another (including possibly itself). An
*association* will have been brought about as the result of an
*activity*. For example, ownership is an *association* between an object
and its owner. The usual way in which an ownership *association* comes
about, is as the result of a sale *activity*. When the object is again
sold, then the ownership *association* is terminated.

One particular type of *association* is an *involvement*. An
*involvement* is what something has to do with an *activity* or
*association*, as indicated above by the *happening* select type.

![](media/image18.emf){width="3.4027777777777777in"
height="2.7916666666666665in"}

Figure 18: Cause and Effect.

An *event-effect* is a change in state of existence of some *thing*. It
can either be a *begin effect*, or an *end effect*. A *begin effect*
indicates that some *thing* has had the change of state of coming from
not existing, to existing. An *end effect* is when some *thing* has
changed its state from existing, to not existing. For reasons I don't
fully understand, all other changes of state result from the *begin
effect* or *end effect* of some other object.

An event effect will be caused by an activity. However, the activity may
not be known about, or you may not care about it. For example, you know
that I have been born, and so the event effect that states I have come
into existence can be recorded, but that does not mean you know, or care
about, details of my birth.

On the other hand, the cause may be indirect. Here, one event effect
causes another, but eventually an activity is involved. So if I die
before my wife, the event effect of my ceasing to exist can be recorded,
and this in turn causes my marriage to my wife to terminate. It will
often be the case that when an object ceases to exist, so will many of
its associations.

![](media/image19.emf)

Figure 19: Some basic associations.

There are a small number of subtypes of thing, beyond the basics above,
which are necessary to describe the things of interest to us. These are
shown in Figure A.3.

A *class* has a basis for inclusion and exclusion, and *classification*
is an *association* that indicates that some thing is a member of a
*class*. It should be noted that here *class* is neither used to be the
extension of the membership of the *class*, nor as a template for
members of a *class*.

*Class* and *classification* is one of the basic ways in which we refer
to *things*, and manage the world around us. With *class* and
*classification* we can divide the world into lumps that we can deal
with together, and that behave in similar ways. Through *classification*
hierarchies, and *associations* between them, we can build up ontologies
of our general knowledge of the world around us. These can be held as
data, or made explicit through subtype trees from the entity types
already defined.

A *characteristic* is something observable, however, it is not the
result of an observation. *Characteristics* include properties, states,
time, and space. Examples are the thickness of paint on a particular
pipe, that a particular pipe is painted. Note that a *characteristic* is
not the result of the measurement of a *characteristic*, with a unit of
measure, but what it was that was measured. A *possession* *association*
indicates that a *thing* possesses a *characteristic*.

*Information* *content* is the meaning that can be derived from a
pattern or the arrangement of something physical. It is what we use to
describe *things* with. A *description* *association* indicates that a
*thing* is described by an *information* *content*.

Note that everything here is a subtype of *thing*, as a result, for
example, a *class* can be classified, a *characteristic* can possess
*characteristics*, and an *information* *content* can be described.

![](media/image20.emf){width="3.5631944444444446in"
height="3.2506944444444446in"}

Figure 20: The basics of holding data.

This bit of data model provides the structures to actually hold data.
You will have noted that so far there has only been one data type. Here
are all of the ones EXPRESS supports for use in a data model, so here as
different subtypes of *information* *content* we have the means to hold
information, rather than just relate it, which is what the rest of the
model does.

Note that not all *information* *contents* are one of these subtypes.
*Information* *content* is not abstract.

## EXPRESS

![](media/image21.emf)

Figure 21: EXPRESS-G used to generate the EXPRESS.

The EXPRESS below was generated using FirstSTEP XG/21 from the EXPRESS-G
model above. It has not been compiled.

## **cause**

A select indicating the cause of an event-effect.

### EXPRESS specification:

\*)

TYPE cause = SELECT

(event-effect,

activity);

END_TYPE;

(\*

## **happening**

A select of an activity or association, these being that which things
can be involved in.

EXPRESS specification:

\*)

TYPE happening = SELECT

(activity,

association);

END_TYPE;

(\*

## **activity**

Something happening.

NOTE 1 - The distinction between an activity and an association is that
an association is passive, where as an activity is active. Thus, storage
is a passive association between something and what it is stored in,
whilst a transfer is an activity because something is being moved from
one place to another.

### EXPRESS specification:

\*)

ENTITY activity

SUBTYPE OF (thing);

END_ENTITY;

(\*

## **association**

What one thing has to do with another.

### EXPRESS specification:

\*)

ENTITY association

SUPERTYPE OF (ONEOF(involvement,classification,description,possession))

SUBTYPE OF (thing);

END_ENTITY;

(\*

## **begin_effect**

Indicates that something has come into existence.

### EXPRESS specification:

\*)

ENTITY begin_effect

SUBTYPE OF (event-effect);

END_ENTITY;

(\*

## **binary_value**

An information content that is a binary value.

### EXPRESS specification:

\*)

ENTITY binary_value

SUBTYPE OF (information_content);

value : BINARY;

END_ENTITY;

(\*

### Attribute definitions:

value: The attribute of BINARY datatype that contains the binary value.

## **boolean_value**

An information content that is a boolean value.

### EXPRESS specification:

\*)

ENTITY boolean_value

SUBTYPE OF (information_content);

value : BOOLEAN;

END_ENTITY;

(\*

#### Attribute definitions:

value: The attribute of BOOLEAN datatype that contains the boolean
value.

## **characteristic**

Something observable that may be used as a basis to describe something.
This includes properties, time, space, and states.

NOTE 1 - The distinction between a class and a characteristic is that a
characteristic has a point value, whilst a class has a characteristic
range within which a characteristic of an object must fall in order to
be considered a member of the class.

A characteristic is the property something possesses, rather than a
description of a property. I.e. it is the degree of hotness in this
room, rather than "20 DegC".

### EXPRESS specification:

\*)

ENTITY characteristic

SUBTYPE OF (thing);

END_ENTITY;

(\*

## **class**

A thing that is a type of thing. A Class has an actual or implied basis
for inclusion or exclusion from the class. The class is not the
extension of the membership, and is not a template for making instances
of the class.

### EXPRESS specification:

\*)

ENTITY class

SUBTYPE OF (thing);

END_ENTITY;

(\*

## **classification**

An association that indicates that a thing is classified as being a
member of a class.

### EXPRESS specification:

\*)

ENTITY classification

SUBTYPE OF (association);

classifiable : thing;

classifier : class;

END_ENTITY;

(\*

### Attribute definitions:

classifiable: A pointer to the thing being classified.

classifier: A pointer to the class for the classification.

## **description**

An association that indicates a thing is described by an information
content.

### EXPRESS specification:

\*)

ENTITY description

SUBTYPE OF (association);

descriptor : information_content;

described : thing;

END_ENTITY;

(\*

### Attribute definitions:

descriptor: A pointer to the information content that is the descriptor
in the description association.

described: A pointer to the thing that is described through the
description association.

## **end_effect**

Indicates that something has ceased to exist.

### EXPRESS specification:

\*)

ENTITY end_effect

SUBTYPE OF (event-effect);

END_ENTITY;

(\*

## **event-effect**

A change in state of existence.

### EXPRESS specification:

\*)

ENTITY event-effect

SUPERTYPE OF (ONEOF(begin_effect,end_effect))

SUBTYPE OF (thing);

affected : thing;

cause : OPTIONAL cause;

END_ENTITY;

(\*

### Attribute definitions:

affected: Points to the thing that is affected by the event-effect.

cause: Points to the activity or other event-effect that is the cause of
the event-effect.

## **information_content**

A type of thing that is the meaning that can be derived from the
arrangement or properties of material (e.g. ink on paper, bits in
computer memory, etc.)

### EXPRESS specification:

\*)

ENTITY information_content

SUPERTYPE OF (ONEOF(binary_value,logical_value,boolean_value,
real_value,integer_value,number_value,text))

SUBTYPE OF (thing);

END_ENTITY;

(\*

## **integer_value**

An information content that is an integer number.

### EXPRESS specification:

\*)

ENTITY integer_value

SUBTYPE OF (information_content);

value : INTEGER;

END_ENTITY;

(\*

### Attribute definitions:

value: The attribute of INTEGER datatype that contains the integer.

## **involvement**

A type of association that indicates the role played by a thing in an
association or activity.

### EXPRESS specification:

\*)

ENTITY involvement

SUBTYPE OF (association);

happening : happening;

involved : thing;

END_ENTITY;

(\*

### Attribute definitions:

happening: A pointer to the activity or association that has the
involvement.

involved: A pointer to the thing that has the involvement with an
activity or association.

## **logical_value**

An information content that is a logical value

### EXPRESS specification:

\*)

ENTITY logical_value

SUBTYPE OF (information_content);

value : LOGICAL;

END_ENTITY;

(\*

### Attribute definitions:

value: The attribute of LOGICAL datatype that contains the logical
value.

## **number_value**

An information content that is numeric, either integer or real.

### EXPRESS specification:

\*)

ENTITY number_value

SUBTYPE OF (information_content);

value : NUMBER;

END_ENTITY;

(\*

### Attribute definitions:

value: The attribute of NUMBER datatype that contains the number.

## **possession**

An association that indicates a thing possesses a characteristic.

### EXPRESS specification:

\*)

ENTITY possession

SUBTYPE OF (association);

possessor : thing;

possessed : characteristic;

END_ENTITY;

(\*

### Attribute definitions:

possessor: A pointer to the thing that is the possessor in the
possession association.

possessed: A pointer to the characteristic that is possessed in the
possession association.

## **real_value**

An information content that is a real value.

### EXPRESS specification:

\*)

ENTITY real_value

SUBTYPE OF (information_content);

value : REAL;

END_ENTITY;

(\*

### Attribute definitions:

value: The attribute of REAL datatype that contains the real number.

## **text**

An information content that consists of a string of characters.

### EXPRESS specification:

\*)

ENTITY text

SUBTYPE OF (information_content);

value : STRING;

END_ENTITY;

(\*

### Attribute definitions:

value: The attribute of STRING datatype that contains the text.

## **thing**

Anything that exists, real or imagined.

### EXPRESS specification:

\*)

ENTITY thing

SUPERTYPE OF
(ONEOF(activity,association,event-effect,class,characteristic,information_content));

END_ENTITY;

(\*

# Annex B: A Part 21 File.

This Annex is a part 21 file for the example used to illustrate mapping,
using the model in Annex A.

HEADER;

FILE_DESCRIPTION(,);

FILE_NAME(,,,,,,);

FILE_SCHEMA();

ENDSEC;

DATA;

#1 =text(\'batch\');

#2 =text(\'Product Type\');

#4 =text(\'Kerosene\');

#5 =text(\'Primary\');

#6 =thing();

#7 =class();

#8 =class();

#9 =class();

#10 =class();

#11 =description(#1,#7);

#12 =description(#2,#8);

#13 =description(#4,#9);

#14 =description(#5,#10);

#15 =classification(#6,#7);

#16 =classification(#6,#9);

#17 =classification(#9,#10);

#18 =begin_effect(#15,\$);

#19 =begin_effect(#16,\$);

#20 =begin_effect(#17,\$);

#21 =begin_effect(#11,\$);

#22 =begin_effect(#12,\$);

#23 =begin_effect(#13,\$);

#24 =begin_effect(#14,\$);

#25 =begin_effect(#7,\$);

#26 =begin_effect(#8,\$);

#27 =begin_effect(#9,\$);

#28 =begin_effect(#10,\$);

#29 =begin_effect(#1,\$);

#30 =begin_effect(#1,\$);

#31 =begin_effect(#2,\$);

#32 =begin_effect(#4,\$);

#33 =begin_effect(#5,\$);

#34 =begin_effect(#6,\$);

ENDSEC;