distributed-conversation-formats-fr: Difference between revisions
m (→Email/Usenet) |
|||
Line 33: | Line 33: | ||
===IBIS - Issues Based Information Systems=== | ===IBIS - Issues Based Information Systems=== | ||
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 | * [http://dannyayers.com/xmlns/ibis/ vocabulaire IBIS] | ||
* [http://collab.blueoxen.net/forums/yak/2003-12/threads.html#00191 | * [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)] | ||
Le modèle hypertexte d'IBIS comprend trois types de noeuds : | |||
1. issues | 1. issues | ||
2. positions | 2. positions | ||
3. arguments | 3. arguments | ||
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''' | ||
Comme pour TDL, IBIS semble tacler un plus gros problème que celui discuté ici. | |||
* | * 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. | ||
* | * 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 === |
Revision as of 16:42, 16 August 2006
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 RFC2076 - Common Internet Message Headers section 3.6 :
- In-Reply-To - Référence vers un message dont ce message est un "reply to".
- 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 - Références vers d'autres articles en rapport dans Usenet News.
- Obsoletes - Référence au message précédent étant corrigé et remplacé.
- 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 - Seulement dans Usenet News, similaire à "Supersedes:" mais ne provoque pas le fait que l'article référencé soit effacé physiquement.
- Article-Names - Référence vers articles tout particulièrement importants pour un Newsgroups spécifique Usenet.
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.
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
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. (Weblog Kitchen)
Le modèle hypertexte d'IBIS comprend trois types de noeuds : 1. issues 2. positions 3. arguments Huit types de lien représentent les relations autorisées entres ces noeuds : 1. generalises 2. specialises 3. replaces 4. questions 5. is_suggested_by 6. responds_to 7. objects_to 8. supports
Discussion à propos d'IBIS
Comme pour TDL, IBIS semble tacler un plus gros problème que celui discuté ici.
- 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.
- 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) 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.
Relevant properties defined under 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)