Blogabriel

L’AFISI organisait la semaine dernière une conférence sur les réseaux sociaux. L’approche n’était pas celle des conférences habituelles … que je ne veux pas dénigrer par ailleurs. Les conférenciers ont présentés des aspects peu abordés (dont le droit, le développement durable) qui ont donné son originalité et son intérêt à l’événement.

J’y ai contribué en présentant « quelques repères philosophiques ». Les slides sont disponibles sur Slideshare. En quelques slides et une demi-heure, on ne peut qu’ébaucher un sujet aussi vaste. A côté de Martin Heidegger, de Paul Ricoeur, j’aurai bien développé aussi à partir de la pensée d’Emmanuel Lévinas. Le visage de l’autre prend chez lui une dimension qui nous invite à la responsabilité … le parallèle avec la personne exposée par les réseaux sociaux me semble très riche. Le philosophe est mort en 1995, au moment où nait le web public. Je suis persuadé qu’il aurait écrit des pages intéressantes …

Les réseaux sociaux (rs) se partagent l’audience mondiale avec les moteurs de recherche (mr). Au top 10 des sites les plus visités[1] se trouvent par ordre décroissant : Google (mr), Facebook (rs), Youtube (rs), Yahoo ! (mr), Windows live (mr), Baidu (mr), Wikipedia (rs), Blogger (rs), MSN (mr) et Twitter (rs). Soit 5 de chaque catégorie.

La bipartition au sommet de la popularité Internet entre moteurs de recherche et réseaux sociaux motive l’apparition de nouveaux sites aux usages ajustés. Citons en deux : l’immédiateté et la proximité.

Immédiateté. Puisque les internautes et les mobinautes ont un rapport de plus en plus immédiat avec le Web grâce aux réseaux sociaux où publier se fait à la vitesse du clic, leur besoin de recherche suit la même tendance. Ils veulent trouver jusqu’aux informations publiées et diffusées les plus récentes. Des moteurs d’un nouveau type apparaissent pour répondre à cette demande, ce sont les moteurs en temps réels[2] dont les nouvelles exigences sont la vitesse d’actualisation et la segmentation des sources sociales (réseaux, blogs, sites d’information etc.).

Proximité. Avec les progrès de la géolocalisation, les moteurs ont acquis une autre dimension sociale : ils ont appris à répondre au plus près de l’utilisateur ou de ses contacts.

Nous assistons à des tentatives répétées pour faire converger les moteurs de recherche et les réseaux sociaux. Qu’est-ce que cela va donner ? Google essaie de pénétrer de force le monde des réseaux sociaux. Mais le géant a jeté l’éponge pour Wave. L’outil de communication collaboratif n’a pas eu le succès attendu : « Wave n’a pas eu autant d’utilisateurs que nous l’aurions souhaité. » C’est la phrase que toute la presse a retenue de l’explication donnée par un responsable de la société. Google s’est aussi fait rappeler à l’ordre pour Buzz par un collège international d’autorités de type CNIL. Les réseaux qui marchent sont des succès inattendus. En 2004, un étudiant de 20 ans crée thefacebook.com dans sa chambre à Harvard. Et deux semaines plus tard, les 2/3 de l’école s’inscrivent. Six ans plus tard, plus d’un demi-milliard de comptes ont été ouverts sur le site. Google a la mémoire courte, son moteur est lui aussi un succès inattendu.

Je ne crois pas le vainqueur du rapprochement search et réseau social soit un acteur significatif de ces deux mondes. Je vote pour un nouvel entrant qui émergera à la suite d’un succès inattendu.

Je suis sûrement comme plusieurs d’entre vous un lecteur attentif des analyses du Gartner. Alors quand j’ai découvert la page où le célèbre cabinet publie la liste des accès Twitter de l’ensemble de ses analystes, je me suis jeté dessus. Vous auriez fait pareil.

Ils sont 85 analystes à être présents dans cette page. Je me suis amusé à faire des statistiques sur l’usage de Twitter que font les analystes. Je vous livre ici quelques résultats étonnants.

Nombre de personnes que les analystes écoutent

• 54 analystes représentent 10 % de l’écoute globale du Cabinet et 31 représentent 90 %
• Les 5 analystes les plus écoutants représentent 49.4 % – ils font respectivement 6.3 % – 6.8 % – 9.4 % – 13.3 % et 13.4 %

On aurait pu penser que les analystes de Gartner seraient plus attentifs à ce qui se dit dans le réseau le plus actif du Web 2.0. La moitié de l’écoute globale du Gardner est faite par 5 analystes sur 85.

Nombres de personnes qui écoutent les analystes

• 25 analystes représentent 10 % des écoutés et 60 représentent 90 %
• Les 17 analystes les plus écoutés représentent 50.2 %
• Les 5 plus écoutés font respectivement 3.9 % – 4.3 % – 4.3 % – 4.8 % et 5.0 %

60 des 85 analystes du Gartner sont très écoutés avec un score cumulé de 90 %. En revanche, 25 analystes sont à peine écoutés. Parmi ces derniers, il y a bien entendu les analystes qui ont décidé de masquer leurs twitts. La moitié de l’écoute du Gartner est le fait des publications des 17 analystes les plus productifs.

Nombres d’analystes qui figurent dans des listes

• 27 analystes représentent 10 % de la présence du Gartner dans des listes et 58 représentent 90 %
• Les 15 analystes les plus présents représentent 49.5 %
• Les 5 plus présents font respectivement 4.0 % – 4.3 % – 4.6 % – 5.4 % et 7.3 %

Les résultats de la présence dans des listes est assez conforme à l’écoute, voir juste au-dessus.

Nombres de twitts publiés par des analystes

Pour m’essayer concrètement au web des données, j’ai publié mon fichier FOAF. Il est ici.

Pour valider sa syntaxe, sa conformité RDF, on peut utiliser le Validator du W3C. Le résultat peut prendre la forme de triples validés et/ou de graphe.

Dans toutes les pages de ce blog, on trouve la ligne suivante dans le header :

 <link rel="meta" type="application/rdf+xml" title="FOAF" href="http://www.kepeklian.com/sem/foaf.rdf" />

Ca permet aux plugin sémantiques de Firefox de se déclencher.

Voici quelques outils qui permettent de visualiser les données liées :

* captsolo
* Talis

Twitter propose un accès FOAF.

Voici la 7e partie de ma traduction du fameux tutorial  » How to Publish Linked Data on the Web? « écrit par Chris Bizer (Web-based Systems Group, Freie Universität Berlin, Germany), Richard Cyganiak (Web-based Systems Group, Freie Universität Berlin, Germany) et Tom Heath (Knowledge Media Institute, The Open University, Milton Keynes, UK).

7. Recettes pour exposer des informations sous la forme de données liées

Ce chapitre fournit des recettes pratiques pour la publication de différents types d’informations sous la forme de données liées. Les informations doivent remplir au moins les conditions suivantes pour être considérées comme « publiées en tant que données liées sur le Web » :

• Les choses doivent être identifiées avec des URI HTTP déréférenceables.
• Si un tel URI est déréférencé en demandant un type MIME application/rdf+xml, une source de données doit retourner une description RDF/XML de la ressource identifiée.
• les URI qui identifient les ressources non-informatives doivent être créés de l’une de manières qui suit : soit la source de données doit renvoyer une réponse HTTP 303 qui contient une redirection HTTP vers une ressource d’information décrivant la ressource non-informative, tel que discuté précédemment dans le présent document. Ou l’URI de la ressource non-informative doit être obtenue en prenant l’URI de la ressource d’information et en ajoutant un fragment d’identifiant (#foo, par exemple), tel que discuté dans la recette 7.1.
• Outre les liens RDF aux ressources d’une même source de données, des descriptions RDF devraient également contenir des liens RDF vers des ressources fournies par d’autres sources de données, de sorte que les clients puissent naviguer sur le Web de données dans son ensemble en suivant les liens RDF.

Parmi les recettes suivantes, lesquelles correspondent à vos besoins ?

• Quelle quantité de données voulez-vous servir ? Si vous voulez seulement de publier plusieurs centaines de triplets RDF, vous voudrez peut-être les servir dans un fichier RDF statique en utilisant la Recette 7.1. Si votre ensemble de données est plus grand, vous pourrez vouloir le charger dans un magasin RDF (en anglais : RDF store) propre et mettre le Pubby Linked Data Interface en face de celui-ci tel que décrit dans la recette 7.3.
• Comment vos données sont-elles actuellement stockées ? Si vos informations sont stockées dans une base de données relationnelle, vous pouvez utiliser D2R Server comme indiqué dans la recette 7.2. Si l’information est accessible via une API, vous pourriez mettre en œuvre un wrapper autour de cette API comme décrit dans la recette 7.4. Si votre information est représentée dans un autre format tel que Microsoft Excel, CSV ou BibTeX, vous devrez d’abord le convertir en RDF comme décrit dans la recette 7.3.
• Combien de fois vos données doivent-elles changées ? Si vos données changent fréquemment, vous préférez les approches qui peuvent générer des vues sur vos données RDF, tels que D2R Server (Recette 7.2), ou les wrappers (Recette 7.4).

Après avoir publié vos informations sous forme de données liées, vous devez vous assurer qu’il y a des liens RDF externes pointant vers des URI de votre ensemble de données, de sorte que les navigateurs RDF et les robots puissent trouver vos données. Il existe deux méthodes de base pour y parvenir :

1. Ajouter plusieurs liens RDF à votre profil FOAF qui pointent des URI identifiants des ressources centrales de votre dataset. En supposant que quelqu’un dans le monde vous connaisse et note votre profil FOAF, votre nouvel ensemble de données sera désormais accessible via des liens RDF.
2. Convaincre les propriétaires de sources de données liées d’auto-générer des liens RDF vers des URI de votre dataset. Ou pour faciliter les choses pour le propriétaire d’un autre ensemble de données (en anglais dataset), créez des liens RDF vous-même et envoyer les lui, il ne lui plus qu’à les fusionner avec son ensemble de données. Un projet qui est extrêmement ouvert à la création de liens vers d’autres sources de données RDF est le projet communautaire DBpedia. Il suffit juste d’annoncer votre source de données sur la liste de diffusion DBpedia ou d’envoyer un ensemble de liens RDF à la liste.

7.1 – Servir des fichiers statiques

La plus simple façon de servir les données liées est de produire des fichiers RDF statiques et les télécharger sur un serveur web. Cette méthode est généralement choisie dans les situations où

• les fichiers RDF sont créés manuellement, par exemple lors de la publication personnelle fichiers FOAF ou de vocabulaires RDF ou
• les fichiers RDF sont produits ou exportés par un bout de logiciel qui n’a que des sorties fichiers.

Il y a plusieurs aspects à considérer :

Configuration du serveur pour des types MIME correct

Les anciens serveurs Web ne sont parfois pas configurés pour renvoyer le bon type MIME lorsqu’ils doivent servir des fichiers RDF/XML. Les navigateurs de données liées peuvent ne pas reconnaitre les données RDF servies de cette façon parce que le serveur fait valoir que ce n’est pas RDF/XML, mais du texte brut. Pour savoir si votre serveur a besoin d’une correction de ce problème, utilisez l’outil cURL et suivez les étapes décrites dans ce tutoriel.

La façon de réparer cela dépend du type de votre serveur web. Dans le cas d’Apache, ajoutez cette ligne au fichier de configuration httpd.conf, ou à un fichier. Htaccess dans le répertoire du serveur web où les fichiers RDF sont placés :

AddType application/rdf+xml .rdf

Cela indique à Apache de servir les fichiers ayant une extension .rdf en utilisant le bon type MIME pour RDF/XML, à savoir application/rdf+xml. Remarque, cela signifie que vous avez nommer vos fichiers avec l’extension .rdf.

Pendant que vous y êtes, vous pouvez également ajouter ces lignes pour faire en sorte que votre serveur web soit prêt pour d’autres syntaxes RDF (N3 et Turtle) :

AddType text/rdf+n3;charset=utf-8 .n3
AddType application/x-turtle .ttl

Taille du fichier

La publication de pages HTML de très grandes tailles n’est pas recommandée, car elles se chargent très lentement dans les navigateurs et consomment inutilement de la bande passante. La même chose est vraie quand il s’agit de publication de données liées : vos fichiers RDF ne devraient pas être plus grand que, disons, quelques centaines de kilo-octets. Si vos fichiers sont plus volumineux et décrivent de multiples ressources, vous devez les diviser en plusieurs fichiers RDF, ou l’utilisation Pubby tel que c’est décrit dans la recette 7.3 et ainsi les servir par morceaux.

Lorsque vous servez plusieurs fichiers RDF, assurez-vous qu’ils sont liés les uns aux autres par le biais de triplets RDF qui impliquent des ressources décrites dans les différents fichiers.

Le choix des URI pour les ressources non-informatives

L’approche de fichiers statiques ne supporte pas les 303 redirections nécessaires pour les URI des ressources non-information. Heureusement il existe une autre méthode conforme aux normes de nommer les ressources non-information, qui fonctionne très bien avec les fichiers statiques RDF, mais a un inconvénient, nous discuterons plus tard. Cette méthode est fondée sur les URI avec dièse.

Lorsque vous servez d’un fichier statique RDF à, disons, http://example.com/people.rdf, vous devez alors le nom de la non-information sur les ressources décrits dans le fichier en ajoutant un identificateur de fragment d’URI du fichier. L’identifiant doit être unique dans le fichier. De cette façon, vous vous retrouvez avec des URI comme cela pour votre non-ressources d’information :

• http://example.com/people.rdf#alice
• http://example.com/people.rdf#bob
• http://example.com/people.rdf#charlie

Cela fonctionne parce que les clients HTTP déréférencent les URI avec dièse en séparant la partie qui suit le dièse et en déréférençant l’URI résultant. Un navigateur de données liées va ensuite se scruter la réponse (le fichier RDF dans ce cas) et trouver des triplets qui en disent plus sur la ressource non-informative, obtenant ainsi un effet assez similaire à la redirection 303.

L’inconvénient de cette approche est que le nommage des URI n’est pas très « cool » au sens des critères énoncés dans la section 3. Il y a une référence à un format de représentation spécifique dans les identifiants (l’extension .rdf). Et si plus tard vous décidez de renommer le fichier RDF, ou si vous décidez de diviser vos données en plusieurs fichiers, alors tous les identifiants changeront et les liens existants casseront.

C’est pourquoi vous ne devriez utiliser cette approche que si la structure globale et la taille de l’ensemble de données ne risquent pas de changer beaucoup dans l’avenir, ou pour une solution temporaire pour des données transitoires où la stabilité des liens n’est pas si importante.

Extension de la recette pour des redirections 303 et la négociation de contenu

Cette approche peut être étendue pour utiliser des redirections 303 et même pour permettre la négociation de contenu, si vous êtes prêt à faire toutes sortes de gymnastique. Malheureusement, ce processus dépend de votre serveur web et de sa configuration. Le W3C a publié plusieurs recettes qui montrent comment faire avec un serveur web Apache : Best Practice Recipes for Publishing RDF Vocabulaires. Le document est officiellement destiné aux éditeurs de vocabulaires RDF, mais les recettes marchent aussi pour d’autres types de données RDF servies à partir de fichiers statiques. Notez qu’au moment d’écrire il reste un problème avec la négociation de contenu dans ce document qui pourrait être résolu en passant le serveur Apache du mode mod_rewrite à celui de mod_negotiation.

7.2 – Servir des bases de données relationnelles

Si vos données sont stockées dans une base de données relationnelle, c’est généralement une bonne idée de les y laisser et de publier uniquement une vue sur les données de votre base sous la forme de données liées.

Un outil qui permet de servir des vues de bases de données relationnelles sous forme de données liées est D2R Server. D2R Server repose sur un mapping déclaratif entre les schémas de la base et les termes RDF ciblés. Sur la base de ce mapping, D2R Server sert une vue de données liées sur votre base de données et fournit un endpoint SPARQL pour la base de données.

AddType text/rdf+n3;charset=utf-8 .n3
AddType application/x-turtle .ttl

Il existe plusieurs serveurs D2R ligne, par exemple Berlin DBLP Bibliography Server, Hannover DBLP Bibliography Server, Web-based Systems @ FU Berlin Group Server ou EuroStat Countries and Regions Server.

La publication d’une base de données relationnelles sous la forme de données liées comporte habituellement les étapes suivantes :

1. Téléchargez et installez le logiciel serveur comme indiqué dans la section Démarrage rapide de la page d’accueil D2R Server.
2. Ayez un D2R serveur pour générer automatiquement un mapping D2RQ à partir du schéma de votre base de données (voir Démarrage rapide).
3. Personnalisez le mapping en remplaçant les termes générés automatiquement par des termes de vocabulaires RDF bien-connus et accessibles au public.
4. Ajoutez votre nouvelle source de données dans la liste des ensembles de données du Wiki ESW dans la catégorie « données liées » et dans la liste « endpoint SPARQL », puis établissez plusieurs liens RDF à partir de votre profil FOAF vers des URI de ressources centrales au sein de votre nouvelle source de données afin que les robots puissent découvrir vos données.

Alternativement, vous pouvez aussi utiliser :

1. OpenLink Virtuoso pour publier votre base de données relationnelles à la façon de données liées.
   • Vues RDF de Virtuoso – Guide de démarrage sur la façon de mapper votre base de données relationnelle avec RDF et
   • Déploiement de données liées sur la façon d’obtenir un déréférencement d’URI et une négociation de contenu en place.
2. Triplify, un petit plugin pour les applications Web, qui révèle les structures sémantiques encodées dans les bases de données relationnelles en rendant le contenu disponible sous la forme de base de données RDF, JSON ou de données liées.

7.3 – Exposer d’autres types d’informations

Si vos informations sont actuellement représentées dans des formats CSV, Microsoft Excel, ou BibTeX et si vous voulez les servir comme des données liées sur le Web, voici des bonnes idées à réaliser dans ce qui suit :

• Convertissez vos données en RDF en utilisant un outil de RDFisation. Il y a deux endroits où de tels outils sont répertoriés : ConverterToRdf qui est mis à jour dans le wiki ESW, et RDFizers maintenu par l’équipe de SMILE.
• Après la conversion, stockez vos données dans un référentiel RDF. Une liste des référentiels RDF est maintenue dans le wiki ESW.
• Idéalement, le référentiel RDF choisi est accompagné d’une interface de données liées qui prend soin de rendre accessibles vos données Web. Comme de nombreux référentiels RDF n’ont pas encore implémenté des interfaces pour les données liées, vous pouvez également choisir un référentiel qui fournit un endpoint SPARQL et met à disposition Pubby comme interface de données liées en front de votre endpoint SPARQL.

L’approche décrite ci-dessus est entre autres adoptée par le projet DBpedia. Ce projet utilise des scripts PHP pour extraire des données structurées à partir de pages Wikipédia. Ces données sont ensuite converties en RDF et stockés dans un référentiel Virtuoso OpenLink qui fournit un endpoint SPARQL. Afin d’obtenir une vue sous forme de données liées, Pubby est placé en front pour exploiter l’endpoint SPARQL.

Si votre ensemble de données est de taille suffisamment petite pour s’adapter complètement dans la mémoire principale du serveur Web, alors vous pouvez vous passer d’un repository RDF, et utiliser l’option conf:loadRDF de Pubby pour charger les données RDF à partir d’un fichier RDF directement dans Pubby. Cela pourrait être plus simple, mais à la différence d’un dépôt réel RDF, Pubby tient tout en mémoire principale et ne propose pas d’endpoint SPARQL.

7.4 – Mise en œuvre autour des applications existantes ou des API Web

Un grand nombre d’applications Web ont commencé à rendre leurs données disponibles sur le Web au travers d’API Web. Des exemples de sources de données fournissant de tels API sont donnés par des entreprises comme eBay, Amazon, Yahoo, Google et Google Base. Une liste plus complète des API se trouve sur Programmable Web. Différentes API fournissent différentes requêtes et interfaces d’extraction et renvoient les résultats en utilisant un certain nombre de formats différents tels que XML, JSON ou ATOM. Ceci conduit à trois limitations générales des API Web :

• Leur contenu ne peut pas être exploré par les moteurs de recherche
• Les API Web ne peuvent être accédés à l’aide de navigateurs de données génériques
• Des Mashups ont été réalisés pour un certain nombre de sources de données et ne peuvent pas profiter des nouvelles sources de données qui apparaissent sur le Web.

Ces limitations peuvent être surmontées par la mise en œuvre de wrappers de données liées sur la base des API. En général, les wrappers de données liées procèdent comme ceci :

1. Ils assignent des URI HTTP aux ressources non-informatives pour lesquelles l’API qui fournit des données.
2. Lorsque l’un de ces URI est déréférencé en demandant un type application/rdf+xml, le wrapper réécrit la demande du client en une requête pour l’API sous-jacente.
3. Les résultats de la requête de l’API sont transformés en RDF et renvoyés au client.

Exemples de wrappers de données liées notamment :

Le RDF Book Mashup

Le RDF Book Mashup expose l’information sur les livres, leurs auteurs, les critiques et les librairies en ligne, et les rend disponible sous forme RDF sur le Web. Le RDF Book Mashup assigne un URI HTTP pour chaque produit qui a un numéro ISBN. Lorsque l’un de ces URI est déréférencé, le Mashup demande des données sur le livre, son auteur ainsi que des notes de lecture et des offres commerciales à l’aide des API d’Amazon et des API Google Base. Ces données sont ensuite transformés en RDF et retournés au client.

Le RDF Book Mashup est implémenté comme un petit script PHP qui peut être utilisé comme modèle pour la mise ou point d’autres wrappers similaires dans d’autres API Web. Vous trouverez plus d’information sur le Book Mashup et la relation entre les API Web et les données liées en général dans The RDF Book Mashup: From Web APIs to a Web of Data (diapositives).

Exporteurs SIOC pour WordPress, Drupal, phpBB

Le projet SIOC a développé des wrappers de données liées pour les moteurs de plusieurs blogs populaires, des systèmes de gestion de contenu et des forums de discussion. Voyez exporteurs SIOC pour une mise à jour la liste de leurs wrappers. Le projet fournit également un API d’exportation en PHP qui permet aux développeurs de créer d’autres outils d’export SIOC sans qu’il soit nécessaire d’entrer dans des détails techniques sur la façon dont l’information est représentée en RDF.

Virtuoso Sponger

Virtuoso Sponger est un cadre pour le développement de wrappers de données liées (appelés cartouches) autour de différents types de sources de données. La source de données peut varier depuis la page HTML contenant des données structurées jusqu’aux API Web. Voyez Injecting Facebook Data into the Semantic Data Web pour une démonstration sur la façon utilisée par Sponger pour générer une vue de données liées sur Facebook.

Même si vous êtes à San Francisco, vous pouvez suivre en direct le débat passionnant qui a lieu en ce moment à l’Atelier et qui est repris en direct par une foule de journalistes improvisés : les participants eux-mêmes qui pianotent sur Twitter pour livrer leurs impressions, leurs commentaires, leurs notes … tout un matériel brut de fonderie qui est très intéressant à livre au fur et à mesure des mises à jour automatique du navigateur.

Le tag #oubli a été retenu le 5 nov. par un petit échange sur Twitter et hop, c’est fait, c’est adopté par NKM (@nk_m) et Christian Bensi (@christianbensi). A 8h13, premier twitt sur la conférence et depuis, c’est le déluge (presqu’un millier de twitts à la fin de la conf) !

Plusieurs thèmes sont abordés et les commentaires affluent aussitôt. Rapidement, on peut lire une inquiétude chez certains : twitter ne garde pas la trace très longtemps de ce qui se twitte. C’est même carrément angoissant. Vous avez peut-être remarqué qu’on ne peut pas revenir longtemps en arrière pour une recherche donnée. La limite, actuellement d’à peu près un mois, est dynamique et peut donc changer. Si le nombre de tweets par jour ne cesse d’augmenter, Twitter oubliera encore plus vite !

A la fin de la conférence, un des participants fait la remarque suivante en s’adressant à @nk_m « Dommage que le hashtag #oubli n’ait pas été diffusé sur un écran pendant l’atelier ! » Voilà un oubli fâcheux !!! Dans le salle, on n’est pas au courant … et à des milliers de kilomètre, on a suivi la conférence. Voilà de l’ubi cuitée

Pour ceux qui voudront suivre et revivre les échanges, une solution existe. Comme Twitter oublie, les développeurs de http://www.flotzam.com/ ont créé l’outil The archivist. Bref, même si semblait que Twitter puisse oublier, ce n’est déjà plus possible. Et ce n’est pas de Twitter que vient l’outil.

Moralité : même quand tu oublies de faire quelque chose, il y aura toujours quelqu’un dans le grand web qui le fera pour toi.

Entre Twitter, 140 caractères au plus pour s’exprimer, et le livre, 140 pages au moins pour s’exprimer, il y a un rapport que l’esprit saisit immédiatement : comme un grand écart !

Serge Roukine propose dans son blog une lecture en trait d’union avec un post qui s’intitule 50 auteurs de livres francophones à suivre sur Twitter.

Dans la vraie vie, lorsque nous croisons un ami, un parent, nous nous saluons et cela a du sens, même si c’est convenu. L’aller / retour : « Comment vas-tu ? Ca va et toi » n’est pratiquement qu’un tic de langage, mais il existe. Sans cette politesse, nous serions certainement fâchés de voir que l’autre nous ignore.

Dans les transports en commun, ce sont des réseaux sociaux, on se salue à Bayonne mais pas à Paris. A Paris, on ne se regarde même presque plus. A la Défense, dans les grandes tours, les ascenseurs sont des réseaux sociaux où les personnes se saluent encore régulièrement. Il y a une proximité qui l’autorise.

Il y a plus de 40 ans, les premiers mails étaient échangés. Aujourd’hui chacun connait le bon usage de l’objet dans l’envoi d’un message : c’est une forme de politesse que de le respecter. De même, une pièce jointe légère est aussi une marque d’attention. Et bien entendu, le message commence et se termine par les formules de politesse classique.

Mais dans nos réseaux sociaux virtuels, ceux de la toile, où en est-on ? Nous pouvons constater que chaque réseau, en se développant, produit ses codes qu’il faut apprendre pour ne pas passer pour un plouc 2.0.

Les formes classiques disparaissent. On ne se salue presque plus d’un « bonjour » mais on peut encore trouver un « A+ » ou un « BR » chez les saxons. La politesse va se loger dans le respect des formes. Avec Twitter, si l’on cite quelqu’un, il faut le mention d’un RT. Dans Facebook, d’un clic on peut dire « j’aime ».

Je constate avec plaisir que les réseaux qui marchent bien ont des codes qui permettent cette attention à l’autre. Selon vous, est-ce une condition de succès des réseaux sociaux ? Je serais très intéressé de lire votre avis sur ce sujet.

Le sociologue Stanley Milgram a décrit en 1967 une expérience qui le rendra célèbre : le small world phenomenon. Selon cette théorie, entre deux individus, quelques ils soient et où qu’ils soient sur terre, il n’existe au plus que six intermédiaires. La plupart des réseaux sociaux s’appuient sur cette théorie, pour définir la profondeur relationnelle maximale de leurs membres.

Qui est Stanley Milgram ?
Stanley Milgram est né le 15 août 1933 à New York. Il fait ses études de science politique au Queens College de New York, poursuit à l’université Harvard où il rédige une thèse en psychologie sociale en 1960. Le psychologue social américain s’est principalement fait connaître pour deux expériences. La première, qui porte son nom, l’expérience de Milgram porte sur la soumission à l’autorité. La seconde est l’expérience du petit monde « small word phenomeon ». Il est considéré comme l’un des psychologues les plus importants du XXe siècle. Il meurt dans sa ville natale le 20 décembre 1984 à l’âge de 51 ans.

Tout le monde s’accorde pour dire que les TIC, les technologies de l’information et de la communication, se sont développées rapidement. Or, le mot apparait dès le début des années 90, je n’ai pas retrouvé la date exacte, mais ça ne doit pas être loin. Cela fait donc environ 20 ans.

Aujourd’hui, le terme est nettement dépassé. En effet, la « communication » est une opération qui consiste à diriger une information vers un public, alors que le propre du web actuel nous oriente vers la collaboration, l’interactivité, le participatif, le réseau social, le networking, le réseautage, etc. Les mots ne manquent pas pour couvrir ces usages qui sont désormais les nôtres. Nous devrions donc parler des TIR, c’est-à-dire des technologies de l’information et de la relation, comme le suggérait un intervenant de l’émission « Place de la toile » sur France Culture, juste avant les vacances.

Pour faire bref, la communication est au Web 1.0 ce que la relation est au Web 2.0. Ou encore, les TIC sont au Web 1.0 ce que les TIR sont au Web 2.0.

Mais, l’histoire ne s’arrête jamais. Et comme je l’ai écrit dans mon livre « Deployer Un Projet Web 2.0 ; Anticiper Le Web Semantique …« , le Web 2.0 est un web de passage, un web de transition. Pour vous, après les TIR, que devrions-nous trouver ?