CRDO —> SldrWiki —> SLDR_FR —> Developpement_fr —> Journal
Subject: Passage en production CRDO
Date Sent: Saturday, June 19, 2010 1:56
From: Bernard Bel
To: Olivier Rouchon (CINES), Pascal Dugénie (TGE-Adonis), Michel Jacobson (SIAF), Pierre-Yves Jallud (CC-IN2P3), Séverine Guillaume (Lacito)
CC: Stéphane Pouyllau (TGE-Adonis), Alexis Michaud (Lacito), François Jacquesson (Lacito), Philippe Blache (LPL), Boyd Michailovsky (Lacito), Martine Mazaudon (Lacito)
Bonjour,
Lors de la journée de travail au Lacito aujourd'hui, nous avons fait le point sur les questions en suspens concernant la fusion des composantes CRDO,tout en essayant de distinguer celles qui devraient impérativement être réglées avant le passage en production de celles qui pourraient être réglées plus tard via de simples mises à jour de métadonnées.
Précisons tout de suite qu'il y a un consensus entre Lacito et LPL sur l'intérêt de passer en production le plus vite possible, pour diverses raisons qu'il n'est pas nécessaire d'expliciter. C'est pour cette raison que certains points qui nécessiteraient plus ample discussion pourraient être réglés ultérieurement, avec mise à jour de métadonnées même si ça demandera plus de manipulations. Par contre les points à régler en amont sont ceux qui touchent à l'irréversibilité de l'archivage pérenne. Il serait irréaliste par exemple de décider qu'après quelques mois un service versant devra redéposer une nouvelle version de tous ses objets, ce genre de manipulation étant infiniment plus lourde qu'une simple mise à jour des métadonnées.
Commençons par les points qui ne me paraissent plus poser problème vis-à- vis de la mise en production :
1. Fichiers de grande taille : mon test d'un objet de 50 Go vient de passer avec succès suite aux ajustements de Pascal ; s'il s'affiche correctement dans Fedora, je déposerai une 2e version d'environ 70 Go pour vérifier qu'elle passe sans intervention humaine.
2. Format AAC : je n'ai pas de nouvelles mais ça n'empêche pas de démarrer la production. Il faudrait juste que ce soit sur l'agenda du Cines, à court terme, car ce format va être très répandu pour certains corpus.
3. Objets contenant un grand nombre de fichiers : je vais relancer le test car la correction de (1) aura peut-être résolu ce problème.
Les points en suspens mais qui pourraient être réglés plus tard via les métadonnées :
4. Le fichier XML contenant les métadonnées "métier", que nous transmettons dans le répertoire DEPOT/DESC, aurait intérêt à toujours porter le même nom, par exemple "olac.xml" (on peut en choisir d'autres) et il devrait être basé sur une DTD accessible de manière pérenne comme par exemplehttp://www.language-archives.org/OLAC/1.1/olac.xsd
S'il y a des raisons d'ajouter des métadonnées autres que OLAC basées sur une autre DTD, il faudrait les exposer et en discuter. L'homogénéité entre les métadonnées "métier" des services versants est indispensable puisqu'elles pourront ainsi être moissonnées directement sur le site de distribution. (Pour cette raison aussi nous déclarons systématiquement "olac.xml" en accès ouvert.)
5. Je réitère l'importance d'attribuer un index unique crdoXXXXXXX aux objets de tous les services versants afin qu'il soit facile de rassembler les métadonnées puis de lancer des requêtes génériques renvoyant vers les labos producteurs, comme celles qui sont déjà implémentées :http://crdo.fr/wiki/Redirections
La question du changement d'identificateur OAI pour les objets de CRDO-Paris me paraît obscure et il se peut que ce problème doive être réglé ultérieurement - l'id OAI n'étant pas obligatoirement construit à partir de l'index unique.
Le point qui pose vraiment problème est celui de l'unification de l'espace de distribution. Si le CC-IN2P3 déclare qu'il sera possible ultérieurement de fusionner les espaces CRDO-Aix et CRDO-Paris en un espace unique CRDO, on peut démarrer avec des espaces distincts et reporter la discussion des méthodes permettant de gérer les restrictions d'accès sur les objets "privés". Dans le cas contraire, il faut se mettre d'accord tout de suite. Pour cette raison, j'avais exposé le problème et présenté en détail des solutions sur la pagehttp://www.tge-adonis.fr/wiki/index.php/QuestionsEtSolutionsCrdo. (Voir copie)
Si on travaille avec un espace Fedora unique pour les deux services versants, il faut faire en sorte que tous les cas de figure de restrictions d'accès puissent être gérés. Les questions à régler sont les suivantes :
6. Actuellement un filtrage IP est en place, il est question de développer une autre solution basée sur l'authentification XACML : est-ce qu'une des solutions exclut l'autre ?
7. Dans la solution que j'ai exposée (et testée) "tout est fermé par défaut" et on ajoute un fichier de configuration "public.xml" donnant la liste des datastreams en accès ouvert. Dans le cas des objets en libre accès versés par CRDO-Paris il suffirait que ce fichier contienne les noms de tous les fichiers constitutifs de l'objet (cf exemple sur la page wiki). Y aurait-il un avantage technique à faire l'inverse : "tout est ouvert par défaut" et on donne la liste des datastreams à soumettre au filtrage IP ?
8. Si CRDO-Paris souhaite mettre en place une solution basée sur XACML authorization de Fedora, et si l'espace de distribution est unique, il devrait anticiper cette mise en place en déposant dans DESC une information caractérisant les objets en accès privé. Mais peut-être devrions-nous élaborer un peu plus le fichier "public.xml" (en lui donnant un autre nom) afin qu'il soit possible, pour chaque fichier, de déclarer s'il est en accès ouvert, accessible via le filtrage IP ou contrôlé par XACML.
A part ça, j'ai pris pas mal de notes au cours de notre discussion d'aujourd'hui et certaines suggestions vont immédiatement être implémentées sur crdo.fr comme par exemple celles qui concernent les "communautés d'utilisateurs".
Bernard
