SDI 4 Apps - Uptake of open geographic information through innovative services based on linked data

Technical experts from the SDI4Apps and OpenTransportNet projects discussed some technical aspects of linked open data with the main standardisation body in the area of web technologies and data, the World Wide Web Consortium (W3C).

The meeting took place in Brussels at the premises of the OpenTransportNet coordinator, the Flemish Region authority. A three day workshop provided a lot of interesting discussions when some open issues were solved and many other issues emerged.

The following topics were on the agenda:

  • metadata catalogues and the GeoDCAT-AP standard,
  • open data including open transport data, points of interest and open land use data,
  • application programming interfaces (APIs).


OpenTransportNet uses CKAN and Micka as metadata catalogues. CKAN supports mainly open data, while Micka was designed for handling metadata of geospatial (geographic) data. The features of both catalogues provide certain advantages that the other catalogue is lacking. Also using both catalogues caused a lot of confusion on the side of the users.

The discussion led to a conclusion to use CKAN only as a middleware, a component in the entire architecture for retrieving and storing open non-spatial data and their metadata and invisible for the user. Metadata records are then through a developed extension of CKAN forwarded to Micka. Micka serves as a single access point for all metadata including those related to geospatial data.

The key point of the discussion was the brand new standard for metadata records GeoDCAT Application Profile (GeoDCAT-AP) developed by the Joint Research Centre in Ispra (JRC) in collaboration with W3C and the Open Geospatial Consortium (OGC). This standard is a combination of the INSPIRE metadata specification for geospatial data and the GeoDCAT-AP for public sector datasets in Europe. GeoDCAT-AP is based on the W3C’ Data Catalog Vocabulary (DCAT) recommendation for describing data catalogues. The development of the GeoDCAT-AP was initiated jointly by the DG CONNECT, DG DIGIT and the Publications Office of the EU.

Micka is one of the very few metadata catalogues supporting this GeoDCAT-AP. That’s also why Micka was chosen as the main access point for the OpenTransportNet data hub users. In this way, OpenTransportNet is testing the implementation and use of the GeoDCAT-AP and provides feedback to JRC, W3C and OGC.

A comprehensive overview of the OpenTransportNet approach for handling metadata can be found here.

Open Data

SDI4Apps and OpenTransportNet recently signed a Memorandum of Understanding to cooperate on open datasets including:

Data management, which is the main point of the cooperation, is time consuming and requires a lot of resources. Sharing data management tasks will mean that users will have access to more and up-to-date data.

A lively debate was about the Smart Points of Interest dataset, especially what concerns the persistent identifier of POIs. Otakar Cerba (UWB) designed the identifier as a combination of the following items:

  • Country code (based on ISO 3166-1 alpha-2)
  • Category of POI (based on the Waze navigation data)
  • Coordinates (longitude and latitude)

An example can be:

<rdf:Description rdf:about=”“>

where ML refers to Mali, NAT refers to Natural features and 0.8712 is longitude and 14.9746 is latitude.

Phil Archer (W3C) argued that this identifier is not unique for every point of interest, which is the main principle of Linked Open Data that every resource has a unique identifier. If there will be two cash machines next to each other and each of them will be mapped as a point of interest, then the country code will be the same, category will be the same and coordinates might be the same as well for both points of interest.

Moreover, Phil said that the coordinates of a point of interest might change in time and the same applies to the country code. In the end, the only persistent part of the identifier is the category.

The experts haven’t come to a solution of this problem. However, a viable solution seems to be to use a code (a running number) instead of the human readable identifier.

Application Programming Interfaces (APIs)

Runar Bergheim (AVINET) presented the current status of the API development for the SDI4Apps project. OpenTransportMap decided to reuse some of the features and implement them in the open data hub that is developing.

The SDI4Apps developers also discussed a problematic behaviour of Virtuoso, the engine used for data storage and publication as SPARQL endpoints in SDI4Apps. They agreed to perform a testing of other open source solutions.

Stay tuned and follow our next steps and developments through this channel!

Your opinion and comments on the above mentioned issues will be appreciated.

Share this: