Feature #13448
fermé
Paramétrer plus finement la pondération de chaque entité de contribution
Ajouté par David Lesimple il y a plus d'un an. Mis à jour il y a 5 mois.
100%
Description
Le but est de pouvoir pondérer plus finement chaque typologie d'informations d'une contribution en fonction de son importance dans les résultats de recherche :
Par exemple, par ordre décroissant de poids :
1/ Entête de publication (dans le détail, c'était l'objet de l'évolution https://tracker.silverpeas.org/issues/2932)
2/ Contenu (wysiwyg, champs de formulaire y compris document), fichiers joints.
3/ Commentaires
En effet, actuellement, les contributions qui comportent plusieurs fois le terme recherché dans les commentaires apparaissent avant une contribution dont le terme recherché n'apparait qu'une seule fois dans l'entête, ce qui n'est pas très logique.
Mis à jour par Miguel Moquillon il y a environ un an
- Statut changé de New à Feedback
David, as tu essayé de jouer avec la propriété boost.field.header dans searchEngineSettings.properties ?
Cette propriété permet de booster le score des entêtes dans la recherche.
Mis à jour par David Lesimple il y a environ un an
Miguel Moquillon a écrit (#note-2):
David, as tu essayé de jouer avec la propriété
boost.field.headerdanssearchEngineSettings.properties?
Cette propriété permet de booster le score des entêtes dans la recherche.
Cela ne répond pas complètement au besoin exprimé, car boost.field.header permet juste de donner plus de poids de l'entête par rapport à tout le reste des infos de l'élement indexé.
Mais ici, le besoin va plus loin et devrait permettre de donner par exemple plus de poids au contenu, par rapport aux commentaires notamment.
En effet, actuellement, quand le nombre d'occurrences d'un même terme dans les commentaires est elevé, c'est cette publication qui va arriver en 1ère position, c'est assez gênant.
Mis à jour par Miguel Moquillon il y a environ un an
Manipuler l'API de de Lucene pour arriver à lui faire ordonner et donc scorer les champs sur lesquels la recherche s'effectue est loin d'être anodin. Ceci demande d'utiliser des parties dites expertes de l'API.
Est ce que l'introduction de nouvelles facettes pourrait remplir le besoin ? Par exemple, ajouter comme type de contribution les commentaires. Il suffirait alors à l'utilisateur de sélectionner les publications et non les commentaires pour affiner les résultats en excluant les commentaires. Ici, j'ai l'impression que ce sont surtout les commentaires qui polluent dans certains cas la recherche.
Mis à jour par David Lesimple il y a environ un an
Miguel Moquillon a écrit (#note-4):
Est ce que l'introduction de nouvelles facettes pourrait remplir le besoin ? Par exemple, ajouter comme type de contribution les commentaires. Il suffirait alors à l'utilisateur de sélectionner les publications et non les commentaires pour affiner les résultats en excluant les commentaires.
C'est peut-etre la solution de repli en effet si c'est trop compliqué de sous-pondérer les commentaires par rapport à l'entête et le contenu, mais le mieux est quand même d'avoir les résultats les plus pertinents dès l'affichage.
Ici, j'ai l'impression que ce sont surtout les commentaires qui polluent dans certains cas la recherche.
Oui c'est tout à fait ça, ce sont les commentaires qui polluent la pertinence des résultats.
Mis à jour par Miguel Moquillon il y a 6 mois
- Statut changé de Feedback à Resolved
- A l'indexation, le contenu des commentaires n'est plus utilisé dans la valorisation du champs d'index
TITLEet par conséquent n'est plus non plus utilisé dans la valorisation du champs d'indexHEADERdédié à la recherche. Avec l'intégration de la correction #13842 le problème est résolu. - Une nouvelle facette a été définie pour ne lister que les commentaires. Celle-ci permet donc de ne sélectionner que ceux-ci, étant donné qu'ils ne sont plus remontés en haut des résultats pertinents et dans l'éventualité que l'utilisateur cible ce type de contenu en particulier.
Intitulé des commentaires dans les résultats de recherche¶
Pour satisfaire l'objectif recherché par la demande de ce ticket, un extrait du contenu du commentaire n'est plus utilisé pour créer l'intitulé du commentaire dans les résultats de recherche. En effet, celui-ci est récupéré du champs d'index TITLE qui est lui même utilisé pour valoriser le champs d'index HEADER utilisé dans la recherche et qui présente de plus un poids important dans le calcul de la pertinence des résultats d'une recherche. Afin de présenter un titre aux commentaires listés dans les résultats de la recherche, il a été choisi ici de valoriser l'intitulé à afficher par un texte standard du type "Commentaire de [NOM DE l'AUTEUR]" .
Facette des commentaires¶
Mise en place¶
Afin de ne filtrer que les commentaires ou d'éviter leur présentation lorsque qu'une facette sur un type de contribution est choisi (par exemple les "Publication GED" ), une nouvelle facette a été définie pour les commentaires. Elle est définie dans le fichiers de propriétés :SILVERPEAS_HOME/properties/org/silverpeas/pdcPeas/settings/pdcPeasSettings.properties :
search.type.10.components=kmelia,blog,quickinfo
search.type.10.types=Comment
Il suffit donc de commenter ou de supprimer ces deux propriétés pour que la facette des commentaires ne soit plus supportée.
Code¶
Afin de pouvoir créer des facettes sur des contributions liées à d'autres contributions (les commentaires et les fichiers joints aux publications par exemple), il a été nécessaire de revoir le code autour des objets d'index manipulés dans Silverpeas (IndexEntryKey, IndexEntry, etc.) et des résultats de recherche (SearchResult, GlobalSearchResult, etc.). Désormais, ces objets référencent exactement la ressource dans Silverpeas qui satisfait la recherche (une publication, un commentaire, ...) ; l'identifiant est donc celui de la ressource référencée et non plus, dans le cas d'une contribution liée (commentaire, fichier joint), celui de l'objet lié (publication).
Pour obtenir l'identifiant de la ressource liée, il faut faire appel à la méthode correspondante (IndexEntry#getLinkedObjectId(), GlobalSearchResult#getLinkedResourceId()). IL a fallu donc revoir d'une part le code de génération de liens vers les ressources dans Silverpeas qui satisfont la recherche puisque ces derniers pointent, dans le cas de contributions liées, à la contribution qui est liée (la publication), et d'autre part la vérification des droits d'accès puisque ces derniers sont portés par les contributions mères.
De même, pour l'indexation, la clé d'index (champs d'index KEY), utilisée pour identifier la ressource indexée, n'est plus formatée comme suit dans le champs d'index KEY : COMPONENT|OBJECT_TYPE|OBJECT_ID mais désormais comme suit :COMPONENT|OBJECT_TYPE|OBJECT_ID|LINKED_OBJECT_ID.
Mis à jour par Miguel Moquillon il y a 6 mois
Mis à jour par Miguel Moquillon il y a 5 mois
- Assigné à mis à Miguel Moquillon
- Version cible mis à Version 6.4
Mis à jour par Yohann Chastagnier il y a 5 mois
- Statut changé de Resolved à Integration in progress...
Mis à jour par David Lesimple il y a 5 mois
- Lié à Bug #13842: L'ordre des publications dans les résultats de recherche ne respecte pas forcément le nombre d'occurrences des termes recherchés ajouté
Mis à jour par Yohann Chastagnier il y a 5 mois
- Statut changé de Integration in progress... à Closed
- % réalisé changé de 0 à 100
Validé et intégré sur master et master-jackrabbit.
Comme vu avec Miguel et David, quelques ajustements ont été réalisés au niveau de l'indexation des commentaires et de la restitution des résultats de recherche.
(https://github.com/Silverpeas/Silverpeas-Core/commit/2ebaf5dd266c0013d9d06f8c3e8cbc580f01edb6 et https://github.com/Silverpeas/Silverpeas-Components/commit/16fdf4faf0b17a716d8551d675863d46d7330595)