Implémenter SPARQL Update sur le PATCH des ressources.

[srosset81]

Problématique
Nous allons supprimer la méthode PATCH actuelle car elle ne fonctionne pas sur des graphs RDF. Cependant son absence pose des problèmes: on risque de faire continuellement face à des problèmes de concurrency. En effet, la méthode PUT fait d'abord un GET sur la ressource, puis elle fait un diff pour savoir quoi ajouter ou retirer. Mais si entre temps la donnée a été modifiée, le PUT peut supprimer des données.

C'est déjà le cas pour l'ajout de collections par le ActivityPub registry, mais je vois beaucoup d'autres cas où ça pourrait être problématique. On est parti pour de longues heures de débugging, avec parfois des solutions très compliquées (pour le ActivityPub registry, cela m'obligerait à tout réécrire afin d'ajouter les collections avant que l'event ldp.resource.created soit émis).

Proposition
On pourrait implémenter un PATCH sur les ressources avec un SPARQL Update limité. Dans cette issue du projet Solid, ils reconnaissent que le plus simple dans un premier temps c'est de ne supporter que les opérations INSERT DATA et DELETE DATA. C'est exactement ce que @nikoPLP a fait pour le PATCH sur les containers et on pourra reprendre son code. Cela limite les risques de sécurité et simplifie le code.

La seule limitation est qu'on ne peut pas insérer des blank nodes par ce biais. Il faudra donc, lorsque ce cas est nécessaire, passer par GET+PUT. Lorsqu'on aura l'énergie, on pourra voir pour supporter des requêtes SPARQL plus complexes.

Cette méthode PATCH pourrait être utilisée côté semantic data provider, mais ça fera l'objet d'autres issues.

Côté middleware, je proposerai que l'action ldp.resource.patch accepte aussi, à la place du body sous forme de SPARQL Update, deux paramètres de type Array faciles à utiliser: triplesToAdd et triplesToRemove. Cela évitera que les autres services aient besoin de construire des requêtes SPARQL à chaque appel.

Alternative
Il existe un autre standard pour faire du PATCH sur un serveur LDP mais il n'est pas utilisé par Solid et je ne crois pas qu'il soit utilisé ailleurs. Il m'a l'air très compliqué car il introduit un nouveau vocabulaire: https://www.w3.org/TR/ldpatch/

[srosset81]

Après lecture plus complète de l'issue Solid, je vois qu'ils se sont décidés pour la v0.9 pour un format N3:

solid/specification#332

Car il donne plus de possibilité qu'un SPARQL Update avec seulement INSERT DATA / DELETE DATA.

Mais ils disent qu'ils comptent revenir sur le SPARQL Update pour la v1.0

Personnellement je préférerai rester à ce stade à une solution simple, sachant que rien n'empêchera d'implémenter plusieurs formes de PATCH. Surtout qu'on utilise déjà INSERT DATA / DELETE DATA pour les containers.

[srosset81]

Fait #1080