InferenceService: ajouter la relation inverse sur le serveur fédéré

[srosset81]

Tension Lorsqu'on ajoute une relation vers une donnée d'un serveur fédéré, on ne peut pas, comme pour des données internes, ajouter la relation inverse directement dans le triple store. C'est dommage car cela permettrait de rendre visible les relations entre instances.

Proposition Au niveau de l'inference service, lorsqu'on détecte qu'une donnée fait partie d'un serveur distant, faire un appel PATCH sur la ressource avec la relation inverse. Si jamais l'appel échoue, réessayer plus tard (permettre d'utiliser une Queue, comme on fait pour ActivityPub). Lorsque la relation est supprimée, faire un PATCH pour supprimer la relation inverse sur le serveur distant.

Attention: Ne pas créer le triple au niveau du triplestore local, sinon on risque d'avoir des données qui ne sont pas synchronisées (notamment si le serveur distant supprime le triple ou si l'appel PATCH échoue).

Si les WebACL sont activés sur l'instance distante, il faudra peut-être un mécanisme de token entre serveurs "amis", indiquant qu'un serveur est autorisé à modifier les données sur un autre serveur.

Alternative Utiliser ActivityPub, avec une activité de type Offer (qui pourrait être acceptée ou refusée), mais cela obligerait toutes les instances SemApps à supporter ActivityPub. On pourra proposer cette option dans le futur, en complément à un appel direct LDP.

[GuillaumeAV]

Ce serait une bonne chose non que toutes les instances SemApps supportent ActivityPub non ?

Je comprends l'intérêt de la modularité mais s'il y a des besoins d'interopérabilité et de fédération, je me dis qu'AP peut faire partie de la solution ...

[srosset81]

Pour maintenir une instance avec ActivityPub depuis une année (pour Colibris), je peux dire que ça ajoute plus de complexité, notamment au niveau des données. Je pense pas qu'il faut obliger à utiliser ActivityPub, sauf s'il y a un réel besoin.

[srosset81]

Commentaires suite à la réunion de ce jour (voir le CR complet):

• Ce type de problématique est peu traité car très peu de serveurs acceptent de faire du read-write. La plupart sont en read.
• Concernant la gestion des droits, le plus simple serait d'utiliser le webId de l'utilisateur connecté pour l'opération PATCH
• Au niveau de l'endpoint avec les infos de l'instance, on pourrait indiquer si on accepte ou pas l'ajout des relations inverses. Et pour quelles ontologies.
• Il existe une ontologie pour décrire les métasdatas des datasets: https://www.w3.org/TR/void/
• Voir comment SOLID gère ce type de problèmes, notamment autour des ACP (alternative aux ACL)
• On pourrait stocker les liens inverses sur un "serveur de fédération" ? (Utile lorsque le serveur distant est en read-only) On pourrait indexer les relations inverses sur une instance Elasticsearch ?

[srosset81]

Implémentation

• Envoyer une activité Offer > Add > Relationship vers l'acteur Relay du serveur distant
• Si pas d'acteur Relay disponible, on fait LDP PATCH et on voit si elle est acceptée
• Traiter l'activité Offer du côté du serveur B (accepter automatiquement, si ce bot existe)