Merci pour ces publications ! Et bravo pour le travail !
Je ne les ai vu passer qu’en fin de semaine, n’hésite pas à me mentionner pour que je sois notifié.
Voici déjà quelques retours concernant l’implémentation Solid.
Retour sur le document « Solid compliance »
Quelques remarques :
WebID ne semble pas être correctement implémenté (voir le point sur le support des documents plus bas).
Pour l’autorisation, tu n’as pas forcément besoin d’implémenter les ACP. Tu peux implémenter WAC ou ACP ou les deux. Pour moi le voyant autorisation peut être à 100% vert. Source : la spec « Solid protocol » dit "Servers MUST conform to either or both Web Access Control [WAC] and Access Control Policy [ACP] specifications.
Le support de la pagination LDP (LDP paging) est facultatif. Ce n’est pas une recommandation mais une note de groupe de travail LDP et la spec « Solid protocol » n’impose pas au serveur de l’implémenter.
La partie « SPARQL endpoint » ne devrait pas faire partie de cette page étant donnée que Solid ne le requiert pas (peut être à décaler sur la page « spécificités » ?).
La modification en N3 patch
L’argument pour ne pas implémenter N3 PATCH me semble assez léger : « Until the N3 Patch method is standardized, we will continue to use the SparqlPatch format ».
Ca me semble assez étrange de dire ça alors que d’autres composants non standards sont indiqués comme implémentés ou en cours (ex : WebID, Solid-OIDC). Et que la spec Solid n’est elle même pas standardisée.
D’autant plus qu’il y a déjà le support d’une méthode en particulier « SparqlPatch ». En conception logicielle, une bonne pratique est de prévoir des couches d’abstraction (interface) un peu partout. Cela permet d’être beaucoup plus souple et agile dans le développement. C’est à mon avis encore plus incontournable quand on cherche à implémenter une spécification en développement. Si couche d’abstraction il y a il est potentiellement très facile d’ajouter une autre méthode de PATCH.
Pour les deux raisons énoncées, je trouve que cet argument mériterait d’être revu ou détaillé.
Absence du support des documents (parfois appelés graphes nommés) ?
L’article ne mentionne pas l’absence du support des documents. Le document permet de faire des déclarations à propos de chose(s) dans un contexte donné. Techniquement, au sens de Solid, il permet de faire des paquets de triplets RDF, ou de regrouper des triplets. J’ai créé une discussion dédiée pour exposer le problème.
Concernant WebID, la spec concernée et particulièrement la section 5. Publishing the WebID Profile Document demande la représentation d’un document : « WebID requires that servers MUST at least be able to provide Turtle representation of profile documents ».
Merci @lecoqlibre pour ces retours précis et très utiles !
Ah c’est une bonne nouvelle ça
Il ne le requiert pas, mais est-ce qu’il l’interdit ? Il me semble qu’une partie de la communauté Solid aimerait trouver un moyen d’intégrer les endpoints SPARQL dans la spécification. Voir par exemple cette issue pas si ancienne. Ruben Verbogh dit également dans cette discussion« We should definitely think about different server-side interfaces to RDF. However, I expect LDP to remain the only mandatory interface, and other interfaces such as a SPARQL endpoint (but there are others). » (malheureusement Ruben a effacé tous ses posts du forum Solid, donc on n’a plus que quelques citations…)
Concernant le N3 Patch, je suis d’accord que ça devrait être reformulé, merci. En tout cas l’architecture de SemApps ne devrait pas poser de problème pour supporter deux formats de patch. Mais N3 patch sera quand même un gros morceau puisque, comme on utilise un graph global pour chaque Pod, il ne faudrait pas qu’on puisse modifier des triplets en dehors du document patché. Cela est donc en lien avec la problématique des « documents Turtle » adressée dans ton autre post, auquel je répondrai à part.
Il me semble qu’une partie de la communauté Solid aimerait trouver un moyen d’intégrer les endpoints SPARQL dans la spécification. Voir par exemple