"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Quebec 2009 - Design Task Group agenda and meeting notes


Agenda and Meeting Notes

Meeting notes and action items are inline with the agenda items.

"More info" numbers refer to issues at: https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/GeoSciMLv3DesignProposals

Items may be added following discussions of Use Cases, Service Architecture and Concept Definitions.

1.      Model admin and issues arising from Service Architecture TG - Version 3.0

1.1    Package organisation and namespaces for GeoSciML v3.0          (more info #13)
    • Refactor the schema into multiple separately governed packages, with separate XML namespaces

Proposal to refactor based on:

  • Action 1. Establish GeoSciML Version RC 2.1 based on GeoSciML Version 2.0 to capture required bug fixes and minor enhancements - SteveRichard Done, 23 Sept 09.
BE CAREFUL if you're working with this version in EA, make sure your version control configuration has %GeoSciML% pointed at %subversionRoot%\GeoSciML\branches\2.x\model. There doesn't seem to be any problem using Simon's new refactoring of the ISO schemas and HollowWorld.

  • Action 2. Establish GeoSciML Version RC3.0 to capture major proposed changes to GeoSciML version 2.0 - Main.Steve.Richard - Done

  • Action 3. Refactor GeoSciML Version RC3.0 to better reflect the maturity and potential governance of the individual packages - SteveRichard - Done

  • Action 12. Check all associations in GeoSciML RCv3.0 for appropriate sequenceNumber and inlineOrByReference tags - OliverRaymond

  • Action 24 Create proxy classes gsml:identifier and gsml:MD_RepresentationFraction - SteveRichard This will be done in the v3 trunk, not in v2.1.

1.2    Implications to the model of upgrade to GML 3.2 and WFS 2          (more info #7) - Version 3.0

1.3    What is the correct codespace for URNs for unique feature IDs?          (more info #22) - Version 3.0

Discussion on whether the CodeSpace should include the dictionary, thesaurus etc or just that it will be a URN (urn:ietf:rfc:2141). DECISION: Take this off-line and resolve through the Service Architect Task Group.

1.4    estimatedProperty stereotype          (more info #5)

  • Action 7. Create a specialisation of gml:AssociationAttributeGroup that provide attributes to link back to Observation collections - EricBoisvert DONE
Answer: This should be pushed to GML (3.3 ?) , it is not a GeoSciML specific requirement.

Also see GML Change Request 08-133 http://portal.opengeospatial.org/files/?artifact_id=29332&version=1 'Use xlinks for property metadata'. But this has been labelled 'Strategic' and will not be considered in GML 3.3. -- SimonCox - 2009-11-12

What does "Strategic" mean ? -- EricBoisvert - 2009-11-13

1.5    Gsml:Map          (more info #16) - Version 3.0

Proposal to use gml:Bag instead of GSML to capture all features in a BBOX along with hrefs within a single stand alone XML document (Can't as gml:bag is deprecated). DECISION: Separate working group to look at how to use gml patterns to meet requirements. - Action 16.

A specific class should be created in GeoSciML to do this. Action back to Ollie / Steve to add this to GeoSciML UML. See GML 3.2 Clause 9.9

1.6    Rationalisation of properties on some feature types - dealing with non-mandatory, nillable attributes          (more info #11) - Version 3.0

1.7    Any changes to which elements should be InLine or ByReference          (more info #15) - Version 3.0

DECISION: MappedFeature:occurrence should be inlineOrByReference - Done

1.8    How are different resolutions of data identified, e.g. 1:20000, 1:100000, 1:1000000 scale data in the same bounding box.

Much discussion on use of capture scale vs portrayal scale. Attempted to use O&M:ObservationProcess:Method bit this has a resultQuality element which duplicated MappedFeature:positionalAccuracy. resultQuality used the abstract DQ_Element which generated polymorphism problems. For MappedFeature:positionalAccuracy a Data type of gml:Measure::Distance was considered but this was the same as CGI_Numeric which we have retained elsewhere in the model. DECISION retain current GeoSciML properties and add a scale property.

DECISION: MappedFeature:observationMethod with data type CGI_Term -- Done

DECISION: MappedFeature:positionalAccuracy with data type CGI_Measure -- Done

DECISION: Add new property MappedFeature:resolutionScale with data type MD_RepresentationFraction to represent the 'capture' scale or intended resolution of the MappedFeature. -- Done

2.      CGI value and data types - Version 3.0

2.1    CGI_Value          (more info #9) - Version 3
    • replace by O&M, SWE Common, ISO data types?
    • statistical values (eg, for PhysicalProperty - more info #2 )
    • error/accuracy/precision
    • ranges

  • Proposal to replace all ControlledConcept with ScopedName.
  • Replace all CGI_Value with one of:
    • ScopedName (or replace with swe:DataRecord or swe:category)
    • Measure
    • Range (new type, but with minimum use)

Replace all with numeric ranges instead?

Debate about the intention of GeoSciML. The participants identified that the prime aim is to achieve interoperability. This will result in loss of information and require improving definitions of vocabularies. Still would like to have the flexibility to deliver the information 'as is' with the option of tightening it up at a later date.

Two use cases:
  1. Content and structure is fully interoperable - data from database into a common standard
  2. Data exchange - take data from database into GeoSciML and back into database without loss

A possible way of reconciling interoperable vs data delivery use cases is to allow two schema with GeoSciML v2.x providing a 'flexible' method for delivering information while use GeoSciML v3.0 as an 'interoperable' schema. Allow the user community to determine which schema the choose to use.

Maintain separate schema or separate profiles?

What will happen to ControlledConcept if we move to swe:Category? Deprecate ControlledConcept?

Wherever in the model we use ControlledConcept or CGI_Term or ScopedName replace with swe:Category. This will need to be tested, both that it works to deliver the data we require and that it can be queried. All the changes will need to have scope notes added specifying how swe:Category is to be used, ie what CodeList specification is required, what the swe:Value should be etc.

CGI_NumericRange should be an upper and lower swe:Quantity rather than upper and lower CGI_Numeric. Attempting to do this identified inconsistencies between swe:Quantity and gml:Measure. For consistency, revised decision to use gml:ScopedName and gml:Measure in order to keep it all within gml rather than mixing gml and swe. In order to improve interoperability, created gsml:CGI_Term as subtype of gml:ScopedName with a qualifier property.

All properties in GeoSciML will be given either ScopedName, CGI_Term, single CGI_Measure or CGI_MeasureRange. CGI_Range, CGI_Term and CGI_Numeric unions will be deprecated.

DECISION: Replace all ControlledConcept Data types with ScopedName and ensure cardinality is 1..*. Use CGI_Numeric or CGI_NumericRange for the numbers. CGI_Term is a qualified ScopedName to be used where the property is optional.

  • Action 5. Why is the "Measure" class in the ISO19103 UML package different to the gml:measure in the GML 3.2.1 schema? SimonCox EricBoisvert DONE (Already answered by SimonCox
    • How is it different?
      1. There is only one Measure class in HollowWorld
      2. ISO 19136 Table D.2 and clause D.2.2 makes it quite clear that gml:MeasureType is the implementation of the ISO 19103 class Measure

  • Action 18. Determine a list of all elements in the model that potentially should be 1..? rather than 0..? - OliverRaymond

2.2    Replacing TermValues, Scoped Names with ControlledConcepts      (more info #28) - Version 3

DECISION - See 2.1

2.3    Need a more consistent/uniform approach to encoding nulls          (more info #10) - Version 3

DECISION: Determine from SimonCox how to do this.

  • Action 19. Determine from SimonCox solution for a uniform (third) approach to implementing nulls - EricBoisvert

This one is a bit tricky, There is at least two kind of nulls. a) null pointer, that appears in xlink:href and tells that the properties does not contain any complex content and b) a null key that tell that a litteral (a string) represents a null value. Both are required and have different semantic.

2.4    Geologic Age model          (more info #6) - Version 3
    • possible use of gml:timePosition data type
    • interoperability (or not) of CGI_value for age
    • use of PreferredAge

Proposal is to use TimeOrdinalEra from GeologicTime.

DECISION: Have a numericAgeDate property with TM_Period data type to capture the numeric age ranges. Have an olderNamedAge and youngerNamedAge using GeochronologicalEra data type.

See NumericAgeDate representation discussion (-- SteveRichard - 2009-10-03)

DECISION: to deprecate preferredAge and replace with queries which look at eventProcess property and numericAgeDate. Will require Geoscience Concepts Task Group to ensure appropriate vocabularies on eventProcess are available.

  • Action 15. Geoscience Concept Task Group to look at eventProcess vocabulary to ensure a query on eventProcess and numericAgeDate will return appropriate values (ie capture both deposition and intrusion events) - SteveRichard

3.      SKOS and vocabularies - Version 3.0

3.1    Encoding of ControlledConcept vocabularies in SKOS          (more info #14)
    • may be dealt with by SA and/or CDTG discussions?

4.      Boreholes and other sampling features (eg: specimens) - Version 2

4.1    Verbosity/repetition of information          (more info #24) - Version 2.1 or Best Practise
    • in the MappedInterval model for boreholes
    • appropriate use of byReference in drill logs          (see also (more info #15))

4.2    Other Borehole isues          - Version 2 to see if list needs additional. Move to Vocabulary in Version 3.0 (more info #27)
    • drilling methods - cardinality, new values for enumeration
    • other issues arising from use cases.....

DalePercival to circulate proposed additions to DrillingMethod CodeList and add to model after general acceptance

GuillaumeDuclaux is mapping Australian AuScope boreholes to GeoSciML and DalePercival to check this.

Association between Borehole and MappedInterval is unidirectional. Does this need to be bidirectional? Dale & Eric to look at this relationship and determine whether the association is bidirectional or unidirectional.

  • Action 10. Association between Borehole and MappedInterval is currently unidirectional. DalePercival & EricBoisvert to check this relationship and determine whether the association is bidirectional or unidirectional. DONE

From an email exchange with SimonCox:

Having a bidirectional link between Borehole and MappedInterval essentially means that we'll have a link from a feature to a SamplingFeature (Borehole). In general, it's not a good idea because we don't expect features to 'know' of all those that samples it. Specially since SampleFeature can sample things that are in a different schema/governance. "Bidirectional link is the ennemy of modularity" because it impose dependencies to the domain specific schema. All (WFS) queries that involves SampleFeatures should be written from the SamplingFeature end. So, unless we have a very compelling reason to have this birectional link, we should refrain doing so to preserve modularity). I therefore propose that we keep the logElement as is.

-- EricBoisvert - 2009-12-10

4.3    Geologic Specimens          - Version 3.0 (more info #32)

DECISION: There does not appear to be any reason to add special Geologic Specimen classes to the O&M model apart from a vocabulary for Material class.

  • Action 22 Attempt to rework the Geologic Specimen workflow application of the Geologic Specimen classes and its dependencies in the standard O&M - OliverRaymond, GuillaumeDuclaux

5.      Earth Material - Version 3.0

5.1    Rock vs UnconsolidatedMaterial          (more info #1) - Version 3.0

DECISION: Leave CompoundMaterial:RockMaterial as is.

5.2    ConstituentPart, MaterialRelation, CompoundMaterial and ParticleGeometry          (more info #20) - Version 3.0

DECISION: Created an association between ConstituentPart and ParticleGeometryDescription in order to describe the particle geometry of the ConstituentPart

Also See 5.4

5.3    Specifying Proportions in Component Relationships          (more info #3) - Version 3.0

DECISION: This is seen as a very low priority that is deferred until someone has a burning desire to implement it.

5.4    Material Relation and Earth Material vocabularies          (more info #4) - Version 3.0

DECISION: Reworked draft MaterialRelation to allow referring to ConstituentPart (change ConstituentPart from DataType to Type), changed MaterialRelation from Feature (removed subtype from GeologicRelation) to DataType and simplified specifying the roles.

5.5    CompositionPart/lithology and RockMaterial/lithology?          (more info #26) - Version 3.0

DECISION: Remove composition:CompositionPart:lithology

5.6    PhysicalProperty          (more info #2) - Version 3.0

NOTE: Pattern used here was found useful during the GroundWaterML design as it could be subtyped readily to cover additional related properties.

DECISION: Hard typing found to be useful. Individual communities should extend this class as required.

DECISION: Modified CGI_NumericRange to handle upper, lower and a 'middle' (mean, median, average, common) to deal with delivering ranges and for example the mean.

6.      Geologic Unit - Version 3.0

6.1    CompositionCategory          (more info #17) - Version 3.0

DECISION: Change cardinality of compositionCategory on GeologicUnit to 0..*.

DECISION: Rename GeologicUnit:compositionCategory to GeologicUnit:unitComposition

6.2    DeformationUnit definingStructure cardinality          (more info #8) - Version 3.0

DECISION: change cardinality to 0..*

6.3    Boulder frequency          (more info #30) - Version 3.0

DECISION: Vocabulary issue - going to use outcropCharacter

6.4    Geochemical analyses          (more info #32) - Version 3.0

DISCUSSION: How do we deliver geochemical data? The requirement is to be able to deliver spreadsheets of geochemistry data. The NSF geochemistry requirements is based on a list of items with attributes in the elements. We require an O&M/GeoSciML format that can be converted to the NSF format.

University of Kansas have an EarthTime (geochronology) model which is similar to the O&M model.

GeochronML (RagingSpot) also has a draft model. None of the models have dealt with the Result = any specification.

6.5    Alteration properties          (more info #18) - Version 3.0

Modified WeatheringDescription class and renamed to AlterationDescription to capture all non-metamorphic alteration.

Added associations between AlterationDescription and MetamorphicDescription and GeologicEvent. (Note: see AlterationDescriptionDiscussion for post-Quebec discussion re addign AlterationDescription to EarthMaterial)

Removed DisplacementEvent and associated DisplacementValue with GeologicEvent. DisplacementEvent is required to capture the incrementalMovementSense.

7.      Geologic Structure - Version 2

7.1    Fault Type          (more info #29) - Version 2

Modify movementSense and movementType vocabularies to allow single list of Fault Types covering all acceptable combinations of dip, movement sense and fault type. Combine movementSense and movementType into faultType property.

DECISION is to have a FaultType property on the DisplacementStructure, movementSense and movementType on the DisplacementValue

7.2    PlanarOrientation, LinearOrientation          (more info #21) - Version 3

DECISION - Make cardinalities for azimuth and dip to cardinality of 1..1. Change CGI_Value to CGI_NumericRange.

Discussion on problem with ConventionCode variation reducing interoperability. DECISION to leave it as is and try to promote the use of one or the other to encourage interoperability.

8.      Metadata - Version 3.0

8.1    Making better use of MD_Metadata in GeoSciML v3          (more info #23) - Version 3
    • observationMethod
    • DQ data quality, accuracy etc (see related CGI_Value issue)
    • CI_Citation, ResponsibleParty (eg, Boreholes?)

9.      GeologicFeature, MappedFeature - Version 2.1

9.1    Update scope notes for ObservationMethod          (more info #25) - Version 2

  • Action 23 Reword the Scope Notes on MappedFeature and GeologicFeature to distinguish between the various observationMethods - SteveRichard Done. Scope notes updated in v2.1 and v3 -- OliverRaymond - 2009-11-05

10.      GeologicFeature byReference or inLineOrByReference

GeologicFeature byReference or inLineOrByReference when referred to from within other Features (MappedFeature, GeologicFeature) when referred to from within other Features (MappedFeature, GeologicFeature)

DISCUSSION: Needs an automatic URN resolver otherwise leave all as inlineOrByReference. GeologicRelationships always byReference.

11.      Data value specification

11.1 Should data value specification schemes be specified by service architecture or by xml schema. this bears directly on discussion of CGI_Value in the data model. DECISION - Agreed is a data model issue.

-- OliverRaymond - 15 Sep 2009

     Timelines

  • October 30 Version 2.1 schema ready for testing

  • November 30 Version 3.0 schema ready for testing

-- BruceSimons - 2009-09-24
Topic revision: r30 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).