Utiliser un triplestore est compliqué parce que les différentes specs Solid prennent très peu en compte cette possibilité.
Oui car ce n’est pas utile : je le répète on n’a pas besoin d’un triplestore pour faire du Solid. La spec Solid n’a pas à définir les choix techniques sous-jacents, elle définit des règles de plus haut niveau.
Personnellement je ne regrette pas une seule seconde le choix du triplestore ! […] alors que ce qu’on a fonctionne également très bien (les performances d’ActivityPods sont excellentes grâce à la combinaison des choix qui ont été fait).
Peut-être mais ce n’est pas compatible avec Solid donc ça ne vaut rien sur le plan du standard ! Il y a plein d’autres solutions qui fonctionnent très bien mais ce n’est pas ce qui est demandé. Ce qui est demandé ce sont des solutions compatibles avec le standard, point.
Je constate également que le choix d’utiliser un storage en filesystem créent de grosses complications pour les autres serveurs Solid, comme on le voit en lisant le fameux article de Ruben. Donc au final chaque choix technologique implique des complications et aussi des simplications. C’est la beauté de la diversité
Je ne sais pas exactement ce à quoi tu fais référence ici mais je ferais la même réponse que Tim B. Lee à Ruben : tu sembles ignorer complètement l’aspect standard client-à-client. La spécification client-serveur de Solid donne un cadre qui permet de faire tout ce qu’on veut à l’intérieur. C’est ensuite le rôle du standard client-à-client, réunissant un ensemble d’acteurs souhaitant fonctionner ensemble, de résoudre ces complications.
Mais tu n’as pas répondu à ma question: Quel serait l’intérêt de stocker chaque ressource dans un graph différent du triple store ? Et par extension: Quel serait l’intérêt d’avoir des documents dans lesquels on peut mettre n’importe quel type de triple ? Moi je trouve que le principe « une ressource = un URI » fonctionne très bien et je ne comprends pas ce qu’apporteraient des documents tels qu’on peut en avoir avec un storage en filesystem.
C’est plutôt Henry Story qui y a répondu notamment avec « The statement by a doctor that I should take some medication does not have the same value as someone in a bar telling me to ».
C’est vrai. Mais je ne suis pas d’accord que SemApps s’éloigne de Solid. Il y a deux ans, on avait pas de Pods. Maintenant on en a,
Non désolé, vous n’avez pas de PODs puisque vous n’êtes pas compatibles Solid ! Tu ne peux pas prendre le concept de POD, le sortir de son contexte, lui enlever ce qui ne te convient pas et appeler ça un POD. Un POD n’a de sens qui s’il est compatible avec d’autres PODs (Solid). Tu ne peux pas prendre uniquement ce qui t’arrange dans un standard. C’est le principe, c’est la définition d’un standard ! En plus de l’authentification, vous n’êtes pas en architecture documents (RDF) donc vous n’avez pas de POD. Vous avez quelque chose qui y ressemble mais ce n’est certainement pas un POD Solid.
on se rapproche du standard, du moins autant que cela est possible.
Même remarque que précédemment, tu ne peux pas prendre uniquement ce qui t’arrange dans un standard. Il faut implémenter le tout (ou au moins le minimum) pour être compatible avec l’écosystème.
Il est vrai que lorsqu’on a commencé SemApps en 2019, on hésitait à implémenter Solid-OIDC (qui s’appelait à l’époque WebID-OIDC) car les specs bougeaient encore trop.
C’est le jeu quand on construit un standard. Au Data Food Consortium c’est pareil, le standard évolue et des mises à jour doivent être faites continuellement. Cela n’a pas de sens de vouloir implémenter un standard tout en se plaignant des évolutions normales issues du processus de construction de ce standard. Oui implémenter un standard en construction est coûteux mais c’est annoncé dés le départ.
Maintenant Solid-OIDC semble plus stable, donc je ne vois pas de raison de ne pas l’implémenter, si ce n’est un manque de moyens (Mais j’avoue que ce n’est pas non plus une priorité pour ActivityPods car l’authentification par signature HTTP fonctionne bien et il y a d’autres problèmes plus graves qui mérite mon attention)
Le fait de ne pas faire une priorité de Solid-OIDC indique pour moi un manque de considération de l’aspect collectif et communautaire de Solid. Solid ce n’est pas uniquement une solution technique, c’est un projet collectif qui fonctionne si tout le monde (ou au moins ceux qui souhaitent contribuer) joue le jeu. Un projet collectif ne peut pas réussir si chacun fait les choses à sa manière dans son coin. On définit des règles ensemble et on les applique, c’est une condition sine qua non.
Si je m’en foutais des standards, j’aurai pu arriver au même résultat en 10x moins de temps.
! Mais là on parle du standard Solid. Si tu veux le respecter tu ne peux pas faire l’impasse sur certains éléments essentiels comme l’authentification par exemple.