En direct de l’IFLA

Il faut que je songe a remplir mes devoir de blogueuse IFLA (fonction attestée par le ruban bleu que je porte sur mon badge) et ne pas céder à la facilité en me contentant de réflexions en moins de 140 caractères…

Le congrès a commencé comme à son habitude intensément, avec les réunions des comités permanents samedi matin, le caucus des francophones samedi soir, la session d’ouverture et les premières sessions thématiques dès dimanche. Pas de week-end pour les congressistes ! (pas de jour ferié non plus, cela va sans dire).

Le programme est très intéressant cette année et on regrette de ne pas pouvoir se dédoubler pour assister à plusieurs sessions à la fois. Heureusement, grâce au fil Twitter #wlic2011 qui est assez bien alimenté, on peut avoir une idée de ce que se passe dans les autres salles.

Ainsi le Web sémantique est à l’honneur et il a été abordé hier dans deux sessions qui se déroulaient en parallèle : la session des bibliothèques d’art, avec une présentation sur VIAF et celle de la section de Catalogage avec le projet polymath, un projet sur les autorités en Linked Data dont j’avais entendu parler parce qu’ils ont présenté un use case au LLD XG. Dans cette 2e, il semblerait que la question de l’avenir de MARC (ou son absence en l’occurrence ;-) ait été évoquée. Elle le sera encore dans d’autres sessions.

En parallèle encore, le FAIFE (Committee on Freedom of Access to Information and Freedom of Expression) organisait une session intitulée « how to fix the world », oui, rien que ça ! ou il a été question (d’après le flux Twitter) notamment des émeutes en Egypte et des libertés individuelles.

Ce matin, après avoir écouté la session plénière ou il était question de propriété intellectuelle, je me suis rendue a la réunion du Namespace task group. Ce groupe, pour l’instant plus ou moins informel, réunit plusieurs sections et groupes de l’IFLA pour coordonner la publication des standards bibliographiques sous forme de vocabulaires RDF.
Cela faisait longtemps que le groupe ne s’était pas réuni (je me demande même si ce n’était pas la première fois… On avait surtout travaillé par mail par le passé) et c’était tout à fait passionnant. Parmi les sujets abordés, nous avons évoqué le problème de la traduction des labels dans des langues autres que l’anglais, les liens entre vocabulaires, le dédoublonnage des notices…
Les activités de ce groupe seront liées à celle du groupe d’intérêt spécialisé sur le Web sémantique, le SWSIG, que je réunis mercredi matin à 9:30 (si des congressistes me lisent : surtout n’hésitez pas à y assister, même par simple curiosité !)

A suivre…

Ma valise pour l’IFLA

Bon alors… départ pour l’IFLA la semaine prochaine… qu’est-ce que je vais mettre dans ma valise ?

1, Mon article sur Convergence et interopérabilité : l’apport du Web de données pour la session de la la section Classification et Indexation. Que j’ai écrit en français, pour une fois… Faudrait peut-être que je fournisse la traduction, d’ailleurs, oups, ne serais-je pas un peu en retard ?
Tiens, en tout cas, il va y avoir des choses intéressantes dans cette session : comment skosifier votre bibliothèque, un service japonais pour le Web sémantique, et l’indexation par le Web à la Bibliothèque du Congrès.

2. Le rapport final du LLD XG, dont nous allons présenter les résultats lors de la première réunion du nouveau groupe « Web sémantique et bibliothèques » que j’anime.
Le rapport en question n’est pas tout à fait fini, on y travaille encore… Et d’ailleurs ce n’est pas tout ! Il y a deux livrables complémentaires : l’un qui liste les données et vocabulaires disponibles, l’autre qui synthétise notre collecte de use cases.

3. Le texte fondateur du groupe d’intérêt spécialisé que j’évoquais plus haut, le SW SIG. C’est qu’il va falloir réfléchir à ce qu’on va faire dans ce groupe pendant les deux ou trois ans à venir… Ce sera le but de la réunion du groupe : une réunion ouverte, à laquelle tout le monde peut venir.

4. Les documents des autres groupes auxquels je participe :
– le comité permanent de la section Information Technology,
– le Namespaces task group qui travaille sur la publication des vocabulaires de l’IFLA (dont la FRBR family),
– l’ISBD XML group qui (comme son nom ne l’indique pas) finalise en ce moment une version de l’ISBD en RDF, version qui a déjà été utilisée par la British Library dans la version Linked Data de leur bibliographie nationale, publiée récemment.

5. Le programme de toutes les intéressantes sessions de la conférence auxquelles je vais pouvoir assister : sur le dépôt légal numérique, la formation pour la gestion des collections numériques, etc.

6. Mon ordinateur portable. Mon blog. Mon Facebook. Mon Twitter, avec le hashtag #wlic2011.

7. Mon maillot de bain :-) quand même…

Un réservoir de données liées…

En farfouillant dans les archives du Figoblog pour produire un document, je retombe sur cet article d’avril 2006 dans lequel je suggérais :

Moi je verrais bien l’évolution du catalogue vers un statut de base « pivot », contenant des données en XML qu’on pourrait réutiliser à volonté, dans des applications adaptées aux différents types d’usagers.

5 ans après, je ne sais pas si je suis complètement monomaniaque ou franchement visionnaire, mais j’ai toujours la même vision. A quelques détails près.

Je pensais XML, parce que je n’avais pas encore réalisé qu’il n’était pas vraisemblable de vouloir faire entrer toutes les données du catalogue, dans leur diversité, dans un même modèle documentaire.
Il a fallu s’extraire des carcans de la pensée documentaire pour considérer que ce dont nous avons besoin, ce n’est pas un format unique, mais un modèle générique capable d’intégrer de façon souple et auto-descriptive différents formats.

J’avais aussi pressenti que le problème n’était pas d’imaginer les nouveaux usages, mais d’imaginer un réservoir de données capable de s’adapter à tous les usages possibles :

Il y a des usages, multiples, différents, et aucun outil miracle ne saura tous les contenter. Il faut des données fiables et souples, qu’on peut sortir, transformer, adapter, réutiliser. Pour moi c’est ça le futur du catalogue.

En fait, j’envisageais déjà le catalogue comme un système métastable, c’est à dire capable d’intégrer les évolutions de façon naturelle, et pas uniquement comme des facteurs de remise en cause et d’instabilité.

En fait, il fallait pousser le raisonnement jusqu’au bout : ce qui m’inspirait ces réflexions c’était le modèle du Web. Or, le Web, en tant qu’espace global d’information (un espace où on peut naviguer d’une page à l’autre sans rupture, ni technologique, ni dans l’expérience utilisateur : il suffit de « cliquer »), nous apprend précisément ceci : si on veut que de larges quantités d’informations puissent interopérer, il faut accepter qu’elles soient produites de façon hétérogène, et n’imposer que le niveau minimal de normalisation permettant à toutes ces informations de cohabiter dans le même espace.

Les systèmes d’information actuels (dont les catalogues) posent exactement ce type de problème : ils sont instables au sens où leur équilibre est sans arrêt remis en cause par quelque chose de nouveau (un nouveau format, un nouveau besoin, une nouvelle fonctionnalité), et ils sont hétérogènes parce qu’à chaque nouveau besoin, on donne une réponse spécifique.

Le Linking Enterprise Data correspond à l’application des principes du Linked Data au domaine de l’entreprise. Je ne vous parle même pas d’exposer les données sur le Web. L’enjeu est seulement d’utiliser le Web (ou le Web sémantique) comme modèle pour la conception du système d’information. On adopte un niveau de normalisation minimal pour toutes les applications, de façon à ce que les données soient interopérables et reliées (avec des URI). A partir de là, le système devient métastable, capable de maintenir une certaine stabilité dans un contexte en évolution. Quand un nouvel usage émerge, la donnée est déjà disponible, il suffit de l’agréger pour la retraiter.

La masse des données manipulée dans les catalogues (surtout les gros) rend illusoire l’adoption d’une base unique, d’un format unique. Techniquement, les problèmes de performance et de cohérence sont exponentiels. Du point de vue de l’utilisateur, le modèle est rigide, inadapté aux évolutions.
Il faut adopter un modèle qui est prévu, de façon inhérente, pour être permissif aux évolutions. RDF par exemple.
Dès lors le catalogue, plutôt qu’un réservoir unique, est une plate-forme, un environnement cohérent au niveau local (à l’intérieur de la bibliothèque) dont le rôle majeur est de relier les données et de les rendre disponibles.

Merci à Got d’avoir partagé ses lumières avec moi sur ce sujet.

Et au fait, le LLD XG ?

Il y a quelques mois, j’annonçais ici la naissance d’un groupe au W3C sur les bibliothèques et le Web de données. Depuis, silence radio… et pour cause ! C’est un peu prenant, comme activité. D’ailleurs, ceux d’entre vous qui auraient essayé de suivre via la liste de discussion se seront rendu compte qu’il s’y passe tellement de choses que c’est parfois difficile de suivre. Même pour les membres du groupe, et même pour les co-chairs, alors ;-)

Du coup je me suis dit qu’un petit point d’étape à mi-parcours, et en français dans le texte, ne serait pas inutile. Oui à mi-parcours, on a déjà passé la moitié de l’espérance de vie normale de ce groupe…

Depuis le mois de mai, le groupe se réunit chaque semaine pendant une heure au téléphone. Vous me direz, comment on fait pour tenir une réunion d’une heure, avec en général entre 10 et 20 personnes en ligne, par téléphone et dans une langue étrangère pour la la plupart des membres du groupe ? Et ben, on y arrive grâce à l’infrastructure géniale du W3C (et un peu d’organisation).
Sur le wiki vous trouverez le running agenda, qui contient toutes les actions en cours et les sujets de travail actifs. Chaque semaine, celui qui préside la réunion le met à jour et envoie un sous-ensemble, les points qui seront traités, sur la mailing list.
Pendant la réunion, on est au téléphone et en même temps sur un canal IRC qui permet aux robots du W3C (Zakim et ses amis) de nous rejoindre et de gérer les aspects « logistiques » de la réunion : passer à la parole à ceux qui la demandent, couper les micros qui font trop de bruit, et prendre des notes. Enfin, c’est le scribe (une fonction tournante) qui écrit directement dans le canal IRC tout ce qui se passe : comme ça les minutes sont prêtes, ou presque, dès que la réunion est finie.

Je ne vous recommande pas la lecture des minutes de réunion, qui sont un peu dures à comprendre quand on n’a pas participé, mais il existe une page où sont récapitulés tous les sujets qui ont été traités pendant les réunions, ce qui permet de voir un peu l’avancement du groupe.

En octobre, nous nous sommes rencontrés à Pittsburgh pour le « face to face », seule et unique réunion présentielle dans la vie du groupe. Cette réunion a duré 1 jour et demi, et était elle aussi assistée par Zakim, avec des minutes extensives.
Mais bon, pour que cela soit compréhensible pour le reste du monde, nous avons produit un résumé des résultats de cette réunion.
Principalement, ce que nous avons fait c’est que nous avons regroupé les 42 (et plus) « use cases » que nous avions reçu en plusieurs « paquets » thématiques, les use case clusters, sur lesquels nous travaillons actuellement (voir ci-dessous).
Nous avons aussi travaillé sur la liste des sujets intéressants (« topics ») que nous avions identifié en lançant le groupe, pour essayer d’évaluer ce qui serait faisable dans le groupe d’incubation lui-même, et ce qui devrait faire l’objet de recommandations pour des actions ultérieures.

Depuis, nous bossons dur sur les use case clusters. L’objectif est, en partant de cas réels identifiés dans les use cases, d’essayer de couvrir plus ou moins tout le spectre des problématiques du Web de données en bibliothèque… pas une mince affaire !

Le cluster Bibliographic Data s’intéresse au cœur de cible des données de bibliothèques : la notice bibliographique. Il aborde des sujets tels que l’évolution des modèles et des formats, les problématiques de duplication et d’échanges de notices, et bien sûr, une discussion qui fait rage sur la liste en ce moment : dans un contexte de Web de données, peut-on encore parler de « notice » ?

Le cluster Authority data (la page est encore vide, mais ça va venir ;-), qui porte sur les données d’autorité, touche des problématiques assez différentes. Il fait l’objet d’une discussion pour savoir si quand on parle d’autorités, il est question des « choses » elles-mêmes ou juste des « noms » des choses. En fait, une discussion intensive autour de VIAF sur la liste a conduit à une sorte de consensus sur un modèle qui, à partir d’une notice d’autorité (par ex. une personne), produit un ensemble d’assertions reliées entre elles, dont certaines portent sur la personne en tant qu’entité, et d’autres sur son « label » (sa forme, on dirait en français) et les caractéristiques de cette forme.

Le cluster Vocabulary alignment porte sur l’utilisation de vocabulaires reliés entre eux pour améliorer l’interopérabilité entre des données qui sont décrites suivant des standards différents.
En fait, il s’avère que ce terme de « vocabulaire » était sujet à ambiguïté, ce qui a conduit, là encore, à tout un tas de discussions sur la liste, et débouché sur cette définition, dont nous ne prétendons pas qu’elle est globalement parfaite, mais plutôt qu’elle est suffisamment claire pour servir les besoins de notre groupe, à savoir, produire un rapport à peu près compréhensible pour des bibliothécaires ;-)
Au-delà de ça, il s’agit d’identifier la façon dont l’utilisation des technologies du Web sémantique pour aligner des vocabulaires va permettre d’améliorer l’expérience de l’utilisateur en terme de recherche et de navigation (search and browse). Bien sûr, cela ouvre aussi des perspectives pour améliorer ces vocabulaires eux-mêmes.

Le cluster Archives and heterogeneous data est un ensemble de cas qui touchent à la convergence entre des données au-delà des bibliothèques (archives, musées, etc.) en particulier dans des contextes où on essaye d’agréger ou de fédérer des grosses quantités de données.
C’est celui sur lequel j’ai travaillé donc je ne suis peut-être pas tout à fait objective… Mais à mon avis, son intérêt principal est de faire émerger le besoin, pour ce type de données, d’utiliser ce que les archives appellent le contexte (ou les bibliothèques, les autorités), bref un réseau d’informations sémantiques, pour relier des données qui sont différentes, qui décrivent des ressources différentes, mais qu’on voudrait pouvoir connecter quand même pour offrir une dimension de navigation à l’utilisateur.
Dans ce cluster, on touche aussi à l’intérêt du Linked Data pour des données non bibliographiques et à des fins professionnelles (l’utilisateur est le bibliothécaire ou l’archiviste).

Le cluster Citations travaille sur la notion de référence bibliographique. Après avoir posé une définition à plusieurs niveaux, il s’est attaché à imaginer ce que le Linked Data pourrait apporter comme enrichissements à la notion de citation telle que nous la connaissons actuellement : notamment en permettant l’accès direct à la ressource citée, ou en ajoutant des liens typés permettant d’être plus précis sur la relation entre le document citant et le document cité. La problématique des formats de citation est à rapprocher de celle des données bibliographiques.

Le cluster Digital Objects fait le tour des besoins liés à la publication d’objets numériques en ligne, l’accent étant mis sur la nécessité de pouvoir regrouper des objets, les enrichir, les parcourir et les réutiliser. Derrière la notion de regroupement on retrouve celle de structuration des objets complexes, avec notamment la mention d’OAI-ORE.

Ces 6 clusters étaient ceux qui avaient émergé de la réunion « face to face », mais par la suite nous avons été amenés à en créer deux autres : Collections qui traite des collections de bibliothèques et aussi de la problématique de la localisation des objets physiques, et Social Uses qui vient juste de lancer un appel à contributions.

Voilà, nous en sommes là ! Le travail sur les clusters est en train de se terminer, et je suppose qu’ensuite, nous commencerons à l’intégrer dans l’embryon de ce qui sera notre rapport final.

DC 2010…

Me voici donc à Pittsburgh pour la conférence «Dublin Core 2010», où le DC fête ses 15 ans, et la conférence ses 10 ans.
Un petit mot sur cette communauté : on compte ici environ 150 personnes, ce qui fait peu, je trouve, si on considère que c’est une des conférences majeures sur les métadonnées (à croire que les experts en métadonnées ne sont pas légion ;-)

Bien qu’il y ait beaucoup de «nouveaux», de gens qui comme moi assistent à leur première conférence DC, ma première impression a été celle d’une communauté arrivée à un moment critique de son existence, en quête d’un difficile équilibre entre l’expérience sur laquelle elle est assise, associée à un certain effet d’inertie, et son image de communauté innovante ancrée dans l’écosystème du Web.
Ainsi, quand la communauté se retourne pour regarder les 15 années passées derrière elle, ce n’est pas sans une certaine amertume… Impression qui ressortait particulièrement de la «Keynote» de Stu Weibel, un des fondateurs du DC, qui est revenu sur les succès et les échecs de 15 années de normalisation. Un bilan quand même assez désabusé, face à la complexification croissante de ce qui se voulait un standard simple, et les difficultés pour se conformer véritablement au mode de fonctionnement et au développement du Web.

Mais à part cela, le Linked Data est partout, et l’initiative du LLD XG a été citée de façon répétée, apparaissant comme une porte de sortie, ou plutôt un espoir de transition vers quelque chose de nouveau, un nouveau souffle pour la communauté.
Il faut dire qu’avec 42 use cases collectés, le LLD XG semble réunir le matériau nécessaire pour démontrer à la fois l’importance et l’utilité du Web de données, et la voie pour y arriver.
J’ai assisté à une grande partie de la session «spéciale» sur le Linked Data organisée par Karen Coyle et Corey Harper. Dans le groupe de travail «Library Community», le Linked Data était aussi à l’honneur, avec une présentation du XG, et des initiatives allemandes (Univ. de Mannheim et DNB).

Autre sujet brûlant, les FRBR. Il y avait une session plénière qui leur était consacrée, mais on en a aussi beaucoup parlé dans la session spéciale Linked Data, qui portait sur les «domain models».
Cela soulève beaucoup de questions : les FRBR sont-ils trop complexes ? sont-ils le modèle adapté pour décrire l’information des bibliothèques, en particulier une information «héritée» (legacy data) qui n’est pas conforme au modèle ? Est-ce que la complexité du modèle ne risque pas de complexifier les données ?

A suivre…

Petite visite guidée de RDA

Pour ceux qui n’auraient pas encore eu l’occasion de jeter un oeil au RDA Toolkit, voici un petit guide de ce que l’on peut y trouver (NB : j’avais pris ces quelques notes à l’époque où il était encore en accès libre…)

Si on le déroule dans l’ordre (ce qui n’a peut-être pas de sens, vu qu’il y a des liens dans tous les sens, c’est un hypertexte ;-) mais bon il faut bien commencer quelque part), on rencontre d’abord une introduction qui présente les objectifs de RDA, le lien avec les FRBR et autres standards, et une liste des « core elements ».

Viennent ensuite les sections 1 à 4, consacrées à l’enregistrement des attributs des
– manifestations et items,
– œuvres et expressions,
– personnes, familles et organisations,
– et concepts, lieux et événements (cette section n’est pas encore développée sauf pour les lieux).
Dans RDA, les attributs jouent un rôle essentiel puisque ce sont les éléments qui constituent la description elle-même, et donc qui permettent d’identifier les entités. Chaque entité est ainsi décrite avec des « core elements », qui sont plus ou moins obligatoires, et des éléments additionnels qui ne doivent être utilisés que s’ils sont nécessaires pour identifier l’entité.
Pour tout ce qui peut servir de point d’accès, au sens bibliographique du terme (ce par quoi l’utilisateur cherche), donc les œuvres, expressions, personnes etc., on construit également un « point d’accès autorisé » avec un titre ou nom préféré, et des variantes.

Viennent ensuite les sections consacrées aux relations entre entités.
La section 5 est consacrée à l’enregistrement des « relations primaires » c’est-à-dire les relations structurelles entre entités du groupe 1 : Œuvre, Expression, Manifestation et Item. Elles sont supposées être exprimées dans cet ordre, sauf qu’on peut sauter l’Expression si on veut.
Les sections 6 et 7 sont consacrées aux relations entre les entités du groupe 1 et celles des groupes 2 et 3 (celles du groupe 3 ne sont pas encore développées).
Les sections 8, 9 et 10 sont pour les relations internes à chaque groupe d’entité (le groupe 3, vous l’avez deviné, n’est pas encore développé).
L’expression de toutes ces relations fait appel à des « relationships designators » dont les listes sont enregistrées en annexe :
– annexe I pour les relations entre une entité du groupe 1 et une entité du groupe 2 (ce qu’on pourrait appeler les « rôles »);
– annexe J pour les relations internes entre les entités du groupe 1;
– annexe K et L pour les relations internes aux groupes d’entités 2 et 3.

Ces relations constituent une sorte de spécialisation ou d’interprétation de FRBR, au sens où des choix assez radicaux ont été effectués.
Par exemple, s’agissant des « rôles », le « creator » ne s’applique qu’à l’œuvre, alors que l’expression, elle, a un « contributor ». La manifestation peut avoir un publisher, un distributor, et un manufacturer ; quant à l’item, il peut avoir un owner et un custodian.

Les règles elles-mêmes peuvent porter sur les sources d’informations à consulter (même si « take this information from any source » est probablement la phrase qui revient le plus souvent dans RDA, surtout quand il s’agit des œuvres et ce genre de trucs…), et sur la façon de transcrire les informations. Il y a un certain nombre de règles particulières pour les manuscrits, les documents et œuvres audiovisuel(le)s, ou encore les documents électroniques (y compris des informations techniques et des informations sur les restrictions d’accès).

Enfin pour certains éléments, on dispose de référentiels qui permettent de prédéterminer une liste de valeurs à utiliser.
Noter ainsi que le support se décline en trois éléments :
– le type de média, qui indique le type de matériel à utiliser pour accéder au contenu, dans une liste qui inclut « unmediated: Media used to store content designed to be perceived directly through one or more of the human senses without the aid of an intermediating device » (j’adore…)
– le type de support, à préciser pour chaque média (par exemple si le média est « computer », le support peut être « computer disc », computer tape », etc.)
– et enfin l’étendue (? « extent ») qui indique le nombre d’unités (et éventuellement de sous-unités) qui constituent la ressource : par ex. 3 microfiches, 2 computer discs etc.

Au final, après le rapide tour d’horizon de RDA que j’ai effectué, voici quelques impressions personnelles :
– beaucoup de souplesse : les règles ne sont pas très directives ; elles proposent souvent des alternatives, des exceptions, ou laissent la porte ouverte à l’interprétation…
– du flou, parfois : il faut la plupart du temps décortiquer les exemples pour réussir à comprendre où les règles veulent nous emmener…
– et pas mal d’implicite : il faut connaître ses FRBR sur le bout des doigts. Les RDA ne vous donneront pas de clés pour décider comment dépatouiller les cas complexes et limites d’identification des œuvres. Si vous cherchez à déterminer quelle est précisément la relation à utiliser pour raccrocher le dernier livre de bain que vous avez offert à votre tout-petit et qui s’intitule « la petite sirène » à l’œuvre d’Andersen, autant vous le dire tout de suite, la réponse ne se trouve pas dans les RDA.
Bref, les RDA ne sont pas du prêt à consommer. Il me semble qu’il y a un gros travail d’accompagnement et de documentation à effectuer avant de mettre cela entre les mains d’un catalogueur…

Enfin, sachez que même si vous n’avez pas accès au Toolkit dans sa version payante, vous pouvez télécharger tous les schémas qui représentent les différentes entités, leurs attributs et relations, et incluent les principales définitions.

Le catalogueur, l’usager et le système

Comme je parcourais le RDA Toolkit, profitant de sa temporaire gratuité (jusqu’au 31 août, je le rappelle), je me suis sentie dériver librement au fil de pensées inattendues.

S’appuyant sur les FRBR et sur les principes internationaux de catalogage, les RDA rappellent une chose qu’on parfois trop tendance à négliger quand on parle de catalogage : le but du catalogage, c’est de répondre aux besoins des utilisateurs, tout en rationalisant les moyens qu’on déploie pour y arriver :

The data should meet functional requirements for the support of user tasks in a cost-efficient manner.

Non, le catalogage n’a pas été inventé par les bibliothécaires pour se faire plaisir (ou pas uniquement).

Les lecteurs de ce blog, quand on leur parle FRBR, se souviendront peut-être des fameux 3 groupes d’entités et de l’articulation entre Œuvre, Expression, Manifestation et Item. Je suis à peu près sûre que parmi les gens qui ont des notions quelconques de FRBR, peu d’entre eux se souviennent que les FRBR, c’est aussi une description détaillée des opérations effectuées par les utilisateurs, réparties en 4 grands groupes : trouver, sélectionner, identifier et obtenir. S’y ajoute le niveau de pertinence des différentes métadonnées pour accomplir ces tâches.

Les RDA reprennent ces tâches pour rappeler à quoi sert chaque partie de la description, ce qui n’est pas du luxe. Cela leur permet de définir les « core elements », dont on a toujours besoin quoi qu’il arrive, et les autres qui ne sont à renseigner qu’en tant qu’ils sont indispensables pour accomplir les tâches utilisateurs.
En cela, ma compréhension de RDA (je n’ai pas fini de les lire, c’est donc plutôt une impression globale) c’est qu’une grande liberté est laissée au catalogueur (ou à l’agence pour qui il travaille) pour décider plus précisément des éléments nécessaires à la description de telle ou telle ressource.
Derrière cette liberté se cache l’économie du catalogage. En effet, RDA nous laisse entrevoir un monde meilleur où on ne décrirait d’une ressource que ce qui est vraiment nécessaire pour la trouver, l’identifier, la sélectionner et l’obtenir, et rien de plus. Un monde où au lieu de répéter N fois l’information, on pourrait relier les ressources et les descriptions entre elles. Un monde où on aurait des descriptions pour des parties, des descriptions pour le tout, et des descriptions hiérarchiques qui les combinent.

Dérivant toujours le long du fil de mes pensées, j’ai saisi l’effluve évanescent d’un souvenir, ou plutôt, d’un leitmotiv que j’ai entendu maintes fois prononcé, chuchoté dans les couloirs : c’est le fantôme du catalogage à niveaux qui revient.
Moi qui suis une (relativement) jeune professionnelle, je n’ai connu du catalogage à niveaux que ces réminiscences lointaines, comme un spectre qu’on aurait eu tant de mal à chasser, et qui s’obstinerait à revenir par la petite porte.
Alors, me suis-je demandé, au fait, c’était quoi le catalogage à niveaux, et pourquoi diable l’a-t-on abandonné ?
Après une courte recherche dans mon moteur préféré, je suis tombé sur cet article de 1988 qui explique que le catalogage à niveaux, c’était :

une présentation élégante, rationnelle : les éléments communs de la notice sont mis en dénominateur commun ; les éléments propres aux volumes sont donnés à la suite les uns des autres

et qu’on l’a abandonné parce qu’il était mal géré par certains formats MARC (notamment nord-américains) et par les progiciels de catalogues de bibliothèques.
Je ne résiste pas à vous proposer cette autre citation d’une saveur toute particulière (nous sommes, je le rappelle, en 1988) :

L’arrivée de nouveaux supports de diffusion utilisant des logiciels documentaires puissants permettant des combinaisons de clés variées et la recherche par mots clés sur la totalité de la notice, confirme aujourd’hui que la séparation des informations est une technique dépassée.

Un élan de nostalgie m’a emportée à l’idée qu’on a renoncé à quelque chose qui était pratique pour les catalogueurs ET pour les utilisateurs, parce que les formats et les systèmes ne savaient pas le gérer.
Puisse l’avenir nous préserver d’un monde où on définit les formats en fonction des systèmes, et les usages en fonction des formats. Voilà à quoi sert l’étape de modélisation : à définir les objectifs du modèle et le modèle lui-même, avant de concevoir les outils qui vont l’exploiter.

NB : en fait, les notices à niveaux n’ont pas totalement disparu du catalogue de la BnF. L’intermarc permet de gérer des « notices analytiques » pour le dépouillement de plages de disques, lots d’images, etc…

Après Göteborg, Singapour : un cadre pour les Application Profiles

Après avoir entendu parler (ou reparler ?) à plusieurs reprises des « profils d’application » (application profiles ou AP) du Dublin Core, que ce soit dans le LLDXG ou à l’IFLA, j’ai éprouvé le besoin de me replonger dans tout cela. Force est de constater que je ne m’y étais pas intéressée de près depuis plusieurs années, alors que le développement de RDF et du Web de données a conduit le DCMI à revoir complètement son modèle abstrait (le DCAM, Dublin Core Abstract Model) et cette notion d’Application Profile, vers 2007.

Il n’est pas dans mon propos d’entrer dans les détails du DCAM aujourd’hui. Ce modèle est surtout utile en tant que référent pour le vocabulaire un peu particulier utilisé dans le monde Dublin Core.
Plus intéressant, à mon avis, est le Singapore framework for Application Profiles, un autre document du DCMI qui a le statut de « recommended resource » (autrement dit, ce n’est pas un standard, mais il est important quand même).

Ce document, le cadre de Singapour, a été proposé à la conférence DC en 2007 (décidément une année cruciale). Il définit les différents éléments constitutifs d’un Application Profile.
Quand on applique un standard de métadonnées, il existe différents niveaux qui doivent être pris en compte pour favoriser l’interopérabilité : bien sûr il faut respecter la syntaxe, le nom des éléments, la façon adéquate de les utiliser selon qu’ils sont obligatoires ou pas, répétables ou pas, etc. Mais pour aller plus loin, il faut aussi définir précisément les valeurs de ce qu’on met dans ces éléments, et éventuellement la façon de construire ces valeurs.

Je vais faire une comparaison pas du tout triviale avec le monde des bibliothèques.
Nous avons des standards qui sont des formats de métadonnées (MARC par exemple, et ses « différents parfums » comme dirait l’autre).
Nous avons d’autres standards qui sont des règles de catalogage et expliquent comment, à partir d’un document qu’on a entre les mains, on va déterminer quel est le titre, l’auteur principal, l’éditeur, etc. et comment il faut les transcrire dans la notice. Cette deuxième famille de norme comprend AACR2 pour les anglo-saxons, ISBD pour le reste du monde, et RDA pour l’avenir (peut-être).
Nous avons également des standards qui décrivent le modèle sous-jacent de toute cette information et à quoi elle sert : ce sont les FRBR et leurs petits frères FRAD (vient de sortir en français) et FRSAD.
Construire un Application Profile, cela revient à embrasser toute la palette de ces normes pour une communauté définie, et à formaliser le résultat.

Le Singapore framework définit ainsi les éléments suivants comme constitutifs d’un AP :
– les spécifications fonctionnelles (functional requirement ou FR – ça vous rappelle quelque chose ?) et le modèle du domaine : ce sont les représentations abstraites qui définissent l’objectif de notre AP, et elles sont obligatoires ;
– le Description Set Profile, sur lequel je vais revenir dans un instant ;
– et les guides d’utilisation (guidelines) pour le contenu et pour l’encodage, tous deux optionnels. Ce sont les équivalents de nos règles de catalogage mais aussi, guides et outils du catalogueur divers.

Je ne reviens pas sur les modèles et sur les guides.
Le Description Set Profile (DSP) fait l’objet d’un document normatif DCMI encore au stade de « working draft ».
Le DSP est un document XML qui permet de décrire les différentes propriétés qu’on utilise dans notre AP, et jusqu’à un certain point, la façon dont on les utilise.
Le DSP prend complètement acte de RDF, au sens où il ne se restreint absolument pas aux propriétés du DC (voir ici pour un rappel). On peut donc construire un Application Profile en piochant dans les différents vocabulaires qu’on veut, FOAF, DC, etc. du moment que les propriétés qu’on utilise sont identifiées par une URI. Jusqu’ici, on est bien dans l’esprit de RDF.
Le DSP permet aussi de préciser un certain nombre de choses sur la façon dont on utilise ces propriétés. On peut préciser si l’objet doit être une ressource (identifiée par une URI) ou un littéral (une chaîne de caractères), ou si la propriété doit être obligatoirement une sous-propriété d’une propriété plus générique. On peut également définir qu’une propriété est obligatoire ou non, répétable ou non.

Bref, le DSP est conçu pour permettre de « valider » un ensemble de triplets RDF en fonction de règles prédéfinies (on parlerait d’un « pattern » en anglais, et ce sera compliqué à traduire). Le but étant d’obtenir des descriptions, ou si vous voulez des notices, le plus homogènes possibles. Il existe un document du DCMI qui définit les différents niveaux d’interopérabilité que l’on peut atteindre. Le DSP permet d’atteindre un niveau d’interopérabilité optimal !
Cette notion de validation, en réalité, est un non-sens en RDF. Les ontologies ne servent pas à valider les données. Elles se contentent de décrire les choses et leurs qualités, mais elles ne sont pas prescriptives. Ce n’est pas parce qu’il y a une propriété foaf:geekCode que tous les gens qu’on décrit en utilisant foaf sont nécessairement des geeks (ou doivent le devenir ;-) A l’inverse, en RDF, chaque triplet est indépendant ; il n’y a pas de notion de « notice », donc aucun moyen de dire que si on veut décrire une personne, il est obligatoire de mentionner son nom de famille – par ex.
Pour autant, si on veut pouvoir vérifier que certaines règles sont respectées pour produire certains types de données, on aura besoin de ce genre de mécanisme. Cela peut être le Description Set Profile tel qu’il se présente actuellement, mais on pourrait imaginer (et les gens du DCMI y réfléchissent) d’autres formalismes, des schémas XML, des schématrons, ou même des requêtes-type pour exprimer cette notion de validation.

Le Singapore framework for Application Profiles et le Description Set Profile sont donc des documents qui à mon sens méritent toute notre attention, car ils font le pont entre le monde du Linked Data et celui des bibliothèques où tout est encore articulé autour du paradigme de la notice. Il me paraît clair que nous aurons besoin de ce type de formalisme – je ne dis pas celui-là en particulier, mais quelque chose de ce genre – si on veut porter toute la complexité des données des bibliothèques dans le Linked Data. Ou ne serait-ce qu’une partie.

IFLA 2010 – Suite et fin

Les deux dernières journées de l’IFLA, samedi et dimanche, ont été riches en ce qui me concerne, car le dimanche matin se déroulait la session « Libraries and the semantic Web », que j’ai contribué à organiser, et l’après-midi la session « Development of systems for long-term storage and preservation of library collections » dans laquelle je présentais un article.

Samedi, mis à part une courte (et extrêmement agréable) rencontre avec quelques membres du LLD XG, j’ai consacré la plupart de mon énergie à finir de préparer la journée du lendemain, ce qui incluait la modération de la session du matin, la préparation des différentes copies de mon article pour la traduction simultanée, etc.

La session « Libraries and the Semantic Web », bien que se déroulant un dimanche 15 août à partir de 8h30 (!), a attiré environ 250 personnes, dont la plupart ne dormaient même pas !
Nous avons eu droit à une ouverture riche et éclairante par Richard Wallis, suivie par 6 présentations toutes pertinentes et de haute qualité dont vous retrouverez les textes sur le site de l’IFLA et les présentations sur Slideshare. La session a aussi été assez bien couverte sur twitter (#ifla2010) y compris par votre serviteuse qui twittait depuis la tribune ;-)

La session de l’après midi, consacrée à la préservation numérique, s’est très bien passée aussi. Il y avait environ 120 personnes, ce qui n’est pas mal du tout pour la dernière session de la conférence. Les autres présentations portaient sur le système e-Depot de la KB, et sur Hathi trust. La défection d’un des intervenants a été habilement compensée au pied levé, grâce au brio des animatrices de la session, par une intéressante discussion avec la salle permettant de faire un peu le tour des initiatives en cours.

Et puis c’était la fin : la session de clôture, avec ses récompenses, ses remerciements… et pas son annonce du lieu d’un futur congrès, puisque le lieu du congrès de 2013 ne sera annoncé que l’année prochaine.
Mystère donc !

… Rendez-vous l’année prochaine à Puerto Rico ?

IFLA 2010 – Au jour le jour (3)

La 3e journée de l’IFLA, hier vendredi, a commencé en beauté avec la plénière de Hans Rosling. Il nous a invité à revisiter nos idées reçues sur la répartition du monde entre pays développés et en voie de développement. Sa présentation est disponible sur Vimeo ; je ne peux pas vous dire si ce sera aussi décoiffant qu’en vrai, mais je peux vous garantir que nous avons passé un très bon moment. Vous pouvez également visiter le site Gapminder (nommé d’après la mention sur les quais du métro londonien, « Mind the Gap ») où vous retrouverez ses graphiques de statistiques animées, les vidéos de ses présentations à TED, etc.

Ensuite, en ce qui me concerne, j’ai aligné les réunions des « standing committee » / comités permanents des différentes sections dont les activités m’intéressent.
Ces dernières années, dans l’espoir de réduire la durée du congrès et par là son coût, l’IFLA a décidé de rendre optionnelle la deuxième réunion des comités permanents des sections. En pratique, les sections ont besoin de cette deuxième réunion. Déjà qu’on ne se voit qu’une fois par an, cela ne paraît pas excessif de faire le point une fois au début et une fois à la fin de la semaine, ne serait-ce que pour partager le résultat des travaux qui se sont tenus dans les groupes de travail entre temps. La conséquence c’est que cette deuxième réunion n’apparaît pas dans le programme, et qu’elle se déroule en parallèle des conférences.

Bref. Petit aperçu interne de ce qui se passe dans ces réunions.
Les sections, je crois que je l’ai déjà dit, ont un président (chair) et un secrétaire qui animent la réunion. Les membres (élus) de la section siègent à la table, et les observateurs s’installent en retrait (certaines sections, c’est le cas de la section IT, invitent les observateurs à leur table, ce qui n’est possible évidemment que si on est relativement peu nombreux – impossible donc dans une section comme Catalogage).

La réunion commence généralement par un tour de table ou chacun se présente.
Ensuite, les sujets abordés incluent le rapport des sous-groupes ou groupes de travail, le rapport du trésorier sur le budget de la section, la mise à jour (annuelle en principe) du « strategic plan » de la session, et d’autres sujets administratifs.

Ainsi l’année prochaine sera une année d’élections ; sujet qui a été abordé dans la plupart des réunions auxquelles j’ai assisté. Les élections touchent tous les niveaux de l’IFLA, à savoir de bas en haut :
– les membres des sections : si vous voulez devenir membre d’une section, vous devez demander à votre institution (qui doit être membre de l’IFLA) de proposer votre candidature. Les membres sont élus pour 4 ans en deux fois (par exemple, dans l’IT section, certains membres ont été élus pour 2007-2011, et d’autres pour 2009-2013 ; de cette façon tous les membres ne risquent pas de changer en même temps.) Ce processus aura lieu vers le mois d’octobre ; les nouveaux membres siègeront pour la 1e fois à Puerto Rico l’année prochaine.
– les officiers des sections : le président, le secrétaire, le trésorier et le responsable de l’information (qui s’occupe notamment de la Newsletter de la section). Ils doivent être membres de la section et sont élus dans leurs fonctions pour 2 ans. Ils bénéficient d’une formation spécifique, assurée par l’IFLA pendant le congrès.
– les responsables des divisions : l’IFLA a été réorganisée l’année dernière et compte maintenant 5 grandes divisions qui regroupent les sections. Les divisions ont chacune un président qui siège de droit au comité professionnel et au governing board.
– Le comité professionnel et le governing board sont les groupes qui pilotent l’IFLA. Le governing board compte, en plus des membres de droits (les présidents des divisions, le président du comité professionnel, etc.), dix membres directement élus parmi les membres des sections. Le président du comité professionnel est aussi élu. Toutes ces fonctions sont concernées par les élections de l’année prochaine.
– Enfin, le (ou la) président(e) de l’IFLA : il est élu pour 2 ans, mais en décalage 2 ans avant son terme (c’est un peu compliqué). Il prend alors le titre de « president-elect » en attendant que le président précédent termine son terme. Actuellement Ellen Tise est présidente, et Ingrid Parent est « president-elect ». Donc l’année prochaine, Ingrid Parent sera présidente, et un nouveau président-elect sera élu.
Je sais, c’est horriblement compliqué ; mais enfin, il m’a fallu deux ans pour recoller tout cela ensemble, donc j’ai pensé que ça pouvait être utile si je partageais. Il faut savoir qu’on peut très bien vivre à l’IFLA en n’ayant qu’une connaissance minimale de tous ces processus (si on n’est pas officier). Les gens se soucient donc assez peu de vous l’expliquer quand vous débarquez.

Pour en finir avec les comités permanents des sections, un des sujets qui les occupe est la préparation des conférences de l’année suivante, et éventuellement l’organisation des conférences satellites.
Chaque section a en principe un créneau de 2h dans la conférence, mais elles peuvent se grouper et ainsi démultiplier leur temps (comme nous l’avons fait cette année avec la session « Libraries and Semantic Web »).
A Puerto-Rico en 2011, il y aura un satellite sur RDA organisé en collaboration avec le JSC. De notre côté, nous aimerions organiser un événement sur le Web sémantique en 2012 (le congrès aura lieu à Helsinki). Du travail en perspective !

Après tout ça, nous avions bien mérité le délicieux dîner informel de la section IT, que nous avons pris dans un restaurant suédois sur Kungsportavenyn, et la soirée dansante (un autre événement très fameux de l’IFLA : quand les bibliothécaires se mettent à danser…) qui nous a gardés en mouvement jusque tard dans la nuit.