The Core Public Service Vocabulary Application Profile (CPSV-AP) is a reusable and extensible data specification used for harmonising the way public services are described in a machine-readable format. CPSV-AP captures fundamental characteristics of a public service, such as the name, description, competent public organisation, output, etc. Public administrations and service providers can therefore use this approach to describe their services and guarantee a level of cross-domain and cross-border interoperability at European, national and local level.
CPSV-AP includes the cardinality and data type of the properties, while specifying mandatory and optional elements to be used. According to the latest version, only 2 classes are mandatory: public service and public organisation, the rest being optional classes. Mandatory classes and properties indicate the minimum requirements to comply with CPSV-AP. A minimal implementation of CPSV-AP at least provides information on the mandatory properties of the mandatory classes. Optional classes can still have mandatory properties for which information should be provided when the particular class is used in the description of public services and events.
Below you will find various guides and practical examples.
1. From tabular data to linked data
Public Administrations might want to have descriptions of public services in the form of tabular data, such as a spreadsheet.
Several tools exist that can be used to transform tabular data into linked data. SEMIC provides an Excel sheet template that can be used to convert tabular data into linked data according to CPSV-AP using SKOS Play !.
In the template each tab represents a class that is present in CPSV-AP. In each tab the respective properties can be found, as well as a URI for each entry.
Below an example of an entry in the template can be found:
The template can be filled using the CPSV-AP documentation to determine the ranges and cardinalities of each field. For the inclusion of multiple values in a single entry, or other customisations of the Excel sheet, the SKOS Play ! documentation can be consulted.
Please note that the cells in the “rdf:type” column of each class should be populated with the URI of that class; for example in the case of Public Service that would be http://purl.org/vocab/cpsv#PublicService.
To convert the model to linked SKOS Play ! can be used, for which this Excel sheet is optimised. The Excel sheet simply has to be uploaded to the web interface and SKOS Play ! will automatically convert the Excel document to RDF expressed in a Turtle format. Guidelines for using SKOS Play ! can be found below on the left side of the image.
Once converted the tool will display the converted Excel document in the desired serialisation format, in this case Turtle in the browser which then can be saved locally and viewed in any text editor. The generated Turtle for the example can be found on below on the right side of the image.
2. From technical interoperability to semantic interoperability (JSON to JSON-LD)
Public Administrations that have already reached technical interoperability provide a REST API to describe or interact with Public Services.
If such an API returns a JSON response, semantic interoperability could be reached by enriching the API with a JSON-LD context, provided by CPSV-AP. An example of an output of a REST API reusing the CPSV-AP JSON-LD context can be found below on the left.
On the top of the JSON structure, you will find an URL which is the value of the @context property, this URL corresponds with the CSPV-AP JSON-LD context.
After assuring that all the properties in the JSON are described with an URI inside the JSON-LD context, it is possible to turn the JSON into JSON-LD. In JSON-LD Playground, the JSON content can be pasted in the input field. The JSON input will be converted to JSON-LD and can be displayed in different manners such as an expanded JSON view, tabular or a graph visualisation. This is shown on the right side of the image above.
3. Being compliant with CPSV-AP with manual and automatic validation
a. Being compliant with CPSV-AP with manual validation
The Interoperability Test Bed provides a validation service allowing public administrations to validate their data against the CPSV-AP data model by integrating the SHACL shapes provided by CPSV-AP.
You can access the CPSV-AP validator via this link.
To validate a model an RDF file can be uploaded. Next the CPSV-AP model against which it can be validated can be selected. Lastly, the syntax of the content can be selected. However, based on the file extension the ITB can automatically detect the correct syntax.
If your file is validated against the CPSV-AP data model, you will see the validation message that is displayed on the right side of the image above.
Let us consider the example of instance data of CPSV-AP that is provided in the CPSV-AP specification. We can save this example in a Turtle format and test it in the validator. The results are displayed on the right.
We can see that some validation errors are found. In this case, the errors that are found are regarding the use of values that do not originate from the correct codelist associated with the concepts they are describing.
b. Being compliant with CPSV-AP with automatic validation
Via the SHACL Validator REST API, you are able to validate a single or multiple RDF instances against SHACL shapes. The REST API can be accessed through an interface and the output is a machine readable API response indicating validation errors.
To validate a single RDF instance. The content can be provided either within the request as a BASE64 encoded string or remotely as a URL. The RDF syntax for the input can be determined in the request as well as the syntax to produce the resulting SHACL validation report. The version of CPSV-AP against which you want to validate your data should also be specified.
To start the validation select the first POST request and the additional fields will collapse. To use this request, press on ‘Try it out’.
For the domain you should specify ‘cpsv-ap’. In the example the following request body was provided:
{
"contentToValidate": "https://raw.githubusercontent.com/SEMICeu/CPSV-AP/master/releases/3.2.0/html/examples/example-rdf_public_service.ttl",
"contentSyntax": "text/turtle",
"embeddingMethod": "URL",
"validationType": "v3.2.0",
"reportSyntax": "application/ld+json"
}
This includes the example from CPSV-AP taken from GitHub has content to validate, the embedding method of which is a URL. The content syntax and the report syntax should also be provided. Additionally, the user must specify which version of CPSV-AP the data is validated against. An example of using the interface can be found below.
The response indicates, like in the previous example, that the file does not pass the validation. The same issues persist, namely that an instance of a skos:Concept is expected.
4. Reusing CPSV-AP - the Flemish Government example
Concepts in CPSV-AP, like Public Service, can be reused by pointing at the same URI. In this that would be http://purl.org/vocab/cpsv#PublicService when the concept is reused as-is, that is having the same meaning. The example below shows how OSLO (Open Standard for Linking Organisations), an initiative by the Flemish government, reuses the concept of Public Service together with its properties (OSLO Dienstencataloog).
The example below is from the OLSO Dienstencataloog, in particular the class Publieke Dienstverlening, which translates to English as Public Service. Hovering over the name of the class shows the underlying URI, which corresponds to the URI of Public Service in CPSV-AP.
Below is an excerpt from the JSON-LD context of the OSLO Dienstencataloog. On the penultimate line the URI for CPSV-AP Public Service can be found.
