Table Of Contents 
- Mise en forme des objets
- Le modèle OAIS au SLDR : aperçu rapide
- Mise en forme élémentaire
- Limitations actuelles
- Différences entre l'objet d'origine et son SIP
- Différences entre les SIP et les AIP
- Différences entre l'AIP et le DIP
- L'interface du [SLDR] : présentation des objets, prévisualisation etc.
- Pour en savoir plus...
Mise en forme des objets
Cette page contient les informations destinées aux producteurs de ressources linguistiques souhaitant faire appel au SLDR pour leur archivage pérenne et leur diffusion.
La procédure à suivre se résume ainsi :
- Inscrivez-vous sur SLDR et attendez la validation de votre inscription.
Veuillez noter que ce site est réservé aux transactions non-commerciales, bien que certaines ressources puissent aussi faire l'objet d'une distribution commerciale par des services comme ELRA et le LDC avec qui nous coopérons (voir exemples :
http://sldr.org/crdo000770 et
http://sldr.org/crdo000035). De manière générale, ce service s'adresse aux organismes de recherche publique, aux universitaires, étudiants et chercheurs indépendants qui s'intéressent aux sciences du langage. - Créez une fiche décrivant l'objet que vous souhaitez sauvegarder/archiver/distribuer via SLDR. (
Voir les instructions) - Une fois que votre fiche a été validée, un administrateur vous contactera pour organiser le téléchargement des données. C'est à ce stade que les informations contenues dans cette page vous seront indipensables.
Le modèle OAIS au SLDR : aperçu rapide
SLDR est une implémentation du système d'archivage ouvert (Open Archival Information System, OAIS) qui fonctionne comme suit :
- Un objet est stocké sur le site et sa description détaillée (les métadonnées) est enregistrée dans une fiche de la base de données.
- L'accès à cet objet est possible immédiatement, si son producteur le souhaite, quel que soit son statut vis-à-vis de la diffusion ou de l'archivage pérenne.
- Après une décision commune des administrateurs et du producteur, l'objet est exporté vers le service d'archivage. Dans le jargon OAIS, l'objet numérique qui contient à la fois les fichiers et les métadonnées est appelé un Submission Information Package (SIP). Ce SIP est vérifié par la plateforme d'archivage au niveau de sa compatibilité avec un modèle décrit dans l'archive. Si le SIP est bien formé, dans le mode d'archivage pérenne, il est préservé par le CINES sous la forme d'un Archival Information Package (AIP) et le SLDR reçoit un certificat indiquant le succès de l'opération. En mode 'diffusion' aucun AIP n'est préservé.
- Dans les minutes qui suivent, la plateforme d'archivage transfère l'objet et ses métadonnées à la plateforme de diffusion. L'objet numérique qui contient à la fois les fichiers et les métadonnées est appelé un Distribution Information Package (DIP).
- Le DIP est traité par la plateforme de diffusion et stocké dans un espace spécifique auquel peuvent avoir accès les clients du SLDR moyennant les restrictions d'accès spécifiées dans ses métadonnées.
Dans le modèle OAIS développé à SLDR et CRDO-Paris sous l'égide de TGE-Adonis, la plateforme d'archivage est mise en œuvre par le Centre Informatique National de l'Enseignement Supérieur (CINES) et la plateforme de diffusion se trouve au Centre de calcul de l'Institut national de physique nucléaire et de physique des particules (CC-IN2P3). Ces deux grands centres de calcul sont distants de plusieurs centaines de kilomètres l'un de l'autre et des services versants. L'archivage pérenne fait l'objet de conventions signées entre le CINES, la Direction des archives de France (SIAF) et le CNRS. La plateforme de diffusion proprement dite est implémentée dans l'environnement
Fedora-commons et son interaction avec le SLDR est (pour des raisons de sécurité) entièrement invisible aux utilisateurs.
Les utilisateurs du SLDR peuvent tout ignorer du processus qui vient d'être brièvement décrit, ainsi que des centres de calculs assurant les fonctions d'archivage et de diffusion. En effet, il n'y a pas de modification significative des opérations d'authentification ni de l'accès aux objets, que ceux-ci soient disponibles sur le
site du SLDR ou sur la plateforme de diffusion après avoir été archivés. Pour cette raison, les informations qui suivent n'ont d'importance que pour les producteurs des objets. Elles leur permettront de faire le meilleur usage des ressources disponibles, plus particulièrement lorsque les objets à partager sont générés par des projets en cours d'exécution.

Mise en forme élémentaire
Pour chaque objet, les producteurs doivent préparer deux répertoires principaux contenant les données numériques (son, vidéo, texte, images etc.) :
- Un répertoire DATA (voir figure à gauche) qui contient tous les fichiers à archiver et à distribuer sous la
licence du SLDR. Ces fichiers peuvent être placés dans une hiérarchie de répertoires avec (en option) des fichiers index-xx.html qui décrivent leur contenu (où 'xx' désigne le code de la langue : en, es, fr ou zh). Il n'y a aucune restriction au nombre ni à la profondeur des répertoires, ni à la longueur et au style des noms de fichiers ou de répertoires pourvu qu'ils utilisent l'encodage Unicode (UTF8). Le script d'archivage réorganisera automatiquement cette hiérarchie et renommera les fichiers et répertoires, de manière totalement invisible aux utilisateurs et aux producteurs. (Cette transformation garantit le respect de contraintes propres aux plateformes d'archivage et de diffusion.) D'autre part, une fois l'objet archivé, le système du SLDR génèrera une page de téléchargement sur laquelle apparaîtront la hiérarchie et les noms de fichiers/répertoires d'origine.

- Un répertoire PREVIEW (voir figure à droite) qui contient les fichiers nécessaires à l'accès libre aux données, par exemple des fichiers MP3 accessibles en streaming. Si l'objet est entièrement en accès libre, ce répertoire PREVIEW doit contenir des copies de tous les fichiers, et le répertoire DATA peut être vide.
Trois répertoires annexes peuvent être ajoutés :
- §licence contiendra tout ce qui concerne une licence supplémentaire spécifique de l'objet.
- §autorisations contiendra les forumulaires de consentement signés par les participants. Ces formulaires peuvent être anonymisés, dans ce cas les originaux sont archivés dans un répertoire SECRET inaccessible aux utilisateurs.
- §doc contiendra des documents descriptifs annexes, distincts des données proprement dites, et susceptibles de révision périodique.
Limitations actuelles
- La limite de volume du répertoire DATA est de 500 (cinq cent) Giga-octets. Ceci inclut les fichiers 'zip'/'tar' créés si nécessaire pour permettre le téléchargement en un seul clic de répertoires importants.
- Tout objet de taille supérieure à 50 (cinquante) Giga-octets ou contenant plus de 30000 fichiers sera fragmenté en plusieurs segments compatibles avec les limites des systèmes d'archivage et de diffusion. Toutefois, cette fragmentation restera invisible aux utilisateurs car le point d'accès aux fichiers restera unique.
- Les contraintes sur la profondeur des répertoires et les longueurs de noms de fichiers sont celles en cours sur le systèmes informatiques récents. Les noms de fichiers doivent être encodés en Unicode (UTF8).
Différences entre l'objet d'origine et son SIP
Dans le cas de projets en cours d'exécution, les producteurs peuvent avoir besoin de stocker des données sur le site du SLDR sans que celles-ci soient transmises aux plateformes d'archivage et de diffusion. La règle suivante est prise en compte par le SLDR : tout fichier ou répertoire dont le nom commence par '_' (signe de soulignage) est ignoré par le script produisant les SIPs pour la plateforme d'archivage.
La plateforme d'archivage a ses propres restrictions concernant les formats de fichiers. Elle doit vérifier la conformité de tout fichier avant de l'accepter pour l'archivage pérenne. Cette précaution vise à ce que les données puissent encore être lues et interprétées par des machines (et des humains) dans plusieurs centaines d'années ! Dans l'implémentation actuelle, des formats bien connus comme MP3, ZIP, MS-Word DOC/DOCX/RTF, ZIP, TAR etc. ne sont pas acceptés. (Voir le validateur FACILE du CINES.) Afin que ces données non-archivables soient quand même disponibles sur la plateforme de diffusion, il faut faire en sorte qu'elles soient redirigées par la plateforme d'archivage sans générer de message d'erreur. Cette transmission est assurée par le répertoire DIFFUSION (voir ci-dessous).
Les formats couramment acceptés en archivage pérenne sont listés ici : http://crdo.aix.fr/wiki/Developpement/Formats.
Différences entre les SIP et les AIP

Le SIP est divisé en deux parties principales (voir figure à droite) :
- Le répertoire DEPOT contenant tous les fichiers à envoyer à l'archivage pérenne ;
- Le répertoire DIFFUSION contenant tous les fichiers qui ne sont pas destinés à l'archivage pérenne mais seront transmis (sans vérification) à la plateforme de diffusion.
Le choix entre ces répertoires n'est pas fait par le producteur mais par le script d'archivage qui utilise pour cela les critères suivants :
- Tout fichier/répertoire contenu dans un répertoire nommé 'TEMP' sera transmis via le répertoire DIFFUSION. Ceci permet aux producteurs d'éviter d'archiver des fichiers de très forte taille qui risquent d'être périmés une fois le projet terminé. Les producteurs et les administrateurs doivent garder en mémoire le fait que toutes les versions d'un objet sont archivées indéfiniment sur la plateforme.
- Tout fichier dont le format est compatible avec la plateforme d'archivage sera transmis via le répertoire DEPOT.
- Tout fichier dont le format n'est pas compatible avec la plateforme d'archivage sera transmis via le répertoire DIFFUSION.
- Tout fichier contenu dans un répertoire nommé 'PERMANENT' ou dans un répertoire 'stream' est archivé avec son nom d'origine précédé du chemin d'accès, le tout étant toutefois corrigé pour compatibilité avec les limites de Fedora Commons concernant les noms de datastreams. Entre autres, le nom de fichier ne contiendra pas plus d'un point, ce qui fait que par exemple "MonFichier.2.0.pdf" sera remplacé par "MonFichier.pdf". Ce dispositif est pratique pour pérenniser les URLs de fichiers accessibles en accès ouvert malgré le dépôt de nouvelles versions de l'objet.
Pour déterminer le format d'un fichier, le script d'archivage examine son extension (avec la possibilité de variantes comme 'aif'/'aiff', 'jpeg'/'jpg' etc.). Pour tout objet il est aussi possible de dresser une liste d'extensions spécifiques de fichiers qui doivent être traités comme du texte Unicode (UTF8). (Par exemple, bjw, gok, strings, sta, dic, 6 pour
Aix-MARSEC.) Dans une telle liste, l'indication '(none)' signifie que tout fichier sans extension est aussi un fichier texte Unicode.
Ni les utilisateurs ni les producteurs n'ont besoin de savoir par quel répertoire une donnée a été transmise. En effet, à la fin du processus OAIS, la hiérarchie de l'objet affichée sur la page de téléchargement est exactement celle de l'objet d'origine.
Différences entre l'AIP et le DIP
- Tous les fichiers contenus dans le répertoire DIFFUSION sont transmis à la plateforme de diffusion sans être validés par le système d'archivage.
- Un fichier contenant des informations confidentielles est stocké par le système d'archivage sans être pris en compte par la plateforme de distribution.
- Un fichier public.xml est généré automatiquement dans le répertoire DEPOT/DESC pour donner la liste des fichiers (représentés sous Fedora par leurs datastreams) qui devront être en accès ouvert sur le serveur de diffusion (sans authentification ni filtrage). La mise en pratique de la gestion des droits d'accès est décrite sur la page Réglage des droits d'accès.
L'interface du SLDR : présentation des objets, prévisualisation etc.
Les dispositifs permettant d'améliorer la présentation des objets et la prévisualisation des données (« vitrine ») sont décrites sur la page Présentation des objets.
Pour en savoir plus...
L'archivage numérique à long terme - les débuts de la maturité ? (Françoise Banat-Berger, Laurent Duplouy et Claude Huc). DAF / La Documentation française, 2009.- Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)
Flexible Extensible Digital Repository Architecture (FEDORA)
OAIS Reference Model (pdf)
