none
WSS - Search et les mots clés parasites RRS feed

  • Question

  • Bonjour,

    J'ai mis en production un site basé sur Windows Sharepoint Services 3.0 couplé avec Microsoft Search Server 2008 Express.
    J'utilise celui-ci comme centre de recherche.
    Les bases de données sont hébergées sous SQL Server 2008 Standard Edition.
    Le problème que je rencontre est le suivant :
    Lorsque que j'effectue la recherche "signature dans outlook" je retrouve bien un document dont le titre est "insérer une signature dans outlook".
    En revanche, lorsque je recherche avec l'expression "signature avec outlook", le document ne ressort pas.
    J'aimerais savoir comment peut-on éliminer les mots parasites de la recherche.
    A priori, ça semble lié au moteur de recherche SQL Server, qui nativement devrait éliminer ce genre de mots clés, mais sur mon environnement, ce n'est pas le cas.

    Merci d'avance pour votre aide.
    jeudi 4 février 2010 09:08

Réponses

  • Les pages de résultats de recherche et de recherche n'ont pas à être redéveloppées. A priori elles n'incorporent pas directement les composants de recherche, mais ce qu'on appelle des Delegate Controls. Ce composant apporte un niveau d'abstraction et redirige selon le contexte vers un composant particulier (dans votre cas le composant de recherche).

    Pour vérifier que nous parlons bien de la même chose, le composant dont je vous parle devrais ressembler à ça dans la page :

    <SharePoint:DelegateControl runat="server" ControlId="SmallSearchInputBox"/>

    Si c'est bien le cas, c'est gagné. Le véritable contrôle de recherche associé au delegate control se trouve ailleurs. Tout ce que nous savons c'est qu'il est identifié par le nom SmallSearchInputBox.

    Une recherche sur les tous fichiers contenant ce nom sur votre serveur devrait devrait indiquer les fichiers SearchArea.xml situés dans les dossiers C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\OSearchBasicFeature et  C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\OSearchEhhancedFeature (devrait car ça diffère peut être avec Search Server).

    Ces fichiers contiennent quelque chose proche de ceci :

    <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
      <Control 
        Id="SmallSearchInputBox" 
        Sequence="100" 
        Url="/templates/mysearchcontrol.ascx"/>
    </Elements>

    Notez l'attribut URL. Le fichier .ascx qu'il référence est le véritable contrôle de recherche. IL est donc possible de le modifier. Cependant, modifier directement les fichiers XML ou ASCX standards de SharePoint n'est pas recommandé. Pour effectuer une modification proprement, il vous faut développer une feature SharePoint référençant un delegate control avec l'identifiant SmallSearchInputBox et un numéro de séquence plus petit. En effet, l'interface SharePoint remplace la déclaration du delegate control par le contrôle ayant le plus petit numéro de séquence.

    Donc ici, vous avez la possibilité de remplacer le contrôle utilisé sur toutes vos pages de recherche par votre propre contrôle, sans modifier du tout les pages de recherche. En prime, vous pourrez revenir en arrière très simplement (simple désactivation de feature).

    L'idée est donc de créer un contrôle de recherche (copiez le fichier ascx existant et modifiez le) pour qu'il supprime les mots parasites (vous externaliserez cette liste de mots parasites dans un fichier sur le serveur ou dans une liste SharePoint pour la gérer plus facilement).

    Si vous comptez utiliser cette fonctionnalité depuis une application tierce, vous gagnerez peut être à faire ce filtrage des mots parasites sous la forme d'un service WCF utilisé à la fois par vos application et par les WebParts.

    Pour savoir comment créer une feature SharePoint, vous pourrez vous référer à la page Working with Features du MSDN.

    Sébastien PICAMELOT - http://blogs.developpeur.org/gribouillon
    vendredi 26 février 2010 14:57
    Modérateur

Toutes les réponses

  • Bonjour Xavier,

    Je ne serai malheureusement pas à même de t'aider sur WSS.
    Néanmoins, j'ouvre une parenthèse parce que manifestement d'après la description de ta config tu as réussi à installer SQL Server 2008.

    Tu avais un problème d'install pour ce produit dans ce thread-ci :
    http://social.msdn.microsoft.com/Forums/fr-FR/sqlserverfr/thread/90cef57a-9ecf-4283-89dd-2ac918865604

    Je voudrais donc savoir si les articles que je t'avais donnés t'ont aidé.
    Et si ce n'est pas le cas, peux-tu nous donner ce que tu as fait pour résoudre ton problème ?
    Merci d'avance pour ta réponse, de préférence sur le thread en question ;)

    Cordialement,

    Thomas
    Thomas Aimonetti - C# - Sharplog Engineering - http://www.sharplog.fr
    jeudi 4 février 2010 09:54
  • Je relance ce sujet car à ce jour je n'ai pas eu d'ébauche de solution...

    Le problème est que sharepoint n'élimine pas les mots vides ou parasites (du type : et, le, la les, avec) et ne sait pas non plus gérer les pluriels.

    y a t'il des solutions ?

    merci d'avance.
    mardi 23 février 2010 12:48
  • Vous avez deux solutions :

    - celle en natif (ok pour SharePoint, peut être pas sous Search Server... à voir) : http://www.shannonbray.com/2008/03/noise-words-in-search.html
    - celle basée sur la suppression des mots parasites directement sur l'interface de recherche : http://www.andrewconnell.com/blog/articles/405.aspx



    Sébastien PICAMELOT - http://blogs.developpeur.org/gribouillon/
    mardi 23 février 2010 13:02
    Modérateur
  • Bonjour,

    Avant tout, merci pour ces informations très utiles qui viennent compléter celles que j'ai déjà pu glaner.
    Le fonctionnement de Search diffère sans doute de celui de WSS 3.0 (cf : http://clubmoss2007.org/MOOSsearch.aspx). Voici un extrait d'un article sur le sujet :

    Le processus d'indexation et de stockage démarre au niveau du moteur d'indexation, qui est chargé d'analyser la source de contenu. Le moteur commence son analyse après avoir vérifié qu'il dispose d'un gestionnaire de protocole approprié pour lire les sources de contenu. Une fois le gestionnaire de protocole approprié pour la source de contenu chargé, le gestionnaire de protocole et les IFilters nécessaires extraient et filtrent les éléments de la source de contenu. Un IFilter est un complément qui permet au moteur d'index d'ouvrir, de lire et d'indexer le contenu de nouveaux types de fichiers qu'il ne pourrait pas entièrement indexer sans cela. Les IFilters extraient le texte et les métadonnées de chaque document et retransmettent ensuite le flux au moteur d'index.

    Les propriétés du document sont ensuite enregistrées dans la mémoire des propriétés, et le texte du document à proprement parler est placé dans l'index de contenu. Mais juste avant cela, le moteur d'index supprime les mots « parasites ». Le moteur traite également les informations à l'aide de séparateurs de mots et d'outils de conjugaison afin de simplifier les données, et de permettre une meilleure exécution des requêtes. (Les séparateurs de mots décomposent le texte en mots et en phrases. Les outils de conjugaison génèrent les formes désinentielles d'un mot donné).


    J'en déduis donc que le moteur devrait de lui même éliminer certains mots vides (= parasites) et gérer les conjugaisons, ce qui n'est pas le cas puisqu'une recherche sur un pluriel ne ramène pas les singuliers du mot.

    Pour la 1ère hypothèse, je n'ai pas de catalogue de texte intégral sur les bases WSS, donc l'utilisation des dictionnaires de mots vides ne peut non plus fonctionner.

    Reste la 2ème solution que vous me proposez qui m'intéresse et que j'avais déjà envisagé (les sources présentées ici m'intéressent tout particulèrement). Le cas exposé n'est pas tout à fait le même puisqu'il s'agit plutôt d'exploiter le moteur de recherche de WSS depuis une application .Net tierce. J'ai du coup un problème de conception en terme d'architecture.

    Mon site est constitué comme suit :
    - en haut de chaque page : la webpart de recherche (actuellement basée sur un centre de recherche Search Server) qui pointe vers l'url http://monsite/recherche/.
    - un centre de recherche dispo via l'url http://monsite/recherche/.
    Du coup, je serai tenté de dire qu'il me faut recréer une webpart en remplacement de la webpart de recherche. Le souci est qu'il me faudrait aussi redévelopper la page du centre de recherche (recherche simple mais aussi recherche avancée) ce qui me semble tout de même assez compliqué.

    Avez-vous des conseils à me donner ?

    Cordialement,
    vendredi 26 février 2010 13:35
  • Les pages de résultats de recherche et de recherche n'ont pas à être redéveloppées. A priori elles n'incorporent pas directement les composants de recherche, mais ce qu'on appelle des Delegate Controls. Ce composant apporte un niveau d'abstraction et redirige selon le contexte vers un composant particulier (dans votre cas le composant de recherche).

    Pour vérifier que nous parlons bien de la même chose, le composant dont je vous parle devrais ressembler à ça dans la page :

    <SharePoint:DelegateControl runat="server" ControlId="SmallSearchInputBox"/>

    Si c'est bien le cas, c'est gagné. Le véritable contrôle de recherche associé au delegate control se trouve ailleurs. Tout ce que nous savons c'est qu'il est identifié par le nom SmallSearchInputBox.

    Une recherche sur les tous fichiers contenant ce nom sur votre serveur devrait devrait indiquer les fichiers SearchArea.xml situés dans les dossiers C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\OSearchBasicFeature et  C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\OSearchEhhancedFeature (devrait car ça diffère peut être avec Search Server).

    Ces fichiers contiennent quelque chose proche de ceci :

    <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
      <Control 
        Id="SmallSearchInputBox" 
        Sequence="100" 
        Url="/templates/mysearchcontrol.ascx"/>
    </Elements>

    Notez l'attribut URL. Le fichier .ascx qu'il référence est le véritable contrôle de recherche. IL est donc possible de le modifier. Cependant, modifier directement les fichiers XML ou ASCX standards de SharePoint n'est pas recommandé. Pour effectuer une modification proprement, il vous faut développer une feature SharePoint référençant un delegate control avec l'identifiant SmallSearchInputBox et un numéro de séquence plus petit. En effet, l'interface SharePoint remplace la déclaration du delegate control par le contrôle ayant le plus petit numéro de séquence.

    Donc ici, vous avez la possibilité de remplacer le contrôle utilisé sur toutes vos pages de recherche par votre propre contrôle, sans modifier du tout les pages de recherche. En prime, vous pourrez revenir en arrière très simplement (simple désactivation de feature).

    L'idée est donc de créer un contrôle de recherche (copiez le fichier ascx existant et modifiez le) pour qu'il supprime les mots parasites (vous externaliserez cette liste de mots parasites dans un fichier sur le serveur ou dans une liste SharePoint pour la gérer plus facilement).

    Si vous comptez utiliser cette fonctionnalité depuis une application tierce, vous gagnerez peut être à faire ce filtrage des mots parasites sous la forme d'un service WCF utilisé à la fois par vos application et par les WebParts.

    Pour savoir comment créer une feature SharePoint, vous pourrez vous référer à la page Working with Features du MSDN.

    Sébastien PICAMELOT - http://blogs.developpeur.org/gribouillon
    vendredi 26 février 2010 14:57
    Modérateur
  • Merci, je vais m'empresser de tester votre réponse et vous informerai du résultat.

    Cordialement,
    vendredi 26 février 2010 15:31