Créer un service qui indexe les ressources sur Elasticsearch

[srosset81]

Tension
Pour faire de la recherche sur différentes instances, on peut faire une requête SPARQL fédérée, mais ça peut poser des problèmes de performances et aussi de disponibilité.

Proposition
On pourrait imaginer un serveur de recherche ElasticSearch dédié qui serait informé (en mode push) des mises à jour des ressources des différentes instances d'un écosystème. Lorsqu'on l'interrogerait sur un mot-clé, il retournerait les résultats avec, pour chaque ressource, l'URI et le label (pour pouvoir afficher quelque chose sans requête l'URI).

L'avantage d'Elasticsearch, c'est qu'il possède un API très évolué et qu'on pourrait donc utiliser directement Elasticsearch sans aucune surcouche.

Il serait facile de créer un service Moleculer qui écoute quand une ressource LDP est créé / modifiée / supprimée, qui l'indexe directement sur un serveur Elasticsearch via le client Node d'ES (voir l'exemple ici).

Ensuite une simple requête ES (effectuée depuis le front, ou via le middleware) permettrait de récupérer très rapidement les ressources qui matchent les mots-clés entrés par l'utilisateur.

Cela pourrait être utilisé pour de la recherche fédérée, mais aussi simplement pour fournir un résultat rapide à la recherche (sans avoir besoin de configurer Fuseki pour faire de la recherche sur du texte)

Alternatives

• Permettre la requête SPARQL fédérée Permettre la requête SPARQL fédérée #450 (plutôt facile, mais peu performant)

[GuillaumeAV]

Oooh oui pas sur de comprendre exactement de quoi il retourne, et encore moins d'avoir un avis pertinent mais j'ai l'impression que la proposition est excellente :)

[srosset81]

Je ferme car on a laissé tomber cette proposition en faveur d'un serveur d'indexation en SPARQL: #849