KEN Interviews: Simon Templer of Fraunhofer IGD

In the second interview of the INSPIRE KEN series, my guest is Simon Templer. He is a researcher at the Fraunhofer Institute for Computer Graphics Research IGD and is the lead developer for HALE. His Spatial Information Management group at Fraunhofer IGD was the coordinator of the HUMBOLDT research project and is still the driving force behind the continuous development of HALE.

Thorsten: What was the big idea that led to the development your software?

Simon: Enabling domain experts to easily create and maintain Schema Mappings – even for complex schemata.

Thorsten: What is the main strength of your software? What are you particularly proud of?

Simon: The main strength is the instant feedback you get on the transformation during the whole process of creating the Schema Mapping. Starting with the first relation you create you can observe how the transformation takes form and visually verify the results.

As I’m also a developer working on HALE I see a different strength – HALE is designed to be extendable. It offers a large set of extension points, e.g. to add support for additional schema and data formats, transformation functions or User Interface components.

Thorsten: For which problems or use cases is it particularly well suited? What differentiates it from other products or solutions?

Simon: The INSPIRE GML Application Schemata and many other XML schemata are really complex. Other tools tend to work well with simple feature models, but get exponentially harder to use and understand with increased schema complexity. Scaling an intuitive, simple user experience to schemata of any complexity and data sets of any size is one thing we focused on when developing HALE – but without hard-coding everything, so that power users still have as much choice as they need.

Thorsten: On which phases of a schema transformation project does your software focus?

Simon: The main focus lies on the development and maintenance of the Schema Mapping. The design, development, debug and validation phases are not strictly separated in HALE, but are rather tied into a single, fast feedback loop. However, for each phase you can create specific resources.

Thorsten:Describe (ideally use a concrete example) how users of your software should design the schema transformation in a project.

Simon: To design a schema transformation, people use HALE’s schema explorer as well as the source data view to analyze the schemata and data. An especially helpful function in this phase are the statistics on the schema, such as which elements are actually filled with data, and with what kinds of data. The schemata can also be exported as a matching table to get feedback from persons used to working with matching tables. The next step is identifying correspondences and deciding how to express them as relations in HALE, first on type, then on property level.

Thorsten: Describe (ideally use a concrete example) how users of your software develop the actual schema transformation. Which tools do they need, which knowledge should they have?

Simon: The development tool is HALE, and it can be used without programming skills – just bring your data model knowledge. Developing the Schema Mapping is a short cycle of defining or adapting individual relations and immediately getting feedback on how the changes influence the transformation. Rapid development is supported through the accessible schema documentation, instant transformation feedback, validation of transformed instances, as well as generated and user defined mapping documentation.

In addition to the regular relations that are used to define the Schema Mapping, advanced users have the possibility to combine them with custom Groovy scripts.

Thorsten: Describe (ideally use a concrete example) how users of your software should debug and validate the schema transformation process they have developed. Again, which additional tools and knowledge do they require?

Simon: During the creation of the Schema Mapping sample data is transformed and validated based on the constraints defined by the associated schema. Transformed objects can be inspected individually or as a whole, and compared with the objects they originated from. Errors in individual relations won’t stop the transformation – HALE always provides as complete results as possible.

Thorsten: Describe (ideally use a concrete example) how users of your software should document a schema transformation project.

Simon: Documentation can be generated automatically for a mapping project in a variety of formats, such as HTML or Excel. It includes detailed information on all defined relations. In addition, notes and comments can be attached to each individual relation as well as the whole project.

Thorsten: Describe (ideally use a concrete example) how users of your software should maintain a schema transformation project.

Simon: Due to the declarative nature of our mapping language, each relation can be independently added, removed, edited or disabled. Mappings can be versioned, forked and merged. Furthermore it is possible to import existing mappings in your own project. As an example, you can import a CityGML to INSPIRE Buildings base mapping and then create your own mapping to deal with an ADE.

Thorsten: Classify your software according to the criteria given in this article:


  • Paradigm: HALE uses a declarative approach.

  • Execution: HALE combines Schema-driven and Instance-driven elements during the transformation – schema and mapping are compiled into a transformation graph which can be modified for individual instances.

  • Representation: HALE uses a graphical representation of relations as well an RDF-Text-based one. The user creates and configures relations guided step-by-step by specific wizards.
  • Expressiveness: Out of the box, HALE offers almost complete expressiveness. It only lacks spatial filtering and loop constructs. Both are rarely used (so far they haven’t been requested by the users) and can be added through scripting or custom extensions.

Thorsten: Give an example of a schema transformation project in the INSPIRE context using your software.

Simon: In our newest user project, KU Leuven from Belgium uses HALE to produce Air Quality data compliant to INSPIRE and the EU Air Quality Directive IPR, based on their existing Web Feature Service.

Thorsten: What do you think of creating a schema transformation standard language, e.g. in the OGC?

Simon: A schema transformation standard language should be relatively easy to design and implement. It should focus on defining a framework, with some basic transformation functionality and mechanisms to extend it, coupled with a public registry to discover transformations.

Thorsten: Anything else that you would like to explain? Future plans for the software? The next big thing?

Simon: Be sure to check out the next release which will be out in the first half of November. It adds transformation based on PostgreSQL/PostGIS databases, an improved user interface for defining classifications and advanced scripting functions.

Thorsten: Thank you very much, Simon!

Leave a Reply

Your email address will not be published. Required fields are marked *