CRGGIDNotes de travail à propos du cas MRCI-1

Résumé

Ce document contient des notes de travail à propos du cas MRCI-1.

Auteur: Christian Rémillard, GRDS
Version: 1.0
Est remplacé par: http://grds.ebsi.umontreal.ca/CRGGID/cas-MRCI-1/notes_20031203.htm
URL: http://grds.ebsi.umontreal.ca/CRGGID/cas-MRCI-1/notes_20031126.htm


Note: Les paragraphes marqués de la mention [À FAIRE no.x] sont des points en suspends pour les quels un ou des participants au projet doivent statuer.

Modèle et profil de métadonnées

Format

[IROSOFT] Il est possible qu'un document existe en plusieurs formats. Il se peut aussi qu'un document soit composé de parties de différents formats. Par exemple, un document dont la table des matières est en html et dont les parties sont en pdf. Il a donc été convenu avec les gens du MRNFP, lors de la rencontre de vendredi après-midi (2003-11-21) que la saisie dans le formulaire allait adopter la convention suivante:

champ format champ localisation
un seul plusieurs
un seul un document (ne devrait pas se produire)
plusieurs un document dont les parties ont plusieurs formats un document pour lequel on déclare plusieurs formats

Ceci implique que ces deux champs doivent être répétables.

Identifiant

[Comité des métadonnées] L'identifiant devrait être répétable dans le profil de métadonnées pour satisfaire certains types de documents comme les rapports annuels qui peuvent avoir à la fois un ISBN et un ISSN. De plus, certains documents n'ont pas de tels numéros. L'identifiant devrait donc être facultatif.

Il faut savoir que la fiche d'enregistrement institutionnel d'un document - qui incorpore le profil de métadonnées des documents de référence - a son propre identifiant (enr:identifiant) obligatoire et non répétable. Cet identifiant sera généré automatiquement par le service d'enregistrement institutionnel lors de la récrption d'une fiche soumise par le service de complétion.

Langue

[IROSOFT] Ajouts à la liste. Voir le message ci-après:

To: Rene Cléroult <rene.cleroult@...>,
        Denis Lévesque <levesque@...>,
        "Daniel Shane" <shane@...>
Cc: grds@..., Richard Parent <richard.parent@...>,
        Nicole.Lemay@...
Subject: [grds] [MRCI-1] Schème d'encodage pour les codes  
 de langue

Bonjour,

La réflexion qui suit fait suite à la demande de la part de René et Nicole 
pour l'ajout de nouveaux codes de langues dans le formulaire du cas MRCI-1. 
On a en effet remarqué que la liste dans le formulaire actuel est constituée 
de deux chois: français et anglais. On a mentionné qu'il se peut qu'il y ait 
besoin d'autres langues, dont fort probablement l'espagnol. On a donc proposé 
d'ajouter la mention "autre" dans la liste de façon à couvrir tous les cas 
que l'on risque de rencontrer dans le cas d'application.

Je crois comprendre que Denis (d'IROSOFT) a soulevé le fait, avec raison, que 
l'ajout de la mention "autre" nécessite des changements au schéma XML. En effet, 
le schème d'encodage employé avec la métadonnée "langue", soit "ISO639-2-code" 
se base sur la norme ISO 639-2 (on l'a deviné), laquelle définit une liste de 
codes alpha-3 pour les langues, et ne comprend donc pas de code pour désigner 
"autre". Donc, ajouter la mention "autre" reviendrait à produire un nouveau 
schème d'encodage, vrai?

Après vérification, j'apprend (eh oui) que la norme ISO 639-2 possède le 
code "und" (Undetermined) [1] pour les cas où la langue est indéfinie. Il existe 
aussi un intervalle qaa à qtz réservé pour usage local [2]. Je n'ai pas trouvé 
de code réservé pour le concept "autre". On pourrait donc se servir du 
code "qaa" pour "autre".

Je suggère donc de conserver le schème d'encodage actuel dans le formulaire du 
cas MRCI-1 et d'ajouter à la liste de l'interface les items suivants:

<xforms:item>
   <xforms:label>Espagnol</xforms:label>
   <xforms:value>spa</xforms:value>
</xforms:item>
<xforms:item>
   <xforms:label>Autre</xforms:label>
   <xforms:value>qaa</xforms:value>
</xforms:item>

Vos commentaires?

[1] http://www.loc.gov/standards/iso639-2/faq.html#25
[2] http://www.loc.gov/standards/iso639-2/faq.html#26

--------------------------------------------------------------------------------
Christian Rémillard

Limite d'accès

[Comité des métadonnées/GRDS] Le champ meta:limite-accès est répétable dans le profil de métadonnées, alors qu'il est unique à la BNQ. Que faire?

Localisation

[Comité des métadonnées] Le cas d'application ne comporte en principe que des publications en ligne. On peut donc limiter les schèmes d'encodage à un seul, soit: meta:URI.

[Comité des métadonnées] Changer l'aide en ligne.

Coût

[Comité des métadonnées] Ajouter l'enrichissement coût à meta:droits-utilisation

[Comité des métadonnées] Ajouter l'enrichissement coût-unitaire à meta:coût

[Comité des métadonnées] Ajouter l'enrichissement coût-abonnement à meta:coût

[GRDS] L'enrichissement meta:coût a été intégré dans la version 0.2.2 du schéma pour les enrichissements. Ajouter les deux derniers enrichissements dans la prochaine version (0.2.4).

Processus/activité

[GRDS] Cette métadonnée devient répétable 1-2.

Type de document

[GRDS] Cette métadonnée devient répétable 1-3.

Relation

[Comité des métadonnées/GRDS] Ajouter au profil de métadonnées et au schéma XML l'enrichissement est-un-numéro-de.

Fiche d'enregistrement institutionnel d'un document

[GRDS] Ajouter au schéma XML de la fiche les métadonnées d'administration de la saisie. L'hypothèse actuelle est de n'ajouter que l'identifiant (adresse de courriel dans notre prototype) de la personne qui a fait la saisie et la date de soumission.

[GRDS] Dans les métadonnées associées à un numéro de périodique, changer meta:porte-numéro-séquentiel par meta:est-un-numéro-de.

[GRDS] Dans les métadonnées associées à un périodique, ajouter meta:porte-numéro-séquentiel. Cette métadonnée servira à indiquer, lors de l'enregistrement institutionnel d'un périodique, les numéros déjà parus qui lui sont associés.

Transmission des données pour dépôt légal à la BNQ

Numéro(s)/parution(s) déposé(es)

[BNQ/GRDS] Le champ no. 4 du formulaire de la BNQ pour le dépôt d'un périodique, soit le champ Numéro(s)/parution(s) déposé(es) est obligatoire. Pourquoi?

Mot de passe

On présume que la transmission pour dépôt à la BNQ fait l'objet d'une entente entre la BNQ et le M/O. Cette entente contiendrait les modalités d'accès aux publications, y compris les habilitations d'accès. Le mot de passe n'est donc pas envoyé avec le formulaire de demande de dépôt légal.

Longueur des champs

Certains champs du formulaire d'enregistrement institutionnels sont répétables, alors que leur équivalents du formulaire de la BNQ ne le sont pas, ou encore le sont mais permettent moins d'occurences du champ. C'est le cas nottament pour les champs auteur et localisation. Il a été convenu que dans ces cas, le contenu des occurences exédentaires allaient être concatené dans la dernière occurence du champ du formulaire de la BNQ, chaque occurence étant séparée de l'autre par un point-virgule.

Une conséquence de ceci est que le contenu de certains champs transmis à la BNQ risquent d'excéder la longueur maximale des champs des formulaires de la BNQ. Voici à ce sujet un extrait d'une message transmis par Martin Voghel, Technicien en informatique de la BNQ, à Denis Lévesque d'IROSOFT (2003-11-24):

La validation sur la taille des champs dans les formulaires se fait 
grace à l'attribut "maxlength" dans les champs de type text (en HTML). Pour 
les champs de type textarea elle se fait dans le script de programmation.
 
Tout les champs sont de type "chaine de caractères" sauf pour les champs 
contenent les dates qui eux sont de type date (AAAA-MM-JJ).
 
Voici une description de la limite de taille des champs:
 
Éditeur = 80
Courriel = 80
Titre = 160
Autre version = 80
 
Accès à la publication sur Internet
    Usager/mot de passe = 50
    Acces payant = 10
 
Mise en ligne sur Internet
    fréquence de mise à jour - autre = 50
 
URL = 250
Auteur = 200
notes et commentaires = 400
 
Numéro de parution = 80

[BNQ/IROSOFT] On se demande alors si l'excédent en longueur de ces champs risque de poser des problèmes lors de la transmission des données du formulaire à la BNQ ou même lors de l'entrée des données dans le système de la BNQ. La réponse à cette question doit provenir des gens de la BNQ (elle est posée par Denis). Dans ce cas, IROSOFT s'assurera que les données transmises soient tronquées selon les longueurs mentionnées ci-haut.

Cette expérience apporte un éclairage sur l'architecture d'un service d'enregistrement institutionnel. On peut aisément imaginer que le contenu du service puisse servir à plusieurs fins, dont celui du dépôt légal. Les clients ainsi intéressés par les données du service devraient définir eux-même un filtre d'exportation pour harmoniser les données du service d'enregistrement institutionnel à leurs systèmes et non l'inverse.


© 2003, GRDS - Groupe de recherche départemental sur les documents structurés.