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.
[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.
[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.
[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
[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?
[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.
[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).
[GRDS] Cette métadonnée devient répétable 1-2.
[GRDS] Cette métadonnée devient répétable 1-3.
[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
.
[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.
[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?
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.
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.