D06.01 - Report on the support activities to the MS, main ... Web viewReport on the support activities to the MS, main results and conclusions based on the practical results from

SC270DI07171

D06.01: Report on the support activities to the MS, main results and conclusions based on the practical results

from the pilots

D06.01 - Report on the support activities to the MS, main results and conclusions based on the practical results from the pilots

Document Metadata

Property Value

Release date 2016-11-10

Status For acceptance

Version 1.00

Authors

Michiel De Keyzer – PwC EU Services

Ana Fernández de Soria – PwC EU Services

Dimitrios Hytiroglou – PwC EU Services

Christophe Parrein – PwC EU Services

Reviewed byNikolaos Loutas – PwC EU Services

Pieter Breyne – PwC EU Services

Approved by

05/05/23 Page ii


Table of Contents1. INTRODUCTION.......................................................................................................................... 6

1.1. CONTEXT.....................................................................................................................................61.2. SCOPE AND OBJECTIVE...................................................................................................................61.3. APPROACH...................................................................................................................................71.4. STRUCTURE OF THE DOCUMENT.......................................................................................................8

2. PILOTING A CROSS-BORDER CATALOGUE OF PUBLIC SERVICES WITH FINLAND AND ESTONIA.....9

2.1.1. List of stakeholders..............................................................................................................92.1.2. Business need......................................................................................................................92.1.3. Proposed solution..............................................................................................................102.1.4. Success criteria..................................................................................................................122.1.5. Outcome and pilot results.................................................................................................132.1.6. Communication Log...........................................................................................................18

3. PILOTING A FEDERAL CATALOGUE OF PUBLIC SERVICES IN BELGIUM.........................................21

3.1.1. List of stakeholders............................................................................................................213.1.2. Business need....................................................................................................................213.1.3. Proposed solution..............................................................................................................223.1.4. Success criteria..................................................................................................................233.1.5. Outcome and pilot results.................................................................................................233.1.6. Communication Log...........................................................................................................30

4. TAILORING THE PUBLIC SERVICE DESCRIPTION EDITOR TO THE DUTCH NATIONAL DATA MODEL FOR DESCRIBING PUBLIC SERVICES (SAMENWERKENDE CATALOGI)...................................................33


5. ADAPTING THE CPSV-AP VALIDATOR FOR CPSV-AP_IT IN ITALY.................................................37


6. MAPPING NATIONAL AND REGIONAL DATA MODELS TO THE CPSV-AP......................................42


7. CONCLUSIONS AND NEXT STEPS...............................................................................................45

ANNEX I. MODULES USED BY THE PUBLIC SERVICE DESCRIPTION EDITOR...................................46

05/05/23 Page iii


List of TablesTable 1: Stakeholders list – Pilot with Estonia and Finland..........................................................................9

Table 2: Communication log with Estonia – Cross-border pilot.................................................................19

Table 3: Communication log with Finland – Cross-border pilot.................................................................19

Table 4: Stakeholders list – Pilot with Belgium..........................................................................................21

Table 5: Communication log Federal – Federal pilot.................................................................................30

Table 6: Communication log with Flanders – Federal pilot.......................................................................31

Table 7: Communication log with Wallonia – Federal pilot.......................................................................32

Table 8: Stakeholders list – Pilot with Netherlands...................................................................................33

Table 9: Summary of communications......................................................................................................36

Table 10: List of stakeholders – Validator pilot.........................................................................................37

Table 11: Summary of communications....................................................................................................40

Table 12: List of stakeholders – Mapping pilot..........................................................................................42

Table 13: Summary of communications – Malta.......................................................................................44

05/05/23 Page iv


List of FiguresFigure 1: Approach to collect public service descriptions..........................................................................10

Figure 2: Proposed solution for the cross-border pilot.............................................................................11

Figure 3: Estonian MKM website...............................................................................................................12

Figure 4: User-centric visualisation...........................................................................................................12

Figure 5: Example of Finnish mapping.......................................................................................................13

Figure 6: Mapping Estonian data model with CPSV-AP in the mapping tools...........................................14

Figure 7: Configuration file – Harvesting of Estonian and Finnish data.....................................................15

Figure 8: Filter section for citizens.............................................................................................................16

Figure 9: List of PS descriptions available for citizens................................................................................16

Figure 10: Complete PS description of a PS from Estonia and a PS from Finland......................................16

Figure 11: Additional information of a Service Provider............................................................................16

Figure 12: Technologies used for the cross-border PS descriptions’ visualisation.....................................17

Figure 13: CPSVAPdefinittion.ttl................................................................................................................18

Figure 14: Harmonised information – Federal level..................................................................................22

Figure 15: Proposed solution for the federal pilot....................................................................................23

Figure 16: Example of Flemish mapping....................................................................................................24

Figure 17: Mapping between IPDC and CPSV-AP in mapping tool.............................................................25

Figure 18: Configuration file – Harvesting of federal data.........................................................................26

Figure 19: Filter section for citizens...........................................................................................................27

Figure 20: List of PS descriptions available for citizens..............................................................................27

Figure 21: Complete PS description of a PS from Flanders........................................................................28

Figure 22: Additional information of a Criterion.......................................................................................28

Figure 23: Technologies used for the PS descriptions’ visualisation..........................................................29

Figure 24: CPSVAPdefinittion.ttl................................................................................................................29

Figure 25: Creating a description following the Samenwerkende Catalogi format...................................35

Figure 26: Interface to export the stored descriptions..............................................................................35

Figure 27 - Export of descriptions in Samenwerkende Catalogi format....................................................35

Figure 28: Error result from testing the Trentino data sample..................................................................38

Figure 29: Error results of the validator in Italian......................................................................................39

Figure 30: Main interface of CPSV-AP-IT Validator....................................................................................40

Figure 31: Maltese mapping in the mapping tool......................................................................................43

05/05/23 Page v


1. INTRODUCTION

1.1. Context

This report has been prepared in the context of Action 1.3 – Catalogue of Services1 of the European Commission’s Interoperability Solutions for European Public Administrations (ISA) programme2.

Under specific contract (SC) 57, we identified and analysed the tools that are used by the Points of Single Contact (PSCs) of 10 Member States (Austria, Estonia, Finland, Latvia, Lithuania, Greece, Poland, Spain, Sweden and the Netherlands) and by the Your Europe Portal in order to create, harvest, publish, export and harmonise public service descriptions.

PSCs, similar to other public service catalogues, have common needs and perform similar operations, i.e. create public service descriptions, publishing the descriptions, etc. Hence, in the course of harmonising the provision of information about public services, both falling in the scope of the Service Directive and beyond, the European Commission plans to develop reusable tools in close collaboration with interested Member States.

In that context, functional and technical specifications for four tools have been described in the deliverable “D03.02 - Definition of the functional and technical requirements for the reusable solutions to be developed” of SC57. Test-implementations of the tools have been developed under the deliverable “D05.01 - Test implementations of the tools” of the SC270, implementing a subset of the functional requirements.

These test implementations form the basis for running some pilots with MSs in order to show the benefits of using interoperable tools to manage public service descriptions and the usage of technology to facilitate the harmonisation of descriptions.

The complete development of these tools will facilitate harmonisation across Europe, allow the interoperable exchange of public service information across borders and will lower the costs of implementing and managing PSCs.

1.2. Scope and objective

The scope of this document is to pilot the test-implementations developed under “D05.01 - Test implementations of the tools” of SC270, with those Member States that have shown interest on participating in the pilots. Therefore, the following points were set out as the objective for this work:

Overall coordination of the support to the MS for the use of the test-implementations of the tools for the development of some piloting use cases;

Technical support to the participating MSs to facilitate the adoption of the CPSV-AP at the PSCs or any other portals sharing public service descriptions, and the mapping to the specific services offered in each MS;

Overall coordination activities with the participating MSs in the pilots; Documentation of the pilots carried out in collaboration with the participating

MSs; and

1 European Commission. Interoperability for European Public Administrations (ISA). Accessing Member State information resources at European level. http://ec.europa.eu/isa/actions/01-trusted-information-exchange/1-3action_en.htm

2 European Commission. Interoperability for European Public Administrations (ISA). http://ec.europa.eu/isa/index_en.htm

http://ec.europa.eu/isa/index_en.htm

http://ec.europa.eu/isa/actions/01-trusted-information-exchange/1-3action_en.htm

http://ec.europa.eu/isa/actions/01-trusted-information-exchange/1-3action_en.htm


Based on the results of the pilots, draw up some recommendations for future steps and improvements of the solutions to be taken in the context of this action.

1.3. Approach

The starting point of the tasks performed under this deliverable is the test-implementations developed under “D05.01 - Test implementations of the tools” of the SC270. We worked together with stakeholders from the Member States and EU Institutions that showed interest in participating in the pilots. The work in this deliverable consists of the following steps:

1. Raise awareness on the pilots’ development. We shared the work done on tools with the CPSV-AP stakeholders, i.e. the development of test-implementations of a sub-list of the functional and technical specifications of the reusable tools, and the future work on pilots. Communication was performed via email and through the CPSV-AP Revision webinars;

2. Webinar on test-implementations and pilots. We prepared a webinar to present the first version of the test-implementations on the 19th of May 2016 to the CPSV-AP stakeholders. During the webinar, different MSs representatives and EU Institutions showed interest on the test-implementations and expressed their willingness to participate in piloting the tools;

3. Open communication with those stakeholders that showed interest on piloting the test-implementations. We sent emails to every stakeholder that showed interest in the pilots in order to schedule a call to further discuss and agree on the work to be done;

4. Propose and agree the scope, objectives and success criteria for each pilot. In every call, we presented and discussed the ideas for each pilot. The goal was to agree on the scope for the pilot, success criteria…

5. Development of pilot. After having clearly defined the use case, objectives and success criteria we developed the pilots. Intermediate calls were organised to discuss interim results and receive feedback. The feedback was addressed and a final version was delivered and presented to the stakeholders; and

6. Document the work done on the pilots’, outcome and main results, conclusions and next steps. In parallel with the development of the pilots, we registered all the communications held with stakeholders. In addition, the pilots were documented in detail in this deliverable. Conclusions and next steps have also been identified and described at the end of this deliverable.

1.4. Structure of the document

This document consists of the following sections:

Section 2 to 6, contains the documentation related to each pilot. For every pilot, the following has been described in detail in a corresponding subsection:

o List of stakeholders, providing a the list of people from MS and EU Institutions that were contacted and that participated in the pilot;

o Business needs that the stakeholder pilots want to see addressed with the development of the particular pilot;


o Proposed solution describing the approach to develop the pilot and the initial solution design for the pilot;

o Success criteria explaining when the stakeholders consider the pilot as a success;

o Outcome and pilot results, i.e. the documentation about the test-implementations that were used, how they were adapted to achieve the pilot scope and a detailed description of the pilot results; and

o Communication log summarising the communication activities carried out for developing the pilot;

Section 7, Conclusions and next steps. Describing possible next steps, ideas for future work and some conclusions that can be derived from developing the pilots documented in this deliverable.


2. PILOTING A CROSS-BORDER CATALOGUE OF PUBLIC SERVICES WITH FINLAND AND ESTONIA

The goal of this pilot is to create a cross-border catalogue of public services, i.e. a catalogue of public services with various Member States, in the context of this pilot specifically for Estonia and Finland. Therefore the following main tasks needed to be executed:

Mapping of the different stakeholders’ data models to the CPSV-AP; Transformation of the public service descriptions received from both

countries to CPSV-AP, based on the mapping done; Harvesting of the CPSV-AP compliant data from both countries; and Displaying the information in a user-centric way.

These tasks, together with the communication log and steps performed to achieve the pilot goals, are further explained in the following subsections.

2.1.1. List of stakeholders

The following stakeholders were involved for setting up this pilot:

Table 1: Stakeholders list – Pilot with Estonia and Finland

Name Organisation Country/Region

Risto Hinno Ministry of Economic Affairs and Communications

Estonia

Janek Rozov Ministry of Economic Affairs and Communications

Estonia

Marko Latvanen Suomi.fi Finland

2.1.2. Business need

Citizens and businesses face different challenges both at national and European level when trying to find information about public services available in each MS:

There are different portals where to find public service descriptions, and the information is offered in different languages;

The descriptions are organised in different ways, not following a common structure; and

There is no portal that offers an overview of all the public services that are available across Europe.

In addition, public administrations have to work on solutions in order to achieve the publication of the public service descriptions, in a user-centric way, to citizens and businesses.

Estonia and Finland are an example of two countries where cross-border movement of citizens and businesses occurs often. Therefore, these countries need to exchange a big amount of information across-border, for instance, the exchange of information on public services. On this basis, they showed interest in setting up a pilot as a proof-of-concept in this context.


To help them offering information on public services from both countries to businesses and citizens, we designed a pilot to implement a user-centric portal where to offer public service descriptions from both countries, based on the harvesting of information from both sources into a common system.

Piloting the mapping and harvesting of the Finnish and Estonian public service descriptions would provide a proof-of-concept for the cross-border exchange and consolidation of public service descriptions.

This pilot, implements a decentralised approach, where the information is stored in different portals in each Member State, and exchanged with a federated portal which, after transforming the information to a common vocabulary (e.g. the CPSV-AP), collects and publish the information in a user-centric way (see Figure 1).

Figure 1: Approach to collect public service descriptions

In a nutshell, this pilot aims to proof how this approach could work technically, using the CPSV-AP as common language and the test-implementations of the mapping and harvester tools to transform, exchange and integrate the data in a user-centric way.

Additionally, DG GROW has identified this need of exchanging cross-border information and thus is working on the definition of a Single Digital Gateway (SDG). This pilot is thus an interesting proof-of-concept to see how cross-border exchange of information on public services could work in a European context, in the light of setting up the SDG.

2.1.3. Proposed solution

To face the business needs described above, two test-implementations have been piloted in order to build a cross-border catalogue of services with Estonia and Finland, i.e. the CPSV-AP Mapping Tool and the Public Service Description Harvester. In addition, a test-implementation of a user-centric web portal has been implemented to publish and present the data previously transformed and harvested.

Figure 2 illustrates the steps and tools involved to develop the pilot, together with the input received from Estonia and Finland. These different steps that were followed to implement the pilot are explained in more detail in section 2.1.5.


Figure 2: Proposed solution for the cross-border pilot

The proposed solution aims to gather the information spread in the different sources, such as the Estonian website of the Ministry of Economic Affairs and Communications, where they offer their services at national level (see Figure 3), to a centralised user-centric visualisation of public service descriptions (see Figure 4), where the same Estonian public services are offered together with the Finnish ones.


Figure 3: Estonian MKM website

Figure 4: User-centric visualisation

2.1.4. Success criteria

For both Estonia and Finland, the pilots are a success if they provide a proof-of-concept for testing the technology needed for a cross-border exchange of information on public services. Another benefit would be if the pilot demonstrates and communicates the added value and usefulness of using the test-implementations. Mapping and harvesting across borders will also provide visibility on a national and European level for the initiatives.

In addition, the pilot would have been a success for Finland when the mapping highlights the places where mapping with the CPSV-AP is difficult or improvements have to be made.

2.1.5. Outcome and pilot results

Mapping with the CPSV-APThe documentation provided by both Estonia and Finland, i.e. a spreadsheet with public service descriptions, structured according respectively to the Estonian and Finnish data model, was the starting point of the pilot. In addition, an existing mapping between the Estonian data model to describe public services and the CPSV was used as input as well.

The first step was to map the structure of these spreadsheets with the CPSV-AP v2.0 specifications (version for public review3). The mappings were defined in a common template used for all the mappings done within the pilots, i.e. with Estonia, Finland, Belgium and Malta. The template follows the structure below:

Class and property to map of the source data model (Estonian or Finnish); Mapping relation column (aligned with the SKOS matching relationships4) to

indicate the type of mapping existing between the source data model (Estonian or Finnish) and the target (CPSV-AP);

Target data model (CPSV-AP) property and class to which the mapping is done; and

Questions/Comments column to gather possible existing questions and the reply from the stakeholder.

3 https://joinup.ec.europa.eu/node/152593/

4 http://www.w3.org/2004/02/skos/#mappingRelation

http://www.w3.org/2004/02/skos/#mappingRelation

https://joinup.ec.europa.eu/node/152593/


Figure 5: Example of Finnish mapping

Note that we used a spreadsheet to do the mappings because the work on this pilot was done in parallel with the development of the test-implementation of the Mapping Tool. However, the mappings were inserted in the Mapping Tool once its development was completed (see Figure 6).

Figure 6: Mapping Estonian data model with CPSV-AP in the mapping tools

The second step was to share the result of these mappings with both stakeholders. A call was held in order to solve questions and agree on the mappings done.

As results of the mappings, we observed that the Estonian and Finnish data models are not fully compliant with the CPSV-AP, as some of the mandatory classes and properties of the CPSV-AP are not mandatory for them and thus, they are not always filled in.

Transformation to machine-readable CPSV-AP descriptionsOnce the mappings were finalised and agreed upon with the stakeholders, we transformed the public service descriptions to CPSV-AP RDF for a sub-set of the received public service descriptions from Estonia and Finland. To do so, the following steps were taken:

1. Select a sub-set of public service descriptions from both countries;2. Copy the descriptions from the files received to the CPSV-AP spreadsheet

template;3. Include additional information needed in order to properly visualise the PS

descriptions, such as URIs to link between CPSV-AP classes, group the PS descriptions into Business or Life Events, etc.; and


4. Transform the data from XLS to RDF using Google Refine, applying an RDF Skeleton.

HarvestingOnce the data was transformed, it was uploaded in simulated Estonian and Finnish sources. To do so, we created a folder per MS in an Apache server, where we placed the RDF CPSV-AP public service descriptions. Then, we configured the harvester with:

The URL of the SPARQL endpoint; The URL of the graph where to store the data; The URLs of both Apache folders; The format of the machine-readable files (RDF/XML, RDF Turtle, N-Triples or

JSON); and An extra parameter that we added to the original configuration of the test-

implementation of the Public Service Description Harvester: the origin of the information (Estonia or Finland). This is needed for the later visualisation of information.

Figure 7: Configuration file – Harvesting of Estonian and Finnish data

Once the harvester was configured, the data was harvested and stored in a common triple store.

Visualisation Finally, we developed a website to visualise the harvested data in a user-centric way. This provides a proof-of-concept for the Single Digital Gateway and the harmonisation of information based on the CPSV-AP as common vocabulary.

It consists of three HTML pages, i.e. index, citizen and business. The index gives the user the opportunity to choose whether he is a citizen or a business. Afterwards, the information visualised will be aligned to this decision.

Both, citizen and business pages, are structured in the same way:

First, a filtering section (see Figure 8); Second, a list of the available public service descriptions from both

countries, i.e. Estonia and Finland (see Figure 9). It shows:o The origin of the public service description;o The title and description of each PS; ando A button to visualise the complete description of the PS; and

Finally, a section where to get the complete description of each public service selected (see Figure 10).


Figure 8: Filter section for citizens

Figure 9: List of PS descriptions available for citizens

Figure 10: Complete PS description of a PS from Estonia and a PS from Finland

In addition, the user can have further information of those properties of the public service that are linked to CPSV-AP classes by clicking on the property (e.g. the service provider). When selected, a pop-up is shown with the additional information of that class (see Figure 11).


Figure 11: Additional information of a Service Provider

Finally, the filtering works the following way:

The user can select the life or business event that fits better to his needs (or show all descriptions regardless of the event by selecting “All”); and

The user can select the sector that matches with his needs.Once clicking “Filter”, the list of public service descriptions available will be updated with those services that match the criteria selected. These are the PS descriptions that are grouped by the selected event, together with those PS descriptions that are either categorised under the selected sector, or that do not have information about the sector.

The website was implemented combining different technologies (see Figure 12):

HTML, CSS and Javascript for the user interface; Python for the extraction of information from the triple store where it was

previously harvested; and AJAX and PHP to communicate between Javascript and Python.

Figure 12: Technologies used for the cross-border PS descriptions’ visualisation

The website has been developed in order to be as reusable as possible, aiming to be reused by the Belgian pilot described in section 3.

In addition, we created an RDF Turtle file (CPSVAPdefinition.ttl) used to facilitate a user-friendly visualisation of the CPSV-AP structure. This file consists of different triples created to facilitate the transformation of machine-readable information to human-readable and user-friendly format (see Figure 13). On this purpose, the file contains two types of triples:

Triples to establish the text to be used on the user-interface for each CPSV-AP class and property. It is indicated as:


<Class/Property URI> <http://cpsvapfield> "User-oriented label".

Triples to indicate which property of those classes that are related with a public service will be shown when giving information of a specific public service. For instance, if a public service is related to a Formal Framework, when visualising the description of that public service, the property “Name” of the Formal Framework related will be shown:<Class URI> <http://cpsvapshow> <URI of the property to show>.

Figure 13: CPSVAPdefinittion.ttl

In addition, a Python script was created for the storage of these additional triples that support a better user-oriented visualisation. It only needs to be executed once when the graph on the triple store is created/modified, or when one of the visualisation triples has been modified. The script uses the configuration file of the harvester to know the URL of the SPARQL endpoint and the graph where the descriptions will be harvested.

The resulted website is allocated in an Amazon server and is publicly accessible: http://cpsv-ap.semic.eu/cpsv-ap_harvester_xBorder_pilot/index.html

In addition, the code of the website is shared on GitHub: https://github.com/catalogue-of-services-isa/cpsv-ap_harvester_xborderPilot

2.1.6. Communication Log

We had meetings with representatives from each MS to discuss the pilot objectives, know when the pilot would be successful for them and agree on the next steps. Therefore, we held the meetings and exchanged the emails listed in Table 2 (Estonia) and Table 3 (Finland).

https://github.com/catalogue-of-services-isa/cpsv-ap_harvester_xborderPilot

http://cpsv-ap.semic.eu/cpsv-ap_harvester_xBorder_pilot/index.html


In addition, the emails exchanged were tracked in JIRA tickets:

Estonia - https://webgate.ec.europa.eu/CITnet/jira/browse/COS-8 Finland - https://webgate.ec.europa.eu/CITnet/jira/browse/COS-5

Table 2: Communication log with Estonia – Cross-border pilot

Date Type Details

02/03/2016 Email Reply from Risto Hinno showing interest in participating in the pilot and presenting himself as the point of contact for this matter.

15/06/2016 Call Conference call with Risto Hinno to introduce him about the pilots, ask for the input needed and agree on future steps.

17/06/2016 Email Email from PwC to Risto Hinno sharing a summary and action points of the first call concerning the pilots.

21/09/2016 Email Email from PwC to Risto Hinno informing about the work done regarding the pilot, i.e. the mapping between the FSR and CPSV-AP, and proposing to schedule a meeting to comment and agree on the mapping done.

26/09/2016 Call Conference call with Risto Hinno to solve some questions about the mapping done in order to finalise the mapping between the Estonian data model and the CPSV-AP.

27/09/2016 Email Email from PwC to Risto Hinno asking for public service descriptions that could be aligned with the ones received from Finland in order to show their equivalence in the cross-border catalogue pilot.

Table 3: Communication log with Finland – Cross-border pilot

Date Type Details

11/04/2016 Email Email from ISA to Marko Latvanen to inform him about the CPSV-AP webinar and give an introduction to the future work on tools.

11/04/2016 Email Reply from Marko Latvanen to ISA showing interest on participating in the tools pilots.

18/04/2016 Call Conference call with Marko Latvanen where he gave PwC a first overview of the FSR and PwC provided a short introduction about the tools designed and the future work.

18/04/2016 Email Email from Marko Latvanen to share information related to the FSR data model.

21/04/2016 Email Email from Marko Latvanen to inform that they met the Estonian service catalogue team and that a pilot could be implemented to harvest and collect public

https://webgate.ec.europa.eu/CITnet/jira/browse/COS-5



service descriptions from both countries.

21/04/2016 Email Reply from PwC to Marko Latvanen sharing the meeting minutes from the call and sharing some information related to the test-implementations of the tools.

21/04/2016 Email Email from Marko Latvanen informing how public administrations are adopting the FSR (directly or by intermediate mappings).

07/06/2016 Call Conference call with Marko Latvanen to introduce him about the pilots, ask for the input needed and agree on future steps.

08/06/2016 Email Email from PwC to Marko Latvanen sharing a summary and action points of the first call concerning the pilots.

28/09/2016 Call Conference call with Marko Latvanen to solve some questions about the mapping shared and the use of the FSR.


3. PILOTING A FEDERAL CATALOGUE OF PUBLIC SERVICES IN BELGIUM

This pilot aims to collect and offer public service descriptions at national level. Descriptions are being created and maintained in the federal level but also on a regional level, i.e. Flanders and Wallonia. The goal of this pilot is to create a decentralised (federated) catalogue of public services of public services, harvesting the public service descriptions from regional and federal catalogues and making them available through a one-stop-shop. An overview of the main tasks performed is listed below:

Mapping of the different stakeholders’ data models (Flanders & Wallonia) to the CPSV-AP;

Transformation of the public service descriptions received from both regions to CPSV-AP, based on the mapping done;

Creating CPSV-AP compliant public service descriptions for the federal level; Harvesting of the CPSV-AP compliant data from the different stakeholders; Displaying all the information in a user-centric way.

These tasks, together with the communication log and steps performed to achieve the pilot goals, are further explained in the following subsections.


The following stakeholders were involved throughout for setting up this pilot:

Table 4: Stakeholders list – Pilot with Belgium

Name Organisation Country / Region

Bart Hanssens Fedict Belgium (federal)

Katrien De Smet Agentschap Informatie Vlaanderen (AIV) Belgium (Flanders)

Thomas D’Haenens Agentschap Informatie Vlaanderen (AIV) Belgium (Flanders)

Raf Buyle Agentschap Informatie Vlaanderen (AIV) Belgium (Flanders)

Ziggy Vanlishout Agentschap Informatie Vlaanderen (AIV) Belgium (Flanders)

Edouard Vercruijsse eWBS Belgium (Wallonia)


From the federal level, Fedict is interested in the editor and harvester as a proof-of-concept for further implementation. Fedict wants to use the European example to standardise and structure their data and the CPSV-AP tools can help with this.

In addition, eWBS (who supports Wallonia and the federation Wallonia-Brussels) and Agentschap Informatie Vlaanderen (AIV) from the Flemish region are very interested


in the CPSV-AP as a common layer between the different data models to exchange and integrate data between public administrations.

eWBS, Fedict and Agentschap Informatie Vlaanderen (AIV) are interested to work together in order to create a pilot for an interfederal catalogue of services for Belgium.

By collecting data from Flanders, Wallonia and the federal level, the pilot can be an overarching project for Belgium proving interchangeability of descriptions in a user-centric visualisation (see Figure 14).

Figure 14: Harmonised information – Federal level


To accomplish the creation of an interfederal catalogue of services, we proposed to start from the results realised in the cross-border pilot with Finland and Estonia (see section 2.1.5), adapting it to the situation of Belgium and its regions. On this purpose, there was a mapping between the Flemish data model, i.e. the IPDC (interbestuurlijke producten- en dienstencatalogus) and a mapping between the Walloon data model, i.e. NOSTRA, and the CPSV-AP. These mappings have been used for creating CPSV-AP compliant descriptions of public services.

Afterwards the public services described by these Belgian regions, together with public service descriptions provided by Fedict at federal level, were harvested and stored in a central repository. The test-implementations of the CPSV-AP Mapping Tool and the Public Service Description Harvester were used for these tasks. In addition, CPSV-AP public service descriptions at federal level were created with the test implementation of the Public Service Description Editor.

Finally, we reused the test-implementation of the user-centric web portal from the cross-border pilot to publish and present the data previously transformed and harvested.

In a nutshell, Figure 15 illustrates the steps and tools involved to develop the pilot, together with the input received from eWBS, Fedict and AIV. The different steps followed to implement the solution are explained in more detail in section 3.1.5.


Figure 15: Proposed solution for the federal pilot


For all the stakeholders, the pilot is a success if it provides a proof-of-concept for testing the technology needed for the exchange of information at federal level, across regions. Further benefits are demonstrating and communicating the added value and usefulness of these implementations and the benefit of reusing European initiatives. The pilot demonstrates the possibility and utility of intra-border exchange of public service descriptions and the creation of an interfederal catalogue of services.

Other benefits include demonstrating the usefulness of the test-implementations and seeing how compatible the different data models are with each other.

An additional and important success factor is demonstrating that the CPSV-AP can be used as a common layer to exchange and integrate data between different public administrations on the federal, regional and in the future also the local level.


The documentation provided by Wallonia and Flanders was used to create a mapping between their data models and the CPSV-AP. Furthermore, Fedict provided feedback on the test-implementation of the Public Service Description Editor, together with sample public service descriptions at federal level. The summary of input received from all the stakeholders is listed below:

Documentation on the IPDC and NOSTRA data models; Sample data of public service descriptions at regional level following the

IPDC and NOSTRA; and Sample public service descriptions at federal level from Fedict, created using

the test-implementation of the Public Service Description Editor.Using the above-mentioned documentation and in line with the work done for the cross-border pilot (see section 2) for setting up a federated catalogue of public services, the following work was carried out for the pilot:


Mapping with the CPSV-APThe documentation on data models and schemas provided by Flanders, Wallonia and Fedict was the starting point of the pilot.

The first step was to map the structure of these data models with the CPSV-AP v2.0 specifications (version for public review5). The mappings were defined in a common template used for all the mappings done within the pilots, i.e. with Estonia, Finland, Belgium and Malta. The template follows the structure below:

Class and property to map of the source data model (IPDC or NOSTRA); Mapping relation column (aligned with the SKOS matching relationships6) to

indicate the type of mapping existing between the source data model (IPDC or NOSTRA) and the target (CPSV-AP);

Target data model (CPSV-AP) property and class to which the mapping is done; and

Questions/Comments column to gather possible existing questions and the reply from the stakeholder.

Figure 16: Example of Flemish mapping

Note that we used a spreadsheet to do the mappings because the work on this pilot was done in parallel with the development of the test-implementation of the Mapping Tool. However, the mappings were inserted in the Mapping Tool once its development was completed.

5 https://joinup.ec.europa.eu/node/152593/



https://joinup.ec.europa.eu/node/152593/


Figure 17: Mapping between IPDC and CPSV-AP in mapping tool

The second step was to share the result of these mappings with the stakeholders. A call with Wallonia and an on-site meeting with Flanders were held in order to solve questions and agree on the mappings done.

As a result from the mappings, we observed that the data models are, to a large extent compatible with the CPSV-AP.

Transformation to machine-readable CPSV-AP descriptionsOnce the mappings were finalised and agreed upon, we transformed the public service descriptions to CPSV-AP RDF for a sub-set of the received public service descriptions from Flanders, Wallonia and Fedict. To do so, the following steps were taken:

1. Select a sub-set of public service descriptions from both countries;2. Copy the descriptions from the files received, to the CPSV-AP spreadsheet

template;3. Apply some editing when needed. For instance, Flanders provided the

different keywords or sectors separated by a comma, whereas for the CPSV-AP spreadsheet, each word is inserted in a different row;

4. Include additional information needed in order to properly visualise the PS descriptions, such as URIs to link between CPSV-AP classes, group the PS descriptions into Business or Life Events, etc.; and

5. Transform the data from XLS to RDF using Google Refine, applying an RDF Skeleton.

HarvestingOnce the data was transformed, it was allocated in simulated sources. To do so, we created a folder per stakeholder in an Apache server, where we placed the RDF CPSV-AP public service descriptions. Then, we configured the harvester with:

The URL of the SPARQL endpoint; The URL of the graph where to store the data; The URLs of both Apache folders; The format of the machine-readable files (RDF/XML, RDF Turtle, N-Triples or

JSON); and An extra parameter that we added to the original configuration of the test-

implementation of the Public Service Description Harvester: the origin of the information (Flanders, Wallonia or Fedict). This is needed for the later visualisation of information.


Figure 18: Configuration file – Harvesting of federal data

Once the harvester was configured, the data was harvested and stored in a common triple store.

VisualisationFinally, we developed a website to visualise the harvested data in a user-centric way. We reused the website developed for the cross-border pilot, but adapted it to situation in Belgium. This provides a proof-of-concept for the harmonisation of information based on the CPSV-AP as common vocabulary.

It consists of three HTML pages, i.e. index, citizen and business. The index gives the user the opportunity to choose whether he is a citizen or a business. Afterwards, the information visualised will be aligned to this decision.

Both, citizen and business pages, are structured in the same way:

First, a filtering section (see Figure 19); Second, a list of the available public service descriptions from each source

(see Figure 20). It shows:o The origin of the public service description;o The title and description of each PS; ando A button to visualise the complete description of the PS; and

Finally, a section where to get the complete description of each public service selected (see Figure 21).

D06.01 - Report on the support activities to the MS, main results and conclusions based on the practical results from the pilotsFigure 19: Filter section for citizens

Figure 20: List of PS descriptions available for citizens

Figure 21: Complete PS description of a PS from Flanders

In addition, the user can have further information of those properties of the public service that are linked to CPSV-AP classes by clicking on the property (e.g. the criterion property). When selected, a pop-up will be showed with the additional information of that class (see Figure 22).

Figure 22: Additional information of a Criterion

Finally, the filtering works the following way:


The user can select the life or business event that fits better to his needs (or show all descriptions regardless of the event by selecting “All”); and

The user can select the sector that matches with his needs.Once clicking “Filter”, the list of public service descriptions available will be updated with those services that match the criteria selected, i.e. the PS descriptions that are grouped by the selected event, and those PS descriptions that are either categorised under the selected sector, or that do not have information about the sector.

The website was implemented combining different technologies (see Figure 23):

HTML, CSS and Javascript for the user interface; Python for the extraction of information from the triple store where it was

previously harvested; and AJAX and PHP to communicate between Javascript and Python.

Figure 23: Technologies used for the PS descriptions’ visualisation

The website has been developed in order to be as reusable as possible, aiming to be reused by the cross-border and federal pilots described.

In addition, we created an RDF Turtle file (CPSVAPdefinition.ttl) used to facilitate a user-friendly visualisation of the CPSV-AP structure. This file consists of different triples created to facilitate the transformation of machine-readable information to human-readable and user-friendly format (see Figure 24). On this purpose, the file contains two types of triples:

Triples to stablish the text to be used on the user-interface for each CPSV-AP class and property. It is indicated as:<Class/Property URI> <http://cpsvapfield> "User-oriented label".

Triples to indicate which property of those classes that are related with a Public Service will be shown when giving information of a specific public service. For instance, if a public service is related to a Formal Framework, when visualising the description of that public service, the property “Name” of the Formal Framework related will be shown:<Class URI> <http://cpsvapshow> <URI of the property to show>.


Figure 24: CPSVAPdefinittion.ttl

In addition, a Python script was created for the storage of these additional triples that support a better user-oriented visualisation. It only needs to be executed once when the graph on the triple store is created/modified, or when one of the visualisation triples have been modified. The script uses the configuration file of the harvester to know the URL of the SPARQL endpoint and the graph where the descriptions will be harvested.

The resulted website is allocated in an Amazon server and is publicly accessible: http://cpsv-ap.semic.eu/cpsv-ap_harvester_federal_pilot/index.html

In addition, the code developed for the website is shared on GitHub: https://github.com/catalogue-of-services-isa/cpsv-ap_harvester_federalPilot


We had meetings with representatives from each region to align about the pilot objectives, know when the pilot would be successful and agree on the next steps. Therefore, we held the meetings and exchanged the emails listed in (Flanders) and (Wallonia).

In addition, the emails exchanged were tracked in JIRA tickets:

Federal - https://webgate.ec.europa.eu/CITnet/jira/browse/COS-20 Flanders - https://webgate.ec.europa.eu/CITnet/jira/browse/COS-18 Wallonia- https://webgate.ec.europa.eu/CITnet/jira/browse/COS-23

Table 5: Communication log Federal – Federal pilot

Date Type Details

03/06/2016 Email Email from PwC to Bart Hanssens informing about the possibility of piloting some of the CPSV-AP tools in a




https://github.com/catalogue-of-services-isa/cpsv-ap_harvester_federalPilot

http://cpsv-ap.semic.eu/cpsv-ap_harvester_federal_pilot/index.html


federal pilot.

14/06/2016 Call Call with Bart Hanssens to introduce him about the pilots, ask for input and agree on possible future steps

15/06/2016 Email Email from PwC to Bart Hanssens with the meeting minutes from the call held.

15/07/2016 Email Email from PwC to Bart Hanssens updating him about the communication with the other stakeholders (AIV and eWBS) and the agreement on the pilot proposed.

26/08/2016 Email Email from PwC to Bart Hanssens providing him with the user account details to access and use the test-implementation of the Public Service Description Editor.

29/09/2016 Email Reply from Bart Hanssens giving feedback about the test-implementation of the editor.

30/09/2016 Email Reply to Bart Hanssens to discuss his feedback and set up a call for further discussion.

04/10/2016 Email Email from Bar Hanssens with further feedback and suggestions.

04/10/2016 Call Call with Bart Hanssens to discuss his feedback, remarks and suggestions.

04/10/2016 Email Email from PwC to Bart Hanssens with a summary of the discussion of the call.

14/10/2016 Email Email from Bart Hanssens requesting machine-readable metadata of the CPSV-AP (URIs of the classes and properties, namespaces…).

18/10/2016 Email Email from PwC to Bart Hanssens to give an update on the request for machine-readable metadata of the CPSV-AP

26/10/2016 Email Email from Bart Hanssens providing feedback on the export functionality of the editor test-implementation.

27/10/2016 Email Email from Bart Hanssens providing additional feedback and test results for the export functionality

Table 6: Communication log with Flanders – Federal pilot

Date Type Details

06/06/2016 Email Email from Thomas D’Haenens expressing the interest of Flanders to participate in the planned pilots

08/06/2016 Email Email from PwC to Thomas D’Haenens setting up a meeting to discuss further collaboration in the


pilots

05/07/2016 Meeting Meeting with the Flemish stakeholders to introduce them about the pilots, ask for input and agree on possible future steps

05/07/2016 Email Email from PwC to AIV to share the meeting minutes and next steps of the first meeting on pilots held.

12/07/2016 Email Email from Katrien De Smet sharing public service descriptions and explanation on how they extracted them.

25/08/2016 Email Email from PwC to AIV to share the meeting minutes and next steps of the call held.

05/09/2016 Meeting Meeting with Raf Buyle, Geraldine Nolf, Geert Thijs and Thomas D’Haenens to discuss OSLO and possible alignment with the CPSV-AP.

08/09/2016 Meeting Meeting with Raf Buyle, Thomas D’Haenens, Katrien De Smet, Siegfried Vanlishout and Geraldine Nolf to discuss the mapping done between the IPDC and the CPSV-AP

13/09/2016 Email Email from PwC to the Flemish stakeholders with the new version of the mapping based on the last meeting

Table 7: Communication log with Wallonia – Federal pilot

Date Type Details

22/06/2016 Email Email from PwC to Edouard Vercruysse informing him about the pilots and inquiring about possible collaboration

14/07/2016 Call Call with Edouard Vercruysse informing about the pilots and discuss possible next steps.

15/07/2016 Email Email from PwC to Edouard Vercruysse with the meeting minutes and next steps agreed on during the meeting held.

05/08/2016 Email Email from Edouard Vercruysse sharing documentation about NOSTRA.

29/09/2016 Email Email from PwC to Edouard setting up a call to discuss the mapping between the CPSV-AP and NOSTRA

12/10/2016 Call Call with Edouard Vercruysse to discuss the mapping between NOSTRA and CPSV-AP done by PwC

27/10/2016 Email Email from PwC to Edouard Vercruysse sharing the new version of the mapping, considering the


feedback received during the call.

07/11/2016 Email Email from PwC to Edouard Vercruysse to request descriptions of public services following NOSTRA to use it in the pilot.


4. TAILORING THE PUBLIC SERVICE DESCRIPTION EDITOR TO THE DUTCH NATIONAL DATA MODEL FOR DESCRIBING PUBLIC SERVICES (SAMENWERKENDE CATALOGI)

The goal of this pilot is to prove that the Public Service Description Editor can be easily adapted and reused for other data models. In this pilot we have adapted the CPSV-AP Public Service Description Editor to the Dutch data model (Samenwerkende Catalogi format7) with a customized export functionality.


Table 8: Stakeholders list – Pilot with Netherlands


Marco Aarts ICTU The Netherlands


The Netherlands want to have an easy way to create public service descriptions that follow the Samenwerkende Catalogi. The descriptions will be created by the municipalities and government organisations. They are looking into the possibility of adapting the Public Service Description Editor to their own data model and make them available as a service to the municipalities.


The business needs of the Netherlands can be fulfilled by adapting the CPSV-AP Public Service Description Editor to the Samenwerkende Catalogi. Furthermore the translation of the labels and instructions to Dutch will improve the user experience for Dutch users.

The adapted editor will provide all the functionality of the original CPSV-AP Public Service Description Editor like creating, editing and exporting descriptions. The export will be able in the CPSV-AP format as well as the Samenwerkende Catalogi XML format.


The pilot will be a success if the adaptation of the editor is a successful proof-of-concept from which a production-ready application can be developed with minimal effort or further adaptations. Furthermore, the Netherlands demonstrate active involvement with the programme by reusing results from the ISA programme. The pilot also demonstrates alignment on the European level.


The documentation provided by ICTU and used to determine the modifications needed to be done to adapt the CPSV-AP Public Service Description Editor to the Samenwerkende Catalogi was the following:

Documentation on the Samenwerkende Catalogi format;

7 https://www.logius.nl/diensten/samenwerkende-catalogi/

https://www.logius.nl/diensten/samenwerkende-catalogi/


Sample data of public service descriptions following the Samenwerkende Catalogi format; and

A validator to check the correctness of the develop XML export.Using the above-mentioned documentation the following work was carried out for the pilot:

Research the Samenwerkende Catalogi specification; Determine which elements of the CPSV-AP Public Service Description Editor

can be reused; Determine which elements are missing and which elements need to be

removed from the editor; Creation and configuration of separate Drupal instance of the CPSV-AP Public

Service Description Editor on PwC’s virtuoso universal server to host and serve the web application and store the data in its triplestore;

Removal of non-relevant elements and creation of new additional fields needed to cover the entire data model;

Translation of the labels and menu’s in Dutch;

Figure 25: Creating a description following the Samenwerkende Catalogi format

Create a custom XML export that can export the descriptions in the Samenwerkende Catalogi format and integrate it in the tool (see Figure 26 and Figure 27);

Discussion with ICTU on results and modifications to the tool based on their feedback.


Figure 26: Interface to export the stored descriptions

Figure 27 - Export of descriptions in Samenwerkende Catalogi format


We had meetings with the stakeholders to align about the pilot objectives, know when the pilot would be successful and agree on the next steps. All the emails exchanged were tracked in a JIRA ticket:

https://webgate.ec.europa.eu/CITnet/jira/browse/COS-11 Table 9: Summary of communications

Date Type Details

3/06/2016 Email Email from PwC to Marco Aarts (ICTU), to inquire about the expressed interest during the webinar and possibility to set up a meeting to discuss scope, objectives and use cases.

15/06/2016 Call Call to gather information on the Samenwerkende Catalogi and discuss possible collaboration with ICTU to pilot the CPSV-AP public service description editor

26/08/2016 Email Email from PwC to Marco Aarts (ICTU), to report on the



progress and set up a meeting to discuss the adapted version of the Public Service Description Editor.

05/09/2016 Call Call to gather feedback and first impressions of the adapted version of the Public Service Description Editor. Further steps on testing are discussed and agreed.

14/09/2016 Email Email from PwC to Marco Aarts (ICTU) with login details of a test account for the adapted version of the Public Service Description Editor.


5. ADAPTING THE CPSV-AP VALIDATOR FOR CPSV-AP_IT IN ITALY

The goal of this pilot is to tailor the test-implementation of the CPSV-AP Validator accordingly, in order to validate sample public service descriptions of Italy. This involves modifying the rules of the validator according to the Italian specification, namely CPSV-AP_IT. The validation will show if there is a gap on the process of creating these descriptions.


The following stakeholders were involved throughout for setting up this pilot:

Table 10: List of stakeholders – Validator pilot


Marco Combetto Region of Trentino Italy

Giorgia Lodi AgID Italy

Antonio Rotundo AgID Italy


AgID is working on the creation of a catalogue of public services at national level. With that purpose, they are collecting the descriptions from different sources. It is common that the public service descriptions that they receive are not compliant with the national data model, i.e. the CPSV-AP_IT8. Thus, they have to either ask for legitimate descriptions or update them on their side, increasing the effort and time needed to gather all the descriptions. By tailoring the test-implementation of the CPSV-AP Data Validator, AgID can test the legitimacy of the acquired public service descriptions and give the necessary feedback to the provider.

In addition, the Italian province of Trentino was interested in the validator with the main goal to use it to check the compliance of their data with the CPSV-AP_IT, i.e. to ensure its compliance with the data models used at national and European levels. In this vain, Trentino wants to improve standardisation and structuring of their public service descriptions. On this purpose, they are looking at the European solutions on how to do this. By reusing the tools and applications that are realised by ISA Action 1.3 they can achieve cost-savings and compatibility benefits. For this purpose, Trentino also provided data for the piloting of the test-implementation.


The pilot adapted the test-implementation of the CPSV-AP Data Validator to the Italian data model, i.e. the CSPV-AP_IT. Labels and error messages have been translated to Italian, as AgID wants to either offer it directly as part of their catalogue, or providing an external link to the validator. AgID tends to offer the validator as an additional service on their portal.


On the one hand, the pilot will be a success for AgID when public administrations can make use of it while learning from the mistakes and improving the descriptions.

8 CPSV-AP-IT : http://www.dati.gov.it/onto/CPSV-AP_IT.owl

http://www.dati.gov.it/onto/CPSV-AP_IT.owl


On the other hand, Trentino sees the pilot as successful when it can check the compliance of its data with the CPSV-AP_IT and highlight the areas that need improvement.


The documentation provided by AgID and used to determine the modifications needed to be done to tailor the CPSV-AP validator to the Italian model was the following:

UML Diagram of the Italian version of CPSV-AP; OWL ontology description of the Italian version of CPSV-AP; Sample data displaying the Italian data model in use; and Public service descriptions from Trentino to test the validation process.

Figure 28: Error result from testing the Trentino data sample

Using the above documentation the following work was carried out for the pilot:

Research into the Italian version of CPSV-AP to:o Determine addition, modification and use of elements compared to

the original CPSV-AP model;o Determine type and function of rules required for the proper

validation of the model. Creation and configuration of separate instance of the CPSV-AP validator tool

on PwC’s virtuoso universal server to host and serve the web application and store the data in its triplestore;

Creation of the 196 custom rules to validate the Italian CPSV-AP model; Translation of the validation error messages to Italian;


Figure 29: Error results of the validator in Italian

Modification of the application’s appearance to suit the Italian version and separate it from the original;

Testing of the rules on two different data samples; Discussion with AgID on results and modifications to the tool based on their

feedback, which included:o Requests on fine tuning the rules after the first version of the Italian

validator was finished;o Requests to update some of the rules according to a new version of

the Italian CPSV-AP specification, which came out after the creation of the first version of the pilot validator.


Figure 30: Main interface of CPSV-AP-IT Validator

After discussion with AgID the consensus is that the pilot has fulfilled its intended goals in full and is predicted to be very useful.

Next steps that could be taken for further development of the tool include:

Adding the functionality to switch language for the whole interface of the tool between English and Italian;

Add rules to support the validation of geospatial data, for example in the case of the locn:Geometry class.


The table below summarises all communications carried out for the pilot, which have been logged in detail at a JIRA Ticket:


Table 11: Summary of communications

Date Type Details

11/2/2016 Email Email from PwC to AgID, to express interest in collaborating with AgID to pilot the tools being developed for CPSV-AP.

25/2/2016 Call Call to gather information on CPSV-AP-IT and discuss possible collaboration with AgID to pilot the CPSV-AP



validator.

23/3/2016 Email Email to exchange information on development of each parties individual projects.

17/8/2016 Email Email, from PwC to AgID, to give an update on the development of the pilot of the validator for the Italian model and propose to schedule a call.

19/9/2016 Call Call to demonstrate the close to final version of the pilot of the validator for the Italian model and to discuss how to address a number of issues.


6. MAPPING NATIONAL AND REGIONAL DATA MODELS TO THE CPSV-AP

In this pilot we have used the CPSV-AP mapping tool to map data models from Member States to the CPSV-AP. In particular Malta asked for such a mapping in order to see the compliance of their data model with CPSV-AP 2.0 and to find areas for improvement.


The following stakeholders were involved for setting up this pilot:

Table 12: List of stakeholders – Mapping pilot

Name Organisation Country

Joseph Azzopardi Information Technology Agency

Malta

In addition, we used the test-implementation of the CPSV-AP Mapping Tool to map the national and regional data models from Finland and Estonia (see section 2.1.1) and Belgium (see section 3.1.1).


Malta wants to maximally align the description of their pubic services with European standards. As Malta has been an active member of the CPSV-AP Working Group, they wanted to map the data model currently being used for describing public services with CPSV-AP 2.0. The goal was to check the level of alignment with the CPSV-AP and to identify potential areas of improvement. They wanted to make their data compliant but also keep their own independence for extending the model.


To map the Maltese data model with the CPSV-AP, we proposed to use the test-implementation of the CPSV-AP Mapping Tool. This will help testing the development of the test-implementation and identify the compliance and gaps between the data models and the CPSV-AP.


The pilot will be a success when Malta gets the feedback and results on the compliancy between their data models with the CPSV-AP, and highlights of those areas that need attention.


In order to do the mapping, we have received the following documentation:

Documentation about their data model; and Sample data of public service described according to their data models.

As for the other pilots, the mapping has first been defined in a common template. The template follows the structure described below:


Class and property to map of the source data model (Estonian or Finnish); Mapping relation column (aligned with the SKOS matching relationships9) to

indicate the type of mapping existing between the source data model (Estonian or Finnish) and the target (CPSV-AP);

Target data model (CPSV-AP) property and class to which the mapping is done; andQuestions/Comments column to gather possible existing questions and the reply from the stakeholder.

Note that we used a spreadsheet to do the mapping because the work on this pilot was done in parallel with the development of the test-implementation of the Mapping Tool. However, the mapping were inserted in the Mapping Tool once its development was completed (Figure 31).

Figure 31: Maltese mapping in the mapping tool

The second step was to share the result of these mappings with both stakeholders. A call was held in order to solve questions and agree on the mappings done.

The outcome of the pilot is the mapping using the SKOS matching relationships10.

The latest version of the mapping can be found on the test-implementation of the CPSV-AP Mapping Tool:

http://cpsv-ap.semic.eu:8890/cpsv-ap_mapping/


We had meetings with the stakeholders to align about the pilot objectives, know when the pilot would be successful and agree on the next steps. All the emails exchanged were tracked in JIRA tickets:

Malta: https://webgate.ec.europa.eu/CITnet/jira/browse/COS-21Table 13: Summary of communications – Malta

Date Type Details9 http://www.w3.org/2004/02/skos/#mappingRelation



http://cpsv-ap.semic.eu:8890/cpsv-ap_mapping/




15/06/2016 Call Conference call with Joseph Azzopardi to introduce him about the pilots, ask for the input needed and agree on future steps.

15/06/2016 Email Email from Joseph Azzopardi providing PwC with the input needed.

17/06/2016 Email Email from PwC to Joseph Azzopardi with the meeting minutes from the call.


7. CONCLUSIONS AND NEXT STEPS

The pilots’ outcomes are very successful and recognised by the stakeholders. Each pilot proofs that the MSs that participated are interested in working together to harmonise the information in order to facilitate the provision of public service descriptions to citizens and businesses.

Pilots set as a proof-of-concept that working with the CPSV-AP as common vocabulary helps facing the existing challenges, such as information spread, not harmonised, etc. to better reach users of the PSCs and other platforms.

In addition, the outcome of the pilots might help DG GROW with the definition of the Single Digital Gateway. The pilots are a proof-of-concept of the benefits of using the CPSV-AP specifications as basis of the descriptions exchange between MSs, which could help DG GROW with the realisation of the SDG.

Finally, the pilots have successfully tested the test-implementations and their reusability. From doing the pilots some improvements to the test-implementations were identified, of which some of them have been applied immediately, where others have been logged as next steps and opportunities for the future.

The following next steps have been identified for the continuation of this work:

Enlarge the cross-border pilot collecting public service descriptions from additional Member States;

Continue mapping different data models used to describe public services with the CPSV-AP in order to help them realise the existing level of compliance;

Adapt the test-implementations to the needs of other MSs or EU Institutions, similar to the validator or editor pilot;

Work on new pilots by engaging more stakeholders and considering their needs. Potential pilot candidates already identified are Latvia, Greece and Germany;

Maintain and further improve the running pilots; Present the results from the pilots to different stakeholders;


ANNEX I. MODULES USED BY THE PUBLIC SERVICE DESCRIPTION EDITOR

Chaos tools suite: set of APIs and tools to improve the developer experience. It is a perquisite for a plethora of modules. It contains:

o Chaos tool;o Custom content panes;o Views content panes;o Page manager.

Data: Data module provides Views integration for displaying table data and Drupal search integration for searching table content.

o Data entity: adds a simple API to add data to any entity;o Data search: enables the search of table content.

Database: Database API provides a standard, vendor-agnostic abstraction layer for accessing database servers.

o Schema: the Schema API allows modules to declare their database tables in a structured array (similar to the Form API) and provides API functions for creating, dropping, and changing tables, columns, keys, and indexes.

Entity Connecto Entityconnect: The Drupal module will allow you to dynamically

create and edit entities which should be referenced into an Entity reference field.

Featureso Features: enables the capture and management of features in

Drupal. Fields

o Countries: adds a countries field, a countries database, way to alter Drupal’s core country list;

o Entity Reference: Provides a field type that can reference arbitrary entities;

o Multiple Selects: Rather than having a multi-select field, this modules allows you to have multiple select fields with the traditional FieldAPI 'Add another item' button;

o Reference Dialog: his module extends reference fields like the user and node reference fields by adding links to add, edit and search for references through a dialog;

o Select (or other): Provides a new Forms API element which is a select/radios/checkboxes element that has an 'other' option.

OAutho OAuth: This module implements the OAuth 1.0 standard for use with

Drupal and acts as a support module for other modules that wish to use OAuth.

RDFo RDF Indexer: RDF indexer uses the Search API module to manage

and perform indexing of the RDF data for entities present on your site;

http://drupal.org/project/views


o RDF Indexer for Virtuoso Open Source: Indexes the RDF data for entities present on the site for Virtuoso;

o RDF UI: The module enables you to specify mappings between content types and fields with types and properties of Schema.org and build Content types based on schema.org;

o RDFx (RDF Extensions): The RDF Extensions module will add several additional features on top of the core RDF module;

o SPARQL API: This is a module that enables the use of SPARQL queries with the RDF API;

o SPARQL Endpoint: provides the SPARQL endpoint;o SPARQL Endpoints Registry: ships with the SPARQL Endpoint

module. Rules

o Rules: The Rules module allows site administrators to define conditionally executed actions based on occurring events

o Rules scheduler: allows Rules to be scheduled;o Rules UI: provides a simple UI for easy configuration and scheduling

of rules. SCF

o ARC2Store: Used by the RDF indexer as a temporary triple store. Search

o Search API: This module provides a framework for easily creating searches on any entity known to Drupal, using any kind of search engine;

o Search facets: This module provides integration with the popular Facet API module to allow faceting on any search executed with the Search API;

o Search views: This module integrates the Search API with the Views module, allowing searches on any index to be created and viewed via Views.

Search toolkito Facet API: The Facet API module allows site builders to easily create

and manage faceted search interfaces;o Facet API Pretty Paths: Enables pretty paths for searches

with Facet API;o Facet API Collapsible Links: Provides a Facet API widget plugin for

collapsible facets links. Services

o Services: A standardized solution for building API's so that external clients can communicate with Drupal.

Services Authenticationo Oauth authentication: Comes with the Services module, used for

authentication purposes. Services resources

o UUID Services: The integration for UUID with the Services module. User interface


o CKEditor: This module will allow Drupal to replace text area fields with the CKEditor - a visual HTML editor for rich text processing;

o Options element: Provides a better mechanism to specify select list, checkbox, and radio button options.

UUIDo Universally Unique ID: This module provides an API for adding

universally unique identifiers (UUID) to Drupal objects;o UUID Path: Rewrites some entity paths (e.g. nodes, node revisions,

users, comments) to use UUIDs instead of entity IDs. Views

o Views: Using the Views module, you can fetch content from the database of your site and present it to the user as lists;

o Views UI: The user interface module for Views. Other

o CSS injector: Allows administrators to inject CSS into the page output based on configurable rules;

o Entity API: This module extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties;

o Entity tokens: Comes with the Entity API, adds tokens for most entity properties and fields;

o Libraries: The common denominator for all Drupal modules/profiles/themes that integrate with external libraries;

o RESTful web services: Exposes Drupal resources (e.g. entities) as RESTful web services.

Documents

D06.01 - Report on the support activities to the MS, main ... Web viewReport on the support activities to the MS, main results and conclusions based on the practical results from