Recherche
Un article de InOutWiki.
Sommaire |
RÉSEAU, données et répartition
Des données sur un réseau
Attention : nous ne parlons pas ici de flux ou de contenus (médias audio/video/data). Nous parlons de données telles que :
- logins des personnes connectées
- adresses ip
- profils des projets inscrits
- aperçus figés des flux
- caractéristiques temporelles (durées de connexion)
- etc...
Il existe des données figées (identifiant unique et non modifiable) et d'autres qui sont susceptibles de changer (adresse ip, profils)
Pour ces ensembles de données, il existe plusieurs répartitions possibles de la "connaissance".
Centralisation
Un serveur a toutes les données. Pour lire ou écrire une donnée, il faut nécessairement s'adresser au serveur (connu de tous). Ici, pas de position initiale. On rentre dans le réseau global immédiatement, en communiquant avec le serveur. Il n'y a pas de perte d'information possible car toutes les données passent par le serveur (on présuppose la robustesse par techniques de redondance et de load-balancing).
Répartition
- Tout le monde possède toutes les données (!). Pour lire une donnée, on s'adresse à n'importe quel point du réseau. Lors d'une modification de donnée (je change le nom de mon projet), la nouvelle donne doit être communiquée à l'ensemble des autres points du réseau.
- Tout le monde n'a qu'une partie des données. La modification d'une donnée s'effectue localement. La lecture s'effectue par propagation (transmission de la demande : ai-je la dernière version ?).
NB : Avec le temps, le cas 2. tends vers 1.
Personne n'a de vision globale du réseau. Chacun a sa propre vision locale. Pour rentrer dans la boucle, il faut et il suffit de connaître une personne déja intégrée. On peut alors avoir connaissance des autres par propagation de l'information. Nous avons ici un modèle de diffusion par affinités (cf débuts de gmail avec inscription par invitation). Dans ce cas, le réseau est susceptible de subir des pertes d'informations et/ou de se fragmenter en plusieurs sous-réseaux.
Méthode mixte
Une bonne approche consisterai à coupler les deux approches :
- lieu unique pour les données critiques (adresses ip, états courants de connexion des différents projets ...?)
- répartition de certaines autres données moins critiques (tags ...?)
Comment définir l'importance d'une donnée ? Suis-je prêt à ne pas pouvoir accéder rapidement (voire à perdre) :
- le nombre total de projets connectés
- l'aperçu d'un flux de projet (image)
- la connaissance d'une connexion (le projet A est lié au projet B, mais ce n'est pas totalement sûr)
- etc...
Pour résumer : existe-t-il des données dont on peut se permettre d'avoir une connaissance floue ? Si oui, lesquelles ?
IDENTITÉ, métadonnées
Comment mettre en place un language commun pour permettre les échanges ? La question se pose pour :
- les échanges de flux (choix du protocole, du format de compression du flux vidéo par exemple) mais aussi pour
- les échanges de descriptions (langage commun pour décrire / évaluer / rechercher un profil de projet ou de flux)
On s'intéresse dans cette section aux échanges de descripteurs.
Il existe deux grands types de descripteurs de contenus : nous pouvons les séparer en deux grandes classes :
- critères objectifs
- critères subjectifs
Critères objectifs
- luminosité
- couleurs
- taille de la vidéo
- taux de compression du flux
- fréquence d'envoi des messages (data)
- etc ...
Cela nécessite la création d'un vocabulaire normé, permettant ensuite d'utiliser ces critères dans des recherches complexes :
Par exemple : ( L=0.7 ) & ( Size=320x240 ) & ( R=0.2 ) & ...
Critères subjectifs
Statiques
Ma description, mon point de vue (je peux mentir). Déterminé au départ par le créateur du flux. Il doit pouvoir exister :
- Une description totalement libre : Mon flux de données est terriblement sexy, il est composé de mots courts et clinquants. Aimez-moi
- Une description formatée, par exemple une liste de tags : T = sex, small, love
Dynamiques
Description qui évolue dans le temps
- Dynamique en description
flux stable dans le temps, corrections successives du réseau pour créer un consensus
- Correction transparente : Par mesure de temps de connexion relatif (on suppose que si les gens se déconnectent, c'est qu'il ne sont pas satisfaits)
- Correction facile : Par notation simple des tags par les autres utilisateurs
- Correction manuelle : Par mise-à-jour des tags de description du flux : création de nouveaux descripteurs
- Dynamique en contenu
flux variable dans le temps
Création et modification d'un tag
A l'origine, aucun tag n'existe. Lors de la création d'un nouveau tag, il est demandé de la positionner par rapport aux autres tags existants :
- Par correspondance : amour / amitié
- Par antinomie : lourd / léger
- Aucun rapport
Il faut imaginer un système qui minimise l'effort de l'utilisateur : par exemple en lui demandant de cliquer dans l'espace des tags existants à l'endroit le plus approprié. Ceci permet de construire progressivement un système de relation entre tags. Ce système de valeur est construit par les projets du réseau, et n'a pas vocation à être une juste représentation du champ sémantique d'une langue.
Les utilisateurs créent le langage du réseau : Blanc peut y être proche de Noir, Brukme proche de Cheval.
NAVIGATION, recherche de projet, de flux
Questions
Quel est l'objet de ma recherche ?
- un projet ? (démarche artistique)
- un flux ? (type d'image, type de son)
- un tag ? (symbole)
- une description ? (mot clef, thème)
Quelles sont les données que je fournis ?
- Liste rigide de paramètres :
- Les projets souhaités : P = pierre (très voulu), moloko (pourquoi pas), johnny (surtout pas)
- Les tags souhaités : T = speed (12), small(1), red(-20)
- Les caractéristiques du flux souhaitées : Size = 320x240, etc...
- Navigation floue : je me promène parmis les différentes descriptions. Mon oeil joue le rôle d'organe de filtrage et de recherche.
- Liste rigide de paramètres :
Quelles priorités ?
- Tous les critères décris dans la section précédente peuvent rentrer en jeu. Il faut donc déterminer les priorités de choix en cas de contradictions.
Quel résultat ?
- Un résultat unique (le "j'ai de la chance" de google)
- Liste ordonnée (résultats classiques d'un moteur de recherche)
Problème de la séduction
In the digital world, we don't just categorize an object, we also optimize its future findability. We need to consider not just the most likely category, but also where we are most likely to look for the item at the time of finding.
taken from A cognitive analysis of tagging
Nuages de tags
Postulat : l'oeil est le meilleur organe de filtrage et de recherche. On peut se permettre d'afficher un grand nombre de mots. Cela favorise par ailleurs l'exploration.
Il faut se méfier du fort parti-pris de l'interface :
- reflet du contenu du réseau ? si 90% des tags sont pouet, l'affichage est saturé de pouet
- révelatrice de contenus pathogènes / particuliers / rares ? (chance donnée aux petits)
Quelle taille ?
- plus nombreux -> ++ ?
- plus rares -> ++ ?
- meme taille pour tout le monde, quel que soit le nombre d'occurences ?
- respiration aléatoire (taille variable) ?
Quel ordre ?
- en désordre : le cerveau fait le tri (++)
- alphabétique : chaise/chaises/chaises-longues (+)
- par date d'utilisation (+)
- par nombre d'occurence ( -- ) -> provoque le mass-media
Exemples et scénarios de recherche
Modes de recherche
Différents modes de présentation du nuage : (cf del.icio.us : sort by...)
- je veux être surpris (autre chose qu'avant)
- quels sont les succès ? (quel est le plus diffusé)
- rassure moi (comme avant)
Sélection progressive
- Le système fournit un ensemble aléatoire de mots
- L'utilisateur peut supprimer ou appuyer certains tags
- etc...
- Le système évolue doucement vers un ensemble de solutions qui conviennent
Liens rigides (tags associés aux projets)
- Premier tirage aléatoire de tags
- Un rollover sur un tag met en valeur tous les autres tags associés (car liés au même projet par exemple)
- Un clic permet d'isoler le tag et les liens directs (plus lisible)
Par séparation
On considère un ensemble de tags :
- Une zone neutre permet de prendre les mots disponibles
- Une zone + permet de placer les tags voulus
- Une zone - pour les tags à éviter
Cela revient à effectuer une pondération spatiale des tags que l'on souhaite évaluer. De plus, chaque disposition effectuée par un utilisateur permet de mettre à jour les liens entre les tags.
POLITIQUE, gestion des connexions
Déterminisme
J'ai envie de A (je désire utiliser son flux audio par exemple). Alors :
- Je suis exaucé : Je l'ai forcément (seul problème : si il existe trop de connexions, ça ne marchera pas bien techniquement)
- Je suis plutôt satisfait : Le système tend vers une solution générale qui tient compte de mes aspirations (mais ce n'est pas sûr que je sois complètement satisfait)
- Je suis compris : Le système a mémorisé le fait que j'ai beaucoup demandé B dans le passé : il favorise les configurations A+B (Mémorisation des recherches et aspirations passées).
Orientation subjective de la forme du réseau
Faut-il interdire des configurations particulières du réseau ?
- Convergence vers des situations qui n'évoluent pas -> forcer le renouvellement ?
- Emergence de fournisseurs principaux : modèle mass-médiatique -> nombre limité de connexions sortantes ?
- Situation d'échanges ponctuels (A - B, C - D), petits groupes isolés
Sécurité
Problèmes :
- Diffuser depuis un serveur Icecast en local (sur sa machine) implique de donner son adresse IP à celui qui souhaite se connecter. Ce dernier peut donc se connecter quand il le souhaite par la suite.
MONITORING, projets, réseau et flux
Première question qui se pose : si l'on suppose un affichage du réseau sous la forme de graphe : quelles sont les données qui doivent être exhibées ?
- Les projets et leurs liens ? (ex: graphe simple : les sommets représentent les projets)
- Les relations entre les différents tags ? (graphe de mots avec liens sémantiques)
Graphes et connexions
Graphes classiques
Arcs et demi-cercles
Arbres
Boîtes ou disques
Un lien entre un objet A et un objet B est représenté par une intersection entre les objets A et B.
Avantages :
- On voit tout de suite les zones d'influence
Inconvénients :
- Difficile à construire
- Pas clair du tout si le réseau possède un grand nombre de liens
Aspirations et déterminants
- Comment représenter ma volonté de n'avoir qu'un flux ?
- Comment afficher les différents tags et informations disponibles ?
- etc...
Parcours des données
- Visualisation des flux : accéder au contenu émis
- Arborescence et transformation des flux
- Profondeur : provenance et diffusion (influences)
- Anneaux concentriques et morceaux de disques (camembert)
- Affichages des versions successives
- Représentation de la quantité de données qui transitent
- Distances des projets les uns par rapport aux autres
Temps et mémoire
Comment conserver des données telles que :
- Reconfigurations des connexions dans le temps
- Age d'un projet, date d'arrivée, durée de connexion
- Contenus eux-mêmes (vidéo, audio, data)
Représentation des reconfigurations
Fresque représentant la fréquence d'apparition et de disparition des liens
Un rollover sur cette fresque permet de montrer sur le graphe les liens concernés (tous les autres sont alors masqués ou amoindris).
Tableau : abscisse = les projets, ordonnée = temps
Les liens sont représentés au moment où ils sont créés ou détruits.
