Interface CINES-IN2P3/fedora donnees necessaires

Un article de wikis du tge-ADONIS.

Cette page est un résumé de l'exemple donné dans le Fichier type de création d'objet FEDORA. Je vais y recenser les données nécessaires ou optionnelles pour la création d'un objet FEDORA. Toutes ces données ne sont pas forcément à fournir par le CINES ou les CRDO. J'essayerai de le préciser pour chaque donnée.

D'autres informations sont aussi disponibles dans l'article IN2P3/fedora utilisation

Si vous avez des commentaires, n'hésitez pas à les mettre sur l'onglet discussion prévu à cet effet.

Champs renseignés pour le foxml

(définition de l'objet FEDORA proprement dit):

PID

Correspond à l'identifiant unique de l'objet dans FEDORA.

Je propose que ce champ soit de la forme <déposant>:<PID> où <déposant> correspond à l'organisme qui dépose l'objet (ex: CRDO-Aix) et <PID> à son identifiant unique.

Actuellement, je ne l'ai pas vu dans les sip du CINES. Éventuellement, le champ DocMeta.identifiantDocProducteur devrait correspondre, mais les valeurs trouvées ne ressembles pas à un PID correct. D'après le document XLS, il semblerait que ce soit le champ DocMeta(ou DocDC).identifier... à discuter.

type

Valeurs possibles: FedoraObject; FedoraBDefObject; FedoraBMechObject; FedoraCModelObject.

Dans notre cas, il devrait prendre systématiquement la valeur FedoraObject.

Ni les CRDO ni le CINES n'ont à fournir la valeur de ce champ.

state

Valeurs possibles: A (actif); I (inactif); D (supprimé)

Cette valeur reste à être définie et dépendra des règles qui seront suivies concernant les droits de diffusions. Dans tous les cas, la valeur sera A ou I.

D fonctionne comme une poubelle: tant que celle-ci n'est pas vidée (purgée), l'objet peut être récupéré. Sauf si les objets peuvent être amenés à être supprimés, cette valeur ne devrait pas être utilisée.

Cette valeur pourrait être fournie par les CRDO... à discuter.

label

Cette valeur pourrait correspondre au champ DocDC.description du sip fourni par le CINES/CRDO.
J'essaierai de trouver la liste des caractères acceptés pour ce champ.

ownerid

Correspond à l'identifiant du propriétaire.
C'est un champ libre.

Ce champ pourrait correspondre au champ DocDC.creator, DocDC.publisher, DocDC.contributor du SIP fourni par le CINES/CRDO ... à discuter.

Les champs communs aux Datastreams

Les datastreams seront utilisés pour lier à un objet FEDORA un fichier. Ce fichier pourra être un fichier son, une vidéo, un fichier descriptif au format texte, un fichier de méta-données, des règles définissant des droits propres à l'objet, etc...

ID

Ce champ est l'identifiant unique du datastream. Il ne doit pas avoir les valeurs suivantes car elles sont réservée au fonctionnement de FEDORA: DC, RELS-EXT, AUDIT, POLICY (cette liste sera éventuellement complétée au cours de mes recherches).
À l'intérieur d'un objet l'ID doit être unique, mais il peut se retrouver dans plusieurs objets.

Ce champ doit être fourni par les CRDO sinon il sera impossible de retrouver facilement l'accès au fichier auquel il fait référence. Il pourrait être intéressant de fixer certains ID de datastream comme ceux faisant référence à un fichier de meta-données descriptives, ceux faisant pointant sur la donnée de référence (vidéo originelle, ...)... à discuter.

Le champ correspondant dans les sip fournis par les CINES/CRDO semble être FichMeta.idDocument... à confirmer.

STATE

Comme pour l'objet lui-même, il peut avoir 3 valeurs possibles: A (actif); I (inactif); D (supprimé). Sa valeur reste à être définie... à discuter.

CONTROL_GROUP

4 valeurs possibles: M (Managed Content), E (Externally Referenced Content), R (Redirected Content) ou X (Inline XML).

M:le datastream est un fichier qui sera enregistré dans le repository (système de stockage) de FEDORA.
E: le datastream est une URL pointant sur un fichier sur un serveur web extérieur. Pour accéder à ce datastream, FEDORA le chargera puis le renverra au demandeur. Pour le client, ce fonctionnement sera le même que pour le CONTROL_GROUP M.
R: le datastream est aussi une URL pointant sur un fichier sur un serveur web extérieur. Ici, pour accéder au datastream, le demandeur sera redirigé vers l'URL. Ce fonctionnement peut être utilisé par exemple pour le streaming de vidéos.
X: ici, le datastream ne pointe pas sur un fichier mais contient des informations au format XML. Ce fonctionnement pourrait être utiliser pour définir des méta-données de description... ou pas.
Dans tous les cas, ce champs peut être fourni par les CRDO. Il peut être aussi déduit des informations fournies par le CRDO ... mais s'il était précisé, je pense que cela éviterait certainement des malentendus. À discuter...

MIMETYPE

Correspond au type MIME du datastream.

Le type MIME ne semble pas être fourni par les CINES/CRDO mais pourrait être déduit éventuellement du champ FichMeta.formatFichier.

LABEL

Chaîne de caractères décrivant le datastream.

Dans les sip, le champ FichMeta.noteFichier pourrait être utilisé... à confirmer du côté du CINES.

ALT_IDS

Chaîne de caractère donnant les ID alternatifs du datastream.

À définir si ce champ a une utilité dans le cadre du projet...

FORMAT_URI

URL(/URI) donnant la description du datastream. Par exemple http://www.openarchives.org/OAI/2.0/oai_dc/ pour le Dublin Core.

Ce champ est optionnel. Il peut être fourni par les CRDO ou le CINES ... ou laissé vide. À discuter...

SIZE

Taille du fichier.

D'après la documentation, FEDORA peut éventuellement le calculer automatiquement... à voir si ce champs nous est utile.

VERSIONNABLE

Indique si FEDORA doit mémoriser les différentes versions du datastream.

À discuter de son utilité dans notre cas...

Datastream spéciaux

Datastream DC

Correspond aux méta-données Dublin Core. Ce datastream est systématiquement créé par FEDORA et deux champs sont automatiquement renseignés.

DC est un identifiant de datastream réserver au fonctionnement de FEDORA.

title

Ce champ est automatiquement renseigné par FEDORA lors de la création de l'objet et sa valeur correspond au label.

identifier

Ce champ est aussi automatiquement renseigné par FEDORA lors de la création de l'objet et sa valeur correspond au PID.

... tous les autres champs du Dublin Core peuvent être renseignés ici.

Datastream RELS-EXT

Ce datastream est optionnel. Il servira à déterminer si l'objet est ou fait parti d'une collection.
Les champs contenus ici suivent les règles du RDF. Une description est disponible ici.

RELS-EXT est un identifiant de datastream réserver de FEDORA.

Datastream POLICY

Ce datastream permet de définir des règles d'accès propres à l'objet sous la forme de fichier XACML. Les règles d'écriture des fichiers XACML sont disponibles ici.

Ce fichier pourra bien entendu être généré automatiquement par le traitement de transformation des données du CINES... sauf si les CRDO veulent se lancer dans leur élaboration... ;o) Il faudra par contre établir un protocole pour permettre la création de ce fichier.

Actuellement, je n'ai pas trouvé de champs correspondant dans les sip du CINES. Le champ DocDC.rights semble prévu pour cet effet... à discuter.

Datastream AUDIT

Ce datastream est généré automatiquement par FEDORA et correspond à un historique des interventions sur l'objet et ses datastreams.
Pour chacune de ces interventions on retrouve:

le processus (ex: API-M)
la fonction (ex: modifyDatastreamByReference)
l'ID de l'objet touché (si objet proprement dit, vide, sinon, ID du datastream)
l'utilisateur ayant fait a modif
la date de modification (précise au millième de secondes!!!)
un message d'explication (qui peut être vide)

Retour à la page Interface CINES-IN2P3