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:

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: 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. 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: 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: Delete all existing subtypes of Object_alias and make it non-abstract. This will delete: Delete the following:

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 subtypes of Reference_behavior as subtypes of Aliasable_reference_behavior. This includes the following entities which have identifiers: The following subtypes of Reference_behavior have no identifiers but could conceivably be aliasable: The following entities are subtypes of both Association and Reference_behavior and probably should not be aliasable:

 Diagram