hypertopic / protocol Goto Github PK

Un objet par utilisateur (et point de vue ? ou item ? ou corpus ?) :

• contiendrait les triplets : (item (ou fragment), topic, user),
• sorte de scope (cf. Topic Maps),
• ferait d’Hypertopic un vrai modèle hybride « folksonomie ET facettes hiérarchiques »,
• permettrait de savoir qui a associé le topic à un item (ou fragment) quand le point de vue est collectif,
• règlerait le problème des droits de mise à jour,
• rendrait plus logique le lieu d’enregistrement des fragments,
• résoudrait le problème du lieu d’enregistrement des motifs de Cassandre.

Nous avons opté pour le dépôt d'une source à la fois sur Steatite (pour les images) et Cassandre (pour les textes). Ce choix me semble correspondre à l'usage (la composition patiente et progressive d'un corpus).

Cependant, les utilisateurs souhaitent parfois, au terme de leur travail, retirer un corpus entier de notre plateforme. L'administrateur a-t-il la possibilité, sous CouchDB, de supprimer d'un coup les quelques dizaines (voire centaines) de sources concernées ?

L'environnement Traduxio actuel (appelons le TraduXio 1) est une plateforme collaborative de traduction multilingue et de précision. Pour l'instant, son fonctionnement est indépendant du protocole Hypertopic, mais les deux projets ont vocation à se rejoindre: quand et sous quelle forme, avec quelles promesses, limites et impossbilités.
Question symétrique: quelles sont les futures étapes du développement de TraduXio qui sont susceptibles d'être compatibles avec une "convergence" vers Hypertopic : la visualisation des points de vue différents sur une traduction, l'annotation collaborative multi-points de vue, etc. ?

Création de la documentation de la fonctionnalité Créer un marqueur

The user name is currently notified only once to the user : on the webpage, when he choose his/her password. Unfortunately, many users hit the button without reading the username. They worry about their username so sooner than when requested by our platform.

I suggest that the user name will be notified in the invitation mail so that the user can keep it in the future.

L'ensemble de la platerforme Hypertopic poursuit, entre autres buts, de documenter le travail d'analyse des chercheurs en sciences humaines. Il s'agit d'être en mesure de montrer les documents étudiés ainsi que la façon dont ils sont "annotés" par différents chercheurs. L'idée de "traçabilité" d'une recherche en cours est difficilement séparable du cahier de laboratoire ou du journal de bord. Selon moi, le "carnet de bord" fait donc partie de notre programme de recherche. Un tel journal pourrait bien entendu être "généré" à partir des "log" de nos applications. Mais il ne devrait pas se limiter à ces traces formelles d'activité et fournir un espace d'écriture aux chercheurs. Cet espace permettrait de consigner à la fois la raison d'être des "annotations", les lectures (théoriques) qui les ont inspirées, les différentes pistes suivies, les raisons pour lesquelles une de ces pistes est infléchie (voire abandonnée), etc.
Que faire d'une telle idée ?
Est-elle reconnue comme utile par plusieurs d'entre nous ?
S'agira-t-il de développer un nouvel outil ? De l'intégrer à un outil existant ?

URI could be named after what is represented instead of being named after the parameter.

Example:

• /item/?resource=<URI> would be a list of items (rather than the current list of items IDs),
• /highlight/?corpus=<ID> and /item/?corpus<ID> would replace /corpus/<ID> for both the items and highlights part,
• /viewpoint/?portfolio=<ID> and /viewpoint/?corpus=<ID> would get list of viewpoints that requires for now several requests and data processing,
• etc.

This makes bookmarking more difficult.

Argos and the Hypertopic library (in Porphyry and LaSuli) implements references from viewpoints to items and highlights while the protocol does not specify this.

For better privacy.

Il y a quelques mois déjà, nous avons été sollicités par des étudiants sur notre expérience avec Dolomite. Ce contact nous donnait la possibilité d'exprimer notre satisfaction, nos besoins, nos suggestions. Quelles suggestions de la communauté des 'dolomitiens' ont-elles été retenues dans le cahier des charges de Dolomite (et/ou d'un autre outil de notre plateforme) ?

Les plateformes d'analyse qualitative de textes ou d'images ont la cote ! Chacune traite la question de la confidentialité des données privées à sa façon. Saturate reste relativement évasif. Dedoose joue la carte de la sécurité bancaire. Qu'en est-il d'Hypertopic ?

Si, en la matière, l'Europe est moins regardante que le Canada, nous sommes de plus en plus souvent interpelés à ce sujet lors de nos présentations. Ce fut le cas à Montréal en septembre 2008, à Liège en juin 2011, à SciencePo (Paris) en novembre 2011.

Il existe plusieurs positions intermédiaires entre la sécurité bancaire et l'ouverture totale. Cette question n'est sans doute pas prioritaire, mais elle est à la fois politique et stratégique. La réponse que nous lui donnerons a des conséquences sur différents plans.

• Pédagogique L'ouverture totale (situation actuelle pour Cassandre 2) reporte la question sur l'utilisateur (à qui il est implicitement conseillé de n'analyser que ce qu'il peut effectivement partager). Cette situation n'est pas nécessairement une faiblesse. À l'heure de Facebook, il peut être en effet utile de faire réfléchir nos utilisateurs sur ce qu'est une 'publication'.
• Épistémologique Notre projet de recherche me semble lié à un plaidoyer pour le partage des sources. Une compartimentation sécurisée peut donc être contre-productive. Mais comment sensibiliser nos utilisateurs à ce point ?
• Logistique Nous avons sans doute mieux à faire que passer notre temps à développer une sécurité inviolable...

Quelle est la relation entre CouchDB et Hypertopic?