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
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)
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.
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.
There is hope: https://github.com/cschwarz/wkx (given this - why even bother with WKT ? why not using WKB ?)-- EricBoisvert - 12 Jun 2018