Welcome to the GeoSciMLswg web

Minutes of the St Petersburg face-to-face meeting, 3-7 June 2013

Items for Discussion

• GeoSciML v3 documentation as the abstract specification for GeoSciML v4
  • identify requirements and conformance classes (see WaterML, O&M, CityGML specs)
  • schematron rules as conformance classes

• GeoSciML v4
  • the model pattern
    • core basic package with abstract extension classes providing links to extension packages
    • what is teh bast way to handle the abstract extension classes
  • requirements, use cases - what do we need in "GeoSciML Basic"
  • detailed model editing
    • fix problems identified in the UML
    • problem with ability to query swe:QuantityRange elements (eg, compositionPart proportion)

• Documentation of best practice encoding of swe:Category and swe:QuantityRange

• Borehole intervals and local srsNames
  • what the WFS spec says
  • Ben Caradoc-Davies' change request
  • limitations of Geoserver
  • do any other WFS apps have issues with generating GM_Objects from a non-spatial database?
  • the way forward
  • fix problems identified in the UML

• Update from Marcus Sen on applications of GeoSciML To coverages. Encoding coverages for model results? Use coverage for elevation model on geologic surface with GeoSciML description.
  • Note: we did not have time to cover this topic at the meeting

• Generalize mapped feature specification to point to gml:AbstractFeature

• Use of GeoSciML in Urban Geology
  • Note: we did not have time to cover this topic at the meeting

Minutes 2013-06-04

Tuesday June 3

Documentation

At OGC made commitment to draft documentation for GeoSciML V3, abstract specification. This will be abstract model for v4, which will be XML implementation of v3 model. Therefore transformation from v3 to v4 should be possible. Question as to relation of GeoscimL portrayal; this will have to be determined. Portrayal hopefully will be considered an implementation of the conceptual model, and the Level0-level1 etc will be more complete implementation of the conceptual model.

v3 UML has XML artifacts that we might remove

Bruce -- based on on experience with water quality model. Conformance class is defined by passing a schematron class.

WaterML-- has section on UML to XML; this is the abstract model (section 9), section on implementation of XML instance (section 10).

The GeoSciML 3 abstract model will follow pattern of WaterML section 9.

GeoSciML v4 implementation model will follow pattern of section 10

Long discussion trying to figure out relationship between OGC modular specification for abstract model and OGC modular specification for XML implementation of that model. Question is does the packaging in the implementation specification have to mimic the abstract spec packaging. We concluded that the XML implementation packaging can be different from the abstract specificaiton packaging.

Will write implementation spec for GeoSciML v4 against CGI GeoSciML v3 abstract model as an informal framework. But try to stay true to the v3 conceptual model wherever possible.

GeoSciML portrayal is a different Specification that GeoSciMLv4. There is no way to define a core conformance class that will unify the GSML4 classes with the portrayal classes. Keep GeoSciML-Portrayal separate from GeoSciML v4.

Start work on Core Requirements (see RequirementsDiscussion).

A requirement that Categories are populated by URI that can dereference to SKOS or HTML is probably not a testable, useful requirement. Probably better as a recommendation, or optional conformance class. (but conformance classes can't be optional.)

Tim suggested that there should be a requirement that v4 XML uses same class and attribute names as GeoSciML v3, wherever possible. Agreed.

Bruce suggested that some attributes names are not unique in GeoSciML v3 (eg, various "role" attributes) and that they should be unique to conform to OGC modelling rules. Agreed - need to identify all of these and change them where required.

GeoSciML-Portrayal

Portrayal Identifier is not considered a foreign key that should join a portrayal feature with a GeoSciMLv4 MappedFeature on a 1:1 basis.

ACTION: Decision to include site observation and specimen portrayal classes, after broader discussion about role of portrayal services in GeoSciML. This direction is suggesting a pattern in which each important feature type has a portrayal feature class.

June 6, 2013

INSPIRE conformance issues for 3.1. Request from INSPIRE/Robert Tomas -- we reviewed table of mapping of GeoSciML elements to Inspire requirements to check that INSPIRE elements are catered for where appropriate.

Issue-- CollectionType is a property required by Inspire, not present in GeoSciML. Agreed to add one attribute to the Collection package - collectionType - to satisfy INSPIRE needs.

In process of evaluating proposal, discovered that the 3.0 collection.xsd imports 3.0 schema, so can't actually implement a collection of v3.1 items. ACTION: fix imports in collection.xsd to import v.3.1 instead of v3.0; add collectionType property that is of type collectionTypeTerm. This will be schema version 3.1.0

ThemeClassificationValue-- for classifying maps... Is property on GeologicFeature. Maps clearly to classifier on GeologicFeature

for beginLifespan and endLifespan use MD_Metadata//citation//date//dataTypeCodes (use 19115-1 codelist and don't even have to add anything, see 19115-1 in drafts in HollowWorld/TC211/drafts package)

GeoSciML v4

Proposal to make specification association from MappedFeature point to gml:GF_Feature. This would allow use of mapped feature by other related models.

GFI_Feature from O&M or gml:AbstractFeature. GFI_Feature is apparently a sibling of AbstractFeature; observation doesn't derive from GFI_Feature, but it is stereotyped <<FeatureType>>, and GFI_Feature is as well, so AbstractFeature seems more general. Intention is that a mappedFeature is something that has an extent (it can be mapped). make MappedFeature specification an AbstractFeature.

OK, now to the actual model specificaiton for v4.

see the RequirementsDiscussion page, start at GeologicUnit description.

Long discussion about philosophy of v4 -- should it attempt to implement simpler conformance classes against some actual set of imagined user scenarios, or to meet INSPIRE requrements classes. Or should we take the quicker path to OGC spec and use the UML model packaging as the conformance classes for the modular specification and use v3.1 pretty much out of the box.

Review of v4 Level1 package

Need to add older and younger geochron age terms in geologic event

Move GeologicUnitDescription to geologicUnit extension package

swe:QuantityRange has value as a pair of values; this can not be queried using OGC Filter. Discuss how to solve; whether to try WFS SWG change request.

ACTION: Eric to email Alex Robin from the SWE working group to see if they have a plan for queryability of swe:QuantityRange. If not, then add upper value and lower value attributes to the model so that we can query proportion properties.

GeologicUnitPart is the same

CompositionPart gets lithology:LithologyTerm property; need condition that RockMaterial:lithology:LithologyTerm is only used if not in context of Geolgoic Unit.

ACTION: adopt NaturalGeomorphologicFeatureView ; allows for point, line or polygon feature. Carlo Cippoloni and Mike Craig to propose a class & attribute structure

Need a geologic unit extension package

Need a physical properties extension package

ACTION: Need to continue development work via future teleconferences. Ollie to co-ordinate.