# Gestion LDP Containers

*Réunion du 13/12/2019 avec Thomas Francart, Simon, Niko et Sébastien.*

## Décisions prises

- On permet pour le moment d'avoir deux types de containers:
- Les containers "automatiques" qui font une requête SparQL (quelle qu'elle soit) et retournent les résultats sous forme de container LDP. Les informations sur le container (notamment le champ `ldp:contains`) sont construites manuellement par le middleware.
- Les containers "standards" (?) qui se basent sur des relations container-ressource établies dans le triple store. Pour qu'une ressource apparaisse dans ces containers, il faut nécessairement que la relation ait été préalablement enregistrée dans le triple store.
- Les containers "standards" sont nécessaires lorsqu'on est dans de cas de "boîtes aux lettre" (p.ex. l'inbox de Linked Data Notifications), c'est-à-dire lorsqu'on veut qu'une ressource soit postée dans un container spécifique. A ce moment, il faut impérativement que la relation resource-container soit enregistrée quelque part, et l'enregistrer dans le triple store via le prédicat `ldp:contains` est à la fois naturel et efficace.
- Les containers "automatiques" posent des problèmes en terme de performance et de lisibilité du graphe de donnée. Mais il serait difficile d'imposer que la relation container-ressource soit systématiquement établie dans le triple store.
- Par exemple pour un container qui retournerait toutes les ressources d'un certain type, il faudrait ajouter l'appartenance au container à chaque fois qu'une ressource de ce type est ajoutée dans le triple store, y compris via SparQL.
- Pour que les containers "automatiques" puissent se baser sur des relations établies dans le triple store, il faudrait mettre en place un système d'indexage. Ils pourraient alors devenir des containers "standards", c'est-à-dire se baser sur les relations établies dans le triple store. C'est cependant un travail important et pas vraiment prioritaire.
- On accepte que ce problème existe en l'état des choses, et que les deux types de containers peuvent avoir du sens. On continue à y réfléchir et à en discuter au fur et à mesure que se présenteront des cas d'usages dans les semaines et mois qui viennent. Rien encore n'est fixé définitivement.

## Problèmes en suspens

- Pour l'instant les containers "automatiques" sont retournés sous forme de JSON-LD. Il faut aussi permettre de le retourner sous forme de RDF (selon le header Accept passé par le client ?) afin d'être conforme LDP.
- Est-ce que tous les types de containers "automatiques" peuvent accepter de recevoir des données en POST ? Par exemple un container qui ferait une requête SparQL très particulière, est-ce que ça a du sens qu'il puisse recevoir des nouvelles ressources en POST ? Où est-ce qu'il enregistrait ces ressources ? Sur quels critère se baserait-il pour accepter ou non cette ressource ?

*Si vous voyez d'autres problèmes en suspens que j'aurai oublié ou qui n'aurait pas encore été évoqués, n'hésitez pas à les ajouter ici !*