2.4.1 WITSML Hierarchies

Topic Version1Published10/16/2017
For StandardETPW20 v1.1

In pre-v2.0 versions of WITSML, all data objects (except for well) were required to be a child of a wellbore, thereby requiring a fixed hierarchy of well/wellbore/dataobject (where dataobject is an object such as log, trajectory, report, etc.) to identify an object.

In the v2.0+ WITSML design, use of Energistics identifiers means all domain data objects are now uniquely addressable in WITSML-enabled software. For more information, on hierarchies, URIs, and how they are constructed, see 5 Discovering the Content of a Store (Protocol 3: Discovery) , 4.4 Examples: Streaming Alarms, Alerts, and Annotations .

Types of Hierarchy

Support Requirements

  • Ones composed with the “top” of the hierarchy as any TLO (including the traditional well/wellbore hierarchy). For example:
  • eml://witsml20/Well(uuid)/Wellbore(uuid)
  • eml://witsml20/Log(uuid)
  • eml://witsml20/Rig(uuid)

Required. If WITSML-enabled software supports a TLO, then the software must also support related hierarchies with the object at the “top” (as shown in the left cell in this table row).