An important aspect of the application was to be able to configure your own preferences. By doing so, the application will send an e-mail as soon as a car was available that matches your preferences.

This type of information is user-bound, and we believe that type of information should be stored with the customer (or in this case, the employee). That's why we decided to look at the Solid project.

WHAT IS SOLID

Solid is a project bringing scientists from all over the world together. This includes people like Tim Berners-Lee, who is known for inventing the World Wide Web, and Ruben Verborgh, who is a professor specialized at Decentralized Web Technologies at the Ghent University in Belgium.

The goal of the project is to put the users in control over their data, rather than the data being in control by organizations.

The way Solid works is by centralizing the data into a single data storage or "a pod". The specification of these pods is completely open and relies on open standards such as OpenID, OAuth 2, Demonstration of Proof-of-Posession tokens (DPoP), JSON Web Tokens (JWT) and JSON Web Keys (JWK) for security, and the Resource Description Framework (RDF) to store and retrieve the data.

Due to the open specification, you can choose whether you host your own pod or whether you use a pod hosted by another vendor.

‍

A PROOF OF CONCEPT

Mats Van Audenaeren and Ward Driesen, two students at the KdG University of Applied Sciences and Arts developed the fleet management web application as part of their internship at Optis. One of the tasks during their internship was to find out how Solid works, and how we could integrate it within the application.

MEET CARCARE

The final result of the internship is an application called CarCare. When a Cronos employee first opens the application, they will be able to authenticate using their Solid provider.

Once logged in, they'll see the current car fleet. There are a few interesting things here already. First of all, the full name comes from the Solid pod, just like their e-mail address behind the scenes. Due to the fact that there's only a single source of truth, a user will be able to change their name or e-mail address instantly across all applications that use Solid. To me, this is one of the powerful features of Solid. Imagine you moving somewhere else and having to change your address just once!

Within their profile, they can configure certain preferences. These preferences are then stored as a part of a customer profile folder within your Solid pod.

This means that other applications that have access to your pod, and are interested in building or retrieving a customer profile, can use the same data.

THE DATA MODEL IS IMPORTANT

An important aspect of the Solid project is the way you structure your data. Data is only useful if properly modelled, or as Tim O'Reilly said:

"We’re entering a new world in which data may be more important than software."
— Tim O'Reilly

This means you have to think about data through the eyes of the user, rather than through the eyes of the software.

For example, in our application, we decided to store the preferences as part of a customer profile, rather than storing it as "application data". The reasoning behind this is that we want to connect data together, rather than having individual data sources for each application.

The Solid project encourages this, by allowing us to use a Resource Description Framework or RDF. Data can be modelled using schemas or onthologies, and linked together. Then we can serialize the data using the Turtle syntax:

@prefix : <#>.
@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix pim: <http://www.w3.org/ns/pim/space#>.
@prefix schema: <http://schema.org/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix pro: <./>.
@prefix inbox: </inbox/>.
@prefix g00: </>.
@prefix n: <http://www.w3.org/2006/vcard/ns#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.

pro:card a foaf:PersonalProfileDocument; foaf:maker :me; foaf:primaryTopic :me.

:me
   a schema:Person, foaf:Person;
   n:fn "Dimitri Mestdagh";
   n0:trustedApp
           [
               n0:mode n0:Append, n0:Read, n0:Write;
               n0:origin <https://podbrowser.inrupt.com>
           ];
   ldp:inbox inbox:;
   pim:preferencesFile </settings/prefs.ttl>;
   pim:storage g00:;
   solid:account g00:;
   solid:privateTypeIndex </settings/privateTypeIndex.ttl>;
   solid:publicTypeIndex </settings/publicTypeIndex.ttl>;
   foaf:name "g00glen00b".

For example, this is the Turtle format of my profile card data. At the top, you can see which namespaces or onthologies I'm using.

One of these onthologies is the vCard onthology or http://www.w3.org/2006/vcard/ns#. From this onthology, I'm using the "fn" property, which stands for "The full name of the object".

For our customer preferences, we decided to start simple, and modelled the preferences as a Thing, with various name properties. However, in the future, we could use other schemas like a Car.

‍

‍

WHAT'S NEXT

The internship of Mats and Ward is coming to an end, but we do have a good base to expand now. First of all, I think there are more use cases for Solid within the CarCare application. For example, what if the organization had their own Solid pod. This would allow us to store the carfleet within their Solid pod. That means the organization wouldn't experience a vendor lock-in when using the application. Once a better alternative comes to the market, all they have to do is log in to the new application, and their carfleet would become available!

Other than that I think there are many use cases that could benefit from using a Solid pod. As seen before, Solid can be interesting for both the users, as the organizations!

And last but not least, the code we wrote for the CarCare appplication could be extracted to its own library, so that future Java projects can talk to the Solid pod based on the code we wrote!