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

GeoSciML -Basic continued

• Steve discovered a circular dependency between Basic and Extension, involving ParticleGeometry
  • Decision : moved Basic/CompoundMaterial --> ParticleGeometryDescription association to Extension/CompoundMaterialDescription --> ParticleGeometryDescription
• 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
  • Want to keep the generic GeologicRelation association class in GeoSciML -Extension but can't link from GeologicFeature in GeoSciML -Basic to GeologicRelation in GeoSciML -Extended
  • Decision: create abstractGeologicRelation association class in Basic to provide a hook from Extension/GeologicRelation to Basic/GeologicFeature/relatedFeature
• 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-Portrayal

• Decision: Add NumericYoungerAge and NumericOlderAge to GeologicUnitView and ShearDisplacementStructureView. (Particularly for web services delivering lots of Precambrian rocks.)
• Decision: Add GeomorphologicUnitView class to Portrayal. Carlo and Mark provided main input to list of attributes. Done.
  • Need vocabularies to be published for Landform Class (natural, anthropogenic), Landform Type, and Activity

GeoSciML -Extension

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

Borehole

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