European spatial data infrastructure conceptual schema language workshop
Download
1 / 25

European Spatial Data Infrastructure Conceptual Schema Language workshop - PowerPoint PPT Presentation


  • 105 Views
  • Uploaded on
  • Presentation posted in: General

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. Outline. Introduction Issues, challenges

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentation

European Spatial Data Infrastructure Conceptual Schema Language workshop

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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


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.


Participants


Participants


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!


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


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


ad
  • Login