Read the current page with ALL its highlights

[benel]

Because highlights are from different and incompatible viewpoints, the color is:

• either the same for all (i.e. yellow as in LaSuli v2),
• or depends from the viewpoints (not the topics).

Contrary to v2, the display is not automatic. The user has to click the extension button before highlights are shown.

Here is a TODO list to achieve this:

• [x] When the user clicks, modify the page (e.g. with the number of fragments) [messages between scripts].
• [x] When the user clicks, display all highlights in the text with a single colour [highlights overlay algorithms from the research paper],
• [x] When the user clicks, display all highlights in the text with a colour corresponding to the viewpoint [colors cycle formula, and colors addition on overlays],
• [x] When the user clicks, display also a side panel with the mapping between colors and viewpoints titles [reactjs side bar, async requests to the corresponding viewpoints].
• [x] When the user clicks, in the side panel display also the other viewpoints used in the corpus [async requests to the corpus, filter, and async request to the corresponding viewpoints].

[florentpergoud]

J'ai une question à propos des couleurs de highlights. Dans la v2 que je viens de telecharger :

• Il est impossible d'afficher plusieurs Viewpoints en même temps.

• Les couleurs de surlignage dépendent des "Catégories d'analyse" tel que les deux couleurs sur cette capture. Les catégories d'analyse sont bien ici les topics ?

• Ainsi, les différentes couleurs à afficher dépendent bien des topics et non des viewpoints ?

[benel]

Dans les deux versions, il y a deux modes d'affichage : un sans avoir sélectionné de point de vue, l'autre en en ayant sélectionné un.

Ces deux affichages correspondent à deux fonctionnalités différentes. Ce fil correspond au premier affichage. Le second correspond à la fonctionnalité #46.

Dans la v2 :

• pour le premier affichage, tout est en jaune,
• pour le second, les couleurs dépendent des thèmes (cf. votre copie d'écran qui correspond donc à l'autre fonctionnalité, la suivante dans l'ordre de priorité).

Pour la v3 :

• pour le premier affichage, la couleur dépendra des points de vue,
• le second affichage sera identique à celui de la v2.

[florentpergoud]

Merci pour ces précisions !

[gnoxr]

Je pensais être au point sur le récupération des points de vue d'un corpus :

1. Quand on récupère les items associés à une ressource à l'adresse /item/?resource=<uri>, chaque item renvoyé est un objet {corpus, id}
2. On peut récupérer les fragments de cet item à l'adresse /item/<corpus>/<id>
3. On peut récupérer le corpus de cet item à l'adresse /corpus/<corpus>

Problèmes :

• Pour la troisième étape, le point d'entrée /corpus/<corpus> est fermé sur Steatite (nécessite authentification).
• Sur le document que j'utilise pour tester, les corpus sont sous la forme "Marques-pages de \<user>", et les points de vue de ces corpus n'ont pas de lien sémantique.
• Les données d'IF14 font plusieurs Mo et mettent longtemps à charger de chez moi (entre 5s et 40s)

On en reparlera j'imagine jeudi.

[benel]

On peut récupérer les fragments de cet item à l'adresse /item// On peut récupérer le corpus de cet item à l'adresse /corpus/

Notez qu'en théorie, il est inutile de faire les deux requêtes à la suite puisque la réponse à la première est entièrement contenue dans la réponse à la seconde.

Pour la troisième étape, le point d'entrée /corpus/ est fermé sur Steatite (nécessite authentification).

Vous voulez dire sur Cassandre (et non Steatite) ? En effet, LaSuli v3 sera uniquement utilisé pour annoter des textes (et non plus des images).

Les données d'IF14 font plusieurs Mo et mettent longtemps à charger de chez moi (entre 5s et 40s)

Sur le même réseau, la requête proprement dite (sans affichage ni stockage en mémoire) prend environ 1,6 s sur Argos et 1,3 s sur Cassandre.

C'est beaucoup, même si ça reste raisonnable. Il faut noter que le corpus IF14 est un corpus "limite" : au lieu de correspondre à une seule étude, comme ça devrait être le cas, c'est la concaténation de toutes les études de tous les étudiants sur toutes les années... Probablement que l'on s'organisera différemment les années prochaines par exemple en ayant un corpus par groupe de TD (ex : TD d'IF14 des mardis d'A18).

Quelques pistes (au-delà du fait de choisir un autre corpus) :

• commencer l'affichage avant d'avoir reçu la réponse des corpus (qui peut se faire attendre et n'est de toute façon qu'une manière en mode édition de choisir un nouveau point de vue),
• utiliser les méthodes fonctionnelles de traitement de données (notamment .filter() et .reduce()) pour réduire très rapidement la taille des données que l'on parcourt,
• voir si on peut jouer sur la portée locale des variables en ES6 pour libérer la mémoire rapidement.

[gnoxr]

J'ai spécifié Steatite car c'est le serveur secondaire actuellement utilisé (y compris dans le code de la v3) :

let db = require('hypertopic')([
  'http://argos2.hypertopic.org',
  'http://steatite.hypertopic.org'
]);

Si je remplace Steatite par Cassandre, les corpus obtenu ont beaucoup plus de sens. Merci pour ce retour.

[gnoxr]

À propos de la sidebar :

• Les appels à la fonction de la sidebar sont asynchrones
• Attendre pour une fonction asynchrone « casse » la pile d'appels
• Firefox nécessite que les appels à la sidebar soient gérés depuis un handler d'action utilisateur
• Si la pile d'appels est cassée, on ne peut pas faire d'autres appels à la sidebar
• Le toggling est donc impossible ; le deuxième appel (open/close) sera refusé

let sidebar = browser.sidebarAction;
if (await sidebar.isOpen({})) {
  sidebar.close();
} else {
  sidebar.open();
}