1. European Spatial Data Infrastructure Conceptual Schema Language workshop Summary INSPIRE – EuroSDR – CEN/TC 287 WG SDI 13 and 14 Oct 2005, JRC, Ispra, Italy Paul.smits@jrc.itPaul.smits@jrc.it, Stephen.peedell@jrc.it, anders.friis@jrc.itStephen.peedell@jrc.itanders.friis@jrc.it 17 Oct 2005

2. Outline Introduction Issues, challenges Recommendations

3. 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.

4. Participants Last nameFirst name Affiliatione-mail BellusiAlbertoUniv. Veronaalberto.belussi@univr.it BernardLarsJRClars.bernard@jrc.it BernathAndreINTERLISabernath@geoaargau.ch BielskiConradJRCConrad.bielski@jrc.it BorrebækMortenCEN/TC 287morten.borrebaek@statkart.no CragliaMaxJRCmassimo.craglia@jrc.it CurtisEddySnowflakeeddie.curtis@snowflakesoftware.co.uk EisenhutClaudeEisenhut Informatikce@eisenhutinformatik.ch Friis-ChristensenAndersJRCanders.friis@jrc.it GnägiHans- Rudolf INTERLISgnaegi@geod.baug.ethz.ch GriseSteveESRIsgrise@esri.com HøseggenSteinarStandardssteinar.hoseggen@bravida.no

5. Participants IllertAndreasBKG Germanyandreas.illert@bkg.bund.de JanssenPaulRAVIpaul.janssen@ravi.nl KanellopoulosIoannisJRCioannis.kanellopoulos@jrc.it KmiecikAlinaCEN/TC 287akmiecik@ics.p.lodz.pl Lehto Lassi Finnish Geodetic InstituteLassi.Lehto@fgi.fi LesageNicolasEuroGeographicsnicolas.lesage@ign.fr LutzMichaelm.lutz@uni-muenster.de MillotMichelJRCmichel.millot@jrc.it NowakJoannaJRCjoanna.nowak@jrc.it PeedellSteveJRCstephen.peedell@jrc.it PorteleClemensInteractive Instrumentsclemens@portele.de QuakWilkoUniv. Delftw.quak@otb.tudelft.nl SchadeSvenUniv. Muensterschades@uni-muenster.de SmitsPaulJRC, CEN/TC 287paul.smits@jrc.it SonnetJeromeIONIC Softwarejerome.sonnet@ionicsoft.com TothKatalinJRCkatalin.toth@jrc.it VowlesGrahamOrdnance Surveygraham.vowles@ordnancesurvey.co.uk WoodsfordPeterEuroSDRconsultancy.woodsford@ntlworld.com

6. V(owles)-diagram

7. 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)

8. 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!

9. The role of CSLs in interoperability Data transfer Matching application schemas Semantic mapping Without CSL: Weeks Hours Seconds, minutes This is where CSL can help

10. CSLs are important Conceptual schema languages will greatly benefit the integration of national data in a European context

11. 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

12. 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.

13. Outline Introduction Issues, challenges, research Recommendations

14. 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?

15. Outline Introduction Issues, challenges Recommendations

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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)

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