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.
Bien cordialement,
Jean-Paul Gaschignard
Cordialement,
Michel Bottin
Très cordialement,
Michel Bottin
|