Archives des articles tagués search

john ross.

Few things in this world go together better than peanut butter and jelly. It’s a proven fact by the 3 people I’ve personally surveyed.  When Microsoft announced SharePoint Server 2013 the piece that I was the most excited about was the new Web Content Management (WCM) functionality.  Why am I so excited?  Read on and I’ll explain.

Search Driven Content Management

In the past the way we’d always thought about planning a WCM project hinged on where we put our content in SharePoint then we tagged it with metadata and surfaced it with things like the Content Query Web Part (CQWP). Moving forward with SP2013 the FAST search engine has now been fully integrated into SharePoint and it will be the primary engine driving WCM.  This is a game changer for a number of reasons:

  • Search has always been a great way to get content from across the farm.  Since the CQWP…

View original post 1 281 mots de plus

Publicités

Pourquoi cette question de la distance sociale ?

C’est vrai, pourquoi se poser tant de questions ? Dans SharePoint, vous rencontrez la notion de distance sociale à différents niveaux.

De manière explicite et visible, lorsque vous effectuez une recherche sur les personnes, SharePoint vous propose de trier les résultats de recherche selon la « Distance Sociale » :

De manière implicite, la notion de distance sociale intervient aussi dans différents processus, particulièrement de recommandation et de ranking. Il est donc intéressant de s’y attarder quelque peu et de l’expliciter.

Un peu de théorie

Si l’on s’en tient à la définition de Wikipedia, la distance sociale est une notion essentiellement sociologique :

« Social distance describes the distance between different groups of society and is opposed to locational distance. The notion includes all differences such as social class, race/ethnicity or sexuality, but also the fact that the different groups do not mix. The term is often applied in cities, but its use is not limited to that. »

Pour aller plus loin :

En tant que transposition virtuelle des modèles et processus du monde réel, les réseaux sociaux font abondamment référence à cette notion. Je vais tenter de l’expliciter…
Dans les faits, pour mesurer la distance sociale entre des groupes ou individus, plusieurs échelles peuvent être utilisées et parfois combinées. On trouvera entre autre :

  • Les degrés de séparation
  • Les degrés de proximité ou de similarité

Mais ces deux échelles représentant des réalités très différentes qu’il convient d’appréhender.

Les degrés de séparation

Rendue célèbre par l’expérience des 6 degrés de séparation, cette expression de la distance sociale est mesurée en déterminant le chemin le plus court entre deux individus dans le réseau constitué par leurs contacts directs.
Par exemple, dans la représentation graphique ci-dessous, les individus A et B sont à une distance de 6 :

Ce système est utilisé par exemple dans les réseaux sociaux comme LinkedIn ou Viadeo pour envoyer une demande de mise en relation entre deux individus qui ne se connaissent pas encore, en transmettant la demande à tous les contacts intermédiaires.

A titre anecdotique, l’expérience des 6 degrés de séparation a prouvé que deux individus, pris totalement au hasard dans la population mondiale, sont au maximum à une distance de 6. Ces résultats ont d’ailleurs été confirmés par Microsoft sur la base d’une étude à grande échelle menée anonymement sur utilisateurs de Windows Live Messenger : http://www.washingtonpost.com/wp-dyn/content/article/2008/08/01/AR2008080103718_pf.html

Mais cette expression de la distance sociale n’est que partielle et ne reflète pas certains facteurs comme “nous avons les mêmes centres d’intérêts” ou “nous travaillons dans le même secteur d’activité”, il était donc nécessaire d’introduire un autre outil de mesure.

Les degrés de similarité

La problématique de la similarité, par nature floue et non binaire, est pourtant traitée par l’informatique dans de nombreuses situations.
Par exemple, les moteurs de recherche tels que Bing ou Google utilisent ces systèmes de comparaison de mots pour proposer des corrections automatiques à des fautes de frappe :

Dans ces cas « simples », deux valeurs sont comparées puis on leur attribue une note de similarité sur une échelle donnée. Mais pour comparer des contenus plus complexes, comme un document bureautique, une page Web ou un profil utilisateur, de multiples facteurs entrent en jeu.

De nombreux algorithmes de calcul et de ranking de similarité existent, un des plus courants étant la distance de Levenshtein.

Sans trop vouloir rentrer dans le détail, on peut par exemple transposer ces algorithmes à des profils utilisateurs traités comme des documents. Ils sont tout d’abord transposés sous forme d’espaces vectoriels afin d’être manipulables mathématiquement, puis traités selon des algorithmes de ranking tels que le Okapi BM25.

Un autre exemple concret avec la “iTunes Genius Bar”, qui élabore des playlists musicales à partir des morceaux de votre bibliothèque qui se ressemblent, ou que des utilisateurs « similaires » ont acheté :

Pour cela, iTunes utilise notamment :

  • Les artistes classés dans le même genre musical
  • Les musiques communes à d’autres playlists
  • Les données anonymes d’autres utilisateurs
  • La base des achats de l’iTunes Store

L’approche mixte

Pourquoi comparer des profils dans les réseaux sociaux ? Simplement pour créer un moteur de recommandation et ainsi mettre en relation des utilisateurs présentant des points communs. Certes plus complèxe que d’utiliser un seul système, la démarche mixte (séparation + similarité) peut par exemple prendre en compte :

  • La proximité des intérêts
  • Le maillage complet et explicite des contacts

Par exemple dans Facebook avec l’application “People you may know”, qui propose notamment les “contacts de mes contacts” (FOAF pour Friend Of A Friend) ainsi que les profils similaires, par exemple travaillant dans la même société :

Les applications pratiques dans SharePoint

Les moteurs de recommandation

De manière similaire à FaceBook, SharePoint propose au travers de la fonction “Suggested Colleagues” des recommandations de personnes à suivre ou à inviter dans une communauté :

Il utilise pour cela un moteur de recommandation basé entre autres sur la notion de distance sociale.

De la même manière, avec l’introduction dans SharePoint 2013 de la possibilité de « suivre » un document (de s’y abonner), SharePoint peut désormais vous recommander des documents similaires, ou que d’autres utilisateurs proches suivent également :

Le « ranking » de résultats

Autre application de la distance sociale, l’ordonnancement des flux d’information et des résultats de recherche :

Ainsi lorsque vous consultez des résultats de recherche triés par distance sociale, un traitement complémentaire des résultats est utilisé pour les regrouper par priorité :

  1. Les premières pages selon la distance relative des collègues associés aux contenus (Collègues, Collègues de vos collègues puis tout le monde)
  2. Dans chacun de ces groupes, les résultats sont triés par pertinence
  3. Puis le système de regroupement s’applique à nouveau sur les pages suivantes
Cela peut sembler simple, mais les algorithmes de ranking sont particulièrement complexes, et peuvent faire intervenir un très grand nombre de critères de multiples natures :
  • Statiques et dynamiques
  • Degrés de séparation / Similarité directe
  • Similarité sémantique
  • Similarité sonore, particulièrement utile pour les recherche de noms de personnes dont on ne connait pas l’orthographe exacte… (Voir la fonction SQL SoundEx : http://en.wikipedia.org/wiki/Soundex)
  • Utilisation des centres d’intérêts pour pondérer les critères de recherche

Pour aller plus loin, vous trouverez plus d’informations sur la configuration du moteur de recherche de SharePoint 2013 dans cette vidéo.

Conclusions

Comme vous avez pu le constater, cette notion de distance sociale est partout et influence bon nombre des applications que nous utilisons quotidiennement. C’est un des apports majeur du social computing, et c’est particulièrement vrai pour SharePoint 2013 puisque les intéractions sociales sont démultipliées (Follow, Tag, Posts…).

Si le sujet vous intéresse, voici quelques références bibliographiques complémentaires pour étancher votre soif de connaissances :

Lors de ma dernière session de présentation à l’UGSF, et dans cet article sur la recherche SharePoint pour le marketing et la CRM, nous avions présenté plusieurs modes d’intégration possibles de la recherche SharePoint 2010 avec Twitter.
Je vais ici vous présenter de manière détaillée deux modes d’intégration et leurs implémentations respectives, mais avant, un petit rappel simple sur le fonctionnement de base du moteur de recherche de SharePoint.

L’indexation des sources de contenus

Il s’agit ici du mode de fonctionnement classique de SharePoint. Il est configurable depuis l’administration centrale :

Dans cet exemple, plusieurs sources de contenus sont définies :

  • Les sites SharePoint (C’est la moindre des choses !)
  • Un site Web
  • Une base de données métier (Ici une CRM)

En somme, à une fréquence définie (et configurable), le moteur de recherche SharePoint va lire l’ensemble de ces contenus (les crawler), les indexer (en extraire les informations, les formater…), puis les rendre accessibles au travers de ses écrans de recherche, par exemple ici une recherche sur un site Web :


Pour ce faire, SharePoint utilise des connecteurs paramétrables qui lui permettent d’accéder à différentes sources de données, notamment :

  • Sites SharePoint
  • Sites Web
  • Partages réseau
  • Dossiers publics Exchange
  • Applications métiers
  • Source personnalisée

Vous retrouvez ces options depuis le formulaire de création d’une nouvelle source de contenus :


On peut même développer ses propres connecteurs, qui seront alors accessibles depuis l’option « Custom Repository »… Mais alors pourquoi ne pas indexer directement Twitter avec un connecteur spécifique ?

  • D’abord parce que Twitter n’est pas en soit une source de données accessible pour l’indexation du fait de limitations techniques (nombre de requêtes…)
  • Surtout parceque votre index serait démesurément grand ! En général un index représente 30% de la taille du contenu original…

Il y a en réalité deux options viables pour intégrer ce type de média :

  • Par fédération
  • Par API

La fédération de moteurs de recherche

Cette première option consiste à utiliser le mécanisme de fédération présent dans le moteur de recherche SharePoint.

Pour être tout à fait complet, cette option est disponible nativement pour SharePoint Server (Standard et Enterprise) et par intégration de Search Server pour SharePoint Foundation.
En quelques mots, la fédération consiste à déléguer le travail de crawling et d’indexation à un moteur de recherche distant, puis à l’appeler pour récupérer les résultats lorsqu’une recherche est déclenchée par un utilisateur.

Voici un exemple de fédération du moteur de recherche Bing dans SharePoint :


Donc dans notre exemple, nous allons faire appeler le moteur de recherche de Twitter par celui de SharePoint.
Pour ce faire, naviguez jusqu’à l’écran de gestion du moteur de recherche SharePoint, sélectionnez « Federated location » dans le menu puis cliquez sur « New location » :

Renseignez les différents champs informatifs :

Puis renseignez ces valeurs dans les champs de la zone « Location information » :

  • Location type : OpenSearch 1.0/1.1
  • Query Template : http://search.twitter.com/search.atom?q={searchTerms}
  • « More results » link template : http://search.twitter.com/search?q={searchTerms}

Vous avez défini une fédération c’est bien… Mais afin de faire apparaître les résultats dans vos pages de recherche, vous allez devoir les configurer.

Pour ce faire, exécutez une recherche sur votre SharePoint, puis depuis la page de résultats, dans le menu « Actions du site », cliquez sur « Modifier la page » :

Cliquez dans une zone de la page sur « Ajouter un composant WebPart » :

Puis sélectionnez une Web Part « Résultats fédérés » dans la catégorie « Rechercher » :

Cliquez sur « Ajouter », puis utilisez la fontion « Modifier le composant WebPart » :

Dans la liste « Emplacement », sélectionnez « Twitter » puis cliquez sur « OK »

Enregistrez et publiez vos modifications (Menu Actions du site \ Publier ) :

Relancez une recherche et admirez le résultat 😉

A noter que le présentation des résultats (Layout, styles…) est personnalisable via XSL.

Comme vous l’avez constaté pendant la configuration, cette méthode repose sur le protocole OpenSearch, vous trouverez des informations détaillées et les dernières spécifications à cette adresse :

http://www.opensearch.org

D’autres moteurs sont accessibles au travers de ce protocole, et Microsoft propose en téléchargement les fichiers de configuration de plusieurs médias à cette adresse :

http://technet.microsoft.com/en-us/sharepoint/ff727944/

Une fois téléchargés, vous pouvez les importer depuis l’écran de gestion des fédérations en utilisant la fonction :

L’intégration applicative par API

Cette seconde option consiste à utiliser les API Search de Twitter pour effectuer les requêtes et afficher les résultats dans vos pages.

La manière « lourde »

La manière « lourde » consisterait à effectuer une intégration serveur complète entre SharePoint et Twitter (Identification via oAuth, utilisation d’une query de recherche, formatage des résultats via un template…). Cette option est tout à fait réalisable, et vous trouverez des exemples pratiques pour différentes plateformes et langages en consultant le SDK à cette adresse :
https://dev.twitter.com/docs/using-search

Bien que très souple, cette solution et aussi assez complexe et réservée aux développeurs. Je vous propose donc une solution alternative plus accessible.

La manière « légère »

Ce que je vous propose ici est blen plus léger, et consiste à intégrer dans vos pages un widget fourni par Twitter, et à le configurer pour afficher les résultats souhaités.
Les plus pointilleux me feront remarquer qu’il ne s’agira pas d’une recherche sur les tweets du passé, mais d’un filtre sur les messages en temps réel. C’est vrai, mais l’idée de l’usage de ce widget est justement d’obtenir un instantané des conversations en cours, pas d’obtenir un cliché du passé.

Cette méthode se décompose en 3 étapes :

  1. Obtenir et configurer le widget original Twitter
  2. Modifier le widget pour lui transférer les paramètres de recherche SharePoint
  3. Intégrer le widget modifié à vos pages de recherche SharePoint

1. Obtenir et configurer le widget original Twitter

Commencez par configurer votre widget depuis cette adresse :
https://twitter.com/about/resources/widgets/widget_search

Depuis cet écran, pensez surtout à personnaliser les couleurs des bordures et du texte afin qu’elles correspondent à la charte graphique de votre plateforme SharePoint :


Et ne vous occupez pas de la zone « Search query » pour l’instant, nous définirons plus tard sa valeur.

Une fois vos personnalisations réalisées, cliquez sur « Finish & Grab code », puis copiez le code généré.

Observons ce code :

On constate qu’il est composé de deux blocs :

  • La première ligne ne fait que charger dans la page le script « Widget.js » depuis les serveurs de Twitter.
  • Le reste du code crée une instance d’un objet « Widget » du namespace « TWTR » avec certains paramètres.

2. Modifier le widget pour lui transférer les paramètres de recherche SharePoint

Si vous observez vos pages de recherche SharePoint, vous constaterez que les paramètres de recherche sont transmis via l’URL sous cette forme :

http://monserveur/sites/search/Pages/results.aspx?k=MARECHERCHE

Voici donc une légère modification du script original, qui va simplement, au chargement de la page de résultats de recherche, lire la valeur « MARECHERCHE » du paramètre « k » dans l’URL, puis la passer à l’attribut « search » du widget :

Pour aller plus loin, vous pouvez aussi configurer le widget pour qu’il utilise des opérateurs de recherche avancés.

Consultez le SDK Twitter au besoin :
https://support.twitter.com/articles/71577

3. Intégrer le widget modifié à vos pages de recherche SharePoint

Maintenant que vous avez configuré et modifié votre widget, vous allez pouvoir l’intégrer à votre page de recherche.

Mais vu que je suis d’un naturel gentil, altruiste et généreux (oui pas tout le temps je sais ;-)), voici de quoi intégrer twitter plus rapidement…

J’ai simplement packagé le widget avec les modifications nécessaires pour qu’il puisse être importé directement dans vos pages de recherche SharePoint.

Commence  par télécharger ce fichier : Twitter Widget for SharePoint Search (DWP)
Il contient une Web Part déjà configurée avec tout le code nécessaire.

Vous n’avez plus qu’à ouvrir votre page de résultats de recherche puis passer en mode édition par le menu « Actions du site » :

Ouvrir le menu d’ajout d’une Web Part :

Importer le fichier précédemment téléchargé :

Cliquez sur télécharger puis sélectionnez la Web Part importée :

Sauvegardez et publiez vos modifications :

Et oh miracle ! Votre page de résultats de recherche SharePoint et Twitter fonctionne !

Bilan

La solution du fichier DWP est pratique pour tester le fonctionnement finalisé, mais vous devrez utiliser une autre méthode plus industrialisée pour passer en production. En quelques mots :

  1. Enregistrer le script JS dans un fichier dédié
  2. Publier ce fichier sur une URL accessible (SharePoint ou non), par exemple dans une bibliothèque SharePoint, le dossier « Layout »…
  3. Référencer ce script dans une « Content Editor Web Part » (CEWP) et la positionner sur la page de recherche (Déploiement par script…)
Si vous m’en faites la demande, je pourrai publier une procédure détaillée de mise en production à l’occasion.

J’espère que cet article vous a intéressé, n’hésitez pas à me solliciter si vous rencontrez des problèmes dans la mise en oeuvre de cette solution !

Notre présentation

Vous trouverez ci-dessous les supports de la présentation que j’ai eu l’honneur de donner lors de la dernière session du club UGSF chez Microsoft le 21 juin 2012.

Je profite de cet article pour remercier Pierre Tatot, tant pour son dynamisme que pour son aide précieuse durant la préparation et l’animation de cette session.

Compléments d’information

Modération des résultats de recherche

Lors de cette session, la question de la possibilité de modérer les résultats des moteurs de recherche fédérés a été posée. L’idée étant d’appliquer un filtrage sur les contenus similaire à celui défini par cette option sur Bing.com :

Si la fédération repose sur OpenSearch, il doit être possible d’utiliser un attribut « Adult » dans l’URL du service, par exemple pour Bing :

http://search.live.com/results.aspx?q={searchTerms}&count={itemsPerPage}&first={startItem}&mkt={language}&format=rss&FORM=SHAREF

Plus d’informations : http://msdn.microsoft.com/en-us/library/dd251083

Mais la meilleure solution à mon sens consiste, si des besoins de customization importants sont exigés, à utiliser l’API Bing Search en lieu et place d’OpenSearch comme solution d’intégration et de fédération. Comme vous le constaterez dans la documentation de l’API, une propriété explicite « Adult » permet de contrôler ce comportement :

Les autres propriétés offrent par ailleurs bon nombre d’autres options intéressantes, comme la localisation des résultats.

Plus d’informations : https://datamarket.azure.com/dataset/5BA839F1-12CE-4CCE-BF57-A49D98D29A44

Licensing de Business Connectivity Services (BCS)

Lors de cette démonstration, nous avons utilisé les services BCS pour présenter les intégrations possibles grâce à BCS entre SharePoint et des applications distantes.
Côté licensing, et en résumé, voici les services disponibles dans chaque édition :
  • SharePoint Foundation : BCS + Page de profil (pour les résultats de recherche)
  • SharePoint Server Standard : SharePoint Foundation + Business Data Integration avec les Clients Office + Business Data Web Parts
  • SharePoint Server Enterprise : SharePoint Server Standard + Business Intelligence Center

Pour consulter le détail des services proposés par édition :

D’autres questions ? N’hésitez pas à me contacter !

A très bientôt pour la prochaîne session du club UGSF.