Introduction

Once documented, the mapping of these items into Epicentre also serves as a useful guide to data loaders and application developers, shortening the length of time it takes them to begin using Epicentre in an effective way.

Also, by avoiding misunderstandings and differing interpretations of the data model by implementors, this document will greatly facilitate the interoperability of application programs based on Epicentre.

Express-I Notation

The notation adopted for describing the mapping to Epicentre is a simplified adaptation of the Express-I syntax. The Express-I instance language provides a means of displaying example instantiations of Express defined elements.Express is the international standard (ISO 10303, part 11) information modeling language used to define the Epicentre Logical Data Model.

A brief explanation of some Express-I notation used in the context of Epicentre is provided here for clarity. Refer to the Express-I Language Reference Manual for details.

• The `;' symbol is used to terminate a statement. Statements can be nested.
• The `=' symbol is used to associate a name to an entity instance. For example:

  well_1 = WELL {};
  

• The `-->' symbol can be read as `assigned the value of'. Examples:

  start_time --> `1-Jul-83';
  well --> @well_1;
  

• The `@' symbolizes a reference to an entity instance. Hence in the example above, `@well_1' indicates a reference to the entity instance `well_1'.
• Dynamic members (e.g., attributes for an entity instance) are represented and enclosed by a pair of braces `{}'.
• Aggregates (lists, sets or bags) are represented and enclosed by a pair of parentheses `()'.
• Comments are delimited by `(*' and `*)' and can span several lines. For example:

  well --> @well_1; (* This is a comment
  which spans
  several lines *)
  

• In-line comments are denoted by a double dash `--' and terminated by a LINEFEED. For example:

  well --> @well_1; -- This is an in-line comment
  

• The `<--' symbol can represent a derived attribute, or an inverse attribute. With Epicentre it is used more often in the latter sense, and can be used to depict an inverse relationship. For example, when a WELL_ALIAS is defined for a WELL, the WELL has an inverse relationship to WELL_ALIAS:

  Wa = WELL_ALIAS {well --> @W};
  W = WELL {well_alias <-- @Wa};
  

• Inverse entity relationships (i.e., represented by `<--' ) are also documented to facilitate the task of data readers or viewers. Inverse entity relationship values are automatically assigned by DAE calls.

Additional notation convention adopted in this document are listed below.

• Epicentre entities are represented in uppercase (e.g., WELL).
• "Hot" links are shown in italics with entities leading to the dictionary and other links that follow the @ symbol go to the pertinent reference in the model.
• Instance data and POSC reference values (PRV) that are part of the example are shown in Blue to enhance readability.
• Entity attributes which are mandatory (M) or secondary identifiers (K) are indicated for each instantiation. For example:

  name(M,K) --> `drilling contractor';
  

• List and unique list aggregates (i.e., ordered) are indicated with LIST or LIST OF UNIFQUE respectively and bag aggregates are indicated with BAG. If an aggregate type is not specified then SET is assumed. For Example:

  coordinates(M) --> LIST (32.34424019, 102.47281293);
  descriptor --> LIST OF UNIQUE (@i_index,@j_index);
  

• The `#' symbolizes a reference to an entity instance in another model using the form `#model_id.instance_id'. Hence in the example above, `#Field_Performance.well_1' indicates a reference to the entity instance `well_1' in the `Field_Performance' model. This reference is extensively used for coordinate system information.
• The information content of complex data values (i.e., quantity, ratio, line, etc.) is presented as an Epicentre data type with attributes and values (using similar Express-I syntax) . Access and manipulation of these data values is via Data Access & Exchange (DAE) calls. For example,

  data_value(M) --> QUANTITY { -- ndt_temperature
       real_value --> 212 ;
       ref_unit_of_measure --> @PRV_degF; };
  

• Supertype and subtype entities will not be instantiated or indicated unless they add clarity to the documentation. This attempt to minimize clutter is possible because attributes inherited by instantiated subtypes are explicitly documented in Epicentre. An exception is when the inclusion of SUBOF or SUPOF will clarify relationships between entities. A supertype will be represented by its entity identifier rather than an instance as illustrated below:

  depth_axis = VERTICAL_DEPTH_AXIS {
     SUBOF (COORDINATE_SYSTEM_AXIS);
  };
  

• Although each entity may have many optional attributes, only the minimal set of attributes needed to illustrate the mapping is documented.

Reference Values

Reference values needed for mapping of each of the business objects defined in this document is provided in each section. However, to minimize clutter, POSC defined reference values are not explicitly shown, except where needed for clarity. They are referenced using the name of an instance where the name is created by pre-pending `PRV_' (POSC Reference Value) to the reference value and by substituting `_' for spaces in the value (e.g., PRV_drilling_contractor)and are in Blue to incrrease readability. A POSC Reference Value expands to a form similar to the ones illustrated in the examples below:

PRV_drilling_contractor = REF_BUSINESS_ASSOCIATE_FACILITY_ROLE {
   name(M,K) --> `drilling contractor';
   source --> @PRV_POSC;};

PRV_POSC = REF_SOURCE {name(M,N) -->`POSC';};

ref_business_associate_facility_role(M,K) --> @PRV_drilling_contractor;

Documentation Structure

• The heading will indicate the business term being discussed.
• A definition will be specified if appropriate.
• A description of the data being instantiated will be described, if appropriate.
• The full context will be defined using the Express-I format (with POSC extensions) in order to precisely and unambiguously define the information to the extent necessary to support interoperability. This will begin with at the statements that define the name of the model and the schema used:

  MODEL Model_name_here;
  SCHEMA_DATA Epicentre_V2.1;
  

• The body of the Express-I example will be given
• The Express-I example will end with the following statements:

  END_SCHEMA_DATA;
  END_MODEL;