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 :

  1. spécifique à la version du SEDA exportée : “seda-2”, “seda-1”, “seda-02”,
  2. générique au SEDA : “seda”
  3. anglais : “en”
  4. 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.