Le format, qui n'était autrefois pour les bibliothécaires qu'un des élé- ments de la collation et ne trou- blait que lorsqu'il était à l'italienne (dois-je mentionner la hauteur avant la largeur ou l'inverse ?), est un terme ma- gique depuis qu'on s'est avisé d'infor- matiser. Brandi par les constructeurs, agité par la direction du Livre et de la Lecture et les directions régionales des affaires culturelles, chouchou des ca- hiers des charges, il est mis à toutes les sauces. Or, l'emploi de ce terme ne va pas sans de fâcheuses confusions, vo- lontaires ou involontaires, de la part des uns ou des autres. Essayons donc de faire le point.
Deux choses. Le Journal officiel de la République française (1) a donné une dé- finition officielle du format en informa- tique : c'est « [1] 'agencement structuré d'un support de données ou "[la] dis- position des données elles-mêmes. »
Mais les dictionnaires et lexiques d'in- formatique donnent parfois une défini- tion plus large, par exemple : « descrip- tion de la présentation des informations dans la mémoire de l'ordinateur, sur un support de mémoire auxiliaire ou lors de leur édition sur un périphérique (2) ». De fait, ce terme renvoie en informati- que à deux notions bien distinctes :
Quatre choses. Un format biblio- graphique est un cas particulier de for- mat informatique qui contient des don- nées bibliographiques destinées à être traitées comme telles. On peut en dis- tinguer sommairement quatre sortes :
On voit que les deux premières notions sont des notions de structure, alors que les deux secondes sont des notions de présentation. Ainsi, l'ISBD n'est en ges- tion informatique qu'un format d'affi- chage, alors qu'en gestion manuelle c'est aussi le «format» de catalogage.
Cette distinction entre quatre sens dé- rivés des deux significations fondamen- tales n'est en réalité pas propre aux for- mats bibliographiques, mais elle est dans ce cas à la fois particulièrement claire et particulièrement utile.
De deux façons. Les données biblio- graphiques peuvent, telles Vichnou, se manifester sous différents avatars ; elles passent d'un type de format à l'autre, voire d'un format à l'autre de même type.
Ainsi, une notice en format d'échange importée par un système est convertie dans le format de stockage du-dit sys- tème grâce à un programme de conver- sion, vulgairement appelé moulinette. A la base d'un tel programme se trouvent des tables de conversion qui constituent un système de correspondance entre la structure de l'un et de l'autre format. Inversement, une notice peut être con- vertie du format de stockage en format d'échange pour l'exportation. Ces conversions peuvent entraîner des pertes ou des déformations de données (voir encadré).
Mais une notice peut aussi être affichée ou imprimée dans un des formats pro- posés par le système : il s'agit alors d'une simple réorganisation des don- nées, sans risque de perte d'informa- tion. Enfin, lorsqu'on catalogue, les données stockées dépendent directe- ment de celles qui ont été saisies.
Un format découpe généralement les données en champs identifiés par un code. Ces champs peuvent être en nom- bre limité et préétabli par le logiciel, ou bien en nombre variable, paramé- trable par l'utilisateur, comme c'est maintenant le cas pour de nombreux systèmes de gestion de bases de don- nées. Ils peuvent être de longueur fixe, c'est-à-dire contenir un nombre de ca- ractères limité, défini pour chacun d'eux, ou de longueur variable, au gré des données saisies ou récupérées par l'utilisateur.
Les formats bibliographiques peuvent être structurés en un nombre limité de champs de longueur fixe, mais cette so- lution n'est guère satisfaisante. L'apport des formats de la famille MARC a été de proposer une structure complexe adap- tée aux données bibliographiques.
Ces formats sont normalisés, et non pa- ramétrés au gré des utilisateurs. Ils sont structurés en champs, identifiés chacun par une étiquette composée d'un nombre à trois chiffres et commençant par deux indicateurs numériques permettant d'i- dentifier la nature des informations ou d'opérer certains traitements ou tris.
Un nombre limité de ces champs, des- tinés à recevoir des données codées, est de longueur fixe. Mais la plupart, conte- nant des données bibliographiques pro- prement dites, sont de longueur varia- ble ce qui laisse libre le catalogueur de saisir toutes les informations néces- saires. La plupart des champs sont di- visés en sous-champs, commençant par un séparateur et un code de sous- champ indiquant de quelle information il s'agit, ce qui permet un traitement fin des données.
Voici par exemple, en format UNIMARC, le champ correspondant à la zone du titre propre et de la mention de respon- sabilité de l'ISBD :
Enfin, les formats MARC distinguent clairement les champs descriptifs, qui permettent notamment de reconstituer à l'affichage l'ISBD, et les champs d'ac- cès, le cas échéant normalisés par un système d'index ou d'autorité. Ils constituent des standards, des normes (qu'il ne faut pas confondre avec les normes de catalogage proprement dites). Là où les formats normalisés ont tout leur sens, c'est bien évidement comme format d'échange, et l'utilité d'un format d'échange, de référence n'est pas contestable, quelle que soit par ailleurs la variété des formats de fourniture disponibles sur le marché des notices.
Les utilisateurs ou futurs utilisateurs d'un système exigent couramment de celui-ci qu'il soit au format X ", les fournisseurs de logiciels présentent fré- quemment leur produit comme étant « au format X ». Ces expressions n'ont pas de sens car on ne sait pas de quel type de format il s'agit.
En matière d'importation, la question semble aller de soi si l'on veut pouvoir récupérer des notices bibliographiques. Mais demander l'importation sous un seul format, par exemple UNIMARC, peut se révéler insuffisant. Des données bibliographiques sont diffusées sous d'autres formats d'échange (US-MARC pour OCLC...). D'autres sont diffusées sous plusieurs formats. Il est alors judi- cieux de récupérer les données dans le format du réservoir source, plutôt que dans un format d'échange issu d'une conversion. Enfin, quand on a dit UNI- MARC, on n'a encore rien dit puisqu'en sus de l'UNIMARC officiel dans lequel au- cune notice bibliographique n'est à no- tre connaissance actuellement disponi- ble en France, la BNF fournit des notices sous deux variantes contradictoires désignées sous cette appellation (voir article sur les UNIMARC). Il est donc sage d'exiger qu'un système sache im- porter le ou les formats d'échange correspondant aux réservoirs dont on aura besoin.
Quant au format d'échange dont cer- taines bibliothèques ont besoin pour exporter des notices, s'il ne doit y en avoir qu'un, on peut actuellement pen- ser que ce doit être UNIMARC version BN-Opale sous la norme ISO 2709.
La question est rarement débattue. No- tamment parce que les constructeurs sont en général peu bavards sur leur format de stockage, à l'exception de ceux qui revendiquent un « UNIMARC natif », ce qui tendrait à faire penser que leur stockage se fait dans une structure identique à UNIMARC (lequel ?) ou en tout cas fort proche.
La question de savoir si un format de stockage doit coller le plus possible ou non à tel format d'échange, qui est sus- ceptible d'évoluer, mérite pour le moins discussion. Elle échappe de toutes fa- çons largement aux utilisateurs, qui dis- posent de critères externes pertinents pour apprécier le format d'un logiciel : est-ce que les informations importées sont correctement traitées et restituées ? Là est toute la question.
Cette autre question controversée n'ap- pelle pas de réponse univoque. Dès lors qu'on ne confond plus échange, stockage et saisie, la question du format de cata- logage peut être une question pratique, s'appréciant en termes de « convivialité », comme disent les informaticiens.
Il existe cependant une nette tendance à la généralisation de la saisie en UNI- MARC entendez le catalogage sur un masque présentant la structure et les ca- ractéristiques (étiquettes de champs, in- dicateurs, codes de sous-champs) d'un des UNIMARC, qui tend, en France du moins, à devenir le langage commun des bibliothécaires comme l'était aupa- ravant l'ISBD, au point que les deux ma- nuels de catalogage en UNIMARC qui viennent de paraître en France étaient fort attendus (3) .
Mais l'essentiel est de disposer du for- mat de catalogage qui permet la meil- leure maîtrise possible de la description et des accès (ce sera selon les cas l'un des formats MARC, avec éventuellement des intitulés en clair, ou un format pro- priétaire) tout en permettant de créer des notices conformément aux normes en vigueur.
Enfin, le catalogage en MARC deman- dant une solide formation préalable, on pourra lui préférer pour certains types de bibliothèques une grille plus simple à utiliser.
Cette question est plus simple à abor- der. On pourra distinguer :
Il n'est pas interdit de penser que si les bibliothécaires sont particulièrement at- tachés au format ISBD, ce n'est certai- nement pas le cas du public. Mais, en matière de format d'affichage public, chaque système ou chaque utilisateur de système paramétrable invente ac- tuellement sa solution, ce qui entraîne une fâcheuse dispersion.
La distinction entre les différents types de format est indispensable à la fois pour pouvoir apprécier un logiciel et pour pouvoir utiliser l'information bibliographique disponible, l'essentiel étant que le système local restitue convenablement les informations im- portées et permette à la fois une des- cription normalisée et des accès et trai- tements pertinents.
Convertir une notice bibliographique peut entraîner des pertes ou des défor- mations d'informations. On peut som- mairement distinguer trois types de ris- ques, présentés ici dans le cas de figure d'une conversion par un système im- portateur dans son format de stockage (que nous appelerons format cible), de notices importées dans un format d'échange.
Si le système dispose d'un tel format non conforme aux formats MARC, les données importées sont alors suscepti- bles d'être tronquées.
Exemple : une bibliothèque d'une pe- tite commune disposant d'un système sommaire avec champs de longueur fixe pourra importer des notices de la BDP qui la dessert, mais tous les carac- tères dépassant la longueur de ces li- mites disparaîtront.
Le système importateur peut alors soit ignorer ces informations (elles sont alors perdues) soit les stocker dans un champ (ou un sous-champ) « fourre- tout prévu à cet effet, (elles sont alors inexploitables), soit enfin les traiter d'une façon qui les rende exploitables, en « rusant avec le format cible.
Exemple : lors de la conversion en US- MARC de notices en UNIMARC, les champs de liens ascendants ou descen- dants d'UNIMARC (461 et 463) posent problème car ils n'ont pas d'équivalent en USMARC.
Il est parfois possible grâge à un pro- gramme de conversion complexe d'i- dentifier les élémets d'information exi- gés par le fprmat cible.
Exemple : lors de la conversion d'US- MARC en UNIMARC, le champ du titre et de la mention de responsabilité, qui peut ne comporter que trois sous- champs en USMARC, est décomposé par programme dans les sous-champs exi- gés par UNIMARC en utilisant la ponc- tuation de l'ISBD.
Mais, le plus souvent, il y a déforma- tion, un champ ou un sous-champ du format cible devenant le réceptacle d'in- formations plus larges que celles qui correspondent à sa définition exacte.
Exemple : on peut sur le CD-ROM ELEC- TRE récupérer des notices en format ELECTRE, en UNIMARC, en LC-MARC ou en UK-MARC. Mais c'est le format ELEC- TRE qui est le format de la base du Cer- cle de la librairie, les notices étant con- verties par le fournisseur dans trois for- mats MARC. Or il s'agit d'un format « maison nettement moins riche que les formats MARC. Par exemple, il ne distingue pas entre auteur principal et auteurs secondaires. Il en résulte que la conversion de notices ELECTRE dans un format MARC, fut-elle proposée par de Cercle de la librairie lui-même sur son propre CD-ROM, ne peut pas offrir plus d'informations qu'il n'en existe dans le format d'origine.