Post on 11-Jan-2016
description
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