ActivityPods est 100% compatible ActivityPub, LDP, WAC… on peut déjà reconnaître ça 
Si je m’en foutais des standards, j’aurai pu arriver au même résultat en 10x moins de temps.
Oui c’est super 
! 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.
On peut aussi faire des « statements » avec le principe « Une ressource = un URI ». Je ne vois pas ce que l’usage de « documents turtle » (comme tu les qualifies) change à cela ?
Le contexte ! Je répondrai plus en détails plus tard.
Pour moi il y a deux choses: le concept philosophique et architectural de « personal online datastore » (Pod), qui a été imaginé à un moment donné et qui n’est certainement pas la propriété d’une seule personne ou un seul groupe, et l’implémentation concrète de Solid via des standards sur lesquelles un grand nombre de personnes se mettent d’accord.
Tu peux reprendre l’idée du POD et l’arranger à ta sauce mais ce n’est plus un POD Solid. Tu proposes alors un standard technique alternatif ce qu’on cherche précisément à éviter.
Pour info le terme POD est en train de changer de nom et va probablement s’appeler « storage » car la communauté s’est rendue compte que le mot « Personal » dans POD induit trop de personnes en erreur sur le fait qu’un POD est uniquement personnel. Or un POD (storage) peut très bien être utilisé collectivement. Certains membres de l’AV utilisent le mot COD avec le C pour « Collective », mais un POD/storage a déjà cette fonctionnalité en lui-même.
Pour le dernier, je ferai remarquer que le standard est très loin d’être finalisé (le working group au sein du W3C n’a été créé qu’il y a une année) et qu’il y a encore de la place pour des évolutions, si les groupes de travail sont ouverts.
Le fait que le standard ne soit pas finalisé n’est à mon sens pas une raison pour ne pas l’implémenter convenablement. C’est normal dans un processus de construction. Au Data Food Consortium nous avons des gens qui nous disent qu’ils ne contribueront pas au projet car il n’est pas finalisé. Nous on leur dit qu’on a justement besoin de gens qui contribuent pour que la finalisation arrive plus vite !
Côté standardisation, je ferais remarquer tout de même que le projet Solid est bien plus proche de devenir une recommandation W3C qu’ActivityPods ou SemApps !
La réponse plutôt « énervée » de TBL à l’article de Ruben m’a créé des doutes sur ce point, mais je reste optimiste et je vais continuer à travailler ces prochains mois dans le sens d’une coopération, dans la mesure de mes petits moyens.
Je n’ai pas plus de détails sur cet échange. La réponse de Tim B. Lee a été dé-publiée peu de temps après. Je sais néanmoins qu’il existe des tensions entre les deux protagonistes. Même si c’est désagréable, c’est tout à fait habituel dans un projet collectif.
Je pense que tu sous-estimes le temps que je passes à réfléchir à ces sujets…
J’avoue que je n’en ai aucune idée.
Je ne peux que constater ton absence de réponse sur le sujet du standard client-à-client.
De plus nous avions commencé ensemble un travail d’intégration d’ActivityPub (AP) à Solid. Nous avions obtenus de très bons résultats qui montraient une faisabilité. Ce travail demande à être continué. Personnellement je n’ai pas encore de bande passante à consacrer à ça pour l’instant. Mon temps salarié reste dans le champ de l’indexation, j’ai d’ailleurs réalisé un agent indexeur lors d’un Hackathon Solid. Comme AP c’est ton sujet je trouve que cela aurait été bénéfique que tu continues ces travaux d’intégration d’AP à Solid. Je n’ai pas vu de tes nouvelles sur ce sujet donc j’ai plutôt l’impression que tu préfères développer ta solution non standard plutôt qu’une solution Solid ?
De plus, l’argument du temps passé ne fait pas autorité. C’est quelque chose de relatif, il y a des gens très rapides, d’autres très lents. Ce n’est pas parce qu’on étudie quelque chose depuis longtemps qu’on ne peut pas passer à côté de quelque chose. Ruben est par exemple passé à côté su standard client-à-client alors qu’il est expert sur le sujet sémantique/Solid !
Je te remercie quand même car cette discussion m’a permis de mieux prendre conscience de la spécificité des projets SemApps, Archipelago et ActivityPods, et je vais faire un article sur notre histoire et là où on pourrait aller
Génial, j’ai hâte de lire ça !
C’était une intention très différente de Solid, qui se focalise sur le respect de la vie privée et donc sur la protection des données.
La partie protection des données n’est qu’une partie de Solid. Solid est également un projet d’interopérabilité dans lequel tu peux très bien implémenter une solution pour « aider les organisations de la Transition à coopérer, en créant des bases de données ouvertes en lecture et écriture ».
Mais avec ActivityPods, la jonction a été faite entre ces deux approches.
Tu sous entends que ces deux approches ne sont pas jointes ce qui est pour moi faux. Solid permet justement de joindre ces deux approches, c’est dans son ADN. Mais pour ça il faut s’intéresser au standard client-a-client. ActivityPods réinvente la roue puisque l’impossibilité d’intégrer ActivityPub dans Solid n’est pas démontrée (nos premiers travaux montrent plutôt que c’est possible, comme dit précédemment).
assurer un maximum d’autonomie tout en maintenant un maximum d’interopérabilité
Yes, c’est exactement le projet Solid ! 
Il n’est pas possible de réaliser une requete SPARQL directement sur un enssemble de documents stoqués sous forme de fichier.
Ca fonctionne très bien avec Comunica ou LDflex !
Avec Communica, une requete multi document doit se faire sur le navigateur
Pour info c’est possible côté serveur également.
ce n’est pas possible de faire cette requete (qui exploite des liens entre sujets de différents documents) actuellement dans communcia
Si, tu as le link traversal pour ça ! Il y a même un link traversal spécial Solid qui exploite certaines caractéristiques des PODs ! On est en train de voir pour rajouter la prise en charge d’index dans ce moteur.
Mais même sans link traversal, tu peux parcourir toi même les liens et les ajouter comme sources, c’est très facile avec LDflex.
A l’AV nous avons considéré que les applications devaient pouvoir faire une requete SPARQL à un serveur et que celui-ci devait le faire sur la globalités des données qu’il possede et que les serveurs fédérés possedent (actuellement grace au miroir mais on voudrait faire mieux). Si nous nous étions limité à l’architecture induite par le stockage en fichier (je rejoinds @srosset sur l’adhérence de Solid à celle-ci) cela imposait aux applications clientes de devoir agréger des données dans un moteur SPARQL sur le navigateur pour pourvoir faire des requete cross-document
L’équipe de Comunica a démontré depuis bien longtemps qu’une requête SPARQL était faisable sur une architecture documents multi-serveurs (PODs). Et même très performante avec l’arrivée des streams !
Maintenant on est en train de d’étudier comment les index définies dans les standards client-à-client peuvent permettre d’obtenir de très bonnes performances sur les petits jeux de données comme sur les très gros. Nos premiers résultats sont très bons mais ce n’est pas encore publiable. C’est quelque chose qui aurait pu/dû être étudié avant si l’aspect client-à-client avait été pris en compte. Je crois savoir que l’équipe de Ruben est en train de s’y mettre aussi maintenant…
