[GeoSciML] GeoSciML interoperability experiment
S.Grellet at brgm.fr
Mon Nov 13 03:14:12 EST 2017
Also sorry for the delay replying to this e-mail.
Just to let you know that we also moved forward on that topic here
1°/ Generating ontologies for a subset: GeoSciML Basic, Borehole and Lite
- Lite is cleaner that in the current GeoSciML version as we can now explicitly pick properties in GeoSciML basic and Borehole ontologies
2°/ Testing populating instances for Bholes, Geologic Units
- Pointing to vocabs when available (FR, EU, CGI GTWG) and testing some viewing (maps, graph).
3°/ As regard the methodology
- we ran ShapeChange (building on Eric's first try) to generate a starting point then revisited what was produced for the reasons mentioned by Eric and also to take the opportunity to revisit things such as references to SWE
- we tried to summarize our steps in a small doc.
Happy to push this to some svn
De : GeoSciML [mailto:geosciml-bounces at lists.opengeospatial.org] De la part de Boisvert2, Eric (NRCan/RNCan) via GeoSciML
Envoyé : lundi 30 octobre 2017 13:48
À : GeoSciml OGC mainling list <geosciml at lists.opengeospatial.org>
Objet : [GeoSciML] GeoSciML interoperability experiment
First, sorry for the delay. I was meant to follow up on this two weeks ago and got dragged into other things.
In the meant time, Marcus sent a couple of suggestions and got in contact with IGS (the folks who turned GeoSciml vocabularies in OWL) and they showed interest into participating.
In a nutshell, Marcus proposes
a) we concentrate on RDF/OWL encoding of GeoSciML, (JSON-LD considered as another encoding)
b) we look how vocabularies bound to the conceptual model, and
c) test some tools/software.
As you know, we tested UML->RDF/OWL using ShapeChange and everyone agrees it's probably not the right way to go. Not because of ShapeChange, but because UML designed to create XSD are full of XSD artefacts and GeoSciML has a lot of them. This might mean to either revisit the current UML model to create a more conceptually pure version or figure out transformation mechanisms that fix artefacts. Right now, UML model does not (?) provide all the information needed to generate a proper OWL model - it will generate an OWLish view of UML (a lot of things that could not be expressed in UML/XSD can be in OWL)
At this point, we can choose to look at a subset of GeoSciML instead of attacking the whole model (it's an interop experiment).
For b) we'll need involvement of GTGW. As a reminder, IGS took GeoSciML vocabularies (in SKOS) and modelled the terms as subtypes of GeoSciML classes (SimpleLithology terms as subtypes of RockMaterial). They also added extra properties. If I remember correctly, it's something Steve Richard also looked into on earlier version of GeoSciML. This means we remove the artificial distinction between "model" and "vocabulary".
So, the list of tasks that could be part of this IE
· Come up with 1 or 2 uses cases that could be resolved with RDF/OWL encoding
o Figure out that data provider will generate and how (piggy back on existing WFS created for OneGeology seems to be a good start)
o Figure out what (tools/software) will ingest this (IGS will be of great help here)
· Scope part of the model that we need
o Generate RDF / OWL
o Look into relevant vocabularies and rework them the way IGS did
Expert TI-GI / IT-IM Expert
eric.boisvert2 at canada.ca<mailto:eric.boisvert2 at canada.ca>,
490, rue de la Couronne, Québec (Québec),
G1K 9A9, Canada
Laboratoire de cartographie numérique et de photogrammétrie (LCNP)
Digital Cartography and Photogrammetry Laboratory (DCPL)
Commission géologique du Canada (Québec) / Geological Survey of Canada (Quebec)
Lands and Minerasl Sector / Secteur des terres et des minéraux
Ressources naturelles Canada / Natural Resources Canada Gouvernement du Canada / Government of Canada
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6966 bytes
More information about the GeoSciML