Table of Contents

Table of Figures

i. Abstract

This document describes a conceptual model, logical model, and GML/XML encoding schema for the exchange of borehole related data and especially all the elements that are positioned along a borehole trajectory. In addition, this document provides GML/XML encoding instances documents for guidance

ii. Business Value

Many domain specific communities exchange data concerning Boreholes (Wells) with their own semantics & standards. One common ground for all those communities is that most of the objects they describe are positioned underground along the trajectory of the Borehole.

Enabling access to all information about a given Borehole from multiple communities would increase its value, reduce the effort required by data users and foster data exchange. Reuse of multiple domain borehole data would enable better decision making and underground resource and environment management.

With that common goal, key authors of existing external and internally used Borehole (Well) related standards defined a common framework for such data access.

The aim of the Interoperability Experiment (IE) was to avoid the creation of yet another standard and consider pre-existing community standards as much as possible.

At least two well-known Borehole (Well) standards were produced under the OGC (GeoSciML4 & GroundWaterML 2). This IE also tried to anticipate potential changes to those standards in order for OGC to maintain consistency across its standards.

Outside the OGC standards track, there are well-established, multi-million dollars/euros/pounds systems already operational using other standards. It was therefore unlikely for the IE to design a single model that would cover all the very specific use cases these systems cover.

Within this context, this IE did not aim to design a 'Borehole' specification from scratch, but instead how to create reusable components that can be incorporated into existing standards.

iii. Keywords 1.

Summary

1.1 Subject This OGC document reports on an Interoperability Experiment aimed at creating reusable components to represent the concept of a Borehole. The concept of a drilled hole in the ground has multiple names that are more or less synonymous: Borehole, Bore, Well or Wellbore. Wells are usually restricted to a borehole used to extract something, while borehole often refers to the hole itself. Given that several communities rely on information acquired by drilling a hole in the ground, an IE was established to look at possible harmonization of some of the common concepts. One aspect of this Engineering Report (ER) is the recognition that Boreholes are features used by several geoscience and civil engineer domains and it is unlikely that one universal all-encompassing view of borehole data will satisfy all use cases. If we exclude groups interested in the engineering object itself (the borehole and everything about the methods used to drill it, its purpose and ownership), the ultimate interest in boreholes are the things they traverse.

One constant practice from all domains is to report position of observation along the borehole as a distance from some reference point, instead of using an absolute (3D) position. The IE therefore tried to narrow its scope on the geometry (the location and space of the bore) and the mechanism by which domain specific features can be positioned with regard to that geometry. This would form the core section of what could potentially be expanded in the future. Therefore, more than an exercise to define the object itself, efforts were directed on defining a useful pattern to bridge multiple domains around a shared concern.

1.2

Executive summary This document reports on an exercise involving several government organizations, private companies, and academics trying to harmonize various representations of boreholes into a common model. Boreholes are widely used in geoscience and engineering to probe and assess the underground, and all those communities (custodians, vendors, distributors, etc.) model this information differently. This heterogeneity becomes a problem when information from various sources needs to be aggregated. On the other hand, different communities use boreholes, therefore, different models are expected to address different use cases. This experiment looked at solutions to harmonize core aspects of boreholes while recognizing domain specific models. This exercise resulted in a tentative model, examples and recommendations for next steps. Those steps include the recommendation for OGC to support the creation of a Borehole Standards Working Group (SWG) to formalize the core borehole model (BoreholeML (BhML)) as an official standard.

Future work should include expanding the scope of the draft borehole model presented here and co-ordinate with ongoing OGC Geoscience standards for geology and hydrogeology to ensure that those standards can operate together. It also includes working with existing standard custodians to produce BhML-compliant version of their existing borehole standards.

Generic information describing the Borehole (who, how, when, etc.) and the other aspects that describe a Borehole (e.g. construction, monitoring, management areas, etc.) are required but were excluded from this IE. Many of these are already summarized in pre-existing models. This semantic enrichment should be undertaken by a second Borehole IE or a SWG. This report includes several XML Instance Document that conform to a draft BhML XML Schema. These are contained in the various ER Annexes as well as from the Borehole IE GitHub repository (https://github.com/opengeospatial/boreholeie/). Where appropriate, the report references the corresponding GitHub content.

Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors: Removing OCL constraint on "FromToLocation"

1.5

Future work This report documents the results of an Interoperability Experiment that looked at specific aspects of overlapping between existing borehole standards and products. The group recognized that more formal work should be undertaken by an OGC SWG. The contributors to this IE also intentionally scoped a narrow aspect of the problem in order to find a useful pattern to address similar problems as more concepts are added.

Future work should include expanding the scope of the draft borehole model presented here and co-ordinate with ongoing OGC Geoscience standards for geology and hydrogeology to ensure that those standards can operate together.

Because this report used ISO 19148 as a starting reference model and highlights the parallel between ISO19148 and boreholes, some of the classes still use names derived from 19148 (such as BoreholeEventCollection). These concept names might not resonate with communities using boreholes and future work should address appropriate naming. Specific recommendations from this IE are:

• OGC supports the creation of a Borehole SWG to formalize the core borehole model as an official standard;

• A Borehole SWG refines the model to reflect the nomenclature and concepts names used by the communities using Borehole;

• A Borehole SWG work with existing standard custodians to produce BhML compliant version of their existing borehole standards;

• The GeoScience Domain Working Group (DWG) work with data consumer to assess the usability of the BhML standard; and

• GeoScience DWG to spearhead the implementation of operational services from data providers and consuming applications.

Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The following documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

LE_Event

The LE_Event class is used to specify information about linearly located feature and attribute events. For attribute events, this information includes an event name, a value specifying an attribute value, the linear location along which the event applies, defined by linearly referenced locations along the locating or attributed feature and possibly further qualified as applying at an instant in, or during a period of, time. For feature events, a located feature of type Feature is specified in place of the attribute value [ISO 19148:2012-08]

3 3. .6 6

Linear referencing

Linear referencing is the specification of a location (4.19) relative to a linear element (4.9) as a measurement along (and optionally offset from) that element. NOTE It is an alternative to specifying a location as a two-or three-dimensional spatial position (4.22).

[ISO/TS 19148:2012-08, definition 4.10]

3 3. .7 7
Linear Referencing Method Linear referencing method is the manner in which measurements are made along (and optionally offset from) a linear element (4.9).

[ISO/TS

Trajectory

Path created by the drilling device while it progressed through the material. The geometry is usually represented by a GM_Curve (ISO 19107) centered in the middle of the Borehole. It could also be represented using a spatio-temporal object representing the progress of the drilling through time (penetration rate is an important cost estimation parameter). Most diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of [OGC 06-121r3].

Conventions

4.3

Platform-neutral and platform-specific standards This ER proposes a first version of a conceptual model adapted from ISO 19148. Naming of concepts are tentative as many communities use boreholes and have different names to refer to similar concepts.

A physical model (XSD encoding) has been produced for this IE, but is not a normative at this point.

4.4

Data dictionary tables BhML model was done using UML formalism. The model is maintained in a version controlled XMI file generated with Sparx Enterprise Architect.

In order to present the model, its description in section 9 applies the following template.

• Each class is described a dedicated section with its definition (and 'Note' when relevant);

• each attribute using this

Overview

Borehole and associated data are crucial for many domains. They are used in any domain that needs to probe the underground: geology (hydrogeology, oil and gas, mining), civil engineering (utilities, constructions, transportation) and environment (ice coring, limnology), amongst others.

A key element of boreholes is a spatial reference system that defines the trace of the borehole and the location of observations along this trace in 3D space.

In summary, a borehole dataset informs about:

a) The borehole itself, as an engineering object;

b) what is being observed at or along the borehole (otherwise called the "log"); and c) the relationship between the geometry of the borehole and the things that are observed or positioned at different locations along its trajectory.

Information in (a) fall in the realms of engineering and describe methods, techniques, ownership, schedule and other key characteristics of man-made features and the business around its realization.

Information in (b) fall in the realm of the physical world the borehole traverses and provides information to the variety of domains using boreholes: Geology, Hydrogeology, Mining, Oil and Gas, Civil Engineering, Environmental Science and other closely related overlapping domains, but yet exercised by different community of interest.

And finally (c) deals with the connection between the engineering feature and the physical world it traverses.

This Interoperability Experiment is dealing with a core model for (a) and (c) and assumes that (b) is dealt with by the relevant communities. The particular challenge of the IE is to suggest a reusable method for precise navigating in borehole space that can be utilized in different topical domains (i.e. (b)) and, possibly, used or adopted in existing and future standards.

Naturally, each domain has a slightly different concept of what a borehole represents and how it is utilized. Thus, each domain defined their views and model in different ways. The challenge of this IE is to clarify the commonalities and differences of the diverse approaches by providing a semantic umbrella linked to the pre-existing work and defining the core elements shared by all disciplines. This will provide a basis for future work (outside this IE) towards a better integration of existing standards and possibly a common approach for describing boreholes.

To this end, the Interoperability Experiment has been looking at the problem in a slightly different way than other modelling exercises (such as for groundwater (GWML) and geology (GeoSciML)). In these cases, the Standard Working Group (SWG) assumed it represented the domain it was modelling and defined it in detail until the model satisfied its pre-defined use cases. This resulted in overlapping concerns between the GWML (GW_Well and Borehole classes) and GeoSciML (Borehole class) standards. Several members of this IE also ran into a similar issue between GWML2 and HY_Feature with regard to the definition of Aquifer. The resolution mechanism of those two situations were not the same: one ended with two 'competing standards' for Borehole, while the second resulted in a debate over 'ownership' of the concept due to subtle differences in the concept meaning between the two domains.

In an attempt to avoid these issues, the Borehole IE chose a different path using a bridging approach. This helped resolve a lot of the discussions, even though the Borehole IE members are representative of many pre-existing standardization exercises on the 'Borehole' topic.

This also proved useful when it came to testing the proposed model (BhML). Every stakeholder was able to encode information about the borehole geometry along with their domain-specific features of interest using the common model and their own data standard.

A data interoperability dynamic between domains was truly created here, with proposed next steps described in the 'Future work' section.

In addition to this document, this report includes several XML Instance Documents that conform to a draft BhML XML Schema. These are contained in the various ER Annexes as well as from the Borehole IE GitHub repository (https://github.com/opengeospatial/boreholeie/). Where appropriate, the report references back to the corresponding GitHub content.

The rest of this document is organized as follows:

• section 6 introduces the IE objectives;

• section 7 describes the various use cases supporting this work;

• section 8 provides an overview of the various vocabulary needs encompassed;

• section 9 contains and explains 'BhML Core' package;

• section 10 covers how other vocabulary needs that are covered by 'BhML Core' package would go in an extension;

• section 11 is dedicated to the description and results of the various tests of 'BhML Core' that ran during the IE;

• section 12 summarizes the findings and standing issues of the IE;

• section 13 provides guidance on the recommended next steps; and

• the annexes provide comprehensive examples of 'BhML Core' model applied to wellknown Borehole related data exchange situations.

Objectives

The goals of the IE were the following:

1. Create a generic conceptual model that can be used with existing models related directly or indirectly to a borehole; and 2. have a series of useful concepts that can be used by data providers and mapped into existing models.

The tentative model should be designed to:

1. Avoid creating yet another standard, especially in this field since software vendors already have well tested and widely used models / formats. Seek a common pattern for data providers to deliver to software vendors so they can easily map to their current products).

2. Avoid reinventing existing specifications, but create a model that can harmonize with them.

Use Cases

Borehole IE participants cover a wide diversity of sub-domains directly related to the notion of Borehole.

The scoping exercise was driven by uses cases from IE participants. These use cases were collected on a GitHub wiki page (https://github.com/opengeospatial/boreholeie/wiki/Example-Use-Case-Summaries) and further detailed on individual wiki pages for each use case. This exercise drove the scoping the process but also helped the involved parties find a common ground and semantic concepts for discussion, the result of which is the proposed BhML model.

The breadth of the content of use cases illustrates the difficulty to isolate useful common elements without stepping into existing domain models (such as GeoSciML or GWML) and existing products (Energetics), or defining concepts that should be managed by other communities, while at the same time acknowledging the participants' needs as expressed in those use cases.

From the use cases we excluded from the model, but still consider the feasibility of:

• requirements that are not specific to boreholes (such as versioning, observation workflow, metadata); and

• requirements that are best addressed by other communities (geothermal, lithology, aquifer, etc.) or already addressed by an existing standard.

Excluded items were those already covered, or who should be covered by another specification or standard. The instance documents presented in this report demonstrate that most of the use cases were covered by including existing work instead of reinventing it. As such, the scoping phase was the most time consuming. The Borehole concept is so ingrained in several geoscience and engineering domains that it was difficult to define a minimal, but useful and non-trivial set of concepts.

Use case description

In the Borehole IE GitHub, each use case has a unique identifier assigned. It will be reused here in parenthesis (ex: (1) Managing national borehole databank is Borehole IE Use Case n°1) along with the URL to the UseCase description itself.

Each use case also describes its vocabulary requirements.

7.2

List of use/test cases for the BhML model

This section contains the final set of use cases that were considered.

(1) Managing national and regional borehole databank

UseCase description on BoreholeIE GitHub. Who: BGS, BoM, BRGM Context: There are national obligations for drillers to declare where, how, why they drilled a Borehole and provide the description of what they observed (log) and associated documents (construction details). For example, in France every type of Borehole (actually every hole deeper than 10 meters) is to be declared even those used in Oil & Gas (embargo periods can apply). Similarly, in Australia, any bore drilled for groundwater, mineral exploration, hydrocarbon exploration and production, or geothermal resources must be reported to various State, Territory, and/or Federal government authorities.

Requirement towards the IE:

• borehole general details

• drilling details, purpose/use

• raw logs

• site data, i.e., elevations, location, etc.

• all the information needed to curate Borehole data coming from drillers 7.2.2 (2) From raw driller log to geologist validated one UseCase description on BoreholeIE GitHub. Who: BRGM, FedUni, GSC Context: raw logs provided by drillers to their client are analyzed by geologist specialists of the area. From this 'validated' logs for the same borehole may be created.

Requirement towards the IE:

• a log = an observation • a Borehole has many logs Requirement towards the IE :

• Semantic coverage: Contain enough information to enable search about z information attached to the Borehole trajectory (lithology, samples, construction, etc.)

• Be able to position elements along the Borehole trajectory and relative to a reference. In WITSML and RESQML all localizations of "Event on which a measurement is done" along a Wellbore trajectory is grouped in a list of "Measured depth Values" along the wellbore trajectories. This is the WellBoreFrameRepresentation in RESQML.

7.3

List of complementary application use cases This section contains use cases that complement the previous ones but have not been directly used in the testing process.

(4) Geothermal Boreholes

UseCase description on BoreholeIE GitHub.

Who: BRGM, BGS Context: Geothermal probe deployment to assess subsurface heating storage capacity via Ground Thermal Response Testing (TRT) as well as construction details specific to geothermal exploitation (e.g., geothermal doublets).

Requirements towards the IE:

• 'geothermal log'

• Ground Thermal Response Testing (TRT) details Who: BRGM, GSC, UU-SE Context: Enhance discoverability of borehole data through the Web. For example, in the context of the EU EPOS research infrastructure, GeoSciML Lite BoreholeView was re-used and extended to provide Borehole summary information in order to facilitate borehole data discovery. This summary information could be considered as a vCard for the Borehole. See : https://external.opengeospatial.org/twiki_public/GeoSciMLswg/SouthamptonGsmlSwgSept2017

• JSON-LD: representation of the Borehole vCard and associated data. Reusing practices summarized in the recent OGC Environmental Linked Feature Interoperability Experiment (ELFIE) would make a lot of sense.

• For the JSON-LD context we will need a reference ontology to point to.

(12) Sharing borehole related vocabularies

UseCase description on BoreholeIE GitHub.

Who: 3DS, Geoscience Australia, GFZ Context: Various systems already have vocabularies describing boreholes and associated data.

Vocabulary should be understood either as data structure (ontology, UML model, etc.) and/or codeLists/nomenclature/etc. Establishing a registry that maintains and manages the manifold of terms, concepts and relations between the scientific communities is important Requirement towards the IE:

• the IT formalism applied should support the use case (ontologies, thesaurus) in order to properly map the semantic umbrella produced by the IE to pre-existing vocabularies (provided those are exposed accordingly etc.).

Consolidated vocabulary from Use Cases

Vocabularies required by the individual use cases were consolidated and grouped into 13 categories as shown in the figure below. The detailed consolidated vocabulary is available on the Borehole IE GitHub (https://github.com/opengeospatial/boreholeie/blob/master/vocabulary/BoreholeIE_consolidated _vocab.xlsx ).

EU EPOS Research Infrastructure conceptual model was used as a strawman to foster discussions. This model is a first attempt to conceptualize many other existing Borehole subdomain models.

Through this comprehensive list of requirements from several domains, the positioning of elements (observations, construction, samples, etc.) along the borehole trajectory was identified as a fundamental requirement for all the use cases to enable interoperability across the various sub-domains of the Borehole domain. It was agreed by the group that addressing this requirement would meet a large portion of the shared data interoperability needs.

Consequently, the IE focused on providing a generic conceptual model for positioning elements down the borehole. This is the core part of this IE report.

9.

The 'BhML Core' package 9.1 Methodology 'BhML Core' package addresses the description of the borehole geometry and the positioning of arbitrary elements along the trajectory of the hole. Several conceptual models have been used by various standards. Those build around OGC conceptual model (GeoSciML and GWML) modelled boreholes as SF_SamplingCurve. This model is also proposed informally in O&M ( ISO -19156). The divergence appears in the way features observed along the borehole are linked -what is commonly called the "log." GeoSciML (OGC 16-008) follows the model "Borehole as a 1D map," where BoreholeInterval features represent segments of a Curve (LineString). The borehole intervals are linked to the geological entity through a specification property the same way a MappedFeature is related to the geological feature it represents. GWML (16-032r2) model on the other hand follows the Coverage (a pattern also followed in earlier versions of GeoSciML) where observations (Coverage range) are organized along a 1D domain (the borehole trajectory). This pattern is also used by TimeSeriesML (albeit, the domain is time, not geometry). Note that neither pattern is imposed by O&M. Using O&M, one could merely model the borehole as a linear feature and state that this feature can be related to other features and related Observations. Observation results can be of any type, simple or complex.

In oil and gas, RESQML uses an approach where WellboreFrame positions nodes on the borehole trajectory. Information (e.g., lithology) is then attached either at a given node or between two nodes (an interval).

O&M and ISO Coverage do not address the positioning down a line. The conceptual model that discuss linear referencing is ISO 19148. The IE explored the applicability of ISO19148 to the borehole observation positioning. A first set describes the elements forming the linear feature and the coordinate system built on that feature. The core concept is the "LR_PositionExpression" that links together three elements.

• The "LR_LinearElement"; that is the linear element along which a position is expressed.

This "LR_LinearElement" can be associated either to a feature, a GM_Curve or a TP_DirectedEdge, as defined by ISO 19107, to obtain the geometry of this "LR_LinearElement."

• The "LR_LinearReferencingMethod"is the method used to establish this position.

• The "LR_Distance_Expression" defines the position value along the linear feature from an arbitrary reference which is the "LR_Referent."

The "LR_Referent" is both positioned into the linear referencing coordinate system (the location attribute) and also in another global positioning system (the position attribute). It can be used as a join between the two co-ordinate systems (see figure above). The second set covers the elements to be positioned (see Figure above). Since ISO 19148 main use case is routing, features to be positioned are modelled as Events (such as a car accident on a road), therefore located both in space and time. Spatially, an event is positioned along the linear feature at a single location or occupies an interval (AtLocation and FromToLocation respectively).

While there are obvious parallels between ISO 19148 and how borehole are modelled, ISO 19148 covers wider generic cases, such as intersecting linear features, which was considered overly complex for the simpler borehole use cases.

Therefore, while BhML is strongly inspired from ISO 19148, it does not implement it exactly.

On the other hand, some refinements, not specifically covered by 19148 were also added.

As a result, a dedicated conceptual model that reuses ISO 19148 principles and modelling patterns has been iteratively designed and tested during this IE. That is one of the main deliverables of this IE.

Developing a conceptual model of its own, it was considered more valuable to have a lightweight model. 'BhML Core' model is not reusing the following concepts from ISO 19148 as they were deemed superfluous for the particular needs of this IE.

• Linear elements are limited to Feature and Curve. Directed edges are not used in any use cases.

• We did not consider branching in borehole trajectory. Although they exist, they are easier to model as distinct trajectories (as different BoreholeEventCollection) that happen to partially overlap

• ISO 19148 allows each Event of have their own Distance expression (and therefore, their own referent) and their own LinearReferencingMethod. In the context of a borehole, we normally use a single referent. The conceptual model is adjusted to only allow a single referent

• LE_Event is simplified by removing LE_EventTime. Time-dependent features reported along the trajectory are expected to be modelled as OM_Observation, which carry their own time properties.

'BhML Core' package is:

• introducing a semantic that is closer to the Borehole domain terminology (for example LR_PositionExpression being renamed into BoreholeLRS for 'Linear Referencing System');

• restricting some ISO 19148 patterns, for example when 'forcing' a BoreholeEventCollection to only have one BoreholeLRS thus one Referent (whereas ISO 19148 allows each 'Event' to redefine its Referent;

• providing slights adjustments to ISO 19148 model (ex: 'units' in LR_LinearReferencingMethod renamed into 'unit' in BoreholeReferencingMethod);

• adding the possibility to position an 'Event' with regards to another Event which is a slight adaptation of the ISO 19148; and

• allowing to link to standards that are not Features as modelled in ISO19109, hence widening to any types.

In order to help remember from which ISO 19148 class a BhML one was inspired, notes were added to the definitions (e.g. in 'BoreholeEvent' definition Note: this class is an adaptation of ISO 19148 LE_Event (see ISO 19148 Figure 44). BhML class diagrams also mimic ISO 19148 layout as much as possible.

The XMI, .eap file and corresponding HTML documentation are available on the GitHub: https://github.com/opengeospatial/boreholeie/tree/master/model.

9.2

Mapping of ISO-19148 to 'BhML Core'

Theory

The following figures describe the way 'BhML Core' package positions things along Borehole trajectory. Various support materials are available from the IE meetings and are on the BoreholeIE GitHub. Drawings below are extracted from the following document (https://github.com/opengeospatial/boreholeie/blob/master/vocabulary/LinearReferencing.pptx) which contains more, explaining BhML with regards to other Borehole related elements (Samples, etc.).

In the 'BhML Core' model each element located in the borehole (e.g., observations, construction elements, etc.) is named as a 'BoreholeEvent.' This is consistent with the ISO 19148 semantics which uses the term 'Event.' ISO-19148 defines the concept of "Event", as a description of something happening along a linear network. The common example is an incident on a road, at a certain distance from an intersection. The model applies to borehole, replacing an incident which some element of interest for a geologist, an engineer, etc. at some distance from the beginning of the bore.

Thus, further building on the ISO 19148 semantics, 'boreholeEventLocation' is defined as the property along a borehole/well 'BoreholeTrajectory' with regards to a 'TrajectoryReferent.' The following figure maps this concept to a geologic log (we kept the same color code). The first one shows that both the 'TrajectoryReferent' and the 'BoreholeTrajectory' can be either described by a geometry or by a full Feature having its own geometry description.

It also shows that each 'attached' element can be described either in-line or by reference using URIs.

Figure 6: 'BhML Core' applied to geological Log step 1

The second one shows how domain features are located as a BoreholeEvent along the borehole.

TrajectoryReferent and BoreholeReferencingMethod

The referent is a key feature in the model that links the location of a feature in real world coordinates to the 1D linear coordinate system of the trajectory.

Several elements must be considered to understand the role of the TrajectoryReferent (ISO 19148):

• The TrajectoryReferent can be located anywhere on the BoreholeTrajectory; and

• The TrajectoryReferent can be any feature that is considered an observable reference to pin a known location along the Borehole trajectory and position the other elements relative to this feature. The BoreholeReferencingMethod defines:

○ whether the distanceAlong the BoreholeTrajectory is relative to the TrajectoryReferent or absolute by reference to the first point in the BoreholeTrajectory; and ○ the orientation in which the linear referencing systems operates (e.g., positive upwards, positive downwards).

For example, in the following figure, the TrajectoryReferent is the 'Top of Casing' and the BoreholeReferencingMethod is relative to the TrajectoryReferent and positive going downwards. The distanceAlong can then be unambiguously inferred for the elements positioned along the trajectory. An XML version of that theoretical example is provided in Annex A. Note that this example does not specify the direction 'positive going downward' as this is one limitation of the current BoreholeReferencingMethod. This limitation identified by the group is described in a GitHub issue and already added to the future work.

Conceptual model 'BhML

BoreholeEvent

A Class used to specify the position (location) of an element (locatedMember) along the borehole trajectory. The locatedMember can correspond to observations, construction elements, etc.

A BoreholeEvent corresponds to any valuable domain information observed along the trajectory of the bore. The concept of an Event is consistent with Observations and Measurements (ISO-19156) which models the act of observing and measuring as events, with methods, subjects, and time. Communities using borehole rarely speak of observations along a borehole as "Event", but the term "log" suggests a similar concept.

ISO-19148 defines its own concept of "Event," as a description of something happening along a linear network. The common example is an incident on a road, at a certain distance from an intersection. The model applies to borehole, replacing an incident which some element of interest for a geologist, an engineer, etc. at some distance from the beginning of the bore.

Note: this class is an adaptation of ISO 19148

BoreholeEventLocation

Specifies the distance of an event along the borehole trajectory.

A BoreholeEventLocation describes the position of a BoreholeEvent along a borehole as the distance from an origin location specified in the BoreholeLRS (Borehole Linear Reference System). The location can either be a single location (a point) or an interval, composed of a "from" and a "to" location, defining the boundaries of the interval. BhML considers the borehole trajectory going "from" an origin "to" some distance along the trajectory; therefore "from" is by definition closer to the origin, and "to" further.

BoreholeTrajectory

The linear geometry or feature (the trajectory) representing the centerline of the drilled hole, along which the distance is measured. The measurement method is described by the Borehole Linear Referencing System.

It can express either the trajectory directly with a GM_Curve geometry or an existing feature having such shape. The latter reuse existing Borehole features, or any feature that displays a linear shape suitable to represent a borehole trajectory. For instance, alternative ways to describe the underground location of the trajectory, such as a collection of tropari measurements or a spatio-temporal geometry describing the location and time of the drilling operation as the drill head progresses in the ground.

Because the BoreholeTrajectory may be a geometry or a feature containing a geometry it is modelled as a Union class.

Note: this class is an adaptation of ISO 19148 LR_LinearElement.

Attribute Type and Multiplicity Definition

DistanceExpression

Expresses a distance along the BoreholeTrajectory. Not all referents are necessarily located at the origin of a Borehole Trajectory. The referent is a real-world feature (natural or artificial) designated as the reference point. This feature can be designated at the origin of the reference system (the zero) or located itself using another reference system (such as an external height datum like 'sea level') and therefore be different from zero.

Note: this class is adaptation of ISO 19148 LR_DistanceExpression.

Attribute Type and Multiplicity Definition

distanceAlong Measure A measure (usually a distance) of this distance expression (maps to ISO 19148 distanceAlong).

MeasureOrEvent

A position can be expressed using an explicit distance or be referring to another located feature, hence expressing that a feature is semantically at the same location by design (and not by coincidence). There are several cases when this design is appropriate: For example, Geologic units (intervals down the borehole) delimited by geologic contacts, with multiple interpretations using the same contacts.

Because MeasureOrEvent may be a geometry or another located feature, it is modeled as a Union class.

Note: this class is an adaptation of ISO 19148 LE_AtLocation and LE_FromToLocation pattern in which the properties are not LR_DistanceExpression but either distanceAlong or reference to a boreholeEvent.

Attribute Type and Multiplicity Definition boreholeEvent

BoreholeEvent

The event used to express the position (ex: a lithostratigraphic unit interval pointing to a geological contact).

distanceAlong Measure Measure (usually a distance) done according to the BoreholeReferencingMethod. 9.3.12 9.

3.L TrajectoryReferent

The referent provides the link between the 3D world and the 1D view (the linear referencing system). Depending on the BoreholeReferencingMethod, it may be the "zero" of the positioning within the BoreholeLRS.

The referent can either be a well-known feature (e.g., BoreholeCollar) described with the corresponding semantics or a coordinate (point geometry).

Note: this class is an adaptation of LR_Referent.

Constraint:

•

AccuracyStatementType

Term describing an accuracy statement from a registry of accuracy description vocabulary.

PrecisionStatementType

Term describing a reference statement from a registry of precision description vocabulary.

UnitOfMeasureType

Term describing a unit of measurement from a unit of measurement registry (e.g. QUDT, UCUM, etc.).

Logical Model

The conceptual model was translated to a UML logical feature model GML profile in order to create a GML Application schema. This step is needed to create testable, by schema validation, instances using XML. The model is essentially the same as the conceptual model, but modelled as GML features.

No specific extra rules were applied.

The Logical model is presented in the following figures.

«CodeList» UnitfOfMeasureTypeTerm «CodeList» AccuracyStatementTypeTerm «CodeList» PrecisionStatementTypeTerm
The ShapeChange configuration used is available in GitHub: https://github.com/sgrellet/boreholeie/tree/master/shapechange_conf Some aspects of XSD generation from the Logical model have been subject of discussions between the IE members. Some deemed not crucial for the semantics of BhML model were described but not corrected to avoid derailing the IE timeline. As a result, they are tracked in the Borehole IE GitHub for further uptake by a SWG.

'BhML Extension' package

This document proposes the seeds of a core package centered on a spatial model and a pattern to link to existing geoscience/engineering domains. Several other aspects of borehole are of interest and should eventually be addressed.

This ER does not propose a specification, but reports on an experiment driven by the need to look into the issue of a specification that overlap multiple existing models.

The formalization of the recommendations of this ER should be carried by a SWG and as further requirements emerge, more packages developed from the 'BhML Core' package.

In order to foster discussion during the scoping phase, 'BhML Extension' was bootstrapped from EPOS conceptual model. This and the testing phase helped identify the need for potential additional classes that may go into an 'Extension' package.

For example, there is a need for generic information describing the Borehole (who, how, when, etc.) and also the other aspects that describe a Borehole (Construction, monitoring, management areas, etc.). Many of these are already summarized in pre-existing models such as GeoSciML, GWML2, several INSPIRE data specifications, the EU EPOS Borehole conceptual model, BoreholeML and RESQML. This semantic enrichment should be undertaken by a second Borehole IE or a SWG. In order to ease this uptake, all the Github issues that covered that topic were tagged accordingly in the Borehole IE GitHub repository.

Testing

Methodology

One key aspect of this work was to reuse as much as possible existing standards. BhML core should be as neutral as possible and provide a framework to position features from various domains along a borehole trajectory. Therefore, this ER does not address domain specific information.

The core requirement class is limited to:

1. Positioning the trajectory of the borehole in space; 2. Identify a reference point in a 3D space and its equivalent relative position in 1D; 3. Provide a relative positioning along the trajectory defined in 1D for arbitrary data elements.

Several of the existing standards or encodings use XML and therefore XML encoding was chosen for testing and demonstration. Choosing XML does not imply it is preferred over any other encoding. Reusability means different things for different encoding. UML and XSD are fixed and rely on class specialization for extension. OWL (RDFS) works differently: "schema" is more a tool for inference than validation (albeit the inference engine could signal inconsistencies). An inference engine can conclude an instance is of a specific type by applying the rule identified in OWL/RDFS, while XSD will flag unexpected use of the association as an error. Finally, some encodings have loose validation rules that depend on the context -from "duck typing" to application specific rules.

This ER uses the UML->XSD (ISO 19139) route to create XSD schemas that can be used testing with instance document. Instance documents presented in this ER are validated against that schema. Another scenario, described below, extends that schema and adds domain specific elements to demonstrate an alternative use. Other encodings will use other conformance rules. XML encoding as per ISO 19136 uses XSD.

The testing was done through the creation of instance documents and comprises 2 main scenarios.

A. Use case where elements from existing XML standards (domain specific) need to be located in a borehole. They are called "without dependency" because there are no schema level dependencies between BhML and the domain schema.

B. Use case where the core is extended by a community to create a new standard (a "MyBorehole" class derived from BhML Borehole). By creating a direct dependency to BhML, they are named "with dependency."

Participants created instances documents using either approaches. Those who created instances using both ended up with very similar instances. The first one can readily cover simple cases without the need to create a new schema, and the second is more semantically rigorous because the community can adapt the core concept to fit their requirements.

A variation of the "Without dependency" scenario was also tested using SWE encoding (Sensor Web Enablement 08-094r1), which provides a compact encoding using data structure.

All the examples more or less follow that same structure described in sections 11.1.1, 11.1.2 and 11.1.3.

The testing phase started really soon along the modelling exercise to enable refining BhML models (and corresponding xsd schema) iteratively. During the IE, GitHub issues were created to support the conceptual model exercise (to document and keep track of decisions), the writing of the ER and to identify future work. All are documented and organized in a GitHub project (https://github.com/opengeospatial/boreholeie/projects/1).

To ease presentation, only XML snippets supporting the chapter they are located in are provided.

The complete XML instances are provided on the Borehole IE GitHub.

Only 3 comprehensive instance examples are provided in annex to highlight how specific Borehole features can be exposed using BhML model:

• Observation log (+events as location and samples) -> NRCan;

• Drillers log (three encoding options); and

• Construction log -> CERDI. <gml:description>Complex example made of units constructed from reused contacts and samples. This borehole is an encoding of a example described in Boisvert & Michaud, 1998</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/id/waterwell s/unbounded.1</gml:identifier> <gml:name codeSpace="urn:gin">demo</gml:name> (...) <BhML:collectionLRS> <BhML:BoreholeLRS gml:id="LRS1"> <gml:description>The reference is an arbitrary point on the ground at the top of the borehole. Because it's also the beginning of the linear element, it's both, providing no trajectoryReferent would also be valid by using "absolute" Referencing method</gml:description> <gml:name>ground</gml:name> A full example is available in GitHub (https://github.com/opengeospatial/boreholeie/blob/master/instances/NRCan/GSC_BoisvertMich aud.xml).

A caveat of this encoding is that BhML:Borehole itself does not have any properties to carry domain specific values (such as the owner, the drilling method, etc.). This aspect has been clearly described in a corresponding GitHub issue and is part of proposed future work.

The encoding of the Union (BhML:MeasureOrEvent) would also require rework, solutions are already identified in the corresponding GitHub issue for future work.

Another implementation of the 'Without Dependency' approach is the route taken for RESQML related testing (see section 11.6). 'Semantic' mapping is done between BhML and RESQML models. As equivalences are found between both, it is possible to transfer (e.g., by using XSLT) instances from one model to the other without destroying information.

With dependency

With dependency requires the community to create a dependency with BhML by subtyping BhML:Borehole (or any BhML types).

Figure 15: With dependency reuse of 'BhML Core' example

The instance is essentially the same as in the previous section (except for the subtyped classes). The benefit of this option is to add domain specific properties and potentially alter constraints.

Without Dependency variation using SWE encoding

This approach is a variation of the "Without Dependency" one. SWE Common encoding (OGC 08-094r1) provides an alternative representation for datasets (as opposed to domain model). It is more suitable, and more compact, to encode large collection of results.

The elements of interest are the SWE mappings to properties in the BhML model. <swe:field name="from"> <swe:Quantity definition="https://www.opengis.net/def/BoreholeML/FromToLocation/from"> <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m" xlink:title="m"/> </swe:Quantity> </swe:field> <swe:field name="to"> <swe:Quantity definition="https://www.opengis.net/def/BoreholeML/FromToLocation/to"> <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m" xlink:title="m"/> </swe:Quantity> </swe:field> A more comprehensive example is provided in annex C.

EPOS COSC Sample

The European Plate Observing System (EPOS) is a research infrastructure gathering many domains in observing the solid earth.

One of these domains covers geological information and modeling. Amongst many features, it serves the description of boreholes and associated data according to a conceptual model that is part of the reference material of this IE.

At the time the EPOS conceptual model was turned into a logical model and xsd were generated, the Borehole IE was not initiated. Mapping were produced to map this Borehole conceptual model to O&M, GeoSciML, GWML2, and BoreholeML. None were fully successful. Then, an ad hoc logical model was generated according to OGC GFM, specializing O&M and linking as much as possible to pre-existing standards such as GWML2. An xsd schema was generated using ShapeChange.

University of Uppsala (UU-SE) maintains WFS services to serve IODP, ICDP data according to EPOS borehole model (and XSD under eposb namespace). Instances served by this endpoint have been used as a basis for testing the BhML model especially on the location of the samples and the description of Boreholes Segments.

The following XML snippet shows an example of how eposb:Sample (O&M Specimen) could be localized along a BoreholeTrajectory using BhML model. The full XML instances are available on the GitHub: https://github.com/opengeospatial/boreholeie/tree/master/instances/EPOS_COSC. This test on eposb:sample and on eposb:segment, shows that the EPOS conceptual and logical models can be easily adapted using the BhML 'Core' package. EPOS Borehole model is also enforcing the reuse of GWML2 model for Geology logs (which is covered by other tests in this section 11). Provided GWML2 also evolves taking into account the BhML model, it will be easy for the EPOS Borehole model to benefit from the proposed developments of BhML. This provides new useful ways for exchanging the position of elements along the Borehole Trajectory.

Geological Survey of Canada (Natural Resources Canada)

GSC tested test cases n°2 "From raw driller log to geologist validated one" and 6 "Generic positioning of features on a borehole coordinate system" in particular, although it also has interest in all the use cases explored in the IE.

Because GSC has been involved in two OGC standards that included Boreholes (GeoSciML 16-008) and GWML (16-032), it was exposed to the complexity of overlapping domains. The GSC, through its Groundwater Information Network, maintains a WFS 2.0 service (https://gin.geosciences.ca/GinService/wfs/cache?REQUEST=GetCapabilities&AcceptsVersion =2.0.0&SERVICE=WFS) but does not for the moment deliver encoding in BhML. Also, the database does not provide examples of the use case n°2 (delivery of multiple reinterpreted logs). GWML model allows multiple logs, but does not provide the level of flexibility BhML offers. For this reason, the GSC encoded an example used in a late 1990 publication that proposed a topological model for borehole -also based on a conceptual model used for route network -called dynamic segmentation, from ESRI products -which is essentially the topic of ISO 19148.

The test was done by encoding all the elements presented in the main figure of the paper (Figure 16).

Figure 16: Boisvert Michaud core image used as a basis for NRCan test

This figure encompasses all the key elements to be tested in BhML. A series of point elements (contacts) labeled "Discontinuities" in this figure, 3 logs presenting 3 different interpretations, and locations of samples (on the left). The borehole is therefore composed of elements from O&M (samples and Observations for water levels in contact log), GeoSciML (contact, geologic units) and GWML (Hydrogeologic unit). The encoding used the "Without Dependency" pattern and created 5 BoreholeEventCollections:

• Contact and other discontinuities (top, bottom, water levels);

• Geologic units for lithologic log;

• Geologic units for lithostratigraphic log; Making corrections to contact locations also propagate to all units by design, and it is also possible to manage any number of contacts without creating multiple small units of the same nature.

Samples are encoded using distance boundaries (as they are not tied semantically to contact locations). This use case is largely based on the availability of well-established and domain-controlled vocabularies as well as on the fact that any borehole information makes use of it (Use Case 12: Sharing borehole related vocabularies). All parameters for the correlation of borehole and model information should be encoded in a way that they can be identified and addressed in an interoperable way. Thus, it is essential to establish a common vocabulary that specify the terms which are needed to identify the desired information across system and domain boundaries. A geologist, for example, is interested in boreholes that have reached a horizon of a certain age. According information is often encoded via the term "Last Horizon", which, however, is not common among all of the various communities within the various drilling domains.

The full XML instances are available on the GitHub: https://github.com/opengeospatial/boreholeie/tree/master/instances/GermanStateGeologicalSurve ys_BoreholeML.

With Dependency

This approach is illustrated in the following example: encoding a groundwater observation based on the Borehole Markup Language (BML). Disambiguation note: in section 11.4 snippets contains namespace prefix that are close to one another are used:

• 'BhML' that corresponds to the XSD generated during the Borehole IE and based on the model defined during this IE; and

• 'bml' that corresponds to Borehole Markup Language -BoreholeML, common exchange format for borehole data in Germany used by federal and regional authorities, universities and other research facilities. The "with dependency" approach is achieved with the substitution of abstract BhML elements and restricting the according complex types (e.g., BoreholeEventType) with the specific BML extensions of the BhML complex types (e.g., LocatedMemberType). Since BML is largely based on Simple Features, according data can be parsed without "knowing" the underlying schema. However, more complex encodings (e.g., lithology logs) require the according schema to be present. An example is available on GitHub.(https://github.com/opengeospatial/boreholeie/blob/master/instances/GermanStateGeolo gicalSurveys_BoreholeML/BoreholeWithMoreDependencies-0.3.xml ).

The details of the substitution mechanics and according schema types are shown in annex D.

Although a valid XML-Schema mechanism, this approach does not conform to the OGC approach (Not substituting properties).

Without Dependency

This solution does not differ significantly from the "with dependency" approach instead of a more "loosely coupling" of the encodings. As already stated in the Methodology section, the benefit of the "with dependency" approach is "to add domain specific properties and potentially alter constraints."

BML Groundwater Observation are easily added into BhML compliant structure. A 'without dependency' variation using SWE is also available in annex E.

Conclusions

The main focus of BhML lies on the integration of heterogeneous encodings based on an implementation of a specification that covers all facets of referencing boreholes and borehole measurements (ISO 19148, Linear Referencing). By adapting this specification, the main problem has been solved, which is correlating geographically referenced information from various borehole representations. This IE, with the BhML model, has made a decisive contribution to ensuring that borehole information from various heterogeneous domains can be clearly referenced geographically.

Tests concerning the focus above have been run based on the Java API for XML Binding. All encodings, available on GitHub have been parsed accordingly. The tests utilize Java classes that have been compiled from XML Schemas.

From the different patterns available to test BhML model, the GFZ definitely prefers the SWE encoding. Among many others, SWE, both SensorML and Observations & Measurements, offer the following main advantages:

• Balanced mix of well-known structural elements (e.g., DataRecord) and flexible key/value pairs that are based on domain-driven vocabularies;

• Comprehensive, yet compact and performant description of data;

• Well-suited for hierarchical data (Composite Pattern), see Lithology Interval example;

• Interoperability to the greatest possible extent based on a domain-agnostic approach; and

• Domain-specific encoding is based on controlled vocabularies.

Also, the acceptance of SWE is steadily growing. Software for transforming various encodings into each other and into SWE is ready for productive use.

To push the IE exercise further and inline with use case n°12, the GFZ has also run usability tests on retrieving borehole measurements information from the various encodings. The scenario deals with the correlation of lithology information available from various domains, and systems with different encodings such as BML, SWE, GeoSciML or GWML2. And more precisely, how those various encodings declare references to registers of codeLists (URI; labels, …). Summarizing: all encodings largely differ from each other in this matter which hinders streamlined search for data.

FedUni (CeRDI)

11.5.1 Methodology CeRDI at Federation University (FedUni) maintains an OGC WFS delivering groundwater borehole data using the OGC GWML2 standard (http://services.cerdi.edu.au:8080/geoserver/wfs?request=GetCapabilities). As part of the Borehole IE, FedUni compared data being delivered by the current service to delivering the same data using the logical model developed as part of the IE.

The testing was carried out by handcrafting xml instance documents using the BhML schema to encode example data from the FedUni GWML2 service. The pattern uses the "Without Dependency" pattern (i.e., no changes to the GWML2 schema were made) described above.

Two examples are provided: one covering construction details and the other alternative ways to encode lithology logs.

The first (CeRDI_BhML_Borehole-26654.xml) contains encodings for:

• a reference elevation (http://www.opengis.net/gwmlwell/2.2:gwWellReferenceElevation);

• a Screen (http://www.opengis.net/gwml-wellconstruction/2.2:Screen ); and

• two Filters at the same from-to depth (http://www.opengis.net/gwmlwellconstruction/2.2:FiltrationComponent ).

The second example (CeRDI_BhML_GW_Well-26654.xml) contains three different encodings of non-standard vocabulary lithology values (driller's logs).

• Defining the geological contact reference points using GeoSciML4 (http://www.opengis.net/gsml/4.1/GeoSciML-Basic:Contact ) and specifying the lithologies (http://www.opengis.net/gsml/4.1/GeoSciML-Basic:GeologicUnit ) between them:

○ Issues with this encoding were that not all the boundaries between the lithology values could be considered true GeoSciML:Contacts (e.g.; top and bottom of well); and ○ The encoding is extremely verbose. Although only a short well example with 16 "units" this requires specifying all the contacts and then all the units for each pair of contacts (only 2 lithologies are included in the example).

• Describing a GWML2 coverage (http://www.opengis.net/gwmlwell/2.2:GW_GeologyLogCoverage) and the location of its start and end: ○ This encoding avoids the 'Contact' problem of the previous encoding, but retains the original GWML2 verbosity.

• A compact SWE data array encoding using a GWML2 GeologyLog (http://www.opengis.net/gwml-well/2.2:GW_GeologyLog):

○ Although a compact encoding it results in the whole lithology log being one BhML:BoreholeEvent.

The full XML instances are available on the GitHub: https://github.com/opengeospatial/boreholeie/tree/master/instances/CeRDI

Encoding of Tests on Lithology logs

Three examples are shown of encoding geology logs. The detailed content is available in annex F.

Geology log by specifying contacts and content separately

This follows the NRCan example by defining the geological contact reference points using GeoSciML4 (http://www.opengis.net/gsml/4.1/GeoSciML-Basic:Contact) and specifying the lithologies (http://www.opengis.net/gsml/4.1/GeoSciML-Basic:GeologicUnit) between them.

<!---######################## CONTACTS ############################--> <!--
<!---############ LITHOLOGY RELATED TO CONTACTS ###########--> <!--

Geology log by describing a GWML2 geology log coverage

(http://www.opengis.net/gwml-well/2.2:GW_GeologyLogCoverage) and the location of its start and end.

<!---############# LITHOLOGY ENCODING USING GWML #################--> <!--In

Geology log by specifying a GWML2 geology log

A compact SWE data array encoding. No encoding was identified for the following GWML2 borehole "metadata" properties:

<--############### LITHOLOGY ENCODING USING swe array ##################--> <!--
• <http://www.opengis.net/gwml-well/2.2:gwWellPurpose> • <http://www.opengis.net/gwml-well/2.2:gwWellWaterUse/> • <http://www.opengis.net/gwml-well/2.2:gwWellYield/> • <http://www.opengis.net/gwml-wellconstruction/2.2:bholeDateOfDrilling/>

Data in GWML2 not directly encoded in BhML

GWML2 has specific properties to specify the borehole total length, start and end depths, and reference elevations.

Borehole total length

GWML2 encodes the total length of the borehole using the gwTotalLength property: <http://www.opengis.net/gwml-well/2.2:gwWellTotalLength> <swe:Quantity> <swe:uom code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>11.68</swe:value> No single BhML property specifies the borehole length. Instead information about the well total length is incorporated into the BoreholeLRS property as a gml:posList. This requires a client to process the <posList> information to determine the borehole's length: No single-purpose BhML property specifies the type of borehole reference elevation. This has been described in GitHub for future work.

…

Borehole constructed depth

GWML2 has a specific property to capture the constructed depth of the borehole (gwml2w:gwWellConstructedDepth). In GWML2 this is either an http://www.opengis.net/om/2.0:OM_Observation or a http://www.opengis.net/gwmlwell/2.2:GW_GeologyLog.

In BhML this can be captured as a BoreholeEvent with a FromToLocation:

GWML2 borehole construction details

GWML2 specifies a number of elements to capture the borehole construction features, such as Screen, Filtration, Casing, Sealing. These can be directly encoded in BhML as BoreholeEvents.

The detailed content is available in annex G.

Redundant GWML2 data

GWML2 allows specifying the from-to depth of the borehole construction material (Casing, Screen, Filtration, Sealing). Using BhML:location to capture the from-to depth makes this redundant.

RESQML and Energistics standards

Use case 16 target is to be able to generate valid RESQML content from BhML compliant instances to feed RESQML capable tools and vice versa.

Test is done on GSC_BoisvertMichaud.xml file provided by NRCan according to BhML (https://github.com/opengeospatial/boreholeie/tree/master/instances/NRCan).

The full .epc and .h5 files generated after the mapping are available on the Borehole IE Github: https://github.com/opengeospatial/boreholeie/tree/master/instances/RESQML 11.6.1 Semantic mapping The mapping done between RESQML and BhML semantics is described below. RESQML object are identified within RESQML "FIRP" structure or Feature/Interpretation/Representation/Property structure.

The complete mapping structure and more background information on RESQML to understand the mapping philosophy are provided in annex H.

The RESQML Well Bore object is the : <BhML:BoreholeLRS gml:id="LRS1">.

The RESQML Well Bore Interpretation has no explicit management in the BhML structure but we could find several Interpretations in GSC example: Discontinuities, Litho, LithoStrati and Hydrogeology which could be realized at different steps in the life cycle and concerns the same WellBore. In this example we could associate Discontinuities, Litho, LithoStrati into one representation only, the WellBoreInterpretation named GSC lithology on which were regrouped: <BhML:BoreholeEventCollection gml:id="contact.1">, <BhML:BoreholeEventCollection gml:id="litho1">, <BhML:BoreholeEventCollection gml:id="surf1"> to build only one WellBoreFrameRepresentation named BhML : Borehole-Event_Collection_of lithology.

For Hydrogeology, the RESQML WellboreInterpretation is named: GSC Hydrogeology and the corresponding location information of the <BhML:BoreholeEventCollection gml:id="hydrogeo1"> is used to build another WellBoreFrameRepresentation named BhML:Borehole-Event_collection_for_Hydrogeology.

Inside each <BhML:BoreholeEventCollection the location of each Event can be found separately using the distance along the Well trajectory (first 3 values extracted from the litho and lithostratigraphy example): <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">3.2</BhML:distanceAlong> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">4.5</BhML:distanceAlong> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">4.9</BhML:distanceAlong> This distanceAlong is attached to the RESQML/WellBoreFrameRepresentation on which the Quantity Class and the Uom are defined once.

Then, for each of this point, the topology corresponds to a topological list of "Nodes" which can be also used as a topological list of "IntervalEdges". On these topological Nodes RESQML is adding One Geometry and this information is recorded into an hdf5 dataset as MdValues (note that the hdf5 group path uses the same UUID than the DataObject and, then, ensure the link between the content of an epc and a hdf5 file). The RESQML WellBoreTrajectory is a DataObject which can be shared by several WelBoreFrameRepresentation because the "distances along" could be different whether the WellBore markers are tracked or if Logging operation with a specific sampling rate are being executed. This is the reason why this specific DataObject is independent and linked with a description of the Datum (x,y,z and 3D Local CRS of the beginning of the WellBore trajectory), the Deviation Survey on which the location of measurement stations of Md, azimuth and declination are given or the geometry of the trajectory.

To attach wellLogInformation, in RESQML ContinuousProperties or DiscreteProperty values are associated to the Nodes or interval edges of the WellboreFrame Representation. These properties are defined by a specific Catalog of Property Kind attached to their Quantity Class of Uom (Units of measure) which are part of each.

To attach Information about known samples or limits (discontinuities), RESQML associates CommentProperty containing for each node or Interval edge a String with an UUID if the relation is established with another DataObject defined in RESQML or by an URI or URL if the information is contained elsewhere. This method is applied to link the WellboreFrameRepresentation nodes with the UUIDs of HorizonInterpretation DataObjects. This method is also applied to link some of the Interval Edges WellboreFrameRepresentation to the URI on which we can find their description.

To attach Information about Local or universal semantic description in RESQML CateoricalProperty can be used. The same approach is used to describe lithology, lithostratigraphy, and Hydrogeology proposed in the example. These categorical properties can be defined for a whole set of Wellbores in a StringTablelookup. For each Property a specific table, based on the list of the WellBoreFrame Representation Interval Edges associates these look up table to every WellBoreFrameRepresentation.

The figure below provides an example of such table for litho units: StringTableLook up and MdValues + lithoUnits tables created in RESQML. This IE was restricted to a small, but relevant, subset of use cases. Often when trying to improve interoperability the first task is to build a new model, creating a single artefact to stand for multiple representations of the same concept from existing "competing" models. The scoping exercise showed that a significant portion of the use cases provided by IE participant overlapped with a wide swath of geoscience and engineering domains. With this in mind, the IE attempted a reusability pattern where a borehole would be "domain agnostic" and allow existing communities to maintain their concepts and vocabulary. This implied that BhML would be stripped of any domain specific properties and concentrate on essential "boreholeness."

A common element to all domains using boreholes is the unique linear positioning system. This aspect was an obvious shared concern amongst the disciplines represented in the IE. Examination of the use cases collected in the early phase of the IE supported this conclusion.

Narrowing the experiment to the positioning of domain specific entities along a borehole has the benefits of:

• keeping the problem tractable by removing domain specific concerns;

• leveraging on an existing body of work (ISO-19148); and

• allowing to quickly assess its suitability because existing models could be used directly.

All participants who contributed instances could relatively easily represent their own domain into the proposed patterns. The ISO-19148 conceptual model fitted much of the positioning use cases with minor adaptation, mostly simplifications. The delimitation between "positioning" concepts and domain specific concepts did not pose any major difficulties. Most of the difficulties came adapting ISO-19148 to the borehole context. Members of the IE were strongly biased toward geosciences (geology and hydrogeology), but because of the very nature of the model, any domain using boreholes can be accommodated.

There are still shortcomings, room for improvements and potential for more areas of normalization. This section attempts to identify likely impacts on those standards the borehole model presented here is likely to have.

Standing issues

OGC (GeoSciML and GWML)

This interoperability experiment resulted from a concern expressed by members of the GeoSciML and GWML SWG confronted with two similar but distinct models for Borehole. The rational to have two standards was then justified because they addressed different domains.

There was interest from both groups to explore ways to address this particular situation and other cases of overlap between domains.

Both GeoSciML and GWML are designed in such a way that their core model does not have any direct dependencies with their respective Borehole model. Therefore, alternative borehole encoding won't affect the core concepts of either GeoSciML or GWML. An eventual BhML standard could then be used without any change to existing models. But because BhML tries to be agnostic, those communities may tailor BhML for their own use. Preferably this would be done in a way that maintains the BhML core package so that interoperability between domains is possible. Because of the absence of dependency between the GeoSciML and GWML borehole packages and their core packages, this adapted model should be able to be designed without change to existing models.

Under this scenario, GeoSciML and GWML SWG could publish standalone borehole extensions while both use the same BhML core package.

Borehole ML

As mentioned before, Sensor Web Enablement (SWE) shows steadily growing influence on the various scientific communities and governmental authorities. It is for this reason that at least BoreholeML (BML) is going to be migrated completely to SWE. BML's maintaining groups, the State Geological Surveys of Germany also provide already largely elaborated vocabularies, which can be integrated seamlessly. Although the GFZ only can assess an according development based on the experiences with BML, is it is likely that all external standards will at least adapt the principles of SWE (if not happened already). Something that absolutely must be achieved, is the strict separation of structure, content and semantics as well as avoiding the flurry of different encodings for one and the same facet of a borehole.

BhML providing a domain agnostic mechanism will help reduce redundancy in standards.

12.3.3 RESQML RESQML for the time being can integrate some links to official sites or regulatory offices in a string format from Comment Properties attached to nodes along the trajectories or along Interval Edges. But this linkage is not actually explicit enough and could be better described using URIs or well-defined URL or part of a specific catalog on which their syntax should be constrained to access well known and referenced URL (as we can find in the BhML document).

In order to gather BhML represented information on BoreHoles and use it for petroleum or infrastructure, environment and Building Industry it could be possible after this first test to automate the conversion of BhML from and to RESQML entities.

Conclusions & recommendations

This report documents the results of an Interoperability Experiment that looked at specific aspects of overlaps between existing standards and products. The group recognized that more formal work should be undertaken by a Standard Working Group. The contributors to this IE also scoped intentionally on a narrow aspect of the problem to find a useful pattern to address similar problems as more concepts are eventually added.

Future work includes looking into add more features under BhML and involves coordination with ongoing OGC Geoscience standards for geology and hydrogeology to ensure that those standards can operate together.

Because this report also highlights the parallel between 19148 and boreholes, some of the classes still bare names derived from 19148 (such as BoreholeEventCollection). These concept names might not resonate with communities using borehole and future work should address proper naming.

We recommend that:

• OGC supports the creation of a Borehole SWG to formalize the core borehole model as an official standard;

• A Borehole SWG refines the model to reflect the nomenclature and concepts names used by the communities using Borehole; and

• A Borehole SWG reach to existing standard custodians to produce BhML-compliant version of their existing borehole standards. The previously presented approach implements the Dependency Injection Pattern (nomen est omen) by substituting the "locatedMember" Element. This pattern is also known as the Hollywood principle: "Don't call us, we call you!". For this, BoreholeEvent and locatedMember are substituted with external elements that have been derived from the according types and which then are "utilised" (called) by the external borehole elements.

!--- | | ###################### SURFICAL GEOLOGY GSC STANDARD ############################ | --
Although a valid XML-Schema mechanism, this is not conform to the OGC approach (Not substituting properties).

Therefore a second version of this approach has been implemented and tested, in which the within GML defined AbstractObject is substituted by the external types. Since the AbstractObject does not provide any constraint, the dependency is far less strong. The following code snippets illustrate this approach on the BoreholeML GroundwaterObservation:

Original BML Schema Definition: The Objective of RESQML is not to represent one WellBore in an xml instance but to groups together xml instances of Wellbores, Horizons, faults, Stratigraphic Units, EarthModel and associates 3D Representations and properties to these Objects. RESQML expresses the fact that an object can have several Interpretations during its life Cycle (by several people or organizations along years). Also it expresses that an interpretation can have several way to be represented : by example a fault can be a set of 3D points, a collection of polylines, a triangulated surface, a 2Dgrid or a set of cells boundaries in a grid. As these representations are gathering a topological description and ONE geometry of the geological or technical Object (like the wellbore), RESQML can attach Properties to all the elements of this Topology. The properties can be continuous and discrete values but also URI and URL to capture values or descriptions on specific Web sites. This is what RESQML people are calling the "FIRP" structure or Feature/Interpretation/Representation/Property structure. This is a very generic mechanism allowing to gather and exchange all the information collected in a BhML instance.

As a Feature can be relative to multiple Interpretation, An Interpretation can be Represented by several types and multiple properties can be attached to ONE representation RESQML uses a DOR (DataObject Reference) to link these Object.

As a result, inside each property you will find the DOR of One Representation, inside each Representation you will find the DOR of One Interpretation and Inside the Propertyyou will find the DOR of One Feature.

Each DataObject in the RESQML Epc has for Primary Key an UUID ( Universal UID) which is totally unique and used as a Foreign Key by the other DatObjects to Structure the FIRP mechanism.

A RESQML EPC is collecting all the information on this structure but it is not a management object.

Figure 1 :

 1 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 3 :

 3 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 4 :

 4 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 5 :

 5 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 6 :

 6 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 7 :

 7 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 9 :

 9 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 10 :

 10 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 11 :

 11 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 12 :

 12 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 17 :

 17 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 18 :

 18 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 19 :

 19 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 20 :

 20 Figure 1: Grouping of Borehole IE vocabulary needs ................................................................................ Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ......................................................Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes ..............................................................Figure 4: 'BhML Core' explained -boreholeEventLocation .....................................................................Figure 5: 'BhML Core' BoreholeEventLocation explained ........................................................................Figure 6: 'BhML Core' applied to geological Log step 1 ........................................................................... Figure 7: 'BhML Core' applied to geological Log step 2 ........................................................................... Figure 8: TrajectoryReferent explained ......................................................................................................Figure 9: 'BhML Core' conceptual model -Positioning ............................................................................ Figure 10: 'BhML Core' conceptual model -Borehole & BoreholeEventCollection .................................Figure 11: 'BhML Core' conceptual model -CodeLists .............................................................................Figure 12: 'BhML Core' logical model -Positioning ................................................................................ Figure 13: 'BhML Core' logical model -Borehole & BoreholeEventCollection ....................................... Figure 14: 'BhML Core' logical model -CodeLists .................................................................................... Figure 15: With dependency reuse of 'BhML Core' example ..................................................................... Figure 16: Boisvert Michaud core image used as a basis for NRCan test ..................................................Figure 17: GFZ knowledge base example ..................................................................................................Figure 18: Generated RESQML Nodes ......................................................................................................Figure 19: RESQML Table look up between MdValues and LithoUnits ...................................................Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment ................................................................................................................................................

Figure 1 :

 1 Figure 1: Grouping of Borehole IE vocabulary needs

Figure 2 :

 2 Figure 2: ISO 19148 -Figure 14 -Linear Referencing System classes ISO 19148 covers two sets of concepts of interest for this IE.A first set describes the elements forming the linear feature and the coordinate system built on that feature. The core concept is the "LR_PositionExpression" that links together three elements.

Figure 3 :

 3 Figure 3: ISO 19148 Figure 44 -Linearly Located Event classes

Figure 4 :

 4 Figure 4: 'BhML Core' explained -boreholeEventLocation A 'boreholeEventLocation' can either be at a location ('AtLocation' illustrated on the left of the figure below) or from a location to another one ('FromToLocation' illustrated on the right side).

Figure 5 :

 5 Figure 5: 'BhML Core' BoreholeEventLocation explained

Figure 7 :

 7 Figure 7: 'BhML Core' applied to geological Log step 2

Figure 8 :

 8 Figure 8: TrajectoryReferent explained

  Figures below provide the class diagram of the conceptual model.

Figure 9 :Figure 10

 910 Figure 9: 'BhML Core' conceptual model -Positioning

  Note: this class is an adaptation of ISO 19148 LE_EventLocation. This class is abstract. AtLocation Specifies a single position along the Borehole Trajectory.AtLocation describes a single location along the borehole trajectory. The location can either by a direct distance measurement or a reference to another feature located at the same location.Note: this class is an adaptation of ISO 19148 LE_AtLocation.AttributeType and Multiplicity Definition atPosition MeasureOrEvent Specifies the linearly referenced location of the BoreholeEvent at a single point along the borehole trajectory. The location is defined according to the borehole referencing method defined by the borehole linear referencing system.

Figure 12 :Figure 13

 1213 Figure 12: 'BhML Core' logical model -Positioning

  <my:MyBorehole> (this is a community redefined borehole) <!--(see without dependency -same content up to : --> codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml" codeListValue="owner":indexData> A full example is available in GitHub : https://github.com/opengeospatial/boreholeie/blob/master/instances/NRCan/GSC_BoisvertMicha ud_dep.xml and also provided in annex B.

  uom="http://qudt.org/vocab/unit/M">1618.16</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <!--# and this continues with a lot of Samples (see Segment URI -> https://www.geodata.rocks/Segments/SD-5054_1_A-3)--> </BhML:BoreholeEventCollection>

4

 4 gml:id="spc.2"> <gml:description>clay sample</gml:description> <gml:name>S.1</gml:name> <sam:sampledFeature xsi:nil="true" nilReason="unknown"/> <spec:materialClass xlink:href="http://resource.geosciml.org/classifier/cgi/lithology/0060" xlink:title="Clay"/> <spec:samplingTime> <gml:TimeInstant gml:id="spc.2.ts"> <gml:timePosition>2012-06-24</gml:timePosition> </gml:TimeInstant> </spec:samplingTime> <spec:size uom="g">650</spec:size> <uom="http://qudt.org/vocab/unit/M">10.3</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">13</BhML:distanceAlong> <Borehole Markup Language (BML) of the State Geological Surveys, Germany11.4.1 MethodologyThe GFZ mainly tested the Use Case 11, "Testing 3D/4D geologic model coherence" by the application of Use Case 12, "Sharing borehole related vocabularies." In this use case, a modeler searches for all available information dealing with a geological formation with a stratigraphic age "Tertiary." The images below show the result of a query for boreholes that have observed (drilled) this "Tertiary" formation within the search area.

Figure 17 :

 17 Figure 17: GFZ knowledge base exampleBased on Domain Controlled Vocabularies, this approach leads scientists into a position which allows an effective evaluation of data provided within an infrastructure. Agreed upon terms are essential for data mining and fusion, which in return takes scientific research to a new level. A very high value for a scientific community can be achieved by the suitable visualization of data. Researchers can evaluate the suitability of data for their utilization in a certain planned context. It is also possible to correlate (fuse) borehole information with results from numerical modelling and/or geophysical prospection.

<

  <bml:drillingDepth uom="m">42</bml:drillingDepth> <bml:groundwaterObservationType/> <bml:dateTime>2019-08-04T01:00:00</bml:dateTime> <bml:groundwaterLevel uom="m">9</bml:groundwaterLevel> <bml:overflow>true</bml:overflow>

<

  xlink:title="outstanding"/> <BhML:precisionStatement xlink:title="good"/> <BhML:boreholeReferencingMethod> <BhML:BoreholeReferencingMethod> <BhML:name>meter</BhML:name> <BhML:unit xlink:href="http://qudt.org/vocab/unit/M"/> srsDimension="3" srsName="http://www.opengis.net/g ml/srs/epsg.xml#4979"uom="http://qudt.org/vocab/unit/M">0.00 <<bml:drillingDepth uom="m">42</bml:drillingDepth> <bml:groundwaterObservationType/> <bml:dateTime>2019-08-04T00:00:00</bml:dateTime> <bml:groundwaterLevel uom="m">10</bml:groundwaterLevel> <bml:overflow>true</bml:overflow> <

  The 'CONTACTS' <BhML:collection> specifies the first two lithology boundaries (<gsmlb:Contact>). These <BhML:BoreholeEvent> are then used to specify the upper and lower depths of the lithology in the 'LITHOLOGY' section.This is a very verbose encoding. --> <BhML:collection> <BhML:BoreholeEventCollection gml:id="feduni.well.26654.bhec3"> <BhML:collectionLRS> <snip> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="be4"> <gml:name>lithology contacts</gml:name> <BhML:locatedMember> <gsmlb:Contact gml:id="c1"> <gml:name>Surface</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier> http://resource.geosciml.org/classifier/cgi/contacttype/unconformable_contact <uom="http://qudt.org/vocab/unit/M">0.0</BhML:distanceAlong> <gml:id="be5"> <BhML:locatedMember> <gsmlb:Contact gml:id="c2"> <gml:name>Sedimentary contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/depositional_c ontact</swe:identifier> </swe:Category> </gsmlb:classifier> <uom="http://qudt.org/vocab/unit/M">0.5</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <snip>

  This is only the first lithology. --> <BhML:collection> <BhML:BoreholeEventCollection gml:id="feduni.well.26654.bhec4"> <gml:name>lithology</gml:name> <BhML:collectionLRS xlink:href="#LRS2"/> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="be12"-The first lithology occurs between the first two contacts --

  this encoding no reference is made between the depths associated with the lithologies. Instead the depths are encoded with the lithology log and BhML:location provides the log upper and lower depths (equivalent to <gwml2w:startDepth> and <gwml2w:endDepth> --> <BhML:collection> <BhML:BoreholeEventCollection> <BhML:collectionLRS xlink:href="#LRS2"/> <BhML:collectionMember> <BhML:BoreholeEvent> <BhML:locatedMember> <gwml2w:GW_GeologyLogCoverage gml:id="feduni.well.26654.1.coverage"code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>0.0</swe:value> </swe:Quantity> </gwml2w:fromDepth> <gwml2w:toDepth> <swe:Quantity> <swe:uom code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>0.5</swe:value> </swe:Quantity> </gwml2w:toDepth> <gwml2w:value> <swe:DataRecord definition="http://www.opengis.net/def/gwml/2.1/datarecord/earthMaterial"> <swe:field name="lithology"> <swe:Category definition="http://www.opengis.net/def/gwml/2.1/datarecord/earthMaterial"> <swe:value>BRN FS LOAM DRY</swe:value> <

3

 3 This encoding uses gwml2w:GW_GeologyLog and a swe data array --> <BhML:collection> <BhML:BoreholeEventCollection> <BhML:collectionLRS xlink:href="#LRS2"/> <BhML:collectionMember> <BhML:BoreholeEvent> <BhML:locatedMember> <gwml2w:GW_GeologyLog gml:id="feduni.well.26654.1<gml:timePosition>1987-02-16Z</gml:timePosition> </gml:TimeInstant> </om:resultTime> <om:procedure xlink:href="http://www.opengis.net/def/gwml/2.0/observedProperty/earthMaterial" xlink:title="drillers log"/> <om:observedProperty xlink:href="http://www.opengis.net/def/gwml/2.0/observedProperty/earthMaterial" xlink:title="lithology"/> <om:featureOfInterest xlink:href="#feduni.well.26654"/> <om:result> <swe:DataArray definition="http://www.opengis.net/def/gwml/2.0/coverage/geologyLog"> <swe:elementCount> <swe:Count> <swe:value>1</swe:value> </swe:Count> </swe:elementCount> <swe:elementType name="LogValue"> <swe:DataRecord definition="http://www.opengis.net/def/gwml/2.0/datarecord/earthMaterial"> <swe:field name="from"> <swe:Quantity definition="https://www.opengis.net/def/BoreholeML/FromToLocation/from"> <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m" xlink:title="m"/> </swe:Quantity> </swe:field> <swe:field name="to"> <swe:Quantity definition="https://www.opengis.net/def/BoreholeML/FromToLocation/to"> <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m" xlink:title="m"/> </swe:Quantity> </swe:field> <swe:field name="lithdesc"> <swe:Text definition="http://www.opengis.net/def/gwml/2.0/observedProperty/lithdesc"/> </swe:field> </swe:DataRecord> </swe:elementType> <swe:encoding> <swe:XMLEncoding/> </swe:encoding> <swe:values xmlns:d="http://www.opengis.net/def/gwml/2.0/datarecord/earthMaterial"> <d:LogValue> <d:from>0.0</d:from> <d:to>0.5</d:to> <d:lithdesc>BRN FS LOAM DRY</d:lithdesc> <GWML2 to BhML remarks Data in GWML2 not able to be encoded in BhML

  <BhML:BoreholeEvent gml:id="be1"> <gml:name>constructed depth</gml:name> <BhML:locatedMember xlink:href="http://www.opengis.net/gwmlwell/2.2/gwWellConstructedDepth" xlink:title="gwWellConstructedDepth"uom="http://qudt.org/vocab/unit/M">0</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">11.68</BhML:distanceAlong> <

  <BhML:BoreholeEvent gml:id="be0"> <BhML:locatedMember> <gwml2wc:Screen gml:id="feduni.borehole.construction.26654.screen.1"> <gml:name>screen</gml:name> <gwml2wc:screenElement> <gwml2wc:ScreenComponent gml:id="feduni.borehole.construction.26654.screen.component.3193"> <gwml2wc:screenInternalDiameter> <swe:Quantity> <swe:uom xlink:href="http://registry.it.csiro.au/def/qudt/1.1/qudt-unit/Centimeter" code="cm" xlink:title="centimetre"uom="http://qudt.org/vocab/unit/M">9.5</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">11.5</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent>GWML2 allows specifying the from-to depth of the construction material. Using BhML:location to capture the from-to depth makes this redundant. uom="http://qudt.org/vocab/unit/M">11.5</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation>

  code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>9.5</swe:value> </swe:Quantity> </gwml2wc:from> <gwml2wc:to> <swe:Quantity> <swe:uom code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>11.5</swe:value> </swe:Quantity> </gwml2wc:to>

Figure 18 :

 18 Figure 18: Generated RESQML Nodes How to can attach all Property Type encountred into the BhML instance to this WellBoreframeRepresentation is explained below.This WellBoreFrame Representation is also linked to The WellBoreFrameTrajectory which is attached to the Datum (equivalent of the <BhML:BoreholeLRS gml:id="LRS1">).

Figure 19 :

 19 Figure 19: RESQML Table look up between MdValues and LithoUnits

Figure 20 :

 20 Figure 20: Initial 'BhML Core' compliant converted to RESQML and loaded into Autodesk/Civil3D BIM environment

  gml:id="u5"> <BhML:locatedMember> <gsmlb:GeologicUnit gml:id="geol.surf.5"> <gml:description>Till blanket</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/id/surfical/Tb</gml:i dentifier> <gml:name>Tb</gml:name> <gml:id="u6"> <BhML:locatedMember> <gsmlb:GeologicUnit gml:id="geol.surf.6"> <gml:description>Bedrock</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/id/surfical/R</gml:id entifier> <gml:name>Bedrock</gml:name><########################## HYDROGEOLOGICAL UNITS ######################### | --><BhML:collection> <BhML:BoreholeEventCollection gml:id="hydrogeo1"> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/id/log/unbounded.1.co ntacts</gml:identifier> <gml:name codeSpace="urn:gin">demo.surficialunit</gml:name> <BhML:collectionLRS xlink:href="#LRS1"/> <!--this time, classified using GSC surficial standard units --> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="gw1"> <BhML:locatedMember> <gwml2:GW_Aquifer gml:id="hg1"> <gml:description>Vadose zone is everything about the static gw level</gml:description> <gml:id="gw3"> <BhML:locatedMember> <gwml2:GW_ConfiningBed gml:id="hg3"> <gml:description>All the impermeable units (till and clay)</gml:description> <-in order to restrict BoreholeEvent with external Types like GroundwaterObservation, which substitutes locatedMember in the extension --> <complexType name="BoreholeEventType"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <!--in order to be substituted by and derived from by third party (BML) types of geological information→ <element ref="BhML:locatedMember"/> <element ref="BhML:location"

  <xs:complexType name="GroundwaterObservationLogType"> <xs:complexContent> <xs:extension base="bml:AbstractMeasurementType"> <xs:sequence> <xs:element name="drillingDepth" type="gml:LengthType"> <xs:annotation> <xs:documentation> Distance from the starting point of the borehole during the observation.Distances are measured along the borehole path. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="groundwaterObservationType" type="gml:CodeType"> <xs:annotation> <xs:documentation> Type of groundwater observation. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="dateTime" type="gml:TimePositionType" nillable="true"> <xs:annotation> <xs:documentation> Date and time of groundwater observation or measurement. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="groundwaterLevel" nillable="true"> <xs:annotation> <xs:documentation> Groundwater level in the borehole relative to the starting point. Distances are measured along the borehole path. </xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="gml:LengthType"> <xs:attribute name="nilReason" type="gml:NilReasonType"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="overflow" nillable="true"> <xs:annotation> <xs:documentation> Information about artesian conditions. </xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:boolean"> <xs:attribute name="nilReason" type="gml:NilReasonType"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <DataRecord definition="bml:stratigraphy"> <field name="ChronoStratigraphy"> <Text definition="http://../bml/ChronoStratigraphy.xml"/> </field> <field name="LithoStratigraphy"> <Text definition="http://../bml/LithoStratigraphy.xml"/> </field> </DataRecord> </field> <field name="petrography"> <DataRecord definition="bml:petrography"> <field name="Lithology"> <DataRecord definition="bml:Lithology"> <field name="rockName"> <Text definition="http://../rn.xml"/> </field> <field name="rockColor"> <Text definition="http://.././rc.xml"://../def/BhML/FromToLocation/from"> <uom code="m"/> </Quantity> </field> <field name="to"> <Quantity definition=" https://../def/BhML/FromToLocation/to"> <uom code="m"/> Mapping ENERGISTICS RESQML and BhML The complete mapping structure obtained is the following Quick Overview of RESQML to follow up the mapping philosophy.RESQML (see www.energistics.org/RESQML) is mainly an exchange format which has writer and readers on many geosciences tools used previously in the petroleum industry and applied to the Infrastructure of road, tunnels, highway, railway and environmental objectives;The exchange is now operated by writing and reading a standardized "EpC" ( Energistics Package containers) of xml instances which is in fact an EPC file (Standard used for docx (Word) ,xlsx (Excel) and pptx ( Power point) exchange) and hdf5 files (for large binary information.. up to several terabytes).

  When UML is used in an OGC document, that document should indicate the UML notation that is used. Inclusion of the following paragraph is suggested.

	4.1	Abbreviated terms
	BML		Borehole Markup Language -BoreholeML
	BhML		Draft OGC Borehole Model generated during the Borehole IE
	EPOS		European Plate Observing System (EPOS)
	ER		Engineering Report
	GeoSciML	Geoscience Markup Language
	GWML2	WaterML2 Part 4: Groundwater Markup Language
	ICDP		International Continental Scientific Drilling Program (ICDP) Drilling
			Information System (DIS)
	IE		Interoperability experiment
	O&M		Observations and Measurements
	XML		eXtensible Markup Language
	4.2	UML notation

table ;

 ;

	Attribute	Type and Multiplicity	Definition
	name of the	Attribute type and	Attribute definition
	attribute	multiplicity
	• and each relation using this table.
	Relation	Source	Target	Description
	Relation type	Entity: source entity name	Entity: target	Relation
			entity name	description
		Role: source entity role
			Role: target entity
			name

5) Borehole for geotechnical investigation

	Who: BGS, BoM, BRGM, FedUni, GSC
	Context: National Ground Water Information Networks
	Requirement towards the IE:
	• borehole general details
	• geo-resource (waterbody, aquifer), monitored (quantity, quality) or exploited (water
	abstraction
	• sensor system
	• management zone around the well (to protect water resources)
	• pump/aquifer test
	• construction details/equipment
	7.2.4 (UseCase description on BoreholeIE GitHub.
	Who: BGS, BRGM, Energistics
	Context: Boreholes are drilled for Geotechnical engineering projects (e.g., tunnel, foundations,
	etc.) to acquire knowledge of the subsurface. This Use Case has a direct link with Building
	Information Models (BIM) activities.
	Requirement towards the IE:
	• borehole general details
	• drilling details
	• detailed geotechnical tests results
	• details observation acquired down the hole (ex: borehole televiewer)
	7.2.5 (
	• an observation workflow
	7.2.3 (3) Water well
	UseCase description on BoreholeIE GitHub.

6) Generic positioning of features on a borehole coordinate system

	7.2.6 (
	UseCase description on BoreholeIE GitHub.
	Who: BRGM, GSC, UU-SE
	• Ability to position features from any domain along a borehole
	• Definition of various positioning systems (eg: tropari, absolute, relative, etc.)
	• ResqML approach on wellboreframe is an interesting approach

11) Testing 3D/4D geologic model coherence

	UseCase description on BoreholeIE GitHub.
	Who: 3DS, GFZ, OGC
	Context: Borehole Logs can be used to validate or adapt existing 3D-Models of specific
	structures like geological horizons or tectonic faults. If new logs have been generated in a region
	where one or more 3D/4D models are available based on pre-existing knowledge of the
	underground, both geological and geophysical information from the logs can be applied to the
	corresponding parameters of the model. Thus, the logs can be used to validate or adapt the model
	accordingly. In the simplest case, this allows for example the inserting of new independent
	variables into the approximation (e.g., Kriging) of a geological structure. Borehole
	measurements are nearly the only way to verify geological or geophysical models derived from
	indirect investigation methods (for example Magnetotellurics). For this reason, it is essential to
	establish the means that are suitable to exchange borehole information like lithostratigraphic logs
	within the various communities without the need to implement the processing each time anew. If
	for example a significant amount of Iridium is measured in a geophysical log at a certain depth
	interval, the according unit can be identified as belonging to a geological horizon, which in turn
	has been observed (modelled) as a geological structure and classified (categorized) as K-T
	boundary. If the depth information of both samples differ from each other, the model can be
	adapted according to the depth information from the borehole log.
	Requirement towards the IE:
	• Multiple logging information linked to borehole information
	• Interoperable encoded terms (key/value pairs) for a unique identification
	• Availability of agreed-upon and domain-controlled vocabularies
	• Availability of mappings between parameters of borehole logs and 3D/4D models
	7.2.7

(13) Analysis on core & result positioning down the hole UseCase description on BoreholeIE GitHub.

	• Positioning rock samples along Borehole trajectory
	• Dealing with dense observation data results
	7.2.8 (
	Who: BRGM, CSIRO, UU-SE
	Context: Core taken from the Borehole are further analyzed either with destructive (rock
	samples) or non-destructive methods.
	For example: Core from scientific boreholes from the IODP, ICDP program have huge amounts
	of rock samples attached to them.
	Another example are Spectrally Scanned Borehole Cores where mineral boreholes are scanned
	with spectral reflectance logger (e.g., the Australian National Virtual Core Library project,
	http://www.auscope.org/nvcl/). Core in the tray are scanned and the result is a dense spectral
	reflectance downhole log.

14) Serving borehole events from an active drill site for off-site science support.

	UseCase description on BoreholeIE GitHub.
	Who: UU-SE
	This use case explores how the latest scientific information from the drill site can be made
	available to the scientific manager (PI, or responsible geologist) in order to provide sufficient
	information and support for off-site decision making.
	Real world setting of the use case: A drilling (project) that has basic to advanced on-site
	scientific documentation. These advanced information (e.g., core or cutting description,
	sampling, preliminary downhole logging data) are stored in a database. Basic information about
	the drilling operations that also is stored in a database and can be correlated to the scientific data
	is an advantage. Internet connection at the drill site is required.
	Use case in the IE:
	• Examples from the International Continental Scientific Drilling Program (ICDP)'s
	Drilling Information System (DIS) database have already been encoded in the borehole
	model (eposb) of the European Plate Observing System (EPOS).
	• Use eposb:Segment and eposb:Sample to analyse how compatible the present eposb is
	with BhML positioning.
	• Create examples that illustrate how BhML could be used for positioning these events in
	(future) eposb.
	7.2.9

(16) Oil & gas Well / Borehole description

	UseCase description on BoreholeIE GitHub.
	Who: Energistics
	Context: Be able to generate valid RESQML content from BhML compliant instances to feed
	RESQML capable tools and vice versa. Petroleum Industry needs to exchange WellBore
	information during the whole life cycle of a field. This encompasses Localisation and Raw Data
	measurement Exchanges (WITSML PART) and BoreHole Interpreted Information Exchange (oil
	and Gas well _RESQML PART).

7) Representation of temporal information about and/or positioned on a borehole UseCase description on BoreholeIE GitHub.

	• Geothermal doublets: coupled borehole
	• Geo-resource available (geothermal field)
	7.3.2 (Who: GSC, Geoscience Australia
	• representation of borehole status (active, inactive, in production, etc.) in time
	• representation of changes to borehole (headwork, deepening, etc.)
	7.3.3 (

8) Core set of attributes to create a borehole vCard

  UseCase description on BoreholeIE GitHub.

  LE_Event (seeISO 19148 Figure44). BoreholeEventCollection The BoreholeEventCollection is a collection of BoreholeEvents. Many collections can be managed within a single borehole. The grouping of BoreholeEvents in a collection is arbitrary and varies from one community to another. Geologists tend to group lithologic observations in one collection -called "logs" -and samples in another one. The current model does not impose any grouping by (e.g., Borehole Log, Borehole Construction, etc.).

		BoreholeEventCollec	BoreholeLRS	Linear Referencing
	Composition	Entity:BoreholeEventCollection tion	Entity:	Relates a System
			Role:	BoreholeEvent	BoreholeEventColl (BoreholeLRS)
		Role: Role:	collectionLRS Role:	ection to the member framing the location of the BoreholeEvent(s). BoreholeEvent(s) of the collection.
	9.3.3 Note: this class is an adaptation of ISO 19148 LE_Feature.
	Attribute Relation	Type and Multiplicity Source	Definition Target	Description
	locatedMember Aggregation	Any Entity: BoreholeEventCollec	Element located along the Borehole Entity: Borehole Relates a Borehole to trajectory the
		tion	BoreholeEventCollect Could be a Feature in the ISO191xx sense (OM_Observation, SF_Specimen, gwml2:constructionElement, ...) but not Role: ion(s) it can have.
		Role: collection	only. The type Any allows to use other community standards that don't apply
			ISO 191xx series of standards.
	Composition	Entity:	Entity:		Relates a
	location	BoreholeEventLocation BoreholeEvent BoreholeEventColle The linearly referenced location for this BoreholeEventCollect ction ion to the member event. BoreholeEvent(s).
		Role:
		collectionMember	Role:
	Association	Entity:	Entity:		Relates a
	Relation	Source		Target	Description BoreholeEventCollect
					ion to the Borehole

  BoreholeLRSDescribes the 'Linear Referencing System' that frames all the locations of the BoreholeEvent(s) composing BoreholeEventCollections. This LRS consists of the linear element being measured, the method of measurement and the referent relative to which all locations are measured.

	9.3.6 FromToLocation		two locations
	FromToLocation describes a continuous interval along the Borehole trajectory bounded by two along the Association Entity: Entity: BoreholeLRS Relates a Association Entity: Entity: BoreholeLRS Relates a
	positions (measure or events). BoreholeEventCollection TrajectoryReferent	borehole BoreholeEven BoreholeLRS
	tCollection to to the referent trajectory Note: this class is an adaptation of adaptation of ISO 19148 LE_FromToLocation. defining the boundary of the interval. Role: Role: collectionLRS the Borehole Linear Referencing used to Role: location measure the Role: trajectoryReferent BoreholeEven
	Attribute		Type and Multiplicity	Definition	System t linear
					(BoreholeLRS position.
					) framing the
	fromPosition 9.3.7 Note: this class is an adaptation of ISO 19148 LR_PositionExpression (see ISO 19148 Figure MeasureOrEvent Specifies the starting linearly referenced location of the BoreholeEvent as a single point along the borehole trajectory. The location is defined according to the borehole referencing method defined by location of the BoreholeEven t(s) of the collection. the borehole linear referencing system. 14). Association Entity: BoreholeLRS Entity: Relates a By convention, this position is the closest BoreholeReferencingMethod BoreholeLRS to the origin. to the
	toPosition Attribute accuracyStatement Role:	MeasureOrEvent Type and Multiplicity Role: BRM Definition Specifies the ending linearly referenced referencing method used to measure the location of location of the BoreholeEvent as a single point along the borehole trajectory. The location is defined according to the borehole referencing method defined by each AccuracyStatementType Statement regarding the accuracy of BoreholeEven the BoreholeLRS. t.
					the borehole linear referencing system.
	By convention, this position is farthest from the origin. precisionStatement PrecisionStatementType Statement regarding the precision of Association Entity: BoreholeLRS Entity: BoreholeTrajectory Relates a the BoreholeLRS. BoreholeLRS
	Relation	Source Role:	Target Role: linearElement	to the Description BoreholeTraje ctory along
					which
	Generalization Relation Relation	Entity: Source Source	Entity:BoreholeEventLocation Target Target	AtLocation is a BoreholeEven Description Description t(s) are
		AtLocation		specialized linearly
					location referenced.
	Generalization	Entity: FromToLocation Role:	Role: Entity:BoreholeEventLocation	composed of a FromToLocatio single distance. n is a specialized
		Role:	Role:	location that describes an interval
					composed of

  BoreholeReferencingMethodDescribes the procedure used to establish the measured distance along the borehole trajectory. Commonly used referencing methods are expected to be described in appropriate methods registers.

	Relation Association	Source Entity:	Target Entity:	Description Relates a
		BoreholeLRS	BoreholeReferencingMethod	BoreholeLRS to
					the referencing
					method used to
	Association	Entity: BoreholeLRS Role: Role: BRM Entity: BoreholeTrajectory	Relates a measure the location of each BoreholeLRS to the BoreholeTrajectory BoreholeEvent.
		Role:	Role: linearElement	along which BoreholeEvent(s) are linearly referenced.
	9.3.9 Attribute	Type and Multiplicity	Definition
	name	CharacterString		The name of the referencing method.
	unit	UnitOfMeasureType	The unit of measure used by the
				referencing method for measures along
				the borehole trajectory.
		GFI_Feature		A reference to an existing feature (distinct
				from the current Borehole) having a
				GM_Curve geometry.
	Relation	Source	Target		Description
	curve	GM_Curve		The geometry of the borehole trajectory.

Note: this class is an adaptation of ISO 19148 LR_LinearReferencingMethod.

  Standing issues are described in BoreholeIE as GitHub issues (https://github.com/opengeospatial/boreholeie/issues) and are labeled according to whether they target 'BhML Core' or potential extensions. A Github project provide an overview of them (https://github.com/opengeospatial/boreholeie/projects/1). Boreholes are used by a number of different domains, some of which have existing standards.

	○ Ensure 'feature' and 'position' attribute from the TrajectoryRefent provide
	coherent geospatial information (#37).
	○ Refine BoreholeReferencingMethod to add direction (#77).
	• Schema and encoding issues
	○ Union (#74)
	■ https://docs.opengeospatial.org/is/16-008/16-008.html#109
	■ https://www.seegrid.csiro.au/wiki/AppSchemas/UmL2GMLAS#A_4._Cla
	ss_association_pattern_45_target_stereotyped_42_60_62_42
	■ For the end of the IE it was decided to leave the encoding as specified in
	19139
	12.3 Impacts on external standards
	They are organized here grouped by topic with reference to issue number (#n).
	• Semantics
	○ Reduce the semantic influence of ISO 19148 on BhML classes as the target
	communities are more 'borehole' related communities than 'linear referencing
	ones.' Refining semantics to get even closer to Borehole semantics and loosen
	dependency with ISO 19148 terminology (#54, #67, #72).
	○ Various domains use the terms Borehole/Well/WellBore differently. Resolving
	these cross-domain class semantics is difficult (#43).
	• Model adjustment
	○ Introduction of O&M SF_SamplingFeature to link to other sampling features and
	observations (#55).
	○ Point from the domain feature to the borehole (reverse association between a
	domain feature and the borehole 'hosting' it) (#24).
	• Model enhancement
	○ Missing header (generic) information about the borehole (#56).
	○ Refining the reference elevation of a Borehole (#21).
	○ Refining that a Borehole always have a Trajectory (#44).

Borehole IE, BhML, BoreholeML, Energistics, EPOS, GeoSciML, GroundWaterML 2.0, INSPIRE, ISO 19148, Linear Referencing, RESQML, WITSML

<BhML:collectionMember>

</BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> </BhML:BoreholeEventCollection> </BhML:collection> </BhML:Borehole>

<BhML:accuracyStatement xlink:href="https://opengis.org/def/accuracy/good" xlink:title="Good"/> <BhML:precisionStatement xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" xlink:title="Unknown"/> <BhML:boreholeReferencingMethod> <BhML:BoreholeReferencingMethod> <BhML:name>relative</BhML:name> <BhML:unit xlink:href="http://qudt.org/vocab/unit/M" xlink:title="meter"/> </BhML:BoreholeReferencingMethod> </BhML:boreholeReferencingMethod> <BhML:linearElement> <BhML:BoreholeTrajectory> <BhML:curve> <gml:LineString gml:id="well.1" srsDimension="2" srsName="http://www.opengis.net/gml/srs/epsg.xml#4326"> <gml:posList>47.593616 -70.390738 379.269 47.593616 -70.390738 379.269 360.469</gml:posList> </gml:LineString> </BhML:curve> </BhML:BoreholeTrajectory> </BhML:linearElement> <BhML:trajectoryReferent> <BhML:DistanceExpression> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0.00</BhML:distanceAlong> <BhML:trajectoryReferent> <BhML:TrajectoryReferent gml:id="TR1"> <gml:identifier codeSpace="urn:_">Collar position</gml:identifier> <BhML:position> <gml:Point srsDimension="3" srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>47.593616 -70.390738 379.269 47.593616</gml:pos> </gml:Point> </BhML:position> </BhML:TrajectoryReferent> </BhML:trajectoryReferent> <BhML:location/> </BhML:DistanceExpression> </BhML:trajectoryReferent> </BhML:BoreholeLRS> </BhML:collectionLRS> <BhML:collectionMember> <BhML:BoreholeEvent> <BhML:locatedMember xlink:href="http://resource.bhml/org/classifier/boreholeFeatures/surface"/> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <!--etc --> <BhML:BoreholeEvent> <BhML:locatedMember xlink:href="https://www.geodata.rocks/Samples/SD-5054_1_A_531_3WR_64-76" xlink:title="SD-5054_1_A_531_3WR_64-76"/> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">1616.294</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">1616.414</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent> <BhML:locatedMember xlink:href="https://www.geodata.rocks/Samples/SD-5054_1_A_532_2WR_35-45" xlink:title="SD-5054_1_A_532_2WR_35-45"/> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">1618.06</BhML:distanceAlong> • Hydrogeologic units; and • Samples. The full XML instances are available on the GitHub: https://github.com/opengeospatial/boreholeie/tree/master/instances/NRCan Contacts and other discontinuities were encoded as simple point locations (AtLocation).

<BhML:BoreholeEvent gml:id="qu1"> <BhML:locatedMember> <gsmlb:Contact gml:id="c1"> <gml:name>Sedimentary contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/depositional_c ontact</swe:identifier> <!--depositional contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">3.2</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent>

The following 3 logs used the contacts from the first log to define the boundaries of the intervals. This pattern is optional. Defining the boundaries of Geologic Units using distance is also valid. But this pattern provides interesting properties, such as unambiguously identifying contact between two Geologic Units from 2 distinct logs (they share the same contact). <BhML:BoreholeEvent gml:id="l1"> <BhML:locatedMember> <gsmlb:GeologicUnit gml:id="geol.litho.1"> <gml:description>Organic, Peat</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/geologicUnit/well.dem o.l1</gml:identifier> <gml:name>Peat</gml:name> <gsmlb:composition> <gsmlb:CompositionPart> <gsmlb:role xlink:title="unspecified part role" xlink:href="http://inspire.ec.europa.eu/codelist/CompositionPartRoleValue/unspecifiedP artRole"/> <gsmlb:material> <gsmlb:RockMaterial gml:id="rock.1"> <gsmlb:lithology xlink:href="http://resource.geosciml.org/classifier/cgi/lithology/0185" xlink:title="Peat"/> </gsmlb:RockMaterial> </gsmlb:material> <gsmlb:proportion> <gsmlb:GSML_QuantityRange> <swe:uom code="%" xlink:href="http://unitsofmeasure/ucum.html#para-29" xlink:title="percent"/> <swe:value>90 100</swe:value> <gsmlb:lowerValue>90.0</gsmlb:lowerValue> <gsmlb:upperValue>100.0</gsmlb:upperValue> </gsmlb:GSML_QuantityRange> Borehole geology log start and end depth GWML2 encodes the start and end depth of the geology log with specific tags, startDepth and endDepth. <http://www.opengis.net/gwml-well/2.2:GW_GeologyLog> <http://www.opengis.net/gwml-well/2.2:gwWellGeology> ... <http://www.opengis.net/gwml-well/2.2:startDepth> <swe:Quantity> <swe:uom code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>0.0</swe:value> </swe:Quantity> </http://www.opengis.net/gwml-well/2.2:startDepth> < http://www.opengis.net/gwml-well/2.2:endDepth> <swe:Quantity> <swe:uom code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>11.68</swe:value> </swe:Quantity> </http://www.opengis.net/gwml-well/2.2:endDepth> </http://www.opengis.net/gwml-well/2.2:GW_GeologyLog> </http://www.opengis.net/gwml-well/2.2:gwWellGeology> Three possible encodings of that approach are possible. 1. One possible encoding of the geology log from-to depths is to specify them as an upper and lower BhML:BoreholeEvent. <BhML:BoreholeEvent gml:id="be1"> <BhML:locatedMember> <gsmlb:Contact gml:id="c1"> <gml:name>top of geology log</gml:name> … <BhML:location> <BhML:AtLocation> <BhML:atLocation> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">2.0</BhML:distanceAlong> A separate BhML:BoreholeEvent then describes the two BoreholeEvents representing the upper and lower geology log depths as a GWML2:GW_GeologyLog: 85 <BhML:BoreholeEvent gml:id="be3"> <BhML:locatedMember> <http://www.opengis.net/gwml-well/2.2:GW_GeologyLog>

The issue with this encoding is that the log start and end depths may not correspond to geological contacts and so "gsmlb:Contact" is not an appropriate gml:FeatureType. An appropriate feature type may not be available.

2. The start and end depth of the geology log can be specified using the BhML:FromToLocation property when using a GWML2 coverage (GW_GeologyLogCoverage) as a BhML:BoreholeEvent: <BhML:BoreholeEvent> <BhML:locatedMember> <gwml2w:GW_GeologyLogCoverage gml:id="feduni.well.26654.1.coverage"> <gwml2w:element> <gwml2w:LogValue> ... <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0.0</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">11.8</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> … 3. The start and end depth GWML2 geology log properties can be used directly by incorporating GW_GeologyLog into BhML as a BhML:BoreholeEvent as used in the SWE compacted encoding: <BhML:BoreholeEvent> <BhML:locatedMember> <http://www.opengis.net/gwml-well/2.2:GW_GeologyLog> ... <http://www.opengis.net/gwml-well/2.2:startDepth> <swe:Quantity> <swe:uom code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>0.0</swe:value> </swe:Quantity> </http://www.opengis.net/gwml-well/2.2:startDepth> <http://www.opengis.net/gwml-well/2.2:endDepth> <swe:Quantity> <swe:uom code="m" xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/> <swe:value>11.5</swe:value> </swe:Quantity> </http://www.opengis.net/gwml-well/2.2:endDepth> In this case the BhML:FromToLocation property duplicates the GWML2 startDepth -endDepth properties: <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0.0</BhML:distanceAlong> Annex A: A TrajectoryReferent example in XML This XML file corresponds to the file available on GitHub : https://github.com/opengeospatial/boreholeie/blob/master/instances/TrajectoryReferent/Trajector yReferent.xml <?xml version="1.0" encoding="UTF-8"?> <BhML:Borehole xmlns:gww="http://www.opengis.net/gwml-well/2.2" xmlns:sam="http://www.opengis.net/sampling/2.0" xmlns:spec="http://www.opengis.net/samplingSpecimen/2.0" xmlns:swe="http://www.opengis.net/swe/2.0" xmlns:sams="http://www.opengis.net/samplingSpatial/2.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:BhML="https://raw.githubusercontent.com/opengeospatial/boreholeie/master/schemas " xsi:schemaLocation="https://raw.githubusercontent.com/opengeospatial/boreholeie/master /schemas https://raw.githubusercontent.com/opengeospatial/boreholeie/master/schemas/BhML-Core.xsd "> <gml:description>Example of xml to support section describing the use of TrajectoryReferent and BoreholeReferencingMethod</gml:description> <BhML:collection> <BhML:BoreholeEventCollection> <BhML:collectionLRS> <BhML:BoreholeLRS gml:id="LRS1"> <BhML:accuracyStatement/> <BhML:precisionStatement/> <BhML:boreholeReferencingMethod> <BhML:BoreholeReferencingMethod> <BhML:name>relative</BhML:name> <BhML:unit xlink:href="http://qudt.org/vocab/unit/M" xlink:title="meter"/> 97 </BhML:BoreholeReferencingMethod> </BhML:boreholeReferencingMethod> <BhML:linearElement> <BhML:BoreholeTrajectory> <BhML:curve> <gml:LineString gml:id="well.1" srsDimension="2" srsName="http://www.opengis.net/gml/srs/epsg.xml#4326"> <gml:posList>47 -70 201 47.593616 47 -70 258</gml:posList> </gml:LineString> </BhML:curve> </BhML:BoreholeTrajectory> </BhML:linearElement> <BhML:trajectoryReferent> <BhML:DistanceExpression> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0.0</BhML:distanceAlong> <BhML:trajectoryReferent> <BhML:TrajectoryReferent gml:id="TR1"> <gml:name>Top of Casing</gml:name> <BhML:position> <gml:Point srsDimension="3" srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>47 -70 201</gml:pos> </gml:Point> </BhML:position> </BhML:TrajectoryReferent> </BhML:trajectoryReferent> <BhML:location/> </BhML:DistanceExpression> </BhML:trajectoryReferent> </BhML:BoreholeLRS> </BhML:collectionLRS> <BhML:collectionMember> <BhML:BoreholeEvent> <gml:name>Platform</gml:name> <BhML:locatedMember xlink:href="http://resource.bhml/org/classifier/boreholeFeatures/platform"/> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">-1</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent> <gml:name>Ground level</gml:name> <BhML:locatedMember xlink:href="http://resource.bhml/org/classifier/boreholeFeatures/ground-level"/> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">1.0</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> 99 </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent> <gml:name>Something 1 meter below ground</gml:name> <BhML:locatedMember xlink:href="http://resource.bhml/org/classifier/boreholeFeatures/depth-1"/> <BhML:location> <BhML:AtLocation>

<BhML:atPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">2.0</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent> <gml:name>Final Depth</gml:name> <BhML:locatedMember xlink:href="http://resource.bhml/org/classifier/boreholeFeatures/final-depth"/> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">43.0</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember></BhML:BoreholeEventCollection> </BhML:collection> </BhML:Borehole>

Annex B: Observation log in BhML

This XML file corresponds to the file available on GitHub : https://github.com/opengeospatial/boreholeie/blob/master/instances/NRCan/GSC_BoisvertMicha ud_dep.xml "With dependency" example based on Boisvert and Michaud (1999). Schema ( https://github.com/opengeospatial/boreholeie/blob/master/instances/NRCan/MyBorehole.xsd) adapted from GeoSciML 4.1 (OGC 16-008). This instance shows an example where a community decides to extend BhML to add their own properties. In this case, we adapted an existing class from GeoSciML borehole package (BoreholeDetails, clause 8.7.1.4 https://docs.opengeospatial.org/is/16-008/16-008.html#307)

Handcrafted encoding of Boisvert, E., Michaud, Y., 1998, Gestion des données de forage à l'aide d'une approche topologique : application au projet de cartographie hydrogéologique du piémont laurentien, Québec Current research 1998-E/Recherches en cours 1998-E; by Geological Survey of Canada; Geological Survey of Canada, Current Research no. 1998-E, 1998 p. 117-124, https://doi.org/10.4095/209958 diagram on p.119 Complex example made of units constructed from reused contacts and samples. Examples that use a Borehole derived from core BhML Borehole and adds a BoreholeDetails class adapted from GeoSciML --> <my:MyBorehole xmlns:gww="http://www.opengis.net/gwml-well/2.2" xmlns:sam="http://www.opengis.net/sampling/2.0" xmlns:spec="http://www.opengis.net/samplingSpecimen/2.0" xmlns:swe="http://www.opengis.net/swe/2.0" xmlns:BhML="https://raw.githubusercontent.com/opengeospatial/boreholeie/master/schemas " xmlns:sams="http://www.opengis.net/samplingSpatial/2.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:cit="http://standards.iso.org/iso/19115/-3/cit/1.0" xmlns:my="http://www.example.org/MyBorehole" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gwml2="http://www.opengis.net/gwml-main/2.2" xmlns:gco="http://standards.iso.org/iso/19115/-3/gco/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gsmlb="http://www.opengis.net/gsml/4.1/GeoSciML-Basic" xsi:schemaLocation="http://www.example.org/MyBorehole MyBorehole.xsd http://www.opengis.net/gsml/4.1/GeoSciML-Basic http://schemas.opengis.net/gsml/4.1/geoSciMLBasic.xsd http://www.opengis.net/samplingSpecimen/2.0 http://schemas.opengis.net/samplingSpecimen/2.0/specimen.xsd http://www.opengis.net/gwml-main/2.2 http://schemas.opengis.net/gwml/2.2/gwml2main.xsd">

<gml:description>Complex example made of units constructed from reused contacts and samples. This borehole is an encoding of a example described in Boisvert & Michaud, 1998</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/id/waterwells/unbound ed.1</gml:identifier> <gml:name codeSpace="urn:gin">demo</gml:name>

<BhML:collection> <BhML:BoreholeEventCollection gml:id="contact.1"> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/id/log/unbounded.1.co ntacts</gml:identifier> <gml:name codeSpace="urn:gin">demo.contacts</gml:name> <BhML:collectionLRS> <BhML:BoreholeLRS gml:id="LRS1"> <gml:description>The reference is an arbitrary point on the ground at the top of the borehole. Because it's also the beginning of the 103 linear element, it's both, providing no trajectoryReferent would also be valid by using "absolute" Referencing method</gml:description> <gml:name>ground</gml:name> <BhML:accuracyStatement xlink:href="https://opengis.org/def/accuracy/good" xlink:title="Good"/> <!--should be xlink:href --> <BhML:precisionStatement xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" xlink:title="Unknown"/> <!--should be xlink:href --> <BhML:boreholeReferencingMethod> <BhML:BoreholeReferencingMethod> <BhML:name>relative</BhML:name> <BhML:unit xlink:href="http://qudt.org/vocab/unit/M" xlink:title="meter"/> </BhML:BoreholeReferencingMethod> </BhML:boreholeReferencingMethod> <BhML:linearElement> <BhML:BoreholeTrajectory> <BhML:curve> <gml:LineString gml:id="well.1" srsDimension="2" srsName="http://www.opengis.net/gml/srs/epsg.xml#4326"> <gml:posList>47.593616 -70.390738 379.269 47.593616 -70.390738 379.269 360.469</gml:posList> </gml:LineString> </BhML:curve> </BhML:BoreholeTrajectory> </BhML:linearElement> <BhML:trajectoryReferent> <BhML:DistanceExpression> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0.00</BhML:distanceAlong> <BhML:trajectoryReferent> <BhML:TrajectoryReferent gml:id="TR1"> <gml:identifier codeSpace="urn:_">Collar position</gml:identifier> <BhML:position> <gml:Point srsDimension="3" srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>47.593616 -70.390738 379.269 47.593616</gml:pos> </gml:Point> </BhML:position> </BhML:TrajectoryReferent> </BhML:trajectoryReferent> <BhML:location/> </BhML:DistanceExpression> </BhML:trajectoryReferent> </BhML:BoreholeLRS> </BhML:collectionLRS> <BhML:collectionMember> <BhML:BoreholeEvent> <BhML:locatedMember xlink:href="http://resource.bhml/org/classifier/boreholeFeatures/surface"/> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> 105 </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="qu1"> <BhML:locatedMember> <gsmlb:Contact gml:id="c1"> <gml:name>Sedimentary contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/deposit ional_contact</swe:identifier> <!--depositional contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">3.2</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="qu2"> <BhML:locatedMember> <gsmlb:Contact gml:id="c2"> <gml:name>Sedimentary contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/deposit ional_contact</swe:identifier> <!--depositional contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">4.5</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> 107 <BhML:collectionMember> <BhML:BoreholeEvent gml:id="ns3"> <BhML:locatedMember> <!--in this case, it's not a contact, but an observation of a static groundwater level --> <om:OM_Observation gml:id="obs.ns3" xmlns:om="http://www.opengis.net/om/2.0"> <gml:description>Static Water Level</gml:description> <om:phenomenonTime> <gml:TimeInstant gml:id="ti.1"> <gml:timePosition>1981-09-12T00:00:00</gml:timePosition> </gml:TimeInstant> </om:phenomenonTime> <om:resultTime> <gml:TimeInstant gml:id="ti.2"> <gml:timePosition>2014-06-09T00:00:00</gml:timePosition> </gml:TimeInstant> </om:resultTime> <om:procedure xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" xlink:title="unknown"/> <om:observedProperty xlink:href="urn:ogc:def:phenomenon:GIN:StaticWaterLevel" xlink:title="Static Water Level"/> <om:featureOfInterest xlink:href="https://geoconnex.ca/aquifer/StMaurice" xlink:title="St-Maurice Aquifer"/> <om:result> <swe:Quantity> <swe:uom xlink:href="http://qudt.org/vocab/unit/M" xlink:title="m"/> <!--this is actually an elevation, not a depth --> <swe:value>374.369</swe:value> </swe:Quantity> </om:result> </om:OM_Observation> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">4.9</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="nd4"> <BhML:locatedMember> <!--in this case, it's not a contact, but an observation of a dynamic groundwater level --> <om:OM_Observation gml:id="obs.nd3" xmlns:om="http://www.opengis.net/om/2.0"> <gml:description>Static Water Level</gml:description> <om:phenomenonTime> <gml:TimeInstant gml:id="ti.3"> <gml:timePosition>1981-09-12T00:00:00</gml:timePosition> </gml:TimeInstant> 109 </om:phenomenonTime> <om:resultTime> <gml:TimeInstant gml:id="ti.4"> <gml:timePosition>2014-06-09T00:00:00</gml:timePosition> </gml:TimeInstant> </om:resultTime> <om:procedure xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" xlink:title="unknown"/> <om:observedProperty xlink:href="urn:ogc:def:phenomenon:GIN:DynamicWaterLevel" xlink:title="Static Water Level"/> <om:featureOfInterest xlink:href="https://geoconnex.ca/aquifer/StMaurice" xlink:title="St-Maurice Aquifer"/> <om:result> <swe:Quantity> <swe:uom xlink:href="http://qudt.org/vocab/unit/M" xlink:title="m"/> <!--this is actually an elevation, not a depth --> <swe:value>273.269</swe:value> </swe:Quantity> </om:result> </om:OM_Observation> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">6.6</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="qu5"> <BhML:locatedMember> <gsmlb:Contact gml:id="c5"> <gml:name>Sedimentary contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/deposit ional_contact</swe:identifier> <!--depositional contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">6.6</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> 111 </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="qu6"> <BhML:locatedMember> <gsmlb:Contact gml:id="c6"> <gml:name>Sedimentary contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/deposit ional_contact</swe:identifier> <!--depositional contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">10</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="qu7"> <BhML:locatedMember> <gsmlb:Contact gml:id="c7"> <gml:name>Sedimentary contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/deposit ional_contact</swe:identifier> <!--depositional contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">11.1</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> 113 </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="qu8"> <BhML:locatedMember> <gsmlb:Contact gml:id="c8"> <gml:name>Sedimentary contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/disconf ormable_contact</swe:identifier> <!--Disconformable contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">13.3</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="qr9"> <BhML:locatedMember> <gsmlb:Contact gml:id="c9"> <gml:name>Sedimentary contact with bedrock</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/nonconf ormable_contact</swe:identifier> <!--Nonconformable contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">16.5</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> 115 <BhML:collectionMember> <BhML:BoreholeEvent gml:id="rc10"> <BhML:locatedMember> <gsmlb:Contact gml:id="c10"> <gml:name>Faulted contact</gml:name> <gsmlb:classifier> <swe:Category> <swe:identifier>http://resource.geosciml.org/classifier/cgi/contacttype/faulted _contact</swe:identifier> <!--Faulted contact --> </swe:Category> </gsmlb:classifier> </gsmlb:Contact> </BhML:locatedMember> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">17.7</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="bs11"> <BhML:locatedMember xlink:href="http://resource.bhml/org/classifier/boreholeFeatures/bottom"/> <BhML:location> <BhML:AtLocation> <BhML:atPosition> <!--this is not the right encoding for a union --> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">18.8</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:atPosition> </BhML:AtLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> </BhML:BoreholeEventCollection> </BhML:collection>

> <BhML:collection> <BhML:BoreholeEventCollection gml:id="litho1"> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/id/log/unbounded.1.co ntacts</gml:identifier> <gml:name codeSpace="urn:gin">demo.litho</gml:name> <BhML:collectionLRS xlink:href="#LRS1"/> <!--same referent as the contact referent, which makes sense --> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/geologicUnit/well.dem o.l2</gml:identifier> <gml:name>Fine Sand</gml:name> <gsmlb:composition> <gsmlb:CompositionPart> <gsmlb:role xlink:title="unspecified part role" xlink:href="http://inspire.ec.europa.eu/codelist/CompositionPartRoleValue/unspecifiedP artRole"/> <gsmlb:material> <gsmlb:RockMaterial gml:id="rock.2"> <gsmlb:lithology xlink:href="http://resource.geosciml.org/classifier/cgi/lithology/0228" xlink:title="Sand"/> </gsmlb:RockMaterial> </gsmlb:material> </gsmlb:CompositionPart> </gsmlb:composition> </gsmlb:GeologicUnit> </BhML:locatedMember> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:boreholeEvent xlink:href="#qu1"/> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:boreholeEvent xlink:href="#qu5"/> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="l3"> <BhML:locatedMember> <gsmlb:GeologicUnit gml:id="geol.litho.3"> <gml:description>Fine Sand</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/geologicUnit/well.dem o.l3</gml:identifier> <gml:name>Coarse Sand</gml:name> <gsmlb:composition> <gsmlb:CompositionPart> <gsmlb:role xlink:title="unspecified part role" xlink:href="http://inspire.ec.europa.eu/codelist/CompositionPartRoleValue/unspecifiedP artRole"/> <gsmlb:material> <gsmlb:RockMaterial gml:id="rock.3"> <gsmlb:lithology xlink:href="http://resource.geosciml.org/classifier/cgi/lithology/0228" xlink:title="Sand"/> </gsmlb:RockMaterial> </gsmlb:material> </gsmlb:CompositionPart> </gsmlb:composition> </gsmlb:GeologicUnit> 121 </BhML:locatedMember> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:boreholeEvent xlink:href="#qu5"/> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:boreholeEvent xlink:href="#qu6"/> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="l4"> <BhML:locatedMember> <gsmlb:GeologicUnit gml:id="geol.litho.4"> <gml:description>glaciomarine clay</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/geologicUnit/well.dem o.l4</gml:identifier> <gml:name>Clay</gml:name> <gsmlb:composition> <gsmlb:CompositionPart> <gsmlb:role xlink:title="unspecified part role" xlink:href="http://inspire.ec.europa.eu/codelist/CompositionPartRoleValue/unspecifiedP artRole"/> <gsmlb:material> <gsmlb:RockMaterial gml:id="rock.4"> <gsmlb:lithology xlink:href="http://resource.geosciml.org/classifier/cgi/lithology/0060" xlink:title="Clay"/> </gsmlb:RockMaterial> </gsmlb:material> </gsmlb:CompositionPart> </gsmlb:composition> </gsmlb:GeologicUnit> </BhML:locatedMember> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:boreholeEvent xlink:href="#qu6"/> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:boreholeEvent xlink:href="#qu8"/> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> 123 </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="l5"> <BhML:locatedMember> <gsmlb:GeologicUnit gml:id="geol.litho.5"> <gml:description>Coarse till with sand facies</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/geologicUnit/well.dem o.l5</gml:identifier> <gml:name>Till</gml:name> <gsmlb:composition> <gsmlb:CompositionPart> <gsmlb:role xlink:title="unspecified part role" xlink:href="http://inspire.ec.europa.eu/codelist/CompositionPartRoleValue/unspecifiedP artRole"/> <gsmlb:material>

<gsmlb:RockMaterial gml:id="rock.5"> <gsmlb:lithology xlink:href="http://resource.geosciml.org/classifier/cgi/lithology/0070" xlink:title="Diamicton"/> </gsmlb:RockMaterial> </gsmlb:material> </gsmlb:CompositionPart> </gsmlb:composition> </gsmlb:GeologicUnit> </BhML:locatedMember> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:boreholeEvent xlink:href="#qu8"/> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:boreholeEvent xlink:href="#qu9"/> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent gml:id="l6"> <BhML:locatedMember> <gsmlb:GeologicUnit gml:id="geol.litho.6"> <gml:description>Fractured and altered rock</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/geologicUnit/well.dem o.l6</gml:identifier> <gml:name>Granite</gml:name> <gsmlb:composition> <gsmlb:CompositionPart> <gsmlb:role xlink:title="unspecified part role" xlink:href="http://inspire.ec.europa.eu/codelist/CompositionPartRoleValue/unspecifiedP artRole"/> <gsmlb:material> <gsmlb:RockMaterial gml:id="rock.6"> <gsmlb:lithology <BhML:boreholeEvent xlink:href="#qu9"/> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> </BhML:BoreholeEventCollection> </BhML:collection> <BhML:collection> <BhML:BoreholeEventCollection gml:id="samples1"> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://geoconnex.ca/id/log/unbounded.1.sa mples</gml:identifier> <gml:name codeSpace="urn:gin">demo.samples</gml:name> <BhML:collectionLRS xlink:href="#LRS1"/> <!--samples are not constrained by contact, they have arbitrary positions --> <BhML:collectionMember> <BhML:BoreholeEvent> <BhML:locatedMember> <spec:SF_Specimen gml:id="spc.1"> <gml:description>Coarse sand sample</gml:description> <gml:name>S.1</gml:name> <sam:sampledFeature xsi:nil="true" nilReason="unknown"/> <spec:materialClass xlink:href="http://resource.geosciml.org/classifier/cgi/lithology/0228" xlink:title="Sand"/> <spec:samplingTime> <gml:TimeInstant gml:id="spc.1.ts"> <gml:timePosition>2012-06-24</gml:timePosition> </gml:TimeInstant> </spec:samplingTime> <spec:size uom="g">150</spec:size> </spec:SF_Specimen> </BhML:locatedMember> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">6.9</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">9.6</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> <BhML:collectionMember> <BhML:BoreholeEvent> <BhML:locatedMember> <spec:SF_Specimen gml:id="spc.2"> <gml:description>clay sample</gml:description> 139 <gml:name>S.1</gml:name> <sam:sampledFeature xsi:nil="true" nilReason="unknown"/> <spec:materialClass xlink:href="http://resource.geosciml.org/classifier/cgi/lithology/0060" xlink:title="Clay"/> <spec:samplingTime> <gml:TimeInstant gml:id="spc.2.ts"> <gml:timePosition>2012-06-24</gml:timePosition> </gml:TimeInstant> </spec:samplingTime> <spec:size uom="g">650</spec:size> </spec:SF_Specimen> </BhML:locatedMember> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">10.3</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">13</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> </BhML:BoreholeEventCollection> </BhML:collection> <my:indexData> <my:BoreholeDetails> <my:operator> <cit:CI_Responsibility> <cit:role> <cit:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml" codeListValue="owner"/> </cit:role> <cit:party> <cit:CI_Organisation> <cit:name> <gco:CharacterString>Natural Resources Canada</gco:CharacterString> </cit:name> </cit:CI_Organisation> </cit:party> </cit:CI_Responsibility> </my:operator> <my:driller> <cit:CI_Responsibility> <cit:role> <cit:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml" codeListValue="pointOfContact"/> </cit:role> <cit:party> <cit:CI_Organisation> <cit:name> 141 <gco:CharacterString>Geological Survey of Canada</gco:CharacterString> </cit:name> </cit:CI_Organisation> </cit:party> </cit:CI_Responsibility> </my:driller> <my:dateOfDrilling> <gml:TimePeriod gml:id="drilldates-01"> <gml:begin> <gml:TimeInstant gml:id="drilldates_begin-01"> <gml:timePosition>1999-08-01</gml:timePosition> </gml:TimeInstant> </gml:begin> <gml:end> <gml:TimeInstant gml:id="drilldates_end-01"> <gml:timePosition>1999-08-01</gml:timePosition> </gml:TimeInstant> </gml:end> </gml:TimePeriod> </my:dateOfDrilling> <my:inclinationType xlink:href="http://gin.geosciences.ca/def/inclinationtype/vertical" xlink:title="vertical"/> <my:boreholeMaterialCustodian> <cit:CI_Responsibility> <cit:role> <cit:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml" codeListValue="pointOfContact"/> </cit:role> <cit:party> <cit:CI_Organisation> <cit:name> <gco:CharacterString>Geological Survey of Canada</gco:CharacterString> </cit:name> </cit:CI_Organisation> </cit:party> </cit:CI_Responsibility> </my:boreholeMaterialCustodian> <my:purpose xlink:href="http://gin.geosciences.ca/def/purpose" xlink:title="groundwater monitoring"/> <my:dataCustodian> <cit:CI_Responsibility> <cit:role> <cit:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml" codeListValue="pointOfContact"/> </cit:role> <cit:party> <cit:CI_Organisation> <cit:name> <gco:CharacterString>Geological Survey of Canada</gco:CharacterString> </cit:name> </cit:CI_Organisation> </cit:party> </cit:CI_Responsibility> </my:dataCustodian> </my:BoreholeDetails> </my:indexData> </my:MyBorehole>

Annex C: NRCan without Dependency variation using SWE encoding

This example uses a DataArray (data is presented in an array) where some of the fields are identified as representing elements defined in BhML. <!--at this point, we don't use the BhML:BoreholeEventCollection:collectionMember --> <gwml:log> <swe:DataArray definition="http://www.opengis.net/def/gwml/2.0/coverage/geologyLog"> <swe:elementCount> <swe:Count> <swe:value>28</swe:value> </swe:Count> </swe:elementCount> <swe:elementType name="LogValue"> <swe:DataRecord definition="http://www.opengis.net/def/gwml/2.0/datarecord/earthMaterial"> <swe:field name="from"> <swe:Quantity definition="https://www.opengis.net/def/BoreholeML/FromToLocation/from"> <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m" xlink:title="m"/> </swe:Quantity> </swe:field> <swe:field name="to"> <swe:Quantity definition="https://www.opengis.net/def/BoreholeML/FromToLocation/to"> <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m" xlink:title="m"/> </swe:Quantity> </swe:field> <swe:field name="lithdesc"> <swe:Text definition="http://www.opengis.net/def/gwml/2.0/observedProperty/lithdesc"/> </swe:field> <swe:field name="lithclass"> <swe:Category definition="http://www.opengis.net/def/gwml/2.0/observedProperty/lithologyClass"/> </swe:field> </swe:DataRecord> </swe:elementType> <swe:encoding> <swe:XMLEncoding/> </swe:encoding> <!--actual values are here → <swe:values> <d:LogValue> <d:from>0.0</d:from> <d:to>11.8872</d:to> <d:lithdesc>Brownish Yellow,Till</d:lithdesc> <d:lithclass xlink:href="https://geoconnex.ca/def/lithology/gin/2a-1">Till</d:lithclass> </d:LogValue> <d:LogValue> <d:from>11.8872</d:from> <d:to>12.8016</d:to> <d:lithdesc>Gravel,Clayey</d:lithdesc> <d:lithclass xlink:href="https://geoconnex.ca/def/lithology/gin/2b">Gravel</d:lithclass> </d:LogValue> (...) Annex F: GWML Lithology Log encoding options This XML file shows three ways of encoding lithology (driller's logs) using GWML in BhML. It corresponds to the file available on GitHub : https://github.com/opengeospatial/boreholeie/blob/master/instances/CeRDI/CeRDI_BhML_GW _Well-26654.xml <?xml version="1.0" encoding="UTF-8"?> <!--This is an annotated example handcrafted by B. Simons 25/09/2019 It compares the Federation University (CeRDI) GroundWaterML2 WFS GML (GWML2) response with various BoreholeIE BhML encodings. The GWML2 WFS response is at: https://id.cerdi.edu.au/gwml2/feature/well/26654?f=xml This example contains encodings for : -a reference elevation (gwWellReferenceElevation) -three different encodings of lithology (driller logs): 1 defining the geological contact reference points (gsmlb:Contact) and specifying the lithologies (gsmlb:GeologicUnit) between them (only a single lithology value is included because of verbose encoding); 2 describing a /gwml2w:GW_GeologyLogCoverage (only a single lithology value is included because of verbose encoding) and the location of its start and end 3 a compact swe data array encoding (only two lithology values are included) --> <BhML:Borehole gml:id="feduni.well.26654" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:sam="http://www.opengis.net/sampling/2.0" xmlns:sams="http://www.opengis.net/samplingSpatial/2.0" xmlns:swe="http://www.opengis.net/swe/2.0" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gwml2w="http://www.opengis.net/gwml-well/2.2" xmlns:gwml2wc="http://www.opengis.net/gwml-wellconstruction/2.2" xmlns:gsmlb="http://www.opengis.net/gsml/4.1/GeoSciML-Basic" xmlns:om="http://www.opengis.net/om/2.0" xmlns:BhML="https://raw.githubusercontent.com/opengeospatial/boreholeie/master/schemas " xsi:schemaLocation="https://raw.githubusercontent.com/opengeospatial/boreholeie/master /schemas https://raw.githubusercontent.com/opengeospatial/boreholeie/master/schemas/BhML-Core.xsd http://www.opengis.net/gsml/4.1/GeoSciML-Basic http://schemas.opengis.net/gsml/4.1/geoSciMLBasic.xsd http://www.opengis.net/gwml-well/2.2 http://ngwdbdnes.cits.nrcan.gc.ca/service/gwml/schemas/2.2/gwml2-well.xsd http://www.opengis.net/samplingSpecimen/2.0 http://schemas.opengis.net/samplingSpecimen/2.0/specimen.xsd"> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://id.cerdi.edu.au/gwml2/feature/well /26654</gml:identifier> <gml:name codeSpace="http://www.vvg.org.au/">26654</gml:name> <gml:name codeSpace="http://www.vvg.org.au/">14</gml:name> <BhML:collection> <!--The first <BhML:collection> is the linear reference system information. --> <BhML:BoreholeEventCollection gml:id="feduni.well.26654.bhec1"> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://id.cerdi.edu.au/gwml2/feature/bore hole_event_collection/26654.bhec1</gml:identifier> <BhML:collectionLRS>

<BhML:BoreholeLRS gml:id="LRS1"> <!--<BhML:BoreholeLRS gml:id="LRS1"> is the linear referencing system for the borehole based on the casing standpipe as the starting point --> <gml:name>Casing Standpipe</gml:name> <BhML:accuracyStatement/> <BhML:precisionStatement/> <BhML:boreholeReferencingMethod> <BhML:BoreholeReferencingMethod> <BhML:name>relative</BhML:name> <BhML:unit xlink:href="http://qudt.org/vocab/unit/M" xlink:title="metre"/> </BhML:BoreholeReferencingMethod> </BhML:boreholeReferencingMethod> <BhML:linearElement> <BhML:BoreholeTrajectory> <!--This is the Borehole "trace", its x,y,z position as you follow the trajectory--> <BhML:curve> <gml:LineString gml:id="feduni.well.26654.shape" srsDimension="2" srsName="http://www.opengis.net/gml/srs/epsg.xml#4283"> <gml:posList>-38.287214 143.650349 164.5 -38.287214 143.650349 152.82</gml:posList> </gml:LineString> 157 </BhML:curve> </BhML:BoreholeTrajectory> </BhML:linearElement> <BhML:trajectoryReferent> <BhML:DistanceExpression> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0.00</BhML:distanceAlong> <BhML:trajectoryReferent> <BhML:TrajectoryReferent gml:id="TR1"> <gml:name>Well location</gml:name> <gml:name>Collar position</gml:name> <BhML:feature> <gwml2wc:BoreCollar> <gwml2wc:collarElevation uomLabels="metre">164.5</gwml2wc:collarElevation> </gwml2wc:BoreCollar> </BhML:feature> <BhML:position> <gml:Point srsDimension="3" srsName="urn:ogc:def:crs:EPSG::4979"> <gml:pos>-38.287214 143.650349 164.5</gml:pos> </gml:Point> </BhML:position> </BhML:TrajectoryReferent> </BhML:trajectoryReferent> <BhML:location/> </BhML:DistanceExpression> </BhML:trajectoryReferent> </BhML:BoreholeLRS> </BhML:collectionLRS> <BhML:collectionMember> <!--First BoreholeEvent is the constructed depth. Using xlink:href to specify what the property is that is located at this event. gwWellConstructedDepth has no additional information apart from a from-to depth --> <BhML:BoreholeEvent gml:id="be1"> <gml:name>constructed depth</gml:name> <BhML:locatedMember xlink:href="http://www.opengis.net/gwmlwell/2.2/gwWellConstructedDepth" xlink:title="gwWellConstructedDepth"/> <BhML:location> <BhML:FromToLocation> <BhML:fromPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">0</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:fromPosition> <BhML:toPosition> <BhML:MeasureOrEvent> <BhML:distanceAlong uom="http://qudt.org/vocab/unit/M">11.68</BhML:distanceAlong> </BhML:MeasureOrEvent> </BhML:toPosition> </BhML:FromToLocation> </BhML:location> </BhML:BoreholeEvent> </BhML:collectionMember> </BhML:BoreholeEventCollection> </BhML:collection> <!---1a. ########################## CONTACTS ################################--> <!--The 'CONTACTS' <BhML:collection> specifies the first two lithology boundaries (<gsmlb:Contact>) that occur in the borehole. The remainder (to 11.8m) have not been included. These <BhML:BoreholeEvent> are then used to specify the upper and lower depths of the lithology in the 'LITHOLOGY' section. --> <BhML:collection> Annex G: Construction log in BhML This XML file corresponds to the file available on GitHub : https://github.com/opengeospatial/boreholeie/blob/master/instances/CeRDI/CeRDI_BhML_Bore hole-26654.xml <?xml version="1.0" encoding="UTF-8"?> <!--This is an annotated example handcrafted by B. Simons 25/09/2019. It compares the Federation University (CeRDI) GroundWaterML2 WFS GML (GWML2) response with various BoreholeIE BhML encodings. The GWML2 WFS response is at: https://id.cerdi.edu.au/gwml2/feature/well/26654?f=xml This example contains encodings for : -a reference elevation (gwWellReferenceElevation) -a Screen (gwml2wc:Screen); -two Filters at the same depth from-to (gwml2wc:FiltrationComponent) --> <BhML:Borehole gml:id="feduni.well.26654" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:sam="http://www.opengis.net/sampling/2.0" xmlns:sams="http://www.opengis.net/samplingSpatial/2.0" xmlns:swe="http://www.opengis.net/swe/2.0" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gwml2w="http://www.opengis.net/gwml-well/2.2" xmlns:gwml2wc="http://www.opengis.net/gwml-wellconstruction/2.2" xmlns:gsmlb="http://www.opengis.net/gsml/4.1/GeoSciML-Basic" xmlns:om="http://www.opengis.net/om/2.0" xmlns:BhML="https://raw.githubusercontent.com/opengeospatial/boreholeie/master/schemas " xsi:schemaLocation="https://raw.githubusercontent.com/opengeospatial/boreholeie/master /schemas https://raw.githubusercontent.com/opengeospatial/boreholeie/master/schemas/BhML-Core.xsd http://www.opengis.net/gsml/4.1/GeoSciML-Basic http://schemas.opengis.net/gsml/4.1/geoSciMLBasic.xsd http://www.opengis.net/gwml-well/2.2 http://ngwdbdnes.cits.nrcan.gc.ca/service/gwml/schemas/2.2/gwml2-well.xsd http://www.opengis.net/samplingSpecimen/2.0 http://schemas.opengis.net/samplingSpecimen/2.0/specimen.xsd"> <gml:description>Complex example made of borehole construction elements (Screen and Filters) and lithology</gml:description> <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">https://id.cerdi.edu.au/gwml2/feature/well /26654</gml:identifier> <gml:name codeSpace="http://www.vvg.org.au/">26654</gml:name>

The OGC Geoscience DWG may also help in:

• Providing an umbrella that gathers geoscience data providers and consumers, which may help assess the usability of the BhML standard; and

• Induce the implementation of operational services based on geoscience data interoperability standards.

Annex D: Substitution in BhML model

This annex documents the substitution mechanism set up.

Element and type names (e.g., locatedGroundwaterObservationMember) are chosen in order to easily identify the BhML elements and types they are derived from (the dependency). The following snippets from the BhML Core schema (version 0.3.0) illustrate the mechanism to implement the "with dependency" approach. It requires adding an abstract base class for the LocatedMemberType as well as an abstract element that is derived from this class. This abstract element is now referenced in the BoreholeEventType and thus can be substituted by any element that is derived from the LocatedMemberType, for example the LocatedGroundwaterObservationMemberType.

Annex E: BhML-BML without dependency variation using SWE

The following code snippets illustrates a compact SWE-Encoding of hierarchical data, nested intervals, components and related geological information (e.g., Lithology) in this case.

The first one shows a pure BML based example of this. In the case of non-hierarchical plain data (tables), it is also possible to integrate or reference plain ascii files. The according data record or data array definition is exemplarily shown in the following code snippet. It illustrates the definition of a not further subdivisible component of a lithological interval.

The second snippet includes references to BhML semantics within BML content.