European Spatial Data Infrastructure Conceptual Schema Language workshop

1. INSPIRE – EuroSDR – CEN/TC 287 WG SDI 13 and 14 Oct 2005, JRC, Ispra, Italy European Spatial Data Infrastructure Conceptual Schema Language workshop Summary Paul.smits@jrc.it, Stephen.peedell@jrc.it, anders.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

5. Participants

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. yyy xxx Model Semantic Mapping model n o i n t a o t i l t n a a e n t n o m i e t e a l m l p e e m l R p I m L I M X yyy xxx Software tool GML Relational Schema Schema xxx Software Tool yyyy Records GML file The role of CSLs in interoperability Semantic mapping Without CSL: Weeks This is where CSL can help Matching application schemas Hours Data transfer Seconds, minutes

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

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