GeoSciML SWG Meeting - Minutes

Wednesday 28 October

Ollie will remain as acting Chair until GeoSciML v4 OGC spec is published. After that...

DECISION: “Purpose” scope notes need to include a short summary of the three codelist values

In the tags SVN vocabulary folder, the HTML version of the DescriptionPurpose vocabulary is not the right one. DECISION: Steve to email Mark to fix it up

From the Tucson minutes: Create a generic "ExtendedAbstractDescription" class - this was not done. Can’t remember why we thought it was a good idea

DECISION: Tim to provide scope note for GSML:CollectionType

DECISION: Mark to add the need for a vocabulary for SamplingFeature /parameter for use when locating the “start depth” and “end depth” of a borehole interval to locate a geologic specimen. (DONE ?, same as sub decision below?)

SUB-DECISION: Need to declare vocabulary in the OGC specification for use in a GeoSciML Boreholes (requirement and conformance class) (DONE - proposed text in spec, clause 9.10.1)

DECISION: Following copious email discussion, the link to LI_ProcessStep is now byReference only due to problems with ISO19115-3 and GML and OGC and ISO. Eric needs to update the UML to reflect this with a tag on the association. (DONE)

SCHEMAS

Eric reported on schema generation using ShapeChange. Need to investigate what we can make ShapeChange do via its configuration file rather than doing manual changes to schemas

Possible issues around conformance to ISO19118 encoding rules.

• INSPIRE requires ISO19118 conformance for schema encoding.
• classes on the end of composition associations cannot be root elements in an instance document. This is probably not a problem for !GeoSciML
• use of xlink:href for delivering vocabulary terms is possibly not conformant
• need to see what a ISO19118-conformant implementation looks like
  • DECISION #1:question for Clemens Portele and INSPIRE. Is the use of “gml:ReferenceType” valid for use in INSPIRE-compliant schemas? Is it a ISO19136 (GML encoding) problem? Eric needs to check for clarity on this.
  • DECISION #2: If the answer to #1 is that there is a problem with using “byReference” then Eric to provide an encoded example of a ISO19118-conformant schema and an example instance of how we would deliver vocabulary terms using the changed schema.
• STOP PRESS! Tim checked Clemens’ INSPIRE schema encoding document and it says that byReference types will be encoded using GML3.3 gml:ReferenceType encoding rules. Therefore GeoSciML is OK and is following INSPIRE rules.

DECISION: Need to make sure all associations have scope notes.

DECISION: GeoSciML-Portrayal can be made SF Level 0-compliant by incorporating requirement classes:

• one geometry type only
• any attributes added under “any” cannot be multiple cardinality, not repeating existing ones, and no geometries
• replace all “anyURI” types in the XSD with strings, but require that the string values are populated with URI’s (DONE)
• recommend that any mandatory URI attributes which have nil value should use OGC nil value URI’s, or alternatively another recognised controlled nil value URI.

DECISION: GeoSciML -Portrayal will be GML3.1 only

DECISION: use “number” (as opposed to “real”) in all portrayal classes. (Both are encoded as “double” in the xsd, but consistency needed in UML). (DONE)

DECISION: genericSymboliser in GeologicalSpecimen should be optional (DONE)

DECISION: check sequence numbers of numericAge attributes in GeologicUnitView (DONE)

DECISION: make specification_uri and metadata_uri in all classes optional (DONE)

Association classes - ShapeChange at GML3.2 rules cannot handle them. DECISION: If we use the INSPIRE encoding rules (that uses GML3.3 encoding rules) ShapeChange should theoretically be able handle association classes. Eric to investigate GML3.3 INSPIRE encoding rules to handle association classes.

Nil & nilReason.* - ShapeChange processes the “voidable” stereotype. Our working theory is that ShapeChange appears to insert nillable=”True” only for properties that require content, not for “byReference” attributes, and does not process the “nillable” tagged value in the UML. DECISION: Eric to check this. DECISION: Eric to remove all nillable tagged values from the UML, and we will rely on the voidable stereotype. (DONE)

DECISION: Need to insert description of pattern into OGC spec document:

Two mutually exclusive options:

• where we have content, use href + title only
• where we want to deliver a nil, then use only nilReason only (no href and title)

DECISION: Deadline Friday afternoon for UML and XSD changes to Eric.

SCHEMATRONS

Marcus demonstrated the use of schematrons for checking structure and content of GeoSciML instances.

DECISION: “mandatory nillable” schematrons not to be provided as part of the final v4 release.

OGC SPECIFICATION

DECISION: (This supersedes Tucson descisions) OGC Spec Document will describe logical model (ie, the current v4 UML), and XSD encoding, including schematron rules for constraints not explicit in the UML. Reference will be made to the GeoSciML v3.2 UML model as the reference conceptual model, but it will not be explicitly described in the OGC documentation. (DONE, small blurb in spec)

DECISION: Ollie to ask Scott Simmons about OGC membership and submitting organisations (AzGS, GA, BRGM, BGS (associate), etc…)

DECISION: Ask Francois about BRGM OGC membership status

BoreholeInterval - DECISION: need to update very old scope note,

DECISION: and once and for all remove link to MappedFeature that seems to be still hanging around in the UML ( DONE, DONE again)

Minutes continued - Thursday 29 October

DECISION: The element type of extension association classes (ie, GeologicRelation extensions) probably needs to change to "Type" to match the element type of its parent. (Check this in GSML3.2 and in Simon's association class documentation)

DECISION: Eric to add a requirement that a contact has relations to a maximum of two geological units

DECISION: Portrayal schema - Remove "specification_uri" on all the point feature View classes - boreholeView, geologicSpecimenView, siteObservationView (DONE)

DECISION: Need to put plenary presentations on the CGI websites

DECISION: Publish v4.0 schemas and html doco by end of November. DONE!!! Cut off date Friday 11:59pm for any uml or schema changes to Eric.

Instance docs
Ollie needs to make an instance doc to demonstrate borehole with a related GeologicSpecimen (using parameter topDepth and bottomDepth) and an instance with geochem data like done by GWML (see Eric's presentation)

Presentations

Tim Duffy

• OneGeology and INSPIRE updates
• Inspire to be using GeoSciML and Portrayal v4
• Cookbooks being written for use of GeoSciML v4 in INSPIRE and OneGeology. Links to these docs to be added to GeoScML website when published.

Ollie Raymond

• AuScope Portal demonstration using GeoSciML and EarthResourceML to deliver boreholes and mineral occurrence data
• Also using MinOccML (Australian-published ERML-Portrayal schema for mineral occurrences) and MineralTenementML (http://schemas.geoscience.gov.au)

Eric Boisvert

• GWML update - Eric's presentation is here
• interesting use of swe to deliver results of downhole geochem - investigate this for use in GeoSciML
• GWML use O&M model as property types for many properties. In practice, to implement as a service, a community profile of O&M will be required to use it

Carlo Cippoloni

• Carlo's powerpoint is here:
• Using GeoSciML v3.2 for geohazards information transfer
• showing annoying differences between INSPIRE and CGI vocabularies in the way that uri's are constructed. Also some CGI vocabs do not have INSPIRE equivalents.
• Wants to demonstrate these services in GeoSciML v4

Philippe Calcagno

• Phillipe's presentation is here:
• A BRGM methodology for constructing 3D using geological architecture
• investigating using GeoSciML to share geological architecture
• a couple of use cases that Phillipe wasn't sure how to do: relative age ordering of units and some contact types. Discussion suggests that shouldn't be a problem, but might need to be some additions to vocabularies, and some profiling of how the GeologicRelation part of GeoSciML should be used to relate units and contacts.

Tim Duffy

• OneGeology is proposing researching moving into 3D data (including surfaces) - steering group want to move in this direction
• GeoSciML provides a mechanism for delivering geological properties along with the quite extensive geometry varieties available to be delivered with GML.
• The Physical Properties part of GeoSciML is softtyped, and relies on vocabularies, so it is very extensible for geophysical properties
• The question of the best way to deliver 3D geometries (vectors, coverages, etc) can probably be dealt with outside of the current GeoSciML 4 SWG which will close once the OGC candidate standard has been accepted. CGI could consider promoting/joining a new OGC SWG on this topic if it wanted or perhaps initially do such research internally first.
• Can use OGC coverages associated with GeoSciML to distribute attributes that vary across a surface or volume
• for example the EarthServer project use of GSML as part of an OGC WCS coverage response as demonstrated by BGS.
• Francois Robida's request to investigate GeoSciML is for transfer of completed models, not necessarily for use during building of models

GeoSciML website

• Potential for GA to take on hosting of GeoSciML website from CSIRO for long term permanent hosting. Ollie is investigating this and will report back at a later date.

Future of the SWG post-GSML4

Potentially there is ongoing work regarding:

• 3D use of GeoSciML
• profiling of SWE for use in delivering geochemical data (see GWML use of SWE)
• if another particular need is identified by provision of use cases, then suggest setting up a new CGI working group initially. Can move it into OGC-land at a later date if a data spec or other OGC documentation (eg; best practice) is required
• suggest the existing GeoSciML SWG is converted into a Revision Working Group after the publication of the GeoSciML v4 spec.