Offrir des possibilités de recherche complètes

breveté certains des algorithmes du moteur de recherche.

Les utilisateurs peuvent copier manuellement des documents existants dans la base de données de SharePoint Portal Server, mais cette méthode est bien trop longue lorsqu’il s’agit d’assembler les archives départementales. De plus, Microsoft ne fournit pas une méthode standard pour pointer SharePoint Portal Server sur un fileshare ou une autre source d’informations, puis copier les documents de cette source dans un espace de travail. L’avantage de déplacer les documents dans un espace de travail est que l’on peut ensuite utiliser les fonctions de gestion documentaire du serveur pour contrôler les documents. Toutefois, si l’on veut simplement rechercher des informations existantes (legacy), on peut laisser les documents sur le fileshare et pointer SharePoint Portal Server sur ces documents.

Inévitablement, des informations utiles sous de nombreux formats se retrouvent disséminés sur des serveurs Web, des fileshares, des dossiers publics d’Exchange 2000 et d’Exchange Server 5.5, des bases de données Lotus Notes et même d’autres machines SharePoint Portal Server. SharePoint Portal Server est livré avec de nombreux filtres pour différents types de fichiers (.doc, .html, .tiff, .txt, par exemple). Ces filtres permettent au serveur de créer des index provenant de diverses sources. (Toutefois, on ne peut pas rechercher ou indexer des boîtes à  lettres sur des serveurs Exchange Server ou Lotus Notes). Les fournisseurs tiers peuvent créer des filtres pour des types de fichiers propres à  chaque fournisseur ; par exemple, Adobe Systems offre un filtre .pdf et Corel offre un filtre WordPerfect. Vous pouvez même utiliser le SDK (Software Development Kit) de SharePoint Portal Server pour écrire votre propre filtre. (Pour plus d’informations sur l’utilisation de SDK, visiter le site http://www.microsoft.com/sharepoint/downloads/tools/sdk.htm.)

Les index de SharePoint Portal Server sont sûrs. Autrement dit, si l’on n’a pas l’autorisation de voir un document, il n’apparaîtra pas dans un résultat de recherche même s’il répond aux critères de recherche.

Mettre des données dans un référentiel et les en retirer sont deux tâches très différentes. Il est souvent difficile d’obtenir une vue globale de l’énorme quantité d’informations présentes sur le réseau d’une société. La solution de SharePoint Portal Server consiste à  créer un point d’accès (c’est-à -dire le portail) à  des informations rassemblées en provenance de multiples sources discrètes. Tout le monde connaît les crawlers Web (AltaVista, par exemple) et les problèmes que soulève l’assemblage d’informations par cette technique. Si l’on demande à  un moteur de recherche de trouver des documents sur un sujet tel que Win2K, on est sûr de trouver beaucoup plus d’éléments qu’on ne peut traiter ; même une recherche raffinée ne trouvera pas forcément les informations dont on a vraiment besoin. Si l’on ajoute à  cela les liens obsolètes ou absents, la pratique du crawling peut s’avérer très frustrante.

Les deux modes de crawling, celui de SharePoint Portal Server et celui du Web, sont différents à  deux égards. Premièrement, le produit peut combiner des informations provenant de nombreuses sources différentes, y compris des sites Web externes et internes. Le fait de pouvoir agréger des informations provenant des fileshares de réseau, des dossiers publics d’Exchange Server, des bases de données de Lotus Notes et de sites Web, le tout en une seule opération de recherche, est une fonction puissante. SharePoint Portal Server supporte différents types de comportements de crawling – programmé (scheduled), à  incrémentation rapide, à  base de notification, et adaptatif – pour maîtriser toute l’activité de crawling qui se produit. (Le crawling adaptatif utilise des modèles de volatilité de documents – c’est-à -dire la fréquence avec laquelle le contenu des documents est supposé changer – pour réduire le temps passé à  indexer des documents périmés.)

Deuxièmement, la technologie d’indexation de SharePoint Portal Server classe les données en catégories bien mieux que ne le font les crawlers Web. Le produit serveur utilise la support vector machine categorization, un terme compliqué pour dire catégorisation automatique. Quand on fournit à  SharePoint Portal Server un document bien structuré qui utilise les styles et les propriétés pour présenter son contenu, la fonction Category Assistant du serveur peut s’instruire à  partir de la structure du document, puis catégoriser automatiquement d’autres documents de structures similaires. Ainsi, les whitepapers sur le site Web MSDN (Microsoft Developer Network) suivent un format particulier. Une fois que SharePoint Portal Server a appris la structure d’un whitepaper MSDN à  partir d’un exemple, le produit pourra reconnaître les autres whitepapers qu’il rencontrera. Pour que ce concept soit intéressant, il faut bien entendu que l’utilisateur soit discipliné dans sa structuration de document.

A noter que le crawling n’extrait pas des données pour les placer dans la base de données de SharePoint Portal Server. Tout comme les crawlers Web, SharePoint Portal Server note l’emplacement et le contenu d’une donnée puis stocke cette information. SharePoint Portal Server ne stocke des documents réels que quand on les charge explicitement dans un espace de travail documentaire.

SharePoint Portal Server utilise une version modifiée du moteur de recherche livré avec Exchange 2000 et Microsoft SQL Server 2000, pour accepter des fonctions comme Category Assistant et Best Bets. Cette dernière fonction aide les utilisateurs à  trouver les documents se rapprochant le plus de leurs besoins. Un Best Bet résulte souvent d’une correspondance directe entre un critère de recherche et un mot-clé créé sur un document. Ainsi, si on utilise le mot réplique comme mot-clé pour un whitepaper, SharePoint Portal Server présentera le whitepaper comme Best Bet à  quiconque cherche « réplique ».

Comme il est peu efficace de maintenir plusieurs moteurs de recherche (pour Exchange Server, SharePoint Portal Server et SQL Server, par exemple), Microsoft combinera probablement à  l’avenir les moteurs dans un seul service système. Sans toutefois préciser la date de cette combinaison.