CoherenceOAIS

SLDR —> SldrWiki —> SLDR_FR —> Questions en attente

Questions de cohérence du modèle OAIS

Synthèse de discussions avec le CINES et TGE-Adonis

13 septembre 2011

1. Proposition SLDR. Le service d'archivage est supposé transmettre au service de diffusion le répertoire DIFFUSION tel qu'il l'a reçu, sans analyser son contenu. Lorsque nous faisons une mise à jour de métadonnées il est parfois nécessaire de transmettre via DIFFUSION des fichiers descriptifs qui ne peuvent pas transiter par DEPOT/DESC parce qu'ils sont dans des formats non-archivables. Le CINES accepte les dépôts de mises à jour de métadonnées dont le répertoire DIFFUSION n'est pas vide, et il les transmet donc vraisemblablement au CC-IN2P3. Or leurs contenus ne sont pas ingérés dans Fedora. Par souci de cohérence - tout document accepté et/ou transmis par le service d'archivage doit être pris en compte par le service de diffusion - il faudrait configurer Fedora pour ingérer ces fichiers reçus.

21 septembre 2011

1. Proposition SLDR. Vérification de l'identifiantSourceRelation : si le CINES ne vérifie pas l'existence de l’identifiant producteur dans sourceRelation, il ne faut pas que le service de diffusion le fasse, comme c'est le cas maintenant. En effet, en cas de fausse déclaration l'objet est archivé au CINES mais il se "perd en route" lors du transfert vers le service de diffusion. Le service versant n'en est pas informé, outre que cela constitue une incohérence dans le modèle OAIS. A la rigueur, le service de diffusion pourrait signaler le problème au service versant afin que l'incohérence soit rattrapée à l'occasion d'une mise à jour de métadonnées ; toutefois il n'a pas été prévu de mécanisme pour envoyer un diagnostic du service de diffusion vers le service versant - l'interlocuteur exclusif du dépôt étant le CINES.
2. Proposition SLDR. Vérification du versionnage : c'est à peu près le même problème. Le service de diffusion ne devrait pas refuser un objet dont le numéro de version n'est pas celui attendu, sous peine de rejeter un objet archivé. Il est probable que le service de diffusion utilise les numéros de version pour construire la relation inverse de filiation : alors que dans l'archive (au CINES) on ne dispose que de la relation enfant->parent, sous Fedora Commons on a aussi besoin de parent->enfant. Dans ce cas il faudrait modifier l'algorithme d'ingestion de telle manière que si l'objet de version "v - 1" n'existe pas on accroche la relation à l'objet de version "v - 2", etc., ceci afin de combler un éventuel trou dans la numérotation du versionnage. Bien entendu, le service versant doit veiller à la continuité, mais si cette continuité était rompue de manière accidentelle cela ne devrait pas entraîner la disparition du paquet d'informations (DIP) entre le service d'archivage et le service de diffusion.

29 octobre 2011

Le dépôt sldr000776_v1_1 est bloqué à l'ingestion dans Fedora alors qu'il a été validé par le CINES, idPAC = 216874.

31 octobre 2011

Le dépôt sldr000763_v2_1 (version 2 de crdo000763) est bloqué à l'ingestion dans Fedora alors qu'il a été validé par le CINES.

Explication (P.-Y. J.) : [...] le problème du dépôt sldr000763_v2_1 a été traité manuellement. En effet, il existe dans ce dépôt un identifiant "identifiantDocProducteur" qui fait référence à sldr000763. Or, cet identifiant est crdo000763 dans le dépôt référent d'idPAC 6536 (crdo et non sldr). J'ai bien conscience que ce changement est du à un changement du nom de votre structure, mais ce n'avait pas été pris en compte dans le traitement pour la diffusion, même si ce n'est pas un problème pour l'archivage côté CINES. Je suis en train de reprendre les développements sur la plateforme de diffusion, mais je ne peux pas actuellement traiter ces modifications en urgence. Cette correction sera réalisée dès que possible.

De ce fait, je vous demanderai donc de maintenir vos identifiants "identifiantDocProducteur" en "crdoXXXXX" dans vos futurs dépôts jusqu'à ce que la correction soit faite. Sans quoi, le dépôt ne pourra être traité.

Réponse le 2 novembre : Pour le dépôt sldr000763_v2_1, il n'y a pas d'erreur sur "identifiantDocProducteur" qui est la référence de l'objet dans la version déposée. Il est précisé que cet objet est une version d'idPAC 6536, ce qui est mentionné ainsi dans le DC d'archivage :

<docRelation>
   <typeRelation>version</typeRelation>
   <sourceRelation>PAC</sourceRelation>
   <identifiantSourceRelation>6536</identifiantSourceRelation>
</docRelation>

(Voir http://sldr.org/SLDRdata/aip_archive/000763_v2/aip_1.xml)

L'identifiant producteur de la première version (crdo000763) n'a pas été précisé car cette information est optionnelle. Sinon nous aurions indiqué :

<docRelation>
   <typeRelation>version</typeRelation>
   <sourceRelation>Producteur</sourceRelation>
   <identifiantSourceRelation>crdo000763</identifiantSourceRelation>
</docRelation>

Donc "crdo000763" peut figurer dans "identifiantSourceRelation" mais certainement pas dans "identifiantDocProducteur".

Récemment (21 septembre, voir http://sldr.org/wiki/CoherenceOAIS) nous avons éliminé la valeur "Producteur" de "sourceRelation" pour éviter que l'ingestion dans Fedora soit bloquée par une incohérence alors que le SIP a été validé par le CINES qui ne vérifie pas le lien entre idPAC et idProducteur. Nous pouvons réintroduire cette redondance en allant chercher l'identifiant producteur dans son aip.xml, mais cela ne résoudra pas le problème de l'ingestion dans Fedora qui impose (de manière erronée) que toutes les versions aient le même identifiant producteur.

Nous avions abordé cette question en réunion et conclu que les liens de paternité (et notamment de version) devraient être construits à partir des idPAC et non des identifiants producteurs. (Ne pas oublier que dans la relation de type "version" le lien de paternité pointe vers la première version et non vers la version précédente de l'objet.)

On ne peut pas écarter la possibilité qu'un service versant modifie son système d'identification après avoir déposé des objets en archive pérenne. Les objets déjà déposés conservent leurs anciens identifiants, mais les nouvelles versions de ces objets devront suivre le nouveau système, ne serait-ce que pour la cohérence du référencement : identifiants OAI, portails etc. Cette flexibilité est conforme au plan d'archivage du CINES.

Ceci dit, pas de problème pour modifier manuellement le sip.xml en attendant que ce problème ait été réglé dans Fedora.

15 novembre 2011

Un nouveau dépôt de l'objet sldr000776 (sldr000776_v1_1bis) est bloqué à l'ingestion dans Fedora alors qu'il a été validé par le CINES, idPAC = 218333. L'ingestion est bloquée par la taille excessive de fichiers 'zip' qui provoque des time-outs sous Fedora.

Ce problème est réglé manuellement le 22 février 2012 mais la question de la taille limite des fichiers reste à étudier. Nous avons proposé, comme solution partielle, que les fichiers 'zip' ou 'tar' qui servent à empaqueter des répertoires soient générés par la plateforme de diffusion à partir d'instructions inscrites dans un fichier XML transmis par le répertoire DIFFUSION.