Thursday Minutes Tucson

RESQML (Reservoir markup language from Energetics)

  • RESQML is XML and HDF5
  • F Robida want to move to 3D, look at other organisation doing standard in 3D/Geology
  • POSC might overlap , Tim and François Robida attended Energetics meeting in Paris and met. Jean-François Rainaud, Institut Français du Pétrole.
  • RESQML developed from ground up as XML
  • JF Rainaud one of the contributor to RESQML.
  • Sent a report to Tim who circulated to group earlier this week.
  • Michel Perrin (Ecole des Mines de Paris) performing a comparative study of GeoSciML / RESQML in collaboration with Abel/de Ros group (Brazil)
  • Apparently, no overlaps between both models. But after quick inspection, this group sees that there are several overlaps (GeologicUnit, Contact). They soft typed a lot because they are interested in a narrow set of rock types that are useful in oil and gas.
  • V2 document mention they used GML for geometries.
  • Suggest to use GSML as input to their Reservoir QML. Highly complementary. Using GSML to represent geology
  • ACTION: Eric will comment (to all cc'ed) on intent to convert XSD into java classes (not possible automatically because XSD is for document - serialization - and not programming). Also mention that some of their classes do overlap GeoSciML DONE
  • Potential ACTION Do a review of RESQML.
  • ACTION: Ollie - They need link to demo database
  • Potential overlap with WITDML for Borehole (but it's mostly for reporting)


  • We need to defined the best tools to address serving both GeoSciML and INSPIRE schemas
  • Meeting with R. Tomas , made clear 28 states should produce INSPIRE schemas
  • Discussion on Mineral Resource INSPIRE spec. whic provided "Recommended schemas" to use and additional "extended schemas" (the latter are not "law")
  • 9.3.2 The spec says that a unique (INSPIRE and ERML) solution still need to be tested
  • For Geology (GSML) same comment - unique solution still need to be tested. "It should be discussed that GeoSciML should replace INSPIRE".
  • INSPIRE has Transformation Network Service , Transformation language (Schema transformation tool). Based on Humboltd.
  • Every member state must provide a transformation service. There are discussion about its usefulness.
  • Is INSPIRE -> GeoSciML possible (missing data) ?, the reverse IS possible.
  • Discussion of creating a tool to turn a geosciml 3.2 configuration into a inspire configuration so there is no need to maintain two configurations (in the simpler case, just a XSLT that turn one into the other in the case of GeoServer, ArcGIS and Deegree)
  • Need to clarify the use case (two services ?) There are pressure to produce INSPIRE in priority
  • There are DB content issues (vocabularies) - so maybe need duplicated vocabularies in database.
  • Brokered transformation service is not a panacea. BEST solution is to push providers to implement the standard properly, it's the most efficient. IF all else fails, the brokered solution might be considered, but there are caveats (performance, not all use cases can be met because of WFS/FES limitations, incomplete mappings, etc..) - from Canadian GIN experience.
  • Long shot is the "federated" approach, where the data in harvested/transformed from states and stored in a centralised system that deals with compliant WFS service. It obviously has its own set of issues.
  • ACTION: need to look into this tool. Eric will check with GSC if they can contribute in time. Carlo will also check. BGS, ISPRA and GSC will talk with JRC about potential solutions.
  • Technically, there are no legal requirements to follow the implementation - it's the data content that is regulated. But there are ramification into conformance tests.
  • ACTION: Ollie Suggested that CGI council write to INSPIRE to askthat no decision are made to only provided in INSPIRE because global interoperability is also important. see p. 103 for argument : (GeoSciML 3.2 will be tested ...)


(checking if all issues are covered in extended package)
  • Small minor technical fixes and tidying and got blessing from SolidGround
  • There is proposed that we should document an Abstract model, the UML and the XML implementation (so, 3 artefacts)
  • Plan is to do basic and extended in
    • 1 document for basic and extended + TimeScale + Lab Analysis
    • Borehole
    • Portrayal
    • Conceptual
  • WaterML seems to be the best reference to document to learn from.

Requirements and conformances

  • Steve created uml requirements .
  • Imported 3.2 to create abstract model. interesting problem on how to link requirement class to abstract model.
  • Considering what we saw in WaterML and SensorML, we should revise the current model and turn it into a conceptual model, and therefore remove implementations specific elements. Requirements documented in the scope notes of the relevant classes. Several changes done in the model, including (but not restricted to)
    • turn swe:Quantity into "Quantity". Requirement shoud state that they should be turned into swe:Quantity
    • Each properties that points to stereotype <<CodeList>> should be turned to generic term and specify in the requirement that implementation should implement with a term and a source. Renamed several vocabulary properties to end with "Term" for consistency.
    • Update conceptual model 4 to reflect what we did in implementation model (eg: MappedFeature should point to AnyFeature)
    • Take out GeologicRelation sub types from the conceptual model.
    • swe:Category implement ControlledConcept
    • change samplingFrame to mappingFrame and to points to a vocabulary term.
    • Should we have metadata in conceptual model ?
    • Remove Controlled Vocabulary package
    • Technically, "voidable" should be removed from conceptual model, but they don't hurt right now and would require a lot of work.
    • GeologicDateEstimate goes away
    • GeologyEvent 's named ages turned into terms
    • Should define a Recommendation about how GeoSciML should use Observation.
    • In LaboratoryAnalysis, remove explicit reference to 19115 and replace with requirements (shall provide name, etc..)
    • Should have a requirement that we should ignore Observation/resultQuality (because horrendous MD_) and use swe: constructs directly in result.
    • TimeOrdinalEraBoundary - remove reference to MD, change to Quantity
  • ACTION: Steve and Ollie to sit with EarthChem to figure a profile (see Simon and Bruce Water Quality profile for example) to constrain how rock chem is encoded in O&M (using Record)

-- EricBoisvert - 03 Jul 2014
Topic revision: r2 - 03 Jul 2014, EricBoisvert

This site is powered by FoswikiThe information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent.
If you enter content here you are agreeing to the OGC privacy policy.

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback