ERDL working format

Foreword

Following an extensive e-mail discussion, consensus on the approach to the definition of a working format for development and publication of the EPISTLE Reference Data Library (ERDL) has been reached.

Following this consensus, a standard view table has been defined for:

• ERDL identification and description; and
• meta-data which includes source and approval status.

There are two natural extensions to this document, which have not yet been completed:

• a mapping of the standard view table to ECMv4 (EPISTLE Core Model version 4); and
• a definition of the standard view table as an XML DTD.

Acknowledgements

Contributions to this document have been received from Ian Glendinning, Roel Murris, Chris Angus, Andries van Renssen, Hans Teijgeler, Matthew West and Onno Paap.

Document log

Table of Contents

• 1. Introduction
  • 1.1. Background
  • 1.2. Objectives
  • 1.3. Summary of approach
• 2. Publication architecture
  • 2.1. Database and views
  • 2.2. ACCESS or EXCEL download
• 3. Standard view table
  • 3.1. 'One table one row per object' approach
  • 3.2. Engineering dictionary and reference library
  • 3.3. Multiple data items for an object
  • 3.4. Standard view table columns
• A. Single table database schema
• B. Some useful subviews

1. Introduction

1.1 Background

Collaborative work on the ERDL requires one or more publication formats, which:

• can be downloaded and accessed using widely available software;
• are convenient to use for ERDL browsing and updating;
• have clearly defined semantics;
• encompass all necessary data, including meta-data such as source and approval status; and
• are accepted by all EPISTLE participants.

The obvious way to meet these criteria is to relate the publication formats directly to ECMv4.

NOTE - ECMv4 contains a useful set of generic concepts which have been agreed by the participating organisations in EPISTLE. If any other set of generic concepts were adopted as the basis for ERDL publication, this would be equivalent to reopening discussion on ECMv4.

Possible publication formats, which can be related to ECMv4, are:

ACCESS:

This is a useful format because it is based upon widely available software;

STEP part 21:

This is an important format because it is a standard, but does not have such broad software support.

EXCEL:

This is very simple and convenient for browsing and editing. However, the format is less sophisticated than ACCESS, and may be cumbersome when full source and approval meta-data is added.

XML:

This is very important for the long term, but at present no DTD corresponding to ECMv4 has been published.

At the PISTEP meeting on 2001-05-01, it was suggested that ACCESS was one of the most useful publication formats.

1.2 Objectives

The objectives of this document are as follows:

• to define the criteria that shall be supported by an ERDL development and publication application;

  The document will be used to solicit one or more development and publication applications from projects and commercial organisations.

  NOTE 1 - Compliance with the criteria set out in this document may be achieved by minor extensions to existing ERDL publication applications.

  NOTE 2 - There may be many ERDL development and publication applications. The criteria defined in this document will ensure that such applications can work together.

• to provide a formal definition of the ERDL meta-data, such as source and approval.

  NOTE 3 - The ERDL meta-data can be defined as a specified population of ECMv4.

1.3 Summary of approach

The approach to ERDL publication is summarised as follows:

1. An implementation shall enable a standard view table to be downloaded for browsing and updating.

2. A standard view table shall specify the necessary minimum of identification, description, source and approval data for the ERDL content.

3. An implementation shall support downloading in ACCESS or EXCEL format (because these software packages are widely available, although the definition of the standard view table itself will be independent of format)

4. The precise semantics of a standard view table will be defined by a mapping to ECMv4 (because there is no other choice).

   NOTE - This shall not prevent entry of library content that has no agreed mapping to ECMv4. If such content is required, then this is an issue against ECMv4. Any extensions to ECMv4 shall be made using the ERDL itself as far as possible.

5. The mapping to ECMv4 will be defined informally using English and a worked example (because there is no other choice).

6. Exchange of information between different ERDL implementations shall be carried out using either standard view tables or ECMv4 and STEP part 21 (if we can't use ECMv4 for this, then what can we us it for?).

2. Publication architecture

2.1 Database and views

ECMv4 is not a convenient format for browsing or editing. Hence views will be required to support these activities. An outline of a possible network of formats is shown in Figure 1.

Figure 1: ERDL formats

2.2 ACCESS or EXCEL download

It shall be possible to download a standard view table from an ERDL application. The format of a standard view table is defined independently of any software in section 3 below.

It shall be possible to download a table in ACCESS or EXCEL format.

NOTE 1 - These formats are convenient for browsing and editing. The software to handle them is widely available.

The internal database format used by an ERDL application is not specified.

NOTE 2 - An internal database format with a defined mapping to ECMv4 is recommended.

NOTE 3 - Chris Angus has proposed a single table schema suitable as an internal database format, which is described in annex A. This single table schema is flexible and can support ECMv4.

3 Standard view table

3.1 'One table, one row per object' approach

The standard view format for the ERDL consists of one table, with one row per object. This table is not normalised and has many columns.

NOTE - The structure of this table is similar to, but not identical to, that used for the STEPLIB library.

Different ERDL browsing and editing activities require different subsets of the columns, or 'subviews', as shown in Figure 2.

Figure 2: Extract subviews from a single table

A set of useful subviews is suggested in annex B. These are not standardised in any way.

3.2 Engineering dictionary and reference library

The ERDL has two levels:

engineering dictionary:

This is a set of engineering concepts, which are informally defined. The definitions may be understood only in a particular 'context', such as an engineering discipline, country, or company.

reference library:

This is a set of concepts that have a single precise definition, which is independent of context.

Both engineering dictionary and reference library objects have audit trail information, such as source and approval.

A reference library object may have one or more corresponding engineering dictionary objects.

NOTE 1 - Most 'concepts' or 'objects' in the engineering dictionary and in the reference data library are classes. 'Correspondence' between a dictionary class and a library class means that they have the same members. They have merely been identified and described differently in the two places.

NOTE 2 - The relationship between the engineering dictionary and the reference library is similar to that between the ARM (Application Reference Model) and the AIM (Application Interpreted Model) in a STEP AP.

NOTE 3 - A reference library object can be defined even if there are no corresponding engineering dictionary objects.

In the standard view table, a row may correspond to either an engineering dictionary object or a class library object.

3.3 Multiple data items for an object

Not all data fits easily into a one table, one row per object approach.

NOTE - This is why we have a flexible EXPRESS schema for the ECM, rather than a hierarchical document format.

There must be multiple columns to support:

• many dictionary objects corresponding to one reference data library object;
• names and definitions in multiple languages;
• multiple classifications;
• multiple supertypes and property range criteria for a class; and
• the specifications of valid property classes for a class.

These multiple columns shall be created explicitly, giving column headings such as 'dictionary object name 1', 'dictionary object name 2', etc..

If a column contains a name or description in a language other than English, then the language shall be indicated as follows:

'Français: pompe'
'Cymraeg: pwmp'

3.4 Standard view table columns

The standard view table columns are defined in Figure 3.

Figure 3: Standard view table columns

NOTES:

1. Column 'D' indicates the columns that may be instantiated for an engineering dictionary object. Column 'L' indicates the columns that may be instantiated for a reference library object.

2. Column 'repeat' indicates the columns that can be repeated, singly or in groups.

3. The formal definition takes the form of English language text that can be used in a sentence of the form:

   'A <class name> is a <superclass name> that <definition>.'

4. The entity type name indicates the entity type in a schema that can be instantiated to hold the reference library object.

   EXAMPLE - If the object is 'check motor sump oil level', then the entity in ECMv4 is class_of_activity.
   
   The ERDL may include objects within ECMv4., such as 'activity'. It is possible to record separately that 'check motor sump oil level' is a specialisation of 'activity'.

5. The cardinality for composition and connection of an equipment item is for the running state. Any equipment item may violate this cardinality when being serviced or when partially manufactured.

   The cardinality may be specified by:

   • a comma separated list of integers, e.g. 0, 1, 2;
   • a range given in brackets, where the first item in the brackets is an integer and the second item is either an integer or the text 'infinity', e.g. [1, 100], [2, infinity];
   • the text 'any', which is equivalent to [1, 'infinity'].

6. The numeric value or range may be specified by:

   • an integer or real, e.g. 3, 13.5;
   • an integer range, e.g. [3, 10];
   • a real range, e.g. (0, 100.0);
   • a range limit with a bracket, '[' or ']', is closed (i.e. it includes the limit);
   • a range limit with a parenthesis, '(' or ')', is open (i.e. it excludes the limit);
   • an unbounded range is indicated by 'infinity' or '-infinity', e.g. (10.0, infinity).

7. The unit of measure is specified by text. SI units shall be specified according to ISO 31, e.g. m, Kg, kN, W.

8. Dates shall be in YYYY-MM-DD format according to UTC.

A. Single table database schema

The single table schema shown in Figure 4, has been proposed by Chris Angus as an internal database format. This is a highly normalised format which can cope with any ECMv4 defined data. This is not a view format suitable for browsing and editing.

Figure 4: A single table database format

NOTES:

1. 'M' or 'O' indicates whether or not the data is mandatory or optional.

B. Some useful subviews

Some useful subviews of the table defined in Figure 3, are as follows:

object source and approval:

this subview contains the source, and approval information for any engineering dictionary or reference data library class;

reference data library class of object:

this subview contains the definition of a reference data library class, which is not a class of relation;

A class of object is distinguished from the intersection of its superclasses by a text definition.

reference data library class of relation:

this subview contains the definition of a class of relation;

A class of relation has all information for a class of object, with information about the related classes and the cardinalities.

reference data library class of object criteria:

this subview shows intersecting superclasses, including property range criteria;

reference data library class of object valid classes of property:

this subview contains the classes of property that are valid for a class of object.

These views have the columns shown in Figure 5.

Figure 5: Some useful subviews

The 'source and approval', 'class of object', and 'class of relation' subviews are illustrated in figures 6, 7 and 8.

Figure 6: Reference data library source and approval

Figure 7: Reference library class of object

Figure 8: Reference library class of relation