Tu peux avancer sans moi, il me semble que je t’ai transmis les notes que j’ai prises quand on a commencé à travailler là-dessus. ActivityPods reste ton projet c’est toi le moteur ! On aurait aussi pu travailler en asynchrone. Et puis il y a d’autres contributeurs Solid qui peuvent t’aider si tu es bloqué. D’ailleurs j’ai vu passer des mails sur ActivityPub et Solid sur la mailing list Solid notamment ici et ici avec des gens qui semblent très intéressés par le sujet.
Comme je n’ai pas beaucoup de temps je vais remettre au propre les notes, les détailler et les publier sur le forum Solid. Ca pourrait faire avancer les choses.
Je peux être dispo. Pour l’organisation j’aimerais bien qu’on liste les sujets à aborder et les questions que je dois préparer pour être un maximum efficace (temps).
Salut tout le monde et merci pour ces échanges fort (voire un peu trop parfois) stimulants !
@lecoqlibre Il faudrait quoi en plus d’OIDC et du « concept de document » pour que SemApps soit une option susceptible d’être considérée pour le NSS ?
Solid OIDC, on l’avait mis dans le projet archipelago soumis à l’appel à communs mais on a pas été sélectionné … Mais dès qu’on a du budget R&D, je crois en effet que ca vaudrait le coup de l’implémenter, ne serait-ce que pour nous éviter de nous prendre la tête (ca consomme beaucoup d’énergie j’ai l’impression !).
Par ailleurs, tu mentionnes depuis de nombreux mois l’importance du « standard client à client » : Aucune idée si tout le monde est au fait, mais si même Ruben est passé à côté, j’imagine que son importance et la doc qui va avec ne doit pas être mise en valeur et que tu pourrais peut-être partager quelques liens appropriés ?
Haha @srosset de mon côté je résume d’habitude le truc avec une formule un peu pompeuse : Autonomie radicale, reliance maximale …
Intéressantes ces citations, @lecoqlibre Maxime, en tout cas pour un nouvel entrant tel que moi : est ce que tu pourrais me donner les sources et emplacements d où cela aurait été extrait, stp ?
Je ne suis pas en capacité d’échanger avec les contributeur.trices du projet Solid, même si j’aimerais bien le faire, pour plusieurs raisons :
1 : mon niveau d’anglais n’est pas suffisant : je peux lire et écrire, mais pas interagir de manière suffisante à l’orale
2 : mon niveau de maitrise des outils/solutions existants n’est pas suffisant pour le moment, mais cela peut s’acquérir (voir raison 3)
3 : le temps disponible pour expérimenter, se documenter, approfondir au-delà des docs, décortiquer les solutions (usage, architecture, dépendances, limites…) est trop important étant donné mon temps disponible actuel et le retour sur l’investissement de temps est trop loin pour ma vie privée actuelle.
Par exemple, @lecoqlibre explique que comunica peut faire des requêtes SPARQL à partir de plusieurs sources et renvoie vers la documentation associée et je le remercie grandement pour cela. J’aimerais le tester, faire une requête SPARQL qui passe à travers les relations entre plusieurs sources, voir si la résolution se fait sans avoir préchargé les datasets concernés (récupération dynamique des relations nécessaires à l’exécution SPARQL), comprendre quel moteur SPARQL est utilisé et comment il fait pour être léger et autonome dans un navigateur sans l’architecture des moteurs SPARQL habituel (comme Jena), comprendre pourquoi c’est mieux que des solutions comme FedX ou KGRAM-DQP, comprendre pourquoi des thèses consacrées au sujet ne parle pas de comunica, comprendre pourquoi @lecoqlibre fait une thèse sur la recherche multi-sources alors que comunica répond au besoin, etc…
Malheureusement, je n’ai pas la disponibilité pour faire les actions ci-dessus mais j’aimerais beaucoup avoir des temps d’échanges (visio ou irl) avec @lecoqlibre@srosset@niko.plp Ruben @fluidlog@sylvain et toute personne avancée sur ces sujets pour avoir accès à ces informations sans devoir y consacrer l’énergie que je n’ai pas et qui mettrait ma vie privée en danger si je le faisais.
Je peux mettre un peu d’énergie pour organiser des échanges sur ces questions qui vont au-delà de semapps (mais qui pourraient être intégrées) mais je ne le ferais pas si les personnes citées plus haut n’ont pas le souhait ou l’énergie pour ces échanges.
Je me permets un post juste pour participer.
Je trouve ces échanges très intéressants dans le contenu, même si je n’ai pas tout lu, il faut que je prenne le temps de le faire.
Ce qui m’étonne, c’est ta position depuis le début @lecoqlibre.
Je ne souhaite pas échanger plus sans comprendre comment tu te place, quelle est ton énergie par rapport à l’AV (qui, pour rappel, est un ensemble d’organisations et d’humains s’intéressant au web sémantique). Comprendre ton attitude, sans la critiquer, comprendre comment je dois lire tes posts, etc. et je ne souhaite pas que tu me réponde ici. Je pose la question ici pour partager mon questionnement aux autres lecteurs, cela ne regarde que moi.
Vu que ce sujet humain n’a rien à voir avec le sujet cité, je vous propose d’en parler lors d’une réunion entre nous.
@lecoqlibre je te laisse m’appeler en fonction de tes dispos (sinon, je me note de le faire la semaine prochaine) et on lancera un framadate pour trouver une date. Ca vous va ?
Le but de cette réunion sera juste de trouver chacun notre place les uns par rapport aux autres. Ensuite, je serai ravi de reprendre des échanges techniques
Sentez-vous libre de refuser ma demande et de continuer à échanger ici.
Les commentaires de Maxime m’ont bien éprouvées moralement. Etant donné la fixité des positions, je ne suis pas sûr que j’aie envie de continuer en visio…
En fait, ces « échanges » me donnent plutôt envie d’arrêter de passer du temps à me conformer au standard Solid et de me concentrer sur la communauté ActivityPub qui, je pense, comprend très bien la révolution que représente ActivityPods… Mais bon, je vais quand même garder le cap Solid, en espérant trouver dans cette communauté des oreilles plus compréhensives. Je suis en train d’écrire plusieurs articles de blog pour aider à comprendre la spécificité et la « raison d’être » du projet ActivityPods.
Il y a malheureusement toujours un énorme écart entre la théorie que présente Maxime et la réalité de la spécification Solid. Je viens de passer encore 2 jours la semaine dernière à me documenter sur le standard Solid en lien avec les standards LDP et WAC (je n’entrerai pas dans les détails) et le nombre de sujets qui font encore débat a de quoi faire perdre la tête. Cette spec est loin d’être achevée… et en attendant, moi je souhaite faire des applications qui tournent et qui sont utilisées par des êtres humains. Récrire « Bienvenue chez moi » avec un serveur Solid type filesystem et une surcouche ActvityPub prendrait au moins une année, et les résultats seraient très, très incertains.
En tout cas, SemApps reste une boîte à outil très extensible. Rien n’empêcherait de réaliser, en plus d’ActivityPods, un serveur 100% compatible Solid (et sans ActivityPub) qui s’appuierait sur SemApps: mes refactoring actuels aident dans cette direction (p.ex. la création dynamique de containers LDP). Je pourrai aider un développeur qui souhaiterait se lancer dans ce chantier, mais je ne le ferai pas moi-même.
Je réponds quand même à @srosset car sa réponse me donne envie de partager ici comment je communique sur SemApps et Solid au sein du projet Carto4CH (depuis 1 an et demi…).
En effet, je pense que ce serait intéressant d’imaginer un serveur SemApps avec fileSystem, il pourrait s’appeler « SolidApps » .
C’est bien l’objectif de l’AV de permettre à n’importe qui de proposer de nouveaux projets.
Dans mon projet Carto4CH, au début, je « surfais » sur ce terme SOLID car il parlait à certains techniciens qui avaient lu des articles à ce sujet et avaient une « vague idée » de ce que cela permettait, et me permettait une introduction plus simple pour les non initiés, en parlant aussi des PODs etc.
Depuis peu (avant cette discussion), j’ai mis à jour mes slides pour être plus précis et je fais attention à parler de « proposition du W3C ».
J’ai essayé à chaque fois dans mes présentations de ne pas dire que SemApps suivait le « standard » SOLID, j’ai souvent dit que SemApps s’inspire fortement de la proposition du W3C SOLID, et rappelé là où nous ne sommes pas SOLID (authentification, pods, filesystem).
Mais j’ai encore des MAJ à faire, et à chaque mise à jour de mon portail, je corrige des coquilles dans ce sens.
Quand je peux, j’essaye de supprimer le terme SOLID, car je préfère préciser les 5 autres qui sont vraiment des standards.
Par exemple, lorsque j’explique le mode distribué, je précise que chaque partenaire de la cartographie de compétence peut utiliser les technologies qu’il souhaite du moment qu’il respecte les standards proposés (Web sémantique, LDP, SPARQL, WAC, ActivityPub).
Lorsque je parle de SemApps, je dis même que c’est « plus qu’un serveur SOLID », car il permet d’avoir LDP + SPARQL, un frontend fonctionnel, une ontologie PAIR, des composants réutilisables, etc. Dois-je conserver ce discours ? (là, on est pour moi dans une sorte de marketting « il est frais mon poisson ! », et pourquoi pas…).
SOLID reste pour moi un CAP. Car c’est un terme qui commence à « buzer », et donc qui apporte une vision intéressante du web distribué qui invite tous les partenaires d’un projet distribué à aller dans le même sens. Cela ne signifie pas que chaque partenaire soit tout de suite 100 % conforme à SOLID, surtout lorsque ce n’est même pas une recommandation.
Les échanges ci-dessus montrent les écarts qu’il y a entre SemApps et SOLID, et c’est super, peut-être qu’on en restera là, je ne vois personnellement pas en quoi c’est dérangeant si on est clair dans la communication. Peut-être qu’il y aura un projet SolidApps à l’AV l’année prochaine, mais l’important est d’adapter l’outil avec le besoin. Lorsqu’on a besoin d’un triplestore (peu importe les raisons), on utilise SemApps, sinon, soit on développe son propre serveur, soit on utilise les projets de serveurs SOLID déjà existants.
Parfois, je me dis que si j’installe 100 serveurs SemApps pour y cartographier des compétences dans 100 organisations, ça me parait un peu lourd de faire tourner 100 triplestores au niveau de la consommation. J’aimerais être plus sobre à l’avenir.
Lorsqu’un partenaire (Carto4CH) souhaite faire son propre serveur SOLID (autre que SemApps), pour publier ses compétences, je préfère lui conseiller de prendre directement un CSS (Comunity Solid Server), et donc je serais très curieux d’avoir une estimation du temps à passer pour faire tourner le frontend Archipelago sur un CSS.
Car c’est possible que ce soit un des chantier de 2024 (avec le projet européen ECHOES) si on trouve des partenaires intéressés, mais qui ne souhaitent pas utiliser le serveur SemApps (certains veulent faire du Django par exemple…).
Pour info, vous trouverez ici ma présentation de SemApps :
Je vais voir pour proposer un work item à la communauté Solid sur le standard client à client. Il y a aussi l’idée de faire un Primer Solid (document officiel qui explique de manière simplifiée comment faire une appli Solid).
Yes, la réponse de Tim B. Lee à Ruben a été retirée mais tu peux la retrouver dans les archives du net en parcourant les archives de la liste public Solid.
La réponse de Henry Story est dispo sur cette même liste ici.
L’anglais oral n’est pas forcément un problème puisque la majorité des échanges se passent par écrit. La communauté Solid est particulièrement active sur GitHub et sur Gitter.
Attention, je ne fait pas une thèse mais un projet de recherche sur l’indexation et la découverte de données. Comunica est effectivement un outil et à ce titre il ne répond pas en lui-même au besoin. Nous étudions comment on peut indexer et découvrir des données dans un écosystème Solid (stratégies d’indexation, standard client à client, sélection de sources, passage à l’échelle…).
Oui vu tes réponses je me suis dit que tu voulais peut-être être challengé.
En attendant le challenge semble avoir été relevé par quelqu’un d’autre puisque le gagnant du dernier Hackathon Solid for Social Networks Hackathon a présenté un travail sur Solid et le fediverse :
Vincent, who wanted to build an app that’s part of the fediverse, yet stores the data in a Solid Pod. And Vincent succeeded brilliantly, demonstrating how Solid can be seamlessly integrated with Mastodon.
Comme promis, il a reçu une récompense de 2500 $ ! J’essaie d’avoir accès à son travail.
Dans ce fil, je t’avais invité à participer @srosset car je sentais que le sujet Solid + ActivityPub était très prometteur. Avec tes connaissances de la spec AP via ton travail sur ActivityPods, tu avais probablement de quoi faire quelque chose de très convainquant. Sans compter que le Hackathon se fait par équipe donc il y avait peut être moyen de faire quelque chose avec ce fameux Vincent. J’aurais bien aimé y participer mais ce n’est pas mon sujet du moment et mes supérieurs ne m’ont pas laissé y participer (on est sur l’indexation et la découverte de données).
De mon côté je réfléchis à proposer un work item Solid + AP plutôt qu’un article. Cela permettra de travailler à plusieurs sur le sujet et d’être plus bénéfique à la communauté. Pas sûr que ca passe du côté de mes employeurs sauf peut être si c’est à moindre investissement.
Super ! Sais-tu quand tu vas pouvoir publier ? Peut-être déjà un article ?
Une preuve de concept serait déjà top ! Tu peux utiliser le Community Solid Server et implémenter directement AP dans ton client.
Je ne vois pas pourquoi ce serveur 100% compatible Solid ne pourrait pas être compatible AP.
Oui la communication est un point qui me semble très important. Nous avions déjà discuté il y a quelques mois et le positionnement d’ActivityPods n’est toujours pas correct pour moi.
Par exemple, sur le site d’ActivityPods, dans le paragraphe "What is the main shortcoming of Solid Pods ? " on peut toujours lire « Despite its name, Solid includes few features for social networking. For example, when you share a resource, the recipient will not know about it, unless you write to him. In their current implementation, Pods are personal databases with little connection to the outside world » :
Déjà je trouve que la première phrase qu’on peut traduire par « malgré son nom, Solid n’inclut que quelques fonctionnalités pour les réseaux sociaux » laisse sous entendre que le projet Solid ne sait pas vraiment ce qu’il fait. D’autant plus qu’il n’y a aucune preuve de ce qui est avancé et aucune prise en compte de la partie client-à-client. De mémoire je crois que @srosset tu as juste remplacé « no » par « few » (avant c’était carrément « Solid n’inclut pas de fonctionnalité… ».
La seconde phrase « Par exemple, lorsque l’on partage une ressource, le destinataire ne sera pas informé, à moins qu’on lui écrive » n’est pas vraie puisqu’elle ne prend pas du tout en compte la dimension standard client-à-client ni la partie notifications de Solid. Avec Solid on peut tout faire, la partie métier dépend du standard client-à-client. La spec serveur ne se concentre à juste titre que sur la partie serveur.
La dernière phrase « Dans leur implémentation actuelle, les PODs sont des bases de données personnelles avec une faible connexion au monde extérieur » présentes plusieurs points problématiques :
Si « Dans leur implémentation actuelle » fait référence aux différentes implémentations serveur actuelles et bien je ne dirais pas de CSS qu’il permet une faible connexion au monde extérieur puisqu’il permet différentes méthodes de notifications. Et encore une fois cette phrase ne prend pas en compte la dimension client-à-client.
« les PODs sont des bases de données personnelles » n’est pas tout à fait correcte puisqu’on parle plutôt de magasin de données (data store) et ce n’est pas uniquement personnel (un POD peut être utilisé pour une organisation). De plus, l’aspect base de données est réducteur puisque l’architecture document fournit plus qu’une simple base de données.
J’approuve puisque pour Mycelium/DFC, les producteurs ont tous des petits jeux de données (produits, clients, commandes, etc). Le file system est particulièrement adapté. Je ne désapprouve pas le TripleStore pour autant.
Ca me semble délicat compte tenu de l’état actuel de SemApps.
Si SemApps était compatible Solid je ne verrais aucun inconvénient à dire ça ! C’est à mon sens le genre d’argument qu’on va voir fleurir dans le futur quand d’autres serveurs Solid vont arriver sur le marché. Ils vont probablement chercher à se démarquer les uns des autres en mettant en avant différents services.
Pour SemApps, personnellement ça me gênerait d’entendre ce discours tant qu’il n’est pas compatible. Tu peux dire qu’il respecte en partie Solid et propose des services complémentaires.
Pour moi il faudrait arriver à trouver des formulations justes qui n’invisibilisent pas Solid pour autant. Il me semble que Solid est un point important pour l’AV et c’est bien qu’il soit visibilisé car il doit faire face aux concurrents industriels de « data space » qui sont en train d’émerger (GaiX, IDSA).
J’aimerais que tu nous expliques cela d’une manière ou d’une autre. J’ai toujours compris que un POD était lié à un utilisateur et son authentification Solid-OIDC.
J’ai discuté avec @lecoqlibre sur les dataspace (COD) de Solid et le fait qu’un POD doit être lié à un webId/user. Il m’a précisé que ce user est un agent et qu’un agent n’est pas obligatoirement une personne physique, mais peut être l’application elle-même.
Le WebId de l’agent permet d’obtenir son profil et le profil d’une application peut fournir des informations utiles aux autres applications comme les adresses des containers ou autre api utile pour l’interopérabilité (que nous aurions mis dans une url « well-known » dans semapps) et le protocole client-to-client.
J’en ai déduit que ces urls peuvent également être les inBox et outBox de l’application (vs celles des users) pour la synchronisation entre applications avec activityPub.
Ces précisions sont peut-être des portes ouvertes, mais elles m’ont permis de mieux comprendre le protocole client to client de Solid et je trouve cela pertinent pour semapps et activityPod.
Je ne sais pas si les travaux de @srosset vont dans ce sens et je serais ravi d’en apprendre plus.
