Facility Alias
11 February 1998
updated 20 May 1998
Proposal
There has been a proposal to add a Facility_alias entity to Epicentre.
Problem
This appears to be a reasonable request. Unfortunately there are already
22 specific alias entities (not counting Ref_code_alias) and the list is
expected to grow. The Exchange Operations must know of the existence of
all aliases. Before Version 2.2, these were isolated in Ref_code_alias
and as subtypes of Object_alias. Version 2.2 introduced Activity_class_alias,
Equipment_class_alias, Facility_class_alias, Material_class_alias and Well_log_trace_class_alias
without a common supertype.
In addition, the behavior is becoming inconsistent:
-
Most alias entities use Ref_naming_system but some use Classification_system.
-
Some aliasable subtypes of Reference_behavior have a relationship to Ref_naming_system
but most do not. Some of these relationships are mandatory while others
are optional.
-
Most aliases match the length of the string identifier in the object but
others do not (e.g., Ref_code_alias --> Ref_unit_of_measure).
-
Ref_code_alias includes source (ref_source) in its
secondary identifier (SI) but all other aliases use the naming/classification
system. This means that POSC cannot provide multiple aliases (in different
naming systems) for the same instance.
Discussion
There is no semantic benefit from having specific alias subtypes as is
demonstrated by Ref_code_alias and Earth_surface_feature_alias. The semantics
of an alias is provided by the object for which it provides an alias. Further,
there are two fundamentally different behaviors involved in the aliases:
-
Objects which have user assigned identifiers and for which there are many
legitimate choices of identifiers. Examples are Well, Wellbore, Business_associate.
-
Object identifiers and aliases are interchangeable (at least to the extent
allowed by uniqueness constraints and string lengths). Each site may decide
which identifier is with the object and which identifiers are relegated
to alias-only status.
-
There is no particular reason that an alias cannot be longer that the identifier
of the object for which it provides an alternate identifier. This only
places an additional constraint on which aliases may be promoted to object
identifiers.
-
A relationship to Ref_naming_system is important in the object so that
it can be unambiguously understood which alias has been loaded into the
object.
-
These identifiers may have external meaning (as defined by the naming system)
but there is no requirement to understand that meaning in order to use
the model.
-
For objects with multiple components in the secondary identifier (SI),
it should be considered a coincidence (except by the naming system) if
the allias contains knowledge of the full identity of the object. For example,
a Wellbore alias in the naming system of "API 14 digit". Only the naming
system will know.
-
Objects which have reference behavior for which there is a fixed predefined
meaning of each instance. Examples are Coordinate_system and subtypes of
Ref_code.
-
An alias may not replace the identifier in subtypes of Reference_behavior.
-
Since no substitution occurs, the aliases can be any length.
-
There is no need for the object to have a relationship to Ref_naming_system
because that type of information is provided by attributes source and source_reference.
-
The alias should reference a naming system rather
than a classification system. The naming system may actually represent
a true classification system but that should be considered coincidental.
Classification_systems must be understood in order to understand
some standard instance data (e.g., Material_class). There is no requirement
to understand the Ref_naming_system associated with the alias.
-
The alias relates to the instance rather than to any one attribute of the
instance. For example, Ref_property_kind is identified by three relationships
but an alias can be specified which maps to the meaning of a specific instance
of Ref_property_kind.
-
It should be considered a coincidence that most subtypes of Reference_behavior
have a secondary identifier (SI) which is composed of a single attribute
of type STRING.
Currently, both types of alias are involved as subtypes of Object_alias.
This results in additional complexity for the Exchange Operations.
Proposal
To Replicate Existing Functionality
For both types of aliases, create a predictable high level pattern that
the Exchange Operations can rely on. All aliasable objects should inherit
from this pattern. Adding alias behavior to an object should not result
in new entities. See diagram HL4: Object
Alilas.
-
Create an abstract behavior (an entity which has no supertype, i.e., it
is not a subtype of E_and_p_data) of Aliasable_object_behavior.
-
Add Aliasable_reference_behavior as an abstract subtype of Reference_behavior.
-
Change the identifier in Object_alias to have a type of ndt_long_name instead
of ndt_name.
-
Add a many-to-one relationship from Aliasable_object_behavior to Ref_naming_system.
Object_alias and Ref_code_alias already have this. Do not add this
behavior to Aliasable_reference_behavior.
-
Add a many-to-one relationship from Object_alias to Aliasable_object_behavior.
-
Add a many-to-one relationship from Ref_code_alias to Aliasable_reference_behavior.
-
Delete the existing relationship from Ref_code_alias to Ref_code since
this will now be inherited by Ref_code.
-
Change the identifier in Ref_code_alias from ndt_name to ndt_long_name.
-
Change the SI of Ref_code_alias to use ref_naming_system
instead of source.
Make Aliasable_object_behavior the supertype (in addition to existing supertypes)
of all existing aliasable non-reference objects. Delete existing relationships
to Ref_naming_system. This will include:
-
business_associate
-
catalog_equipment
-
contract
-
selected subtypes of Earth_surface_feature (which contains ref_naming_system)
-
discovery_area
-
field
-
geophysical_acquisition_area
-
magnetic_polarity_zone
-
outcrop
-
inventory_object
-
land_property_parcel
-
rock_feature
-
seismic_geometry_set
-
stratigraphic_marker
-
temporal_object
-
wellbore
-
well_log_trace
-
well
Make Aliasable_reference_behavior the supertype of all existing aliasable
reference objects. That is, "move" them from Reference_behavior to Aliasable_reference_behavior.
The previous step will have deleted ref_naming_system from Earth_surface_feature.
Also delete ref_naming_system from Ellipsoid, Geodetic_datum and Typical_material.
This step will affect:
-
ref_code
-
selected subtypes of classification_class
-
activity_class
-
equipment_class
-
facility_class
-
material_class
-
well_log_trace_class
-
coordinate system
-
ellipsoid
-
geodetic datum
-
selected subtypes of earth_surface_feature
-
geodetic zone
-
geologic province
-
geopolitical feature
-
regulatory area
-
selected subtype of typical_object
Delete all existing subtypes of Object_alias and make it non-abstract.
This will delete:
-
business_associate_alias
-
catalog_equipment_alias
-
contract_alias
-
coordinate_system_alias
-
earth_surface_feature_alias
-
ellipsoid_alias
-
geodetic_datum_alias
-
inventory_object_alias
-
land_property_parcel_alias
-
log_trace_alias
-
rock_feature_alias
-
seismic_geometry_alias
-
stratigraphic_marker_alias
-
temporal_object_alias
-
typical_material_alias
-
wellbore_alias
-
well_alias
Delete the following:
-
activity_class_alias
-
equipment_class_alias
-
facility_class_alias
-
material_class_alias
-
well_log_trace_class_alias
Functional Changes
The behavior of the class aliases will change slightly because they currently
point to Classification_system instead of Ref_naming_system.
All aliasable entities (instead of just some of them) will have an 80
character alias.
The aliases for subtypes of Ref_code will be unique
within the Ref_naming_system rather than Ref_source.
Some subtypes of Reference_behavior will no longer have a relationship
to Ref_naming_system. This information can be moved to attribute source_reference.
Ellipsoid, Geodetic_datum and the subtypes of Earth_surface_feature
would no longer require a naming system with their alias.
The alias for Seismic_geometry_set will loose its special behavior of
asserting that the alias only applies to that portion of the set as specified
by the Seismic_line_segment. This semantic can be replaced by adding Seismic_line_segment
as an aliasable object.
Changes to add new functionality
Add entity Ref_naming_system_constraint to function as an association between
Ref_naming_system and Dae_entity_definition. This will allow a naming system
to be constrained for use with a selected set of entities. For example,
"API" can be constrained to Well, "API 12 digit" can be constrained to
Wellbore and "API 14 digit" can be constrained to Well_completion. This
will add semantic understanding of the naming system and will help prevent
nonsensical aliases. See diagram HL4: Object
Alilas.
Add new subtypes of Aliasable_object_behavior as they are requested.
Delete any existing relationships to Ref_naming_system.
-
Add Facility as a subtype of Aliasable_object_behavior instead of just
Well and Wellbore. Consider moving identifier to the supertype since all
existing subtypes of Facility have either name or identifier as attributes.
-
Delete existing relationships to Ref_naming_system from Well and Wellbore.
-
The following are additional candidates that contain a STRING identifier:
-
activity
-
data_collection
-
geologic_process
-
subtype of association
-
subtypes of business_object
-
damage_area
-
divestment_package
-
document_specification
-
evaluated_flow_stream
-
general_land_right (ndt_identifier)
-
geoid_model
-
guideline_or_privilege
-
land_property_boundary
-
legal_survey_area
-
legal_survey_boundary
-
legal_survey_line
-
legal_survey_point
-
mineral_zone
-
pool (ndt_identifier)
-
reservoir
-
reservoir_fluid_system
-
reservoir_zone
-
aquifer (ndt_identifier)
-
schedule
-
seismic_data_set
-
seismic_line_segment
-
seismic_traverse
-
well_surface_point
-
subtypes of technical_object
-
area_cell
-
binset
-
binset_intersection
-
cement
-
contract_clause
-
contractual_obligation
-
data_trace (instead of just well_log_trace)
-
earth_model
-
earth_model_object
-
feature_boundary
-
graphical_element
-
grid_or_mesh
-
hatch_line_pattern
-
incell
-
intext
-
isoline
-
isoline_set
-
line_pattern
-
local_vertical_datum
-
local_rock_feature (ndt_long_name)
-
other_spatial_object
-
pfnu_internal_behavior_model
-
pressure_measurement_datum
-
regulation_clause
-
rock_component
-
rock_fluid_interaction
-
rock_in_outcrop
-
seismic_acquisition_vertex
-
seismic_facility_node
-
seismic_feature
-
seismic_header
-
specific_fluid_component
-
specific_fluid_phase
-
subsurface_rock_segment
-
terminal_cell
-
typical_facility
-
wavelet_or_filter
-
well_test_recovery
Add subtypes of Reference_behavior as subtypes of Aliasable_reference_behavior.
This includes the following entities which have identifiers:
-
activity_template
-
classification_system
-
classification_class (instead of just Activity_class, Equipment_class,
Facility_class, Material_class and Well_log_trace_class)
-
coordinate_transformation
-
coordinate_transformation_method
-
geoid
-
hole_type
-
image_palate_type
-
line_style_type
-
object_abundance_class
-
parameter_type
-
pattern_fill_type
-
predicate_type
-
prime_meridian
-
process_parameter
-
ranking_system
-
relative_rank
-
symbol_library
-
symbol_type
-
text_stype_type
-
typical_activity
-
typical_geologic_process
-
typical_object (instead of just Typical_material)
-
vertical_reference_datum
The following subtypes of Reference_behavior have no identifiers but could
conceivably be aliasable:
-
coordinate_transformation_parameter
-
coordinate_transformation_value
-
general_coordinate_system_axis
-
measured_depth_system_axis
-
vertical_depth_system_axis
The following entities are subtypes of both Association and Reference_behavior
and probably should not be aliasable:
-
activity_class_classification
-
applied_coordinate_transformation
-
document_spec_class_classification
-
equipment_class_classification
-
facility_class_classification
-
material_class_classification
-
well_log_trace_class_classification
Diagram