Solid, vers un web plus sain

Publié le dans #solid, #décentralisation, #découverte.

Alors que je viens de tomber sur un magnifique mail d’Adobe qui annonce des changements sur Adobe XD défiant toute logique, je me décide enfin à vous parler de l’un de mes coups de cœur du moment: la plateforme Solid.

Pour commencer et que ce soit clair, il ne s’agit pas des principes d’une architecture CLEAN mais bien d’un projet lancé par monsieur Tim Berners-Lee à qui l’on doit entre autre le fameux World Wide Web, rien que ça !

Dans cet article, je vous propose un petit aperçu de ce qui se cache derrière Solid alors accrochez vous, avalanche d’acronymes en perspective !

Aujourd’hui

Sur Internet, chaque application possède ses propres données qui ne vous appartiennent pas. Dans le meilleur des mondes, ces données seraient utilisées uniquement pour la dite application.

Sauf que, comme ces données valent de l’argent, et bien elles sont revendues à des tiers, principalement pour des campagnes de publicités ce qui engendre beaucoup de questionnement sur la vie privée et la confidentialité des données.

Dans tous les cas, ces données sont difficilement manipulables et compatibles entre elles.

L’approche de Solid

Vos données vous appartiennent

Solid propose une approche différente. Pour faire très simple :

  • Vous créez un Pod qui contiendra toutes vos données (hebergées chez vous ou un fournisseur de confiance) et vous permettra de vous authentifier sur n’importe quelle application Solid,
  • Vous autorisez les applications à venir lire et écrire des données dans votre Pod,
  • Profit! 🍾

Pour ce faire, il existe des spécifications Solid qui définissent justement comment doit fonctionner un Pod, ce qui doit être exposé et comment.

Au final, Solid n’est ni plus ni moins qu’un ensemble de spécifications:

  • Hypertext Transfer Protocol pour le transport,
  • Linked Data Platform pour l’échange et la manipulation des données,
  • WebID pour l’authentification des utilisateurs,
  • Web Access Control pour la gestion des autorisations.

Le web sémantique

Il y’a un terme qui reviendra souvent si vous vous décidez à lire quelques spécifications susmentionnées, il s’agit des Linked Data.

Avant de me pencher sur ce sujet, j’en avais pour ma part, très peu entendu parler. L’idée est finalement assez simple, de la même manière que l’on expose un document HTML pour les humains, il faut pouvoir exposer des données sémantiques capable de référencer d’autres données sémantiques de manière à ce que les machines puissent les parcourir et les comprendre facilement.

Toutes ces données forment alors un graphe ou plus communément une toile (Oh wait?).

Le terme sémantique est important ici. Le but n’est pas juste d’exposer n’importe quel format avec un champ prénom, qui n’aurait aucun sens dans une autre application qui utiliserait peut-être le champ firstName, mais bien d’utiliser des vocabulaires connus comme ceux figurant dans schema.org pour donner du sens à cette valeur avec le champ https://schema.org/givenName. Si vous représentez vos ressources en JSON par exemple, vous pourriez le faire passer en JSON-LD, ajoutant ainsi de la sémantique à vos ressources.

En utilisant des schémas connus, n’importe quelle application sera à même de comprendre qu’il s’agit du prénom d’une personne et donc de pouvoir recouper des informations de plusieurs sources éparpillées sur le Web.

Ensuite, les Linked Data utilisent le Resource Description Framework (RDF) pour représenter des données sous la forme d’un triplet :

sujet prédicat objet

De cette manière, on est capable de représenter une ressource avec toutes ses propriétés.

Pour un petit topo sur Linked Data et Linked Data Platform, je vous conseille cet excellent article, mais pour que vous ayez en tête à quoi ressemble une ressource RDF, voici un des exemples donnés :

<http://dbpedia.org/resource/Abraham_Lincoln> <rdf:type>           <http://dbpedia.org/class/yago/PresidentsOfTheUnitedStates> .
<http://dbpedia.org/resource/Abraham_Lincoln> <dbp:birthPlaceName> "Hodgenville, Kentucky, U.S." .
<http://dbpedia.org/resource/Abraham_Lincoln> <dbo:birthPlace>     <http://dbpedia.org/resource/Hodgenville,_Kentucky> .

Ici, on nous informe que le sujet Abraham Lincoln (représenté par une URI) est né à Hodgenville et si on suit la ressource représentée par cette URI, alors on aurait toutes les informations sur la ville en question et ainsi de suite.

Notez que le RDF n’est au final qu’une structure de données orientée graphe et que la représentation peut varier (Turtle ou encore JSON-LD pour ne citer qu’eux).

Revenons à nos moutons

Après cette petite digression, voyons ce que ces données sémantiques peuvent apporter à la plateforme Solid.

Imaginez que vous réalisiez une application de calendrier en ligne qui se connecte sur un pod Solid. Si vous utilisez un vocabulaire défini comme par exemple schema.org/Event pour stocker vos événement dans le pod, alors l’utilisateur pourra à tout moment passer à une autre application de gestion de calendrier qui utilise le même vocabulaire si il le souhaite ! Dans tous les cas, ces données restent exploitables et définies au travers d’un schéma public.

Et ça, c’est chouette ! Le web sémantique, c’est la réappropriation des données, le partage et le choix.

OK, je pense qu’on va s’arrêter là pour aujourd’hui, ça fait déjà beaucoup à digérer et j’en suis conscient et c’est sûrement le gros point noir de cette approche, c’est extrémement compliqué au début et pour ma part, tout n’est pas encore parfaitement clair 😁.

Les spécifications Solid sont encore en développement mais je vous invite à créer un pod et à suivre le petit tutoriel pour réaliser une application qui se connecte dessus si vous êtes curieux.