distributed-conversation-formats-fr - Revision history

AcorrOtrel: letochiva

2008-12-19T23:40:07Z

letochiva

Show changes

Brian: Reverted edits by DelliRacmo (Talk) to last version by ChristopheDucamp

2008-12-16T18:55:11Z

Reverted edits by DelliRacmo (Talk) to last version by ChristopheDucamp

Show changes

DelliRacmo: c4toloor

2008-12-16T15:32:46Z

c4toloor

Show changes

ChristopheDucamp at 16:56, 16 August 2006

2006-08-16T16:56:11Z

← Older revision		Revision as of 16:56, 16 August 2006
Line 82:		Line 82:

	== Exemples d'Utilisation ==		== Exemples d'Utilisation ==
	En partant de l'e-mail nous ~~obteons~~ deux relations basiques entre les messages :		En partant de l'e-mail nous obtenons deux relations basiques entre les messages :
	* Reply - Ce message est une réponse au message en référence.		* Reply - Ce message est une réponse au message en référence.
	* Forward - Ce message transfère le message en référence vers des destinataires additionnels.		* Forward - Ce message transfère le message en référence vers des destinataires additionnels.
Line 92:		Line 92:
	* Quote		* Quote
	* Citer une référence		* Citer une référence
	* Via lien/Hat tip (essentiellement dans ~~lees~~ blogs)		* Via lien/Hat tip (essentiellement dans les blogs)

ChristopheDucamp: /* Exemples d'Utilisation */

2006-08-16T16:55:47Z

Exemples d'Utilisation

← Older revision		Revision as of 16:55, 16 August 2006
Line 82:		Line 82:

	== Exemples d'Utilisation ==		== Exemples d'Utilisation ==
	~~From Email we get two basic~~ relations ~~between message~~:		En partant de l'e-mail nous obteons deux relations basiques entre les messages :
	* Reply - ~~This~~ message ~~is a reply to the referenced~~ message.		* Reply - Ce message est une réponse au message en référence.
	* Forward - ~~This~~ message ~~forwards the referenced~~ message ~~to additional recipients~~.		* Forward - Ce message transfère le message en référence vers des destinataires additionnels.

	~~From various~~ publications (~~often of~~ standards) ~~we get~~:		A partir de différentes publications (souvent de standards) nous obtenons :
	* Updates/Obsoletes - ~~This documents contains updates or even replaces the referenced~~ document.		* Updates/Obsoletes - Ce document contient des mises à jour ou même remplace le document référencé.

	~~Citation of resources comes in several flavors~~:		La citation de ressources arrive sous plusieurs formes :
	* Quote		* Quote
	* ~~Citing a reference~~		* Citer une référence
	* Via ~~link~~/Hat tip (~~mainly in~~ blogs)		* Via lien/Hat tip (essentiellement dans lees blogs)

ChristopheDucamp: /* SIOC - Semantically-Interlinked Online Communities */

2006-08-16T16:53:26Z

SIOC - Semantically-Interlinked Online Communities

← Older revision		Revision as of 16:53, 16 August 2006
Line 59:		Line 59:

	=== SIOC - Semantically-Interlinked Online Communities ===		=== SIOC - Semantically-Interlinked Online Communities ===
	SIOC (Semantically Interlinked Online Communities) ~~is an ontology for describing~~ discussion ~~forums and posts on topic threads in online community~~ sites. ~~This includes but is not limited to~~: blogs, bulletin boards, ~~mailing lists~~, newsgroups, etc.		SIOC (Semantically Interlinked Online Communities) est une ontologie pour décrire les forums de discussions et billets sur les fils de discussion thématiques dans les sites de communautés en ligne. Ceci comprend mais n'est pas limité à : blogs, bulletin boards, listes de discussion, newsgroups, etc.
	* http://rdfs.org/sioc/		* http://rdfs.org/sioc/
	* http://rdfs.org/sioc/spec/		* http://rdfs.org/sioc/spec/

	~~Relevant properties defined under~~ [http://rdfs.org/sioc/spec/ SIOC]:		Propriétés pertinentes définies sous [http://rdfs.org/sioc/spec/ SIOC] :
	* has_reply - ~~This details replies or responses to this Post~~, ~~which can be used for purposes of display ordering~~.		* has_reply - Ceci détaille les répliques ou réponses à ce billet, qui peut être utilisé à des fins de tri d'affichage.
	* reply_of - ~~Links to a previous Post~~, ~~which this Post is a reply of~~ (~~or to~~).		* reply_of - Liens vers un Billet précédent, dont ce Billet est une répique de (ou vers).
	* next_version - ~~Links to the next revision of this Post~~.		* next_version - Liens vers la prochaine révision de ce Billet.
	* previous_version - ~~Links to a previous revision of this Post~~.		* previous_version - Liens vers une précédente révision de ce Billet.
	* has_sibling - ~~A Post may have a sibling or a twin that exists in a different Forum~~, ~~but the siblings may differ in some small way~~ (~~for example~~, ~~language~~, ~~category~~, etc.)~~. The sibling of this Post only needs to have the changed~~ information.		* has_sibling - Un Billet peut avoir un jumeau qui existe dans un forum différent, mais les jumeaux peuvent différer de manière minimale (par exemple, langue, catégorie, etc.) Le jumeau de ce Billet n'a seulement besoin que de l'information modifiée.
	* sibling_of - ~~This Post differs from its sibling in some small way~~. ~~The other sibling can be used as a~~ source ~~for any missing data~~.		* sibling_of - Ce Billet diffère de son jumeau d'une manière minimale. L'autre jumeau peut être utilisé comme une source pour toute donnée manquante.
	* attachment - A URI ~~of the attachment related to a Post~~.		* attachment - Un URI de la pièce jointe apparentée à un Billet.
	* related_to - ~~Related Posts for this Post~~, ~~perhaps determined implicitly from topics or references~~.		* related_to - Billets apparentés pour ce Billet, peut-être déterminés à partir des thématiques ou références.
	* is_closed - ~~Details if this~~ (~~and any children~~) ~~is closed~~.		* is_closed - Détails si c'est (et n'importe quels enfants) fermé.

	'''Discussion of SIOC'''		'''Discussion of SIOC'''
	* ~~We cannot expect the complementary~~ relations (~~e.g~~. has_reply) ~~to exist~~. ~~This would require a more strongly connected system that we do not assume exists~~. ~~Similarly for~~ is_closed.		* Nous ne pouvons pas nous attendre à ce que les relations complémentaires (par ex. has_reply) doivent exister. Ceci obligerait l'existence d' un système bien mieux connecté que nous ne n'assumons pas. La même chose pour is_closed.
	* next_version ~~and~~ previous_version ~~might be an interesting~~ alternative ~~to updates in the case where the author of the updated~~ version ~~has control of the previous~~ version ~~as well~~. ~~This is not always the case but might happen often enough to include this~~ option.		* next_version et previous_version pourraient être une alternative intéressante pour les mises à jour dans le cas où l'auteur de la version mise à jour a le contrôle de la version précédente. Ceci n'est pas toujours le cas mais pourrait arriver assez souvent pour inclure cette option.
	* ~~The~~ concept ~~of siblings is an interesting one, although the difference between that and~~ update or forward ~~might be too particular for most users~~.		* Le concept des jumeaux est intéressant bien que la différence entre ça et update ou forward pourrait être trop spécifique pour la plupart des utilisateurs.
	* attachment ~~might be interesting but is it necessary~~?		* attachment pourrait être intéressant mais est-ce nécessaire ?
	* related_to ~~might be useful in an aggregate environment~~ (~~think~~ delicious ~~related tags~~) ~~but otherwise I see those posts use as~~ source ~~citations~~, ~~so this specific~~ relation ~~type might be pointless~~.		* related_to pourrait être utile dans un environnement agrégé (penser au tags en rapport avec delicious) mais autrement je vois ces usages de billets comme des citations de source, par conséquent ce type de relation spécifique pourrait être sans objet.

	== Exemples d'Utilisation ==		== Exemples d'Utilisation ==

ChristopheDucamp: /* IBIS - Issues Based Information Systems */

2006-08-16T16:42:04Z

IBIS - Issues Based Information Systems

← Older revision		Revision as of 16:42, 16 August 2006
Line 33:		Line 33:

	===IBIS - Issues Based Information Systems===		===IBIS - Issues Based Information Systems===
	~~Kunz~~'s Issue Based Information Systems (IBIS) fournit un cadre pour une compréhension collaborative des principales problématiques et implications entourant ce qui est décrit comme des ``wicked problems'' (des problèmes qui manquent d'une formulation définitive). La compréhension est atteinte en utilisant les composants ~~hypertexteproblems that lack a definitive formulation). Understanding is achieved by using hypertext components to create structured arguments surrounding the issues~~. (<cite>[http://www.weblogkitchen.com/wiki.cgi?GraphicalIbis Weblog Kitchen]</cite>)		Les 'Issue Based Information Systems' (IBIS) de Kunz fournit un cadre pour une compréhension collaborative des principales problématiques et implications entourant ce qui est décrit comme des ``wicked problems'' (des problèmes qui manquent d'une formulation définitive). La compréhension est atteinte en utilisant les composants hypertexte pour créer des arguemnts structurés entourant les problématiques. (<cite>[http://www.weblogkitchen.com/wiki.cgi?GraphicalIbis Weblog Kitchen]</cite>)
	* [http://dannyayers.com/xmlns/ibis/ IBIS ~~vocabulary~~]		* [http://dannyayers.com/xmlns/ibis/ vocabulaire IBIS]
	* [http://collab.blueoxen.net/forums/yak/2003-12/threads.html#00191 ~~How to start an~~ IBIS ~~discussion in Email~~]		* [http://collab.blueoxen.net/forums/yak/2003-12/threads.html#00191 Comment démarrer une discussion IBIS dans l'e-mail]
	* [http://www.weblogkitchen.com/wiki.cgi?GraphicalIbis graphical IBIS (gIBIS)]		* [http://www.weblogkitchen.com/wiki.cgi?GraphicalIbis graphical IBIS (gIBIS)]
	~~The hypertext model of~~ IBIS ~~consists of three node~~ types:		Le modèle hypertexte d'IBIS comprend trois types de noeuds :
	1. issues		1. issues
	2. positions		2. positions
	3. arguments		3. arguments

	~~Eight link~~ types ~~represent the allowable relationships between these nodes~~:		Huit types de lien représentent les relations autorisées entres ces noeuds :
	1. generalises		1. generalises
	2. specialises		2. specialises
Line 54:		Line 54:
	'''Discussion à propos d'IBIS'''		'''Discussion à propos d'IBIS'''

	~~Similar to~~ TDL, IBIS ~~seems to tackle a bigger problem than the one discussed here~~.		Comme pour TDL, IBIS semble tacler un plus gros problème que celui discuté ici.
	* ~~The different node~~ types ~~are not necessary for tracking a~~ discussion ~~thread~~. ~~Tracking the flow of the~~ conversation, ~~the~~ arguments ~~and flow of ideas is a wider more complex issue than just gluing together disparate pieces of an online~~ discussion.		* Les différents types de noeuds ne sont pas nécessaires pour tracer un fil de discussion. En traçant le flux de la conversation, les arguments et flux d'idées sont une problématiqu plus complexe que d'assembler simplement des morceaux disparates d'une discussion en ligne.
	* ~~Link type such as~~ "generalises" ~~and~~ "specialises" ~~might be useful but seem to require a lot from the user~~. ~~If we allow for inheritance of link~~ type ~~they could be used as optional parts of the~~ format ~~but it appears that we can do well enough without them~~.		* Les types de liens tels que "generalises" et "specialises" pourraient être utiles mais semblent demander beaucoup de la part de l'utilisateur. Si nous permettons un héritage du type de lien, ils pourraient être utilisés comme des parties optionnelles du format mais il appararaît que nous pouvons bien assez faire sans eux.

	=== SIOC - Semantically-Interlinked Online Communities ===		=== SIOC - Semantically-Interlinked Online Communities ===

ChristopheDucamp: /* Email/Usenet */

2006-08-16T16:36:24Z

Email/Usenet

← Older revision		Revision as of 16:36, 16 August 2006
Line 4:		Line 4:
	===Email/Usenet===		===Email/Usenet===
	Email et Usenet gardent tous les deux trace des fils de discussion d'une manière non-centrale en utilisant les en-têtes et références vers les IDs de messages. Quelques en-têtes communs et leurs usages sont soulignés dans [http://www.faqs.org/rfcs/rfc2076.html RFC2076 - Common Internet Message Headers] section 3.6 :		Email et Usenet gardent tous les deux trace des fils de discussion d'une manière non-centrale en utilisant les en-têtes et références vers les IDs de messages. Quelques en-têtes communs et leurs usages sont soulignés dans [http://www.faqs.org/rfcs/rfc2076.html RFC2076 - Common Internet Message Headers] section 3.6 :
	* In-Reply-To - ~~Reference~~ vers un message dont ce message est un "reply to".		* In-Reply-To - Référence vers un message dont ce message est un "reply to".
	* References - In e-mail: ~~reference to other related~~ messages, in Usenet ~~News reference to~~ replied-to-articles.		* References - Dans l'e-mail : référence vers d'autres messages apparentés, en référence aux News Usenet vers les 'replied-to-articles'.
	* See-Also - ~~References to other related~~ articles in Usenet News.		* See-Also - Références vers d'autres articles en rapport dans Usenet News.
	* Obsoletes - ~~Reference to previous~~ message ~~being corrected and replaced~~.		* Obsoletes - Référence au message précédent étant corrigé et remplacé.
	* Supersedes - ~~Commonly used in~~ Usenet News ~~in similar ways to the~~ "Obsoletes" ~~header described above~~. In Usenet News, ~~however~~, Supersedes ~~causes a full deletion of the replaced~~ article ~~in the server~~, ~~while~~ "Supersedes" ~~and~~ "Obsoletes" ~~in e-mail is implemented in the~~ client ~~and often does not remove the old~~ version ~~of the text~~.		* Supersedes - Communément utilisé dans Usenet News avec des manières similaires aux header "Obsoletes" décrit au-dessus. Dans Usenet News, néanmoins, Supersedes provoque un effacement total de l'article remplacé dans le serveur, alors que "Supersedes" et "Obsoletes" dans l'email est implémenté dans le client et n'enlève pas souvent la vieille version du texte.
	* Article-Updates - ~~Only in~~ Usenet News, ~~similar to~~ "Supersedes:" ~~but does not cause the referenced~~ article ~~to be physically deleted~~.		* Article-Updates - Seulement dans Usenet News, similaire à "Supersedes:" mais ne provoque pas le fait que l'article référencé soit effacé physiquement.
	* Article-Names - ~~Reference to specially important~~ articles ~~for a particular~~ Usenet ~~Newsgroup~~.		* Article-Names - Référence vers articles tout particulièrement importants pour un Newsgroups spécifique Usenet.

	===Langage de Description de Fil===		===Langage de Description de Fil===

ChristopheDucamp at 14:14, 16 August 2006

2006-08-16T14:14:13Z

New page

= Formats de Conversation Distribuée=

== Exemples de Formats Apparentés ==
===Email/Usenet===
Email et Usenet gardent tous les deux trace des fils de discussion d'une manière non-centrale en utilisant les en-têtes et références vers les IDs de messages. Quelques en-têtes communs et leurs usages sont soulignés dans [http://www.faqs.org/rfcs/rfc2076.html RFC2076 - Common Internet Message Headers] section 3.6 :
* In-Reply-To - Reference vers un message dont ce message est un "reply to".
* References - In e-mail: reference to other related messages, in Usenet News reference to replied-to-articles.
* See-Also - References to other related articles in Usenet News.
* Obsoletes - Reference to previous message being corrected and replaced.
* Supersedes - Commonly used in Usenet News in similar ways to the "Obsoletes" header described above. In Usenet News, however, Supersedes causes a full deletion of the replaced article in the server, while "Supersedes" and "Obsoletes" in e-mail is implemented in the client and often does not remove the old version of the text.
* Article-Updates - Only in Usenet News, similar to "Supersedes:" but does not cause the referenced article to be physically deleted.
* Article-Names - Reference to specially important articles for a particular Usenet Newsgroup.

===Langage de Description de Fil===
Thread Description Language - TDL est un vocabulaire RDF pour décrire les discussions en mode fil, tels que Usenet, weblogs, les bulletin boards et conversations par e-mail.
* http://www.eyrie.org/~zednenem/2002/web-threads/
* http://www.eyrie.org/~zednenem/2002/wtprofile/
TDL v3 définit les propriétés suivantes :
* Property tdl:discusses - Relates a Post to a resource it talks about
* Property tdl:follows - Indicates that this resource comes no earlier than the specified resource
* Property tdl:inThread - Relates a post to a thread which includes it
* Property tdl:mentions - Indicates that this resource refers to the specified resource
* Property tdl:respondsTo - Relates a post to its parent(s) in a discussion
* Property tdl:respondsNegativelyTo - Relates a post to a parent post which it dissents from or corrects
* Property tdl:respondsPositivelyTo - Relates a post to a parent post with which it concurs

'''Discussion sur TDL'''

# respondsNegativelyTo, respondsPositivelyTo are beyond the scope of this spec. They can both be implemented using vote-links.
# Without those, respondsTo remains the main connector between posts in a thread.
# mentions and discusses seem to be splitting hairs. It appears that both of them can be replaced by using the CITE tag.
# follows seems to be designed for use in a central registry that tracks threads and therefore is useless for a distributed solution.

===IBIS - Issues Based Information Systems===
Kunz's Issue Based Information Systems (IBIS) fournit un cadre pour une compréhension collaborative des principales problématiques et implications entourant ce qui est décrit comme des ``wicked problems'' (des problèmes qui manquent d'une formulation définitive). La compréhension est atteinte en utilisant les composants hypertexteproblems that lack a definitive formulation). Understanding is achieved by using hypertext components to create structured arguments surrounding the issues. (<cite>[http://www.weblogkitchen.com/wiki.cgi?GraphicalIbis Weblog Kitchen]</cite>)
* [http://dannyayers.com/xmlns/ibis/ IBIS vocabulary]
* [http://collab.blueoxen.net/forums/yak/2003-12/threads.html#00191 How to start an IBIS discussion in Email]
* [http://www.weblogkitchen.com/wiki.cgi?GraphicalIbis graphical IBIS (gIBIS)]
The hypertext model of IBIS consists of three node types:
1. issues
2. positions
3. arguments

Eight link types represent the allowable relationships between these nodes:
1. generalises
2. specialises
3. replaces
4. questions
5. is_suggested_by
6. responds_to
7. objects_to
8. supports

'''Discussion à propos d'IBIS'''

Similar to TDL, IBIS seems to tackle a bigger problem than the one discussed here.
* The different node types are not necessary for tracking a discussion thread. Tracking the flow of the conversation, the arguments and flow of ideas is a wider more complex issue than just gluing together disparate pieces of an online discussion.
* Link type such as "generalises" and "specialises" might be useful but seem to require a lot from the user. If we allow for inheritance of link type they could be used as optional parts of the format but it appears that we can do well enough without them.

=== SIOC - Semantically-Interlinked Online Communities ===
SIOC (Semantically Interlinked Online Communities) is an ontology for describing discussion forums and posts on topic threads in online community sites. This includes but is not limited to: blogs, bulletin boards, mailing lists, newsgroups, etc.
* http://rdfs.org/sioc/
* http://rdfs.org/sioc/spec/

Relevant properties defined under [http://rdfs.org/sioc/spec/ SIOC]:
* has_reply - This details replies or responses to this Post, which can be used for purposes of display ordering.
* reply_of - Links to a previous Post, which this Post is a reply of (or to).
* next_version - Links to the next revision of this Post.
* previous_version - Links to a previous revision of this Post.
* has_sibling - A Post may have a sibling or a twin that exists in a different Forum, but the siblings may differ in some small way (for example, language, category, etc.). The sibling of this Post only needs to have the changed information.
* sibling_of - This Post differs from its sibling in some small way. The other sibling can be used as a source for any missing data.
* attachment - A URI of the attachment related to a Post.
* related_to - Related Posts for this Post, perhaps determined implicitly from topics or references.
* is_closed - Details if this (and any children) is closed.

'''Discussion of SIOC'''
* We cannot expect the complementary relations (e.g. has_reply) to exist. This would require a more strongly connected system that we do not assume exists. Similarly for is_closed.
* next_version and previous_version might be an interesting alternative to updates in the case where the author of the updated version has control of the previous version as well. This is not always the case but might happen often enough to include this option.
* The concept of siblings is an interesting one, although the difference between that and update or forward might be too particular for most users.
* attachment might be interesting but is it necessary?
* related_to might be useful in an aggregate environment (think delicious related tags) but otherwise I see those posts use as source citations, so this specific relation type might be pointless.

== Exemples d'Utilisation ==
From Email we get two basic relations between message:
* Reply - This message is a reply to the referenced message.
* Forward - This message forwards the referenced message to additional recipients.

From various publications (often of standards) we get:
* Updates/Obsoletes - This documents contains updates or even replaces the referenced document.

Citation of resources comes in several flavors:
* Quote
* Citing a reference
* Via link/Hat tip (mainly in blogs)