Keywords

1 Introduction and Motivation

The provision of public services (PS) is the main task of most public authorities and a major part of their operations in total. PS provision is usually the main task for the implementation of a governmental policy targeting the fulfillment of citizens’ needs. As PS provision is a major part of public sector operations, the opening of information on PSs, i.e. publishing structured PS descriptions, highly contributes to the realization of the Open Government vision, promoting transparency and trust between public administrations and citizens.

Every eGovernment system that provides PSs is based on an underlying PS model [15]. PS models and standards are considered as the main enablers for promoting interoperability and quality in the PS provision domain. Embracing the need for a standard PS model, the European Commission has developed the Core Public Service Vocabulary (CPSV) [9] that enables the description of public services.

The adoption of CPSV is expected to facilitate semantic interoperability of public service descriptions throughout Europe. This will be beneficial for the implementation of the Single Digital Gateway (SDG) regulation [14], since the European coordinator of the SDG has to collect the descriptions of public services from European public administrations in one unique portal. However, the use of heterogeneous technologies (e.g. SQL, RDF) to store the data produced based on CPSV-AP as well as the unfamiliarity with some of the technologies related to the CPSV-AP (e.g. RDF) may hinder the collection of such data by the SDG as well as their exploitation by added value services and tools.

Towards this problem definition, APIs can provide uniform access to data described based on CPSV-AP hiding any heterogeneity of the underlying technologies [20]. Additionally, the use of most CPSV-AP data requires skills and tooling (e.g. RDF, SPARQL) that are less widespread than some other web technologies (e.g. JSON, Javascript). For example, there are many Javascript visualization libraries that consume JSON data (e.g. D3.js, charts.js), while there are just a few that consume RDF and their functionality is limited.

In order to unleash the full potential of CPSV-AP described data there is a need to standardize the interaction (i.e. input, output and functionality) in a way that facilitates: i) the development of reusable services and tools and ii) the automatic collection of public service descriptions from different catalogues. This paper describes the requirements, use cases, design choices and implementation details of an API that aims to exploit and unify CPSV-AP data stored using heterogeneous technologies while also making data available in a structure and format that is familiar to a larger group of developers. The API offers a uniform way to access the data, thus enabling the development of generic services and tools that can be reused across datasets and even cross-boarder.

The rest of the paper is organized as follows, Sect. 2 presents relevant background and related work, Sect. 3 describes the methodology followed for the development of the API, Sect. 4 presents the use cases and requirements that need to be covered by the API, Sect. 5 describes the design decisions for the API, Sect. 6 presents the implementation details, Sect. 7 describes some exaples scenarions using the API and finally Sect. 8 concludes the paper.

2 Background Work

This section presents some background work needed to understand the context of the paper and the developed API.

2.1 The Core Public Service Vocabulary (CPSV)

The Core Public Service Vocabulary (CPSV) [9] (Fig. 1) is a data model for describing public services and the associated life and business events (e.g. “having a baby”, “starting a new business”). The two main classes of the model are the “Public Service" and the “Public Organization” that is responsible for offering the service. Except from these two classes there are many other describing other aspects of the public service including the required input to execute the service (i.e. “Evidence”), the “Output” of the service, the “Cost” of the service, the “‘Channel” through which the service is offered, the “Contact Point” of the service etc.

Based on CPSV a linked data application profile CPSV-AP was also developed. An Application Profile is a “specification that re-uses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used” [13]. For example, CPSV-AP reuses classes and the properties of existing vocabularies including FOAF [4], DCT [11] and DCAT [1] as well as other Core Vocabularies e.g. CPOV. It also proposes the use of controlled vocabularies to populate the properties e.g., for the names of countries [17] and languages [18]. The more recent version of CPSV-AP is version 3.0 and was published in 2022.

The classes and properties of CPSV-AP are categorized as mandatory or optional. The minimum requirements of a public service description, in order to comply with CPSV-AP, is to provide at least information on the mandatory properties of the mandatory classes. Optional classes can still have mandatory properties for which information should be provided when an optional class is used.

The CPSV-AP belongs to a set of Core Vocabularies that have been developed by the European Comission in order to conceptualise the public service provision domain. These vocabularies include, apart from the CPSV-AP, the Core Criterion and Core Evidence Vocabulary (CCCEV) [6], Core Person Vocabulary (CPV) [7], the Core Public Organisation Vocabulary (CPOV) [8] and the Core Business Vocabulary (CBV) [5].

Fig. 1.
figure 1

The CPSV-AP v3.0 model [9].

Full size image

Currently there are many known uses of CPSV-AP throughout Europe [12]:

  • Belgium used the CPSV-AP to harmonise public services data from different regional sources and centralise them into a common system. Additionally, the region of Flanders adopted a slightly updated version of the CPSV-AP as their regional model for describing public services.

  • The Estonian Ministry of Economic Affairs extended CPSV-AP to address local needs, as well as to cover the public service life-cycle. They also developed a service to harvest data based on their extension.

  • Finland used the CPSV-AP to create a national data model for describing public services. In addition, they ran a pilot with Estonia for which they used the CPSV-AP and tools to create a cross-border catalogue of public services.

  • The Region of Epirus in Greece used the CPSV-AP to model a subset of their public services catalogue and used the suggested procedure to turn them into linked data.

  • Ireland used CPSV-AP to create a national data model tailored to their needs for describing public services.

  • The Agency of Digitisation in Italy created a national data model that extends CPSV-AP to include country-specific characteristics. They are using the model in a national catalogue of public services. Additionally, they use CPSV-AP at local level and specifically at the Autonomous Province of Trento to describe public services through a distributed Content Management System.

  • Portugal created also a national data model that adapts the CPSV-AP to include country-specific characteristics. They are implementing their model in a national catalogue of public services.

  • Slovakia is working on a national data model based on the CPSV-AP to support the mapping of the Slovakian central meta information system of public administration to the CPSV-AP.

  • Spain is working on a pilot with Portugal for which they are using the CPSV-AP to create a cross-border catalogue of public services.

  • The Netherlands reused certain CPSV-AP tools to develop a simple way of creating public service descriptions matching the Dutch national data model.

2.2 Semantic Web and Linked Data

The term semantic web refers to an extension of the current “web of documents” in order to build a “web of linked data”. In order to achieve the vision of linked data, a set of principles have been proposed to “publish data on the web in such a way that it is machine-readable, its meaning is explicitly defined, it is linked to other external datasets, and can in turn be linked to from external datasets” [3]. Semantic Web and linked data are empowered by technologies such as RDF [10] and SPARQL [21] in order to publish data on the web.

More specifically, RDF is a W3C standard model for data interchange on the Web. It uses URIs to name things and their relationships that are expressed as “triples” <X, Y, Z> (e.g., < PublicService1, hasCompetentAuthority, Organization1>). RDF has many serialization formats such as RDF/XML [23], Turtle [22] and JSON-LD [24]. The JSON-LD is the most recently developed serialization that aims to be lightweight and easy for humans to read. It is based on the successful JSON format and is ideal for APIs. SPARQL is a language to express queries across diverse RDF data sources.

Many researchers suggest that the linked data paradigm is ideal for Public Sector Information publishing, enabling the potentiality of breaking the bureaucratic silos [16]. Towards this direction, CPSV-AP incorporates linked data as an underpinning technology. Thus, public service descriptions, that are modeled using CPSV-AP, can be published as linked data and become part of the linked data cloud.

However, linked data technologies, apart from its benefits, puts some significant challenges [25] [16] hindering the adoption of relevant vocabularies such as CPSV-AP. For example, using linked data requires skills and tooling (e.g. RDF, SPARQL) that are less widespread than some other web technologies (e.g. JSON, Javascript). Thus, there is a need to standardize the interaction (i.e. input, output and functionality) with linked data in a way that facilitates the development of reusable services and tools.

2.3 APIs for Public Service Descriptions

The Application programming interfaces (APIs) are essential enablers of the transformation towards digital governments due to their modularity, reusability and scalability [20]. The APIs are the connection nodes that standardise the interactions at digital architectures and thus foster interoperability through data transfer.

In the context of public service cataloging, EU has already identified cases [19] where either there is limited use of relevant APIs or cases where a CPSV-AP based API will be beneficial. For example a case where there is a limited use of APIs, is the Autonomous Province of Trento. They have established a common datastoreFootnote 1 of concepts (e.g. Public Services) which is used by several local authorities. The data exchanged among local authorities is shared by means of a REST API and published in JSON format. In order to map the shared data structure to other data models, such as the CPSV-AP, a mapping tool has been developed so that data is transformed from JSON to JSON-LD format.

Another case that is quite mature but there is still no relevant API is the Flemish Information Agency. They have developed a model, called OSLO-DienstencataloogFootnote 2, which extends concepts of CPSV-AP in order to uniform their public services. On top of this model they also provide a JSON-LD context that can be shared between APIs.

3 Methodology

This section presents the methodology that has been followed in order to develop an API for the provision of public service information based on CPSV-AP:

  • Define the use cases and the corresponding requirements that need to be covered by the API (Sect. 4).

  • Define the design criteria and decisions for the API (Sect. 5).

  • Implement the API (Sect. 6).

  • Apply the API at some relevant scenarios (Sect. 7).

The following sections describe in detail these steps.

4 Use Cases and Requirements

The main requirement of the API is to support Create, Read, Update, Delete (CRUD) operations on all the CPSV-AP concepts. Additionally, there is also a need for basic search functionality of public services based on some criteria that have been identified by the bibliography [15]. The main use cases that need to be supported by the API are depicted in a UML use case diagram (Fig. 2) and are the following:

  • Retrieve instances of CPSV-AP concepts (e.g. public service). The API should support retrieving either all the instances or a specific instance (e.g. based on its id). The description of the instances should include all the relevant properties defined by CPSV-AP.

  • Search for Public Services. This includes: i) searching based on the competent authority of the service, ii) searching based on the input/output of the service, iii) searching based on the event (i.e. life event or business event) related to the public service and iv) search for dependent public services (based on the properties “requires” and “related” of CPSV-AP).

  • Create a new instance of a CPSV-AP concept.

  • Update an existing instance of a CPSV-AP concept.

  • Delete an existing instance of a CPSV-AP concept.

Fig. 2.
figure 2

UML Use Case diagram of the API

Full size image

Mainly there are two actors/systems that are expected to use the API. The “data publisher" that is responsible for publishing and maintaining the public service descriptions using the API. The “data publisher” can use any storage technology e.g. RDBS or SPARQL endpoints. The “data consumer” can be any application (e.g. mobile device or browser) that retrieves or searches for public service descriptions in order to present them to the end user.

5 API Design

Based on the use cases and requirements described at Sect. 4 the main functionality of the API is to support CRUD operations on all the classes of CPSV-AP, but also support searching of public services based on specific criteria. The architectural approach that has been selected for the design of the API is the REST, since it offers many advantages including the simplicity, scalability, speed, and ability to handle all data type through simple HTTP requests. The functionality of the API, in terms of supported REST calls, is depicted at Table 1.

Table 1. Supported REST API calls
Full size table

Another functionality of the API is the support of different storage technologies in a transparent way to the end user. Specifically, the API supports both RDBS and SPARQL enpoints to retrieve relevant results that are then returned to the end user in a homogenized way. Towards this direction, a design choice that was made is to use JSON-LD as the format of the results that is capable of “blending” relational data with RDF data using also the CPSV-AP model.

6 API Implementation

The API is implemented in PHP language making use of the Symfony 6.0 web application framework that supports the Model-View-Controller architecture. In such architectures the Model component undertakes the management of the data (i.e. storage, processing and retrieval), the View component manages the presentation of information to the end user and the Controller component is the interface between Model and View components. The code of the developed API follows this approach.

Additionally, the developed API uses the api-platform 2.6 framework that facilitates the building of web APIs, the Doctrine platform that supports the abstracted use of data bases and the Composer platform for dependency management. The code of the API is available at GithubFootnote 3.

The code is organized in a way where a separate source file is created for each of the CPSV-AP classes and contains information about the way to handle each class. For example, Listing 1 presents the code that defines the URI of the relevant CPSV-AP class (i.e. Public Service) as well as the supported REST API calls, while Listing 2 presents the code that defines the supported search parameters for the Public Service class.

figure a
figure b

The returned results of the API are in JSON-LD format that extends JSON by adding linked data annotations. In this way the returned results are also compatible with CPSV-AP.

The API supports the connection both to relational databases and RDF SPARQL endpoints. With the appropriate configuration the API can retrieve (using the GET method) data both from relational databases and SPARQL endpoints and return them in a unified way. Specifically, the GET method executes the appropriate SELECT statements on the relational database and the SPARQL endpoint, collects the results from both sources, merges them and returns the result. Currently, this functionality is supported only for the Public Service and the Public Organization classes. Additionally, the current implementation supports only the GET method for the SPARQL endpoints, while all the methods (GET, POST, PUT, DELETE) are supported for the relational databases.

Figure 3 presents a part of the API implementation description for the “Public Service” and the “Rule” classes.

Fig. 3.
figure 3

Part of the description of the API

Full size image

7 Using the API: Example Scenarios

An instance of the API has been deployed in order to execute some example scenarios. The instance of the API is available at the URL: http://pappis.gr/api. The API is connected at two data sources:

  • A relation database with CPSV-AP data related to the public service “Getting a Greek Passport" [2].

  • The SPARQL endpoint http://data.dai.uom.gr:8890/sparql that contains CPSV-AP based linked data descriptions of Public Services. The SPARQL endpoint uses the Virtuoso open-source RDF database.

The following scenarios are executed using the Postman application for calling the API and getting the results.

Scenario 1: search public services based on the name of the public organization (i.e. using the property hasCompetentAuthority of CPSV-AP) that offers them. For example, the following API call retrieves all the public services that are offered by the Public Organization with name “Passport Issuer”.

figure c

An excerpt of the returned result is presented at Fig. 4. The excerpt contains two public services with id 1 and 3 that are offered by the Public Organization with name “Passport Issuer” (some of the API results are in Greek since the relational database and the SPARQL endpoint exploited contain data in Greek).

Fig. 4.
figure 4

Excerpt of the result of Scenario 1

Full size image

Scenario 2: search of public services based on the life event they belong. For example, the following API call retrieves all the public services that belong to the life event “Traveling abroad” with id = 1. The searching is also possible using the life event name (i.e. isGroupedBy.name) but in this case the greek name of the event is required as input.

figure d

Scenario 3: search of public services based on their input/output. For example, the following API call retrieves the public service that produces as output the “Passport with 3 years duration” with id = 1. The searching is also possible using the output name.

figure e

Scenario 4: search of dependent public services (i.e. using the properties “requires" and “related" of CPSV-AP). For example, the following API call retrieves the public service that requires the execution of the public service “Certificate issuance" with id = 4. The searching is also possible using the public service name.

figure f

An excerpt of the returned result is presented at Fig. 5. The excerpt contains one public service with id = 1 that requires for its execution the public service with id = 4.

Fig. 5.
figure 5

Excerpt of the result of Scenario 4

Full size image

8 Conclusion

The Core Public Service Vocabulary Application Profile (CPSV-AP) has been proposed as a European PS data model to facilitate PS catalogue creation and promote semantic interoperability in the PS information provision. Its broader use will also be beneficial for the implementation of the Single Digital Gateway regulation. However, the use of heterogeneous, some times not very popular technologies (e.g. RDF) to provide access to CPSV-AP data hinders their further uniform exploitation.

Towards this direction, this paper proposes the development of an API to provide a uniform, easily-consumable way of serving CPSV-AP data hiding any heterogeneity of the underlying technologies and also facilitating the automatic collection of PS descriptions from multiple catalogues. The API currently provides CRUD operations on all the concepts of CPSV-AP and also basic search functionality of public services. The API is designed in a flexible way enabling the easy addition of more functionalities e.g. searching based on other more advanced criteria. Additionally, the API supports both relational databases and partially SPARQL endpoints enabling also their integration (only for public services and public organizations). In a future version of the API the authors aim at extending the functionality for the SPARQL endpoints by supporting also the PUT, POST and DELETE methods as well as by supporting all the CPSV-AP concepts at the GET.

We anticipate that the proposed API will help towards the further adoption of CPSV-AP by facilitating the development of relevant added value services and applications as well as the automatic collection of PS descriptions from various catalogues throughout Europe. This will provide multiple benefits to citizens including the provision of integrated information about PS throughout Europe, the increase of the quantity/quality of (mobile) applications that use CPSV-AP compliant data and the personalization of PS based on the citizen’s profiles. All the above can lead to the reduction of bureaucracy and time spend to identify and execute public services that in turn can foster transparency and trust between the public administration and the citizens.