Minutes of GeoSciML SWG meeting, Tucson - Day 2 (Monday)

GeoSciML -Basic continued

  • Steve discovered a circular dependency between Basic and Extension, involving ParticleGeometry
  • More discussion about material (lithology) terms in 2 places
    • recognised as a problem having one lithology (material) property in Basic and one lithology in Extension
    • prefer to have only lithology in one place (ie, in Basic). Then lithology is only in one place and it is available to users of both the Basic and Extension app schemas
    • Decision : 1. - Move lithology out of CompositionPart . 2. - Move RockMaterial (with lithology property) into Basic.
  • Much discussion about how to handle extended descriptions of Units and EarthMaterials via the abstract description classes.
    • Decision: Create a generic "ExtendedAbstractDescription" class in the GeoSciML -Basic package which is the parent class for all extended description classes for both GeologicUnits and EarthMaterials in the GeoSciML -Extension package
    • Decision: The associations from GU and EM to the "ExtendedAbstractDescription" abstract class will be 0..*, not 1..* (voidable) because a user of only GeoSciML -Basic (ie, without GeoSciML -Extended) will never be able to encode the abstract description class, so having a mandatory association to it would be silly.
  • Discussion about use of representativeAge (ie, from Portrayal) in GeoSciML -Basic.
    • Decision: leave representativeAge out of Basic. It is only useful for colouring portrayal services.
  • Modelling of numeric ages - what goes in Basic vs Extension?
    • Decision: add numeric age properties into Basic. Needed as a basic functionality by data providers with lots of Precambrian rocks.
    • Decision : simplify all the NumericAgeRange properties (reporting, older, younger ages) to be swe:Quantity. Eliminates the need for the GeologicalDateEstimate and unwieldy DQ_QuantitativeAccuracy that was used in v3.2. This means that all GeologicAge properties now go back into GeoSciML -Basic. Remove GeologicAge from GeoSciML -Extension. Leave the GeologicEvent abstract description in Basic (0..*) as a hook for potential further extension at a later date.
  • GeologicRelation
  • Metadata
    • Why do we need GeoSciML /GeologicFeature/metadata? Does GM_Object/gml:metaDataProperty do exactly the same thing?
    • The reason that GeoSciML v2 had a specific "byReference" only association to MD_Metadata was that, at the time, there was no MD_Metadata published schema. The GeologicFeature /metadata link was probably uneccessarily continued into GeoSciML v3.
    • Now that we want to use "Any" for delivering metadata, and that there is a published schema for MD_Metadata, there is no need for a specific GeoSciML link to "metadata".
    • Decision: Drop the GeoSciML "metadata" link and use the gml:metaDataProperty link (0..*, inlineOrByReference)
  • Collection
    • Decision : add "collection type" attribute to GSML.


GeoSciML -Extension

  • Don't need metadata link from EarthMaterial, as it inherits metaDataProperty from GM_Object.
    • Decision: delete metadata association


  • Located specimens related to boreholes.
    • Best practice to use "samplingFeature/parameter" to indicate "start depth" and "end depth" to locate specimens. This method is used by GWML too. Soil community is using "upperBoundary" and "lowerBoundary".
    • Need a vocabulary for this parameter so that values have a URI.
    • Decision: Need to define a requirement class to state that users must use values from a particular vocabulary
  • MappingFrame - not really applicable to a borehole like it is in a MappedFeature
    • Decision : For a borehole, the mapping frame should identify the borehole that contains the mapped interval. Points to an inline ScopedName that can identify the parent borehole. Use the IETF2616 codespace to indicate if the ScopedName is a URL. Otherwise indicate the location of a codespace for a term. If no codespace is available, use an OGC nil value URL.
    • New decision: Remove MappingFrame.
  • Metadata elements (eg, dataCustodian)
    • Decision: replace all ISO19115 properties with new equivalent (but draft) ISO19115-3 properties.

-- OllieRaymond - 30 Jun 2014
Topic revision: r2 - 01 Jul 2014, OllieRaymond
This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback