2.4.1 WITSML Hierarchies

Topic Version	1	Published	10/16/2017	Topic Change History
For Standard	ETPW20 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).

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).