Affichage d'un groupe de ressources primaires dans 1 même page (notamment : traitement des ressources vidéo et audio liées par dc:relation)
sguillaume opened this issue · comments
Il arrive que des fichiers audio et vidéo soient liés (d'une autre manière que "dcterms:requires" et "dcterms:isrequiredBy" qui concerne principalement les annotations et les EGG).
Le lien est alors juste indiqué par "dc:relation".
Dans ces cas là il faudrait ajouter une règle pour que ces fichiers n'apparaissent pas tous dans la liste des ressources.
Il faudrait que le fichier vidéo apparaisse dans la liste des ressources et que le ou les fichiers audio associés n'apparaissent que dans la page de consultation de la ressource vidéo.
On pourrait voir sur la page de consultation de la vidéo qu'une ou plusieurs ressources audio existent et sont associées à cette vidéo et on pourrait télécharger les fichiers audio ainsi que consulter leurs métadonnées (partie gauche de la consultation de la ressource)
La recherche de pistes continue, y compris une réflexion sur l'encodage des relations dans les métadonnées de Cocoon.
L'enjeu est de bien afficher l'ensemble des ressources liées entre elles / l'ensemble des fichiers qui se rapportent à une même "prise" lors de la captation (enregistrement audio et vidéo fait simultanément + annotations).
La question concerne 2 niveaux du site : les pages de présentation des corpus (comment présenter la liste des ressources en regroupant celles qui sont liées entre elles), et les pages d'affichage des ressources.
Sur la page de présentation des corpus : regrouper sur une même ligne les ressources liées (comme si c'était la même ressource : c'est des ressources liées). (À l'heure actuelle on a l'audio et la vidéo qui apparaissent sur des lignes séparées). Détecter tous les "dc:relation" (entre ressources primaires) et "dcterms:isrequiredBy".
(Petite note savante : pas besoin d'avoir aussi '"dcterms:requires", le symétrique de "dcterms:isrequiredBy", qui est au fond redondant avec "dcterms:requires".)
Sur la page de consultation d'une ressource, il faut présenter en bon ordre ce "groupe de ressources". Un onglet pour chacune des ressources primaires : 1 par vidéo + 1 pour chacun des audio ? (vérifier la compatibilité avec le choix d'onglets pour les annotations aussi : ressources qui ont 2 fichiers d'annotation ou plus).
Quelle est la ressource qui apparaîtra comme la ressource "principale" ? Une forme de hiérarchie reste nécessaire.
- si on a 1 fichier vidéo : c'est lui qui est mis en avant
- si on a plusieurs fichiers vidéo : on met en avant celui qui a des annotations XML ; en cas d'ex aequo : plouf-plouf
- si on a 2 fichiers vidéo : plouf-plouf
- si on a n fichiers audio : on met en avant celui qui a des annotations XML ; en cas d'ex aequo : plouf-plouf parmi les fichiers audio.
Chacune des ressources peut avoir un titre spécifique.
On a n ressources audio, m ressources vidéo, p autres ressources ; et q annotations. On peut recommander de préfixer un titre qui soit commun, et spécifier. "Caravanes - vidéo", "Caravanes - micro serre-tête de la locutrice", "Caravanes - micro d'ambiance".
Affichage des DOI : le DOI qui s'affiche sur la page est celui de l'onglet choisi.
Pas de liens hiérarchiques entre ressources primaires : c'est une limite (choisie) du modèle de métadonnées OLAC.
Idée de @EdouardSombie : Puisqu'on en a besoin pour l'affichage dans Pangloss, on peut avoir un tableau des hiérarchies dans le site Pangloss.
Désigner la tête de gondole, et ordonner les autres ressources le cas échéant.
Inconvénient : un 2e niveau de métadonnées.
Avantage : c'est fonctionnel et se prête à des démos. Ca constitue un prototype qui peut ensuite être proposé à OLAC pour faire évoluer le modèle de métadonnées.
Option retenue. Ce qui peut être automatisé l'est : par exemple, s'il y a 2 fichiers WAV mais que l'un d'eux est un signal électroglottographique, on récupère l'info via les métadonnées (la méthode sera fournie par @sguillaume ). Ensuite un choix se fait parmi les "ex aequo", en mode "plouf-plouf", et une correction manuelle peut être apportée si besoin.
Affichage :
onglets en haut (les ressources primaires liées entre elles)
DOI
boutons des diverses annotations.
Si on met le doigt dans la question des relations possibles entre fichiers multimédia et transcription il faut faire un inventaire des situations possibles, de façon à ne pas adopter une solution qui sera mise en difficulté dès le prochain cas de figure.
Parmi les cas de figure il y a par exemple les prises de sons/vidéo en parallèle, le fait qu'un fichier multimédia soit une suite d'un autre (par exemple deux prises de vue), le fait qle fait que certains appareils de captation vidéo découpent en fichier successifs une même prise (pour éviter la limite de taille de 4GO de certains systèmes). Il faut pouvoir préciser quel est le fichier "principal" s'il y en a un et quels sont ceux qui sont "associés", et sans doute préciser ce que veux dire associé ici : une autre prise en parallèle ? un document annexe capturé indépendamment par quelqu'un d'autre et qui apporte un complément de point de vue ; les produits de différents appareils d'enregistrements spécialisés ; Des transformations des données selon certains algorithmes, etc.. Les prises en parallèle peuvent répondre à différentes fonction : audio de qualité pour l'analyse acoustique, vidéo fisheye pour l'analyse d'une interaction, etc.
Je pense qu'un travail d'inventaire des cas de figure pourrait être utile en préalable. De là pourra découler un modèle de données puis une stratégie de visualisation.
En effet, au-delà du premier niveau identifié (rassembler les différentes prises réalisées en même temps), il y a plein de liens possibles entre ressources.
Pour l'instant, c'est plutôt établi de façon non formalisée informatiquement : par des indications fournies dans le titre des documents concernés, dans la description-résumé qui en est donné...
Par exemple, en langue cuối chăm, il y a 11 documents, qui sont les 11 morceaux d'une même enquête de vocabulaire. C'est dit dans le titre de chacun des documents ("Vocabulaire cuối chăm, partie 1 sur 11", etc), mais il n'y a pas de lien établi au plan informatique entre ces 11 documents. Après, on s'y retrouve tout de même. Il n'y a que ces 11 documents dans le corpus cuối chăm, de sorte qu'il n'y a pas de risque qu'une personne qui visite le site rate certains documents.
Du coup, pour cette année (2022-2023), avant de mettre en train les 3 étapes que tu proposes (@sylvainloiseau) : inventaire des cas de figure, modèle de données, stratégie de visualisation, on va commencer par trouver une solution pour les cas problématiques identifiés. Ce sont des cas où il y a un risque d'induire en erreur la personne qui visite : liste de ressources pas claire, pas intelligible ; et page de consultation "tronquée" qui fait qu'on aborde une ressource "de traviole". Mais rien ne t'interdit en parallèle d'entreprendre une liste des cas de figure (qui aurait toutes chances d'être longue... et sans doute rester ouverte tant la diversité des situations est grande et évolutive avec les technologies).
Oui lister les cas de figure (prise successives, plusieurs enregistreurs parallèles, plusieurs enregistrements (version) d'un même stimulus, etc.) m'intéresserait bien ; si vous rencontrez des cas nouveaux, je veux bien que vous me montriez. Pour cette année, c'est plus sage en effet de faire une solution simple.
Edouard, nous ne pouvons pas appliquer la bijection dont nous avons parlé pour les groupes de ressources liées par une "relation".
Parfois 2 ressources peuvent être en relation avec une même ressource sans l'être du tout entre elles.
Il va falloir détecter les groupes de ressources liées par une simple "relation" entre elles autrement.
On en reparle.
J'ai peut être une idée. Peut être que l'on peut décider d'afficher les ressources par groupes quand elles suivent une certaine règle et d'afficher les autres séparément ? Mais je ne suis pas sûre que ça sera plus simple car il faudra distinguer les cas.
Après reflexion, je ne sais pas si toutes les personnes qui ont relié leurs ressources avec une simple relation souhaitent forcément qu'elles s'affichent ensemble.
Bon, on en reparle vendredi (peut être que d'ici là on aura une meilleure idée).
En attendant je te mets 2 exemples de ressources liées :
1er exemple (toutes les ressources sont liées entre elles) :
cocoon-e91226f5-3964-4582-9226-f5396495820c (video)
cocoon-12d5a712-340d-4bd6-95a7-12340dcbd625 (audio)
cocoon-13e01a35-3e04-4747-a01a-353e04c74706 (audio)
cocoon-58c95dc4-e1b2-421e-895d-c4e1b2821e7f (audio)
2ème exemple (les videos sont reliées uniquement à l'audio mais pas entre elle) :
cocoon-c64977f7-e39a-3b1b-87af-27f2daac028c (audio)
cocoon-77a89408-28f2-3313-8a5c-ac4286544507 (video)
cocoon-75aa2208-a754-354e-a28f-e5d44a9afa75 (video)
Solution retenue :
- mettre toutes les ressources en relation les unes avec les autres un peu librement
- et indiquer dans les métadonnées une information supplémentaire que l’on mettrait dans une balise
dc:type(qui permet d'indiquer un type de ressource de manière large).
On utilisera ce champ pour indiquer si la ressource en question est de type « principal » et ou si elle est de type « à afficher avec le fichier principal ».
Pour mémoire, termes proposés pour encoder l'info :
- dans les métadonnées Cocoon : un champ Dublin Core "
type" contiendra la valeur : "main" (en français : "principal"), ou "ancillary" (en français : "ancillaire").
Pour une ressource "ancillaire" ("ancillary"), il faudra un champ qui indique l'identifiant de la ressource "main" à laquelle elle se rapporte : son "main_identifier". Ce champ contiendra, pour chaque fichier ancillaire, l'identifiant OAI de la ressource principale concernée.
(Merci à l'équipe de Cocoon pour ces propositions !)
Proposition : "main resource for the dataset" et "ancillary resource".
Il faut conserver un peu de sens pour que les gens s'y retrouvent.
Validé ?
Les onglets sont bien présents quand on consulte une ressource faisant partie d’un groupe de ressources liées.
Par contre, les ressources ancillaires continuent d’apparaitre dans la page d’accès aux ressources alors que seules les ressources principales devraient.
Un exemple avec le na de yongning :
Il y a 2 ressources liées :
La ressource principale : https://doi.org/10.24397/pangloss-0004865 (titre : "ComingOfAge3. This is a conversational account, with Bima Lhaco acting as respondent.")
La ressource ancillaire : https://doi.org/10.24397/pangloss-0004866 (titre : Responses of Bima Lhaco (consultant F16) during F4's narrative: “ComingOfAge3”)
Dans chaque page on a bien les ressources regroupées et donc 2 onglets qu’on peut consulter.
Mais ces ressources apparaissent toutes les 2 dans la page d’accès aux ressources (https://pangloss.cnrs.fr/corpus/Yongning_Na?lang=fr&mode=pro) alors que seule la ressource principale devrait apparaitre.
En gros, les ressources ancillaires ne doivent jamais apparaitre dans la page qui liste les ressources d’un corpus.
Elles ne doivent apparaitre que dans un onglet de la page de consultation de la ressource principale.
Salut !
C'est en ligne :)
A bientôt
Edouard
C'est top ! :)