Référentiel SAEM - Guide de l’administrateur¶
Gestion de configuration¶
Le référentiel SAEM est construit sur le cadre applicatif CubicWeb. À ce titre, c’est un composant CubicWeb, dont la structure générale est décrite ici.
Il s’appuie sur les composants logiciels suivants :
- le cadre applicatif CubicWeb lui-même (>= 3.24) ;
- cubicweb-saem_ref, l’application référentiel proprement dite, agrégeant les différents composants ci-dessous ;
- cubicweb-seda, cube implémentant le modèle de données SEDA 2, complet et simplifié, ainsi que les fonctions d’export ;
- cubicweb-eac, cube implémentant le modèle de données EAC, et permettant notamment d’importer puis de réexporter les notices d’autorités ;
- cubicweb-skos, cube implémentant le modèle de données SKOS, et permettant notamment d’importer puis de réexporter des vocabulaires au format SKOS pour la gestion des thésaurus et autres vocabulaires contrôlés;
- cubicweb-oaipmh , cube implémentant un serveur OAI-PMH ;
- cubicweb-signedrequest , cube permettant d’authentifier les requêtes HTTP d’accès aux différents web service.
Pour faire fonctionner une instance, vous aurez également besoin de :
- psycopg2, bibliothèque pour l’accès aux bases de données Postgresql ;
- rdflib (>= 4.1), bibliothèque pour la manipulation de données RDF en Python, utilisée notamment pour l’import de fichier SKOS.
Enfin, une formule Salt pour le déploiement et un client en ligne de commande d’accès aux services web sont disponibles.
Installation¶
Configuration du serveur PostgreSQL¶
Si vous n’en n’avez pas encore un disponible, il faut commencer par installer un serveur PostgreSQL
(pas nécessairement sur la même machine que le réferentiel). Sur une distribution Redhat / CentOS,
les paquets suivants sont nécessaires coté serveur : postgresql<version>-contrib
,
postgresql<version>-plpython
, postgresql<version>-server
où <version>
peut-être par
exemple 96
selon la distribution utilisée.
Il faudra ensuite créer un utilisateur dédiée au référentiel, par exemple nommée « saemref » et permettre l’accès depuis le client.
Installation via Docker¶
Le projet saemref-docker fournit un environnement docker-compose permettant de déployer le référentiel. C’est la façon recommandée et la plus simple de l’installer. Voir la documentation du projet pour plus de détails :
Installation manuelle¶
La procédure décrite dans cette section concerne l’installation manuelle du référentiel. Elle se base sur une combinaison de paquets système (disponibles via une distribution Linux) et un environnement virtuel Python.
Les paquets systèmes suivants sont nécessaires (yum install
sur une distribution Redhat/CentOS) :
- mailcap
- graphviz-gd
- python-devel
- gcc-c++
- python3
- python3-pip
- python3-setuptools
- python3-lxml
- python3-psycopg2
- postgresql
Nous recommandons d’installer le code du référentiel avec un utilisateur standard (pas root) :
[root@srv]% adduser saemref
[root@srv]% su - saemref
et dans un virtualenv, qu’il convient donc de créer puis d’activer :
[saemref@srv ~]$ python3 -m venv saemref-venv
[saemref@srv ~]$ . saemref-venv/bin/activate
(saemref-venv) [saemref@srv ~]$
Par la suite, nous supposerons que vous tapez les commandes indiquées en tant qu’utilisateur saemref et avec le virtualenv activé.
Installer le référentiel :
pip install cubicweb-saem-ref
Création de l’instance¶
Une fois le cube saem_ref et ses dépendances installées, il reste à créer une instance de celui-ci :
cubicweb-ctl create saem_ref saemref
Note
La phase finale de création prend quelques minutes, afin de remplir la base avec quelques données nécessaires au bon fonctionnement de l’application.
- Laisser le choix par défaut à la plupart des questions, si ce n’est pour:
db-name
: choisir le nom de la base créée depuis le serveur PostgreSQL (ex.saemref
)db-user
/db-password
: mettre les informations de l’utilisateurs PostgreSQLAllow anonymous access ?
: mettrey
pour ne pas restreindre l’accès en lecture
- Choisir un login / mot de passe administrateur sécurisé (admin/admin est une
mauvaise idée, nous recommandons d’installer le paquet
pwgen
et de générer un mot de passe aléatoire avec la commandepwgen 20
).
Selon votre configuration postgres, vous pouvez avoir à modifier le fichier sources pour y spécifier les informations de connexion au serveur (hôte, port, utilisateur et mot de passe). Le plus simple est de répondre non à la question « Run db-create to create the system database ? », d’éditer le fichier ~/etc/cubicweb.d/saemref/sources puis de reprendre le processus d’initialisation en tapant :
cubicweb-ctl db-create saemref -cn
Vous pouvez maintenant vérifier que l’instance se lance :
cubicweb-ctl pyramid -D saemref
L’instance est désormais lancée et disponible sur le port 8080.
Pour une instance de production, il est recommandé d’utilisé un serveur d’application WSGI tel que gunicorn et un superviseur tel que supervisor.
pip install gunicorn
Configuration de supervisor¶
supervisor permet de gérer les différents services de l’application, à savoir : le serveur web principal (programme « saemref »), le point d’accès OAI-PMH (programme « saemref-oai ») et le gestionnaire de tâches (programme « saemref-scheduler »).
Un exemple de configuration supervisor, à mettre dans
/etc/supervisor/conf.d/saemref.conf
:
[program:saemref]
command=/home/saemref/venv3/bin/gunicorn 'cubicweb.pyramid:wsgi_application()' --forwarded-allow-ips * --threads 8 --workers 2 --bind 0.0.0.0:8080
user=saemref
redirect_stderr=true
stdout_logfile=/home/saemref/saemref.log
environment=CW_MODE=user,HOME=/home/saemref,CW_INSTANCE=saemref
autorestart=true
startsecs=10
[program:saemref-oai]
command=/home/saemref/venv/bin/gunicorn 'cubicweb.pyramid:wsgi_application()' --forwarded-allow-ips * --threads 8 --workers 2 --bind 0.0.0.0:8081
environment=CW_MODE=user,HOME=/home/saemref,CW_INSTANCE=saemref,CW_CONNECTIONS_POOL_SIZE=8,CW_PORT=8081
user=saemref
redirect_stderr=true
stdout_logfile=/home/saemref/saemref-oai.log
autorestart=true
startsecs=10
[program:saemref-scheduler]
command=/home/saemref/venv/bin/cubicweb-ctl scheduler saemref
environment=CW_MODE=user,HOME=/home/saemref,CW_INSTANCE=saemref
user=saemref
redirect_stderr=true
stdout_logfile=/home/saemref/saemref-scheduler.log
autorestart=true
startsecs=10
Mise à jour de l’instance¶
Avertissement
Il y aura donc une interruption de service pendant cette opération
Lors qu’une nouvelle version est livrée, il faut commencer par mettre à jour le code de l’application. Le plus simple pour cela est de supprimer le virtualenv et de le recréer. Si vous avez installé le référentiel avec pip :
[root@srv] % supervisorctl stop all
[root@srv] % su - saemref
$ rm -rf saemref-venv
$ python3 -m venv saemref-venv
$ . saemref-venv/bin/activate
(saemref-venv)$ pip install cubicweb-saem-ref
Puis il reste à mettre à jour l’instance CubicWeb.
cubicweb-ctl upgrade saemref
La commande cubicweb-ctl upgrade pose un certain nombre de questions, auxquelles il faut toujours répondre par oui (en tapant “y” ou Entrée directement). Un backup de la base de données est effectué avant la migration afin de pouvoir rejouer une migration en cas de problème.
Relancer enfin supervisor
:
[root@srv] % supervisorctl start all
Lancement de l’instance en mode debug¶
Pour comprendre certains problèmes, il peut-être utile de lancer l’instance en mode « debug » afin d’augmenter le niveau de détails des logs. Pour cela, il faut mettre :
log-threshold=DEBUG
dans le fichier ~saemref/etc/cubicweb.d/saemref/all-in-one.conf
puis relancer l’instance :
[root@srv] % supervisorctl restart all
Configuration du frontal web¶
Il faut configurer le frontal web pour diriger les différentes requêtes sur chacun des services configurés (le serveur web principal et le serveur OAI-PMH). Ci-dessous un exemple de configuration pour nginx :
server {
listen 80;
server_name saemref.example.com;
location / {
proxy_pass http://srv:8080;
}
location /oai {
proxy_pass http://srv:8081;
}
}
Gestion d’identifiants pérennes¶
Introduction¶
Pourquoi avoir des identifiants plutôt que simplement des URL (qui peuvent être tout aussi pérennes) ?
Un identifiant (qui peut d’ailleurs être inclus dans une URL, comme dans le cas de ARK) offre une indication plus claire à l’utilisateur final que la référence de l’objet est persistante alors qu’il est difficile de dire à partir d’une URL si elle est persistante ou non.
Un identifiant peut être diffusé par plusieurs canaux (via différentes URL incluant un même identifiant par exemple). L’utilisateur final peut savoir qu’il s’agit de la même ressource.
ARK vs DOI
ARK et DOI fournissent tous deux un mécanisme d’identification pérenne des objets. Historiquement DOI est associé au monde des éditeurs (notamment de publications techniques) et ARK plutôt au monde des associations culturelles (bibliothèques, archives, etc.). La création d’identifiant DOI est payante.
ARK s’intéresse uniquement à l’aspect pérenne de l’identification des objets, pas à la persistance de l’accès à ces objets qui est vu comme une question de service. Ainsi un identifiant ARK est généralement inclus dans une URL de façon à être actionnable directement. DOI s’appuie sur un ensemble d’autorités intermédiaires garantes du registre des identifiants et chargées de la résolution des identifiants DOI (en URL). Ainsi le système DOI se substitue au mécanisme de résolution du DNS ce que ne fait pas ARK (à dessein).
ARK laisse une grande liberté à l’autorité de nommage.
ARK¶
La forme générale d’un identifiant ARK est la suivante (les éléments entre crochets sont optionnels) :
[http://NMAH/]ark:/NAAN/Name[Qualifier]
NMAH
(Name Mapping Authority Hostport) est une adresse (potentiellement temporaire) qui fournira une réponse aux requêtes ARK, on parle d’autorité d’adressage. Cette autorité fournit le service de persistence des URL.NAAN
(Name Assigning Authority Number) est l’identifiant de l’autorité de nommage. Il sert notamment à obtenir (auprès d’un registre) unNMAH
valide pour cette autorité.Name
est le nom assigné par l’autorité de nommage.Qualifier
permet de fournir d’autres ressources ou représentation à partir de l’identifiant ARK (par exemple, une page particulière d’un document, une vue particulière ; voir des exemples plus loin).
Génération de la partie NAME
des identifiants ARK¶
La partie NAME
de l’identifiant ARK est de la responsabilité de
l’autorité de nommage. Une grande liberté est laissée à cette autorité mais
en pratique on recommande de générer des identifiants opaques en respectant
quelques règles comme :
- ne pas rentrer en conflit avec la syntaxe HTML/XML
- éviter les caractères de ponctuation
- de façon générale, limiter les effets liés au contexte du langage de l’utilisateur
A priori, l’autorité de nommage est libre de générer des noms selon la méthode qu’elle choisit. Il est par exemple assez courant de s’appuyer sur un identifiant existant en interne de l’organisation pour construire un identifiant ARK. Il existe des logiciels (tel que NOID ou arkpy) ou des services Web (comme EZID) qui permettent de d’automatiser la génération (et la validation) des identifiants ARK.
La partie Qualifier
¶
L’utilisation de cette partie optionnelle de l’identifiant ARK est laissé à la discrétion de l’autorité de nommage. Elle permet souvent de fournir des services ou ressources complémentaires associés à l’objet identifié par le numéro ARK (par exemple la version d’un document, différents formats ou langues). Par exemple,
http://gallica.bnf.fr/ark:/12148/bpt6k103039f/f26.thumbnail
référence la page 26 en miniature du document identifié par ark:/12148/bpt6k103039f.
Historiquement, le standard ARK propose également un protocole de requête
permettant d’obtenir des informations supplémentaires (notamment liées à la
persistence) à partir d’un identifiant. Ce protocole nommé THUMP (pour The
HTTP URL Mapping Protocol) est basé sur l’utilisation du caractère ?
à
ajouter à l’identifiant va enrichir la réponse HTTP d’un enregistrement
de métadonnées spécifiques à ARK. En pratique, les implémentations de ce
protocole semble assez rares, probablement du fait que la plupart des
fournisseurs de services ARK ont choisi de s’appuyer sur les qualifiers.
Résoudre les identifiants ARK¶
La résolution des identifiants ARK repose en général sur le mécanisme de DNS et d’URL. Le standard ne spécifie pas à notre connaissance de moyen d’obtenir l“« adresse » d’un objet à partir de son identifiant ARK uniquement.
Utilisation d’ARK à la BNF¶
ARK est utilisé pour identifier les ressources du type documents numériques et notices (bibliographiques, d’autorité, etc). Dans chaque cas, la BNF utilise un identifiant interne (existant) pour générer l’identifiant ARK avec en plus :
- un préfixe correspondant au type de ressource,
- un caractère de contrôle
La politique d’utilisation des identifiants ARK à la BNF est disponible à l’adresse suivante : http://ark.bnf.fr/ark:/12148/bpt6k107371t.policy.
Selon les portails de la BNF, l’identifiant ARK peut servir directement d’URL principale ou uniquement d’URL pérenne (permalien). En particulier, le portail data.bnf.fr transforme une URL incluant un identifiant ARK en URL sans identifiant, mais incluant une partie intelligible permettant de reconnaitre l’objet désigné. Par exemple, l’URL http://data.bnf.fr/ark:/12148/cb11907966z devient http://data.bnf.fr/11907966/victor_hugo/ et est référencée en tant que permalien de la ressource. On notera la présence de l’identifiant de la notice 11907966 dans les deux URL et le préfixe c indiquant qu’il s’agit d’une notice (a contrario http://gallica.bnf.fr/ark:/12148/bpt6k107371t référence un document numérique).
Les identifiants ARK sont par ailleurs utilisés en tant qu’URL dans la version RDF des documents (voir par exemple : http://data.bnf.fr/11907966/victor_hugo/rdf.xml) et sont aussi présents dans la version JSON (sous forme courte).
Utilisation d’ARK dans le cadre du Référentiel SAEM¶
Le référentiel permet de paramétrer des autorités nommante ARK. Chaque autorité administrative est associée à une autorité nommante et enfin chaque utilisateur est lui-même associé à une autorité administrative.
Pour créer une notice d’autorité, un vocabulaire ou un profil SEDA, il faut spécifier l’autorité nommante qui sera utilisée pour générer on identifiant ARK - par défaut celle de l’autorité administrative de l’utilisateur connecté.
Une fois le NAAN
désigné, le Name
est généré de la forme :
<prefix><random character sequence><control character>
Certains types d’entités sont des composants d’un autre type d’entité (leur composite). C’est le cas des concepts vis-à-vis des vocabulaires, des agents ou des unités administratives vis-à-vis des autorités administratives ainsi que des unités d’archive vis-à-vis des profils SEDA. Les identifiants ARK des entités de ces types composants sont construits à partir de l’identifiant ARK de leur parent composite avec un qualifier.
<parent ARK identifier>/<qualifier>
<NAAN/<Name>/<qualifier>
La partie <qualifier>
est, comme la partie Name
, une chaine de
caractères aléatoires.
Par exemple, un concept identifié par ark:/75548/rf5cqr376g/mkn4tdx6ff
appartient au vocabulaire identifié par ark:/75548/rf5cqr376g
.
Structure des identifiants ARK¶
Les parties Name
et qualifier
sont construites sous la forme d’une
chaine de caractères aléatoires avec les contraintes suivantes :
- uniquement des consonnes et des chiffres
- au plus trois lettres successives
La partie Name
commence par un préfixe rf
(pour référentiel) et se
termine par un caractère de contrôle.
Ces deux parties ont une longueur fixes de 10 caractères.
Intégrité des identifiants ARK¶
Les identifiants ARK sont stockés dans une table SQL dont la structure est la suivante :
Colonne | Type | Modificateurs
-----------+---------+-------------------------------
naan | integer | non NULL
name | text | non NULL
qualifier | text | non NULL Par défaut, ''::text
Une contrainte d’unicité sur le tuple (naan, name, qualifier)
.
Pour générer un nouvel identifiant, on produit les chaines de caractères aléatoires selon les règles évoquées ci-dessus en s’assurant (via le gestionnaire de base de données) de l’unicité globale de l’identifiant.
SKOS¶
Le référentiel fournit une implémentation de SKOS. Les thésaurus ou vocabulaires contrôlés peuvent être créés ou importés directement dans l’interface web ou bien importés en ligne de commande.
Notez qu’un vocabulaire importé peut être rattaché à une source ou non. L’intérêt de passer par une source est que cette dernière permet de conserver l’URL d’origine du vocabulaire et ainsi de le (re)synchroniser plus tard. De plus le vocabulaire et ses concepts sont identifiés comme provenant de cette source.
Dans l’interface web, il y a deux moyens pour importer un vocabulaire en fonction de son format. Pour importer un vocabulaire au format SKOS (XML ou n3 par exemple) il faut ajouter une source via l’action « importer un vocabulaire contrôlé » disponible sur la page d’accueil. Si vous souhaitez importer un fichier SKOS directement, il faut utiliser l’import en ligne de commande expliqué ci-dessous.
Vous pouvez également depuis un vocabulaire existant importer des concepts issus d’un fichier CSV « simple » ou Linked-CSV.
Import de vocabulaire en ligne de commande¶
Lorsqu’il est lancé par l’interface web, l’import de thésaurus SKOS ne peut utiliser les optimisations qui deviennent nécessaires dès que le thésaurus est de taille conséquente (plus d’une centaine de concepts). En effet ces optimisations nécessitent que l’import soit effectué sans que d’autres connexions à la base de données soient actives (ce qui implique donc de stopper le serveur web pendant ce temps).
Pour importer un fichier SKOS RDF sans que celui-ci soit rattaché à une source de données, vous pouvez utiliser la commande “skos-import” de cubicweb-ctl :
cubicweb-ctl skos-import saemref fichier.rdf
Pour déclencher l’import initial ou la synchronisation de données SKOS RDF dont l’URL a été spécifiée par l’ajout d’une source dans l’interface web, vous pouvez utiliser la commande “source-sync” :
cubicweb-ctl source-sync saemref <nom de la source>
Ces deux exemples supposent que votre instance se nomme « saem » et que vous avez coupé l’interface
web au préalable (cubicweb-ctl stop saemref
ou supervisorctl stop saemref
si votre instance est
supervisée).
Import de fichier Linked CSV¶
- Vous pouvez importer un fichier au format Linked CSV depuis l’action « importer des concepts »
- disponible via l’onglet « concepts » d’un vocabulaire. Hormis le format, vous pourrez spécifier :
- le séparateur de colonnes (au choix parmi : tab, “,”, “;” et espace),
- la langue par défaut des textes contenus dans le fichier,
- l’encodage du fichier.
Un fichier LCSV contient sur ces premières lignes des méta-données permettant d’associer les différentes colonnes à une ontologie (SKOS/RDF en ce qui nous concerne).
Structure d’un fichier Linked CSV¶
Le fichier doit commencer par une ligne d’en-tête spécifiant le contenu des colonnes. Cette ligne d’entête permettra d’identifier la colonne # qui signalera les lignes d’informations prolog et la colonne $id qui contiendra un identifiant local pour les concepts décrits par chaque ligne. Les autres valeurs présentes dans cette ligne ne seront pas utilisées lors du traitement du fichier mais peuvent être renseignées pour améliorer la lisibilité du document.
Cette première ligne sera suivie d’une ou plusieurs lignes dites lignes prolog. Ces lignes contiennent les informations qui nous permettent d’associer la valeur de chaque colonne au concept décrit par la ligne. La nature des informations de chaque ligne sera donnée par la valeur de la colonne #. Les différentes valeurs possibles pour la colonne # sont:
- url, cette ligne indique la relation a établir entre le concept décrit et la valeur de chaque colonne dans le cas de la colonne $id, cette ligne spécifie le type des données représentées par chaque ligne (ex : skos:Concept)
- type, cette ligne indique le type de données contenu dans chaque colonne (url, string, integer)
- lang, cette ligne indique, uniquement pour les données de type string, la langue du texte. Si aucune langue n’est spécifiée, celle fournie par le formulaire sera utilisée par défaut.
Les colonnes pour lesquelles aucune information prolog n’aura été spécifiée seront ignorées lors du traitement.
Les lignes prolog sont suivies par les lignes de données, identifiables par le fait que la colonne # est vide. Toute ligne prolog survenant après une ligne de données sera ignorée.
Une erreur sera levée et le fichier non importé en cas de :
- fichier vide,
- absence de la colonne # ou $id,
- absence de valeur pour une colonne dans la ligne url (ou absence d’une ligne url)
Exemple¶
# | $id | Concept parent | Libellé | Définition |
---|---|---|---|---|
lang | fr | fr | ||
url | skos:Concept | skos:broader | skos:prefLabel | skos:definition |
type | url | string | string | |
#1 | Vie politique | organisation politique de l’organisme | ||
#2 | #1 | Assemblée délibérante | règles de fonctionnement | |
#3 | #1 | Instances consultatives | création en application de la loi | |
#4 | Pilotage | objectifs à long terme | ||
#5 | #4 | Pilotage de Bordeaux | projet d’administration |
Import de fichier CSV simple¶
Vous pouvez également fournir un fichier décrivant simplement une hiérarchie de concepts :
- un concept par ligne,
- le délimiteur permet d’indiquer le niveau hiérarchique (aucun si le concept n’a pas de parent).
Par exemple, avec “;” comme délimiteur :
espèce
;serpent
;;python
va ajouter au vocabulaire un concept “espèce” qui aura un sous-concept “serpent”, qui aura lui-même un sous-concept “python”.
Enfin un simple fichier avec un mot par ligne fera l’affaire :
bleu
jaune
rouge
EAC-CPF¶
Le référentiel fournit une implémentation de EAC-CPF relativement complète. Les notices d’autorités peuvent être créés ou importés directement dans l’interface web ou bien importés en ligne de commande.
Compatibilité EAC-CPF¶
Le tableau ci-dessous référence les balises XML du format EAC-CPF prises en
compte ou non au moment de l’import. Les points .
indiquent
que la balise est prise en compte (pour certaines partiellement). Les x
indiquent que la balise n’est pas prise en compte, les -
qu’elle ne l’est
que partiellement.
Sup. | Éléments EAC-CPF |
---|---|
x | abbreviation |
. | abstract |
. | address |
. | addressLine |
x | agencyCode |
x | agencyName |
. | agent |
. | agentType |
. | alternativeForm |
x | alternativeSet |
. | authorizedForm |
. | biogHist |
. | chronItem |
. | chronList |
. | citation |
x | componentEntry |
. | control |
. | conventionDeclaration |
. | cpfDescription |
. | cpfRelation |
. | date |
. | dateRange |
x | dateSet |
. | description |
. | descriptiveNote |
. | eac-cpf |
. | entityId |
. | entityType |
. | event |
. | eventDateTime |
. | eventDescription |
. | eventType |
. | existDates |
. | fromDate |
. | function |
x | functionRelation |
. | functions |
. | generalContext |
. | identity |
x | item |
x | language |
x | languageDeclaration |
x | languagesUsed |
x | languageUsed |
. | legalStatus |
. | legalStatuses |
x | level |
x | list |
x | localControl |
x | localDescription |
x | localDescriptions |
x | localTypeDeclaration |
x | maintenanceAgency |
. | maintenanceEvent |
. | maintenanceHistory |
x | maintenanceStatus |
. | mandate |
. | mandates |
x | multipleIdentities |
. | nameEntry |
x | nameEntryParallel |
x | objectBinWrap |
. | objectXMLWrap |
. | occupation |
. | occupations |
x | otherAgencyCode |
. | otherRecordId |
x | outline |
. | p |
. | part |
. | place |
. | placeEntry |
. | placeRole |
. | places |
x | preferredForm |
x | publicationStatus |
. | recordId |
. | relationEntry |
. | relations |
. | resourceRelation |
x | script |
x | setComponent |
. | source |
. | sourceEntry |
. | sources |
. | span |
. | structureOrGenealogy |
. | term |
. | toDate |
x | useDates |
Sup. | Attributs EAC-CPF |
---|---|
x | @accuracy |
x | @altitude |
x | @countryCode |
. | @cpfRelationType |
x | @functionRelationType |
x | @identityType |
x | @languageCode |
x | @lastDateTimeVerified |
x | @latitude |
- | @localType |
x | @longitude |
x | @notAfter |
x | @notBefore |
. | @resourceRelationType |
x | @scriptCode |
. | @standardDate |
. | @standardDateTime |
x | @style |
x | @transliteration |
. | @vocabularySource |
x | @xlink:actuate |
x | @xlink:arcrole |
- | @xlink:href |
- | @xlink:role |
x | @xlink:show |
x | @xlink:title |
x | @xlink:type |
x | @xml:base |
x | @xml:id |
x | @xml:lang |
Import de notices d’autorités en ligne de commande¶
Pour importer un fichier EAC-CPF, vous pouvez utiliser la commande “eac-import” de cubicweb-ctl :
cubicweb-ctl eac-import saemref --authority <NAA name> fichier.rdf
À moins qu’il n’y ait qu’une seul autorité de nommage définie dans votre référentiel, il vous faudra spécifier le nom de l’autorité à utiliser avec l’option –authority. Si vous ne connaissez pas le nom de votre autorité de nommage, lancer la commande sans l’option elle vous indiquera les valeurs possibles.
Export des notices en EAC¶
Le modèle des notices implémentées diffèrent nécessairement du module sous-jacent au EAC XML. Voici quelques explications concernant l’export d’une notice en EAC XML.
La balise maintenanceStatus
vaudra « new » si la notice a été créée mais pas encore été modifiée,
« revised » sinon.
La balise publicationStatus
vaudra « inProcess » pour les notices dans l’état brouillon, « published »
pour les notices dans l’état publiée.
Pour chaque forme du nom, l’attribute “parties” est découpée selon le caractère « , » puis chaque
élément est inséré dans une balise part
. C’est le traitement symétrique à ce qui est fait durant
l’import (concaténation des différentes balises part
avec le séparateur « , « )
SEDA¶
Administration des vocabulaires SEDA¶
Le cube SEDA vient avec un certain nombre de vocabulaires utilisés pour contrôler les valeurs possibles pour différents champs des profils. Cette section détaille quelques points à noter à ce sujet.
Paramétrage des vocabulaires¶
Tout d’abord, le vocabulaire associé par défaut à un champ du SEDA est configuré via des enregistrements dans la base de données, mais cela n’est pas à ce jour configurable via l’interface Web. Dans le cas des profils complet, on peut en configurer certains via l’onglet « vocabulaires ». Dans le cas des profils simplifiés ou des composants unités d’archives, les vocabulaires par défaut sont utilisés et il n’est pas encore possible de faire autrement.
Le champ « type de descripteur » d’un vocabulaire permet de contrôler l’interface de saisie des mots-clés associés à une unité d’archive, en ne rendant disponible que les vocabulaires d’un type données en fonction du type choisie dans l’interface.
Contrôle des valeurs entre les différents versions de SEDA¶
Lors de l’export SEDA, la valeur à utiliser dans le cas d’un champ non « sémantisé » (i.e. pour lequel on cherche à exporter une valeur et non une URL) est cherchée de la manière suivante. Étant donné un concept lié, on va chercher le libellé préféré dans la langue :
- spécifique à la version du SEDA exportée : “seda-2”, “seda-1”, “seda-02”,
- générique au SEDA : “seda”
- anglais : “en”
- français : “fr”
Gestion du vocabulaire « Catégories de fichier »¶
Ce vocabulaire est un peu particulier car il ne sert que dans l’interface utilisateur. En fonction de la valeur saisie, le profil sera lié à différents concepts correpondants pour les champs « type MIME » et « identifiant de format » du SEDA.
La structure de ce vocabulaire est la suivante :
+ catégorie
\
+ extension
\
+ type MIME
\
- identifiant de format (PRONOM)
Lorsqu’une ou plusieurs valeurs sont sélectionnées pour la catégorie de fichier d’un objet-données d’un profil, une jointure est effectuée sur le nom des type MIME et identifiants de format sous-jacent avec les vocabulaires « types MIME » et « formats de fichier » sélectionnés pour ce profil. Par défaut, le vocabulaire sélectionné pour ces deux champs et le vocabulaire « Catégories de fichier » (ce qui autorise théoriquement des valeurs supplémentaires indésirées pour chacun des champs mais reste un choix pragmatique) et celui-ci reflêtera donc seul les valeurs exportables.
Dans le cas d’un profil complet avec des vocabulaires spécifiques pour les listes « types MIME » et « formats de fichier » (par exemple en utilisant les vocabulaires dédiés « Types MIME » et/ou « Formats de fichier (PRONOM) ») il conviendra de s’assurer de la cohérence du vocabulaire « Catégories de fichier » avec les vocabulaires sélectionnés car les valeurs exportées seront l’intersection entre les valeurs spécifiées via la catégorie / extension du fichier et les valeurs disponibles dans l’un ou l’autre vocabulaire.
Vocabulaires de contrôle des langues¶
En l’état 2 vocabulaires sont fournis pour les langues : l’un correspond à la liste ISO-639-3 et contient plus de 7000 langues ; l’autre est une restriction de ce vocabulaire ne contenant que des langues dont le code à deux lettres est autorisé par la version 0.2 du SEDA. Celui-ci a été construit par extraction des codes ISO-639-3 de SEDA 1 puis filtrage sur les libellés spécifiés dans le schéma SEDA 0.2 et insertion du code à deux lettres correspondant.
À l’issue de ce traitement automatique, les langues suivantes présentes en SEDA 0.2 n’était pas représentées dans le vocabulaire ainsi créé :
- Bihari languages
- Bokmål, Norwegian; Norwegian Bokmål
- Catalan; Valencian
- Chichewa; Chewa; Nyanja
- Church Slavic; Old Slavonic; Church Slavonic; Old Bulgarian; Old Church Slavonic
- Divehi; Dhivehi; Maldivian
- Dutch; Flemish
- Gaelic; Scottish Gaelic
- Greek, Modern (1453-)
- Haitian; Haitian Creole
- Interlingue; Occidental
- Kalaallisut; Greenlandic
- Kikuyu; Gikuyu
- Kirghiz; Kyrgyz
- Kuanyama; Kwanyama
- Limburgan; Limburger; Limburgish
- Luxembourgish; Letzeburgesch
- Malay
- Navajo; Navaho
- Ndebele, North; North Ndebele
- Ndebele, South; South Ndebele
- Norwegian Nynorsk; Nynorsk, Norwegian
- Ossetian; Ossetic
- Panjabi; Punjabi
- Pushto; Pashto
- Romanian; Moldavian; Moldovan
- Sichuan Yi; Nuosu
- Sinhala; Sinhalese
- Sotho, Southern
- Spanish; Castilian
- Swahili
- Uighur; Uyghur
- Volapük
- Zhuang; Chuang
Les codes pour l’espagnol et le grec moderne ont été ajoutés manuellement, les autres ont été ignorées pour le moment.
Si vous souhaitez utiliser le vocabulaire complet, c’est possible en tapant les commandes suivantes dans un shell cubicweb :
rql('DELETE CS scheme_relation_type RT WHERE '
'RT name IN ("seda_language_to", "seda_description_language_to")')
rql('SET CS scheme_relation_type RT WHERE '
'CS name "Langues (ISO-639-3)", '
'RT name IN ("seda_language_to", "seda_description_language_to")')
commit()
sachant qu’en faisant ceci vous risquez de générer des profils SEDA 0.2 invalides car utilisant des codes à deux lettres inconnus de cette version du SEDA. Il faudrait pour palier à ce problème retirer du vocabulaire la langue “seda-02” fournissant un code non supporté et améliorer la gestion de ce genre d’erreur dans l’application.
Export des profils SEDA¶
Selon leurs caractéristiques, les profils créés dans l’application sont exportable dans une ou plusieurs versions du SEDA (2, 1 ou 0.2) au format RelaxNG, celui-ci étant plus adapté à la génération de profil que les schémas XML.
Les versions supportées sont indiquées dans l’onglet “diagnostic” du transfert.
Il est important de noter que quelque soit la version utilisée, le profil seul n’est pas suffisant pour valider un bordereau. Il faut également valider ce dernier contre le schéma XSD de la version correspondante, car elle permet de valider certains aspects qui ne seront pas validés par le profil.
Limitation des schémas RelaxNG¶
Les profils autorisants plusieurs éléments de même nom à un même niveau avec plus d’un d’entre eux ayant une cardinalité différente de 1 vont générer des schémas RelaxNG valides mais invérifiables par les validateurs existants (Jing par exemple). Une solution technique reste à trouver pour ce problème. Les profils dans ce cas peuvent être identifiés à l’export à l’aide de l’attribut seda:warnings ([1]) sur la balise racine (rng:grammar ou xsd:schema selon le format choisi) qui contiendra la chaîne “rng-ambiguous” dans ce cas.
[1] | le préfix seda étant associé à l’espace de nom « fr:gouv:culture:archivesdefrance:seda:v2.0 » |
Identification des éléments¶
Afin de faciliter l’éventuel travail d’une application cliente, des identifiants sont exportés pour les différents éléments répétables du profil (e.g. unité d’archive, objet-données, mot-clé, etc.) via l’attribut standard xml:id.
Export SEDA 2¶
Gestion des identifiants et références¶
Les identifiants spécifiés dans l’interface utilisateur sur les objets-données et les unités d’archives sont reportés via un attribut xml:id sur l’élément correspond dans le profil RelaxNG généré. La valeur de cette attribut est ensuite utilisée comme valeur par défaut des éléments référençant cet élément.
Ce mécanisme permet de gérer des identifiants pour des éléments XSD qui ne sont pas encore créés (puisqu’ils le seront à la création du bordereau), ce qui est nécessaire pour pouvoir ensuite les référencer, la norme SEDA 2 faisant largement usage de telles références. Il est à noter qu’il est donc à la responsabilité de l’outil qui génère le bordereau de gérer les définitions de références ainsi créées en substituant dans les éléments référencés la valeur de l’identifiant qu’il a attribué à l’élément portant le xml:id correspondant.
Ceci n’étant pas un mécanisme standard de RelaxNG, la cohérence des références entre le bordereau et le profil ne sera pas vérifiée par les outils de validation XSD classiques.
Autres limitations¶
Il est à noter que les références sont exportées en utilisant le type NCName et non IDREF comme dans le schéma XSD : c’est lié au fait qu’il n’est pas autorisé en RelaxNG d’utiliser le type IDREF pour le contenu texte d’une balise, mais uniquement pour le contenu d’un attribut :
<reference>id référencé</reference>
versus :
<reference idref="id référencé"/>
Export SEDA 0.2 et 1¶
Les schémas des versions 0.2 et 1 de la norme SEDA utilisent des types personnalisés venant de différents espaces de nom (par exemple fr:gouv:culture:archivesdefrance:seda:v1.0:QualifiedDataType:1, urn:un:unece:uncefact:data:standard:UnqualifiedDataType:10, etc.). Ces types ne sont malheureusement pas utilisables dans un schéma RelaxNG, uniquement XSD. Pour palier à ce problème, les éléments utilisant ces types sont exportés en tant que simple chaîne de caractères « xsd:string », en supposant que les transferts seront validés contre le profil et contre le schéma XSD de la norme. La même stratégie était utilisée par Agape V1.
Le SEDA 2 n’utilise plus ces types et n’est donc pas exposé à ce problème.
Services Web spécifiques¶
Authentification¶
L’authentification est effectuée en envoyant des requêtes signées à CubicWeb. Il faut commencer par créer un jeton d’authentification pour l’utilisateur en question, et sauvegarder l’identifiant et le secret du jeton quelque-part.
La création du jeton se fait via l’action « profil » du menu utilisateur, puis en cliquant sur l’action « add token » du sous-menu « ajouter » de la boite d’actions.
Sur la base de cet identifiant et secret du jeton, on authentifie une requête HTTP en ajoutant dans les en-têtes :
Content-MD5
: le hash MD5 du corps de la requêteDate
: la date d’émission de la requête au format “%a, %d %b %Y %H:%M:%S GMT” (heure GMT donc)Authorization
: “Cubicweb <token-id>:<signature>” avec <token-id> l’identifiant du jeton et <signature> une signature HMAC (RFC 2104) de la concaténation :- du verbe HTTP (“GET”, “POST”, etc),
- de l’URL,
- des en-têtes HTTP
Content-MD5
,Content-Type
etDate
,
en utilisant le secret.
À noter qu’il est important que l’heure du client et serveur soient synchronisées. Il est donc recommandé d’utiliser un serveur NTP sur chaque machine.
Listes des services¶
Pour obtenir les données au format RDF XML, il convient de positionner l’en-tête HTTP Accept
pour la négociation de contenu.
Description des vocabulaires¶
Liste des jeux de données au format RDF SKOS (XML)
GET /conceptscheme
Accept: application/rdf+xml
Description complète du jeu de données au format RDF SKOS (XML)
GET /conceptscheme/<eid>
Accept: application/rdf+xml
Description des services archives¶
Liste des services d’archives avec leur services versants
GET /archival-units
Accept: application/json
Exemple de réponse :
[
{
"ark": "23578/ou000190053",
"name": "Gironde. Archives départementales",
"state": "published",
"url": "http://orion.tls.logilab.fr:8080/ark:/0/ou000117240",
"authority": {
"ark": "XXX/o20",
"name": "Test saem",
"url": "http://orion.tls.logilab.fr:8080/ark:/XXX/o20"
},
"deposit-units": [
{
"ark": "75548/ou000117317",
"name": "Cenon. service de la Commande publique",
"state": "published",
"url": "http://orion.tls.logilab.fr:8080/ark:/75548/ou000117317",
"authority": {
"ark": "XXX/o13",
"name": "Ville de Cenon",
"url": "http://orion.tls.logilab.fr:8080/ark:/XXX/o13"
}
},
{
"ark": "75548/ou000117342",
"name": "Direction du Patrimoine",
"state": "published",
"url": "http://orion.tls.logilab.fr:8080/ark:/75548/ou000117342",
"authority": {
"ark": "XXX/o19",
"name": "Conseil départemental",
"url": "http://orion.tls.logilab.fr:8080/ark:/XXX/o19"
}
}
]
}
]
Allocation d’identifiants ARK¶
Le point d’accès /ark
permet d’obtenir un identifiant ARK à partir d’une
autorité administrative (collectivité) spécifié via le paramètre de requête
organization=<identifiant ARK>
. L’identifiant d’une autorité administrative
peut être obtenu à partir des données RDF (elles-mêmes disponibles via une
requête OAI-PMH sur une unité administrative) en récupérant la valeur du champ
dc:identifier
(normalement une chaîne de caractères commençant par
“ark://”).
Pour utiliser ce service il faut être authentifié.
Exemple de requête :
POST /ark&organization=ark%3A%2F%2F12345%2Fo67
Accept: application/json
Exemples de réponse (JSON)
[{'ark': '12345/ext-000000001'}]
[{'error': 'This service is only accessible using POST.'}]
[{'error': 'This service requires authentication.'}]
[{'error': 'Organization "12345/o67" cannot assign ARK identifiers.'}]
[{'error': 'No organization matching identifier "12345/o67".'}]
[{'error': 'Missing required "organization" query parameter.'}])
Import d’une notice d’autorité au format XML EAC¶
Il est possible de poster un fichier XML EAC sur point d’accès /authorityrecord
afin d’importer
la notice d’autorité qu’il décrit. Ce service renverra l’identifiant ARK de la notice importée ou
bien une erreur en cas de problème (voir les exemples ci-dessous).
Pour utiliser ce service, il faut être identifié avec le compte d’un utilisateur qui est lié à une autorité administrative, elle-même liée à une autorité nommante.
Exemple de requête :
POST /authorityrecord
Content-Type: application/xml
Accept: application/json
<?xml version="1.0" encoding="UTF-8"?>
<eac-cpf>
<control>
...
</eac-cpf>
Exemples de réponse (JSON)
[{'ark': '12345/r000000042'}]
[{'error': 'This service requires authentication.'}]
[{'error': 'Authenticated user is not linked to an organisation,
or his organisation has no ARK naming authority..'}]
[{'error': u'Invalid XML file',
'details': "Start tag expected, '<' not found, line 1, column 1"}]
[{'error': 'Unexpected EAC data',
'details': 'Missing tag control in XML file'}])
OAI-PMH¶
On implémente les 6 types de requêtes (verbes) du protocole :
- GetRecord
- Identify
- ListIdentifiers
- ListMetadataFormats
- ListRecords
- ListSets
Moissonnage sélectif¶
On supporte le moissonnage sélectif à l’aide des Sets hiérarchiques avec a priori un hiérarchie à deux niveaux (pour l’instant, seul le cas des agents est vraiment concret pour l’aspect hiérarchique).
Le premier niveau hiérarchique correspond au type d’entité sur lequel il faut filtrer la réponse, on a 3 types de filtrage possible :
- agent : agents
- organizationunit : unités administratives
- profile : profils SEDA
- conceptscheme : vocabulaires contrôlés
- concept : concepts issus d’un vocabulaire contrôlé
Ainsi une requête pour obtenir la liste des identifiants des agents du
référentiel prend la forme : <baseurl>oai?ListIdentifiers&set=agent
Pour le cas des unités administratives, on supporte un axe de hiérarchie :
role
: les rôles archivistiques (service versant, service de contrôle, etc.)
Le prototype d’une requête avec un spécification de set hiérarchique est :
<baseurl>oai?verb=<VERB>&set=<entity type>:<axis name>:<axis value>
Exemple de requêtes¶
ListSets
<baseurl>/oai?verb=ListSets
ListIdentifiers avec un filtrage set (obligatoire dans notre cas) :
<baseurl>oai?verb=ListIdentifiers&set=organizationunit
ListIdentifiers avec filtrage hiérarchique :
<baseurl>oai?verb=ListIdentifiers&set=organizationunit:role:deposit
ListRecords avec ou sans filtrage hiérarchique :
<baseurl>oai?verb=ListRecords&set=conceptscheme <baseurl>oai?verb=ListRecords&set=organizationunit:role:deposit
GetRecord avec spécification de l”identifier (obligatoire dans notre cas) :
<baseurl>oai?verb=GetRecord&identifier=ark:/01234/000004145
Moissonnage sélectif d’objets reliés à d’autres objets¶
Certains Sets définis dans le référentiel permettent de moissonner des objets
en fonction de leur relation avec d’autres objets. C’est le cas par exemple
des concepts en fonction de leur appartenance à un vocabulaire à l’aide du set
concept:in_scheme:<scheme identifier>
ou encore des profils
sélectionnables par service versant à l’aide du set
profile:transferring_agent:<agent identifier>
.
Dans ces cas, le set prend la forme :
<type d'objet>:<relation>:<identifiant>
Il n’est pas possible selon la norme OAI d’utiliser des identifiants ARK pour les sets du
moissonnage sélectif car ces derniers contiennent des caractères interdits (:
et /
notamment). Ce problème reste à résoudre à ce jour. Pour le moment, l’identifiant ARK peut-être
directement utilisé simplement en retirant le préfix « ark:/ ».
Format des enregistrements record des réponses OAI-PMH¶
Pour les requêtes GetRecord et ListRecords, la réponse OAI-PMH contient
deux balises à l’intérieur de la (ou des) balise(s) <record>
:
- la balise
<header>
, qui contient l”identifier de l’enregistrement ainsi que sa date de modification ; - la balise
<metadata>
qui contient les données de l’enregistrement dont le format dépend du type d’objet de la requête.
Pour les objets de type agent et vocabulaire contrôlé, la balise
<metadata>
contient une représentation RDF des entités. Pour les profils
SEDA, on renvoie le XSD SEDA en version 0.2.
Modèle de sécurité de l’application¶
Accès anonyme¶
Par défaut, l’application est installée en autorisant l’accès aux données sans avoir à s’authentifier. Les utilisateurs anonymes peuvent voir toutes les données métiers mais ne peuvent rien modifier.
Il est possible de supprimer l’accès anonyme en commentant les options anonymous-user
et
anonymous-password
du fichier all-in-one.conf
de l’instance. Attention, il faut synchroniser
l’utilisateur associé à ses options dans la base de données si vous souhaitez les modifier.
Utilisateurs « standards »¶
Avertissement
Hormis l’utilisateur dédié aux accès anonymes (en général « anon »), tous les utilisateurs doivent être dans le groupe « utilisateurs ». De plus pour le bon fonctionnement de certain aspects métier, il faut les rattacher à une autorité administrative.
Un utilisateur standard (dans le groupe “utilisateurs”), rattaché à une organisation, peut :
- ajouter et mettre à jour des notices d’autorité, des profils SEDA ;
- ajouter et mettre à jour des concepts dans des vocabulaires SKOS existants ;
- ajouter et mettre à jour des agents et unités d’organisation appartenant à la même autorité administrative que lui (ce qui inclut la sélection des profils et vocabulaires liés à une unité d’organisation).
Administrateurs¶
Les utilisateurs qui sont ajoutés dans le groupe « administrateurs » ont des droits supplémentaires sur la plate-forme, notamment :
- ajouter et modifier des utilisateurs ;
- ajouter et modifier des autorités d’assignement de noms (ARK NAA), des autorités administratives et des vocabulaires.
Les actions spécifiques à l’administrateur sont accessibles dans l’interface web via la section « Administration » de la page d’accueil une fois authentifié.
Outil en ligne de commande pour intéragir avec le SAEM¶
saemref-client est un client en ligne de commande permettant d’intéragir avec certains services web fournis par le référentiel SAEM. Son code source est disponible sur framagit.
Pour lister les commandes disponibles :
./saemref-client --help
ou pour obtenir les options spécifiques à une commande :
./saemref-client eac-download --help
Gestion des notices d’autorités¶
Pour récupérer les notices d’autorités :
./saemref-client eac-download https://demo.logilab.fr/saem-demo
Cette commande va rappatrier les notices d’autorités publiques du référentiels sous forme de fichiers XML au format EAC qui seront mis dans le répertoire de travail.
Pour envoyer une nouvelle notice d’autorités au format EAC dans un fichier fichier-eac.xml
:
./saemref-client eac-upload https://demo.logilab.fr/saem-demo fichier-eac.xml
Cette commande s’attend à trouver dans le répertoire de travail un fichier cubicweb.yaml
comportant les identifiants de connexion au format YAML, par exemple :
id: token-arkheia
secret: 11e9ae06d7754a89a13d0e7245bc6132320cb081813b4d229a4d6
Gestion des vocabulaires¶
Pour récupérer les concepts d’un vocabulaire :
./saemref-client skos-download https://demo.logilab.fr/saem-demo 23578/v000200007
Cette commande va récupérer les concepts du vocabulaire ayant l’identifiant ARK
23578/v000200007
, sous forme de fic hier XML au format SKOS qui serons mis dans un
sous-répertoire 23578-v000200007
du répertoire de travail.
Installation¶
Si vous avez une distribution python, vous pouvez simplement l’installer avec pip :
pip install saemref-client
Sinon, sur Windows il suffit de télécharger et extraire l’archive https://ci.appveyor.com/api/projects/logilab/saem-client/artifacts/saemref-client.zip et de lancer saemref-client\saemref-client.exe
Historique des révisions¶
0.17.2
- Correction de l’import d’unités d’archive dans un profil (#43776568)
- Prise en compte des identifiants ARK pour l’import LCSV de concepts en ligne de commande (#44146518)
- Suppression des contraintes NOT NULL pour les champs « ville », « rue » et « code postal » du type d’entité « addresse postale » pour permettre l’import de données lorsque ces champs sont absents (ils sont non-requis par la norme EAC-CPF) (#44640239)
0.17.1
- Correction de la création d’une nouvelle version d’un profil (#42522316)
- Suppression des formats dupliqués dans l’export XSD/RNG (#42606987)
- Correction de l’erreur sur suppression d’un objet-donnée dans un profil (#42606987)
- Possibilité d’import LCSV en ligne commande (#37463080)
- Possibilité de tri sur les noeuds de l’arbre SEDA via drag & drop (financé par le SIAF)
0.17.0
SEDA :
- Ajout d’un identifiant sur les noeuds d’un profil (#39304385)
- Correction d’erreur sur les profils créés avant la version 0.16.0 (#39859256)
- Modification pour n’avoir que le vocabulaire « catégorie de fichiers » comme référence pour les types MIME et identifiants de format (#39322647)
- Ajout d’un attribut dans le XML indiquant si le profil est ambigüe ou non (#39305748)
- Transformation du mécanisme de détection des profils non validable en message de diagnostic du problème plutôt qu’une erreur (#39302963)
Vocabulaires :
- Correction évitant de modifier la date de modification du vocabulaire « type de mot clé » lorsque celui-ci est utilisé pour typer un autre vocabulare (#37975627)
- Restriction du vocabulaire des langues aux langues du SEDA 0.2 (#40281602)
Autres :
- Publication automatique des unités administratives et des contacts référents (#37370184)
- Ajout d’un service web retournant les sites d’archives et les versants associés (#37441757)
0.16.1
SEDA :
- Correction du type mime et identifiant de format des objet-données importés d’un composant unité d’archive (#38194980)
- Correction erreur sur création d’une unité d’archive ou d’une règle de gestion (#37884173)
0.16.0
SEDA :
- Ajout d’un contrôle de conformité pour les cardinalités ambigües en SEDA 0.2 (#34307460)
- Filtrage du vocabulaire « langues » sur les codes disponibles en SEDA 0.2 (#36332314)
- Gestion des type MIME et identifiants de format via un vocabulaire « catégorie de fichiers » (#36331831)
- Correction crash sur import d’UA dans un profil (#37372358)
Autres :
- Ajout de la possibilité d’importer des concepts dans un vocabulaire existant (#29482125)
- Correction crash sur création d’une notice d’autorité sur une base vide (#36759603)
- Correction crash sur ajout d’un email à un utilisateur (#36119710)
- Migration vers cubicweb 3.25 (#36861534)
0.15.6
SEDA :
- Correction de l’ordre des balises Document / ArchiveObject (#33070904)
- Correction de l’export des types MIME (e.g. pdf au lieu de application/pdf) (#32206261)
- Correction de l’export du langauge (e.g. fra au lieu de fr) (#32959185)
- Changement du libellé « Accord de service » devient « Accord de versement » (https://www.cubicweb.org/ticket/17098388)
- Changements pour s’assurer qu’on ne génère pas de profils invalidables
(https://www.cubicweb.org/ticket/17098404)
- dans le cas des éléments répétables (unité d’archive, objet données, mot-clé, historique) on ne peut plus avoir qu’un seul élément avec une cardinalité différente de un, sans quoi une erreur sera levé à l’édition
- pour éviter les erreurs, la cardinalité par défaut est maintenant « obligatoire et unique » plutôt que « optionel et unique »
- lors de l’export SEDA, on s’assure que l’élément de cardinalité différente de un est à la fin
Web services :
- Correction de l’identification de l’organisation sur le service d’attribution d’identifiant (#32206278)
0.15.5
OAI-PMH :
- Correction pour ne pas mettre à jour le concept/scheme lors du référencement par un profil ou une notice (#29296087)
SEDA :
- Correction des permissions rendant possible la modification d’un profil après sa publication (#25271719)
- Correction pour l’affichage de la cardinalité sur le champ date de début en création (#24660770)
- Correction de l’affichage du service producteur sur une unité d’archive (seda #17084054)
- Correction des valeurs exportées en SEDA 0.2 pour les langues (seda #17091259)
- Correction du manque de préfixe “ark://” lors de l’export SEDA 2 des services (#26003592)
Web services :
- Le service d’assignement d’identifiant ark attend maintenant l’identifiant ARK complet de l’organisation (#29484932)
0.15.4
Sécurité :
- Correction des permissions d’ajout sur les unités d’organisation et les agents (#21913461)
- Correction des permissions d’ajout sur les types de notice (#21936714)
Interface utilisateur :
- Correction sur le rendu de la pagination après filtrage à l’aide des facettes (#21942222)
SEDA :
- Correction de l’ordre des élements Description et Language dans l’export SEDA 0.2 (#23707701)
- Correction crash sur export SEDA d’un profil avec un service producteur non fixé (#22071759)
- Ajout du préfix “ark:/” sur la valeur exportée pour ArchivalProfil (#23707073)
0.15.3
Interface utilisateur :
- Correction crash du formulaire de modification d’une notice sur la démo (#18336413, #19232725)
- Correction de la disparition du bouton « + » (ajouter un profil) lors de l’utilisation d’une facette (#18229045)
- Correction de l’incohérence des champs visibles dans le formulaire de création d’unité d’archive (#18337031)
- Correction du crash de l’onglet “concepts” d’un vocabulaire « vide » (#15932289)
- Changement du libellé du bouton pour l’import d’unité d’archive (#18337720)
- Changement du libellé de l’onglet “utilise” entre autorité nommante et notice d’autorité pour éviter une ambiguité (#19227068)
- Réinsertion du lien pour afficher la version du référentiel (#18554125)
Sécurité / permissions :
- Ajout de la possibilité à un utilisateur standard d’éditer les relations d’une notices (#18336405)
- Suppression de la possibilité à un administrateur de modifier un profil après sa publication (#19216837)
- Suppression de la possibilité d’ajouter des vocabulaires à un utilisateur standard (#18369309)
0.15.1
Interface utilisateur :
- cohérence entre le formulaire d’édition / création et l’onglet description d’une unité d’archive (seda #76bb0064f236)
- changement traduction des éléments du menu “ajouter” de l’onglet « unité d’archives » (seda #7769b2787347), et de précurseur vs prédécesseur en eac (saem #fe766631d60a)
- amélioration du formulaire d’édition d’un vocabulaire (seda #c82265657b76, #78ea78713e34), d’un utilisateur (saem #810a47d39c9f, #80dc15aa47bc), de copie d’un profil (saem #5bacf7866df5)
- simplification générale de l’interface en enlevant les éléments indésirés (saem #55db28377169)
Schéma :
- ajout d’une contrainte sur l’état publié d’un profil pour la relation « utilisé par » (saem #95202d3dc968)
- ajout d’une contrainte d’unicité sur Agent(nom, autorité administrative) (saem #57c9841da900)
- suppression d’une contrainte d’unicité sur OrganizationUnit(nom) (saem #ca3741e6372d)
- correction / amélioration de la sécurité pour les relations « type d’agent » (saem #7e1a8f1c1102), « nouvelle version de » (saem #f3850e014596), « type de mot clé » (saem #36596ca5247c), les types d’entités ARK NAA (saem #85e085e85f4a), Activity (saem #b8599a52fa6d, #569dbecd0736, #a42d3be56b5f), Agent et OrganizationUnit (saem #569dbecd0736)
Autres :
- ne copie plus la relation « nouvelle version de » lors d’une copie (saem #dccf96319df2)
- cohérence des URL générés en fonction des versions du SEDA (saem #eacf1752ed3d)
0.15.0
Gestion fonctionnelle :
- Ajout d’un onglet pour les entité Autorités administratives (#12251003)
- Correctif pour l’ajout d’une relation “utilise” entre autorité nommante et notice d’autorité (#14910419)
EAC :
- Affichage des relations entre agents dans une vue liste même pour les relations hiérarchiques et chronologique (#14591642)
- Export de l’identifiant ARK dans la fiche EAC (#12572781)
SEDA :
- Support des activités PROV sur les profils SEDA (#3101354)
- Affichage des règles de gestion héritées (#14593198)
- Correctif pour la création unité d’archives en tant qu’utilisateur non admin (#15224324)
- Correctif pour la création d’un objet données dans une unité d’archives (#14592486)
Interopérabilité :
- Exposition des données prov-o dans les vues RDF des notices d’autorité, vocabulaires et concepts (#12175187)
Interface utilisateur :
- Typage des vocabulaires, améliorant l’interface de saisie des mots-clés SEDA (#12351787)
- Correction d’un libellé sur la fenêtre modale de sélection de concept (#12346621)
- Amélioration de l’interface de saisie des mots clés (#14592456)
Autres :
- Possibilité de séparer une instance web d’une instance point d’accès OAI-PMH (#11855076)
- Correctif pour la création d’un email pour un utilisateur applicatif impossible (#15224342)
0.14
Gestion fonctionnelle :
- Ajout d’un ark sur les organisations (#12308170)
- Ajout d’une relation “utilise” entre autorité nommante et notice d’autorité (#12572793)
EAC :
- Amélioration de la gestion des relations entre agents (#12136839)
- Implémentation du champ « statut juridique » (#12218902) et différentes formes du nom (#12249296)
- Plus de création d’agent lors de l’import EAC (#12573609)
- Outil d’import en ligne de commande d’un lot de fichiers EAC (#12294160)
- Ajout d’un service web pour l’ajout de fichier EAC (#12362590)
SEDA :
- Modification des messages par défaut de l’onglet contenu d’une unité d’archives, financé par le SIAF (#12346618)
- Séparation mot-clé libre / mot-clé contrôlé (#12349783)
- Suppression de l’identifiant pour les unités d’archives et objets-données (#12349490 et #12349471)
- Complétion des profils pour permettre la validation côté asalae (#12542834)
Interopérabilité :
- Rationalisation des urls et identifiants pour utiliser l’ARK quand disponible (#3606819)
- Développement d’un client en ligne de commande pour poster un fichier EAC (#12572067) et moissoner les notices EAC et les vocabulaires SKOS (#12571247), mis à disposition à Anaphore sous la forme d’un exécutable Windows
- Propagation des règles de gestion (#12369828)
- Ajout d’un set OAI pour les autorités administratives, aka organisations (#12369805)
Interface utilisateur :
- Suppression de l’affichage « Autorité d’archivage » sur les vue des autorités administratives (#12272253)
Autres :
- Modification de la formule Salt pour installer des paquets Python hébergé sur pypi.python.org plutôt que des RPM d’un entrepôt spécifique maintenu par Logilab
- Amélioration de la couverture de tests fonctionnels dans la formule Salt et ajout de test du client en ligne de commande vis-à-vis d’une application déployée.
- Montée de version de différents composants sous-jacents, et notamment passage à cubicweb 3.24
- Modification de la structure du cube saem_ref pour être transformée en paquet python standard (possible depuis cubicweb 3.24)
0.13
SEDA :
Changement majeur lié à l’utilisation du cube seda développé avec le SIAF sur la base du modèle SEDA 2, en lieu et place du modèle développé dans le référentiel. Pour le moment, uniquement les profils « simplifiés » du cube seda sont visibles, et non les profils SEDA 2 complet. Ce changement entraîne :
- quelques éléments supplémentaires dans le modèle SEDA supporté (qu’il reste à exporter en XSD/RNG 0.2/1.0),
- une interface utilisateur un peu différente,
- un support de l’export des profils au format RNG, ainsi qu’en version SEDA 2,
- uniquement des unités d’archives comme composant SEDA, plus de data object / document.
A noter que l’aide à la saisie « globale » (i.e. au niveau du profil) était avant transmise via le champ commentaire du seda 0.2. C’est maintenant une annotation comme pour les autres, et on peut décrire des commentaires comme les autres champs SEDA.
EAC :
Utilisation du cube eac extrait du référentiel pour utilisation dans le cadre du projet France Archives. Ceci a permis d’avoir dans cette livraison l’implémentation du champ “OtherRecordId” qui a été financé par le SIAF.
OAI :
- Il faut maintenant obligatoirement indiquer le « metadata prefix » lors des échanges oai pmh ;
- Dans le cas des profils, il y a maintenant les formats seda02xsd, seda02rng, seda1rng et seda2rng ;
- Les notices d’autorités sont exposés en EAC via le format eac.
RDF :
- Utilisation d’URL pérenne dans les exports RDF, i.e. n’incluant pas d’élément possiblement changeant de l’entité, et si possible en se basant sur l’identifiant ark.
0.12
Interface utilisateur :
- Optimisation pour minimiser le nombre de requêtes des pages principales (#12136865)
- Déploiement WSGI - devrait améliorer le support des requêtes concurrentes (#12136865)
EAC :
- Séparation d’agent en une partie fonctionnelle (OrganizationUnit et Agent) et une partie archivistique EAC (AuthorityRecord) (#12140367).
SEDA :
- Amélioration de l’arbre SEDA (#12059534) :
- drag and drop désactivé pour les anonymes
- suppression des requêtes synchrone, ce qui devrait améliorer l’utilisabilité globale
- tentative d’amélioration de l’affichage des hiérarchie en supprimant la marge sur les feuilles de l’arbre
- Import multiples #12205200
Interopérabilité :
- Modification du XSD exporté : - plus d’attribut type sur les éléments définis « en-ligne », - utilisation d”extension pour les éléments avec un contenu textuel et des attributs.
- Les setspecs OAIPMH
agent:kind:<KIND NAME>
ont été supprimés du fait de la dichotomieAgent
/OrganizationUnit
. - Le setSpec OAI-PMH
agent
a été renommée enorganizationunit
(incluant tous les setSpecs sous-jacents tels queorganizationunit:role:control
par exemple). - Un setSpecs OAI-PMH
agent
a été introduit pour permettre de moissonner les entités de typeAgent
.
0.11.0
Interopérabilité :
- Ajout d’un préfix “ark:/” devant la valeur du champ “identifier” de l’en-tête OAI-PMH, qu’il convient de retirer pour construire les setSpec qui eux n’ont pas changé (#11831203).
- Ajout dans le RDF d’un agent des relations hiérarchiques et d’association avec l’ontologie Organization du W3C (#11668412).
- Correction de l’export XSD des profils SEDA pour produire du XSD valide et non le format spécifique à Agape (#3606843)
Interface utilisateur :
- Charte graphique (#11754074).
- Ajout des types d’entités Collectivité (Authority) et Autorité d’assignement de nom ARK (ARKNameAssigningAuthority) afin de contrôler la collectivité responsable d’un agent et l’autorité d’assignement de nom à utiliser pour la génération des identifiants ARK (#11855091).
- Correction de l’autocomplétion pour éviter des propositions incohérentes (#11884489).
- Affichage uniquement des agents de types personnes dans la liste déroulante contact référent (#11867467).
- Lancement automatique de la recherche après sélection d’une proposition de l’autocomplétion (#11884492).
- Optimisation de l’affichage des arbres de concept sur les vocabulaire : temps d’affichage divisé par deux (#11884230).
- Suppression de l’action « Copier » sur les agents (#11716529).
- Correction de l’import des objets-données ou des unités documentaires SEDA (#11785516).
- Correction de l’affichage de l’arbre « Elément du profil SEDA » pour les objets données ou des unités documentaires (#11785524).
- Navigation plus cohérente pour les objets-données et unités documentaires des unités d’archive SEDA (#11557857)
- Utilisation de l’annotation comme titre des objets-données SEDA (#3471036).
- Utilisation d’un vocabulaire pour les durées de conservation SEDA (#3466081).
- Affichage correct des données contenant des accents importées via EAC (#11664020).
EAC :
- Meilleure gestion de l’import/export des paragraphes (#11987275) et des liens (#11664008) EAC.
- Import des balises <generalContext> (#3511427) et <objectXMLWrap> (#3381087).
- Import des fichiers sans éléments <authorizedForm> (#11716516).
- Nommage des fichiers exportés sur la base de l’identifiant ARK (#11664003).
- Corrections pour la validation de l’EAC exporté (#11663901).
Déploiement :
- Mise à disposition d’une recette Salt pour l’installation sur CentOS 6 ou 7, incluant la mise à disposition d’un entrepôt de paquets CentOS 7 (#11884390).
0.10.0
- affichage des (sous)-concepts sous forme d’une liste paginée plutôt qu’un arbre s’il y a plus de 500 concepts à afficher (#2974227, #3350215)
- amélioration de synchronisation de source depuis l’interface : aide en ligne, warning plutôt qu’erreur en cas de définition multi-lingues non supportée, outil pour import de thésaurus de taille importante (#3392144, #3349339)
- problème d’interface empêchant la liaison de concept équivalent si le vocabulaire est publié (#5603390)
- possibilité de mise à jour des vocabulaires contrôlés publiés : possibilité d’ajout de nouveaux concepts et d’ajout / suppression de libellés (#11578206)
- import des balises EAC mandates et des sous-balises mandate (#3381084)
- import des balises EAC occupations et des sous-balises occupation (#3381034)
- export au format XML EAC des fiches agents (#3239716)
- état des lieux des balises non implémentés du schéma EAC (#11543984)
- changement de la gestion des vocabulaires sources : dans l’interface, soit on sélectionne un vocabulaire et un champ permet de sélectionner un concept de ce vocabulaire via auto-complétion, soit on peut saisir du texte libre (#3512232, #3511423)
- on n’affiche pas les agents liés à des utilisateurs dans les listes déroulantes (#3384078)
- on n’affiche pas les agents non publiés dans les listes déroulantes (#3507748)
- intégration basique de la charge graphique développé pour le blog saem, dont notamment le logo (#11520162)
- plus d’incohérence dans l’interface des agents quand on édite les rôles archivistiques (#3510158)
- correction fautes d’orthographe (#11544090, #11557853)
- suppression de la relation useProfile dans “export RDF, on peut utiliser les sets OAI pour obtenir cette information (#3507873)
- ajout des relations chronolique en utilisant dcterms:isReplacedBy (partie de #3477127)
- suppression de la gestion de connecteur vers alfresco et asalae (#3478851)
- amélioration de la gestion des démonstrateurs : sentry, supervision, docker reproductible (#11509296)
0.9.1
- l’export RDF d’un agent de type service versant n’inclut plus la description complète de son service archive, uniquement son URL
- L’attribut foaf:type d’un agent de type contact dans l’export RDF d’un agent est bien foaf:Person
- Plus d’agent dans l’état brouillon exporté sur certains set OAI
- On ne peut plus supprimer des éléments d’un profil publié
- Corrections de plantages sur agent avec lieu sans adresse ou sur certains set OAI avec resumption token
- Corrections / amélioration de label
0.9.0
ajout des concepts en tant que set specifiers OAI-PMH de premier niveau
la requête oai?verb=ListSets renvoie maintenant des set avec le préfixe concept du type :
- concept
- concept:in_scheme:saemref-test/000002219
ce dernier résultat permet de filter les concepts d’un vocabulaire particulier via son identifiant
correction du problème de dates pour l’OAI-PMH : toutes les dates sont maintenant en UTC tant au niveau des résultats retournés que des restrictions de requête via from/until ; on retourne les informations de fuseaux horaires (le suffixe Z dans le cas de l’UTC).
ajout d’attribut à la balise OAI-PMH pour la définition des espaces des noms notamment et du schéma de validation
utilisation d’identifiant ARK pour les profils dans OAI-PMH
gestion des entités supprimées dans OAI-PMH par ajout d’une balise <header status= »deleted »>
web service d’attribution d’ARK (il faut être authentifié)
POST /ark/ Accept: application/json
Exemples de réponse (JSON)
[{'ark': '12345/ext-000000001'}] [{'error': 'This service is only accessible using POST.'}] [{'error': 'This service requires authentication.'}]
le service versant et service archive associé d’un profil ne sont plus inclus dans l’export SEDA XSD