Key takeaways from the INSPIRE What if…? Workshop

Michael Lutz and Athina Trakas decided to spice up the OGC Europe forum slot at the Delft Technical Meeting by asking for position papers around the question “What if we would start implementation of INSPIRE again today?”

More than 40 participants joined the workshop and first of all, saw eight three-minute presentations with a wide range of suggestions:

• Satish Sankaran (Esri Inc.) asked “What are the right metrics to measure success?”, and suggested that adoption rates could be improved if people could contribute to the infrastructure without requiring full compliance.
• Paul van Genuchten (GeoCAT) highlighted the potential of INSPIRE linked data as explored in the GeoNovum testbed Geo4Web.
• Thijs Brentjes (Geonovum) suggested a set of data specifications with a simple base, with no mandatory extensions, built on top of existing (INSPIRE) SDI. He also suggested to use additional encodings with the objective of making INSPIRE usable by web developers.
• Sylvain Grellet (BRGM) also suggested that adoption would be easier with alternative encodings (SF, JSON, ...). He was the first presenter to suggest different levels or labels for compliance. Sylvain also said that joint funding of development should be organised from the start on, instead of leaving everything to the implementers. Sylvain also suggested to better organise aspects such as trainings and hackathons.
• Clemens Portele (Interactive Instruments) explained how important stability and reliability are for a major infrastructure project like INSPIRE. He suggested to improve specifications through small, iterative changes. It should be possible to make these changes in an agile, fast, usage driven way. He briefly outlined the work done by Geonovum and Interactive Instruments on making data accessible to web applications and suggested to put facades or proxies on top of the existing INSPIRE infrastructure.
• Thorsten Reitz (wetransform) focused on the user experience of applications built directly to manage and explore INSPIRE data and services and explained that with most of the investment going to backend infrastructure, these leave a lot to be desired would be essential to show the value of the infrastructure.
• A representative of Natural Resources Canada explained the objectives of the Maps for HTML standards working group and explained that adding capabilities such as MapML would foster usage and adoption.
• Peter Bauman (Rasdaman GmbH) asked “What if our services could talk?” but wasn’t able to join in person.

These three recurring topics emerged:

1. tiered or more flexible compliance,
2. usage of web standards and improvements to data usability and
3. adding proxy layers on top of the INSPIRE infrastructure.

Following this agenda setting, we split up in four groups to discuss several key questions, using the World Cafe methodology:

• What standards and technologies should the infrastructure be based on?
• What architectural pattern would you recommend? What should be the main components of the infrastructure?
• How would you organise the implementation process and make it cost-efficient?
• How would you ensure a wide adoption and use of the infrastructure?

Athina and Michael asked me to facilitate the group discussion around the third question - “How would you organise the implementation process and make it cost-efficient?” Our objective was to define 2-3 recommendations and to suggest follow-up actions. As facilitator, I asked the following questions, and a lively discussion ensued:

What is the very first thing that should happen in the implementation process?

• Define criteria for success early on (not "only" for compliance)
• Define Interoperability (when is data interoperable -> when it us useable in clients), "General" interoperability isn't the goal, usage is!
• Provide end product specifications for high value use cases to large numbers of users
• Define success for concrete users in addition to the overall objective

If you had one year to implement INSPIRE from scratch, how would you do it?

• Start with simple data models, manage complexity (necessary vs. unnecessary, e.g. in ISO and metadata), expand over time with new use cases
• Follow pragmatic approaches
• Use a well-defined set of interfaces that are already proven (mainstream IT industry)
• Follow trend in industry towards RESTful mechanisms
• Focus on pushing data out (e.g. as done in Copernicus)

What is the process to continuously coordinate implementation and make re-use possible?

• Use agile methods such as iterative development
• Keep users in close involvement
• Identify anything
• Keep existing infrastructure, build agile infrastructure on top, then let the market choose what works
• Transparency, make it available
• The metric could be: How many users to you have? Users drive continual improvement?

How can implementation of key components be coordinated in an efficient way?

• Coordinate development of core components early on, in particular validation and registries (e.g. code lists, extensions)
• Common components should be coordinated; Harmonisation may be such an issue
• No mandatory components, but all components for a reference implementation should be available
• Make sure that requirements that are specific to INSPIRE are really understood well - Value vs. effort/costs on very specific INSPIRE requirements?
• Clarify the business case for the implementation coordinator - is that organisation paid for by taxes?
• Countries see lots of liability and low central investment
• Central funds/investments is low compared to the overall investments required for implementation and compared to COPERNICUS
• Harmonisation across INSPIRE and Copernicus currently looks like a Godzilla vs. King Kong fight, will be difficult to achieve effectively

We then consolidated recommendations:

1. We should treat INSPIRE not as separate infrastructure, but rather as integrated with existing products and processes, e.g. by extending national models to meet additional INSPIRE requirements
2. Cost effective: INSPIRE not as something specific, but as a general infrastructure and be a natural part of what we are doing
3. We would reframe INSPIRE in the context of the Open Data Movement to limit competition between INSPIRE and Open Data / Linked Open Data
4. We also make sure products are designed from the user experience first
5. We have to orient implementation guidance towards implementer's questions and problems ("How to provide a bridge in INSPIRE" --> can't be answered by a professional)
6. Have a library of reference implementations to describe how it's done for all annexes

… and Follow-Up actions:

1. Collect reference implementations as concrete guides and publish those
2. Provide compliance levels (?) as a means to get in easily
3. Find how to react to new uses cases in an agile way

A side discussion that came up in our group as well as in at least two of the other three groups was what it meant to be compliant really, but I’ll leave that for another post ☺.

All in all, I really enjoyed the highly interactive format of the What if…? Workshop and the productive discussions, which was not just rehashing of previously discussed issues. Thanks to Athina and Michael!