European Spatial Data Infrastructure Conceptual Schema Language workshop

Summary

INSPIRE – EuroSDR – CEN/TC 287 WG SDI13 and 14 Oct 2005, JRC, Ispra, Italy

Paul.smits@jrc.it, Stephen.peedell@jrc.it, anders.friis@jrc.it

17 Oct 2005

Outline

• Introduction

• Issues, challenges

• Recommendations

Objectives• Translation of a conceptual model between schema languages:

– to draw-up an inventory of the state of the art of operational and experimental software tools that allow for a model created in one schema language (e.g., Visio / ArcGIS Geodatabase) to be used in a different schema language (e.g., INTERLIS).

• Model mapping: – to map, for a specific application domain, an instance of a data model to

a common data model.

• Justification– Existing modelling initiatives are currently not based on a common

conceptual schema language or tools. Therefore, in cross-community applications, issues of interoperability may arise that hinder effective deployment of solutions.

– Mapping legacy data to common data schema may be a solution to data interoperability that avoids expensive re-engineering of data.

ParticipantsLast name First

nameAffiliation e-mail

Bellusi Alberto Univ. Verona alberto.belussi@univr.it

Bernard Lars JRC lars.bernard@jrc.it

Bernath Andre INTERLIS abernath@geoaargau.ch

Bielski Conrad JRC Conrad.bielski@jrc.it

Borrebæk Morten CEN/TC 287 morten.borrebaek@statkart.no

Craglia Max JRC massimo.craglia@jrc.it

Curtis Eddy Snowflake eddie.curtis@snowflakesoftware.co.uk

Eisenhut Claude Eisenhut Informatik ce@eisenhutinformatik.ch

Friis-Christensen Anders JRC anders.friis@jrc.it

Gnägi Hans-Rudolf

INTERLIS gnaegi@geod.baug.ethz.ch

Grise Steve ESRI sgrise@esri.com

Høseggen Steinar Standards steinar.hoseggen@bravida.no

ParticipantsIllert Andreas BKG Germany andreas.illert@bkg.bund.de

Janssen Paul RAVI paul.janssen@ravi.nl

Kanellopoulos Ioannis JRC ioannis.kanellopoulos@jrc.it

Kmiecik Alina CEN/TC 287 akmiecik@ics.p.lodz.pl

Lehto Lassi Finnish Geodetic Institute Lassi.Lehto@fgi.fi

Lesage Nicolas EuroGeographics nicolas.lesage@ign.fr

Lutz Michael m.lutz@uni-muenster.de

Millot Michel JRC michel.millot@jrc.it

Nowak Joanna JRC joanna.nowak@jrc.it

Peedell Steve JRC stephen.peedell@jrc.it

Portele Clemens Interactive Instruments clemens@portele.de

Quak Wilko Univ. Delft w.quak@otb.tudelft.nl

Schade Sven Univ. Muenster schades@uni-muenster.de

Smits Paul JRC, CEN/TC 287 paul.smits@jrc.it

Sonnet Jerome IONIC Software jerome.sonnet@ionicsoft.com

Toth Katalin JRC katalin.toth@jrc.it

Vowles Graham Ordnance Survey graham.vowles@ordnancesurvey.co.uk

Woodsford Peter EuroSDR consultancy.woodsford@ntlworld.com

Conceptual Model

Logical Model

Physical Model

Validation Logial Model

Validation Conceptual Model

Conceptual Schema

Logical Schema

Consumer

V(owles)-diagram

Speaking the customer’s language

• Natural language THE way to tune an information product to consumer’s requirements– Possibly augmented with graphics, markups,

prototypes– Iteration between information product designer

and customer remains key element– Feature Catalogues play important role here– No specific technologies required for user (html,

word)

Technical speak

• Down the V, technical people need more structure– Conceptual Schema Language can be helpful– General models that limit UML options

enhance interoperability• But balance is important: limited UML options can

become obstacles when too detailed!

The role of CSLs in interoperability

xxx Model Semantic Mapping

Software Tool

yyy model

xxx

Records

yyyy

GML file

Re

lati

on

al

Imp

l em

en

tati

on

XM

L I

mp

l em

en

tati

on

xxx Relational Schema

Software toolyyy

GML Schema

Data transfer

Matching application schemas

Semantic mapping

Without CSL: Weeks

Hours

Seconds, minutes

This is where CSL can help

CSLs are important

• Conceptual schema languages will greatly benefit the integration of national data in a European context

Similar approaches in NO, CH, DE, IT (IntesaGI)

• Guidelines for the use of UML – customized profile of ISO 19103/19109– Sufficient for data modelling, geographic concepts are brought in

by using ISO 191xx types but may require additional rules

• Rules for– Identifiers– Coordinate references systems– Units of measurements

• Constraints (important for management/validation and maintenance, less for publication)– OCL constraints– Natural language– Allowed feature types in topological themes

Similar approaches in DE, CH, NO, IntesaGIS (IT) (cont’d)

• Constraints should, where possible, be expressed at the conceptual level (important for management/validation and maintenance, less for publication)

• Constraints are important– validation – Properties– Allowed feature types in topological themes – Specify constraints also when it is not clear how to implement them

• Constraints are difficult– It’s a paradox, we want simplicity, but constraints are complex formalisms

• Constraints can be expressed– In natural language– As OCL constraints– Constraints could also be on the model design, e.g. the documentation filed

should always be filled– Constraints depend on the scope of the model– Constraints can be disconnected from the conceptual level, eg. Refer to MGSCP

(Nicholas)• The Group recommends organizing a workshop on this topic.

Outline

• Introduction

• Issues, challenges, research

• Recommendations

Issues, challenges

• The user– What is the relation with requirements? – Look at tools needed to satisfy user requirements, which may

include management of feature catalogues– Whole Information Resource (offering, resource [data+services]) – Can we achieve sustainable solutions? – Education and training

• What is the foundation (base model)? • The role of ontologies in the mapping between CSLs• Support for service architecture

– Schema translation, What is the state of the art? Maturity of technologies.

– How to handle huge amounts of data?

Outline

• Introduction

• Issues, challenges

• Recommendations

Recommendations

• General– UML is to be used in accordance with ISO 191xx (see

approaches CH, DE, IT, NO) with additional tailoring (rules in GML standard good starting point)

– Maintain the reference version of the schema in one tool

– Common model as simple and as high level as possible

– Test and iterate– Develop guidelines for harmonizing these approaches– Encourage system vendors for CSL tool support

Recommendations

• Producer’s relation with the customer– “Whole Information Resource” principle– The function of the information product

designer is paramount– Distinguish between types of users and use-

cases– Formal description helps in communication– Separate specification and use

Recommendations

• Common model– Common model should be modular

• Establish plan to evolve from simple to more complex• Contribute to relevant standards• Use relevant standards, harmonize usage of standards

– And is to be devised in a stepwise approach• Collect national models• Find common denominator

– Of the models– Of the Rules

• Develop guidelines– Develop feature catalogues, support multi-lingual

usage

Recommendations

• CSL tools, software– Tackle model issues within INSPIRE

framework– Technical forum resulting from ESDI CSL

workshop– Develop practical recommendations of the

usage of tools, like the use the documentation field of the CSL tool

Recommendations

• Outreach and training– Define use cases for CSLs

• Derive requirements for different tasks• “Get simple, Get real”

– Create content guidelines– Validation, also in relation with INSPIRE

• Of models• Of data

– Devise implementation spirals• Including milestones, while keeping the focus on strategy

– Education and training• ISO 191xx standards, involve universities

– Website, forum

Recommendations

• Service architecture– Data model is part of information viewpoint of

RM-ODP– Be careful with automatic transformations,

which can result in bad data– Establish state of the art in WFS-T

• Also on the client side

– Develop implementation spirals with milestones

Recommendations

• Support the community– Any infrastructure is built on knowledge

• Currently focus is on technologies• Should be more on business

– Education and training• Sustainability (resources) requires education of managers• Knowledge of how to do it must be spread

– Guidelines, workshops, …

– Community will benefit from a combination of open tools and encodings, and market mechanisms

Recommendations

• Research topics and workshops– Mapping between CS models by using

ontologies– Visual ontology representation for

communication with users– Geometric issues/ model+geometric

generalization/scale issues– GI business, better identification of who are

the users

Recommendations

• Further standardization work– Clarify the role of feature catalogues and

potentially data dictionaries -> feedback to standardization process

– Support the creation of abstract representations of selected OGC specs (WFS is good example)

Recommendations

• Participants of workshop to submit any material as reference material for INSPIRE– Send e-mail to stephen.peedell@jrc.it