GWML2 GML Logical Model

• SVN (subversion) repository for GWML2 Logical Model: https://xp-dev.com/svn/gwml2

Issues - Resolved

I have prepared initial version of UML model for GWML 2.0. I think it is good start point for discussion about our further works. It in EAP file is attached below ( GW2IE_GWML_v2.0.initial.zip ). All class diagrams are in docx file ( GWML_v.2.0.initial_Diagrams.docx ).

-- JanuszMichalak - 08 Apr 2013

I've attached a zipped version of the xmi for the GWML2 logical model that we produced at Vienna. This still requires checking all the stereotypes, tagged values (including sequenceNumber) and association types prior to generating the XSD.

-- BruceSimons - 13 May 2014

---

Springs - Resolved

Some issues with the GW_Spring feature in the logical model:

What is the SpringConstruction data type? RESOLVED (see below)

What is the Geology Data type ( = GeoSciML:GeologicUnit?) RESOLVED (GeoSciML:GeologicFeature)

-- BruceSimons - 15 May 2014

Spring types are shown in the figure below, taken from Fetter C.W. 2001 Applied Hydrogeology, 4th ed., Prentice Hall

The Spring Geology relates to the geological outcrop at the eye of the spring. For example, the Contact Spring has a different geological unit above and below the spring.

The Spring Construction refers to the modification made at the spring eye, for example the addition of a hand pump, or bore, or concrete pit into which the spring flows, etc.

-- PeterDahlhaus - 15 May 2014

At the moment the UML has a single GeoSciML:GeologicUnit data type. From Peter's discussion this should probably be changed to GeoSciML:GeologicFeature with 0..* cardinality. This would enable describing the geology at the Spring fully (all GeologicUnits, their relationships to each other as well as any associated Geologic Structures such as faults Joints etc). DONE

-- BruceSimons - 15 May 2014

Can we reuse WellConstruction ? I think so, but someone who knows about 'Spring Constructions' should check against the UML. -- BruceSimons - 15 May 2014 RESOLVED (See below)

-- EricBoisvert - 15 May 2014

---

Resolved Logical Model Issues

Known issues that need fixing prior to XSD generation:

1. Circularity between Core and Wells. I'm not sure why GroundWaterML2 -Core is importing GroundWaterML -Well. The circularity needs to be removed somehow.
   • TO DO: Francois to review and advise at June 25 meeting [BB 2014-06-10]
   • TO DO: Well and Spring contain references to Core -- TBD [BB 2014-06-25]
   • TO DO: to be reviewed by Francois / Bruce [BB 2014-07-07]
   • RESOLVED: Generated new dependency diagrams and all 'looks' OK. Deleted dependency between gwml:Well and GeoSciML:Borehole (presuming it was left over from Conceptual Model) [BS 2014-07-08]
   • 
2. GW_Spring:gwSpringConstruction data type needs sorting out. Should it point to GroundWaterML2 -WellConstruction feature WellConstruction?
   • RESOLVED: data type = AnyType; range of this property is too wide to fix to a limited set of terms, so opted for maximum flexibility [BB 2014-06-10]
3. GroundWaterML2 -WellConstruction feature property types and tagged values have not been fully checked.
   • RESOLVED: by Francois during Full-moon XSD generation [BB 2014-06-10]

-- BruceSimons - 15 May 2014

---

More issues in the Logical Model:

• missing: def for gwConductivityConfinement
  • RESOLVED: not missing [BB 2014-06-10]
• missing: GW_FluidBodyChange in LM 1.0?
  • RESOLVED: not included, bad fit to use-cases... will test without and re-evaluate [BB 2014-06-10]
• removed: mixture type constraints for MaterialConstituent and BiologicConstituent
  • seemed too restricted, e.g. materials could be any non-solute (emulsions, colloids, precipitates, etc.)
  • questionable whether applies to biologic ?
  • set multiplicity to [0...1] ?
  • RESOLVED: changes accepted--removal of mixture and state constraints from constituent subtypes [BB 2014-06-10]
• use O&M for constituent values
  • then GW_ChemicalConstituent, etc., are features-of-interest for the observation,
  • RESOLVED: [BB 2014-06-10]
    • GW_ChemicalConstituent is FOI with ChemicalTypeTerm = "As", ObservedProperty is As_Concentration
    • distinguishes between different mixtures or states for the same constituent type
    • distinguishes between different measurement types, i.e. not just concentration
    • enables relations between constituents

-- BoyanBrodaric

More issues in the Logical Model:

• GW_ManagementArea:gwAreaYield property has description:
  "Type of yields (of the aquifer or management area): e.g. specific yield, safe yield, license yield etc. but excludes well yield. TBD"
  However, the DataType is OM_Measurement, indicating it should be the actual yield measurement (value).
  Do we need another property capturing the gwYieldType, or do we intend using the OM_Observation:parameter property to capture the yield type?
  • RESOLVED: we discussed using the parameter property for all such attributes [BB - 2014-06-04]
• What is GW_ManagementArea:gwAreaWaterBudget for? There are no notes in the Logical Model.Does this relate to GW_ManagementArea:gwAreaYield?
  • RESOLVED: this is a water budget for the management area (which can be distinct from an aquifer); not yield, it represents the net flow balance in the area [BB - 2014-06-04]
• I'm not sure how to encode administrative licencing information (e.g. licence under which drilling took place). The MD_Metadata model looks like it only deals with data release licencing. Do we need a GW_Well:gwLicence property?
  • TO DO: Francois and Bruce to review and advise at next meeting (June 25) [BB 2014-06-10]
    • TO DO: review Regulation package and possible inclusion of ManagementArea [BB 2014-06-25]
    • PROPOSAL: [FL 2014-06-25]:
      
      • 

The Regulation package should enable:

• Identifier of the licence to extract groundwater;
• The amount of groundwater that may be extracted under the licence;
• Identifier of the licence to use groundwater;
• The amount of groundwater that may be used under the licence;
• I understand that these licences may be associated with either individual water wells, springs, collections of wells, management areas or aquifers.
• PROPOSAL: [BS 2014-07-07]
  1. Incorporate GW_Licence into GW_ManagementArea;
  2. Rename 'GW_ManagementArea' to GW_ManagementFeature'
     • 
  3. Redefine GW_ManagementFeature:
     • "Area of ground, spring, water well, collection of water wells, or aquifer identified for groundwater management purposes and can be delineated by human factors such as policy or regulation concerns, as well as hydrogeological or hydrological concerns. Does not necessarily align exactly with hydrogeoogical or hydrological boundaries."
  4. Move GW_ManagementFeature to Regulation package (The proposed GWML2-Regulation package would be dependent on GWML2-Core. Therefore would need to make GW_HydrogeoUnit:gwManagementArea property byReference to avoid circularity)
• TO DO: to be revised as per below by Bruce / Francois [BB 2014-07-07] DONE [BS 2014-07-08]
  • do not rename GW_ManagementArea
  • include GW_Licence in Core package, remove Regulation package
  • add valid time variable to GW_Licence
  • add relations between GW_Licence and geohydrounit, wells, springs, management area
• RESOLVED [BS 2014-07-08]
  • Moved GW_Licence to GWML2-Core
  • Changed GW_Licence steretype to DataType
  • renamed associatedGWVolume to gwAssociatedGWVolume, changed Scope to 'Public', set sequenceNumber =3, set stereotype to <<property>>, <<voidable>>,
    
  • renamed licenceID to gwLicenceID, changed Scope to 'Public', set sequenceNumber =1, set stereotype to <<property>>, changed DataType from 'char' to 'CharacterString'
    
  • renamed purpose to gwPurpose, changed Scope to 'Public', set sequenceNumber =2, set stereotype to <<property>>, <<voidable>>, changed DataType from 'char' to 'CharacterString'
  • Added GW_Licence:gwTimePeriod, DataType = TimeRange
  • Added GW_ManagementArea:gwAreaLicence, sequenceNumber = 9
  • Added GW_Well:gwWellLicence, DataType = GW_Licence, sequenceNumber = 14 (renumbered gwWellGeology sequenceNumber to 15)
    • TODO: Should GW_Licence also be used for the 'licence to drill'? If so gwAssociatedGWVolume to use nilReason = 'inapplicable'?
      
    • RESOLVED: changed to 0...n cardinality for multiple different types of licences [BB 2014-07-30]
  • Added GW_Spring:gwSpringLicence, DataType = GW_Licence, sequenceNumber = 11
  • NOTE: Didn't add GW_Licence to GW_HydrogeoUnit (covered by GW_ManagementArea:gwAreaLicence)
• RESOLVED [FL 2014-07-09]
  • Removed Regulation applicationSchema

-- BruceSimons - 07 Jul 2014

• ScreenComponent:nominalscreenDiameter property has description:
  "Value of the nominal screen diameter (thickness of the screen rim)."
  The part in brackets is confusing suggesting it is the same as the screenThickness ("Thickness of the screen walls.") Presumably it is meant to represent the outside diameter of the screen?
  • RESOLVED: refers to external diameter; renamed to ScreenComponent:screenExternalDiameter [BB 2014-06-10]
• CasingComponent:nominalPipeDimension property has description:
  "Value of the pipe dimension of the casing."
  Presumably this is meant to represent the outside diameter of the casing. Rename property to outsideCasingDiameter (or inside if that is more common)).
  • TO DO: proposal: change to external diameter and rename casingExternalDiameter? [BB 2014-06-25]
  • RESOLVED: see below, Jessica's comment.
• Casing and Screen components have a diameter (dimension) property and a thickness property. Should we have inside and outside diameters instead to avoid confusion asto which diameterit is (which is what NGIS has)?
  • RESOLVED: see above. [BB 2014-06-25]

-- BruceSimons - 03 Jun 2014

Following up on the screen dimensions question. In our national database (NWIS) we record the length of the screen and a single diameter. Most often this is the inner diameter, but sometimes people enter the outer diameter. This is obviously a problem for data interpretation. The screen thickness is not recorded.

• • TO DO: proposal: include both internal and external diameter, voidable [BB 2014-06-25]
    • it seems our dbs contain every possible combination of inner / outer diameter and thickness
  • RESOLVED: include all of external diameter, internal diameter, and thickness; all voidable; for screen and casing, e.g. "casingExternalDiameter"; all datatype = Quantity. To be changed by Bruce / Francois [BB 2014-07-07] DONE [BS 2014-07-08]
    
  • Changed screenThickness to screenWallThickness
  • Changed CasingComponent:casingPipeDimension to casingExternalDiameter
  • Added CasingComponent:casingInternalDiameter
    
  • Re-ordered CasingComponent properties sequenceNumbers
  • Added ScreenComponent:screenInternalDiameter
  • Re-ordered ScreenComponent sequenceNumbers
  • Added <<property>>, <<voidable>> stereotypes
  • TODO: Check and add appropriate stereotypes and tagged values to all properties (Francois)
    
  • RESOLVED: done [BB 2014-07-30]

-- JessicaLucido - 13 Jun 2014

• GW_HydrogeoUnit/gwUnitDischarge can contain both GW_Recharge and GW_Discharge (because it points to the parent class). Rename property to "flow" and allow recharge and discharge and interflow in a single property or constrain gw_UnitRecharge and gw_UnitDischarge properly ?
  • TO DO: proposal: hydrogeoUnit discharge/recharge should have datatype GW_Discharge / GW_Recharge [BB 2014-06-25
  • RESOLVED: accepted. To be changed by Bruce / Francois [BB 2014-07-07] DONE [BS 2014-07-08]
• GW_WaterBudget has gwBudgetDischarge and gwBudgetRecharge both with data types GW_InterFlow.
  • To DO: Should these be changed to GW_Discharge and GW_Recharge? [BS 2014-07-09]
  • RESOLVED: changed to GW_Discharge and GW_Recharge? [BB 2014-07-30]
• 
• properties are ordered alphabetically, therefore you have (in the XML document), gwUnitDischarge, then unitMedia, then Recharge. not a huge issue, just not intuitive.
  • TO DO: proposal: correct sequence of properties to conform to UML [BB 2014-06-25]
  • RESOLVED: accepted. To be changed by Bruce / Francois [BB 2014-07-07] DONE [BS 2014-08-07]
• GW_FluidBody/gwBodyDescription is redundant since Feature already have gml:description
  • TO DO: proposal: remove gwBodyDescription [BB 2014-06-25]
  • RESOLVED: accepted. To be changed by Bruce / Francois [BB 2014-07-07] DONE [BS 2014-08-07]
• Hydrogeounit cannot be part of an aquiferSystem.
  • _RESOLVED: not changed, prevents Basin from being part of AquiferSystem; HydrogeoUnit made abstract... to be tested [BB 2014-06-10]
• Encoding of GW_WaterWell.shape. It's a line string representing the path of the line. Many options with various pros and cons. 1D = simple, 3D relative = verbose, but can handle non vertical, 3D absolute also, but issue with coordinate mix (degree and meters, so 2 EPSG required)
  • 1D relative to collar <gml:LineString gml:id="ab.ww.402557.shape.1" srsDimension="1" srsName="#ab.ww.402557" axisLabels="depth"><gml:posList>0.00 11.58</gml:posList></gml:LineString>
  • 3D relative to collar <gml:LineString gml:id="ab.ww.402557.shape.1" srsDimension="3" srsName="#ab.ww.402557" axisLabels="depth"><gml:posList>0.00 0.00 0.00 0.00 0.00 11.58</gml:posList></gml:LineString>
  • 3D absolute <gml:LineString gml:id="ab.ww.402557.shape.1" srsDimension="3" srsName="EPSG:4326 EPSG:XXXX" axisLabels="depth"><gml:posList>49.671622 -114625045 0.00 49.671622 -114625045 1725.78</gml:posList></gml:LineString>
  • TO DO: TBD [2014-06-25]
  • TO DO: Eric to review [BB 2014-07-07]
    • CR sent by is a slightly different but related issue. The case they describe is where the shape of the borehole is actually describe is absolute 3D and the shape used by MappedInterval refers to the LineString as a relative SRS. In GWML 2.0, we don't use geometries in LogInterval, but from/to pair (note, GeoSciML 4 changed MappedInterval to from/to as well). So, if we follow the GeoSciML pattern, bore path should be defined in Absolute 3D (see this example)
  • RESOLVED: encoded as 3D absolute, following GeoSciML [BB 2014-07-30]
• Total well depth = total well length
  • RESOLVED: in wells Bruce/Francois rename wellTotalDepth to wellTotalLength [BB 2014-07-07] DONE [BS 2014-08-07]
• Borehole has logElement that interferes with GW_Well Discrete coverage encoding for logs (will need a requirement clause in the documentation)
  • TO DO: TBD [2014-06-25]
    • I'm not sure what the problem is here. The only 'Borehole' I can find in GWML2-Well is gwWellConstruction:Borehole that is from GWML2-WellConstruction, not GeoSciML;Borehole. Therefore there is no link to GeoSciML:logElement [BS 2014-07-08]
  • RESOLVED: changed to GWML2 Borehole construction type [BB 2014-07-30]
• GW_Well/gwWellTotalLength is of type Observation. A full observation ? really ?
  • TO DO: TBD, note: current datatype = OM_Measurement) [BB 2014-06-25]
  • RESOLVED: Changed to DataType = swe:Quantity (based on externalDiameter discussion 2014-07-07 [BS 2014-08-07]
    

-- EricBoisvert - 09 Jun 2014

OK, one more problem in the logs. We are supposed to override CV_ElementValuePair "à la WaterML 2.0" and replace it with out LogValue (which remove the geometry and replaces it with fromDepth/toDepth).

<gww:GW_GeologyLog gml:id="ab.ww.402557.log.1">
         <om:phenomenonTime>
            <gml:TimeInstant gml:id="ab.ww.402557.log.1.ph">
               <gml:timePosition>1981-09-12T00:00:00</gml:timePosition>
            </gml:TimeInstant>
         </om:phenomenonTime>
         <om:resultTime>
            <gml:TimeInstant gml:id="ab.ww.402557.log.1.rs">
               <gml:timePosition>1981-09-12T00:00:00</gml:timePosition>
            </gml:TimeInstant>
         </om:resultTime>
         <om:procedure xsi:nil="true" nilReason="unknown"/>
         <om:observedProperty xlink:href="http://some.vocab.org/WaterWell/Lithology" xlink:title="Lithology"/>
         <om:featureOfInterest xsi:nil="true" nilReason="missing"/>
         <om:result>
            <cv:CV_DiscreteElementCoverage>
               <cv:domainExtent>
                  <gmd:EX_Extent>
                     <gmd:description>
                        <gco:CharacterString>Extent of the log</gco:CharacterString>
                     </gmd:description>
                  </gmd:EX_Extent>
               </cv:domainExtent>
               <cv:rangeType xlink:href="http://nil"/>
               <cv:element>
               <!-- this bit should be a LogValue -->
                  <cv:CV_ElementValuePair>
                     <cv:geometry/>
                     <cv:value/>
                  </cv:CV_ElementValuePair>
               </cv:element>
            </cv:CV_DiscreteElementCoverage>
         </om:result>
      </gww:GW_GeologyLog>

right now, the xsd force a CV_ElementValuePair. Peter Taylor sent me some documentation on how to override this constrain, which I'm the process of reading.

• • RESOLVED: manually change XSD to replace CV_ElementValuePair with LogValue [BB 2014-06-25]
• Also, there is a result property between GW_GeologicLog and CV_DiscreteElementCoverage that duplicates OM_Observation's result (GW_GeologicLog is a subtype of OM_Observation)
  • TODO: Resolve duplicate Result property
  • RESOLVED: [BB 2014-07-30]
• endDepth and startDepth property are in inverse order (more logical to have start and end)
  • TO DO: proposal: change end start order; TBD--result property [BB 2014-06-25]
  • RESoLVED: [BS 2014-07-08]
    

-- EricBoisvert - 13 Jun 2014

gwUnitVulnerability

GW_HydrogeoUnit:gwUnitVulnerability (description = "The susceptibility of the aquifer to specific threats such as various physical events (earthquakes), human processes (depletion), etc.")
has a data type OM_Measurement.

Will the result be a swe:Quantity or a swe:QuantityRange or either?

Will the type of vulnerability be specified using om:observedProperty (om:observedProperty = "earthquake vulnerability"?)?

• TO DO: TBD--result datatype; proposal: as per the pattern, soft types to be represented with om:observedProperty [BB 2014-06-25]
• RESOLVED: changed to OM_Observation [BB 2014-07-30]

-- BruceSimons - 23 Jun 2014

gwVoidHostMaterial

The description of gwVoidHostMaterial has "The material that hosts the void. Note voids can be hosted by a unit (an aquifer) or its material (e.g. sandstone).". The DataType associated with gwVoidHostMaterial is gsml:EarthMaterial, which does not allow using gwml2:Aquifer.

• TO DO: proposal: do not change model, but reword gwVoidHostMaterial definition to reflect model: [BB 2014-06-25]

"The material that hosts the void. Note voids are always hosted by an unit (e.g. an aquifer) and can sometimes be specifically hosted by a particular material in the unit (e.g. sandstone)."

• RESOLVED: SUGGEST FOLLOWING: [BS 2014-07-07]

"The material that hosts the void. Note voids are always hosted by an unit (e.g. an aquifer) specified by the gwVoidUnit property. gwVoidHostMaterial allows describing a particular material in the unit (e.g. sandstone) that is hosting the void."

-- BruceSimons - 23 Jun 2014

GW_BodySurface

GW_BodySurface has an (unspecified) mandatory association with GW_FluidBody. This makes sense and should be formally specified in the model (cardinality = 1..1).

GW_Divide has an (unspecified) mandatory association with GW_FluidBody. Should a divide be between two fluid surfaces (2.2), can it be a divide within a single surface (1..2) or even not be related to any fluid body surfaces (0..2)?

• RESOLVED: unchanged. [BB 2014-07-30]

-- BruceSimons - 07 Jul 2014

GW_Well

• GW_Well has a gwWellProperty that duplicates relatedObservation property (inherited from SamplingFeature)
• RESOLVED: duplicate removed [BB 2014-07-30]

OM_Measurement

• TO DO: Replace OM_Measurement Data Type with OM_Observation [BS 2014-09-07]

• RESOLVED: done for Vulnerability, otherwise remainder are quantities, non-categorical [BB 2014-07-30]

GW_FlowSystem

• GW_FlowSystem.gwFlowSystemPart is unidirectional (parent -> child), therefore, cannot tell parent system from sub system , Also, do we assume that a child system can only be part of 0..1 parent (as opposed to 0..*) ? [EB 2014-07-10]
• RESOLVED: all parts to be made bi-directional [BB 2014-07-30]

GW_MonitoringSite

• Should be subclass of SF_SamplingFeature - (or shall we use WaterML 2.0 MonitoringPoint ?) [EB 2014-07-10]
• RESOLVED: used SF_SamplingFeature [BB 2014-07-30]

GW_GeologyLog

• In scope note of GW_GeoloyLog "For Stratigraphic logs the observedProperty will be a GeoSciML:GeologicUnit/name. For Lithologic logs the observedProperty will be a GeoSciML:GeologicUnit/composition/CompositionPart/material." This implies that logs are either all lith or all units (because this is stated at the GeologyLog level). We all know it's not true (I often see Clay,Sand,Gravel,XXX Group).
• LogValue value property in the UML is of type Record (swe:Record). FullMoon transformed it into a CodeType (a String + codeSpace). Record is a softype structure to organise content. Not sure what is the original intent, just keep a String (so, fix the UML) or we really want a Record (fix the UML->XSD). [EB 2014-07-16]
• RESOLVED: create a realisation on CV_DiscreteCoverage (GW_GeologyLogCoverage) to implement the realisation. *[EB 2014-07-16]*

Requirements

Draft proposed requirements at LogicalModelRequirements

• TO DO: "GWML-Core" package name conflicts with "Core" requirements.Proposal rename package to one of: "GWML2-Groundwater", "GWML-Hydrogeology", "GWML-GW", "GWML2-Main"
• RESOLVED: rename to "GEML2-Nucleus" [BB 2014-07-30]

GW_Geology_Log Record encoding

Here's how a Record works in SWE. Actually, swe calls it a DataRecord which is an encoding of ISO 11404 Record.

<?xml version="1.0" encoding="UTF-8"?>
<gww:LogValue xmlns:gww="http://www.opengis.net/gwml-well/2.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:sam="http://www.opengis.net/sampling/2.0" xmlns:sams="http://www.opengis.net/samplingSpatial/2.0" xmlns:gu="http://xmlns.geosciml.org/GeologicUnit/3.2" xmlns:gwml2="http://www.opengis.net/gwml-core/2.0" xmlns:gwml2f="http://www.opengis.net/gwml-flow/2.0" xmlns:gsmlem="http://xmlns.geosciml.org/EarthMaterial/3.2" xmlns:gsml="http://xmlns.geosciml.org/GeoSciML-Core/3.2" xmlns:gsmlpp="http://xmlns.geosciml.org/PhysicalProperties/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:swe="http://www.opengis.net/swe/2.0" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:bh="http://www.opengis.net/gwml-wellconstruction/2.0" xmlns:cv="http://www.opengis.net/cv/0.2/gml32" xmlns:om="http://www.opengis.net/om/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/gwml-well/2.0 file:///T:/apache-tomcat-6.0.36/InstanceRies/webapps/service/gwml/schemas/gwml2-well_rec.xsd">
   <gww:fromDepth>
      <swe:Quantity>
         <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m"/>
         <swe:value>0.30</swe:value>
      </swe:Quantity>
   </gww:fromDepth>
   <gww:toDepth>
      <swe:Quantity>
         <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m"/>
         <swe:value>4.27</swe:value>
      </swe:Quantity>
   </gww:toDepth>
   <gww:value>
      <swe:DataRecord definition="http://this.is.where.the.schema.is.defined" id="a">
         <swe:field name="lithology">
            <swe:Text>
               <swe:value>Soil</swe:value>
            </swe:Text>
         </swe:field>
      </swe:DataRecord>
   </gww:value>
</gww:LogValue>

Note the gww:value bit. it contains a DataRecord with a definition attribute. This must contain a URI that leads to "the semantic definition of the precise nature of the component.", ie, to the schema, that can be described using SWE (defined in 08-094r1). There are lot of possibilities, for instance, replace the bland text with a category

<gww:value>
      <swe:DataRecord definition="http://this.is.where.the.schema.is.defined" id="a">
         <swe:field name="lithology">
            <swe:Category definition="ref to definition of EarthMaterial catagory">
               <swe:codeSpace xlink:href="geosciml codespace"/>
               <swe:value>Soil</swe:value>
            </swe:Category>
         </swe:field>
      </swe:DataRecord>
   </gww:value>

The definition of the schema (definition attribute) can be imposed in the spec and defined formally in a registry (like a vocabulary). This allows group to add their own structure an register their structure without changing the schema of GWML.

• RESOLVED: use swe:DataRecord as datatype [BB 2014-07-30]

-- EricBoisvert - 23 Jul 2014

Borehole

• RESOLVED: accepted as below [BB 2014-07-30]
  • Borehole should also be a SF_SamplingCurve
  • Borehole would then have a shape to encode the geometry of the bore, required for non linear bores. If well and borehole share the same shape, borehole can refer to well's shape using <shape xlink:href="#well_shape"/>.

-- EricBoisvert - 28 Jul 2014

Well::LogValue:value/DataRecord:field/AnyData is swe 1.0 - Resolved

The DataRecord used for GSML2:WellLogValue:value is a swe 1.0 class. I think it should be the swe 2.0 equivalent. If so, the DataRecord:field property should use the AbstractDataComponent DataType rather than the AnyData DatatYpe we are currently using.

-- BruceSimons - 29 Sep 2014

Could you clarify, my example validates with SWE 2.0

<?xml version="1.0" encoding="UTF-8"?>
<swe:DataRecord xmlns:swe="http://www.opengis.net/swe/2.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" definition="http://www.opengis.net/def/gwml/2.0/datarecord/earthMaterial" id="le.1" xsi:schemaLocation="http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd">

   <!-- this field is mandatory, the definition is the normative flag to identify this category has having the earthMaterial-->
      <swe:field name="lithology">
         <swe:Category definition="http://www.opengis.net/def/gwml/2.0/observedProperty/earthMaterial">
            <swe:codeSpace xlink:href="http://resource.geosciml.org/classifierscheme/cgi/201211/simplelithology"/>
            <swe:value>Soil</swe:value>
         </swe:Category>
      </swe:field>
   <!-- this field is specific to this data provided -->
      <swe:field name="description">
         <swe:Text definition="http://www.opengis.net/def/gwml/2.0/datarecord/FreeText">
            <swe:value>Free text description of the soil unit</swe:value>
         </swe:Text>
      </swe:field>

</swe:DataRecord>

-- EricBoisvert - 29 Sep 2014

Optional vs. Mandatory (Nillable) properties - Resolved

Background

The intention of having mandatory properties in the UML is to show where properties are required for the model to be logically consistent. So, for example, a pore space or void (GW_HydrogeoVoid) must have some surrounding material (the GW_HydrogeoUnit) so the property identifying the surrounding material (gwVoidUnit) has a cardinality of 1..*, but the material need not contain voids, so the reverse property (gwUnitVoid) has a cardinality of 0..1. Similarly, a void may contain a fluid (the property gwVoidFluidBody with cardinality 0..1) but the fluid must be contained by voids (gwFluidBodyVoid cardinality of 1..1).

Similarly, it is logically consistent for a spatial feature, such as the GW_ManagementArea to have a geometry property (gwAreaShape), or for fluids to have physical properties.

In order for data providers who may not be able to meet these mandatory requirements for a number of reasons (such as missing, confidential or unknown data), the mandatory values may be voidable. So in the UML there are 3 cases:

1. The property is logically expected and not voidable {For example GW_ManagementArea/gwAreaShape}
2. The property is logically expected but voidable {For example GW_ManagementArea/gwAreaFeature}
3. The property is appropriate, but it may or may not be present {For example GW_ManagementArea/gwAreaMetadata}

The Issue

The logical model cardinalities represent the conceptual requirements "and these would be used as constraints (say, schematron) for data exchange scenarios: ‘your submitted data is not acceptable as it does not include values for the following properties: …’ (AlistairRitchie 2014).

However, it does not meet the use case where the end-user may just be interested in a single property, such as the name of the GW_Aquifer or the management area licence. Using the current GWML2 implementation all mandatory properties, including those which are voidable, will need to be returned, which substantially increases the volume of XML being delivered. This may be inappropriate for some applications, such as mobile devices.

With all properties optional, the user can query the WFS using the request=GetFeature, typeName={feature}, propertyName={attribute} to limit the content. For example requesting the complete GW_Well feature

[WFS URI]?service=wfs&version=2.0.0&request=GetFeature&count=1&typename=gww:GW_Well would return (with lots deleted at <snip>):

<gml:featureMember>
        <gww:GW_Well gml:id="feduni.borehole.51409">
            <gml:description>SOBN bore</gml:description>
            <gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">http://groundwater.feduni.edu/borehole/feduni/51409</gml:identifier>
            <gml:name codeSpace="http://groundwater.feduni.edu/waterwell/oldboreid">093</gml:name>
            <gml:name codeSpace="http://groundwater.feduni.edu/waterwell/borecode">119330</gml:name>
            <gml:name codeSpace="http://groundwater.feduni.edu/waterwell/localborename">Ballarat 9037</gml:name>
            <gml:boundedBy>
                <gml:Envelope srsName="EPSG:4939">
                    <gml:pos srsDimension="2">139 -32</gml:pos>
                    <gml:pos srsDimension="2">143 -37</gml:pos>
                </gml:Envelope>
            </gml:boundedBy>
            <sam:sampledFeature xlink:href="http://groundwater.feduni.edu/hydrogeologicunit/feduni/feduni.hydrogeologicunit.newervolcanics" xlink:title="Newer Volcanics" xlink:role="stratigraphic name"/>
         <sam:relatedObservation>
                 <om:OM_Observation gml:id="feduni.borehole.51409.observation.44574.32328">
                     <om:phenomenonTime>
                        <gml:TimeInstant gml:id="feduni.borehole.51409.observation.44574.time">
                            <gml:timePosition>1997-07-14+12:00:00</gml:timePosition>
                        </gml:TimeInstant>
                    </om:phenomenonTime>
                    <om:resultTime xlink:href="#feduni.borehole.51409.observation.44574.time"/>
                    <om:procedure xlink:title="PUM"/>
                    <om:parameter>
                        <om:NamedValue>
                            <om:name xlink:href="http://www.opengis.net/req/gw_well/waterwell_sf_fromParam" xlink:title="from"/>
<snip>
                    <gww:endDepth>
                        <swe:Quantity>
                            <swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m"/>
                            <swe:value>11.58</swe:value>
                        </swe:Quantity>
                    </gww:endDepth>
                </gww:GW_GeologyLog>
            </gww:gwWellGeology>
        </gww:GW_Well>
    </gml:featureMember>

Whereas selecting only a single property via [WFS URI]?service=wfs&version=2.0.0&request=GetFeature&count=1&typename=gww:GW_Well&propertyName=gml:name would return:

<gml:featureMember>
        <gww:GW_Well gml:id="feduni.borehole.51409">
            <gml:name codeSpace="http://groundwater.feduni.edu/waterwell/oldboreid">093</gml:name>
            <gml:name codeSpace="http://groundwater.feduni.edu/waterwell/borecode">119330</gml:name>
            <gml:name codeSpace="http://groundwater.feduni.edu/waterwell/localborename">Ballarat 9037</gml:name>
   </gww:GW_Well>
 </gml:featureMember>

However, with mandatory properties this second response would not be XML schema valid.

Proposal

The proposal is to change all mandatory properties to optional. This would require:

• systematically working through the GWML2 logical model and changing all 1..x cardinalities to 0..x;
• change all minOccurs="1" to minOccurs="0" in all the GWML2 schema;

An alternative is to only change some properties from mandatory to optional. However, given the three criteria currently used to determine cardinality (see 'Background' above), it is not clear what further criteria could be used to determine which properties should remain mandatory.

Concerns

1. If all properties are optional, how do we meet the data exchange use case? Do we need two logical models and associated schema to identify the properties that should be mandatory for data exchange and another set for the optional view;
2. Is schema validation a necessary requirement for the optional use case?
3. Mandatory properties inherited from imported features (OM_Observation, GeologicUnit, etc) will still be mandatory, so a single property response is still likely to be XML schema invalid.

Given these concerns, is the best option to leave the model as is and just recognise that some uses of GWML2 will use invalid XML schema responses?

-- BruceSimons - 17 Nov 2014 {This proposal and the issues presented here resulted from a number of conversations with AlistairRitchie of Landcare Research NZ}

>If all properties are optional, how do we meet the data exchange use case?

Ok, here a proposition, Maybe the pattern should be

• XSD is essentially there to control the syntax "If you have this property, this is where is goes". All properties are optional.
• Use case requirements are expressed in a Rule based languages, such as Schematron. Since there are so many possible use cases, schematron (or whatever) is probably the best way to express rules for particular uses case. So, one use case is defined by a series of rules regarding expected content to fullfill the use case.
• Schema validation is there to ensure that stuff is at the right placs (if present). Schematron (or whatever) is there to check if the stuff needed for a use case is there.
• It also means that we should be sure that "InlineOrByReference" is alway "both", an let the use case decide.
• Mandatory properties inherited from imported features : There is actually a way to override (redefine) cardinality in XSD : see http://wiki.services.eoportal.org/tiki-view_forum_thread.php?comments_parentId=1370&display=print - never tried it, but apparently XSD leggit.

My two snowy cents.

-- EricBoisvert - 18 Nov 2014

Quite elegant. Allows meeting multiple use cases by using Schematron rather than attempting to use schema profiling. Adds an extra 'layer' in the validation process, but I think this is a good thing as it separates the structure validation, from the content validation, where content is both the presence or absence of a property, as well as its value.

-- BruceSimons - 24 Nov 2014

Outstanding Logical Model Issues

• CM: part role names and cardinalities require editing
• CM: needs GW_Licence class
• LM: well construction package needs documentation

Downhole Observations

How should we encode downhole GW_FluidBody and GW_HydrogeoUnit observations?

GW_Well has:

gwWellBody to describe (either in-line or byReference) the GW_FluidBody. This could include observations on the chemistry of the fluid body at certain depths down the well.

gwWellUnit to describe (either in-line or byReference) the GW_HydrogeoUnit. This could include descriptions of the lithology or stratigraphy at certain depths down the well.

gwWellGeology to describe how a property (such as lithology, stratigraphy or hydrochemistry) varies down the well by using OM_Observation.

The problem is how to specify the depths that the GW_FluidBody and GW_HydrogeoUnit occur down the well.

I propose that for GW_HydrogeoUnit:

• gwWellGeology is used to specify the depths for the geological information (lithology, stratigraphy), with the om:featureOfInterest the GW_HydrogeoUnit
• gwWellUnit may also provide geological information (lithology, stratigraphy) via the inherited GeoSciML GeologicUnit. Normally this would be the more general description of the GW_HydrogeoUnit from numerous wells and outcrops, but may be just for this GW_Well. If so, it would duplicate the gwWellGeology result.
• GW_HydrogeoUnit has its spatial representation specified by the GeoSciML occurrence:MappedFeature property. Where the GW_HydrogeoUnit is only known from this well then the MappedFeature geometry (gml:LineString) should be the GW_HydrogeoUnit depth down the well, with the gsml:MappedFeature/gsml:shape, its srsName and gsml:samplingFrame all being the GW_Well:shape.
• This will allow linking the downhole geological observations to any descriptions of the other geological and hydrogeological properties of the GW_HydrogeoUnit

For GW_FluidBody the same as GW_HydrogeoUnit would apply (chemical observations downhole as gwWellgeology with the featureOfInterest the GW_FluidBody) except that:

• GW_FluidBody does not have gsml:MappedFeature/gsml:shape but has gwml2:gwBodyShape (datatype = GM_Object). So where we are only describing the GW_FluidBody in this particular well, the gwml2:gwBodyShape should be the GW_FluidBody depth down the well, with the gwml2:gwBodyShape gml:LineString and srsName being the GW_Well:shape.
• This will allow linking the downhole fluid body observations to descriptions of the the GW_FluidBody. This is necessary to be able to describe for example the chemical constituents at a particular depth ( a feature view rather than an observation view).

-- BruceSimons - 20 Aug 2014

GW_FluidBody - GW_Mixture

For GWFluidBody, gwBodyConstituent/GW_Mixture describes the individual 'groups' of constituents (biological, chemical or material) based on their mixture status (e.g. those in solution as one gwBodyConstituent, those in suspension another, colloidal another and suspension another). For each mixture type GW_ConstituentRelation allows describing the relationships between the various constituents. Is this how we want it to work? Or should the gwMixture property be on the GW_Constituent Class so a GW_FluidBody/gwBodyConstituent can be made up of various mixtures?

-- BruceSimons - 20 Aug 2014

GW_BiologicalConstituent/gwState

GW_BiologicalConstituent/gwState is repeated in GW_BiologicalConstituent instead of being a constraint on the GW_Constiituent/gwState.

-- BruceSimons - 25 Aug 2014

Reference Elevation - resolved (I think - BS)

• BS: Are the cardinalities on GW_Well:gwWellReferenceElevation [1..*] correct? If so how to specify which gwWellReferenceElevation to use for the various depth properties? -- BruceSimons - 13 Aug 2014
  • Clause /req/gwml2-well/origin_elevation states that one of the Elevation must be flagged as the "reference elevation" -- EricBoisvert - 10 Dec 2014
• BS: Are the cardinalities on BoreCollar:collarElevation [1..*] correct? If so which does ConstructionComponent:from and to refer to? -- BruceSimons - 13 Aug 2014
• BS: Federation University collect Well condition data at various times over the life of the well - well depth from surface, well-depth from collar, casing height. It looks like GW_Well only allows a single value for well depth (gwWellConstructedDepth) and casing height (bholeHeadworks). -- BruceSimons - 18 Aug 2014
  • Wow. this means the reference points actually moves over time. If we open this pandora box, this mean we must consider all properties that can change over time

1. Inconsistency between Specification Section 9.5.1 and UML elevationType documentation

Section 9.5.1 of the specifications (http://external.opengis.org/twiki_public/pub/HydrologyDWG/GroundwaterInteroperabilityExperiment2/GroundWaterML2_v0.3.1_DRAFT.pdf) states:

The UML has for Well:Elevation/elevationType:

"Type of reference elevation, defined as the element of the well that considered the reference elevation (eg. Top of Casing, Ground, etc.)"

The two need to be aligned so that both the type of elevation (Top of Casing, Ground, etc) and whether it is the reference elevation for downhole measurements are recorded.

2. Inconsistency between Well and Borehole reference elevations

The Well reference elevation is specified in 9.5.1 by reference to a property in the DataType class that contains the elevation value (Elevation/elevationType):

The Borehole reference elevation is specified in 9.6.2 by reference to the SF_SamplingCurve/shape:

As both Well and Borehole are types of SF_SamplingCurve they should use the same pattern for specifying the reference elevation. This could be readily achieved by adding a BoreCollar /elevationType property as per Well:Elevation/elevationType (subject to resolution of 1. Inconsistency between Specification Section 9.5.1 and UML elevationType documentation).

-- BruceSimons - 27 Nov 2014

OK.. this is the bit that disapeared (don't remember why) from the spec.

/req/gwml2-construction/construction_geometry_origin

The origin of the relative position shall be the first vertex of the Borehole shape

If the borehole is associated with a well, they should share the same shape

It says that the Borehole's shape property shall be a xlink:href to the Well's shape (semantically sharing the same geometry). By way of consequence, the collar of reference will be located at the same place as the well reference elevation (because they follow the same rules). We need this to insure package dependency, so a Construction package cannot import Well (we might want to use construction in Oil industry for instance). The rule when you need to link construction to another Linear feature is the share this feature. Element are alway linearly located from the first vertext of the shape, and the reference elevation is also the first vertex, so is the 2D location of the well. It's all about synchronising multiple geometried all derived from the first vertex of the shape. If this is ok with you, I'll bring it back in the spec - or I'll get my asbestos suit..

-- EricBoisvert - 10 Dec 2014

Well Test

Needs:

Here is what is modelled in the French Water Information System

Attribute Name French	English translation	Mapping to O&M
Date de l'essai	Well test date	phenomenonTime
Heure de l'essai	Well test time
Coefficient d'emmagasinement (s) du pompage d'essai	Well test storage capacity measured	observedProperty
Débit critique	critical yield	observedProperty
Débit maximum exploitable	maximum yield	observedProperty
Débit spécifique	specific yield	observedProperty
Durée de l'essai	well test duration	resultTime (or deducted from)
Méthode d'interprétation du pompage d'essai [1]	welltest interpretation method	Procedure
Rabattement	Drawdown	observedProperty
Rapport d'essai sur le pompage d'essai	well test report	URL to the report in KVP via parameter ?
Transmissivité (T) du pompage d'essai	well test measured transmivity	observedProperty

All : please add your domain need.

---

[1] http://www.sandre.eaufrance.fr/?urn=urn:sandre:donnees:186::::::referentiel:3.1:html

Well test proposal

First version for discussion available here : GWML2_WellTest_proposal_draft2.docx

Discussion on how to encode having a compound result without an OM_ComplexObservation

There is a bit more into this. The Pump Test fit quite nicely into the concept of Observation except that any observation is about gwFuildBodyUnit.. the association between GW_HydroUnit and GW_FluidBody. Observation are normally about a feature (through featureOfInterest or indirectly through the sampling feature sampledFeature property). GW_UnitFluidProperty is not a feature either (it has no identity). One pattern we have , proposed by Simon is to use the procedure to unambiguously refer to the pair of sampledFeature (GW_HydroUnit and GW_FluidBody) here: SamplingFeature , at the bottom of the page.

As for complex results, SWE can deal with this the same way we did for logs and coverages.

-- EricBoisvert - 10 Dec 2014

-- SylvainGrellet - 10 Dec 2014

bholeDrillingMethod cardinality

GWML2 only allows for a cardinality of [0..1]. Australian NGIS database has [0..*]. -- BruceSimons - 02 Feb 2015

Pattern required over properties of SamplingFeature /Observation

SamplingFeature has two generic properties that interferes with some of the properties we have with WaterWell

• sampledFeature links to the real world features sampled by the SamplingFeature, but we also have gwWellBody and gwWellUnit properties that overlaps this semantic (it just adds constrain - but does not prevent usage of sampledFeature)
• relatedObservation links to any observations, but we also have a series of properties that does the same thing (gwWellConstructedDepth, gWellStaticWaterDepth)

We should probably document why use custom properties over generic sampledFeature / relatedObservation (probably around more constrained semantic)

-- EricBoisvert - 05 Feb 2015

ManagementArea proposal

First version for discussion available here :

• GWML2_ManagmentArea_proposal_draft1.docx: Area Management discussion document

-- SylvainGrellet - 16 Mar 2015

*