Cas d’usage et spécifications techniques


Dissocier les données des interfaces sur le web


Être en capacité :
- De manipuler des données issues d’une multiplicité de base de données à partir d’une même interface.
- D’utiliser une diversité d’interfaces pour manipuler un même jeu de données.
- D’utiliser différentes ontologies pour correspondre à la diversité des besoins métiers

Produire et partager des données conformes aux standards du web sémantique

[…]

Lier les données, organiser l’information


L’objectif premier de SemApps est d’organiser l’information. L’usage du web sémantique permet de créer des liens signifiants entre les données.

Interopérer les systèmes d’informations


Il s’agit de pouvoir, en premier lieu, fédérer plusieurs instances du même système, puis en second lieu, que ces instances soient en capacité de se fédérer avec d’autres systèmes, afin de créer réseau social décentralisé.

Chaque plateforme doit pouvoir être source et destination de ces données.
C’est le principe de la fédération.

L’usage de formats standards et de modèles sémantiques communs (RDF, LDP, Sparql font consensus) permet de créer de l’interopérabilité entre les systèmes d’information qui peuvent dès lors communiquer entre eux, ce que ne permettent pas les plateformes actuelles, organisées en “silos”.

Faisons l’analogie avec les langages humains :

- Si 3 personnes parlent 3 langues différentes, alors elles ne pourront pas communiquer. A l’inverse, si elles parlent une langue commune, elles pourront communiquer.
- De la même manière, si 3 systèmes d’information structurent leurs données de manière différente, alors, ils ne pourront pas communiquer. A l’inverse, s’ils utilisent un langage commun pour structurer leurs données, alors ils pourront communiquer.

Permettre une identification, une authentification et une gestion de droits distribuées

[…]

Gérer des données dynamiques

Permettre à des serveurs ActivityPub extérieurs de suivre les activités d’un acteur sur SemApps

Il s’agit d’inclure SemApps dans le graphe global des données ActivityPub, pour permettre à n’importe quelle application ActivityPub de se connecter au flux d’activité qui est généré par un acteur sur une instance donnée.

- Permettre à tout utilisateur / organisation sur SemApps de devenir un acteur ActivityPub, avec implémentation des endpoints /inbox, /outbox et /followers
- Inscrire chacune des opérations CRUD de l’acteur dans son flux d’activités (Outbox)
- Traiter les requêtes Follow venant d’autres serveurs
- Faire suivre aux followers le flux d’activité, à condition que la ressource manipulée soit lisible par l’utilisateur connecté (un follower n’a pas forcément les droits de lecture sur tous les objets)

Rendre visible sur SemApps le flux d’activités des acteurs
Une fois qu’on a rendu public le flux d’activités d’un acteur, il ne serait pas forcément compliqué de le rendre visible directement sur SemApps, ou sur n’importe quelle autre interface. Il suffirait de lire l’Outbox.

Sur la page d’un acteur (utilisateur / organisation), afficher son flux d’activité (Outbox), en filtrant selon les droits de l’utilisateur loggé (ou en ne montrant que les activités publiques si l’utilisateur n’est pas connecté)

Note: A ce stade, on ne pourrait pas voir les anciennes versions des ressources modifiées, sauf si on implémente le versionning avant l’étape 4, par exemple dès la première version de SemApps.

Intégrer la notion de fil personnalisé à SemApps


Là on passe à une autre échelle, puisque SemApps prend les allures d’un réseau social, avec un fil personnalisé regroupant les activités de tous les acteurs qu’on suit.

Permettre à un utilisateur SemApps de suivre un autre utilisateur / organisation, y compris sur une autre instance, en ajoutant un bouton “Suivre” sur la page de cet acteur.
Ajouter à SemApps, ou sur une autre interface, la possibilité de voir sa propre Inbox, qui contiendrait les activités de tous les acteurs qu’on suit.

Note: On pourrait aussi imaginer un bouton “Suggérer à des amis” qui permettrait d’envoyer à tous ses followers - ou à des utilisateurs en particulier - la suggestion de suivre un acteur. L’activité Offer permet ce genre de choses.

Afficher l’historique d’une ressource

Afficher l’historique des activités d’une ressource peut-être précieux, surtout dans le cas d’objets qui sont fréquemment modifiés. On s’approcherait du fonctionnement d’un wiki, en donnant plus largement les droits de modifications sans risquer de perdre les données.

Etendre les objets ActivityStreams pour ajouter une propriété history, qui contiendrait la liste ordonnée de toutes les activités liées à cette ressource (Follow, Update, Like…).
Pouvoir voir une ressource à un instant T. Ou encore mieux: voir la différence d’une ressource entre deux instants.

Pouvoir suivre les activités liées à une ressource

Cela permettrait à un logiciel externe (type YesWiki) d’être tenu au courant de toutes les modifications d’une ressource, quel que soit l’acteur qui l’a modifiée. On pourrait ainsi garder un cache des ressources, sans avoir à les requêter à chaque fois pour savoir si elles ont été mises à jour. On pourrait même généraliser ce fonctionnement aux communications inter-instances SemApps.

- Étendre les objets ActivityStreams en ajoutant une propriété de type subscribers et ajouter une propriété de type subscriptions aux acteurs (cela éviterait de confondre avec l’activité Follow ?)
- Quand une activité est effectuée sur un objet (Update, Delete, Like), envoyer automatiquement toute l’activité aux followers, en signant le message dans le cas de fédération.

Possible implémentation via des webhooks et un serveur “externe”

Il suffirait que SemApps implémente un système de webhooks sortant lors des opérations CRUD et qu’il envoie les donnée au serveur ActivityPub (qui gère déjà les webhooks entrant dans sa version prototype actuelle)

Spécifications techniques


- Serveur LDP sur triple store Jena
- Serveur SOLID sur triple store Jena
- Serveur AP sur triple store Jena
  • Serveur SOLID AP LDP sur triple store Jena !

Base de données

Nous utilisons Jena + Jena Permissions + ldp-service-jena packagé dans un seul repo avec toutes les couches. Docker compose pour structurer la stack.

Pour les droits d’écriture, nous utilisons Jena Actions : Principals may perform Create, Read, Update or Delete operations on secured resources. These operations are defined in the Action enum in the SecurityEvaluator interface.
Pour les droits d’accès et WebACL (qui peut changer les ACL) ce sera a nous de nous en charger, mais ce sera pareil, nous vérifirons les droits pour tout CRUD sur les triple qui représentent des ACLs

Backend

Un backend générique peut répondre à la diversité des besoins de nos différentes communautés.
Celui-ci peut se concevoir comme une composant autonome, et composante de SemApps.

Frontend
- Liste de fonctionnalités pour le Front (Onglet devis front)