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 technologyspecialists from 7 countries across Europe, North America, Australia and Asia

GeoSciML Interoperability Working Group

Geoscience AustraliaNick ArdlieDale PercivalOllie RaymondAaron SedgmenLesley Wyborn

CSIROSimon Cox

Geoscience VictoriaAlistair RitchieBruce Simons

BRGMChristian BellierDominique JanjouFrancois RobidaJean-Jacques Serrano

Geological Survey of CanadaEric Boisvert Boyan Brodaric

Geological Survey of SwedenJonas HolmbergLars Stolen

US Geological SurveyBruce Johnson

Arizona Geological SurveySteve Richard

British Geological SurveyTim DuffyJohn LaxtonMarcus Sen

• GeoScience Markup Language

• a geoscience-specific, GML (Geography Markup Language) application schema

• a standard data transfer model for exchange of digitalgeological 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)

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:

https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/GeoSciML