Proposed modifications in order to reduce our reliance on multiple inheritance

Introduction

Multiple inheritance did not exist in Epicentre V1.0. As a result of the PPDM merger effort, Epicentre V1.1 was modified to split the spatial model into abstract behaviors with each "business" entity inheriting the behavior of one spatial object via multiple inheritance. Since then, the use of the concept has mushroomed.

There has been too strong of a distinction between Business_objects and Technical_objects. As high level business behaviors have been identified, there has been a reluctance to move subtypes of Technical_object to become a subtype of Business_object. The result is that some of the "business" concepts have been relegated to abstract behaviors rather than being a "main line" entity.

In the modifications proposed below:

  • Red text indicates something which may be questionable or more controversial than the other points and should be more closely questioned.
  • Blue text highlights a new behavior.
  • The following behaviors will be addressed: See the diagram High Level Hierarchy for a view of the proposed new high level hierarchy.

    Product_flow_network_unit

    Product_flow_network_unit is equivalent to a SELECT (on a somewhat random collection of entities) and should remain as an abstract behavior. Since it only adds aggregate relationships, it does not affect the subtypes in the physical model. Its effects in the physical model are isolated in Product_flow_network_group_allocation, Product_flow_network_unit_port, Pfnu_period_report, Production_activity, Pfnu_grid_cell_connection, Surface_fluid_phase_condition, Reserves and Reserves_evaluation.

    Reference_behavior

    There are a couple of options for Reference_behavior listed in order of decreasing percieved preference:
    1. Modified 20 April - Delete it. Group its subtypes under a few select supertypes that have the "source" behavior (i.e., replicate the pattern instead of inheriting it).
    2. Same as above but keep Reference_behavior as an abstract supertype of  Technical_reference_alias, Earth_feature_reference, Technical_reference and Association_reference but with no attributes. By eliminating the attributes it does not impact the projection but it still allows the Exchange operations to understand (via meta data) what instances may have "source".
    3. Keep it as an abstract behavior. It only adds simple attributes and void relationships to static Ref entities.There are no relationships "to" Reference_behavior.

    Grid_element_behavior and Grid_geometry_behavior

    There are several possibilities listed in order of decreasing percieved preference:
    1. Modify the DAE specification to explicitly support the Grid_element_behavior and Grid_geometry_behavior at the datatype level. This would include knowledge of specific attributes in associated instances. Make the information queriable. This eliminates any opportunity to have the geometry as part of the uniqueness on the element.
    2. Since the overwhelming majority of the subtypes are properties, move the behavioral entities to become subtypes of Property and eliminate the non-property entities as subtypes:

    Business_object

    Business_object is not an abstract behavior but it is one of the main causes of our nightmarish subtyping scheme. Technical_object does not add any behavior.

    Note that if all of the changes in this proposal are implemented then only the following entities will remain as direct subtypes of Business_object (which leaves other possibilities for cleanup):

    The following alternatives are listed in the order of decreasing perceived preference:
    1. Make Technical_object a direct subtype of E_and_p_data. This will eliminate the object ranking behavior from Technical_objects. Move the Business_object behavior (but keep the entity) up to Object_of_interest and make Topological_object a direct subtype of Object_of_interest. Consider deleting Object_ranking, Relative_rank and Ranking_class entirely.
    2. Leave Business_object as a direct subtype of Object_of_interest. This will necessarily result in many entities which are Technical_objects becoming Business_objects (e.g., as subtypes of Material). This is the scenario which is assumed in the rest of this document (because it captures the most detail).
    3. Make Business_object an abstract behavior which only adds aggregate attributes (i.e., there are no direct attributes in the physical implementation). This isolates the impact in the areas of Contract, Guideline_or_privilege_compliance, Guideline_or_privilege, Derived_interest_makeup, Contractual_obligation and Contract_designation. Make all "detail" entities (i.e., those which otherwise do not become indirect subtypes of E_and_p_data) subtypes of Technical_object.

    4. Delete Business_object and move its behavior up to Object_of_interest. This will add its behavior to all existing subtypes of Technical_object  Move all "detail" entities to be subtypes of Technical_object.

    Subject_of_guideline_or_privilege

    There is no good reason for this entity to be an abstract behavior since all of its "leaf" subtypes are direct or indirect subtypes of Technical_object. See diagram Subject of Guideline or Privilege Hierarchy.

    Process_data

    There are multiple alternatives to handle Process_data listed in the order of decreasing perceived preference:
    1. NEW 21Apr99 - This is a compromise which retains Property high in the hierarchy and retains Process_data as a collector of other things which normally get created in processing.
    2. NEW 19feb99 - This is a combination of the next two bullets plus a movement of Ref_data.
    3. Eliminate the requirement to create a "fake" instance of Data_collection just to say that a single instance of Object_of_interest (e.g. a Well_log_trace) or Ref_data was "used" by an Activity in the context of a Process_parameter.
    4. In order to retain the existing behavior:

    Fluid_component and Fluid_phase

    These are emulating a SELECT data type. There appear to be three options listed in the order of decreasing perceived preference:
    1. Keep them as Abstract_behaviors.
    2. Delete Fluid_component and Fluid_phase.
    3. Modify the DAE to allow SELECT data types. Note that this may not worth the trouble since (in this case) an abstract behavior provides the same functionality in the logical model and the physical implementation would probably be the same in either case.

    Earth_surface_feature

    Make Earth_surface_feature an indirect subtype of E_and_p_data (see Earth_feature and Locatable_object). This recognizes that the surface features are an identifiable business concept  with business identity rather than a behavior (which does not have identity).
  • Eliminate Business_object as the direct supertype of  Regulatory_area, Geophysical_acquisition_area,  Geopolitical_feature, Discovery_area, Field and Outcrop.
  • Eliminate Technical_object as the direct supertype of  Geodetic_zone, Geographic_feature, Geologic_province, Magnetic_polarity_zone.

  • Material and Geologic_object

    Make Material an indirect subtype of E_and_p_data (see Locatable_object). In order to better understand the proposed inheritance changes, see diagram Material and GeologicFeature Inheritance Hierarchy.
  • Add attributes identifier, ref_naming_system and description to Material.
  • Delete attribute identifier in Cement, Subsurface_rock_segment, Local_rock_feature, Rock_component, Rock_in_outcrop, Specific_fluid_component and Reservoir_fluid_system.
  • Modify Subsurface_rock_segment to point to Facility instead of Wellbore. This would allow the rock material in the vicinity of any facilitiy (e.g., verticaly under a Well) to be described.
  • Allow Material to be located by many Spatial_objects (see Locatable_object).
  • Make Document a subtype of Material. Note that this will allow documents to be classified, composed (assembled or collected), etc independent of a Document_specification.
  • Delete Rock_feature_part since it does not do much after removal of Rock_feature as a subtype of Material.
  • Move its subtypes up to be a subtype of Rock_material.
  • Move attribute Rock_feature_part.rock_material up to Rock_material and make it non-void on the other end.
  • Delete Geologic_object and Material_sample.
  • Eliminate Rock_feature as a subtype of Geologic_feature. NEW 1apr99 - In hindsight, Rock_feature should stay as a subtype of Geologic_feature because it primarily represents a named "concept" of the material. Thus we will need to copy the appropriate "material" properties to Rock_feature. The real downside of this is that some material classes may need to be replicated in feature class (similar to the facility/equipment problem).CLASSIFICATION - This might be solvable by having the "object" classification entities point to Classification_class instead of one of its subtypes.  We could delete all existing *_class_classification entities and add Class_specialization (in a hierarchy) and Class_classification so that the classes could also cross-polinate. We could make Rock_feature_class a subtype of Material_class with a mandatory one-to-one relationship to Rock_feature. A similar thing could be done for all of the other possible "archetypes" (e.g., Typical_material_class). We could also eliminate the hard distinction of the classes by deleting the subtypes such as Material_class and rely on the naming system and Ref_naming_system_kind to clarify the intended use of the class.
  • Modify Seismic_feature_classification and Interpreted_feature_association so that they optionally point to Rock_material (this adds Rock_feature_part) and Geologic_feature instead of just mandatory to Geologic_feature. Add mandatory-select-one rule.
  • Modify Wellbore_geologic_target to additionally point to Rock_material (this adds Rock_feature_part). Add rock_material to mandatory-select-one rule and to SI.
  • Add  geologic_process and geologic_province relationships to Rock_material (this adds Rock_feature_part).
  • Make Geologic_feature locatable using many Spatial_objects (see Earth_feature and Locatable_object).
  • Modify Sample_acquisition, Materials_processing and Well_test_recovery to point to Rock_sample, Fluid_sample, and/or Filter_cake (as appropriate) instead of pointing to Material_sample.
  • Move Material_sample.descriptive_text up to Material. Redundant to description?
  • Eliminate Business_object as a direct supertype of Reservoir_fluid_system and Rock_fluid_feature.
  • Eliminate Technical_object as a direct supertype of Subsurface_rock_segment, Local_rock_feature, Rock_component, Rock_in_outcrop, Rock_feature, Feature_boundary, Seismic_feature, Cement and Specific_fluid_component.
  • Delete Inventory_object since it does not provide any inherent business identity of an object.
  • Delete Inventory_object_alias. Rename Inventory_object_storage to Material_storage (modify it to allow storage in Facility rather than General_facility?).
  • Create the association entity Material_disposition and move the concepts of Material_storage (in a facility), Material_composition (in a material), Material_installation (in a facility) as subtypes of Material_disposition. Allow a material to have many dispositions (i.e., move the "disposed material" relationship from the subtypes to the new supertype) but each material should not concurrently have more than one disposition.
  • Consider adding a new concept of Material_transport (i.e., in transition) as another disposition.
  • Make Equipment_item a subtype of Material.
  • Delete Equipment_class, Equipment_class_alias, Equipment_class_classification, Equipment_fulfillment, Equipment_item_installation and Equipment_installation since they will now be redundant.
  • Move Catalog_equipment to be a subtype of Typical_material. Eliminate Business_object as a direct supertye of Catalog_equipment. Note that this would make Catalog_equipment a subtype of Technical_object instead of Business_object.
  • Since Catalog_equipment is non-abstract, consider deleting all of its (26) subtypes. They do not add any behavior and do not contribute to the identity of an instance. If the semantics of the subtypes is important then add a "kind" entity and allow the "kinds" to be specialized (semantically comparable to class-classification but constrained to a hierarchy). This will allow the "kind" to be part of the uniquess of the instance. Allow the kinds to be classified by Material_class. Otherwise, add them as instances of Material_class. See Classification.
  • Move (with rename) Catalog_equipment_installation, Catalog_equipment_succession and Catalog_equipment_version to apply to Typical_material.
  • Move (with rename) Equipment_item_connection to apply to Material.
  • Split material_composition into the two distinct concepts of Material_composition and Typical_material_composition. The existing combination is unnecessarily difficult to explain.
  • Move (with rename) the Equipment_composition behavior to Material_composition (delete/rename Component_material). Note that this will allow material "collections" and it will retain the capability to compose "typicals" into "specifics".
  • Eliminate Material_composition as a supertype of Component_material_type and rename to Typical_material_composition. Make "whole" relationship to Typical_material mandatory.
  • Split Material_classification into the two distinct concepts of Material_classification and Typical_material_classification.
  • Move (with rename) Catalog_equipment_classification to apply to Typical_material.
  • Delete attribute Material_classification.typical_material.
  • Make attribute Material_classification.material mandatory.
  • Add Object_abundance_class and Uncertainty_class relationships to Typical_material_classification.
  • Delete attribute object_abundance_class from Material_classification? This appears to be the desired result since Component_material does not point to Object_abundance_class.
  • Delete Material_typification as being redundant to Material_classification and Typical_material_classification.
  • Delete Catalog_equipment_material_specification since its behavior appears to be identical to Typical_material_classification.
  • Since Hole is documented to be a cavity in one Rock_material and since it does not tell you anything about the "usage" that the facility represents, move Hole (and subtypes Pore and Fracture) to be a subtype of Rock_material instead of being a subtype of General_facility.
  • Delete the redundant "part of" relationship to Rock_material.
  • Delete the following redundant attributes from Hole: lithologic_analysis, pty_effective_permeability, pty_volume, pty_permeability_compaction_curve, pty_tortuosity, pty_permeability_vertical, pty_area, pty_surface_area_per_volume, pty_permeability,  pty_permeability_horizontal,  pty_porosity_compaction_curve.
  • Delete the following redundant attributes from Pore: pty_effective_porosity, pty_pore_throat_diameter, pty_pore_volume_compressibility.
  • Consider moving the following atributes from Hole to Rock_material: pty_volume_per_length, pty_axial_length, pty_effective_length_thickness_ratio, pty_thickness, pty_diameter.
  • Regardless of whether Hole is a Facility or a Material:
  • Delete Hole_classification (and Hole_class) since it is redundant to Material_classification or Facility_classification.
  • Delete Hole_type_interpretation (and Hole_type) since it is redundant to classification.
  • Delete attributes Document.geoscience_interpretation and Equipment_item.utilized_in_activity since they will be redundant to the inherited attribute Material.used_by_activity.
  • Delete Geologic_object_association in favor of a new Geometrical_relationship.
  • ???Make Drilling_kick_fluid and Well_test_recovery a subtype of Fluid_sample instead of just being a direct subtype of Technical_object???

  • Topological_object

    FIX the spatial model by moving it closer in alignment to Epicentre V1.0. That is, split the spatial shape of an object from the business concept of the object and allow the business concept to be represented by many spatial shapes (without constraining what type of shape may be used). In order to better understand the proposed inheritance changes, see diagram Spatial Object Hierarchy.

    Some major subdivisions of this section are:

  • Spatial_object
  • Earth_model_object
  • Earth_feature
  • Earth_feature_component
  • Locatable_object
  • Miscellaneous items



  • Make Topological_object a subtype of Business_object.
  • Eliminate Technical_object as a direct supertype of Temporal_object.
  • Delete Fault_plane_orientation in favor of a new entity Geometrical_relationship that has relationships to Topological_object. Delete the many-many "be the lower boundary of/be the upper boundary of" relationships on the subtypes of Geochronologic_zone in favor of the new Geometrical_relationship. Similarly, delete the many-many "be bound by" relationship between Temporal_event and Temporal_period.


  • Make the Spatial_object subtypes Vertex, Edge, Ring, Face, Shell, Region and Composite_spatial_object non-abstract and eliminate all subtyping.
  • Add identifier, ref_naming_system (???aliasable???) and description attributes to Spatial_object.
  • Delete Simple_spatial_object.
  • Clearly document that each Spatial_object represents one opinion of the spatial nature of something while each associated geometry property represents different representations of that opinion. Note that this is redundant to the "represent" semantics of Grid_geometry_behavior.
  • Allow a Spatial_object to be created (i.e., versioned) by an Activity. The relationship should be identifying on the Spatial_object. This replaces to the relationship from Earth_model_object to Geoscience_interpretation.
  • Allow an Activity to be "located" by many Spatial_objects. This should be identifying on the Spatial Object. Add an Optional-Select-One rule for the two different identifying relationships to Activity. This is independent of a Locatable_object being "located" and allows the spatial representation of an object to be "versioned" within the context of an Activity (i.e., over time). Delete Wellbore_activity.position_in_wellbore[many-to-many].
  • Fix the DAE to allow determination of the subtype of an instance using Level 2 queries. This will be necessary in order to determine, for example, that a Vertex is actually a "wellbore point".
  • Add Composite_spatial_object_composition as a resolver of a many-to-many relationship between Composite_spatial_object and Spatial_object (i.e., move the m-m up from composite subtypes).
  • Allow a Spatial_object to be identified by a Composite_spatial_object of which it is a part (i.e., move from Earth_position_simple).
  • Since all Spatial_objects will now have identity within the context of one "business" object, add a relationship from Property to one Spatial_object which "partially" versions the property? This will handle semantics of the current non-geometry properties which are a property of a Spatial_object (e.g., Position_on_earth_surface.pty_geologic_age).  Note that this is semantically equivalent to Pty_element_behavior (i.e., it is a property of the object "as located there"). It also retains most of the semantics of the relationship from Other_spatial_object to Property.
  • Add a resolving entity to the existing many-to-many relationships between the simple spatial objects. Add a mandatory "inner" or "outer" flag to face-bound-by-ring. Add an optional "begin" or "end" flag to edge-bound-by-vertex (equates each vertex to a bounding node on the grid).
  • Delete "spatial behavior" relationships from subtypes of Graphical_element (i.e., Line_element.ring, Line_element.vertex, Area_element.bounding_ring, Patterned_area.bounding_ring). Delete Composite_graphical_element since it only appears to have spatial behavior. Consider deleting Graphical_element entirely.


  • Delete Earth_model_object and its subtypes (total of 24 entities). Note that General_surface_composite is not a subtype of Composite_spatial_object. Move any required locate/represent behavior (geologic_feature, wellbore_component_facility, well_completion, fluid_system, well_log_trace, other_material, wellbore_activity, material_collection_station, earth_surface_feature) to Spatial_object (see Locatable_object).
  • Move attribute position_uncertainty_classification from Earth_model_object to Spatial_object.
  • Move attributes pty_fault_separation, pty_fault_slip, pty_fault_slip_variable, fault_plane_orientation from Earth_position_face to the new Geometrical_relationship.
  • Move attribute pty_area from Earth_position_face to Face.
  • Move attributes pty_azimuth and pty_inclination_from_vertical from Earth_position_face and General_surface_area to Face.
  • Move attributes pty_azimuth and pty_inclination_from_vertical from Wellbore_interval and General_surface_line to Edge.
  • Move attribute (pty)descriptive_text from Wellbore_interval and Wellbore_point to Spatial_object (as replacement for description?).
  • Move attributes pty_location_1d, pty_location_2d, pty_location_3d from Earth_position_vertex, General_earth_surface_point and Wellbore_point to Vertex.
  • Move attributes pty_azimuth and pty_inclination_from_vertical from Wellbore_aligned_point and General_earth_surface_point to Vertex..
  • Move attribute composite_outline (pty_geometry_2d_ring) from General_surface_composite to  Composite_spatial_object.
  • Move the m-m relationship from Position_in_earth_model to Geologic_process to be between Spatial_object and Geologic_process. Add resolver?
  • Do NOT move ref_wellbore_point from Wellbore_point (i.e., delete it in favor of the changes to Wellbore_reference).
  • Do NOT move ref_other_earth_point from General_earth_surface_point. This semantic should be supported via Earth_surface_feature (make it non-abstract? add classification?).
  • Do NOT move Simple_spatial_object "identified by" Seismic_geometry_set. This can be represented by the "part" relationship (i.e., the spatial object represents the "intersection" of "part" of a survey with an another Earth_feature).
  • Move pty_pressure_gradient from Wellbore_interval to Material??? This is not a geometry.
  • Move pty_geologic_age and pty_geologic_age_range from Position_on_earth_surface to Material??? These are not geometries.


  • Create Earth_feature as an indirect subtype of E_and_p_data (see Locatable_object).
  • Add attributes identifier, ref_naming_system and description.
  • Make Earth_surface_feature a subtype of Earth_feature.
  • Delete attributes identifier, ref_naming_system and description.  Note that Earth_surface_feature currently has attribute identifier with ndt_long_name.
  • Move Business_associate_land_feature_role up to Earth_feature?
  • Move Earth_surface_feature_alias up to Earth_feature. See Alias.
  • Make Geologic_feature, Land_property_volume, Vertical_datum, Binset, Seismic_geometry_set and Seismic_traverse subtypes of Earth_feature. Note that this adds an identifier attribute to Land_property_volume, Reservoir_drainage_feature and Reservoir_pattern_feature.
  • Move attribute pty_geometry_ring_depth_interval from Land_property_volume to Region.
  • Delete attributes identifier and description from Seismic_feature, Geoid, Local_vertical_datum and Vertical_reference_datum.
  • Delete Rock_feature_alias. See Alias.
  • Delete attributes identifier, ref_naming_system and description from Geodetic_datum and Seismic_geometry_set.
  • Delete attributes name and ref_naming_system from Binset and Rock_feature.
  • Delete attributes name and description from Seismic_traverse.
  • Delete attribute identifier from Feature_boundary.
  • Delete attribute name from Aquifer, Pool, Reservoir and Reservoir_zone.
  • Copy all relevant properties from Material and Rock_material to Rock_feature.
  • Fix the one-to-one relationship between Rock_feature and Material_class by adding BAG[1:1] to the inverse.
  • Add Earth_feature_class (as a subtype of Classification_class) and Earth_feature_classification.
  • Delete Boundary_classification, Field_classification, Rock_fluid_feature_classification,  Seismic_geometry_classification.
  • Delete Boundary_class, Ref_field, Rock_fluid_feature_class, Seismic_geometry_class.
  • Deprecate Ref_binset_geometry_class and Ref_seismic_geometry in favor of classification.
  • Make Mineral_zone a subtype of  Earth_feature instead of just being a direct subtype of Business_object.


  • Create Earth_feature_component as a direct subtype of Earth_feature.
  • Make Seismic_line_segment a subtype of Earth_feature_component.
  • Make Pressure_measurement_datum a subtype of Earth_feature_component. Eliminate Technical_object as a direct supertype. Delete redundant attributes identifier and description. Add the mandatory attribute rock_fluid_feature to the SI.
  • Make Earth_surface_boundary a subtype of Earth_feature_component. Delete subtype General_surface_boundary but keep Legal_survey_boundary (delete identifier) and Land_property_boundary (delete identifier) as subtypes. Note that these three remaining entities will not have any non-inherited attributes.
  • Delete Earth_surface_line. Make Legal_survey_line a subtype of Earth_feature_component and delete its redundant identifier. Note that Legal_survey_line will not have any non-inherited attributes.
  • Delete Earth_point and Earth_surface_point.
  • Delete Well_suface_point in favor of a Facility being locatable using Spatial_objects.
  • Make Seismic_facility_node a subtype of Seismic_facility rather than Technical_object. Delete attributes name and description. Move the identifying "seismic_facility" relationship up to be optional on Seismic_facility.
  • Make Legal_survey_point a subtype of Earth_feature_component. Delete redundant attributes identifier and description.
  • Move attribute pty_legal_survey_location from Facility_reference_point and Well_surface_point to the "surface" subtype of Vertex.
  • Move attribute pty_water_depth from Well_surface_point to Well.
  • Modify attributes baseline_node and reference_node in Observation_definition to point to one Locatable_object.
  • Modify Local_vertical_datum.earth_point and Vertical_datum_offset.earth_point to point to one Vertex.
  • Delete Seismic_processing_vertex in favor of a Vertex which partially represents a Binset. The "cdp" numbers can be specified via a geometry which uses a Binset_coordinate_system. Note that this eliminates the "cdp" numbers as an explicit part of the identifier of the point.
  • Make Seismic_acquisition_vertex a subtype of Earth_feature_component and change its name to Seismic_acquisition_point.
  • Delete attribute node_name.
  • Consider making it abstract, deleting Ref_seismic_acquisition_vertex and adding non-abstract subtypes Seismic_station_point and Seismic_source_point. This equates Ref_seismic_acquisition_vertex to a "fixed" entity.
  • Move attribute pty_magnetic_inclination from Earth_point and Earth_surface_point to Earth_feature [not geometries].
  • Delete Earth_surface_area.
  • Move Damage_area, Land_property_parcel, Legal_survey_area and Unitized_land_parcel_area to be subtypes of Earth_surface_feature. Note that this will add an identifier to Unitized_land_parcel_area.
  • Move Map relationship from Earth_surface_area to Earth_surface_feature.
  • Do not move inner_boundary_geometry and outer_boundary_geometry properties from Earth_surface_area since they are redundant to being represented by a Face which is bound by many Rings..
  • Do not delete the LIST relationship from Legal_survey_area to Legal_survey_point.


  • Add Locatable_object as a subtype of subtype of Topological_object (this recognizes that invariant topological assertions can be made independent of any spatial representations of the object). Does anyone have a better name for this since it is not just a location which can be provided? How about Spatially_describable_object?
  • Add Facility, Material and Earth_feature as subtypes.
  • Add Graphical_element as a subtype (unless we delete this stuff).
  • Add Geoid_model as a subtype of Earth_feature. Eliminate as a direct subtype of Business_object.  Delete attribute Geoid_model.data_value (surface) and constrain the "whole" representation to one Face.
  • Do not add Data_trace as a subtype (see Grid_element_behavior).This will eliminate the current capability of locating a trace using "many" spatial objects.  This behavior appears to be redundant to Grid_element_behavior but may be attempting to capture "something else" (resolve with Cary).
  • Eliminate Technical_object as the direct supertype of Seismic_feature, Rock_feature, Feature_boundary, Cement, Binset, Bisnet_intersection, Graphical_element, Geodetic_datum, Geoid, Local_vertical_datum,Vertical_reference_datum, Seismic_acqusition_vertex and Seismic_facility_node.
  • Eliminate Business_object as the direct supertype of Seismic_geometry_set, Seismic_line_segment, Seismic_traverse, Facility, Legal_survey_line, Damage_area, Land_property_parcel, Legal_survey_area, Unitized_land_parcel_area, Land_property_volume, Land_property_boundary, Legal_survey_boundary and Legal_survey_point.
  • Allow a Locatable_object to "contain" many Spatial_objects. This would represent a "partial" spatial description with "unknown" semantics on the part unless more information is supplied (e.g., it locates something else). The relationship should be identifying on the Sparial_object. This relaces the relationships from Wellbore to Position_in_wellbore and from Binset to Seismic_processing_point.
  • Allow a Locatable_object to be "wholly located/represented" by many Spatial_objects (where each instance represents one "complete" opinion of the spatial nature of the object). The relationship should be identifying on the Spatial_object. Delete existing redundant relationships (i.e., Well.well_surface_point, Wellbore_component_facility.position_in_wellbore, Well_completion.position_in_wellbore, Material_collection_station.position_on_earth_surface[many-to-many], Rock_feature_part.earth_model_object, Other_material.position_on_earth_surface[many-to-many], Geologic_feature.position_in_earth_model, Synthetic_log_trace.position_in_earth_model, Well_log_trace.position_in_wellbore and Earth_surface_feature.position_on_earth_surface).
  • Allow a Locatable_object to be "partially located" by many Spatial_objects. This generally represents the intersection with a "contained" spatial part of another Locatable_object (add a rule to force this?). The relationship should be identifying on the Spatial_object. Add a rule which prevents a Spatial_object from representing both the "whole" opinion of something and a "part" (as opposed to "contained") opinion of something. Delete existing redundant relationships (i.e., Geologic_feature.position_on_earth_surface, Geologic_feature.position_in_wellbore, Fluid_system.position_in_wellbore[many-to-many], Local_vertical_datum.earth_point).
  • Add a rule to Vertical_datum to constrain the "whole" representation to one Face.
  • Modify Topological_relationship to eliminate the boundary_overlap attribute. Delete ref_object_intersection (specifying "empty", "equal", "inside" and "overlap") in favor of an enumeration of  the OpenGIS Named Spatial Relationship predicates ("disjoint", "touch", "cross", "in" and "overlap"). Add the OpenGIS Dimensionally Extended Nine Intersection Model (DE-9IM). The existing behavior fails with 3D objects.
  • Delete Geopolitical_association in favor of Locatable_objects having Topological_relationships
  • Delete the "is located within" standard instance value from ref_surface_feature_role in favor of Locatable_objects having a "contain" Topological_relationship. Consider deleting Well_surface_feature_role or changing it to Facility_surface_feature_involvement (or perhaps Facility_earth_feature_involvement) -OR- alternatively, delete ref_well_surface_feature_role and change the entity semantics to "subject to regulations defined for".
  • Delete the following attributes in favor of being locatable using a Spatial_object:
  • Binset_grid:  processing_outline (pty_geometry_2d_ring).
  • Core:  pty_geometry_3d_shell,  pty_geometry_3d_region,  pty_geometry_2d_face,  pty_geometry_1d_edge, pty_geometry_3d_ring , pty_geometry_3d_edge and pty_geometry_2d_ring.
  • Casing_string:  setting_depth (pty_location_1d).
  • Facility_reference_point: pty_location_1d, pty_location_2d.
  • Hole:  pty_geometry_3d_shell, pty_geometry_3d_region, pty_geometry_3d_face, pty_geometry_2d_edge, pty_geometry_2d_face, pty_geometry_3d_ring, pty_geometry_2d_ring.
  • Legal_survey_point:  pty_location_1d, pty_location_2d.
  • Point_element:  pty_locaton_2d.
  • Pressure_measurement_datum:  pty_location_1d.
  • Rock_sample:  pty_geometry_3d_face and pty_geometry_2d_edge.
  • Rock_thin_section:  pty_geometry_2d_face.
  • Seismic_acquisition_vertex:  pty_location_2d.
  • Seismic_facility_node:  pty_location_1d, pty_location_2d.
  • Seismic_geometry_set:  acqusition_outline (pty_geometry_2d_ring).

  • Miscellaneous items.


    Alias

    Since we reorganizing many hierarchies such that the identifier can now be introduced at a higher level, support Alias in a more organized manner. This proposal utilizes much of the information in the separate Proposal for handling Alias but it does not utilize multiple inheritance and it removes all distinction between reference and non-reference data (as far as alias is concerned). That is, reference data has a naming system such that an alias can be substituted for a POSC supplied standard instance value. Note that this substitution must be done with care where the physical implementation has used the string as the foreign key (e.g., ref unit of measure acronyms in the DAE).