INSPIRE Data Specification Extensions
  1. Introduction
  2. Results of the Survey
  3. Inventory of Model Extensions
  4. The INSPIRE Model-Driven Methodology
    1. Creating the Conceptual Model
    2. The INSPIRE Process
    3. Further Reading
    4. Glossary
  5. The Extension Methodology
  6. The Pattern Catalogue
  7. An End-to-End Tutorial Project
  8. Conclusions and Outlook

The INSPIRE Model-Driven Approach

INSPIRE is a directive about interoperability and accessibility of geospatial data related to the environment. Interoperability means that different systems are compatible and are able to exchange information, so that other systems will understand it. There are many different ways about how to achieve interoperability of computer systems, one of which is the Model-Driven Architecture approach (MDA).

 Reading this section will help you understand the extension methodology and much of the related terminology better if you haven't been exposed to it before.

MDA defines a set of guidelines for structuring specifications expressed as models. Using the MDA methodology, system functionality is specified as a platform-independent model (PIM). By creating a common PIM, the INSPIRE community has achieved conceptual interoperability - we have created a common data specification. The PIM has been created using an appropriate Domain Specific Language. In INSPIRE and ISO, this language is the Unified Modelling Language (UML). UML is a language that can be used to describe all kinds of aspects of systems, be it organisations or software:

  • Static aspects such as data structure (Class and Component Diagrams)
  • Dynamic aspects such as run-time behaviour or business processes (BPMN, Activity Diagram, Sequence Diagram)
  • Relationships between people and software (Use Case Diagrams)

To achieve operational interoperability, the PIM is translated to one or more platform-specific models (PSMs), using an implementation language such as like Java, Python, or XML Schema. The translations between the PIM and PSMs are normally performed using automated tools, like model transformation tools. This is a core aspect: Ideally, we «only» have to agree on a conceptual model (PIM), and can generate interoperable PSMs - even for different platforms - automatically.

Model Transformation on different levels

For INSPIRE in particular, the MDA approach brought several advantages with it:

  • Consistent and well-structured approach across the teams working on all 34 themes
  • Ability to model cross-theme relationships
  • Effective re-use and detection of inconsistencies and errors
  • Easy generation of encodings and other artifacts such as feature catalogues and mapping tables

Creating the INSPIRE conceptual Model

The conceptual model sits at the top of the interoperability stack in MDA. Conceptual modeling is the process of creating a formal description of a portion of the real world. The abstract description of these real-world features is called a conceptual model.

In the conceptual model, we express the meaning of terms and concepts used by domain experts to discuss a subject area, and to find the correct relationships between different concepts. The conceptual model clarifies the meaning of terms that are usually ambiguous terms, and resolves problems with different interpretations of the terms and concepts. In the UML notation, we usually describe the conceptual model using a class diagram. Classes represent concepts, associations represent relationships between concepts and role types of an association represent role types taken by instances of the modelled concepts in various situations.

From Use Case to Data Specification

To achieve interoperability the stakeholders of INSPIRE play a key role. User-centered modeling is a process based on understanding the needs of the stakeholders and the reasons why the model should be developed. Use cases allow us to structure these needs. A use case is a written description of how users will perform certain tasks It outlines, from a user’s point of view these tasks and identifies information needs. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.

The creation of an INSPIRE data specification for each of the 33 themes followed these phases:

  1. Organise a thematic working group
  2. Collect Use Cases
  3. Identify user requirements and Spatial Object types
  4. Determine required level of interoperability
  5. Perform as-is analysis and gap analysis
  6. Design a draft model
  7. Test the model and consult stakeholders
  8. Iterate over the model and feedback cycle
  9. After release, maintain the model
From reality to conceptual schema

Further Reading

If you'd like to know more about the INSPIRE MDA approach, please refer to the following sources:

  • INSPIRE Generic Conceptual Model: This document provides a common technological and methodological framework for the creation of INSPIRE data specifications. It is the baseline document for all model extension work as well.
  • TC211 UML Best Practices: This GitHub repository contains best practices on UML modelling in accordance with ISO standards, which is useful for the modelling of the extensions of INSPIRE. The repository also contains Enterprise Architect Model Validation scripts you can use to test you model's compliance to the ISO guidance.
  • Guidelines for the encoding of Spatial Data: This document describes how to create interoperable data using a common encoding derived from the conceptual model.
  • EN ISO 19101:2005, Geographic information — Reference model: This ISO standard and other in the 191xx series provide the foundation for the INSPIRE Generic Conceptual Model.

Glossary

This is an abbreviated and commented excerpt of the Terms given in the INSPIRE Generic Conceptual Model.

  • attribute: A single, simple or complex, named data element that is part of a class. Also called a property.
  • class: A description of a set of objects that share the same attributes, constraints, and semantics.
  • code list: An enumeration of fixed values. Such values are often codes instead of readable values, e.g. "1201" instead of "primary school", so a look-up table is needed for interpretation. Code Lists can often be extended with additional or more specific values.
  • conceptual schema: A formal description of a conceptual model, created using a conceptual schema language.
  • conceptual schema language: A formal language for the purpose of representing conceptual schemas. In INSPIRE and ISO 191xx, UML (Unified Modelling Language) is used.
  • constraint: Constraints are restrictions that allow us to exactly describe what a valid data structure looks like. In a very simple form, a constraint limits the values a certain property can take, similar to assigning a code list to the property.
  • data set: An identifiable collection of data, e.g. a set of files that each contain a feature collection.
  • data specification: A detailed description of a data set or data set series together with additional information that will enable it to be created, supplied to and used by another party. In INSPIRE, the term refers to a harmonised data specification for a theme adopted as an Implementing Rule.
  • feature: A (geographic) feature is an abstraction of a real world phenomenon. It's structure is defined in a class, the feature type. Also called Spatial Object.
  • feature type: A specific type of class that contains a location data structure, such as a bounding box or a polygon.
  • reference: A link or an association between different features.