Vancouver GeoSciML meeting

June 11th 2018

Geological Survey of Canada - Vancouver (British Columbia)

Agenda

PM AGENDA: 13:00* ‐ 16:00 (

Pacific Daylight Time):
  • 1.Introductions
  • 2.Review of agenda
  • 3.Review of minutes from last meeting
  • 4. RDF/OWL encoding progress. Demo from GSIP
  • 5.GeoJSON vs JSON-LD
  • 6.GeoSciML paper
  • 7.Next steps

Meeting report

Attendees

  • Zhang Minghua, Geological Survey of China
  • Wang Yongzhi, Jili University, China
  • Kombada Mhopjeni, Geological Survey of Namibia (GSN)
  • Boyan Brodaric, Geological Survey of Canada
  • Oliver Raymond , Geoscience Australia
  • Michael Sexton, GeoScience Australia
  • James Passmore, British Geological Survey
  • Stephen Richard US Geoscience Information Network
  • Patricia Duringer Jacques, Geoprocessing Division, CPRM , Brazil
  • Maria Glicia da Nobrega Coutinho Geoprocessing Division, CPRM , Brazil
  • Hiran Dias, Geoprocessing Division, CPRM , Brazil
  • Eric Boisvert, Geological Survey of Canada

Remote

  • Marcus Sen, British Geological Survey
  • Carlo Cipolloni, ISPRA/Geological Survey of Italy
  • Sylvain Grellet, Bureau de Recherches géologiques et minière, France

The whole meeting was dedicated to progress on RDF/OWL encoding. BRGM / Atos document their process to create a RDF/OWL encoding from the current GeoSciML UML model. The objectives of this short meeting is to discuss the the issues and recommendations presented in the report : Strategies for Publishing Domain Ontologies as Linked Data from OGC domain standards .

(available on Gihub :https://github.com/opengeospatial/GeoSciML/tree/master/documents)

S. Grellet presented the highlights of the documents (attached). The major points were then furthered discussed in the group.

The group discussed the rational of using the current UML model (version 4.1) to create the RDF encoding. The current UML model contains several XSD artefacts and the standard translation process used by ShapeChange (based on ISO-19150-2) will convert all those artefacts into OWL.

Boyan explained that we need to defined why we are creating this OWL encoding

  • Is it an ontology about the XSD

  • is it an ontology about geological conceptual model.

The group agreed that a ontology of the XSD was not useful and we should aim to ontology of the conceptual model. The group identified two use cases that motivate the creation of RDF/OWL encoding

  • Linked Open Data : OWL is used to classified real world things that is exposed to the web

  • Reasonning (Machine Learning, IA, etc.) to enhance processing of geological data by algorithms.

The latter use case is seing of lot of activities from academia and industries to support mineral exploration. It was agreed there is a role for CGI to play.

It was also discussed of the need to create a new UML model that did not have those XSD artifacts. It was concluded that

  • It is unlikely that a UML model is expressive enough

  • OWL is the best encoding for conceptual model, therefore the canonical model for the conceptual model will be OWL model instead of UML. Might not worth it investing into a UML encoding.

  • Process proposed in the document (Initial translation with ShapeChange and then manual edits) is the best one.

  • Human goes through encoding and fix issues and add things that were not explicit in UML and documents decisions

Ollie suggested that we use GeoSciML 3 instead of 4 as a starting point for the ontology. V 3 does not have AbstractDescriptions classes that is the major break in the conceptual model. It's is mostly the same model packaged differently. V 4 added a few more portrayal (lite) classes but they can easily be retrofitted in V3. Group agreed:

Action : Eric to reconfigure ShapeChange to read from v3

The group reviews a subset of issues identified by BRGM and Atos

Issues:

  • Things added to the model to address XSD (exemple, AbstractDescription classes)

    • should not be encoded as is, but encoded as expected from the conceptual model

  • Things that can be encoded in OWL, but is not expressed in the UML (often spelled out in documentation).

    • Already agreed that human interpretation will be required and OWL is now the canonical representation of the conceptual model.

  • Property name not unique

    • keep pattern provided by ISO-19150-2 (prefix with class name : MappedFeature.observationMethod)

    • Might have same name, but are different property because different Range

  • Strategy document proposed to set constraints at the application level and leave the reference level with open properties

    • Domains and ranges properties should not be defined in the reference ontology to favour reuse. They could be specified it in application ontologies that reuse the properties (if needed). Instead, restriction on the values of the properties should be defined for every class.

    • Group concluded that it should not be applied across the board, but only for certain cases. It would be preferable that properties have explicit domain and range at the reference level

      • This was done to handle “lite” versus “basic”. But those are considered as different logical model (don't think we came to a conclusion)

  • Vocabulary

    • two patterns exists: encode Range of vocabularies as skos:Concept or as a new class bearing the name of the vocabulary (and eventually model the whole vocabulary as subclasses)

    • Because lots of academic work leans on the latter (new classes) it was felt it was the way to go. Except we have all our vocabularies in skos right now, we need a way to address both

    • A pattern has been proposed (below)

    • This means a single “top” classe might also need to be added to current vocabularies

  • Turn swe:Category to skos:Concept

    • Strategies recommends to Rename swe:Category to skos:Concept

    • Category have qualifier (“sometimes”,”always”,etc..), so it is needed

    • Maybe turn the property to association class (to keep the qualifer) and then skos:Concept would work

+-----------------------+
|                       |
| Earth Material        |
|                       |
|                       |
|                       |
+-----------^-----------+
            |  is-a
            |
            |
+-----------+-----------+             +----------------------+
|                       |   lithologyTerm                    |
| RockType              |             |  Skos:Concept        |
|                       +------------->                      |
|                       |             |                      |
+----------^------------+             +-----------^----------+
           |  is-a                                | skos relations (broader ?)
           |                                      |
+----------+-----------+              +-----------+----------+
|                      |              |                      |
| (vocabulary as       |              | existing vocabulary  |
| OWL classes to be    |              | in skos              |
| eVentually encoded)  |              |                      |
+----------------------+              +----------------------+

 

Some of the issues are related to ShapeChange, not the UML model. So we have nothing to do (except fixing encoding or reporting the problem to ShapeChange) : eg Association classes not completely encoded, Union are not encoded the expected way, etc.

There was a general discussion on role of CGI / IUGS in the current stream of activities over OWL encoding of GeoSciML vocabulary. Should GeoSciML SWG propose a standard vocabulary (in the form of an Ontology) ?.

GeoSciML is delegating the vocabularies maintenance to user communities (CGI, INSPIRE, Others) under the governance of the Vocabulary working group.

It was felt that if a vocabulary should be formalised, it should be RockMaterial. It's already what academia and industry is concentrating on.

A smaller group decided to meet again to discuss the technical aspect of vocabularies.

  • hosting issue

  • proposal to rename hasXXX for properties

GeoJSON vs JSON-LD

ELFIE discovered that JSON-LD cannot accommodate GeoJSON style geometry because RDF (JSON-LD is an encoding of RDF) does not handle arrays or arrays : this is how GeoJSON encode vertices. Big problem because it means we cannot derive a GeoJSON from RDF and now we are stuck with another from scratch encoding.

No decision from the group except monitor ELFIE engineering report.

-- EricBoisvert - 12 Jun 2018
Topic revision: r1 - 12 Jun 2018, 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