European spatial data infrastructure conceptual schema language workshop
This presentation is the property of its rightful owner.
Sponsored Links
1 / 25

European Spatial Data Infrastructure Conceptual Schema Language workshop PowerPoint PPT Presentation


  • 74 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. [email protected] , [email protected] , [email protected] 17 Oct 2005. Outline. Introduction Issues, challenges

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


European spatial data infrastructure conceptual schema language workshop

INSPIRE – EuroSDR – CEN/TC 287 WG SDI

13 and 14 Oct 2005, JRC, Ispra, Italy

European Spatial Data Infrastructure Conceptual Schema Language workshop

Summary

[email protected], [email protected], [email protected]

17 Oct 2005


Outline

Outline

  • Introduction

  • Issues, challenges

  • Recommendations


Objectives

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


Participants1

Participants


European spatial data infrastructure conceptual schema language workshop

V(owles)-diagram


Speaking the customer s language

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

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

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

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

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

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.


Outline1

Outline

  • Introduction

  • Issues, challenges, research

  • Recommendations


Issues challenges

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?


Outline2

Outline

  • Introduction

  • Issues, challenges

  • Recommendations


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


Recommendations1

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


Recommendations2

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


Recommendations3

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


Recommendations4

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


Recommendations5

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


Recommendations6

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


Recommendations7

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


Recommendations8

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)


Recommendations9

Recommendations

  • Participants of workshop to submit any material as reference material for INSPIRE

    • Send e-mail to [email protected]


  • Login