When interacting with government institutions, citizens may often be asked to provide a number of documents to various oficials, due to the way the data is being processed by the government, and regulation or guidelines that restrict sharing of that data between institutions. Occasionally, documents from third parties, such as the private sector, are involved, as the data, rules, regulations and individual private data may be controlled by diferent parties. Facilitating eficient flow of information in such cases is therefore important, while still respecting the ownership and privacy of that data. Addressing these types of use cases in data storage and sharing, the Solid initiative allows individuals, organisations and the public sector to store their data in personal online datastores. Solid has been previously applied in data storage within government contexts, so we decided to extend that work by adding data processing services on top of such data and including multiple parties such as citizen and the private sector. However, introducing multiple parties within the data processing flow may impose new challenges, and implementing such data processing services in practice on top of Solid might present opportunities for improvement from the perspective of the implementer of the services. Within this work, together with the City of Antwerp in Belgium, we have produced a proof-of-concept service implementation operating at the described intersection of public sector, citizens and private sector, to manage social benefit allocation in a distributed environment. The service operates on distributed Linked Data stored in multiple Solid pods in RDF, using Notation3 rules to process that data and SPARQL queries to access and modify it. This way, our implementation seeks to respect the design principles of Solid, while taking advantage of the related technologies for representing, processing and modifying Linked Data. This document will describe our chosen use case, service design and implementation, and our observations resulting from this experiment. Through the proof-of-concept implementation, we have established a preliminary understanding of the current challenges in implementing such a service using the chosen technologies. We have identified topics such as verification of data that should be addressed when using such an approach in practice, assumptions related to data locations and tight coupling between our logic between the rules and program code. Addressing these topics in future work should help further the adoption of Linked Data as a means to solve challenges around data sharing, processing and ownership such as with government processes involving multiple parties.
When the government decides to ofer social benefits to its citizens, it will need some information about those citizens to properly allocate the benefits. Furthermore, when the social benefit concerns services ofered by the private sector, such as benefits that are aimed to help citizens with electricity, gas or water invoices, the private sector may need to be involved in the process to some extent. To eficiently manage the allocation of benefits, the necessary data and other information needs to be accessible without unnecessary bottlenecks, such as manual labour in sending and receiving the necessary information as traditional documents multiple times over.
Together with the city of Antwerp in Belgium, we have produced an example use case in social benefit allocation, where the government ofers eligible citizens a subsidy on utility invoices, in the form of social tarif , by paying part of the eligible citizens’ utility invoices to private sector service providers. To facilitate this social tarif use case, the government has provided a set of rules that determine a citizen’s eligibility to this benefit. The citizen has personal information associated with them that is evaluated against the rules to determine eligibility. The private sector utility company possesses the information needed to produce invoices for the citizen.
Decentralisation initiatives such as Solid [
Following this introduction, section 2 will illustrate our use case and the service design, section 3 will introduce the implementation decisions, and section 4 outlines the observations and future work discovered during the experiment, with conclusions in section 5.
Preconditions: The government is ofering a subsidy on utility invoices to citizens who meet a
certain criteria. The subsidy is realised as a social tarif on invoices from utility company, where
the government pays part of the invoice of citizens eligible for that subsidy. To facilitate such
social tarif in practice, the government has defined a set of rules determining the eligibility of a
citizen based on data about that citizen. The utility company has the invoice for citizen together
with a set of rules to allocate that invoice between the citizen and the government based on
the eligibility of citizen. Within this use case, the government, citizen and utility company
have all chosen to use Solid pods to store their respective data and rules, and share that data
with each other as deemed appropriate. The tasks of determining social tarif eligibility and
allocating the invoice appropriately have been assigned to dedicated services. All five entities
– the government, citizen, utility company and the two services – are identified by their own
WebIDs [
Use case 1B: The data associated with the citizen makes them eligible for social tarif according to the government rules. The eligibility update service uses the rules to process the data and saves the status as eligible into the pod of the citizen.
Use case 1B: The data associated with the citizen does not make them eligible for social tarif according to the government rules or the data is not accessible or is unreadable, causing the system to fall back to not eligible. The eligibility update service saves the status as not eligible into the pod of the citizen.
Use case 2A: The user has been marked as eligible for social tarif. The invoice allocator service reads this data, reads the invoice data from the company, processes the invoice using the invoice splitting rules from the company, and then sends the invoice parts to the government and citizen accordingly.
Use case 2B: The user has been marked as not eligible for social tarif. The invoice allocator service reads this data, reads the invoice data and splitting rules from the company, processes the invoice using those rules and just sends the invoice to citizen without splitting it.
The proof-of-concept implementation was built using existing established open-source software and libraries to the greatest extent possible at the time of implementation. Reducing the amount of custom code to the minimum was deemed important for appropriate evaluation of existing software available for implementing such a system. The system consists of three parts: Solid pods, reasoner and services. The technology choices are outlined below, and the code has been made available online1.
The Solid pods were set up using the Community Solid Server [
Listing 1: Sample of the social benefit status for a citizen, to be used with the rules.
The rules from the government and the utility company were expressed through Notation3 [
The services were implemented in TypeScript. Data access was abstracted through the use
of Comunica [
? i d s o c i a l : i s S o c i a l T a r i f f E l i g i b l e ? e l i g i b l e } Listing 3: Sample SPARQL query used to abstract data access in Solid pods, taken from the prototype implementation.
Authentication was implemented using an existing library [
The observations from this proof-of-concept implementation are discussed in section 4. While the specific use case here tackled a social tarif problem, the concept of building services running on Solid and Linked Data could be generalised to other government services such as healthcare or education eligibility, or be applied in business-to-business or other scenarios.
The main purpose of this proof-of-concept prototype was to demonstrate the feasibility of implementing such a system between multiple parties to serve a real-life use case that takes advantage of the decentralised aspects of Solid to ensure all parties maintain full control of their own data, as well as identify potential shortcomings that could impact the implementation of other similar systems in practice. We have identified a number of shortcomings with our approach, outlined below, that when addressed, should help the implementation of Solid and RDF-based services in practice.
• Verification of information : The prototype operates on data spread across pods and
assumes it be accurate and up-to-date. The current approach allows citizens to make
themselves eligible for benefits if they know which data to modify in their pods, regardless
of whether they would be eligible in practice. This issue could be addressed through a
number of approaches, for example by digitally signing the relevant parts of the RDF
graph stored in the pod [
Though our schedule prevented the investigation of solutions to these challenges, we believe that addressing combinations of them will provide an interesting opportunity for future work. We acknowledge the shortcomings of this paper with regards to insuficient eforts towards developing solutions to these challenges and the associated reduction in the significance of this paper’s contributions and the completeness of the work.
We conclude that addressing the shortcomings in section 4 through future work should help the
adoption of Linked Data in practice, to solve real world challenges such as with GDPR but also
general eficiency of passing data around within government and non-government processes.
Services that need to process data should be possible to build on Linked Data and initiatives such
as Solid, without the developers of those services having to make unnecessary assumptions or
workarounds. Some of this work has been outlined previously in work on refining the definitions
of a Solid pod [
The described research activities were supported by SolidLab Vlaanderen (Flemish Government, EWI and RRF project VV023/10). The use case was created in partnership with, and co-funded by, the City of Antwerp. Ruben Taelman is a postdoctoral fellow of the Research Foundation – Flanders (FWO) (1274521N).