distributed-conversation-formats-fr

reltatr

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.

• 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

1. respondsNegativelyTo, respondsPositivelyTo are beyond the scope of this spec. They can both be implemented using vote-links.
2. Without those, respondsTo remains the main connector between posts in a thread.
3. mentions and discusses seem to be splitting hairs. It appears that both of them can be replaced by using the CITE tag.
4. 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)

• vocabulaire IBIS
• Comment démarrer une discussion IBIS dans l'e-mail
• graphical IBIS (gIBIS)

 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) 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/spec/

Propriétés pertinentes définies sous SIOC :

• 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 - Liens vers un Billet précédent, dont ce Billet est une répique de (ou vers).
• next_version - Liens vers la prochaine révision de ce Billet.
• previous_version - Liens vers une précédente révision de ce Billet.
• 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 - 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 - Un URI de la pièce jointe apparentée à un Billet.
• related_to - Billets apparentés pour ce Billet, peut-être déterminés à partir des thématiques ou références.
• is_closed - Détails si c'est (et n'importe quels enfants) fermé.

Discussion of SIOC

• 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 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.
• 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 pourrait être intéressant mais est-ce nécessaire ?
• 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

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.
• Forward - Ce message transfère le message en référence vers des destinataires additionnels.

A partir de différentes publications (souvent de standards) nous obtenons :

• Updates/Obsoletes - Ce document contient des mises à jour ou même remplace le document référencé.

La citation de ressources arrive sous plusieurs formes :

• Quote
• Citer une référence
• Via lien/Hat tip (essentiellement dans les blogs)