IN2P3/fedora utilisation
Un article de wikis du tge-ADONIS.
Retour à la page IN2P3
Vous trouverez sur cette page comment FEDORA sera utilisé dans le projet d'archivage pérenne.
Après de longues semaines de recherches dans la jungle documentaire en pleine restructuration de FEDORA-commons, je commence à avoir une idée de l'organisation possible des outils disponibles. Dans ma recherche, je me suis d'abord orienté vers le site http://www.fedora.info/ . Mais étant données les remaniements du site, j'ai fini par trouvé le nouveau site officiel de la version 3.0 (puis 3.1) à cette adresse: http://www.fedora-commons.org/ . Plus précisément, l'essentiel de la documentation peut se trouver à https://fedora-commons.org/confluence/dashboard.action , ... voir https://fedora-commons.org/confluence/display/FCR30/Fedora+Repository+3+Documentation C'est à partir de cette dernière adresse que se trouveront l'essentiel des liens que je fournirai ci-dessous.
Sommaire |
Généralités
Pour résumer, un objet fedora pourra être vu comme une boîte dans laquelle pourront être mises des données. Celles-ci seront gérées par des datastreams qui pourront être la donnée proprement dite de l'objet (exemple: un enregistrement), une description de cet enregistrement, des meta-données Dublin Core... ou tout autre information pouvant tenir dans un ficher informatique. Le nombre de datastreams n'est pas limité mais certains d'entre eux doivent être uniques (Dublin Core, règles de sécurité liées à l'objet, ...). Le but sera donc de ne pas créer un objet par fichier mais de créer des datastreams groupés dans un même objet. Grâce aux règles RDF, il est aussi possible de regrouper certains objets en collection.
Il est prévu que les authentifications se feront par un annuaire LDAP et les droits de consultation et de modification seront définis en suivant les règles d'écriture des fichiers XACML. Les données pourront transiter sur des liaisons sécurisées (HTTPS). Un moteur de recherche sur les objets et leurs meta-données est encore à l'étude. Il se peut que fedora puisse fournir ce genre d'outil... à suivre. Cet article permet de voir d'un autre point de vue l'objet fedora qui est aussi décrit dans l'article concernant l'interface avec le CINES.
Si vous avez des commentaires, n'hésitez pas à les mettre sur l'onglet discussion prévu à cet effet.
Transformation des sip du CINES à l'aide de SAXON
Utilisation du service SAXON
La documentation concernant ce service se trouve à l'adresse suivante: https://fedora-commons.org/confluence/display/FCR30/SAXON+XSLT+Processor+Service
Ce service ne sera utilisé qu'en interne au centre de calcul, entre le serveur réceptionnant les données du CINES (iRods?) et le serveur fedora. La transformation se fera en appelant l'url suivante
http://serveurfedora/saxon/SaxonServlet?source=sip.xml&style=reference.xsl
Le fichier sip.xml (ou aip.xml) étant le fichier envoyé par le CINES et reference.xsl étant le fichier de type XSLT permettant de générer un fichier XML capable d'être ingéré (ingest dans le texte) par fedora à partir du sip (ou aip).
Création du fichier XSLT
Ce fichier est à créer. Éventuellement, une discussion avec le CINES peut apporter quelques précisions sur les champs à utiliser dans les sip (ou aip). pour cela, on pourra se référer à l'article sur Données nécessaires ou optionnelles à fournir dans les données envoyées par le CINES
Fedora Digital Object Model
Vous pourrez trouver sur ce lien la description du FEDORA Digital Object Model.
Un objet est constitué de données spécifiques (PID, state, label, ownerId, createdDate et lastModifiedDate) permettant de l'identifier et de le décrire, ainsi que des datastreams pouvant être d'autres données internes descriptives (DC, AUDIT) ou des pièces jointes (RELS-EXT, POLICY ou autre identifiant, Enregistrement1 par exemple) sous forme de fichier. Ces pièces jointes peuvent être directement gérées par Fedora ou simplement être un lien sous forme d'URL.
FOXML - références de l'objet proprement dit
<foxml:digitalObject VERSION="1.1" PID="demo:999"
xmlns:foxml="info:fedora/fedora-system:def/foxml#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="info:fedora/fedora-system:def/foxml# http://www.fedora.info/definitions/1/0/foxml1-1.xsd">
<foxml:objectProperties>
<foxml:property NAME="info:fedora/fedora-system:def/model#state" VALUE="A"/>
<foxml:property NAME="info:fedora/fedora-system:def/model#label" VALUE="FOXML Reference Example"/>
<foxml:property NAME="info:fedora/fedora-system:def/model#ownerId" VALUE="Jallud"/>
<foxml:property NAME="info:fedora/fedora-system:def/model#createdDate" VALUE="2004-12-10T00:21:58.000Z"/>
<foxml:property NAME="info:fedora/fedora-system:def/view#lastModifiedDate" VALUE="2005-01-20T22:46:07.506Z"/>
</foxml:objectProperties>
...
</foxml:digitalObject>
Un objet fedora est d'abord défini par son PID. celui-ci est constitué de la manière suivante:
<namespace>:<identifiant de l'objet>
- Le namespace pourra être le nom du CRN ayant fait le dépôt. Dans ce cas, une liste des CRN devra être créée car on ne peut pas les mettre à la volée. Cette liste fait partie des paramètres du serveur fedora. Il existe aussi un namespace à utiliser si aucun n'est précisé à la création de l'objet. On peut aussi imaginer d'autres utilisations de ce namespace... à réfléchir.
- l'identifiant de l'objet peut être généré automatiquement pas fedora... mais je pense que ce n'est pas une bonne solution. Je pense qu'il est mieux d'utiliser ici l'identifiant unique et persistant de type ARK. Par contre, il faudra s'assurer que les jeux de caractères soient compatibles.
Les autres champ contenus dans foxml:objectProperties donnent l'état de l'objet (actif par défaut mais il peut être forcé dès sa création), sa description, son propriétaire (utilisateur ayant créé l'objet ou autre propriétaire à préciser) et les dates de création et de dernière modification. La définition du schéma FOXML peut se trouver à l'adresse suivante: http://www.fedora.info/definitions/1/0/foxml1-1.xsd
les datastreams
Un datastream est une donnée que l'on lie à l'objet fedora. Ces données peuvent être récupérées séparément par différentes méthodes décrites plus bas. Elles peuvent avoir plusieurs formes:
- un fichier de données (vidéo, son, image, texte etc...) possédant son propre identifiant à l'intérieur de l'objet (EnregistrementOriginal par exemple)
- un lien vers un fichier de données, ce lien pouvant soit servir à retourner le fichier proprement dit, soit rediriger l'utilisateur souhaitant consulter ce datastream; ce lien possède lui aussi un identifiant propre à l'intérieur de l'objet
- une description au format XML, données XML stockées directement dans l'objet fedora (identifiant propre)
- des données Dublin Core stocké directement dans l'objet fedora (identifiant réservé: DC)
- des relations vers un autre objet fedora sous la forme RDF (identifiant réservé: RELS-EXT)
- un historique des opérations effectuées sur l'objet (identifiant réservé: AUDIT)
- des règles propres à l'objet (identifiant réservé: POLICY)
Un datastream est défini par son identifiant ID unique dans l'objet ainsi que par le champ CONTROL_GROUP qui définit son format de stockage (interne à l'objet, fichier stocké par Fedora ou lien sur un autre serveur).
identifiants de datastreams internes et réservés à Fedora
- ID = "DC" et CONTROL_GROUP = "X" (Dublin Core)
<foxml:datastream ID="DC" STATE="A" CONTROL_GROUP="X" VERSIONABLE="true">
<foxml:datastreamVersion FORMAT_URI="http://www.openarchives.org/OAI/2.0/oai_dc/"
ID="DC.0" MIMETYPE="text/xml"
LABEL="Dublin Core Record for this object"
SIZE="488"
CREATED="2004-12-10T00:21:58.000Z">
<foxml:xmlContent>
<oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:title>FOXML Reference Object</dc:title>
<dc:identifier>demo:999</dc:identifier>
</oai_dc:dc>
</foxml:xmlContent>
</foxml:datastreamVersion>
</foxml:datastream>
Par défaut, fedora crée dans ce datastream les champs title et identifier, mais il peut être complété par tous les champs du Dublin Core. Si ces meta-données sont fournies, elles seront renseignées ici et pourront être récupérées comme n'importe quel datastream.
- ID = "AUDIT" et CONTROL_GROUP = "X" (historique des modifications apportées à l'objet)
<foxml:datastream CONTROL_GROUP="X" ID="AUDIT" STATE="A" VERSIONABLE="false">
<foxml:datastreamVersion CREATED="2008-12-10T13:18:50.083Z"
FORMAT_URI="info:fedora/fedora-system:format/xml.fedora.audit" ID="AUDIT.0" LABEL="Audit Trail for this object" MIMETYPE="text/xml">
<foxml:xmlContent>
<audit:auditTrail xmlns:audit="info:fedora/fedora-system:def/audit#">
<audit:record ID="AUDREC1">
<audit:process type="Fedora API-M"/>
<audit:action>ingest</audit:action>
<audit:componentID/>
<audit:responsibility>Jallud</audit:responsibility>
<audit:date>2008-12-10T13:18:50.083Z</audit:date>
<audit:justification>Created with Admin GUI "New Object" command</audit:justification>
</audit:record>
<audit:record ID="AUDREC2">
<audit:process type="Fedora API-M"/>
<audit:action>addDatastream</audit:action>
<audit:componentID>DS1</audit:componentID>
<audit:responsibility>Jallud</audit:responsibility>
<audit:date>2008-12-10T13:23:18.080Z</audit:date>
<audit:justification>DatastreamsPane generated this logMessage.</audit:justification>
</audit:record>
...
</audit:auditTrail>
</foxml:xmlContent>
</foxml:datastreamVersion>
</foxml:datastream>
Ce datastream est généré automatiquement et stocké en interne par Fedora. Il ne peut pas être renseigné par un utilisateur, mais il peut être consulté pour connaître l'historique d'un objet. Dans l'exemple ci-dessus, le premier élément d'AUDIT correspond à la création (ingest) de l'objet (le componentID est vide). Le second est un ajout de datastream (addDatastream) dont l'ID vaut DS1 (componentID).
- ID="RELS-EXT" et CONTROL_GROUP="X" (relations internes entre objets Fedora)
<foxml:datastream ID="RELS-EXT" CONTROL_GROUP="X">
<foxml:datastreamVersion FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt-1.0"
ID="RELS-EXT.0"
MIMETYPE="application/rdf+xml"
LABEL="RDF Statements about this object"
SIZE="752"
CREATED="2004-12-10T00:21:58.000Z">
<foxml:xmlContent>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:rel="info:fedora/fedora-system:def/relations-external#"
xmlns:myns="http://www.nsdl.org/ontologies/relationships#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/">
<rdf:Description rdf:about="info:fedora/demo:999">
<!-- This object ("info:fedora/demo:999") is a member of Collection #1 (info:fedora/test:collection1) -->
<rel:isMemberOfCollection rdf:resource="info:fedora/test:collection1"/>
<!-- ... and it is also a member of Collection #2 (info:fedora/test:collection2) -->
<rel:isMemberOfCollection rdf:resource="info:fedora/test:collection2"/>
<!-- You can also make your own relationship assertions in your own namespace...-->
<myns:isPartOf rdf:resource="info:fedora/mystuff:100"/>
</rdf:Description>
</rdf:RDF>
</foxml:xmlContent>
</foxml:datastreamVersion>
</foxml:datastream>
Ce datastream permet de créer des liens de parenté entre différents objet Fedora. Dans cet exemple, l'objet concerné est un membre de la collection définie par l'objet "test:collection1". Il l'est aussi de "test:collection2". Il est possible de définir ses propres relations (par exemple myns)... est-ce bien utile dans le cadre de ce projet?... Je pense que les définitions RDF sont suffisantes. Les relations prises en compte par Fedora sont disponibles à l'adresse suivante: http://www.fedora.info/definitions/1/0/fedora-relsext-ontology.rdfs
autres identifiants de datastream réservés
- ID="POLICY" (définition des règles spécifiques à l'objet)
<foxml:datastream CONTROL_GROUP="X" ID="POLICY" STATE="A" VERSIONABLE="true">
<foxml:datastreamVersion CREATED="2008-12-15T14:59:52.179Z" ID="POLICY.0"
LABEL="POLICY: permit-apim-by-ldap-group (2)" MIMETYPE="text/xml" SIZE="1545">
<foxml:xmlContent><!-- Début du XACML -->
<Policy PolicyId="permit-apim-by-ldap-group"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Description>permit any access if client in a LDAP group administrator</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">urn:fedora:names:fedora:2.1:action:api-m</AttributeValue>
<ActionAttributeDesignator AttributeId="urn:fedora:names:fedora:2.1:action:api" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Rule Effect="Permit" RuleId="1">
<Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<SubjectAttributeDesignator AttributeId="ou" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Groupe autorise</AttributeValue>
</Apply>
</Condition>
</Rule>
</Policy><!-- fin du XACML -->
</foxml:xmlContent>
</foxml:datastreamVersion>
</foxml:datastream>
Ces règles doivent être au format XACML. Il est possible que ces règles soient définies en interne (CONTROL_GROUP="X") ou définies dans un fichier externe (CONTROL_GROUP="M, E ou R"). Ce fonctionnement présente plusieurs avantages:
- pouvoir définir des règles propres à chaque objet fedora tout en gardant les règles globales de sécurité
- mutualiser les règles en faisant pointer les datastreams POLICY vers des fichiers XACML pré-définis
- changer à la volé les règles de sécurité sur un objet; en effet, ces règles sont chargées à chaque accès à l'objet, et non au démarrage du serveur comme les XACML globaux.
Cependant, il faut faire attention aux multiplicités des règles et donc ne pas trop "affiner" la sécurité.
datastream classique
<foxml:datastream CONTROL_GROUP="M" ID="DS1" STATE="A" VERSIONABLE="true">
<foxml:datastreamVersion CREATED="2008-12-10T13:23:18.080Z" ID="DS1.0" LABEL="Amazonie en contre-jour" MIMETYPE="image/jpeg">
<foxml:contentLocation REF="PYJTests:objectTst02+DS1+DS1.0" TYPE="INTERNAL_ID"/>
</foxml:datastreamVersion>
<foxml:datastreamVersion CREATED="2008-12-11T14:18:08.568Z" ID="DS1.1" LABEL="Amazonie en contre-jour (bis)" MIMETYPE="image/jpeg">
<foxml:contentLocation REF="PYJTests:objectTst02+DS1+DS1.1" TYPE="INTERNAL_ID"/>
</foxml:datastreamVersion>
</foxml:datastream>
Les fichiers de données pourront utiliser n'importe quel autre ID. Chaque fichier sera représenté par un datastream. Il est possible, en cours de vie d'un objet de mettre à jour un datastream, d'en créer un nouveau ou d'en supprimer un.
Dans l'exemple ci-dessus, le datastream est une image (MIMETYPE="image/jpeg") dont l'ID est "DS1", sa première version possède le label "Amazonie en contre-jour" et sa deuxième version "Amazonie en contre-jour (bis)" et il est stocké en interne dans fedora (CONTROL_GROUP="M"). Par défaut, l'accès à ce datastream présentera sa dernière version (PYJTests:objectTst02/DS1). Pour obtenir la version précédente, il faudra le préciser (PYJTests:objectTst02/DS1/2008-12-10T13:23:18.080Z)
Il est possible d'interdir la gestion de version pour un datastream. A sa création, il suffira de préciser VERSIONABLE="false".
Il est aussi possible de changer l'état (state) d'un datastream: I le rendra Inactif (simple indication?) et D le marquera à supprimer lors d'une "purge".
Différentes méthodes pour accéder aux données
API-M et API-A
Les données des objets fedora sont accessibles grâce à des Web Services. Pour l'instant seules l'accès en SOAP ainsi que l'accès par URL sont validés. La liste des fonctions SOAP sont accessibles sur les liens suivants: API-A et API-M.
L'API-M est un web service permettant de modifier un objet fedora. ce service fournit toutes les fonctions nécessaires pour la création, l'export, la modification ou la suppression d'objet ou de datastream.
L'API-A permet de consulter (Accéder) les objets sans les modifier. Ce service fournit un ensemble de fonctions pour la consultation ou la recherche des objets ou datastreams. Les moteurs de recherche en fonction des critères sur des méta-données seront vus dans le chapitre suivant.
Accès directe
À l'aide d'un navigateur web, il est possible d'accéder directement à l'objet grâce à une URL construite à l'aide de l'ID de l'objet et de l'ID du datastream:
http://ServerFedora:8080/fedora/get/Namespace:IDObjFedora/IdDatastream
Ce lien permet d'accéder au datastream d'ID IdDatastream de l'objet d'ID Namespace:IDObjFedora. Il utilise l'API-A.
Moteurs de recherche sur les objets fedora
L'étude sur les moteurs de recherche est en cours. Les conclusions ne sont pas définitives...
Basic OAI-PMH Provider
Basic OAI-PMH Provider Ce service fourni par fedora ne fait des recherches que sur les meta-données du Dublin Core. C'est intéressant, mais ça ne semble pas suffisant pour les CRDO qui souhaiteraient pouvoir faire des recherches sur toutes leur meta-données spécifiques définis par OLAC.
OAI Provider Service 1.2
OAI Provider Service 1.2 Il semblerait que ce service fournisse ce que les CRDO recherchent. Il semblerait que l'on puisse dans ce cas gérer une base à l'extérieur de fedora alimentée des meta-données. La recherche se ferait sur cette base limitant la demande de ressource au serveur fedora. La desciption sur le lien qui suit en dit plus http://proai.sourceforge.net/. C'est sans doute la solution la plus intéressante. Il reste bien sûr à vérifier l'installation et le fonctionnement avec fedora.
Generic Search Service 2.2
Generic Search Service 2.2 Cette solution semble permettre des recherches indexées sur les données FOXML, les datastream au format texte inclus (CONTENT_GROUP="X") ou les résultats d'appels au disséminateur (??). Il faut voir la mise en œuvre et expérimenter mais il semblerait qu'il n'y ait pas d'indexation... donc sans doute peu performant ... ou en tout cas, moins que la solution OAI Provider Service 1.2.
Autres solutions
D'autres solutions peuvent être envisagées si la mise en place des outils fournis par fedora ne sont pas suffisants. Elles seraient orientés vers des outils déjà utilisés par les CRDO comme XQUERY ou XPATH... quoi que XQUERY soit préférable. Dans ce cas, des développements sont à prévoir.
Sécurisation de l'accès aux données avec les fichiers XACML
Tous les détails d'écriture des fichiers XACML sont disponibles sur le lien suivant: https://fedora-commons.org/confluence/display/FCR30/Fedora+XACML+Policy+Writing+Guide
Comme il a été décrit plus haut il est possible de définir des règles de sécurité pour chaque objet fedora. Il est aussi possible d'écrire des règles globales. La différence est que la première sera chargée à chaque accès à l'objet tandis que l'autre sera chargée au démarrage du serveur car elle est chargée en mémoire. Il est toute fois possible de re-charger les règles globale sans avoir à re-démarrer le serveur (fedora-reload-policies). Une autre différence tient au fait que la définition de règles pour un objet fedora peut aussi se faire à la volée (en créant ou modifiant un datastream) mais les règles globales ne sont accessibles que par les administrateur du serveur.
Ces règles peuvent être suffisamment fines pour définir les droits sur une seule fonction des API en limitant l'accès à un utilisateur (administrateur) ou un groupe d'utilisateur, ... ou à tous, ainsi que sur un seul datastream d'un objet, ou tous les datastreams, ou tous les objets, etc... du moment qu'on puisse identifier les éléments à filtrer (API, fonction, utilisateur ou datastream).
Authentification par LDAP
La structure de l'annuaire n'est pas encore arrêtée. Ce qui a été testé, c'est l'authentification d'un utilisateur inscrit dans l'annuaire LDAP. Suivant la hiérarchie à laquelle appartient cet utilisateur, il est possible de limiter ses droits. Je pense qu'il est possible de préciser à l'intérieur de la fiche de l'utilisateur ses droits sous forme d'attribut. Mais ce n'est pas encore en place. Apriori, fedora ne peut authentifier un utilisateur que sur un seul attribut. Par exemple, pour l'identifiant, on pourra utiliser uid ou cn (ou tout autre champ) mais pas les deux mélanger: des fiches utilisant uid comme identifiant et d'autres cn.
Retour à la page IN2P3
