GeoSciML GWML join SWG meeting
- Potential change to GeoSciML 4.2 (AbstractDescription missing)
- MappingFrame for Borehole
- WFS 3.0 and encodings
- Progress report on Borehole IE and potential impact of GeoSciML (borehole package)
- Progress report on some ontology work done by GSC
Following the OGC GeoSciML
SWG -several discussion arose and we did not have time to address them in details. Very small session (45 minutes planned, went for an hour).
The first topic is missing AbstractDescription
for some classes in Extension package. The role of those AbstractDescription
classes is described in https://docs.opengeospatial.org/is/16-008/16-008.html#7
But when we created those AbstractDescription
, we did them by pulling properties from existing classes and push some other classes altogether in Extension. For those latter classes, we did not bother to create AbstractDescription
(because it was the mechanism to push their properties in Extension while remaining in Basic package). This is where we neglected the second role of AbstractDescription
: extension points to add more properties. GTK (Finland) spotted the problem when they wanted to create new properties for Fracture.
Check Fracture, Fold System, Lineation and Non-Directional Structure in https://docs.opengeospatial.org/is/16-008/16-008.html#186
There are a couple of solutions
Solution 2 was preferred from the people attending the meeting, but someone rose a need for #1 (more classes into Basic). But solution #1 is not backward compatible. Unless there is a strong use case for #1, the general preference is to go with #2.
Please comment on https://github.com/opengeospatial/GeoSciML/issues/22
- Move Fracture and Join to basic and add AbstractDescription (major, not bacward compatible for Extension pattern)
- Add AbstractDescription in Extension as point of extension (minor -if AbstractDescription is 0..n)
- Add a top level AbstractDescription to GeologicStructure (all class inherits it, minor but some classes get two AbstractDescription)
Topic 2 borehole mappingFrame
Question on INSPIRE forum about the use of mappingFrame.
The question is currently debated on GeoSciML
mailing list. As it was a very recent issue, was not discussed during the meeting.
Topic 3 New encoding and WFS 3.0
There is a growing interest in WFS 3.0 which raises the issue of GeoJson
encoding. Although GML XML is a valid format, most developers prefer JSON / GeoJSON
. The current model has "lite" encoding and has artefacts created to address FES and WFS limitation (the most proheminent is GSML_Quantity Range created to expose explicit values properties to FES that can't access array items)
- Do we keep those artefacts in a GeoJSON encoding
- What are we doing of "Lite" encoding versus "real" GeoSciML.
- Lite is a operational artefact created to allow quick win for people running simpler systems. It's a "flatten" version.
- With the growing interest of GeoJSON and RDF, don't such strict structure, JSON and RDF are confortable with using set of properties on the fly.
- Some member thinks it's still useful for simple WFS.
- The "lite" is more that just an arbitrary list of properties from the "real" model. There are additional convenience properties (symbol) and different types
- "lite" still has value for RDF ?
- There was a discussion (started in GWML) that underlined the importance of RDF/OWL and JSON-LD. We did not get that far in this discussion (was already started in GWML and in Vancouver).
- Since it's the same people in the room, and because of the dependency between GWML and GeoSciML, it's fair to conclude that we need to move into OWL/RDF
- It was concluded that we need to set a meeting to push new encoding work.
- 25 Jun 2019