Marine Community and OGC Experiences of the MarineXML initiative EU MarineXML project SEEGrid IOC-UNESCO

Marine Community and OGCExperiences of the MarineXML

initiative

EU MarineXML projectSEEGrid

IOC-UNESCO

Introduction

• The issues– Marine Community and

Interoperability

• Solutions– Applications of XML and implications– Approaches to using GML

• Route map– Where things are going

MarineXML Overview

Re-use is the nub of the issue

MarineXML Overview

• Major marine-related initiatives requiring data interoperability

• GOOS / EuroGOOS– Global Ocean Observing System– JCOMM (WMO/IOC)

• GMES (EC/ESA)– Global Monitoring for Environmental

Security

MarineXML Overview

XML Wrapper

History and Context

• XML has been used for data exchange in several disciplines:– GML (geographic data)– CML (chemical data)– BSML (human genome project)– XMML (mining applications)– XSIL (general-purpose scientific data)

WP4 Ontologies and Glossaries

Physical - Chemical - Biological

• ISO FTC and Ontologies– MarineXML deployment should be based on ISO FTCs

– FTC is an ontology linking features, attributes and enumerates for a particular community.

– Initial FTC expressed in XSD (‘GML application schema’)

• Prototype marine science ‘ontology’ (D8) complete, but needs issuing as a report.– Developed as NERC-funded project entitled EnParDis with

impetus from MarineXML

– Incorporated within Marine Profile of NDG giving ‘marine science FT dictionary’

• Ontology can be refined as part of the test bed deployment

History and Context

• Projects using XML for marine data exchange:– CML

• coastal mark-up language • Oregon State University (USA)

– MIML • marine information mark-up language• US Coastguard - Waterways Information Network

– MMML (triple ML)• Model and monitoring data mark-up• RIKZ, NL

IOC/ICES Study Group

National Marine Data Centres

MarineXML Initiatives

EU MarineXML

National Marine Data CentresPrivate companies

Research OrganisationsGovernment Agencies

MarineXML.net

IODE

EU MarineXML Project

Aims of the EU Project

WP4Ontologies and

Glossariess

WP5Test Bed

Demonstration

WP6MML Specification

Development

WP2Exploitation andDissemination

WP1Co-ordination

Process flow

Process feedback

External Input

WP3Standards Review

Standards Bodies

W3C, OASIS IHO

StakeholdersIOC/ICES

ExistingStandards and

Formats

GML, XSIL,XMML, BSIL

S-57

Proprietaryformats

ExistingResearch

ARION, CML,MIML

WP3 Standards Review


• Links with standards bodies– W3C (CCLRC)

– IHO/IHB (7CS)

– OGC (SCO)

• Analysis of standards (D6) complete– Implemented as document

• Standards relationship model (D7) complete– Implemented as Protégé ontology

– Look for approaches for deployment and long term update• Web resource

WP3 Standards Review


• GML and ISO– ISO 19136

• IHO with GML– GML encoding of S-57 v4 (IHB Intent)

– GML encoding of S-57 v3.1 (UKHO undertaking)

– IHO we have access to through 7CS and UKHO

• IOC and IHO– Collaboration intent of wider deployment of ‘S-57 FTC’ - IOC

member of MarineXML

• NDG/SEEGrid with GML– NDG/SEEGrid is informing GML 3.1 development

– NDG we have contact with through CCLRC/BODC

– SEEGrid with have contact with through SCO

IHO and FTC catalogue deployment


• A FTC is by definition bound to a user-community. In the IHO they have four main communities (OEF, ICE, AML, S-57). These communities are not over-diverse and the superset of possible FT's (features, attributes and enumerates) accordingly reasonably 'concentric'.

• Nevertheless, what IHO are looking to achieve with their move to ISO is not too dissimilar to MarineXML in that they have a 'compound register' (each with its respective FTC) served from their registry. (conceptual diagram of ISO19135 on next slide)

• To achieve this there must be some kind of ontology to map the various features, attributes and enumerates to the respective FTC: It is not clear how IHO are planning to do this; but the result is a subset of MarineXML, just restricted to the navigation domain.

• What we (the broader marine community) would like to do is extend this upper ontology and accordingly the features in the data dictionary to enable new FTC's to be defined for other communities. IOC would take on the role of the register Manager for this registry.

Register Ow ner Subm itting Organization

Control Body Register M anager

Register Registry

Register User

1

1..*qualifier

qualifiedBy

1

1..*

appointer

appointedBy 1..*

1

delegatedBy

delegator1

1..*

owner

register

1

1..*

receiver

subm itter

1..*

1

m anaged

m anager

1..* 1content storedOn

1

1..*

operator

system

1

1

contentController

controlled

1..*

1..*

usedBy

user

1..*

1..*

accessor

accessedBy

M anagem entLeve l

U ser Leve l

E xecutiveLeve l

D ep loym entLeve l

Registry M anager

1..*1..*

contentManager

system Manager

1..*

1decisionAuthority

decisionRequester

• Registry Concept (from ISO 19135).

WP4 Ontologies and Glossaries


SciencePhysicalChemical

Biological

Navigation

Dredging & Extraction

FisheriesAquaculture

Conservation

Water Quality

• What is the marine community?

WP5 Test Bed Demonstration


• Mapping between communities• Two communities ‘marine science’ (NDG) and ‘navigation’

(S-57) “FT dictionaries”• Uses ‘COZDIS’ (ECDIS) for display

• Demonstrates – the mapping process of mapping MyXML to ‘marine science’

FT’s and marine science to ‘navigation’

– what mapping is and isn't possible

– improved re-use through MyXML composed (bottom-up) from FT's

– governance model requirements

FTC and Test Beds


• Start with established parameter dictionaries and generic models (NERC Data Grid and S57)

• This NDG FT dictionary can be mapped to S-57; this is useful to establish the existence of common FT's between the navigation community and the marine science community and “allocate responsibilities” for maintaining certain FT's. This is useful pre-standardisation effort.

• These test beds can also be used to determine how a suitable governance model can be established between IOC/IHO to manage the registers in the registry; particularly for the common/shared FT's.

EC2007 ECDIS Kernel

Data Dictionary

S52 Portrayal Library

SENCMarineGML

(NDG)

XML Parser

XML

XML

XML

XML

OBIS

NetCDF

Other Data

Other Data

XSLT

XSLT

XSLT

For each XSD (for the source data) there is an

XSLT to translate the data to ‘NDG’. The XSD and XSLT are maintained in the

registry

The result of the translation is a

‘weak-typed’ GML that contains the

marine data.

NDG can then be translated to

SENC for display in the ECDIS

system

XSLT

Features in the XSD must be present in the

data dictionary.

Features in the XSD must have an associated

portrayalXSD

XSD

XSD

XSD

SeeGRID

NDG “FTC”

XML Parser

XML

OBIS

XSLT

XSD

OBIS

OBIS_Vocab_CanMap

OBIS_Vocab_NoMap

NDG

NDG_Vocab

OBIS_Vocab_NoMap

NDG Register

NDG_FTC

OBIS is an example of a private XML

S-57

S57_Vocab

NDG_Vocab_NoMap

S-57 Register

S57_FTC

MarineXML RegisteryMarineXML Features, Attributes, Enumerates

SENC

Mapping Issues


• Mapping with through up all kinds of problems– Strong versus weak typing– Semantic equivalence

• As this process continues, the dictionary of FT's will rise and so will the number of FTC's built on this. In addition the capabilities of GML will be stretched and may need to updated/extended/modified in future releases.

Mapping Issues

RegistryService

service offer

type definition

Service instance

ProviderRequester

Registry Service Application

Programming Interface

publish

bind

find

Feature Types

• Feature Types support operations– Navigate a road network– Extrapolate a surface from samples

• The level of granularity has to be based on the governance model for the schema– If no-one is prepared to put in place a

process to define semantics, interoperability has reached its limits

Feature Type Catalogue

• A tool for governance of Feature Types– Definitions– Structure– Content– Abstractions (polymorphism support)– Equivalence– Implementation resources

Mapping Feature Types

FeatureType FeatureType

Reference == Reference

QName == QName

QName == QName

Content Content

Attributes Attributes

FTC FTC

Transform

Declared Equivalence

Relationship

Transform

Track

Example

Trajectory Feature

Reference == ReferenceCRS CRS

Point WayPoint

NDG S57

Transform

Declared Equivalence

Transform

Conclusions


• Standards analysis concluded that MarineXML should be based on IS019000 standards– IHO Plans

• Marine community cannot be served by a single FTC– Ontology to map features to catalogues

– Evolutionary process

• Test-bed phase beginning• End game is re-use amongst the community

Conclusions - Conceptual Leap

• Relationships between Feature Types are not simple

• Overlapping domains bring additional mappings

• Content and structure intermingle

• But there is a way forward…

Conclusions -Catalogue/Ontology Duality

– The catalogue contains declared relationships…

– These relationships form an “ontology”– I.e. you can treat the set of Feature Types

meeting some criteria as a vocabulary • Weak typed objects classified this way• Mapped to more strongly-typed objects

– Can interrogate FTC to see if a Feature can be used a certain way

Working with MarineXML7Cs

Documents

Marine Community and OGC Experiences of the MarineXML initiative EU MarineXML project SEEGrid IOC-UNESCO