GeoSciML Interoperability Working Group

Formed in 2003 under the Commission for the Management and Application of Geoscience Information (CGI) of the International Union of Geological Sciences (IUGS) It is currently comprised of geology and information technology specialists from 7 countries across Europe, North America, Australia and Asia GeoSciML Interoperability Working Group

Geoscience Australia Nick Ardlie Dale Percival Ollie Raymond Aaron Sedgmen Lesley Wyborn CSIRO Simon Cox Geoscience Victoria Alistair Ritchie Bruce Simons BRGM Christian Bellier Dominique Janjou Francois Robida Jean-Jacques Serrano Geological Survey of Canada Eric Boisvert Boyan Brodaric Geological Survey of Sweden Jonas Holmberg Lars Stolen US Geological Survey Bruce Johnson Arizona Geological Survey Steve Richard British Geological Survey Tim Duffy John Laxton Marcus Sen

GeoScience Markup Language a geoscience-specific, GML (Geography Markup Language) application schema a standard data transfer model for exchange of digital geological information version 1.1 released in 2006 version 2.0 development in progress - international team met in Tucson last week

In 2006, the GeoSciML team constructed a WFS / WMS testbed to demonstrate access to geological data from globally distributed sources used GeoSciML as the data transfer standard first demonstrated at IAMG Conference, Liege, Belgium further development of web clients occurred during 2007

Use case 1: - load a web service - display a map - query a single feature - return attributes in GeoSciML Use case 2: - query a group of map features - download features in GeoSciML format Use case 3: - reclassify (colour) map features based on GeoSciML attributes Use case 4: - select a set of geologic unit mapped features on the basis of age or lithology and highlight them

Canada, USA, Sweden ESRI ArcIMS, MapServer, Oracle platforms Cocoon wrapper to handle queries and XML transformations UK, Australia GeoServer (open source) serving data from ArcSDE and Oracle sources France Ionic RedSpider WMS server and client custom development for WFS Web servers in 6 countries

Canada Phoenix France Ionic RedSpider includes client for borehole data Australia Moximedia IMF (prototype for limited use cases) Generic desktop clients eg: Gaia for testing purposes Web clients

Client in Canada (Phoenix)

Vancouver, CN Uppsala, SV Canberra, AU Ottawa, CN Reston, VA Keyworth, UK Portland, OR Orleans, FR WEB SERVERS USER

Vancouver, CN Canberra, AU Orleans, FR WEB CLIENTS USER

Uppsala, SV Canberra, AU Ottawa, CN Reston, VA Keyworth, UK Portland, OR Orleans, FR WEB SERVERS Vancouver, CN USER

GeoSciML Uppsala, SV Canberra, AU Ottawa, CA Reston, VA Keyworth, UK Tuscon, AZ Orleans, FR USER Vancouver, CN

The 3 most important things to consider in constructing an OGC domain-specific interoperable testbed 1.compliance 2.compliance 3.compliance - to OGC web standards - to the data model schema (GeoSciML) - to agreed vocabularies

Complex and relatively immature GeoSciML data standard (v1.1) Operating at the cutting edge of OGC WFS implementation OGC standards are still developing Operating at the limit of server and client software capabilities (both open source and proprietary vendor) Specifically defining use cases Working towards defined and discrete development milestones The tyranny of distance - communication across the globe

GeoSciML is a relatively complex feature model compared to most existing OGC-compliant WFS services

It contains much interpretive and text-based data Not a large amount of relatively simple numerical data Semantic compliance is not a trivial exercise Requires many vocabularies

Use Cases very important to be developed in conjunction with data model development must be: - useful (scientifically desirable) - useable (practically usable) - achievable (software or standards limitations) - and very well described (documentation) Currently developing Use Cases for the next GeoSciML testbed in parallel with recent GeoSciML v2.0 developments

Best Practice documentation Important to be included with the data model documentation - particularly a model as complex as GeoSciML - to maximise interoperability between data sources Unconstrained population of a complex data model restricts the interoperable use of the provided services However, data model designers cannot legislate for inappropriate application of the data model by users

Ontologies, vocabularies (and mapping local data to them) Local database vocabularies vs agreed international vocabularies e.g. Australian time scale vs International time scale (both of these vocabularies are in English but there are dialect issues) Geoscience Australia mapped the Australian terms to the agreed international terms for their testbed data service

Cainozoic? Palaeozoic? Archaean? Bolindian? Eastonian? Gisbornian? Late? Early? SYNONYMS easy mapping NOT SYNONYMS not so easy

Compliance to vocabularies (like Age) is crucial to be able to construct standardised WFS / WMS requests on distributed data This became evident very quickly in the GeoSciML testbed in trying to execute agreed use cases - e.g.“redisplay geologic features on the basis of Age” “select geologic features on the basis of Age“

Compliance to vocabularies (like Age) is crucial to be able to construct standardised WFS / WMS requests on distributed data This became evident very quickly in the GeoSciML testbed in trying to execute agreed use cases - e.g.“redisplay geologic features on the basis of Age” “select geologic features on the basis of Age“

Ontologies, vocabularies – a long way still to go - multilingual – both concepts and terminology - need internationally agreed vocabularies for more than just Age - the holy grail of vocabulary work - GeoSciML vocabulary (Concept Definition) working group and others

Flexibility in data representation a feature of the GeoSciML model allows representation of some data in different ways according to user’s need e.g. geologic age - single numeric value (eg: 455 Ma) - single scoped text value (eg: Ordovician) - lower and upper value range (eg: 420 to 460 Ma; Silurian to Ordovician)

This pattern is flexible and entirely representative of how geologists use Age information, BUT…. it is an issue for interoperability - how do you process a WFS query on Age if the data is in different, but still schema compliant, formats? GeoSciML v2.0 now contains a preferredAge attribute - a single attribute designed to allow simpler and more straightforward queries on Age

Testbed example of WFS filter query on “age” Client’s decision to query on “upper age” only

Existing proprietary vendor software and open source software aims to support the detail of OGC web service specifications (e.g. GML and complex features) …but they are still at the developmental stage Beware using the most recent version OGC / WFS standards in your testbed if your WFS software is not up to it yet

Much collaborative work was done with software developers during the GeoSciML testbed to be able to serve the complex features needed for the testbed This added considerably to the time and effort needed to deliver the testbed

Implications of the GeoSciML testbed Highlighted both the practical capabilities (the successes) and the limitations of WFS and OGC standards in a real-world, complex feature environment Highlighted technical challenges that need to be addressed by software developers and vendors to be able to deliver and consume OGC-compliant, complex feature WFS services

Implications of the GeoSciML testbed Highlighted the need to establish and comply with well-defined use cases for the use of data services Highlighted the importance of rigorous documentation for the data model to guide participants in a distributed network

For further information on GeoSciML: