POSC Specifications
|
Changes |
Change Overview
Synopsis
This represents a reorganized model that minimizes multiple inheritance, eliminates all
subtypes of Activity, shortens names to a maximum of 30 characters and otherwise simplifies
the model. Additional changes have been derived from extensions developed for the FieldBank
project (adds Potential
Field data), from Statoil's SLEGGE project (to develop and implement a POSC compliant data
store and access) and from EPSG recommendations.
Mechanics
The changes for Version 3.0 were made using the POSC developed
Incremental Express syntax.
The changes were applied using the POSC developed
Incremental Express Tool that is available for
anyone to use.
The changes were applied by the tool in sequential order as indicated by the change number.
A subsequent change would be applied against the results of the previous change.
For example, change C001 was the first change that was applied
and C002 was applied against
the model that resulted from applying C001. In some cases, modifications made in one change
were backed out or modified in subsequent changes. This is especially true for changes which
cross snapshot boundaries since each snapshot was frozen. Also, the Incremental Express Toolset was
evolving over time with more checks being added. This resulted in cleanup changes being added as a
modification to previous snapshots.
Changes developed by POSC have a name that is prefixed by ERP (Epicentre Restructure Project).
Changes that were developed by Statoil's SLEGGE project have a name that is prefixed by ESM (Epicentre SLEGGE Model).
Note that changes submitted by SLEGGE may have had minor changes applied before inclusion.
Changes that were developed for the alpha version do not have a number after the prefix (e.g., "ERP_").
Changes that were developed for the beta version have the number 2 after the prefix (e.g., "ESM2_").
Changes that were developed for the gamma version have the number 3 after the prefix (e.g., "ERP3_").
Projection changes (i.e., they do not affect the logical model) have a prefix of "_ERP4_" and will not
be shown as changes in the documentation.
Changes that were developed for the final version have the number 5 after the prefix.
Global POSC Changes
The following represents global POSC initiated changes that were included in this version:
- Shorten Names (primarily via change C112) - Shorten entity and
attribute names from a maximum of 40 characters to a maximum of 30 characters.
- Standardize Identifier (restructuring changes plus changes C037 and
C049) - Attributes name, identifier and kind were standardized as
identifier. The length of the identifiers was changed to 80 characters. The restructuring changes
allowed the identifiers to be moved to the highest common entity (e.g.,
Material).
- Move Description (primarily via change C117) -
Attribute description was moved up to
E_and_p_data.
- Eliminate many-to-many relationships (primarily via change C053) -
This change converts all remaining many-to-many relationships to an association entity. This more easily allows
local extensions to qualify the relationship. Where appropriate, the new entity used a name derived
from the V2.2 relational projection intersection table.
- Eliminate void inverse relationships (primarily via change C043) -
This change adds attributes to represent missing inverse attributes. This makes the model consistent in that all
direct relationships now have an inverse.
Major POSC Changes
The following represents some of the major POSC initiated changes that were included in this version:
- Minimize Multiple Inheritance (primarily via changes C004 through C042)- This required that the number of abstract behaviors be
minimized. Epicentre requires that all non-abstract entities
be a direct or indirect subtype of
E_and_p_data (or of
Ref_data in previous versions).
An abstract behavior is an entity that does not have a supertype and requires that
all non-abstract subtypes must also be an indirect subtype of
E_and_p_data (thus multiple inheritance).
These changes were based on an initial proof of concept proposal for
Eliminating Reliance on Multiple Inheritance.
The actual changes generally follow proposals in this outline although some details are different.
A primary goal of the reorganization was to simplify the model with no (or minimal) loss of semantics.
Thus, some localized multiple inheritance was retained because the model would be more complex without it.
- The primary change that allowed this to occur was to convert
the spatial model back to the form that existed in Epicentre Version 1.0.
That is, an object may be represented by
many spatial objects rather than being a spatial object. Former subtypes of
Spatial_object that
only represented spatial behavior were eliminated (e.g., Position_in_earth_model and its subtypes).
Former subtypes of
Spatial_object that also had business semantics were retained (e.g.,
Wellbore) but
functionality that represented spatial concepts were moved to
Spatial_object or its subtypes. This change
also moved Topological_object
up in the hierarchy so that objects may be topologically related independent
of any geometrical knowledge (e.g., assert that a
Well is within a
Field without having to create a
Spatial_object for each).
- Some abstract behaviors (e.g.,
Material,
Topological_object,
Process_data,
Technical_earth_feature
(formerly Earth_surface_feature),
Spatial_object) were made an indirect subtype of
E_and_p_data.
- Some abstract behaviors entities (e.g., Reference_behavior, Geologic_object,
Subject_of_guideline_or_privilege) were eliminated (but their subtypes were generally retained) because
they were no longer needed after restructuring.
The attributes of Reference_behavior were replicated as opposed to being inherited.
This was facilitated by grouping the former subtypes under a few supertypes
(i.e., Association_reference,
Earth_feature,
Ref_aliasable_data, and
Technical_reference).
- These changes allowed many common behaviors (e.g., identifier, alias, naming system, description)
to be moved higher in the inheritance hierarchy.
Also, the subtypes of Object_alias represent a higher level in the entity hierarchy.
- The only remaining abstract behaviors are:
PFNU (formerly Product_flow_network_unit),
Grid_element_behavior,
Grid_geometry_behavior,
Fluid_phase and
Fluid_component.
- Eliminate Activity Subtypes (primarily via change C056) -
This resolves a conflict about whether to add new
Activity subtypes
or to add new instances of
Activity_class. The behavior that existed in the former subtypes of Activity
was analyzed and moved up to Activity. The dropped subtypes may be added as instances of Activity_class.
- An instance of Activity may be a kind of one
Activity_class.
- An Activity can be identified within the context of an object (e.g., the
Well where the activity occurred).
- An Activity can have an involvement (e.g., "subject of", "used by") with objects (via
Object_activity_involvement) or other activities (via
Activity_activity_involvement).
This represented the overwhelming majority of the behavior of the former subtypes.
- An Activity may have many
Pty_generic_properties (formerly Pty_equipment_facility).
- An Activity_class can have common expected behavior
(Common_activity_involvement,
Common_activity_property and
Common_activity_composition).
This allows, for example, retention of the knowledge that an activity that IsA "wellbore actitity" should be part of an activity
that IsA "well activity". Thus, the detailed behavior that was formerly captured using the fixed
entity relationship structure can now be captured in the more flexible standard instance data.
- Add Potential Field (primarily via change C110) - Many generic Seismic entities
were renamed as Geophysical entities. In addition, specific entities were added for potential field (i.e.,
Potential_field_data_set,
Potential_field_geometry_set,
Potential_field_proc_grid,
Potential_field_platform,
Potential_field_recorder and
Potential_field_sensor_fcl).
- Apply EPSG Recommendations (primarily via changes C055,
C109 and C148) - These changes modify Epicentre
to the support EPSG V5 data. Other than a general reorganization and renaming of existing functionality,
the major additions were to support concatenated transformations and compound coordinate systems.
Also, the concept of "applied" transformation was eliminated because
most transformations are specific to two systems. In addition, change
C045
allows a local coordinate system to be identified
within the context of an object (e.g., a "measured depth" system within a Wellbore).
- Utilize Class as opposed to Typical (primarily via change C054 and
C047) -
This change resolves a conflict between whether to use class or typical to understand the
fundamental nature of an instance. All references to typicals were removed from objects in favor of a reference
to a class. This decision was reinforced by changes that strengthen the classification model (i.e.,
C039,
C040,
C059,
C063,
C064,
C111 and
C123).
- Rationalize Property Model (primarily via changes C124 and
C125) -
This change reworks the ref property type/kind part of the model as shown on diagram
MTP: Reference Properties. The purpose is to simplify the type/kind
specification and to add the capability of capturing the information that is contained in the NDT
specifications. The kind of property will be independent of any possible representations.
This allows the generic properties to have the same semantics that are available to the
NDT specifications (as used by PTY entities).
- Add Picks (primarily via changes C052 and
C065) - This change adds
Seismic_pick and
Wellbore_pick as versionable concepts. This replaces
the reliance on a Wellbore_point to locate a geologic concept.
- Eliminate most Temporal_object subtypes (primarily via change C057) -
This change eliminates all subtypes of
Temporal_period and
Temporal_event in order to bring this area in line
with the geologic changes made in V2.2. This also moves the temporal concepts from being a
topological concept
because there does not appear to be any topological behavior
that benefits the time concepts.
- Well Log Trace Mnemonic (primarily via change C144) -
This change attempts to do a better job of handling well log trace mnemonics that were stored in
Well_log_trace_alias in V2.2.
- Local Spatial Coordinate System (primarily via change C045) -
Allow a local coordinate system to be identified within a context. This is needed for
parameterized coordinate systems such as measured depth systems within a wellbore and binset coordinate systems.
- GIS Geometry (primarily via change C046) -
Add a GIS oriented geometry property that simply uses a list of real to capture the semantics
of the OpengGIS WKB geometry specification.
- Wellbore Reference (primarily via change C048) -
Eliminate the concept of a Wellbore_reference. Instead, retain Wellbore_point and Wellbore_interval
as subtypes of Wellbore_component_facility to represent interesting "named" point/interval
facilities in the wellbore. The semantics of the deleted subtypes is retained by the kind attribute.
That is, the deleted subtypes become instances of class.
- Add Objective (primarily via change C113) -
This change adds the concept of Objective as requested by the WIME project.
- Data Trace (primarily via change C115) -
This change moves Seismic_data_set to be a subtype of Data_trace and generalizes the
behavior of all "traces".
- Fluid Saturation (primarily via change C120) -
This change generalizes the description of fluid saturations in rock materials and reservoirs.
Major SLEGGE Changes
The following represents some of the major changes that were initiated by Statoil's SLEGGE project:
- Fluid Cargo (primarily via change C132) -
Add the concept of a fluid cargo that describes a discrete amount of material that is stored and/or transported,
probably being the subject of a contract.
- Fluid Phase Properties (primarily via change C128) -
This change alters the current PVT model for fluid phase properties by combining multiple,
concurrently defined properties in the same property instance.
- License and Lease (primarily via change C134) -
This modification merges the surface and mineral (subsurface) concepts for agreements and rights.
This is done to accommodate business practices in that subsurface parts of the earth are
referenced as if they were surface parts.
- Offshore Blocks (primarily via change C135) -
This change clarifies the representation of offshore blocks, and adds offshore areas and quadrants.
- Structured Documents (primarily via change C136) -
This proposal adds the capability to describe the content and structure of document specifications.
This provides a description of the structure of a document based upon a subset of features in XML Schema.
- Data Information (primarily via change C126) -
These changes provide additional meta information on the instantiation state of the data store.
In addition, attribute source was moved up to
E_and_p_data in recognition that all data can have a source.
Minor SLEGGE Changes
The following represents the minor changes that were initiated by Statoil's SLEGGE project:
© Copyright
POSC. All rights reserved.