identity-consolidation-fr - Revision history

ChristopheDucamp: /* design orienté utilisateur */ typo

2007-12-30T16:08:18Z

design orienté utilisateur: typo

← Older revision		Revision as of 16:08, 30 December 2007
Line 10:		Line 10:
	** De ce fait, ne publiez pas d'adresses email (peut-être même rejeter la recherche par adresse email) des utilisateurs		** De ce fait, ne publiez pas d'adresses email (peut-être même rejeter la recherche par adresse email) des utilisateurs
	** Ne publiez même pas des hashes d'adresses email, car ils pourront encore être utilisés par des parties tiers pour exécuter de la consolidation d'identité.		** Ne publiez même pas des hashes d'adresses email, car ils pourront encore être utilisés par des parties tiers pour exécuter de la consolidation d'identité.
	** Ce problème de consolidation d'identité inattendu a tout d'abord été soulevé par les employés d'Adaptive Path lors de l'événement [[events/2007-08-28-social-network-portability-today]], et expliqué/documenté plus à fond ~~ans~~ la [[presentations-fr\|présentation]] de Tantek [http://tantek.com/presentations/2007/10/social-network-portability/ Fundamentos Web: Social Network Portability] ([http://www.elanceur.org/microformats/slides/portabilite-reseau-social-dias.html traduction en français ici])		** Ce problème de consolidation d'identité inattendu a tout d'abord été soulevé par les employés d'Adaptive Path lors de l'événement [[events/2007-08-28-social-network-portability-today]], et expliqué/documenté plus à fond dans la [[presentations-fr\|présentation]] de Tantek [http://tantek.com/presentations/2007/10/social-network-portability/ Fundamentos Web: Social Network Portability] ([http://www.elanceur.org/microformats/slides/portabilite-reseau-social-dias.html traduction en français ici])

	== lien explicite des profils ==		== lien explicite des profils ==

ChristopheDucamp: /* design orienté utilisateur */

2007-12-30T16:07:52Z

design orienté utilisateur

← Older revision		Revision as of 16:07, 30 December 2007
Line 8:		Line 8:
	* Seulement explicite, consolidation d'identité d'utilisateur opted-in		* Seulement explicite, consolidation d'identité d'utilisateur opted-in
	* Pas de "surprise" ou de consolidation d'identité automagique. Les utilisateurs sont bouleversés quand les identités/profils qu'ils pensaient comme différentes (disons parce qu'elles étaient sur différents sites) se retrouvent subitement auto-compactées/consolidées. Les utilisateurs ne s'attendent pas à ce que les sites partagent l'information derrière le dos de l'utilisateur (tout comme leur adresse email).		* Pas de "surprise" ou de consolidation d'identité automagique. Les utilisateurs sont bouleversés quand les identités/profils qu'ils pensaient comme différentes (disons parce qu'elles étaient sur différents sites) se retrouvent subitement auto-compactées/consolidées. Les utilisateurs ne s'attendent pas à ce que les sites partagent l'information derrière le dos de l'utilisateur (tout comme leur adresse email).
	** De ce fait, ne publiez pas ~~les~~ adresses email (peut-être même rejeter la recherche par adresse email) des utilisateurs		** De ce fait, ne publiez pas d'adresses email (peut-être même rejeter la recherche par adresse email) des utilisateurs
	** Ne publiez même pas des hashes d'adresses email, car ils pourront encore être utilisés par des parties tiers pour exécuter de la consolidation d'identité.		** Ne publiez même pas des hashes d'adresses email, car ils pourront encore être utilisés par des parties tiers pour exécuter de la consolidation d'identité.
	** Ce problème de consolidation d'identité inattendu a tout d'abord été soulevé par les employés d'Adaptive Path lors de l'événement [[events/2007-08-28-social-network-portability-today]], et expliqué/documenté plus à fond ans la [[~~presentation~~-fr\|présentation]] de Tantek [http://tantek.com/presentations/2007/10/social-network-portability/ Fundamentos Web: Social Network Portability] ([http://www.elanceur.org/microformats/slides/portabilite-reseau-social-dias.html traduction en français ici])		** Ce problème de consolidation d'identité inattendu a tout d'abord été soulevé par les employés d'Adaptive Path lors de l'événement [[events/2007-08-28-social-network-portability-today]], et expliqué/documenté plus à fond ans la [[presentations-fr\|présentation]] de Tantek [http://tantek.com/presentations/2007/10/social-network-portability/ Fundamentos Web: Social Network Portability] ([http://www.elanceur.org/microformats/slides/portabilite-reseau-social-dias.html traduction en français ici])

	== lien explicite des profils ==		== lien explicite des profils ==

ChristopheDucamp: [fr: sync'd with english version]

2007-12-30T16:06:37Z

[fr: sync'd with english version]

← Older revision		Revision as of 16:06, 30 December 2007
Line 1:		Line 1:
	#~~redirect~~ [[xfn-brainstorming-fr~~#Consolidation_Identité~~]]		<h1> Consolidation d'Identité </h1>
			{{TOC-right}}
			La consolidation d'identité est la capacité pour un utilisateur d'indiquer qu'une ou plusieurs identités, profils, URLs sur différentes sites représentent tout ce même utilisateur. Aussi connu sous : agrégation de profil, équivalence de profil.


			== design orienté utilisateur ==
			La consolidation d'identité doit être produite d'une manière orientée utilisateur. Ceci veut dire :
			* Seulement explicite, consolidation d'identité d'utilisateur opted-in
			* Pas de "surprise" ou de consolidation d'identité automagique. Les utilisateurs sont bouleversés quand les identités/profils qu'ils pensaient comme différentes (disons parce qu'elles étaient sur différents sites) se retrouvent subitement auto-compactées/consolidées. Les utilisateurs ne s'attendent pas à ce que les sites partagent l'information derrière le dos de l'utilisateur (tout comme leur adresse email).
			** De ce fait, ne publiez pas les adresses email (peut-être même rejeter la recherche par adresse email) des utilisateurs
			** Ne publiez même pas des hashes d'adresses email, car ils pourront encore être utilisés par des parties tiers pour exécuter de la consolidation d'identité.
			** Ce problème de consolidation d'identité inattendu a tout d'abord été soulevé par les employés d'Adaptive Path lors de l'événement [[events/2007-08-28-social-network-portability-today]], et expliqué/documenté plus à fond ans la [[presentation-fr\|présentation]] de Tantek [http://tantek.com/presentations/2007/10/social-network-portability/ Fundamentos Web: Social Network Portability] ([http://www.elanceur.org/microformats/slides/portabilite-reseau-social-dias.html traduction en français ici])

			== lien explicite des profils ==
			La plupart des systèmes de profils (réseau social ou autre) ont un endroit pour que l'utilisateur indique une autre URL pour lui-même, pur sa home page, son blog, etc. Clairement c'est une mécanique d'optin, car l'utilisateur doit explicitement dire au site A que le site B est une autre facette de lui-même. Cette interaction/interface passe les critères de design-centré-utilisateur listés au-dessus.

			D'un point de vue format, tout ce qui est nécessaire est que les sites publient de tels liens sur "Autres Profils" pour ajouter la valeur XFN <code>rel="me"</code> aux hyperliens respectifs dans leur HTML. in their HTML.

			Plusieurs [[hcard-xfn-supporting-friends-lists-fr#Services_supportant_la_consolidation_de_l.27identit.C3.A9_avec_XFN_rel.3D.22me.22\|services supportent la consolidation de l'identité avec XFN rel="me"]].

			Voir [[rel-me-fr\|rel-me]] et [http://gmpg.org/xfn/and/#idconsolidation XFN : consolidation d'identité] pour en savoir plus sur la façon dont cela fonctionne.

			== FAQ ==
			En saisissant ici quelques Q&R et idées avant que je ne nettoie les FAQ et/ou produise une page distincte pour la [[identity-consolidation-fr\|consolidation identité]] (ou peut-être une page [[rel-me-fr\|rel-me]] qui discute de consolidation d'identité).

			2007-08-17 Les Q's sont paraphrasées à partir de [[User:JosephSmarr]] de Plaxo, et les réponses sont écrites/éditées par [[User:Tantek]].

			'''Q :''' Est-ce que les liens rel="me" doivent être dans les deux directions pour vérifier le lien ? Il semblent qu'ils doivent l^'etre, parce qu'autrement quelqu'un pourrait trouver tout ce qui fait un lien vers lui et le "déclarer" simplement en plaçant un lien en retour avec rel="me".

			R : Oui, en général les liens rel="me" ont besoin d'être dans les deux directions et ce exactement pour cette raison.


			'''Q :''' Mais quelques sites qui vous laissent lister votre page d'accueil sur le profil n'utilisent pas rel="me", aussi devons-nous simplement les inciter tous à l'utiliser avant que les déclarations bi-directionnelles ne fonctionnent correctement ?

			R : Pas nécessairement. Bien sûr nous préférons le chemin du [[advocacy-fr\|soutien]] pour faire qu'ils implémentent rel="me", mais pour les vieux sites, comme cela est documenté sur http://gmpg.org/xfn/and/ nous pouvons vérifier que les champs spécifiques sur la page profil sont remplis convenablement, avec l'heuristique spécifique au site.

			'''Q :''' Donc soit ils doivent utiliser rel="me" ou nous pouvons gratter les sites connus et faire confiance au lien quoi qu'il en soit ?

			R : rel="me" est le standard qui augmente (ainsi les nouveaux jouers "travaillent simplement") et pour les "anciens joueurs" nous écrivons une liste-blanche avec des règles de compatibilité pour le faire fonctionner.

			'''Q :''' Ainsi je suppose que l'idée est je ne peux pas insérer un lien rel="me" à l'intérieur de n'importe quel contenu-généré-par-un-utilisateur, comme des commentaires sur le blog de quelqu'un d'autre ?

			R : Tout à fait et [[rel-nofollow-fr\|rel-nofollow]] (et [[vote-links-fr\|vote-links]] "vote-against" ou "vote-abstain" pour ce problème) devrait annuler le rel="me".

			'''Q :''' Que penser de Yelp qui utilise rel="nofollow" sur le lien vers votre page personnelle ?

			R : Oui la façon de contourner est de ne regarder seulement que ce lien spécifique "home page", pas n'importe quel lien sur la page, c'est la clé pour les vieux joueurs, avec l'hypothèse étant que seul l'utilisateur/propriétaire de ce profil pourrait modifier cette URL. En outre, Yelp est véritablement en train de violer la spécification [[rel-nofollow-fr\|rel-nofollow]] parce que ce n'est pas un lien vers une partie tiers, c'est un lien vers une partie première, et par conséquent il NE DOIT PAS avoir de rel="nofoww" là-dessus. Ce bug devrait leur être rapporté.

			'''Q :''' Est-ce que des liens à deux sens plus une fermeture transitive suffisent ? Parce que beaucoup de sites peuvent seulement faire un lien vers votre homepage qui pointe alors ensuite vers beaucoup d'autres sites et vous aimeriez pouvoir "ramener ceux-ci" ?

			R : Les liens à deux sens plus une fermeture transitive est un bon début. Mais il existe des cas communs où vous aurez des cricuits en triangle à trois étapes que vous aurez besoin de détecter. Par exemle, disons que ma page profil Plaxo est joseph.myplaxo.com et que je veuille y ajouter ma page twitter twitter.com/jsmarr. Ma page twitter ne fait qu'un lien vers ma home page josephsmarr.com, mais cette page fait un lien arrière vers twitter et aussi vers mon profil plaxo. Ainsi vous pouvez prouver que je suis officiel pour twitter.com/jsmarr même s'il n'a pas un lien à deux sens avec joseph.myplaxo.com. Il peut même y avoir des cas plus complexes, mais que je pense que la 3 voies est commune parce que beaucoup de sites ne vous laissent seulement avoir qu'un lien URL, qui sera généralement vers votre page d'accueil, ainsi à moins que vous ne démarriez par déclarer votre page d'accueil au site, vous devrez crawler en partant d'un "rayon" à l'intérieur du "hub" et puis revenir à nouveau en arrière. Ainsi en général, vous devrez maintenir tous les liens rel="me" sur toutes les pages que vous crawlez, puis assembler le graphe, puis détecter tous les circuits, et puis tous les noeuds dans les circuits qui sont connectés à la page racine avec laquelle vous avez démarré seront vérifiés. Je pense. :)

			'''Q :''' Comment devrais-je ensuite crawler les liens rel="me" ?

			R : Faites chaque 2 voies une par une. Ce qui veut dire allez vers une destination rel="me", cherchez le lien arrière rel="me" vers la même page dans cette source, et ensuite placez dans la file tous les liens restants rel="me" pour le crawling. Mettez dans la file d'attente les relations rel="me" pendant que vous crawlez, ce qui veut dire que pendant que vous crawlez a, vous ne placez pas dans la file d'attente juste les destinations des liens b et c, mais plutôt, vous placez dans la file d'attente les relations a-me->b, a-me->c. Et puis vous crawlez les destinations dans la queue, et pour les rel="me" confirmés à 2 sens, migrez les simplement sur une autre liste, par exemple quand vous voyez b-me->a vous retirez simplement a-me->b de la queue et placez a<->b à l'intérrieur du fichier "me", et quand vous voyez b-me->d vous l'ajoutez simplement à la queue. Répétez jusqu'à ce que vous ayez crawlé toutes les destinations dans la queue et c'est fait.

			'''Q :''' Il existe souvent plusieurs pages équivalentes, comme http://flickr.com/photos/jsmarr , http://www.flickr.com/photos/jsmarr , http://flickr.com/people/jsmarr , http://flickr.com/people/jsmarr/profile . Devons-nous écrire des règles d'équivalence ou simplement faire que les personnes utilisent la même forme ?

			R : De telles pages devraient elles-même faire un a) lien rel="me" vers les versions à la fois "www." et non "www." via les liens déjà sur la page (parce qu'elles l'ont déjà souvent), OU ajouter des tags équivalents à <link rel="me" href="..." /> dans l'en-tête <head> du document.

			'''Q :''' Par conséquent, au moment de crawler une page à la recherche de liens rel="me", devrais-je checher A LA FOIS les liens <a rel="me" dans le body ET les liens <link rel="me" dans le head ?

			R : Oui, ils sont équivalents, par conséquent regardez les deux.


			== Frames ==

			Etrangement, le nouveau site [http://www.google.com/s2/sharing/stuff Google Share] supporte [[hcard-fr\|hCard]] mais dans une frame. Afin de parser cette page, les crawlers ont besoin de quelque crochet pour identifier la source de la hCard. Il est raisonnable d'imaginer utiliser <code><frame src="http://example.com/framesrc.html" rel="me" /></code> (tout comme pour <code><iframe></code> et <code><object></code>) afin de satisfaire cette source non conventionnelle de donnée de profil. Tout comme un lien retour vers la page contenant la frame utilisant rel-me serait nécessaire pour produire une déclaration valide.

			Malheureusement, aucun des <code><frame></code>, <code><iframe></code>, <code><object></code> ne dispose d'un attribut <code>rel</code> en HTML4, et de ce fait nous devons faire usage d'une solution alternative.

			HTML4 a vraiment un élément <code>[http://www.w3.org/TR/html4/present/frames.html#h-16.4.1 <noframes>]</code> que les auteurs web utilisent souvent pour hyperlier vers les contenus de la frame de manière à ce qu'ils soient accessibles dans les navigateurs qui ne supportent pas les frames (comme la plupart de ceux sur les téléphones mobiles par exemple).

			Cet hyperlien dans l'élément <code><noframes></code> devrait avoir sur lui <code>rel="me"</code> afin de consolider la portion "framed" du profil avec la profil elle-même. De la même façon sur la portion de frame, il devrait y avoir un élément <code><noframes></code> qui fasse un lien retour vers la frame/le document parent avec <code>rel="me"</code> afin d'établir la relation bidirectionnelle de consolidation d'identité.

			Pour les encapsulages <code><object></code>, on peut simplement mettre un hyperlien dans la ligne à l'intérieur des contenus <code><object>...</object></code> comme contenus de repli pour les navigateurs qui ne restituent pas les objets encapsulés, fournissant par conséquent à la fois une méthode visible à browser vers l'embed, et un hyperlien sur lequel placer le <code>rel="me"</code>.

			== voir aussi : ==
			* [[rel-me-fr\|rel-me]]
			* [[hcard-supporting-user-profiles-fr\|Profils utilisateurs supportant hCard]]
			* [[hcard-xfn-supporting-friends-lists-fr\|Listes d'amis supportant hCard et XFN]]
			* [[social-network-portability-fr\|portabilité-réseau-social]]
			* [[xfn-fr\|XFN]], [[xfn-brainstorming-fr\|XFN-brainstorming]]
			* [[event-consolidation-fr\|consolidation-évènement]]

ChristopheDucamp: [fr:typo]

2007-12-26T20:27:09Z

[fr:typo]

← Older revision		Revision as of 20:27, 26 December 2007
Line 1:		Line 1:
	#redirect [[xfn-brainstorming-fr#~~Consolitation_Identité~~]]		#redirect [[xfn-brainstorming-fr#Consolidation_Identité]]

ChristopheDucamp: #redirect xfn-brainstorming-fr#Consolitation_Identité

2007-12-26T20:18:16Z

#redirect xfn-brainstorming-fr#Consolitation_Identité

New page

#redirect [[xfn-brainstorming-fr#Consolitation_Identité]]