Pouvoir lier deux instances SemApps

[srosset81]

Description
Pouvoir lier une ressource d'une instance SemApps avec une resource d'une autre instance.

Support de réflexions
https://docs.google.com/presentation/d/1zqt2n9hgnwlwAR42Zz24pFu7nckDPz_RPhxbEHZhQS8/edit

Frontend

• Pouvoir aggréger les ressources de plusieurs instances #794 - 4 JH
  • Amélioration du dataModel utilisé par le semantic data provider #686 - (compris dans issue précédente)
  • Composant pour filtrer les données par serveur #855 - 1 JH (option en plus des 4 JH)
  • Tester le semantic data provider #845 - 2 JH (option en plus des 4 JH)
• Ajouter un lien vers une ressource sur un autre serveur #353 - 3 JH
• Naviguer sur une ressource d'une autre instance #354 - 1 JH
• Adapter l'interface Create pour importer/forker des données existantes #945 - 1 JH

Middleware

• Endpoint VOID pour récupérer des informations d'une instance SemApps #517 - 1 JH
• Service de miroir des données publiques des autres serveurs #849 - 3 JH
• UpdateBot: acteur AP qui averti des mises à jour des données publiques #850 - 1 JH
• Importer des données d'autres instances SemApps #698 - 2 JH
  • Passer par ActivityPub pour la synchronisation des données publiques - 3 JH (option)
• LdpService: rediriger vers l'interface quand on visualise une donnée avec un Accept text/html #771 - 0.5 JH
• InferenceService: ajouter la relation inverse sur le serveur fédéré #652 - 2 JH (option)

Comptes-rendus de réunions

• https://pad.lescommuns.org/3McjRck3Rz2HID6XvcqwBw
• https://pad.lescommuns.org/WkEjbl5oSiCyrKwI1xZmxQ
• https://pad.lescommuns.org/kjsahFvmScyI3kVKEIEXwQ
• https://pad.lescommuns.org/jwkmyoEuSFaNSWnpr3KPNg
• https://pad.lescommuns.org/iA0_DuPjTHuVBRKWDBI68g
• https://pad.lescommuns.org/frkOg6DXS-qTiWpPtfH7Iw?view
• https://forums.assemblee-virtuelle.org/t/suivi-du-chantier-interoperabilite-semapps/246

Estimation du temps de travail en JH (optimiste)

• Temps de spec déjà passé (et d'exploration, recherche):
  • @srosset81 : 4 JH (+ 3 JH bénévole)
  • @nikoPLP : 2 JH
• Temps d'implémentation restant:
  • sans les options: 16.5 JH
  • avec toutes les options: 24.5 JH

[srosset81]

Dans les discussions avec @simonLouvet, nous avions parlé de gérer la recherche par la requête SPARQL fédérée dans un premier temps, puis de voir pour une solution via Elasticsearch. Personnellement j'ai de la peine à croire à la requête SPARQL fédérée, et je ne suis pas sûr que ce soit si simple à implémenter. Ce serait une option intéressante à proposer, mais est-ce que cela vaut la peine de le faire tout de suite ?

[srosset81]

Dans les discussions avec @simonLouvet, nous avions parlé de gérer la recherche par la requête SPARQL fédérée dans un premier temps, puis de voir pour une solution via Elasticsearch. Personnellement j'ai de la peine à croire à la requête SPARQL fédérée, et je ne suis pas sûr que ce soit si simple à implémenter. Ce serait une option intéressante à proposer, mais est-ce que cela vaut la peine de le faire tout de suite ?

Suite à la discussion de ce jour, nous avons réalisé qu'il y avait une confusion entre une vraie requête SPARQL fédérée (qui est compliquée) et un simple appel à de multiples endpoints SPARQL. Nous avons donc séparé en deux issues: #461 et #450. Et du coup Elasticsearch devient une option, qu'on aimerait bien pousser s'il y a le budget, car cela améliorera nettement les performances.

[srosset81]

@simonLouvet @bouviermullerp J'ai ajouté l'issue #652 à ce chantier et j'ai augmenté de 2 jours le temps nécessaire pour son implémentation.

[srosset81]

Enfin ! ;-)