Cher Michel Bottin,
Après votre message du 24 juin, je crois que les choses sont plus claires :
- le groupe Bib-X de l'ADNX a pour but d'élaborer un logiciel,
- la discussion que je propose a pour but de dialoguer avec les fournisseurs de données et les fournisseurs de logiciels de gestion de bibliothèques, pour définir les éléments techniques nécessaires pour que les données transférées puissent être facilement importées et traitées par les différents logiciels de gestion de bibliothèque -cela en garantissant aux bibliothèques utilisatrices qu'il n'y aura au passage aucune perte de fonctionnalités.
Ce sont donc deux initiatives différentes ayant des buts différents.
Mon raisonnement est le suivant : BiblioML ne se diffusera dans les logiciels de gestion de bibliothèques que si des fournisseurs de données bibliographiques importants pour la gestion quotidienne des bibliothèques l'utilisent pour leurs exportations de données, avec des fonctionnalités supplémentaires par rapport à ce que permet aujourd'hui l'ISO 2709.
En clair, si Electre propose demain des notices en BiblioML avec en plus des tables des matières en XML, ou des reproductions des couvertures, les bibliothèques pousseront leurs fournisseurs à adopter le standard. De même si la BNF fournit le même type de données, ou si le protocole adopté permet de récupérer une notice-mère et les notices analytiques associées plus facilement qu'on ne le fait aujourd'hui. De même si un fournisseur de documents sonores l'utilise pour fournir des notices bibliographiques, avec reproduction de la jaquette du disque et fourniture d'un court extrait musical...
Si :
- des fournisseurs de données utilisent BiblioML et un niveau "protocole d'échange"
- d'une manière facile à utiliser et fonctionnelle pour les logiciels importateurs
- sans perte de fonctionnalité pour les bibliothèques importatrices
- et en permettant des services supplémentaires (tables des matières, reproductions de couvertures, d'extraits musicaux, transfert plus facile des sous-notices ou des notices d'autorité du document)
alors il est sûr que BiblioML se répandra.
Sinon, au mieux, rien n'est sûr.
Dans cette affaire, BiblioML ne m'intéresse que, parce qu'élaborée à partir d'Unimarc, cette DTD me garantit que les bibliothèques utilisant Unimarc garderont en l'utilisant toutes les fonctionnalités de recherche documentaire qu'elles ont actuellement.
Je n'exclus pas du tout que la discussion française que je propose aboutisse à la conclusion que tel ou tel protocole existant, OAI-PMH ou autre, remplit toutes les conditions techniques souhaitées et que c'est lui qu'il faut recommander. Mais il faudrait me semble-t-il le vérifier, en faisant le tour des questions liées aux transferts entre fournisseurs de données et bibliothèques.
Et s'il faut compléter un protocole existant, eh bien, il faudra le faire -et pourquoi pas faire intégrer les améliorations souhaitées dans une version future du standard choisi.
Nous aurons, j'espère, l'occasion de rediscuter de ces questions dans le groupe de suivi de BiblioML ou dans le Comité Français Unimarc.
Bien cordialement,
Jean-Paul Gaschignard
-----Michel Bottin <address@hidden> a écrit : -----
Pour : Jean Paul Gaschignard <address@hidden>
De : Michel Bottin <address@hidden>
Date : 24/06/2005 10:48AM
Objet : Re: CFU - BiblioML et couche "protocole d'échange"
Bonjour,
Jean Paul Gaschignard wrote: Cher Michel Bottin,
Je ne comprends pas pourquoi vous supposez que je voudrais à toute force créer un protocole propriétaire. Vous supposez que je ne suis pas conscient de la nécessité de protocoles ouverts, permettant l'échange entre systèmes différents, et de plus en plus communs à des mondes professionnels qui jusqu'ici s'ignoraient : vraiment, je ne vois pas pourquoi vous me prêtez cette inculture ou cette absence de réflexion personnelle. Il y a là un mystère pour moi.
Je ne pense pas que vous voudriez à toute force créer un protocole propriétaire. Tout au plus c'est une crainte dont l'origine est certainement une mauvaise perception de ma part de votre stratégie. Loin de moi de vous prêter cette forme d'inculture ou de non réflexion.
Ceci dit, votre réponse à ma réponse laisse, pour moi, beaucoup de questions sans réponse et ne change rien à ma conviction : si l'on ne prend pas la peine de vérifier en détail, en concertation avec les fournisseurs de logiciel et les fournisseurs de données bibliographiques (ce qui n'est pas un synonyme de "dire oui à tout ce qu'ils diront), ce niveau "protocole d'échange" et "définition des données techniques nécessaires à l'échange", les standards élaborés, aussi beaux soient-ils, ne seront pas utilisés et donc ne serviront à rien.
Les cimetières de normes sont pleins de standards élaborés en petit comité, qui ont soit posé des problèmes techniques, grands ou petits, soit n'ont simplement pas été popularisés, et n'ont en fin de compte pas été utilisés.
A quoi ont servi ces normes inutilisées ? A rien.
Mais là aussi c'est un peu général. L'ISO est pleine de standards non implémentés. En revanche Internet lui-même a montré qu'il était possible de diffuser des protocoles ouverts (et à une échelle réellement mondiale) sans qu'aucune autorité établie n'intervienne si ce n'est a posteriori.
Que risque t'on en ne dialoguant pas avec les fournisseurs de logiciels ? Qu'ils fabriquent des standards propriétaires dans leur coin et que ces standards, eux, s'imposent dans la pratique. Vous comprenez, je suppose, que les enjeux sont lourds. Et, certainement, ceux qui seraient responsables d'un tel manque à gagner porteraient une lourde responsabilité...
Mais trêve de généralités. Et voici pour informations quelques documents relatifs au protocole d'échange OAI:
1. La documentation associée à l'atelier ADNX sur l'OAI qui s'est tenu le 2 juin dernier à l'ENSSIB: http://adnx.org/documentation/oai/
2. Un papier de François Nawrocki de la DLL : Le protocole OAI et ses usages en bibliothèque:
http://www.culture.gouv.fr/culture/dll/OAI-PMH.htm
3. L'adresse du serveur OAI de la BnF: http://bibnum.bnf.fr/oai/
et en particulier l'adresse permettant de récupérer le contenu de l'entrepôt OAI:
http://oai.bnf.fr/repositoryOAI.php?verb=ListRecords&metadataPrefix=oai_dc
Autres remarques sur votre réponse à ma réponse :
1) Nommer les notices d'autorité : oui, ce sont des notices d'autorité. Ma question est : comment les nommer de manière normalisée pour faciliter l'échange ?
Si un protocole existe déjà, pour cela, mais aussi les notices analytiques (au fait, faut-il, et où et comment, préciser leur niveau ?), les notices d'exemplaires, les tables des matières et autres données textuelles à joindre, les fichiers à joindre au fichier XML, quel est son nom ?
2) Vous n'êtes pas d'accord avec la notion de "besoin des fournisseurs" : cela me paraît un purisme sémantique un peu byzantin.
Admettons que seuls les utilisateurs aient des besoins. On conviendra que pour leur part les fournisseurs de données et de logiciels ont des contraintes techniques, et que ces contraintes peuvent nécessiter l'utilisation de données techniques : va-t-on, ou non, s'autoriser à nommer cette nécessité un besoin ? Je m'en moque un peu, pourvu qu'on reconnaisse la réalité et la légitimité de ces nécessités (ou besoins....) techniques -tout en les standardisant.
3) Vous écrivez "c'est un choix de l'application de décider si les données doivent être transmises dans un seul fichier ou dans un ensemble de fichiers" : et il est à mon avis évident que les différents fournisseurs de données (y compris les bibliothèques qui échangeront entre elles) auront parfois des choix différents.
Et cela ne change rien à ma conviction : il faut que le logiciel importateur dispose de toutes les indications et définitions nécessaires, et applicables de manière réaliste, c'est-à-dire sans coûts inutiles, pour traiter facilement les données qu'il importe.
Je demande qu'on vérifie, collectivement, que ces questions d'échange sont bien traitées, et définies avec tous les éléments nécessaires aux fournisseurs de logiciels. Et si, après avoir étudié sérieusement et collectivement la question, il s'avère que des données manquent dans les protocoles existants, il faudra impérativement les compléter -et faire partager ces remarques et compléments.
4) Vous écrivez dans votre première réponse que le projet Bib-X de l'ADNX veut "regarder du côté des notices en BiblioML et d'un protocole tel que OAI-PMH".
Quels sont les objectifs du projet Bib-X ? Qui y participe ?
Les objectifs sont d'élaborer un logiciel libre basé sur des technologies XML et utilisant BiblioML pour assurer la saisie, le stockage, l'indexation, la diffusion et la recherche dans une base de références bibliographiques accessible sur le Web. Elle sera en outre un entrepôt OAI et aussi un moissonneur.
Conçu primitivement dans le cadre du Ministère de la culture il est resté quelque eu en souffrance pour des raisons diverses trop longues à détailler ici mais que je cherche à réactiver au sein de l'ADNX tout en contribuant moi-même au développement.
Ceci dit je persiste à penser que l'on devrait poursuivre cette discussion sur la liste biblioml afin que d'autres puissent en profiter.
Bien cordialement,
Jean-Paul Gaschignard
vice-président de la FULBI (Fédération des utilisateurs de logiciels pour bibliothèques)
chargé de la récupération des données bibliographiques
----- Original Message -----
Sent: Tuesday, June 21, 2005 2:50 PM
Subject: Re: CFU - BiblioML et couche "protocole d'échange"
Bonjour,
Jean Paul Gaschignard wrote: Bonjour,
Je vous remercie de m'indiquer l'existence de protocoles d'échange XML déjà existants. N'étant pas un spécialiste de XML il y a beaucoup de choses que je ne connais pas.
Ceci dit, il me semble nécessaire de standardiser un ensemble de définitions et de noms (balises) donnés à ces définitions : qu'appelle-t-on une notice d'autorité,
C'est une notice qui contient des données d'autorités. Nous avons élaboré à cette fin une autre DTD AuthorityML pour accueillir en XML les données des notices autorités Unimarc.
où et comment la place-t-on dans le fichier XML si on transfère à la fois une notice biblio et les notices d'autorité qui lui sont liées ?
C'est un choix de l'application de décider si les données liées doivent être transmises dans un seul fichier où comme un ensemble de fichiers. Mais de toutes façons il existe un mécanisme général en XML pour inclure dans un seul fichier des données relevant de plusieurs schémas : ce sont les "espaces de noms".
(je ne prends qu'un exemple, et il y en a d'autres).
Une deuxième question, qu'il faut à mon avis étudier avec les fournisseurs de logiciels, est la fonctionnalité des protocoles que vous citez : y trouvent-ils tous les éléments dont ils ont besoin pour traiter facilement, à l'arrivée, les fichiers transférés ?
Les discussions que j'ai eu ce week-end avec les ingénieurs de plusieurs d'entre eux, lors du congrès de l'ABF, me font penser que ces questions ne sont pas encore réglées -ça ne leur paraît pas si évident qu'à vous.
(la théorie "il n'y a qu'à définir un protocole sans les fournisseurs, ils n'auront qu'à s'adapter", sans tenir compte de leurs besoins, est évidemment archi-fausse et très contre-productive)
Je ne suis pas tout à fait d'accord avec la notion de "besoins des fournisseurs" : ce sont les utilisateurs qui ont des besoins
Il se peut très bien que les questions soient déjà résolues et que les protocoles que vous citez répondent à toutes les questions. Auquel cas, il ne suffit que de s'entendre sur ce point et de les faire connaître. Mais cette étape-là ne se fera pas non plus toute seule : la réunion que je propose pourrait très bien y contribuer efficacement.
Le ton très catégorique "le problème est déjà réglé, il n'y a évidemment rien de plus à faire" de votre réponse me gêne.
Seule la brièveté de mes formulations a pu vous donner cette impression. Je n'ai cherché qu'à distinguer des plans : structure des données, protocoles d'échange, fonctionnalités de l'application spécifique. Je crois qu'il serait gravement dommageable de revenir aux pratiques antérieures de procédures ou protocoles métiers et s'isoler ainsi de travaux répandus d'autant plus que ce sont généralement des standards entièrement ouverts.
Je vous prie de bien vouloir excuser les questions d'un bibliothécaire qui n'est qu'un informaticien
J'avais bien lu selon le sens et non pas selon la syntaxe.
et qui n'a qu'une chose à apporter : ses analyses des fonctionnalités nécessaires aux bibliothèques, et sa connaissance pratique, via les clubs d' utilisateurs de logiciels et les remarques des bibliothécaires chefs de projet informatique, de la réalité des relations entre bibliothèques, fournisseurs de logiciels et fournisseurs de données, et de la façon dont elles fonctionnent sur le terrain.
C'est bien pour cela que votre tâche est primordiale : seuls des bibliothécaires peuvent définir les fonctionnalités nécessaires aux bibliothèques et pas les fournisseurs de logiciels (et c'est un informaticien qui parle !). Ceux-ci ne peuvent intervenir que pour définir comment les implémenter mais les utilisateurs ont la rude tâche de savoir distinguer si ce sont des solutions propriétaires ou des solutions ouvertes. Le développement et l'avenir ne sont pas de même nature sans compter les coûts ni les questions de responsabilité.
J'espère que vous prendrez la peine de répondre sérieusement à ce message, pour que nous entamions un vrai dialogue. Il est nécessaire de partager les connaissances, et aussi de prendre le temps d'éliminer les malentendus, et aussi d'étudier rigoureusement les problèmes posés, si on veut faire avancer les choses.
C'est exactement le but de la liste de discussion biblioml sur laquelle je me suis permis de mettre cette réponse en copie pensant que notre discussion est d'un intérêt toit à fait général.
Bien cordialement
Jean-Paul Gaschignard
----- Original Message -----
Sent: Tuesday, June 21, 2005 1:03 AM
Subject: Re: CFU - BiblioML et couche "protocole d'échange"
Bonjour,
Jean Paul Gaschignard wrote: Bonjour à tous,
Lors de la réunion du CFU le 26 mai, je ne me suis pas inscrit pour le
groupe de suivi de BiblioML. Finalement, je souhaite en faire partie.
En attendant vous pouvez vous inscrire sur la liste de discussion BiblioML en:
https://savannah.nongnu.org/mail/?group=biblioml
Voici
pourquoi :
Je suis convaincu que les DTD XML ne se répandront comme format d'échange
entre les bibliothèques que lorsque des fournisseurs de données proposeront
des données dans ces DTD.
C'est évident.
Et il faudra alors une "couche" qui actuellement
ne figure pas dans BiblioML, la couche protocole d'échange.
Je crois qu'il y a là une certaine confusion entre les données à échanger - et avec BiblioML il s'agit de références bibliographiques de (non-)livres - et les protocoles d'échanges. Il existe d'ores et déjà de tels protocoles permettant de diffuser et/ou de moissonner des données en XML. Je pense en particulier au protocole OAI-PMH qui s'il impose toujours au minimum l'échange de données XML conformes au Dublin Core non qualifié permet aussi d'utiliser n'importe quel format XML (n'importe quelle DTD ou n'importe quel schéma)
Cette couche protocole devrait contenir tous les éléments dont les
fournisseurs de logiciels ont besoin pour intégrer les fichiers :
- quelle DTD utilisée, quelle version
- si le fichier contient des ensembles imbriqués, que le système importateur
aura besoin de gérer à part : notices d'exemplaires, notices analytiques de
niveaux divers, notices d'autorité liées à une notice bibliographique, etc;
- si le fichier doit être lié à des fichiers associés dans d'autres formats,
si cette option est retenue : images de couverture, son, vidéos...
avec, dans tous les cas, tous les éléments nécessaires pour que les
fournisseurs de logiciels gèrent facilement les données.
Le but, pour nous, est de pouvoir transférer facilement d'une base à l'autre
non seulement des notices bibliographiques ou d'autorité, mais les notices
et éléments liés.
D'après ce que me disent les fournisseurs de logiciels, XML est très bien
pour transférer toutes de textes dans le même fichier (donc y compris du
plein texte ou des tables des matières) mais il vaut mieux mettre dans des
fichiers séparés ce qui n'est pas du texte : image, son, etc.
Il s'agit toujours ici de données et non pas de protocole d'échanges. A la limite ce que vous demandez c'est simplement que le transfert d'une notice transfère aussi les éléments qui lui sont liés.
Si nous complétons BiblioML par un couche de protocole d'échange
fonctionnelle, cet ensemble pourrait être adopté par les fournisseurs
français de données bibliographiques -auquel cas la DTD en question se
répandra aussi dans les logiciels.
Je ne pense donc pas qu'il s'agisse de "compléter" BiblioML par une "couche de protocole d'échange" mais de déterminer quels sont les protocoles d'échanges de données XML les plus à même d'être utilisés dans les bibliothèques, médiathèques et autres centres de documentation.
De la même façon qu'il y a des notices dans des formats MARC et des protocoles comme le Z39-50 je pense qu'il vaut mieux regarder du côté de notices en BiblioML et d'un protocole tel que OAI-PMH.
C'est d'ailleurs ce que nous voulons faire à l'ADNX avec le projet Bib-X .
Et pour définir ce protocole d'échange, le mieux est me semble-t-il
d'organiser une ou des réunions de travail en y invitant les fournisseurs de
logiciels et les fournisseurs de données.
Je suis volontaire pour travailler à organiser cela.
Cette proposition vous semble-t-elle pertinente ?
Oui s'y l'on distingue clairement les deux niveaux: données et protocole d'échange. Il vaut beaucoup mieux utiliser un protocole universel déjà utilisé dans l'échange de données XML que d'en élaborer un uniquement centré sur un domaine spécialisé et qui ne fera rien de mieux.
Cordialement,
Michel Bottin