Avant de passer à l'étape finale de constitution de mon METS et donc de mon SIP, je me suis dit qu'il ne serait pas inutile de s'intéresser à ONIX. Il s'agit d'une grammaire XML mise au point par EdiTEUR, un groupe international d'éditeurs dont la vocation est de coordonner les initiatives et les standards pour le commerce électronique dans le domaine du livre. Il est promu en France par le Cercle de la librairie, éditeur à l'origine d'Electre et de Livres hebdo.
Je ne vais pas présenter ONIX dans le détail, mais simplement voir ce qui peut m'intéresser dans le cadre d'une édition électronique sur le Web et de la constitution de mon SIP. Si vous voulez plus de détails sur ONIX, je vous renvoie à la traduction française de la spécification et de la liste de codes (essentielle !!) ainsi que cet article de Yves Desrichard, « Vers la convergence des formats bibliographiques. ONIX, application XML du monde de l'édition », paru dans le BBF en 2004, qui, malgré quelques approximations et erreurs sur Dublin Core, HTML et XML, donne un panorama des buts, des objectifs et du format ONIX en lui-même.
ONIX relève des métadonnées descriptives et, comme j'utilise déjà Dublin Core, vous allez me dire que cela fait double emploi. C'est tout à fait vrai, le seul intérêt d'utiliser ONIX est de se positionner dans l'hypothèse, présente dans l'article de Yves Desrichard et déjà entendue dans la bouche d'un conservateur très impliqué dans ces questions, qu'un jour les bibliothèques récupèrent directement ces informations au format ONIX pour créer les notices dans les catalogues (je sais, je rêve un peu, mais on le droit quand même ;-) ). Cela permet aussi d'ancrer nos initiatives dans la communauté des éditeurs.
Bon, soyons clairs, ce format est assez mal foutu, surtout si on le compare à MODS, la grammaire XML mise au point par la library of congres pour supplanter MARC, ses codes et ses dollars :-). Évidemment, les buts et les besoins sont différents et de nombreuses choses sont très spécifiques à la gestion des produits par un éditeur. Mais, cela n'excuse pas tout. Honnêtement, les éditeurs ont encore du chemin à faire pour arriver à un bon niveau de formalisation et de conceptualisation. Je ne m'arrête pas sur la spécification qui est assez mal conçu aussi. Quant aux éléments, le concept de généricité a été très mal assimilé par les concepteurs et le passage de certains éléments en attribut aurait permis de simplifier considérablement la norme. De même, les 80 listes de codes qui accompagnent la spécification est assez imbitable. Honnêtement, je préfère passer plusieurs jours pour comprends comment fonctionne une grammaire bien foutue, plutôt que de passer une demi-journée a passé en revue 180 pages de spécification dans laquelle on répète 40 fois les mêmes éléments et dans laquelle on déconseille l'utilisation d'élément pour des raisons de changement entre deux versions (les gars, il faut assumer quand on fait des conneries et détruire la compatibilité descendante, c'est pas le drame, ça arrive même aux meilleurs, cf la P5 de la TEI...).
Pour finir, je dirais que ONIX aurait intérêt à passer à RDF ce qui permettrait une meilleure formalisation et de reprendre des bouts d'autres vocabulaires existants, plutôt que de réinventer la roue (j'ai adoré les éléments HTML à l'intérieur de certains éléments ONIX, eh ! les espaces de noms, ça existe !!), bon par la même occasion, il faudrait passer MODS en RDF et ce serait nickel :-). Je clos le chapitre pro-RDF et râleries contre ONIX. Voyons maintenant concrètement ce qui peut nous intéresser dans cette norme pour constituer les SIP, car tout n'est pas à jeter et ONIX existe, donc utilisons-le.
Sur les 26 parties qui composent ONIX, 11 sont intéressants pour les publications électroniques sur le Web en accès libre et gratuit. Évidemment, nous n'avons pas besoin des informations relatives à la gestion des stocks, à la description physique du produit... Voici donc ce que j'ai pu relever, mais j'ai peut-être laissé passer des choses intéressantes :
Le format du produit permet de renseigner qu'il s'agit d'un site Web (pas de précisions dans la taxonomie offerte par ONIX). Ce type de produits (si on reprend la terminologie d'ONIX) possède le code DH
Le groupe de titre permet d'indiquer les renseignements sur le titre, sous-titre, titre original dans le cas d'une traduction, abréviation dans le cas d'un titre long...
Le groupe de description d'une publication numérique (comme quoi les éditeurs vont finir par s'y mettre, ne désespérons pas...) pour indiquer le type de publication électronique, dans notre cas, HTML avec la précision (attention, retenez votre souffle !) sans DRM... et décrire le format de la source de la publication (XML dans notre cas)
Le groupe de description du site Web du produit est prévu normalement pour indiquer un lien vers un site Web promotionnel. Ils n'ont pas prévu à cet endroit que le site Web soit lui-même la publication ce qui en dit long sur les pensées des éditeurs traditionnels sur ce vecteur de diffusion. On finit par s'arranger en sélectionnant le code correspondant à « autre rôle du site Web »...
Les informations sur la/les langues utilisées. Pas grand chose à dire, si ce n'est qu'il faut utiliser la norme ISO 639-2/B.
Les sujets du produit. Vous pouvez indiquer les sujets selon la taxonomie qui vous fait plaisir en indiquant laquelle vous utilisez. J'ai trouvé le système bien compliqué, sachant qu'il y a un <MainSubject> et les autres sujets : <Subject>. Ça doit être pour faciliter le travail des bibliothécaires pour l'emplacement selon la dewey ou la CDU.
les groupe de publics permet d'indiquer selon une classification précise les publics concernés par le produit. Dans mon cas, ce sera toujours ou presque : Universités/études supérieures et Professionnel/universitaire.
Les différents textes d'accompagnement, ce qui recoupe quatrième de couverture, extrait de critiques, résumé...
Le groupe d'informations relatives à la collection dans laquelle prend place le produit permet de renseigner le nom de la collection et le numéro du produit dans la collection.
le groupe de renseignements sur les « contributeurs », c'est exactement le même système que Contributor dans Dublin Core. Il permet donc de spécifier précisément le rôle du « contributeur », son nom et les renseignements qui peuvent le concerner (biographie, affiliation, position professionnelle...)
le groupe de renseignements sur l'éditeur (au sens de publisher) et la publication permet de renseigner le nom de l'éditeur, la ville de publication et la date de publication.
A terme, je voudrais bien pouvoir utiliser la partie consacrée aux prix et récompenses reçus par le produit ;-)
Voilà, le tour d'horizon très rapide d'ONIX. Nous voilà équipés pour affronter maintenant le rassemblement au sein du fichier METS de PREMIS, ONIX et Dublin core. A suivre, donc !!...