|
|
|
Réunion sur le Profil Bath
24 et 25 septembre 2000
St. John's, Terre-Neuve
Procès-verbal de la réunion des 24 et 25 septembre
Présidente : Carrol Lunau, Bibliothèque et Archives Canada
Rapporteurs : Paul Miller et William E. Moen
Présents : Voir la liste ci-jointe.
Première journée :
Carrol Lunau souhaite la bienvenue à tous les participants à la réunion. Elle propose une marche à suivre pour la révision des points de discussion et l'établissement des questions prioritaires dans l'ordre du jour distribué au préalable. On expose les différents points de discussion et on demande aux participants de noter les questions et les préoccupations qu'ils souhaitent aborder. Les éléments suivants ont été retenus comme points de discussions pour la réunion de deux jours :
- Discussions de dimanche :
- Syntaxes de notice dans le domaine de fonctionnalité A (XML, SUTRS)
- Domaine de fonctionnalité A SCAN - redondance des termes
- Domaine de fonctionnalité C
- XML DTD
- Demande d'une notice DC XML
- Domaine de fonctionnalité A - incluant les recherches additionnelles
- Attributs de position et de complétude et champs et sous-champs
- Attribut de structure pour la recherche par date
- Voir le niveau 3 du Profil Texas
- Support
- Date de publication
- Examen approfondi dimanche soir et discussions du lundi :
- Domaine de fonctionnalité B - Resources documentaires de niveau 1, exigences additionnelles
- Normalisation
- Étendue du problème de normalisation
- Normalisation des termes de recherche
- Recherche par auteur normalisée
- Ensembles de caractères
- Ensembles de caractères et SUTRS
- UNIMARC
- Discussion de lundi :
- Étendue du Profil
- Pour examen : PEB, NCIP, recherche d'autres Resources (p. ex., Resources Web, bases de données Aet I), etc.
- Référence numérique coopérative
- Pierres d'achoppement pour l'adoption
- Évolution, changements, stabilité du Profil
- Services d'annuaire/explication du système Lite
- Guide des pratiques exemplaires - de quoi a-t-on besoin ?
- Recommandations en matière d'indexage
- Questions opérationnelles, temporisation, etc.
- Directives de formatage SUTRS
Cette réunion fait suite à la conférence ACCESS Y2K et de nombreux participants à cette conférence assisten à la réunion sur le Profil Bath. Puisque les participants n'ont pas tous le même niveau de connaissance du Profil, Bill Moen récapitule l'évolution du Profil Bath et explique qu'il est le fruit de diverses tentatives passées et présentes visant à établir un profil. Il parle également de la relation entre les divers profils comme Bath et Z Texas ainsi que des premiers pas du projet de profil NISO.
Les sections qui suivent résument les résultats des discussions et les ententes intervenues sur les points à l'ordre du jour.
Domaine de fonctionnalité A : Syntaxes de notices (XML, SUTRS)
La discussion porte sur les syntaxes des notices et les analyses de cas / applications permettant de déterminer les syntaxes à utiliser. On convient que XML n'est pas nécessairement du niveau 0.
Au cours de la discussion, on propose de restreindre la portée de l'énoncé de profil, surtout dans ce domaine de fonctionnalité. Ce domaine de fonctionnalité est-il destiné aux catalogues collectifs virtuels ? À des Resources autres que les catalogues des bibliothèques ? Le domaine de fonctionnalité A est défini pour la recherche documentaire bibliographique de base, axée principalement sur les catalogues des bibliothèques. Cela implique que les recherches définies pour ce domaine peuvent servir à d'autres " Resources électroniques ".
Il faut vérifier l'origine de l'énoncé " et autres Resources électroniques " pour le domaine de fonctionnalité A et peut-être resserrer le langage et la portée en éliminant cette partie.
Entente : Les critères de la section 5.A.0, Domaine de fonctionnalité A : Recherche documentaire bibliographique de base de niveau 0, seront modifiés comme suit :
- Niveau 0: Les serveurs doivent prendre en charge (UNIMARC ou MARC21) et SUTRS.Les clients doivent prendre en charge (UNIMARC ou MARC21) et SUTRS.
- Niveau 1: Les critères demeurent les mêmes pour les syntaxes des notices.
Utilisations: Le concept de CCV n'est pas clairement défini en termes de service et de politiques. Les spécifications du Profil Bath sont conçues pour accommoder une variété de CCV.
- Les implantations de niveau 0 accueilleront différentes forrmes de catalogues collectifs virtuels (CCV). Le degré de résistance des CCV sera déterminée par la syntaxe que le catalogue pourra accepter. Par exemple, si un CCV comprend un serveur n'acceptant qu'UNIMARC et un serveur n'acceptant que MARC21, le client peut n'obtenir que des notices SUTRS comme syntaxe commune. Dans ce cas, les services de CCV résistants, comme la déduplication et le rapport des fonds asociés, sont impossibles. Cependant, il est plus probable qu'un CCV repose sur une certaine homogénéité d'implantations fondée sur des domaines géographiques, politiques ou sur d'autres domaines organisationnels. Dans ces cas, tous les serveurs accepteront une syntaxe MARC commune permettant les services de déduplication et le rapport d'information sur les fonds connexes.
- En matière de CCV, le modèle veut qu'il existe une forme d'entente organisationnelle entre les bibliothèques dans le but de former un CCV (par exemple, pour une province, un consortium, un système de bibliothèques). Un utilisateur ne peut espérer former à la volée un CCV résistant en procédant à une recherche générale dans un assortiment aléatoire de serveurs Z39.50 compatibles avec le Profil Bath.
- Les spécifications de niveau 0 permettront à un client compatible au Profil Bath d'interagir avec des serveurs acceptant la syntaxe de notice MARC qu'il utilise et d'échanger des données avec un serveur qui ne le fait pas. Dans ce dernier cas, SUTRS offre un moyen de présenter les données du client de façon à permettre à l'utilisateur d'au moins voir la notice.
- Le niveau 0 est destiné avant tout aux recherches orientées rappel effectuées dans un ensemble de catalogues de bibliothèque utilisant un noyau de recherches élémentaires utiles aux utilisateurs finaux en général, aux bibliothécaires de référence et aux bibliothécaires des services techniques.
Domaine de fonctionnalité A SCAN : Redondance de Term et de DisplayTerm
On suggère de modifier la formulation du Profil (section 5.A.1SCAN. Domaine de fonctionnalité A : Utilisation de SCAN Niveau 1) au sujet des responsabilités des clients et des serveurs quant à envoi / affichage du terme.
Entente : Le libellé sera changé comme suit :
- Texte de départ :
Les clients Z doivent pouvoir accueillir Term et DisplayTerm et les serveurs Z doivent toujours envoyer Term et DisplayTerm (qui peuvent présenter la même valeur), et le client Z doit toujours afficher DisplayTerm.
- Nouveau texte :
Les clients Z doivent pouvoir accueillir Term et DisplayTerm et afficher DisplayTerm s'il est envoyé.
Domaine de fonctionnalité C : Questions de syntaxe des notices et XML DTD
Paul Miller résume quelques-uns des problèmes de XML DTD pour Dublin Core en indiquant qu'il ne fournit pas de mécanisme d'extensibilité permettant aux serveurs d'ajouter localement des éléments définis et de leur envoyer une notice. Le manque d'extensibilité dans DTD ne peut être comblé par le Profil.
Entente : Les exigences en matière de syntaxe des notices de niveau 0 passeront de :
- Les clients Z doivent pouvoir accueillir SUTRSet XML
- Les serveurs Z doivent pouvoir accueillir SUTRSou XML
à
- Les clients Z doivent pouvoir accueillir SUTRS
- Les serveurs Z doivent pouvoir accueillir SUTRS
L'exigence en matière de syntaxes des notices de niveau 1 demeure inchangée lorsqu'on utilise le schéma Dublin Core et le DTD acutel . Toutefois, il n'y aura pas d'extensibilité et les serveurs ne pourront retourner les éléments en plus de ceux désignés dans le DTD. La syntaxe des notices est XML.
On préciser le niveau 2 dans le domaine de fonctionnalité C pour accroître la soupesse d'extraction en établissant un mécanisme de schéma RDF favorisant l'extensibilité. La syntaxe des notices sera XML. On précisera un schéma pour DC dans RDF. (Paul Miller fournira le jargon technique additionnel pour cette spécification et tentera de séparer les trois utilisations du schéma (Z39.50, XML et RDF)).
On déposera à l'Organisme responsable de la norme Z39.50 une demande d'OID appropriés pour le DC DTD et le schéma RDF.
- Domaine de fonctionnalité A : Recherches et exécution de recherches
Ce point soulève bien des questions.
- Attributs de position et de complétude et champs / sous-champs. La sémantique de ces types d'attributs, surtout l'attribut de complétude, n'est pas claire.
- Entente: Clarifier la sémantique de " sous-champ incomplet " pour qu'elle signifie " point d'accès incomplet " dans le texte du Profil. Cela est nécessaire pour éliminer la confusion dans la sémantique de ces valeurs pour l'attribut de complétude Bib-1.
- Devrait-on permettre aux clients de ne pas envoyer tous les types d'attributs et les valeurs définis pour les recherches ?
- Entente: Aucun changement. Les clients qui se conforment au Profil doivent envoyer tous les types d'attributs et les valeurs prescrits pour une recherche. Cependant, le libellé du Profil doit être inclus afin de guider les serveurs. Puisqu'ils vont recevoir des demandes de clients non conformes au Profil Bath, les serveurs conformes au Profil ne devraient pas rater une recherche simplement parce que la demande ne comprend pas tous les types d'attributs.
- Recherches additionnelles. On discute de nouvelles recherches et on convient de les ajouter au domaine de fonctionnalité A, niveau 2.
- Entente: On recommande d'inclure quatre nouveaux types de recherche au niveau 2 :
- Recherches par titres de publications en série / périodiques
- Quatre recherches de titres basées sur les modèles utilisés pour les recherches de niveaux 0 et 1 seront précisées.
- La valeur d'attribut d'utilisation sera 33, Touche de titre
- Recherche par support / type de document
- Ne peut s'utiliser que comme délimiteur de recherche.
- Inclusion de deux recherches par support / type de document, par phrase et mot-clé.
- Utilisation = 1031 (type de document)
- Relation = 3 (égal)
- Position = 1 (premier dans le champ)
- Structure = 1 (phrase) et 2 (mot)
- Troncature = 100 (ne pas tronquer)
- Complétude = 1 (sous-champ incomplète)
- Recherche par langue
- Conçue pour la recherche par langue du document bibliographique et non la langue de la notice.
- Ne peut s'utiliser que comme délimiteur de recherche
- Utilisation = 54 (code-langue)
- Relation = 3 (égal)
- Position = 3 (toute position dans le champ)
- Structure = 1 (mot)
- Troncature = 100 (ne pas tronquer)
- Complétude = 1 (sous-champ incomplet)
- Recherche par période
- Ne peut s'utiliser que comme délimiteur de recherche
- Basée sur l'Ententde des réalisateurs Z39.50 no1 pour la recherche par plages linéaires (voir http://lcweb.loc.gov/z3950/agency/agree/range.html )
- Utilise l'attribut de relation 104, au sein de
- Attribut d'utilisation = 31 (date de publication)
- Relation = 104 (contenu dans)
- Position = 1 (premier dans le champ) ??
- Structure = 4 (date)
- Troncature = 100 (ne pas tronquer)
- Complétude = 1 (sous-champ incomplet)
Jour 2 :
Le premier point du jour 2 est une révision des ententes conclues le lundi. On distribue des exemplaires des ententes pour examen.
Certains participants s'inquiètent de la décision concernant la syntaxe de notice du domaine de fonctionnalité A, niveau 0. Après discussion, on suggère de rendre XML facultatif au niveau 0. Pour l'échange de notices MARC en XML, on propose d'utiliser les archives ouvertes XML DTD pour les notices MARC (voir http://www.dlib.vt.edu/projects/OpenArchives/oa_marc.html ).
Voici les points à l'ordre du jour et les ententes découlant des discussions de lundi.
- Normalisation
Les routines de normalisation pour les données et les demandes comptent parmi les domaines du système documentaire et de la norme Z39.50 qui influencent le résultat des recherches. On soulève une première fois cette question en abordant la recherche par nom normalisée.
Avant d'aborder les recommandations d'indexation pour les notices MARC en vue d'accueillir les profils Bath et Z Texas, il semble approprié de discuter aussi des règles et des pratiques de normalisation. La question est que, dans l'environnement des catalogues des bibliothèques, nous allons travailler avec une base installée et rechercher une interopérabilité avec des systèmes existants, qui ne changeront vraisemblablement pas de pratiques d'indexation et de normalisation. Tout importante qu'elle soit, la normalisation est peut-être une question insoluble.
Entente: On convient que le Profil ne prescrira pas de règles d'indexation mais proposera un ensemble de pratiques exemplaires ou de recommandations en matière d'indexation, semblables à celles qui ont été élaborées par le Groupe de réalisateurs Texas Z39.50 (TZIG) ( http://www.unt.edu/wmoen/Z3950/MARC21Indexing/Z3950MARCIndexing.htm ). Cette question doit demeurer sur la liste des questions à régler.
- Ensembles de caractères
Il apparaît clairement, dans la discussion sur les ensembles de caractères, que cette question fera l'objet de discussions soutenues. Il sera important d'insister sur l'impact des ensembles de caractères sur l'interopérabilité. Toutefois, pour l'instant, voici les ententes et les conclusions issues des discussions.
Entente : Retirer le paragraphe de la section 4.3.3. Repérage : Syntaxes des notices, " L'interopérabilité nécessite l'utilisation d'ensembles de caractères standard ".
- Niveau 0 : Pour les notices SUTRS, Latin 1 pour le repérage. 8859-1.
- Niveau 1 : Inchangé.
- UNIMARC
Le Profil nécessite UNIMARC pour la syntaxe des notices dans le domaine de fonctionnalité A et il sera important de continuer de traiter UNIMARC et MARC 21 sur un pied d'égalité. Il importe aussi que les réalisateurs et les organismes qui désirent intégrer UNIMARC au Profil prennent part aux discussions portant sur UNIMARC.
- Portée du Profil
Le point de discussion aborde les ajouts éventuels au Profil par l'examen de ce qu'est ou devrait être la portée du Profil. Par exemple, le Profil ONE-2 comprendra le PEB, la mise à jour, la circulation et la livraison de documents. D'autres domaines possibles d'élaboration du profil seraient la recherche documentaire dans les Resources bibliothéconomiques extérieures aux catalogues, comme des bases de données A et I, etc. Le Profil Bath pourrait englober les étapes suivantes après la découverte des notices bibliographiques - fonds, PEB, livraison de documents. Le groupe est d'avis que nous devrions regrouper les domaines précisés dans la version actuelle du Profil et ne pas intégrer de nouveaux domaines de fonctionnalité.
- Fonds
Rolande St-Gelais et Poul Henrik Jorgensen ont préparé une présentation pour exposer les questions relative aux fonds ainsi que quelques recommandations. Leur exposé établit clairement que différents scénarios d'utilisation peuvent s'appliquer aux fonds.
On discute des modèles de base qui sous-tendent nos idées sur l'information des fonds et son extraction. Modèle 1 : base de données unifiée regroupant les données bibliographiques et les fonds. Modèles 2 : bases de données distinctes pour les données bibliographiques et les fonds, nécessitant une recherche dans la base de données des fonds.
Ralph LeVan expose la vision des modèles et étend leur perspective :
- Fonds intégrés dans les notices bibliographiques - permet de demander des renseignements sur les fonds
- Demander un livre et son emplacement
- Information non indexée sur les fonds et information bibliographique séparées mais se trouvant dans une base de données logique unifiée.
- Faire une demande puis présenter l'information bibliographique et l'information sur les fonds.
- Fonds bibliographiques et fonds source
- Utiliser un numéro de contrôle local
- Information bibliographique et information sur les fonds explicitement séparées.
- On devra utiliser la clé magique.
- Le client doit être en mesure de tirer une clé magique pour contourner une clé spéciale.
- Utiliser une table de configuration pour l'information hôte sur la bibliographie et les fonds
- Définir la hiérarchie des clés pour contourner la recherche de fonds.
- Procéder à une recherche d'identificateur standard avec valeurs pour divers paramètres / numéros de contrôle / isbn / issn
- Existe-t-il un numéro standard par excellence… peut-être pas….utiliser un numéro local, un isbn / issn, un numéro de contrôle LC, etc.
Afin de réaliser des progrès au cours de cette réunion, le groupe examine les exigences minimales suivantes en rapport avec l'information des fonds.
-
- " J'ai repéré, dans une bibliothèque connue, une notice d'un document qui m'intéresse et j'aimerais maintenant consulter l'information de fonds sur ce document. "
Le groupe conclut les ententes suivantes sur les niveaux de rapport et sur la syntaxe des notices pour l'échange d'information sur les fonds.
Entente : Pour ce cas, il est nécessaire d'avoir les niveaux de rapport suivants pour le schéma de fonds aux niveaux de conformité du domaine de fonctionnalité B :
-
- Niveau 1 -- B1 et B2
- Niveau 2 - C1 et C2
- Niveau 3 - B3, B4 et C3, C4
Entente : Il peut y avoir des cas où XML sera moins puissant que GRS-1, mais efficace pour les besoins du fonds. L'information sur les fonds sera échangée dans XML au moyen d'un schéma XML basé sur le schéma du fonds courant présenté pour GRS-1. Toutes les exigences de GRS-1 dans le domaine de fonctionnalité B seront abandonnées.
Entente : Supposons un modèle no 4 ci-dessus, où une clé associée intervient entre la notice de la base de données bibliographiques et la notice / information du fonds pour le document représenté par la notice. Le client utilisera l'un des identificateurs standard de la notice bibliographique pour interroger la base de données du fonds et extraire l'information du fonds.
- Évolution, changements, stabilité du Profil
La Bibliothèque et Archives Canada est l'organisme responsable du Profil Bath. Cet organisme doit élaborer des politiques et des procédures sur la façon de modifier le Profil (par exemple, à la suite d'une réunion, d'une discussion sur le serveur de liste, etc.) et les cas où les modifications au Profil sont suffisamment importants pour qu'on le resoumette en entier au processus IRP.
Il est important que le Profil projette une image de stabilité et qu'on n'apporte que des modifications minimes (s'il y a lieu) aux spécifications déjà approuvées. Les parties intéressées au Profil Bath doivent participer en temps opportun et formuler des observations sur les spécifications proposées afin de permettre au plus grand nombre d'examiner le Profil et de faire des commentaires avant son adoption. Cependant, on a laissé entendre que l'organisme responsable se réservait un pouvoir de nature dictatoriale dans ce processus de décision.
Entente : La liste de discussion du Profil Bath constitue le lieu officiel d'approbation. Les propositions officielles découleront de cette réunion et seront communiquées aux membres de la liste en tant que modifications recommandées pour le Profil. Selon les réactions exrpimées, l'Organisme responsable pourra décider d'apporter certains changements, avec l'aide d'un groupe de conseillers (comme le premier Groupe d'élaboration du Profil Bath).
Nous devons établir des processus pour protéger la stabilité. Les travaux sur Dublin Core pourraient nous guider quant aux processus à adopter pour le Profil.
Recherche de noms normalisée Vers la fin la journée de lundi, le groupe a abordé la question de la recherche de noms normalisée. Cette recherche pose problème en raison des régles de normalisation en vigueur dans un système donné. LeVan recommande qu'on décrive comme suit le comportement qu'on tente de reproduire :
- recherche de phrase avec troncature (et avec l'exemple dans le Profil - la recherche par phrase comporte une troncature à gauche, ce qui ne peut être réalisé que difficilement et à grands frais)
- recherche par liste de mots avec opérateur de contiguïté implicite.
L'expérience d'implantation du Profil peut nous aider à comprendre la façon de mieux préciser cette recherche à l'avenir.
- Choses à faire
Bien que le groupe ait accepté de consolider le profil à ce stade et de ne pas y ajouter de nouveaux domaines de fonctionnalité, les participants conviennent de certains points qu'il faudra régler :
- Nécessité d'élaborer d'autres scénarios d'utilisation pour l'information des fonds et de rechercher l'information des fonds pour documenter les spécifications du domaine de fonctionnalité B.
- Discussion du schéma XML DTD approprié pour MARC 21 dans le domaine de fonctionnalité A, niveau 1.
- Poursuite de la discussion sur l'indexage et la normalisation et soutien à l'élaboration de documents sur les pratiques exemplaires pour chacun des cas.
L'Organisme responsable du Profil Bath commencera à afficher sur son site Web l'information qu'il recueillera sur les réalisateurs du Profil (organismes utilisateurs et fournisseurs de systèmes de bibliothèques intégrés et autres réalisateurs Z39.50).
Le site Web contiendra également de l'information sur le Profil Bath et des documents soutenant les activités de sensiblisation au Profil.
- Prochaines réunions
On convient de tenir la prochaine réunion en même temps que la réunion ZIG prévue pour le printemps / été 2001, en Angleterre. Le groupe se réunira deux fois l'an et une réunion sera tenue parallèlement à une conférence bibliothéconomique majeure dans le but de favoriser une participation soutenue des bibliothécaires à ces réunions.
- Remerciements
Carrol remerce Slavko Manojlovich et le personnel de la Memorial University pour avoir organisé la réunion et fourni les rafraîchissements lors des pauses-café.
Personnes présentes à la réunion sur le Profil Bath (Retour au début)
|
