KBART: Bases de connaissances et

outils associés

Rapport préparé par le groupe de travail NISO/UKSG KBART

Janvier 2010

Traduction en français assurée par : Thomas Porquet (thomas.porquet@couperin.org)

Karine Delvert (karine.delvert@univ-paris1.fr) Juin/Juillet 2011

Warning : This translation has been provided as a service to the French-speaking community by Couperin and any errors are our sole responsibility. Please see the original document at http://www.uksg.org/sites/uksg.org/files/KBART_Phase_I_Recommended_Practice.pdf and http://www.niso.org/publications/rp/RP-2010-09.pdf for the NISO/UKSG approved version. Avertissement : Couperin met a disposition cette traduction pour la communauté francophone et toute erreur ou inexactitude résiduelle relève de sa seule responsabilité. Vous pouvez consulter la version originale du document sur http://www.uksg.org/sites/uksg.org/files/KBART_Phase_I_Recommended_Practice.pdf et la version approuvée par le NISO/UKSG sur http://www.niso.org/publications/rp/RP-2010-09.pdf

1. Préface..............................................................................................................................4

1.1. Le groupe de travail KBART.....................................................................................4 1.2. Périmètre et objectifs ................................................................................................5 1.3. Les membres du comité thématique NISO...............................................................5 1.4. Les membres du comité principal de l’UKSG ...........................................................5 1.5. Les membres du groupe de travail NISO/UKSG KBART .........................................6

2. Résumé des recommandations ........................................................................................7 3. Terminologie de base........................................................................................................7 4. OpenURL et les bases de connaissances : une vue d’ensemble .....................................9

4.1. Retour sur OpenURL – Pourquoi ? Comment ? .......................................................9 4.2. Pourquoi les bases de connaissances sont importantes........................................10 4.3. La chaine d’approvisionnement OpenURL : les rôles et les avantages .................11

4.3.1. Les fournisseurs de contenus.........................................................................12 4.3.2. Les fournisseurs de résolveurs de liens .........................................................13 4.3.3. Les bibliothèques............................................................................................14

5. Aperçu des problèmes rencontrés dans la chaîne de traitement des bases de connaissances........................................................................................................................15

5.1. le périmètre de KBART...........................................................................................15 5.2. Exemples de cas où les données sont inexactes ...................................................16

5.2.1. Les problèmes d’identifiants incohérents........................................................16 5.2.2. Les problèmes de titres incohérents...............................................................16 5.2.3. Les couvertures temporelles incorrectes ........................................................17 5.2.4. Les formats de dates incohérents...................................................................17 5.2.5. Les problèmes de description de la couverture des contenus........................18 5.2.6. Les problèmes de périodes d’embargo ..........................................................18 5.2.7. Le format et l’échange des données...............................................................18 5.2.8. Les données de contenus obsolètes ..............................................................19 5.2.9. Le manque de personnalisation......................................................................19

6. Recommandations pour un échange efficace de métadonnées avec les bases de connaissances........................................................................................................................20

6.1. La transition vers KBART .......................................................................................20 6.2. L’échange ...............................................................................................................21

6.2.1. La méthode d’échange ...................................................................................21 6.2.2. La fréquence des échanges ...........................................................................21 6.2.3. Les responsables à contacter.........................................................................21

6.3. Les données ...........................................................................................................22 6.3.1. Le format des données ...................................................................................22 6.3.2. Les champs de renseignements.....................................................................23

6.3.2.1. Les champs et leurs désignations...............................................................23 6.3.2.2. Le titre de la publication (publication_title)..................................................24 6.3.2.3. Identifiant du format papier (ex : ISSN, ISBN, etc.) (print_identifier) ..........24 6.3.2.4. Identifiant du format électronique (ex : eISSN, eISBN, etc.) (online_identifier) .........................................................................................................25 6.3.2.5. Date du premier numéro disponible en ligne (date_first_issue_online) ......25 6.3.2.6. Numéro du premier volume disponible en ligne (num_first_vol_online) .....25 6.3.2.7. Premier numéro disponible en ligne (num_first_issue_online) ...................25

2

6.3.2.8. Date du dernier numéro disponible en ligne (ou vide, si la couverture s’étend jusqu’à ce jour) (date_last_issue_online)........................................................26 6.3.2.9. Numéro du dernier volume disponible en ligne (ou vide si la couverture s’étend jusqu’à ce jour) (num_last_vol_online) ...........................................................26 6.3.2.10. Numéro du dernier numéro disponible en ligne (ou vide si la couverture s’étend jusqu’à ce jour) (num_last_issue_online)........................................................26 6.3.2.11. URL du titre (title_url)..............................................................................26 6.3.2.12. Auteur principal (pour les monographies) (first_author)..........................26 6.3.2.13. Identifiant du titre (title_id).......................................................................26 6.3.2.14. Embargo (embargo_info) ........................................................................27 6.3.2.15. L’étendue de la couverture (coverage_depth) ........................................28 6.3.2.16. Les notes de couverture (coverage_notes) ............................................29

6.3.3. Le rapport d’erreurs ........................................................................................29 7. Le matériel pédagogique.................................................................................................30

7.1. La plateforme en ligne ............................................................................................30 7.1.1. Un guide de bonnes pratiques........................................................................30 7.1.2. Une Foire Aux Questions................................................................................30 7.1.3. Un Glossaire ...................................................................................................30 7.1.4. Des modes d’emploi cours et des fiches récapitulatives ................................30 7.1.5. Des démonstrations vidéo ..............................................................................31 7.1.6. Des études de cas ..........................................................................................31

7.2. Sensibilisation.........................................................................................................31 7.3. Exemples de FAQ ..................................................................................................31

7.3.1. Questions générales.......................................................................................31 7.3.2. Les questions des éditeurs et fournisseurs de contenu..................................31 7.3.3. Les questions des bibliothécaires...................................................................32

7.4. Recommandations pour l’amélioration des liens ....................................................33 8. Les prochaines étapes / Phase II....................................................................................35

8.1. Les recommandations et discussion plus poussée ................................................35 8.1.1. Les différences entre les agrégateurs et les fournisseurs de contenus individuels .......................................................................................................................35 8.1.2. Les défis des collections consortiales.............................................................36 8.1.3. Le transfert de métadonnées propres aux établissements .............................36 8.1.4. Le transfert de métadonnées de contenu non-textuel ....................................36 8.1.5. Passage en revue des métadonnées pour le transfert des e-books...............36 8.1.6. L’échange de données pour les ERMS ..........................................................36 8.1.7. Conformité avec les recommandations KBART .............................................37

9. Appendice A....................................................................................................................38 9.1. Echantillon d’un fichier d’échange ..........................................................................38

10. Glossaire .....................................................................................................................41 10.1. Bibliographie...........................................................................................................46

3

1. Préface

1.1. Le groupe de travail KBART En 2007, l’UKSG1, une association qui regroupe et relie les acteurs du monde de l’information, commandite un rapport qui s’intitule “Link Resolvers and the Serials Supply Chain”2. Ce rapport identifie et décrit un ensemble de problèmes affectant l’efficacité du mécanisme de liens OpenURL. Le rapport préconise (dans le chapitre 7.1.1) la création d’un groupe de travail chargé d’élaborer et de promouvoir des bonnes pratiques qui permettraient à la communauté dans son ensemble d’améliorer les échanges de métadonnées avec les bases de connaissances. En lien avec le NISO3, l’UKSG met alors en place d’un groupe de travail qui rassemble des membres issus des différentes composantes de la chaine d’alimentation des données relatives aux ressources électroniques afin de traiter les problèmes identifiés dans le rapport de l’UKSG, d’élaborer des directives et de proposer des solutions. Le groupe de travail conjoint NISO/UKSG KBART4 (bases de connaissance et outils associés) a été mis en place en décembre 2007 et le présent guide de bonnes pratiques est le fruit de cette étape initiale de travail. Les informations concernant le fonctionnement du groupe et sa composition sont données dans la Préface. La formation d’un groupe de travail KBART a été largement diffusée par l’UKSG et le NISO afin d’inciter les représentants des différents acteurs de la chaine de fourniture d’information à manifester leur intérêt pour cette initiative. Une cinquantaine de personnes s’est manifestée. Les co-directeurs du groupe de travail, nommés par les comités directeurs de l’UKSG et du NISO, ont choisi 12 membres pour constituer le groupe de travail principal afin de représenter de façon équitable les parties prenantes au sein de la chaine de fourniture d’information (voir la liste des membres infra). Les personnes ayant manifesté leur intérêt sans pour autant faire partie du groupe de travail, ont été invitées à prendre part au Monitoring Interest group (comité de suivi). Ce groupe a reçu des comptes-rendus réguliers des activités du groupe de travail et a eu pour mission de contribuer à l’évaluation de ce guide de bonnes pratiques avant sa publication. Le groupe de travail s’est réuni tous les mois, par conférence téléphonique, entre décembre 2007 et décembre 2009. Les membres ont été répartis en sous-groupes, qui se sont vus confier du travail sur un domaine spécifique du rapport. La progression des activités de

1 UKSG est l'acronyme de “United Kingdom Serials Group” 2 Culling, J. Link Resolvers and the Serials Supply Chain. Oxford: Scholarly Information Strategies, 2007. Available at http://www.uksg.org/projects/linkfinal trad. “Résolveurs de liens et chaine d’alimentation des données concernant les périodiques” 3 NISO est l'acronyme de « National Information Standards Organization », association à but non lucratif accréditée par l'ANSI (American National Standards Institute) 4 KBART est l'acronyme de « Knowledge Bases And Related Tools» et peut être traduit par « Bases de Connaissance et Outils Associés »

4

chaque sous-groupe a fait l’objet d’un rapport mensuel à l’ensemble du groupe de travail afin de discuter des activités en cours et établir des priorités.

1.2. Périmètre et objectifs Le périmètre de travail du groupe NISO/UKSG KBART est centré sur les problèmes de la chaine d’informations relative à la fourniture de données à des bases de connaissance. Cela exclut notamment des problèmes plus larges touchant la création de liens OpenURL, qui relèvent soit de l’OCLC5, de l’agence de maintenance de la norme OpenURL (ANSI/NISO Z39.88-2004, The Open URL Framework for Context Sensitive Services) soit d’autres groupes de travail NISO. Le groupe s’est également particulièrement concentré sur les données relatives aux portefeuilles de titres plus que sur les données bibliographiques relatives à des titres individuels, qui ne nécessitent pas des mises à jour aussi régulières que les données de portefeuilles. L’objectif du groupe KBART est d’améliorer la chaine d’alimentation des données des résolveurs de liens et des bases de connaissance afin de perfectionner leur fonctionnement et d’augmenter l’efficacité du processus de construction de liens OpenURL. Ces objectifs pourront être atteints via la fourniture de guides de bonnes pratiques, de matériel pédagogique, par l’organisation d’événements et par l’alimentation d’un portail d’échanges communautaires destiné à tenir le rôle d’un centre de ressources sur les bases de connaissance.

1.3. Les membres du comité thématique NISO Les membres du comité thématique NISO intitulé “Discovery to Delivery”6 étaient les suivants lorsque le comité a approuvé les recommandations du présent document : Susan Campbell - College Center for Library Automation Larry Dixson - Library of Congress David Fiander - University of Western Ontario Mary Jackson - Auto-Graphics John Law - ProQuest Tony O’Brien (Co-Chair) - OCLC Norman Paskin - Tertius Ltd Matt Turner - Mark Logic Corporation Tim Shearer (Co-Chair) - University of North Carolina

1.4. Les membres du comité principal de l’UKSG Les membres du comité principal de l’UKSG étaient les suivants lorsque les recommandations du présent document ont été approuvées par ce comité : Beverley Acreman - Taylor & Francis Jo Connolly - Swets Lesley Crawshaw - University of Hertfordshire

5 Online Computer Library Center 6 trad. “de la découverte à la fourniture de documents”

5

Richard Gedye - Oxford University Press Claire Grace - The Open University Ian Hames - ebrary, inc Helen Henderson (Editor, Serials) - Ringgold Ltd Tony Kidd (Chair) - University of Glasgow Ross MacIntyre - Mimas, The University of Manchester Sarah Pearson - University of Birmingham Ed Pentz (Treasurer) - CrossRef Kate Price (Education Officer) - University of Surrey Charlie Rapple (Marketing Officer) - TBI Communications Graham Stone (Secretary) - University of Huddersfield Jill Taylor-Roe - University of Newcastle Diane Thomas - Gale Cengage Learning EMEA Hazel Woodward (Editor, Serials) - Cranfield University

1.5. Les membres du groupe de travail NISO/UKSG KBART

Les personnes suivantes ont participé au groupe de travail KBART du NISO/UKSG. Elles ont conçu et approuvées les recommandations du présent document : Phil Caisley - BMJ Group Adam Chandler - Cornell University Library Anna Gasking - Informa plc Simon Haggis - BMJ Group Nettie Lagace - Ex Libris Group Peter McCracken (Co-Chair, representing NISO) - Serials Solutions Chrissie Noonan - Pacific Northwest National Laboratory Sarah Pearson - University of Birmingham Oliver Pesch - EBSCO Industries Inc Jason Price - Claremont Colleges / Statewide California Electronic Library Consortium Charlie Rapple (Co-Chair, representing UKSG) - TBI Communications Elizabeth Stevenson - University of Edinburgh Margery Tibbetts - California Digital Library Thomas P. Ventimiglia - Princeton University Jenny Walker - Consultante

6

2. Résumé des recommandations Un résolveur de liens est un outil qui aide les usagers à accéder aux ressources électroniques de leur institution. Les données qui servent de bases à un tel outil sont stockées dans une base de connaissances. La qualité d'une base de connaissances repose en grande partie sur les données que les fournisseurs de contenu (éditeurs, agrégateurs, etc.) fournissent aux développeurs de la base de connaissances. Les erreurs contenues dans ces données se retrouvent souvent dans la base de connaissances. En outre, du fait de l’absence de norme pour ce type de données, les développeurs de base de connaissances doivent consacrer beaucoup d'efforts à convertir les listes de titres des différents fournisseurs en un seul et même format, ce qui peut à son tour être la cause de nouvelles erreurs et rendre le pistage de ces erreurs difficile. Les recommandations faites dans le présent document détaillent les bonnes pratiques pour le formatage et la diffusion de listes de titres. En effectuant quelques ajustements au format de leurs listes de titres, les producteurs de contenus peuvent grandement améliorer l’accessibilité de leurs produits. Ces recommandations sont conçues pour être intuitives, faciles à mettre en oeuvre pour les producteurs de contenus, et faciles à traiter pour les développeurs de bases de connaissances.

• La partie 2 fournit la terminologie de base, nécessaire pour comprendre les bonnes pratiques ; un glossaire complet est proposé en plus à la fin de ce document.

• La partie 3 donne un bref aperçu de la résolution de lien OpenURL, des bases de connaissances, et de la chaîne d'information qui les englobe.

• La partie 4 identifie quelques problèmes types rencontrés dans les bases de connaissances, leur causes, et leurs conséquences pour l’utilisateur.

• La partie 5 détaille un ensemble de solutions et de bonnes pratiques qui vous permettront d'éviter ces problèmes.

• La partie 6 explique le rôle que KBART envisage d’endosser pour soutenir l'adoption de ces pratiques.

• La partie 7 propose quelques directions dans lesquelles le travail de KBART peut s’engager à l'avenir.

3. Terminologie de base Pour aider les lecteurs à comprendre la terminologie utilisée dans ce rapport, un glossaire exhaustif est proposé à la fin de ce document. On fournit dès à présent une partie des termes importants et leur définition parce qu’ils seront largement utilisés dans les pages suivantes. Comprendre ces termes tels qu’utilisés dans le contexte de KBART est essentiel pour bien appréhender ce rapport. Il est à noter que le travail effectué lors de la première phase par le groupe de travail KBART, et dont le fruit est le présent rapport, s’est concentré sur la chaîne de fourniture de données relatives aux contenus textuels tels les périodiques et les e-books. C’est en effet pour ces types de contenus que l’OpenURL est déjà le plus répandu et que, par conséquent,

7

l’essentiel des problèmes survenus à ce jour se sont manifestés. La sélection des termes et des définitions doit être comprise dans ce contexte. Reportez-vous la partie 7 pour plus d'informations sur le travail qu’il est prévu d’accomplir lors de la prochaine phase des travaux. La copie appropriée / Appropriate copy C’est la (ou les) version(s), parmi un ensemble de versions, qui correspond(ent) le mieux aux besoins d’un utilisateur donné (et rattaché à une institution donnée). Cette version sera vraisemblablement celle pour laquelle l’utilisateur dispose d’un accès au texte intégral, parce que la bibliothèque y souscrit. Le fournisseur de contenus / Content provider Un vendeur —généralement un éditeur, un agrégateur ou un hébergeur de texte intégral— qui offre du contenu à la vente ou à la location aux bibliothèques. La notion de fournisseur de contenus peut aussi recouvrir les services de résumé ou d’indexation, des portails d’agences d’abonnements et d’autres sources de liens OpenURL. Les liens entrants (syntaxe) / Inbound linking (syntax) Les liens entrants sont les liens des pages de sites externes créant un lien vers votre site. Un fournisseur de contenus autorise les liens hypertextes entrants si il rend publique une syntaxe de lien qui autorise les autres à prédire l’adresse sur leur site, et ce, à différents niveaux (par exemple : les pages d’accueil de périodiques, les tables des matières, ou des articles spécifiques). La base de connaissances / Knowledge base Une base de données complète tenue à jour par un éditeur de résolveur de liens, et qui contient des informations sur les ressources électroniques telles que : listes de titres, dates de couverture, syntaxe des liens entrants, etc. Les bases de connaissances peuvent être personnalisées par chaque institution en fonction de ses collections locales. Par exemple, quels titres sont consultables en version électronique et lesquels sont détenus par la bibliothèque au format papier. On la nommera alors “base de connaissances locales”. Le résolveur de liens / Link resolver Un "résolveur de liens” ou “serveur de liens”, est un outil logiciel qui analyse une OpenURL, en extrait les éléments qui décrivent un article de périodique donné, et les utilise pour créer un lien prévisible vers le ou les services appropriés, identifiés par la bibliothèque de l'utilisateur. La syntaxe d’un lien /Link-to syntax C’est la formule par laquelle des liens vers des pages spécifiques dans un site Web peuvent être construits. Ces liens sont habituellement constitués d’une adresse hypertexte de base et d’une série de métadonnées et d’identifiants. Certains fournisseurs de contenus respectent la syntaxe OpenURL pour permettre les liens entrants, d’autres basent leur syntaxe sur des identifiants propriétaires mais prévisibles.

8

OpenURL La norme OpenURL (ANSI/NISO Z39.88-2004, The OpenURL Framework for Context-Sensitive Services) détaille la syntaxe pour l’acheminement de métadonnées depuis les ressources informationnelles (les sources) jusqu’au résolveur de liens institutionnel, et de là, jusqu’aux services de la bibliothèque (les cibles). La source C’est la ressource qui crée une OpenURL et, de là, mène à un résolveur de liens. La source peut être un site dans son ensemble (par exemple une base de données, la plateforme d’un éditeur, etc.) ou une référence bibliographique donnée, sur ce site. La cible / Target C’est la ressource à laquelle on accède via un résolveur de liens. Les cibles typiques sont les contenus proposés par les plateformes des éditeurs, les catalogues d’un établissement, ou les archives et portails de contenus.

4. OpenURL et les bases de connaissances : une vue d’ensemble

La version 0.1 d’OpenURL est apparue en 1999; cette version est devenue une norme NISO (ANSI/NISO Z39.88-2004, The OpenURL Framework for Context-Sensitive Services) en 2004. OpenURL a été adopté par tous les acteurs de la chaine d’alimentation d’information scientifique pour améliorer le rebond entre ressources. Un certain nombre de fournisseurs a développé des outils qui fournissent une implantation efficace d’OpenURL, et les résolveurs de liens (soit produits commerciaux sous licence, soit produits maison) sont devenus un élément essentiel de la boîte à outils d’une bibliothèque de recherche.

4.1. Retour sur OpenURL – Pourquoi ? Comment ? Créer un lien vers une référence impliquait traditionnellement de coder “en dur” les liens entre un fournisseur de contenus et un autre. Les utilisateurs se trouvaient alors fréquemment renvoyés vers la "mauvaise" version d'un article, c’est à dire une version à laquelle ils n’étaient pas autorisés à accéder selon les termes de la licence. Dans le pire des cas, l’utilisateur commandait ou payait pour le consulter un article auquel sa bibliothèque avait droit. C'est ce qu'on appelle le problème de la "copie appropriée". OpenURL a été développé pour permettre la création de liens qui tiennent compte du contexte, c’est-à-dire des liens flexibles et capables de prendre en compte les affiliations institutionnelles de l'utilisateur et les licences de cette institution. Suite à la normalisation ANSI / NISO, les liens OpenURL ont été largement adoptés. Le parcours simple d’un d'utilisateur qui utilise OpenURL est illustré par la figure 1.

9

Figure 1 : Le parcours d’un utilisateur via un lien OpenURL

OpenURL utilise un résolveur de liens (L) pour mener l’utilisateur de A (une référence bibliographique) à Z (une version du document cité, à laquelle l'utilisateur courant est autorisé à accéder), par le biais d'une requête OpenURL (Q), ce qui concatène une chaine (S) de métadonnées relatives à l'article référencé à l’URL de base (B) de l'institution (I) à laquelle l'utilisateur courant est rattaché. C'est une solution plus efficace que celle des liens codés en dur vers d'autres ressources, telles que les portails d’agences d'abonnements (G), le fonds papier de la bibliothèque (P), les bases de données agrégées (D), les sites Web d’éditeurs (W), ou les dépôts (R).

4.2. Pourquoi les bases de connaissances sont importantes

Les bases de connaissances sont essentielles dans le processus de construction des liens OpenURL, car non seulement elles savent où les contenus se trouvent, mais elles savent aussi pour quelles versions d'objets spécifiques les utilisateurs d’une institution ont un droit d'accès. Les bases de connaissances sont le seul moyen grâce auquel les utilisateurs peuvent être sûrs de parvenir à une "copie appropriée". Si les données fournies aux bases de connaissances sont incomplètes, inexactes, périmées ou incorrectes pour tout autre raison, l'efficacité de la norme OpenURL est compromise à tel point qu’elle devient souvent inutile. En conséquence, le groupe de travail NISO / UKSG KBART a été créé pour analyser les problèmes au sein de la chaine d'approvisionnement et de créer des lignes directrices pour résoudre les problèmes les plus fréquents ou dont les conséquences sont les plus dommageables. Tandis que le groupe KBART se concentre sur l’échange de données à l’intérieur de et entre les bases de connaissances, il est reconnu que l’insertion et l’encodage correct de données dans les liens OpenURL sont également cruciaux dans leur bon fonctionnement.

10

4.3. La chaine d’approvisionnement OpenURL : les rôles et les avantages

La chaine d'approvisionnement OpenURL comprend de nombreuses interconnexions entre les acteurs qui y participent. Chacun a des responsabilités spécifiques en ce qui concerne les données qu'il partage avec les autres. Les responsabilités de transfert de données des acteurs dans la chaine d'approvisionnement OpenURL sont représentées dans la figure 2.

Figure 2 : le parcours des données dans la chaine d’approvisionnement OpenURL

L'auteur fournit des manuscrits à l'éditeur (1). L'éditeur envoie le texte complet de l'article final et des métadonnées associées à un ou plusieurs services de livraison en ligne (les hébergeurs de contenu, les bases de données de texte intégral, les sites d'archives, etc.) (2). L'hébergeur de contenu est souvent responsable de la mise à disposition des métadonnées d’un article auprès d’autres outils de découverte, tels que les bases de données de résumés et d'indexation, les plateformes d’agences d'abonnement, et les moteurs de recherche (3). Les hébergeurs de contenu et les bases de données en texte intégral fournissent également des informations sur les bouquets, et parfois également des notices MARC, aux développeurs de base de connaissances (4) ou directement à l'institution (5) afin d'informer ces systèmes sur l'étendue du contenu disponible. Des services de la base de connaissances enverront alors les données sur l’état des collections aux listes A-to-Z institutionnels et aux résolveurs de liens (6), l'institution utilise ces informations pour paramétrer sa propre collection. Les développeurs de base de connaissances peuvent également envoyer des notices MARC, à l'institution pour qu’elles soient versées dans l'OPAC institutionnel (7). Dans ce scénario, l'établissement doit fournir à son développeur de base de connaissances des détails sur ses collections pour des contenus tels que les revues électroniques, etc. (8). Nous tentons ici de décrire les responsabilités attendues de chaque acteur de la chaine d’approvisionnement et d’identifier les zones dans lesquelles les confusions ou inexactitudes peuvent surgir. Ce faisant, nous nous efforçons de décrire quelles pourraient être les responsabilités de chacune des parties impliquées ici.

11

Dans le cas le plus simple, les intervenants dans la chaine d'approvisionnement OpenURL (les fournisseurs de contenus, les fournisseurs de résolveurs de liens, et les bibliothèques) sont tenus d’effectuer les tâches suivantes, et dans une chaine d'approvisionnement efficace, en tireraient les avantages décrits.

4.3.1. Les fournisseurs de contenus Ceux que nous nommons fournisseurs de contenus sont, entre autres, les éditeurs, les fournisseurs d’accès en ligne, les plateformes d’agences de souscription, les agrégateurs de texte intégral. L’essentiel des métadonnées, ainsi que du contenu, provient des éditeurs. Le plus souvent, les métadonnées transmises lors des étapes antérieures proviennent de l’éditeur. Si ces métadonnées sont incorrectes à la source, elles le resteront potentiellement tout au long de la chaine d’approvisionnement. Leur rôle : Les fournisseurs de contenus peuvent être à la fois une source et une cible pour les liens openURL. L’adhésion à la norme OpenURL implique, pour un fournisseur de contenus d’être en mesure de créer des liens OpenURL conformes à leurs références bibliographiques. Pour que les autres sources OpenURL puissent être en mesure de créer des liens vers lui, un fournisseur doit également mettre à leur disposition des métadonnées précises décrivant ses collections électroniques. Actuellement, il n'existe pas de format standard pour de telles données. Une partie de la mission KBART est de créer des recommandations, des bonnes pratiques, dans ce domaine. Leurs Fonctions :

● Fournir des articles —avec des métadonnées adéquates— aux fins de publication ou d'hébergement

● Recevoir du contenu en texte intégral de la part des éditeurs ● Créer des métadonnées au niveau du texte intégral ou du résumé ● Héberger du texte intégral et fournir des fonctionnalités associées pour le compte des

éditeurs ● Créer des liens OpenURL ● Transmettre toutes leurs listes de contenus aux développeurs de bases de

connaissances ● Envoyer aux bibliothèques la liste de leurs collections (pour leur exploitation locale) ● Fournir des notices MARC aux bibliothèques

Les avantages attendus : La transmission en temps voulu de métadonnées correctes aux fournisseurs de résolveurs de liens est bénéfique aux fournisseurs de contenus sur plusieurs plans. Créer pour l’utilisateur une expérience de navigation fluide réduit le coût de l’assistance technique, améliore la réputation du fournisseur et augmente le trafic vers les contenus. L'augmentation du trafic soutient à la fois l'éditeur, le rédacteur en chef. Elle remplit aussi l'objectif de l'auteur d'assurer à sa production une visibilité, une utilisation et une portée maximale. Cela peut également soutenir les flux de revenus basés sur les usages, ce qui est un facteur clé dans les décisions d'achat lorsque les bibliothèques renouvellent ou annulent leurs contrats d’accès aux contenus sous licence.

12

Les clés pour le succès d’une base de connaissances : ● S’assurer que les données qui décrivent les contenus sont correctes et transmises

selon un planning régulier aux possesseurs de résolveurs de liens, et que les erreurs identifiées sont corrigées le plus rapidement possible.

4.3.2. Les fournisseurs de résolveurs de liens Leur rôle : Les résolveurs de liens sont configurés pour recevoir les liens OpenURL à partir de sources provenant des fournisseurs de contenus. Les résolveurs extraient les métadonnées relatives à l’article cible (ou d’un autre objet) du lien OpenURL puis comparent ces informations à la base de connaissances, qui contient des données sur l’ensemble du contenu sous licence du propriétaire du résolveur de liens. La base de connaissances indique si l'article est disponible pour les individus associés à l'institution détentrice de la licence. Si c’est le cas elle indique où il est hébergé, et le moyen pour l’utilisateur d’y accéder. Le résolveur de liens reconstruit alors un lien vers l'article cible. Ce processus est en grande partie transparent pour l'utilisateur. Le fournisseur d’un résolveur de liens a la charge de la technologie du résolveur, des données de la base de connaissances globale et crée ou contribue à la constitution de la base de connaissances locale. Leurs fonctions :

● Recevoir régulièrement des listes de contenus actualisées de la part des fournisseurs pour leur normalisation, leur traitement et leur ajout dans la base de connaissances globale

● Recevoir les détails des syntaxes des liens entrants des fournisseurs de contenus pour les associer aux informations sur les collections pour les cibles des liens

● Donner les moyens aux fournisseurs de contenus de tester leurs liens OpenURL et fournir leurs métadonnées

● Sensibiliser les fournisseurs de contenus à l’attention qu’ils doivent porter aux URL des résolveurs de liens des fournisseurs

● Vérifier (et éventuellement renseigner) le taux de soutien à la norme OpenURL ● Générer et diffuser des notices MARC pour le fonds de la bibliothèque

Les avantages attendus : La transmission en temps voulu de métadonnées correctes aux résolveurs de liens et la bonne communication entre les acteurs (fournisseur de résolveur, bibliothèque, fournisseur de contenus) doit permettre au fournisseur du résolveur d’offrir un service plus fiable et à jour. Il remplira ainsi sa fonction consistant à donner accès à du contenu sous licence. La transmission en temps voulu de métadonnées correctes réduira aussi les coûts associés à la vérification, au nettoyage et à la maintenance des données contenues dans la base de connaissances. Les clés pour le succès d’une base de connaissances :

● Veiller à ce que la base de connaissances soit régulièrement mise à jour et incorpore des corrections fournies par d'autres membres de la chaine d'approvisionnement.

13

4.3.3. Les bibliothèques La bibliothèque, qui propose l’information à l’utilisateur final, joue un rôle important en s’assurant que la présentation des métadonnées est correcte et utilisable. Ce sont la bibliothèque et l’utilisateur final qui sont les plus à-même de détecter les erreurs dans les données OpenURL ou dans les données de références bibliographiques, et qui sont donc les mieux placés pour les signaler aux autres acteurs de la chaine d’approvisionnement. Les bibliothèques développent elles-mêmes ou achètent des résolveurs de liens afin d’optimiser l'accès à l’ensemble des ressources électroniques pour lesquelles elles ont la licence. Une bibliothèque enregistre auprès des fournisseurs de contenus les informations-clé nécessaires à son identification afférentes à son résolveur de liens (tels que l'URL de base). Elle sélectionne les fournisseurs pour constituer une source de liens OpenURL. Chaque bibliothèque devra personnaliser la base de connaissances consultée par son résolveur de liens afin de refléter son propre fonds papier et en ligne. Les avantages attendus : Le déploiement efficace d’un résolveur de liens présente plusieurs intérêts : il permet d’améliorer l'utilisation (et donc le retour sur investissement) des contenus sous licence, de rendre plus aisées les recherches des utilisateurs et d’augmenter le taux d’accès réussis au contenu. Les utilisateurs solliciteront moins les services d’assistance. La transmission en temps voulu des métadonnées correctes du fonds réduira également les coûts actuels et la charge de travail impliqué dans la vérification, le nettoyage et l'entretien des données de la base de connaissances. Leurs fonctions :

● Recevoir et déployer les mises à jour pour la base de connaissance à intervalle régulier

● Paramétrer précisément le résolveur de liens de la bibliothèque pour chaque fournisseur de contenus

● Lorsque le résolveur de liens est hébergé par le développeur de la base de connaissances, lui fournir les données des collections du fonds pour permettre la personnalisation de la base de connaissances

● Activer les cibles des liens dans la base de connaissances du fournisseur du résolveur de liens. La bibliothèque doit établir des états de collections détaillés afin de mettre à jour la base de connaissances. La mise à jour se fait manuellement à l'aide des outils fournis par le fournisseur du résolveur de liens et, le cas échéant, en personnalisant la liste des collections fournies par le fournisseur d’accès en ligne.

● Signaler au fournisseur du résolveur de liens les données inexactes de la base de connaissances

Les clés pour le succès d’une base de connaissances :

● Fournir des données correspondant aux collections locales pour personnaliser la base de connaissances.

14

5. Aperçu des problèmes rencontrés dans la chaîne de traitement des bases de connaissances

5.1. le périmètre de KBART L'objectif du lien OpenURL est de donner aux utilisateurs qui en ont la permission un accès aux ressources. Des problèmes simples peuvent nuire au bon fonctionnement de cette technologie :

● Manque d'adoption de la technologie OpenURL de la part de certains fournisseurs ● Mauvaise qualité des métadonnées contenues dans les bases de connaissances ● Mise en oeuvre incorrecte de la syntaxe OpenURL dans les liens OpenURL sources ● Mauvaise syntaxe des liens entrants dans les liens OpenURL cibles

Le champ de compétence de KBART comprend l’évaluation des problèmes qui résultent ou se rapportent aux données fournies aux bases de connaissances (cf. les deux premiers points de la liste ci-dessus). Le présent document ne tient pas compte des problèmes qui résultent ou se rapportent à la mise à jour de la documentation de la norme OpenURL, car cette norme se trouve sous la responsabilité de l’organisme en charge de la maintenance de la norme OpenURL, actuellement l’OCLC7. L’OCLC anime la communauté OpenURL au moyen d'une liste de diffusion8 qui favorise la discussion et sert de forum dans lequel la communauté peut soumettre les problèmes rencontrés. Les détails de l’annuaire pour le framework OpenURL sont disponibles sur http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=Identify. Toutefois, parallèlement aux recommandations du présent document qui concernent le transfert des métadonnées, les fournisseurs de contenu devront également fournir des détails sur la syntaxe de leurs liens aux développeurs de bases de connaissances. Ainsi l'exactitude des liens vers du contenu au niveau des titres, des numéros de revues et des articles sera assurée et les utilisateurs finaux pourront effectivement accéder à un contenu pertinent. Le groupe de travail a identifié les problèmes suivants, relatifs aux métadonnées de mauvaise qualité et concernant des cibles openURL, discutées plus tard dans la section 4.2, comme appartenant au périmètre d’intérêt de KBART :

● 4.2.1 Les problèmes d’identifiants incohérents ● 4.2.2 Les problèmes de titres incohérents ● 4.2.3 Les couvertures temporelles incorrectes ● 4.2.4 Les formats de dates incohérents ● 4.2.5 Les problèmes de description de la couverture des contenus ● 4.2.6 Les incohérences des périodes d’embargo ● 4.2.7 Le format et l’échange des données ● 4.2.8 Les données de contenus obsolètes ● 4.2.9 Le manque de personnalisation

7 http://www.oclc.org/research/activities/openurl/default.htm 8 openurl@oclc.org

15

5.2. Exemples de cas où les données sont inexactes Dans ce chapitre, nous illustrons les modalités selon lesquelles les usagers sont directement touchés par une mauvaise gestion des données dans la chaîne de traitement de la base de connaissances. Nous tentons de fournir des solutions indicatives ; les recommandations complètes pour les bonnes pratiques sont données au chapitre 6, intitulé “Recommandations pour un échange efficace de métadonnées avec les bases de connaissances”.

5.2.1. Les problèmes d’identifiants incohérents Le problème central : la réutilisation de l’ISSN (par exemple quand un périodique change de titre) ou de l’ISBN (par exemple parmi plusieurs titres d’un même éditeur) provoque la confusion du côté du résolveur de liens, étant donné qu’un identifiant supposé être unique ne l’est plus. L’impact sur l’utilisateur : la syntaxe OpenURL utilise l’ISSN unique comme composant clé. Quand une référence bibliographique (i.e. une source) utilise un ISSN exact mais qu’une ressource en texte intégral (c’est-à-dire une cible) utilise un ISSN inexact —tel que celui d’un titre antérieur ou postérieur— le résolveur de liens sera incapable de résoudre l’incohérence et ne pourra pas renvoyer les bons liens vers le contenu cherché. Les Solutions: L'utilisation précise de l'ISSN est indispensable pour assurer une bonne résolution des liens basés sur OpenURL. Le fournisseur de contenus doit veiller à ce que l'ISSN fourni dans le fichier qui alimente la base de connaissances est exact et concerne l'ouvrage décrit. Pour éviter la réutilisation inappropriée de l'ISSN lors de l'attribution d'ISSN aux œuvres nouvelles et changeantes, les éditeurs sont invités à consulter les bonnes pratiques de leurs centres ISSN nationaux9, ou celles de l'organisme ISSN international10. KBART attend également des développeurs de bases de connaissances qu’ils soient prochainement capables de gérer avec succès les ISSN multiples pour un titre donné.En effet, la plupart des titres disponibles en version imprimée et en ligne se voient assigner plusieurs ISSN valides. Ce phénomène est courant et la base de connaissances d’un résolveur de liens doit être en mesure de gérer ce cas proprement.

5.2.2. Les problèmes de titres incohérents Le problème central : Les variantes orthographiques de titres, notamment causées par des fautes de frappe, les variations du titre, ou l'utilisation des titres antérieurs ou postérieurs, aboutissent à des problèmes de correspondance. L’impact sur l’utilisateur : La plupart des résolveurs doivent trouver un moyen de gérer les variations typographiques et la ponctuation, mais ne sont pas forcément en mesure de résoudre les abréviations (par exemple : "NEJM" pour le New England Journal of Medicine), les variations orthographiques régionales (par exemple : “labour” vs. “labor”), ou les nombres écrits comme des mots (par exemple : "1er" ou " premier "). Le résolveur de liens peut 9 par exemple http://www.bl.uk/bibliographic/issn.html ou http://www.loc.gov/issn/ 10 http://www.issn.org

16

échouer à trouver le bon titre —ou même ne serait-ce qu’un titre— quand il tente de résoudre une requête OpenURL. Et l'utilisateur ne pourra pas atteindre le contenu qu'il recherche. Les Solutions: Une bonne pratique consiste à ce que tous les systèmes utilisent une forme du titre qui apparaît comme un titre principal dans une source de catalogage standard, tels que le CONSER11, la base de données OCLC WorldCat, ou le registre ISSN. Si aucune de ces ressources ne contient d’entrée pour ce titre, ce dernier doit être reproduit tel qu'il apparaît sur la couverture de l'édition papier. En outre, les bases de connaissances devraient bientôt être en mesure de gérer les variantes de titres au sein de leur système.

5.2.3. Les couvertures temporelles incorrectes Le problème central : La présentation de dates inexactes par les fournisseurs de contenus, ou le défaut de mise-à-jour des dates dans la base de connaissances par les développeurs, renvoie des résultats inexacts ou des liens invalides dans le résolveur de liens. L’impact sur l’utilisateur : Certains usagers peuvent se voir signifier que la ressource qu'ils cherchent n'est pas disponible alors qu’elle l’est (par exemple si le fichier n'a pas été mis à jour et ne contient pas les numéros les plus récents mis en ligne) ou qu'une ressource est disponible quand elle ne l’est pas (par exemple si le contenu a été retiré, mais qu’il figure encore dans la liste des collections). Dans le premier cas, les utilisations considérées comme valides diminueront, dans le second, les usagers finiront par se détourner de la ressource cherchée si chaque tentative d’y accéder se solde par un échec. Les Solutions: Les fournisseurs de contenus fourniront en temps voulu des fichiers d’état de collections qui comportent des dates de couvertures ; les propriétaires d’un résolveur de liens s'assureront quant à eux qu'ils traitent ces fichiers correctement et rapidement.

5.2.4. Les formats de dates incohérents Le problème central : Sans format standard, les dates de couverture peuvent être interprétées de manière incorrecte. Par exemple, “20080305” signifie-t-il 5 mars 2008 ou 3 mai 2008 ? L'existence de plusieurs dates pour un article (par exemple, la date de la mise en ligne et la date de la publication du numéro, lorsque celles-ci diffèrent) peut également empêcher la mise en relation entre une référence bibliographique et la base de connaissances. L’impact sur l’utilisateur : Des informations inexactes concernant la date empêchent la base de connaissances d’associer la référence bibliographique de la source à une ressource cible, ce qui empêche à leur tour les utilisateurs finaux d'accéder aux ressources, causant déception et diminution de l’usage.

11 Le CONSER est un programme coopératif de catalogage de périodiques en ligne dont la base de données est intégrée dans le catalogue en ligne de l’OCLC. Plus de détails sur : http://www.loc.gov/acq/conser/

17

Les Solutions : Le fournisseur de contenu utilisera la syntaxe de dates décrite dans la version la plus récente de la norme ISO 8601:2004 (Data elements and interchange formats – Information interchange – Representation of dates and times) lors de l'interprétation et l'affichage des plages de dates.

5.2.5. Les problèmes de description de la couverture des contenus

Le problème central : Certains fournisseurs n’offrent pas l’intégralité de la version papier quand ils la publient en ligne. Il arrive aussi que les éditeurs ne fournissent qu’un contenu partiel aux agrégateurs. En conséquence, certains articles entiers manquent, même s’ils sont déclarés dans l’étendue des collections. Dans d'autres cas, le contenu agrégé à partir de plusieurs sources est représenté complètement au niveau du titre et comprend tout le texte, mais il lui manque tableaux, figures, notes, ou d’autres parties des articles. L’impact sur l’utilisateur : Les utilisateurs ne parviennent pas à obtenir tout ou partie du contenu qu'ils s'attendent à trouver. Et dans le cas des articles incomplets, ils peuvent même ne pas se rendre compte qu'ils n'ont pas accès à la totalité du contenu proposé par le fournisseur de contenu original. Les Solutions : Les fournisseurs de contenu déclareront le type de contenu offert. Un ensemble de termes pour décrire la couverture est fournie au chapitre 6.3.2.15.

5.2.6. Les problèmes de périodes d’embargo Le problème central : Les développeurs de bases de connaissances se posent souvent des questions quant à la façon d'appliquer des conditions d’embargo changeantes. En effet, les mêmes termes peuvent être entendus différemment par chacun des fournisseurs de contenus. L’impact sur l’utilisateur : La terminologie relative aux embargos est complexe. Un "embargo sur 1 an" peut par exemple signifier que les 12 derniers mois ne sont pas disponibles, ou bien que l'année civile en cours (ou précédente) n'est pas disponible (par exemple, de janvier d'une année donnée jusqu’à ce jour). Les utilisateurs ne savent donc pas avec certitude si l'article qu'ils cherchent se trouve dans une base de données lorsque la date d'émission tombe dans —ou près de— la période d'embargo. Les Solutions : L’utilisation de la syntaxe sur les durées, suivant la norme ISO 8601, atténue ce problème puisqu’elle permet de décrire plusieurs types d'embargo. Voir le chapitre 6.3.2.14 pour plus de détails.

5.2.7. Le format et l’échange des données Le problème central : Les erreurs dans les données ou les échanges non-standardisés de données ralentissent leur versement dans la base de connaissances. Les données qui ne sont pas conformes aux formats convenus sont également une source de liens invalides.

18

L’impact sur l’utilisateur : Des informations inexactes et périmées produisent des liens qui ne peuvent pas être résolus, et empêchent les utilisateurs d'atteindre des contenus auxquels ils devraient avoir accès. Les Solutions : Les fournisseurs de contenus se conformeront aux recommandations de ce rapport et affecteront un membre de leur personnel qui veillera à la bonne marche vers la mise en conformité des données concernées. Les éditeurs de résolveurs de liens procureront aux fournisseurs de contenus l’accès à un compte d'essai afin qu'ils puissent vérifier les données sur leurs publications, telles que représentées dans la base de connaissances.

5.2.8. Les données de contenus obsolètes Le problème central : Les données de contenus obsolètes mènent à une présentation incorrecte des données. L’impact sur l’utilisateur : Les données présentes dans les bases de connaissances ne peuvent pas être plus précises que celles qu’on y a versées. Si certaines données “à jour” ne sont pas disponibles, les utilisateurs ne pourront pas accéder au contenu récent auquel ils ont pourtant droit. Les Solutions : Les fournisseurs de contenus délivreront régulièrement des informations sur les collections, selon une fréquence qui suit leur calendrier de publication. Les fournisseurs de résolveurs de liens permettront aux utilisateurs des catalogues de bibliothèques de voir quand les données ont été fournies pour la dernière fois et quand elles seront de nouveau actualisées. Les fournisseurs de résolveurs de liens informeront les fournisseurs de contenus et les bibliothécaires de leur calendrier de mises-à-jour des bases de connaissances et confirmeront le moment exact de leur exécution.

5.2.9. Le manque de personnalisation Le problème central : Plutôt que de se voir proposer uniquement les titres et couvertures accessibles à leur seul établissement, les clients ont généralement tous accès aux mêmes couvertures temporelles : les plus larges. L’impact sur l’utilisateur : Les bibliothécaires se voient obligés de consacrer du temps à personnaliser ces listes afin qu’elles représentent fidèlement les fonds de l’établissement. Ils prennent alors le risque d’introduire des erreurs qui auront pour conséquence la rupture de l’accès ou de l’utilisation d’une ressource offerte par un fournisseur. Les Solutions : Les fournisseurs de résolveurs de liens et de contenus travailleront ensemble pour échanger des fichiers spécifiques aux collections de chaque bibliothèque. Chaque établissement pourra ainsi mieux gérer les données qui lui sont relatives. Étant données l'importance et la complexité de la question de la personnalisation, KBART a l'intention de l'étudier plus avant au cours d'une phase ultérieure. Même si le fournisseur ne

19

20

peut pas générer un fichier distinct pour chaque établissement, il peut toujours générer des fichiers spécifiques de collections pour les abonnements ou bouquets les plus courants.

6. Recommandations pour un échange efficace de métadonnées avec les bases de connaissances

De nombreux fournisseurs et développeurs de bases de connaissances s’échangent déjà des métadonnées. Le présent rapport ne vise pas à interférer ou à dénigrer les procédures déjà en place. Toutefois, il est évident que beaucoup d'autres acteurs ne connaissent pas de façon efficace d'échanger ces métadonnées. Par conséquent, nous proposons des recommandations élémentaires ainsi que des instructions pour permettre l'échange des principales métadonnées. Nos recommandations sont basées sur les méthodes et champs de données dont la pertinence a été éprouvée par notre expérience collective. Dans de nombreux cas, plusieurs possibilités s’offrent à nous mais, pour plus de clarté et de simplicité, nous n’émettrons qu’une seule recommandation quand cela est possible. Nos recommandations excluent également des informations qui seraient plus proches de données bibliographiques que de métadonnées descriptives des états de collections, telles que la langue, les variantes de titres, le type de contenu, ou la relation à d'autres titres. Comme ces données sont plus statiques que les données relatives aux états des collections, elles n’ont pas besoin d'être échangées de façon aussi régulière, et n’entrent pas dans le périmètre des recommandations du groupe KBART.

6.1. La transition vers KBART Pour les fournisseurs de contenus qui proposent déjà des fichiers de métadonnées aux développeurs de bases de connaissances, par exemple au format OAI ou ONIX-SOH, cet ensemble de recommandations pourra être utilisé comme une feuille de route pour la révision de leurs dispositions actuelles en vue d'intégrer les champs obligatoires manquants recommandés dans le présent document. Il se peut que les méthodes actuelles de transfert de fichiers et les conventions de nommage soient déjà adéquates et qu’aucune modification concernant le nommage ou le mode de transfert des fichiers ne soit nécessaire. Pour les fournisseurs de contenus qui n'envoient pas encore de fichiers de métadonnées relatives à leurs contenus, ces recommandations peuvent être vues comme un guide complet de mise en œuvre. Les fournisseurs de contenus qui participent à CrossRef peuvent contacter CrossRef pour obtenir de l'aide pour certains points concernant l'échange de métadonnées. CrossRef gère déjà la quasi-totalité de l'information définie plus bas, et étudie la possiblité de devenir le noeud central qui diffusera les informations de ses membres en direction des utilisateurs de métadonnées

6.2. L’échange

6.2.1. La méthode d’échange Les fournisseurs de contenus publieront leurs données sur un site Web ou un site FTP pour que les fournisseurs de résolveurs de liens puissent les télécharger. Cela minimisera l'effort impliqué dans la transaction pour les deux parties. FTP12 est un protocole simple qui permet aux utilisateurs d'échanger des fichiers. Même si les fournisseurs de contenus doivent reconnaître qu’une large diffusion de l'information portant sur l'accès à leurs contenus est plutôt dans leur intérêt, le protocole FTP permet de limiter l'accès aux fichiers de métadonnées aux seuls utilisateurs autorisés. Le plus grand nombre de résolveurs de liens (ainsi que les bibliothèques qui gèrent elles-mêmes leur propre résolveur) devront être en mesure d’accéder à ces données. La publication sur le Web ou sur un site FTP est préférable à l’échange de courriels. Il est en effet plus difficile d'intégrer un courriel dans un processus automatisé de vérification, de validation et de téléchargement régulier de nouvelles données. Les échanges par courriel sont également soumis à des restrictions de volume, aux filtres anti-spam, ainsi qu’à la disponibilité de leurs destinataires. Toutefois, si la publication sur le Web ou sur un site FTP est irréalisable, alors le courriel constitue une alternative acceptable. Les données du fichier dont les valeurs sont délimitées par des tabulations (voir le chapitre 6.3.1.1) seront alors placées dans le corps du courriel ; la ligne d'objet du courriel suivra également la convention de nommage décrite au chapitre 6.3.1.2.

6.2.2. La fréquence des échanges Nous recommandons une mise-à-jour mensuelle des métadonnées. Les fournisseurs de contenus choisiront bien sûr une fréquence moins élevée si leurs contenus n’évoluent pas aussi souvent. De même, les fournisseurs pourront procéder plus fréquemment à des mises-à-jour s’ils le souhaitent.

6.2.3. Les responsables à contacter Le fournisseur de contenus et le développeur de bases de connaissances désigneront des personnes responsables des fichiers et de l’échange des données. Procéder ainsi accélère la résolution des problèmes qui peuvent se présenter. Les fournisseurs de contenus devront informer la personne désignée chez le développeur de la base de connaissances de tout changement dans le processus d'échange de données. Les développeurs de bases de connaissances seront tenus d'informer le contact désigné chez le fournisseur de contenus de toutes les erreurs trouvées dans les données. Les deux personnes responsables, désignées plus haut, assumeront la responsabilité de transmettre des messages aux personnes compétentes dans leur entreprise et de s’assurer que des mesures appropriées sont prises. Pour faciliter cette relation, le groupe de travail KBART fournira également un formulaire web, modifiable par la communauté, pour ajouter des informations concernant le fournisseur de contenus et les contacts chez les

12 FTP est l’acronyme de “File Transfer Protocol”

développeurs de bases de connaissances. Un lien vers le formulaire web sera fourni sur les pages Web du site KBART.

6.3. Les données

6.3.1. Le format des données 6.3.1.1 Les fournisseurs de contenus fourniront des métadonnées dont les valeurs seront délimitées par des tabulations13. Il s'agit d'un format générique qui minimise le travail lors de la réception et du chargement des données et réduit le risque d'erreurs lors de l'échange. La délimitation des valeurs par des tabulations est préférable à une délimitation par des virgules14. En effet les virgules sont couramment utilisées dans les champs des données distribuées et, bien qu’elles puissent être distinguées pour ne pas avoir valoir de séparateur, leur présence favorise l’apparition d’erreurs. Les formats contenant des valeurs délimitées par des tabulations sont facilement exportables à partir de tous les programmes de tableurs couramment utilisés15. 6.3.1.2 Le fichier sera nommé “[NomDufournisseur]_AllTitles_[AAAA-MM-JJ].txt”. Par exemple : JSTOR_AllTitles_2008-12-01.txt. 6.3.1.3 Le nom du fournisseur utilisé sera le nom du domaine Web sur lequel vos données sont hébergées (mais sans la ponctuation). Par exemple, JSTOR ou EBSCOhost. Cela garantit que vos données seront clairement distinguées des données fournies par d'autres, qui proposent des noms de bouquets semblables. En outre, pour un fournisseur donné, le nom du fichier doit contenir le même nom de fournisseur pour chaque fichier distinct de métadonnées déposé. 6.3.1.4 Des fichiers distincts seront produits pour chaque bouquet de contenus offert par le fournisseur. Les fichiers seront nommés tel que les clients s'attendent à les voir désignés dans la base de connaissances, en utilisant la syntaxe “[NomDuFournisseur]_[NomDeLaCollection]_[AAAA-MM-JJ].txt”. Par exemple : JSTOR_Arts&SciencesV_2008-12-01.txt Les fournisseurs et les bénéficiaires peuvent convenir à l'avance de la meilleure façon de présenter les noms de collections complexes. 6.3.1.5 Toutes les métadonnées seront fournies dans un fichier en texte brut. Si les métadonnées sont fournies dans un format qui permet en sus styles et mises en forme, il sera proposé sans ces artifices. Les données ne comporteront pas de couleur, police de caractères, italique, ni un autre balisage. 6.3.1.6 Le texte sera encodé en UTF-8. Le jeu de caractères UTF-8 est très répandu et comprend les systèmes d'écriture de nombreuses langues. C'est un encodage courant proposé par les programmes tels que Microsoft Excel.

13 tab-delimited values, tab-separated values, ou TSV 14 comma-separated values, ou CSV 15 http://docs.google.com/support/bin/answer.py?hl=fr&answer=63377

22

6.3.1.7 Chaque ligne du fichier contiendra une publication, avec une colonne pour chaque champ indiqué dans le chapitre 6.3.2 qui décrit les champs de données. 6.3.1.8 Les données seront fournies avec des en-têtes de colonne (voir le chapitre 6.3.2) et sans ligne vide entre l'en-tête de colonne et la première ligne de contenu. 6.3.1.9 Un titre sera répertorié deux fois s'il y a une période lacunaire supérieure ou égale à 12 mois dans sa couverture ; dans ce cas-là, la période de couverture est le seul élément qui différencie les deux lignes. Disposer d’une granularité plus fine quant à la façon dont on rend compte des lacunes dans la période de couverture est souhaitable. La prise en charge de cette fonctionnalité sera convenue avec le fournisseur du résolveur de liens. 6.3.1.10 Toutes les lignes seront cohérentes en termes de format. Par exemple, l’ISSN devra toujours être exprimée en neuf caractères séparés par un trait d'union, et les champs de date seront toujours dans le format décrit au chapitre 6.3.2. 6.3.1.11 Le fichier de métadonnées sera fourni par ordre alphabétique de titres pour faciliter la vérification et l'import par les développeurs de bases de connaissances.

6.3.2. Les champs de renseignements

6.3.2.1. Les champs et leurs désignations Le fournisseur de contenus inclura les champs suivants (en tant que colonnes) dans le fichier de métadonnées au format texte délimité par des tabulations. Tous les champs seront considérés comme obligatoires si ils sont disponibles, et tous les efforts seront déployés pour recueillir les données, même si ces champs proviennent d’un autre service ou même d'une source externe. Comme les bénéficiaires des fichiers de métadonnées s'attendent à recevoir leurs fichiers dans un format compatible, chaque champ apparaîtra dans l'ordre indiqué ci-dessous, même si le fournisseur de contenus n'est pas en mesure de fournir un renseignement et laisse le champ vide, soit parce qu’il ne dispose pas de l’information, soit parce qu’aucune information n’est nécessaire pour ledit champ. Les noms de champs du tableau suivant seront utilisés. Pour éviter des confusions et des erreurs inutiles, les fournisseurs de contenus sont encouragés à inclure les entêtes de colonnes dans tous les fichiers qu'ils génèrent. Dans un souci de cohérence, les dénominations suivantes seront utilisées:

publication_title Titre de la publication

print_identifier Identifiant du format papier (ex : ISSN, ISBN, etc.)

online_identifier Identifiant du format électronique (ex : eISSN, eISBN, etc.)

date_first_issue_online Date du premier numéro disponible en ligne

num_first_vol_online Numéro du premier volume disponible en ligne

23

num_first_issue_online Premier numéro disponible en ligne

date_last_issue_online Date du dernier numéro disponible en ligne (ou blanc, si la couverture s’étend jusqu’à ce jour)

num_last_vol_online Numéro du dernier volume disponible en ligne (ou blanc, si la couverture s’étend jusqu’à ce jour)

num_last_issue_online Dernier numéro disponible en ligne (ou blanc, si la couverture s’étend jusqu’à ce jour)

title_url URL du titre

first_author Auteur principal (pour les monographies)

title_id Identifiant du titre

embargo_info Informations sur l’embargo

coverage_depth Etendue de la couverture de contenu (c’est à-dire “résumé” ou “texte intégral”)

coverage_notes Notes sur la couverture

publisher_name Nom de l’éditeur (s’il n’est pas déjà mentionné dans le titre du fichier)

De plus amples détails sur le contenu de chaque champ sont donnés ci-dessous. Des exemples de dossiers complets pour divers types de contenu sont fournis dans l’Annexe A intitulée “Echantillons de données d’échange”.

6.3.2.2. Le titre de la publication (publication_title) Indiquer ici le nom complet de la publication, tel qu'il apparaît sur l'édition papier ou sur sa page Web d'accueil. Les caractères spéciaux seront encodés en utilisant le jeu de caractères UTF-8. Les abréviations seront évitées. Pour les titres débutant par un article (“le”, “la”, “les”, etc.), celui-ci sera inclus. Par exemple, “Le Monde” sera répertorié comme “Le Monde ” dans sa forme officielle complète, et non pas comme “Monde” ou “Monde, Le”. Les anciens titres de la revue seront listés comme des entrées distinctes, avec leurs propres dates de couverture, correspondant à la période de temps pendant laquelle chaque variante du titre a été en usage. Les développeurs de bases de connaissances assureront alors la mise en relation entre ces titres liés. Les titres de collections ne seront pas gérés comme des titres individuels dans les fichiers de métadonnées. Tous les bouquets de titres (packages) devront être envoyés, chacun dans un fichier distinct, avec le nom de la collection mentionnée dans le nom du fichier.

6.3.2.3. Identifiant du format papier (ex : ISSN, ISBN, etc.) (print_identifier)

Fournir l’identifiant standard du contenu. Pour commencer, ce sera probablement l'ISSN (avec l'ensemble des 9 caractères, y compris le trait d'union et le chiffre de contrôle) ou

24

l’ISBN (ISBN-10 ou ISBN-13 selon l’information disponible ; les résolveurs de liens peuvent les convertir le cas échéant). A l'avenir, cela pourra inclure l'ISMN, l’ISAN, ou d'autres. Dans les cas où plusieurs ISSN ou ISBN existent pour le titre, seul le format papier ISSN ou ISBN sera utilisé pour ce champ.

6.3.2.4. Identifiant du format électronique (ex : eISSN, eISBN, etc.) (online_identifier)

Si les identifiants d’un titre ont été créés pour les formats électroniques, ils seront utilisés dans ce champ.

6.3.2.5. Date du premier numéro disponible en ligne (date_first_issue_online)

Pour les revues, ce champ au format AAAA-MM-JJ inclura la date du premier numéro disponible en ligne. On utilisera uniquement les parties du champs qui sont nécessaires. Par exemple si la revue est annuelle, seule l’année au format AAAA sera renseigné. Alors que si la revue est mensuelle ou trimestrielle, seuls l’année et le mois au format AAAA-MM seront utilisés. On se servira seulement du champ complet AAAA-MM-JJ dans les cas où les numéros de la revue ont précisé des dates de couverture qui comprennent un jour. Pour les monographies, la date de publication sera donnée dans le format AAAA-MM-JJ. Mais, encore une fois, n’utiliser pour ce champ que les informations qui sont spécifiquement indiquées comme date de publication du livre. Le format de date ISO 8601 sera utilisé pour toutes les dates.

6.3.2.6. Numéro du premier volume disponible en ligne (num_first_vol_online)

Pour les revues, mettre le numéro de volume du premier numéro dans ce champ. Ne rien inclure d’autre, comme par exemple, "vol." ou "c.". S’efforcer de respecter le style “maison” de citation de contenu, et donnez une valeur alphanumérique si besoin. Les développeurs de bases de connaissances utiliseront une logique équivalente en normalisant ces données et les données fournies dans les requêtes OpenURL afin d’augmenter la probabilité qu’une référence bibliographique corresponde à une source. Pour les livres, laisser ce champ vide.

6.3.2.7. Premier numéro disponible en ligne (num_first_issue_online)

Pour les revues, mettre le numéro du premier numéro dans ce champ. N’inclure rien d’autre, comme par exemple, "no.", “n°”, “num.” ou "n.". S’efforcer de respecter le style “maison” de citation de contenu, et donner une valeur alpha-numérique si besoin. Les développeurs de bases de connaissances utiliseront une logique équivalente pour normaliser ces données et les données fournies dans les requêtes OpenURL afin d’augmenter la probabilité qu’une référence bibliographique soit associée à une source. Pour les livres, laisser ce champ vide.

25

6.3.2.8. Date du dernier numéro disponible en ligne (ou vide, si la couverture s’étend jusqu’à ce jour) (date_last_issue_online)

Pour les revues, indiquer la date du numéro le plus récent disponible en ligne. Là encore, n’utiliser que les champs qui sont spécifiquement fournis dans les dates de couverture de la revue. Pour les revues, ce champ sera laissé vide si la revue est disponible jusqu’à la date courante. Pour les monographies, laisser ce champ vide.

6.3.2.9. Numéro du dernier volume disponible en ligne (ou vide si la couverture s’étend jusqu’à ce jour) (num_last_vol_online)

Pour les revues, mettre le numéro du volume le plus récent dans ce champ. N’inclure rien d’autre, comme par exemple, "vol." ou “v.”. S’efforcer de respecter le style “maison” de citation de contenu, et donner une valeur alpha-numérique si besoin. Les développeurs de base de connaissances utiliseront une logique équivalente pour normaliser ces données et les données fournies dans les requêtes OpenURL afin d’augmenter la probabilité qu’une référence bibliographique soit associée à une source. Pour les revues, ce champ sera laissé vide si la revue est disponible “jusqu’au jour présent”. Pour les livres, laisser ce champ vide.

6.3.2.10. Numéro du dernier numéro disponible en ligne (ou vide si la couverture s’étend jusqu’à ce jour) (num_last_issue_online)

Pour les revues, mettre le numéro du dernier numéro dans ce champ. N’inclure rien d’autre, comme par exemple, "no.", “n°”, “num.” ou "n.". Ne pas indiquer de mention de partie ou de supplément. S’efforcer de respecter le style “maison” de citation de contenu, et donnerez une valeur alpha-numérique si besoin. Les développeurs de bases de connaissances utiliseront une logique équivalente pour normaliser ces données et les données fournies dans les requêtes OpenURL afin d’augmenter la probabilité qu’une référence bibliographique soit associée à une source. Pour les revues, ce champ sera laissé vide si la revue est disponible “jusqu’au jour présent”. Pour les livres, laisser ce champ vide.

6.3.2.11. URL du titre (title_url) Indiquer dans ce champ l’adresse Web de la page d’accueil du titre. Pour les revues, cette adresse pointera sur la page qui liste les volumes et numéros disponibles. Pour les livres, cette adresse pointera vers la table des matières.

6.3.2.12. Auteur principal (pour les monographies) (first_author) Pour les monographies, donner le nom de famille de l’auteur principal. Pour les revues, laisser ce champ vide.

6.3.2.13. Identifiant du titre (title_id) Si un identifiant de titre est utilisé pour créer des liens vers le contenu, donner l’identifiant propriétaire du titre du contenu. Si plus d'un identifiant existe, fournir l'identifiant du titre utilisé pour le lien.

26

Si des participants externes n’ont pas besoin de connaître ou d’utiliser vos identifiants propriétaires, ou en l'absence d'identifiant propriétaire, ce champ sera laissé vide, mais il est préférable d'inclure un identifiant s'il en existe un.

6.3.2.14. Embargo (embargo_info) Le champ “embargo” représente la période avant laquelle les ressources ne sont pas disponibles en ligne. Cela résulte généralement de limitations contractuelles établies entre l'éditeur et le fournisseur de contenu. Fournir cette information aux bibliothécaires, généralement via les propriétaires de résolveurs de liens, est vital pour s'assurer que les résolveurs de liens ne créent pas de liens vers un contenu auquel les utilisateurs n’ont pas encore le droit d'accéder. Un des principaux problèmes auquel sont confrontés les membres de la chaîne de fourniture de données est l’existence de plusieurs types d’embargos. Dans certains cas, la couverture "jusqu’à il y a un an" signifie que les données âgées de 365 jours deviennent disponibles dès aujourd'hui, tandis que dans d'autres cas, cela signifie que l'élément n'est pas disponible avant la fin de l'année civile en cours. En raison de la complexité inhérente aux embargos, nous recommandons que la norme ISO 8601 régissant la syntaxe des dates soit utilisée. Cette norme est suffisamment flexible pour permettre de décrire les différents types d’embargos. La méthode suivante de spécification des embargos est dérivée de la norme ISO 8601, à laquelle nous ajoutons quelques compléments qui ne sont pas couverts par la norme. La déclaration d’embargo comporte trois attributs : son type, sa longueur, et ses unités. Ces trois attributs sont insérés, dans cet ordre, dans une chaîne de caractères unique et sans espace. Le type: Tous les embargos comprennent une barrière mobile, un point dans le temps exprimé par rapport au présent (par exemple, “il y a 12 mois”). Si l'accès à la revue commence à la barrière mobile, l'embargo sera de type “R”. Si l'accès se termine à la barrière mobile, alors le type de l'embargo sera “P”. La longueur : Un nombre entier désignant la longueur de l’embargo L’unité : L’unité pour le nombre du champ “Longueur” :

● “D” pour les jours, ● “M” pour les mois, ● et “Y” pour les années.

Pour plus de simplicité, “365D” sera toujours équivalent à un an, et “30D” sera toujours équivalent à un mois, même durant les années bissextiles et les mois qui ne possèdent pas trente jours. Le champ «unités» rend également compte de la granularité de l'embargo, c’est-à-dire la fréquence à laquelle la barrière mobile se déplace. Une base de données de revues peut, par exemple, avoir un modèle d'abonnement dans lequel ses clients n’ont accès qu’à exactement un an de contenu. Chaque jour, un nouveau numéro est ajouté, et le numéro publié il y a exactement un an ce jour-là devient inaccessible. Dans ce cas, L’embargo sera déclaré comme suit : “R365D”, parce que la date du numéro accessible le plus ancien change chaque jour.

27

Considérons maintenant le cas d’une revue, dont le modèle donne accès à tous les numéros de l'année en cours, à partir de janvier. Au mois de janvier suivant, le client perd simultanément l'accès à tous les numéros de l'année précédente, et ne pourra qu’accéder aux numéros publiés dans l'année civile en cours. Dans ce cas, nous dirons que le client a accès à une “année civile” du contenu. La déclaration embargo sera “R1Y”, parce que la date du numéro disponible le plus ancien ne change qu’une fois par an. Vous trouverez ci-dessous quelques embargos courants exprimés selon la syntaxe décrite précédemment : • L'accès à l'ensemble du contenu, à l'exception de l'année civile en cours : P1Y • L'accès à l'ensemble du contenu dans l’année civile précédente et l’année civile actuelle : R2Y • L'accès à l'ensemble du contenu à partir d'il y a exactement 6 mois jusqu’à ce jour : R180D • L'accès à l'ensemble du contenu, à l'exception des 6 derniers mois civils : P6M Dans le cas où il y a un embargo à la fois au début et à la fin d'une zone de couverture, les deux déclarations d’embargo seront concaténées, l'embargo de départ en premier. Les deux déclarations seront séparées par un point-virgule. Par exemple, "R10Y;P30D" qui décrit une archive dans laquelle les 10 dernières années civiles de contenu sont disponibles, sauf pour les 30 derniers jours.

6.3.2.15. L’étendue de la couverture (coverage_depth) Ce champ exprime l’étendue du contenu couvert pour la période correspondant aux champs de couverture (“coverage_depth”) et d’embargo. Il peut prendre l’une des trois valeurs suivantes :

● fulltext16 : Indique que le texte intégral des articles est disponible. Si le texte intégral ne correspond pas à son équivalent papier, le champ “coverage_notes” (notes de couverture) décrira ce qui est exclu (par exemple, "exclut les graphiques")

● selected articles17 : La couverture comprend le texte intégral de certains, mais pas de l’ensemble des articles. Les détails de la politique de couverture seront reportées dans le champ ”coverage_notes” (notes de couverture).

● abstracts18 : La couverture comprend seulement des résumés d’articles. La valeur “selected articles” (sélection d'articles) ne sera utilisée dans ce champ que si un grand nombre d'articles n’est pas disponible, peut-être en raison d'une politique spécifique. Une revue particulière pourrait ne publier que des articles de recherche en ligne, mais pas de courrier ni de critique de livres. D’autres bases de données peuvent ne contenir que des articles traitant d’un domaine particulier. Cette politique doit être détaillée dans le champ ”coverage_notes” (notes de couverture). On n’utilisera pas la valeur “selected articles” dans les cas où seuls quelques articles sont manquants en raison de problèmes techniques. Les valeurs d’étendue de couverture ci-dessus peuvent être combinées entre elles avec un point-virgule comme séparateur. Si la couverture d'une revue ne comprend que des résumés 16 trad. texte intégral 17 trad. sélection d'articles 18 trad. résumés

28

29

des articles sélectionnés (comme c’est parfois le cas dans les bases de données de résumés et d’indexation (A&I)), on renseignera dans ce champ : “abstracts; selected articles”. Un produit thématique en texte intégral sera désigné comme: “selected articles”.

6.3.2.16. Les notes de couverture (coverage_notes) Il s'agit d'un champ texte optionnel qui sera renseigné seulement si l’étendue de la couverture nécessite de plus amples explications. Ce champ est utilisé pour décrire les spécificités de la politique de couverture, par exemple : “exclut le courrier et les critiques de livres”. Ce champ est affichable textuellement dans les résultats du résolveur de liens de sorte que les utilisateurs finaux puissent identifier les contenus exclus.

6.3.3. Le rapport d’erreurs Quand les bibliothécaires et leurs utilisateurs relèvent des erreurs dans les données d’une base de connaissances (par exemple, des dates de couverture incorrectes pour une revue dans une base de données de texte intégral), nous les encourageons à signaler ces erreurs au développeur de la base, qui enquêtera sur l'erreur et mettra à jour la base de connaissances globale. L'enquête peut prendre quelques heures ou plusieurs jours, selon le degré de coopération du fournisseur de contenu initial. (Notez que les développeurs des bases de connaissances n'ont pas accès à toutes les ressources électroniques, et se trouvent parfois dans l’incapacité de confirmer l'erreur ou de retrouver les informations correctes car ils ne sont pas aidés par le fournisseur de contenus. En outre, et en fonction du modèle de distribution du fournisseur de résolveur de liens, il peut s’écouler un certain temps avant que la correction n’apparaisse dans la base de connaissances du client). Le groupe de travail NISO/UKSG KBART recommande que les développeurs de bases de connaissances se mettent activement à la recherche de solutions pour que des corrections apportées à la base de connaissances globales apparaissent beaucoup plus rapidement au niveau local, et évitent ainsi aux bibliothécaires d’avoir à personnaliser leurs collections, remède temporaire aux lacunes de la base de connaissances globale. De même, nous recommandons de définir les critères nécessaires et suffisants qui établissent qu’une métadonnée a été correctement corrigée.

7. Le matériel pédagogique Une grande partie des problèmes rencontrés avec la technologie OpenURL trouve son origine dans le manque de publicité autour d’elle : sa technologie, la façon dont elle est utilisée, les avantages qu’elle apporte à chaque maillon de la chaine de l’information. Le groupe de travail NISO/UKSG KBART entend contribuer à faire connaître cette technologie et à la faire adopter en ayant recours à plusieurs canaux, comprenant ce guide de bonnes pratiques, une plateforme d’informations en ligne, des relations publiques et des formations.

7.1. La plateforme en ligne Un site Web de référence19 fournira une source de référence, point de départ pour ceux qui veulent se renseigner sur le circuit OpenURL. Les portails Web sont optimisés pour le référencement par les moteurs de recherche, et donc faciles à découvrir par ceux qui ont en le plus besoin, sans que les termes de base du domaine ne leur soient familiers. Le groupe de travail KBART produit un contenu d’informations et de formations qui ne présuppose que des connaissances et une expérience pratique minimes.Il est destiné à des personnes et des établissements dont la connaissance de la chaine d’alimentation des données OpenURL est limitée. Le contenu de ce rapport est présenté en parties de taille plus digeste sur le portail Web. Ce contenu sera complété par des documents supplémentaires, listés ci-dessous.

7.1.1. Un guide de bonnes pratiques Un résumé de la structure des métadonnées et des recommandations pour l’échange de données, fourni dans ce document

7.1.2. Une Foire Aux Questions Un ensemble de questions fréquemment posées20 pour résoudre les demandes courantes (cf. chapitre 6.3).

7.1.3. Un Glossaire Des définitions de termes de base, comme à la fin de ce document.

7.1.4. Des modes d’emploi cours et des fiches récapitulatives Ces documents comprennent :

● un résumé de KBART : les objectifs, les avantages ● un résumé de la chaine d'alimentation des données qui identifie la liste des

intervenants et de leurs responsabilités, qui explique la façon dont l'information et les technologies sont utilisées, leurs avantages inhérents, et enfin qui identifie les différents produits et outils disponibles.

19 http://www.uksg.org/kbart, dont les informations seront reproduites à l’identique sur http://www.niso.org/workrooms/kbart 20 Foire Aux Questions ou FAQ

7.1.5. Des démonstrations vidéo Des vidéos illustrant par des cas pratiques la technologie OpenURL et les métadonnées d’une base de connaissances dans la pratique.

7.1.6. Des études de cas Une série d'études de cas illustrera les bonnes pratiques en matière de transfert des métadonnées à des bases de connaissances.

7.2. Sensibilisation Pour sensibiliser le public aux productions et résultats de KBART, des actions de communication ont été entreprises et seront poursuivies. Celles-ci comprennent : communiqués de presse, publications d’articles, allocutions et participation à des séminaires de formation / séminaires en ligne. Lorsque cela est possible, nous mettrons à profit l’influence d’organisations telles que ALPSP21, ER & L22, LITA23, ACRL24, ALA25, NASIG26, NFAIS27, NISO, OASPA28, PSP29, PA30, STM31, UKSG, VALA32, et les autres.

7.3. Exemples de FAQ Ceux qui commencent à adopter la technologie OpenURL et ceux qui cherchent des renseignements plus poussés tireront bénéfice de la section de “Foire Aux Questions” (FAQ) du site Web de référence. Des exemples de questions présentes dans la FAQ sont listés ci-dessous.

7.3.1. Questions générales ● Qu’est-ce qu’un résolveur de liens ? ● Qu’est-ce qu’une base de connaissances ? ● Qu’est-ce qu’un lien source, un lien cible ? Et quelle est la différence entre les deux ? ● Qu’est-ce qu’un lien OpenURL ?

7.3.2. Les questions des éditeurs et fournisseurs de contenu ● Comment puis-je m'assurer que mes clients/usagers peuvent accéder à mon contenu

?

21 The Association of Learned and Professional Society Publishers : http://www.alpsp.org/ngen_public/ 22 Electronic Resources & Libraries : http://www.electroniclibrarian.com/ 23 The Library and Information Technology Association : http://www.ala.org/ala/mgrps/divs/lita/index.cfm 24 The Association of College and Research Libraries : http://www.ala.org/ala/mgrps/divs/acrl/index.cfm 25 American Library Association : http://www.ala.org/ 26 North American Serials Interest Group : http://www.nasig.org/ 27 The National Federation of Advanced Information Services : http://www.nfais.org/ 28 Open Access Scholarly Publishers Association : http://www.oaspa.org/ 29 The Professional/Scholarly Publishing Division : http://www.pspcentral.org/index.cfm 30 The Publishers Association : http://www.publishers.org.uk/ 31 International Association of Scientific, Technical & Medical Publishers : http://www.stm-assoc.org/ 32 The Victorian Association for Library Automation : http://www.vala.org.au/

31

● Comment puis-je aider mes clients à créer des liens du contenu de mon site vers d'autres contenus ?

● Qui met à jour les bases de connaissances et comment puis-je le/les contacter ? ● Comment les informations sur mes contenus sont-elles présentées à l'utilisateur d'un

SIGB ? ● De quel genre d'information une base de connaissances a-t-elle besoin pour que mes

clients soient assurés d’accéder à mon contenu ? ● Les développeurs de bases de connaissances ont-ils tous besoin des mêmes

informations ? ● Dois-je aussi fournir des détails sur mes offres de bouquets ? ● Si je fournis déjà des informations aux développeurs de bases de connaissances,

dois-je continuer à fournir leurs informations d’abonnements et de liens directement aux bibliothécaires ?

● J'ai fourni des informations sur mes contenus, mais on me rapporte que les clients n’ont toujours pas d’accès fiable à mon site Web. Comment cela se fait-il ?

● Puis-je fournir des données sur mes e-books en plus de celles sur mes revues ? ● Selon quelle fréquence dois-je fournir de nouvelles informations sur mes contenus ? ● Lors de la description de la couverture d’un contenu, dois-je utiliser des dates ou des

numéros de volumes / revues ? ● Ai-je besoin de fournir des informations sur tous les contenus disponibles, ou

seulement sur les contenus sous licence ? Que faire s’il y a différents modèles de licences ?

● Mes clients enregistrent leurs préfixes pour leur résolveur de liens et ils sont tous légèrement différents. Y-a-t-il une norme à suivre pour ces données et comment puis-je vérifier qu’elles sont correctes ?

7.3.3. Les questions des bibliothécaires ● Quels sont les avantages de posséder un résolveur de liens ? ● Quelles informations dois-je fournir à mon résolveur de liens ? ● Pourquoi les fournisseurs de contenus ne fournissent-ils pas d’informations fiables

sur leurs collections ? Je possède une licence pour une collection soit-disant standard d’un éditeur X mais je suis toujours obligé modifier les informations associées.

● Existe-t-il une liste de plateformes compatibles avec OpenURL (c’est à dire dans lesquelles il m’est possible d’inscrire mon résolveur de liens) ?

● Quelle est la meilleure source de données exactes pour mes collections ? ● Puis-je charger des données dans la base de connaissances, ces changements

doivent-ils être exécutés manuellement ? ● Est-ce que tous les résolveurs de liens utilisent les mêmes bases de connaissances

et les même profils de couverture de collections ? Si non, comment puis-je évaluer la couverture des différents services ?

● Lorsqu’une revue change de titre, dois-je modifier mes collections dans la base de connaissances ou bien la mise à jour est-elle automatique ?

● Lorsqu’une revue change d’éditeur, dois-je modifier mes collections manuellement ? ● Lorsque j’apporte des modifications à mes collections, la base de connaissances se

met-elle à jour automatiquement ?

32

● Je viens d’acquérir une licence pour une nouvelle base de données en texte intégral ou une nouvelle revue électronique mais elle n’apparait pas dans la base de connaissances. Pourquoi et que dois-je faire ?

● Puis-je saisir des informations concernant mes collections de revues papier dans ma base de connaissances ?

● Est-il possible de personnaliser l’interface de ma base de connaissances ? Pouvons-nous par exemple fournir des liens vers d’autres services proposés en bibliothèques, de type PEB (prêt entre bibliothèques) ?

7.4. Recommandations pour l’amélioration des liens Le mauvais formatage des liens et la mise en oeuvre mal réalisée du résolveur menacent souvent le processus de résolution. Les liens OpenURL mal formatés entraîneront inévitablement l’échec de l’accès à la ressource. Les résolveurs de liens transfèrent généralement les informations qu'ils reçoivent en ne vérifiant qu’a minima les métadonnées de la source qui leur sont données. Le résolveur de liens peut, par exemple, vérifier que l'ISSN est correctement formé (mais pas nécessairement vérifier que c'est l’ISSN correct pour la référence bibliographique donnée), puis le supprimer si le contrôle échoue. Le résolveur peut aussi accepter le titre fourni et le renvoyer ensuite dans une version plus précise ou normalisée. Mais si le fournisseur du lien source a créé un lien OpenURL dans lequel les données d’énumération (par exemple, «volume», «revue», «numéro», etc.) remplacent les renseignements chronologiques (par exemple, jour, mois, année, etc.), et vice versa, le résolveur ne reviendra pas en arrière pour corriger ces informations. Par conséquent, il est essentiel que l'institution qui crée le lien OpenURL source le fasse de façon précise et correcte. Il existe un certain nombre de ressources en ligne, qui aident ces institutions à créer ces liens. A titre d’exemples :

● COinS Generator : http://generator.ocoins.info/ ● OpenURL Generator Help : http://search.lib.unimelb.edu.au/help/openurlgen.html

Un projet financé par la Fondation Andrew W. Mellon et basé à la Cornell University explore en outre la faisabilité d'un système qui permettra d'analyser et générer un rapport sur un grand nombre de liens OpenURL sources afin d'identifier les erreurs structurelles et aider à les corriger. Adam Chandler et David Ruddy de la Bibliothèque de la Cornell University se sont engagés avec Eric Rebillard, professeur de lettres classiques à la Cornell University, dans un projet subventionné par la “Mellon Planning Grant”. M. Rebillard est le rédacteur en chef de “L'Année philologique”, une base de données bibliographique. Depuis 2004, la version électronique de “L'Année philologique” (appelé “APh Online”) est compatible OpenURL. Chaque entrée contient un lien qui peut être traité par un résolveur de liens, mais beaucoup de liens OpenURL n’aboutissent pas. A partir de l’examen manuel d’un échantillon de 126 liens OpenURL générés par “L'Année philologique”, Adam Chandler a élaboré un premier ensemble de recommandations pour l'amélioration des métadonnées. Dans son rapport, intitulé “Results of L’Année philologique

33

online OpenURL Quality Investigation”33, il a identifié de nombreux problèmes de métadonnées représentatifs qui provoquent l’échec des liens OpenURL : dates malformées, volume et numéro combinés en un seul champ, absence d'identifiants, etc. Ce rapport est extrêmement utile pour “L'Année Philologique” parce qu'il identifie précisément les zones critiques dans lesquelles porter les efforts de correction avec le plus d’efficacité. Devoir conduire un examen manuel de tous les liens OpenURL générés par “L'Annee Philologique”, ou par tout autre fournisseur, serait d’un coût prohibitif et prendrait beaucoup de temps. Chandler et Ruddy ont proposé d’étudier la faisabilité de développer un processus entièrement automatisé pour évaluer les liens OpenURL. Un tel système prendrait en entrée des liens OpenURL et donnerait des notes fondées selon un ensemble de critères d'évaluation. Ces notes indiqueraient précisément aux fournisseurs de ressources les liens OpenURL les moins fiables et leur permettraient de cibler leur travail d'amélioration des métadonnées de la façon la plus rentable. Enfin ils ont réfléchi à un indice, reconnu par la communauté, qui mesurerait la qualité des liens OpenURL des fournisseurs de contenu. En décembre 2009, le NISO a donné son accord pour lancer un projet de deux ans présidé par Chandler, dont l’objectif est le test et la validation des métriques utilisés pour déterminer la qualité d’un lien OpenURL34.

33 trad. Les résultats de l’enquête sur la qualité des OpenURL de “L'Année philologique” en ligne 34 pour plus d'informations, voir http://www.niso.org/workrooms/openurlquality

34

8. Les prochaines étapes / Phase II Les recommandations de ce rapport présentent un certain nombre de mesures importantes que les fournisseurs de contenu peuvent adopter pour améliorer le transfert de données entre les membres de la chaîne d'approvisionnement des ressources électroniques. Le Groupe de travail NISO/UKSG KBART estime toutefois que de nombreuses mesures peuvent être prises par tous les participants pour améliorer encore l'expérience de l'usager avec leurs résolveurs de liens et bases de connaissances. Ces propositions sont les suivantes:

● Définitions des mises à jour globales vs. locales (voir chapitre 7.1.1) ● Transfert des métadonnées spécifiques aux consortiums ● Transfert des métadonnées spécifiques aux établissements ● Documentation des recommandations pour le transfert des métadonnées des

contenus non-textuels ● Evaluation du transfert de métadonnées pour les livres électroniques ● Suivi et application de la conformité avec les recommandations KBART ● Echange des données d’un ERMS

Le Groupe de travail KBART est ouvert à toute proposition émanant des utilisateurs de ses recommandations quant aux directions à emprunter pour le futur.

8.1. Les recommandations et discussion plus poussée

8.1.1. Les différences entre les agrégateurs et les fournisseurs de contenus individuels

Veuillez noter que les questions de couverture pour les revues électroniques et bouquets de revues électroniques sont très différentes des questions de couverture pour un titre au sein d'une base de données agrégées. Tous les abonnés d'un bouquet ont les mêmes droits pour les mêmes titres. Les bibliothèques louent simplement l'accès aux collections créées par des agrégateurs de bases de données. Lorsque du contenu est ajouté ou supprimé, il l’est pour tous les établissements qui souscrivent à ce forfait, fréquemment à leur insu. En conséquence, quand une erreur de couverture est découverte et que les données correctes sont vérifiées, l'erreur déterminée peut être corrigée en une fois dans la base de connaissances globale. Cependant, concernant les revues électroniques souscrites individuellement, y compris celles qui appartiennent à des bouquets, les listes de titres et les droits d'accès à ces titres varient souvent d'un établissement et d’un contrat à l’autre. La base de connaissances globale ne peut que représenter les dates d'ensemble du contenu disponible pour le titre sur le site de l’éditeur. Les droits d'accès et les couvertures doivent être gérés client par client, soit dans une version personnalisée de la base de connaissances maître soit dans une copie de la base de connaissances installée localement et personnalisée par l'établissement. Les différences de couvertures d’une revue électronique par un client peuvent ne pas s’appliquer aux autres clients. Dans ce cas l'établissement mettra donc seulement à jour sa propre liste de ressources, et non la base de connaissances maîtresse.

35

Une vue d'ensemble de la chaine d'alimentation courante des données de la base de connaissances d’un résolveur de liens soulignera quelques-uns des nombreux défis à relever pour ceux qui tentent de tirer le meilleur parti des ressources électroniques par l'intermédiaire de liens OpenURL.

8.1.2. Les défis des collections consortiales Les établissements qui achètent tout ou partie de leurs ressources électroniques par l’intermédiaire de consortiums de bibliothèques rencontrent, lors du transfert des métadonnées, des complications supplémentaires introduites par les achats dans le cadre consortial. Les consortiums de bibliothèques ne sont pas identiques entre eux : certains offrent seulement un rabais de prix pour un produit existant et statique, tandis que d'autres créent des collections uniques de contenus de revues électroniques pour leurs membres. D'autres encore fournissent une possibilité d’achat élargi (dite “top-up”), par lequel les membres peuvent accéder à des ressources qu'ils n'avaient pas encore achetées. Lorsque la commande effectuée via le consortium a une influence sur la sélection des ressources électroniques, le consortium a intérêt à pouvoir ventiler les spécificités de son achat via le gestionnaire de base de connaissances à tous ceux qui ont accès à ces ressources.

8.1.3. Le transfert de métadonnées propres aux établissements En plus des défis rencontrés pour décrire les bouquets consortiaux, les établissements individuels ont souvent besoin d’apporter des modifications locales (couverture, titres actifs de leur fonds) aux ressources globales afin de faire correspondre les informations de couvertures des collections propres à un établissement. KBART entend se pencher dans une phase ultérieure sur les procédures de transfert de métadonnées des collections locales.

8.1.4. Le transfert de métadonnées de contenu non-textuel Jusqu'à présent, KBART s'est concentré sur des recommandations qui régissent le transfert de métadonnées de contenu textuel (périodiques électroniques et e-books). Alimenter les bases de connaissances avec des métadonnées décrivant du contenu non-textuel devient cependant de plus en plus important.

8.1.5. Passage en revue des métadonnées pour le transfert des e-books

Les procédures documentées dans ce rapport permettent la création et le transfert de fichiers qui décrivent à la fois des fonds de revues et de livres électroniques. Les recommandations actuelles nécessitent d’être évaluées à la lumière d’éventuels commentaires des participants sur des champs qui décrivent le contenu des e-books.

8.1.6. L’échange de données pour les ERMS Jusqu'à présent, KBART n’a abordé le problème de l’alimentation des bases de connaissances que pour les résolveurs de liens. Dans une phase ultérieure, le groupe de travail examinera les données supplémentaires requises pour alimenter les bases de

36

37

connaissances d’ERMS avec les données relatives aux abonnements à des ressources électroniques.

8.1.7. Conformité avec les recommandations KBART À l'heure actuelle, les membres du Groupe de travail KBART ne jugent pas utile de travailler à une norme structurée. Comme mentionné dans le chapitre 6, il existe des alternatives acceptables pour bon nombre des recommandations formulées dans ce rapport, et nous ne voulons pas imposer de travail supplémentaire aux établissements qui possèdent déjà une méthode efficace de diffusion de métadonnées. Cependant, nous souhaitons promouvoir les bonnes pratiques et signaler les problèmes rencontrés lors de la diffusion des métadonnées. Nous espérons que nos recommandations pourront être utilisées par les entreprises pour améliorer la communication avec les autres acteurs de la chaine. Pour cela, le groupe de travail NISO/UKSG KBART recommande que ce document devienne un code de bonnes pratiques (similaire à celle du projet TRANSFER) que les entreprises sont invitées à adopter. Nous envisageons également de créer et rendre publique une liste des fournisseurs de contenus et développeurs de bases de connaissances qui sont capables d’envoyer et utiliser des données dans le format recommandé.

9. Appendice A

9.1. Echantillon d’un fichier d’échange L’exemple suivant montre un fichier de collection complet pour un bouquet proposé par la Royal Society. Dans cet exemple, le fournisseur de contenus ne propose que des périodiques. Les identifiants présents ne sont donc que des ISSN, et non des ISBN. Les données seront échangées au format “délimité par des tabulations” mais, dans un souci de clarté et de lisibilité, elles sont ici présentées dans un tableau. Nous remercions la Royal Society pour la permission d’utiliser ce fichier dans notre exemple.

38

39

40

10. Glossaire Adaptation locale / Localization Procédé par lequel un établissement adapte les informations de la base de connaissances globale de son logiciel de résolveur de liens pour qu’elles reflètent ses états de collections et services locaux. Cela pourra inclure les restrictions sur les collections, le type de services, et les désignations de départements ou de groupes d’utilisateurs. Agrégateur / Aggregator Service bibliographique qui fournit un accès en ligne au texte intégral (numérique ?) de périodiques publiés par différents éditeurs. Les abonnements sont proposés pour des bouquets/packages de titres plutôt qu’au titre à titre. Les packages/bouquets varient généralement selon le type de bibliothèque (par exemple : spécialisée, universitaire, publique). Voir également l’entrée « hébergeur de plein texte ». Base de connaissances / Knowledge base Une base de données complète tenue à jour par un éditeur de résolveur de liens, et qui contient des informations sur les ressources électroniques telles que : listes de titres, dates de couverture, syntaxe des liens entrants, etc. Les bases de connaissances peuvent être personnalisées par chaque institution en fonction de ses collections locales. Par exemple, quels titres sont consultables en version électronique et lesquels sont détenus par la bibliothèque au format papier. On la nommera alors “base de connaissances locale”. Bouquets de contenus / Content packages Ensembles de contenus qui peuvent faire l’objet d’une acquisition à un coût moindre qu’une acquisition via des licences individuelles pour des composantes individuelles. Il peut s’agir par exemple de bouquets offerts par un seul éditeur (« big deals »), par des agrégateurs ou par des consortiums d’éditeurs. Catalogue de bibliothèque accessible en ligne / Online Public Access Catalogue (OPAC) L’interface publique du catalogue d’une bibliothèque. C’est un des modules du SIGB. On utilise aussi l’acronyme OPAC en français. Cible / Target C’est la ressource à laquelle on accède via un résolveur de liens. Les cibles typiques sont les contenus proposés par les plateformes des éditeurs, les catalogues d’un établissement, ou les archives et portails de contenu. Consortiums Groupement de bibliothèques qui coopèrent pour l’acquisition et la fourniture d’accès à des ressources. Dans certains cas il s’agit seulement de « groupement d’acheteurs », alors que dans d’autres, il peut s’agir d’un réseau étroitement intégré de bibliothèques associées. Les

41

éditeurs constituent également des consortiums afin de fournir des bouquets de ressources multi-éditeurs aux bibliothèques. Contenus gratuits / Free content Contenus auxquels n’importe quel individu disposant d’une connexion internet peut accéder. Une inscription préalable peut être demandée mais ni l’accès ni les contenus ne sont payants. Copie appropriée / Appropriate copy C’est la (ou les) version(s), parmi un ensemble de versions, qui correspond(ent) le mieux aux besoins d’un utilisateur donné (et rattaché à une institution donnée). Cette version sera vraisemblablement celle pour laquelle l’utilisateur dispose d’un accès au texte intégral, parce que la bibliothèque y souscrit. Dépendance contextuelle / Context sensitive La dépendance contextuelle signifie que la destination d’un lien est déterminée par le contexte de l’utilisateur, c'est-à-dire son affiliation institutionnelle ainsi que les préférences paramétrées par son institution. Développeur de base de connaissances / Knowledge base developer Une entreprise ou une institution qui compile, distribue et tient à jour une base de connaissances. Digital Object Identifier (DOI) Le système de Digital Object Identifier (DOI) (littéralement “identifiant d'objet numérique”) définit de façon unique une ressource numérique, que ce soit un article de revue, un chapitre de livre, un paragraphe, une image, ou un autre objet. Pour attribuer des DOI, les fournisseurs de contenu doivent être affiliés à un organisme d’enregistrement DOI et posséder les droits sur les contenus à identifier. Pour la syntaxe d’un DOI, reportez vous à la norme ANSI/NISO Z39.84-2005. Embargo L’embargo est une limitation de l'accès à une ressource créée par l'éditeur pour les distributeurs de leurs données, le plus souvent pour éviter l'annulation des abonnements individuels. Par exemple : le site Web d'un éditeur fournira les numéros actuels de ses publications électroniques, mais le site d’un agrégateur ne disposera que des numéros datés d’il y a plus d'un an. Fournisseur de contenus / Content Provider Un vendeur —généralement un éditeur, un agrégateur ou un hébergeur de texte intégral— qui offre des contenus à la vente ou à la location aux bibliothèques. La notion de fournisseur de contenus peut aussi recouvrir les services de résumé ou d’indexation, des portails d’agences d’abonnements et d’autres sources de liens OpenURL.

42

Fourniture de documents / Document delivery Fourniture de documents à l’unité à la demande et moyennant paiement (soit immédiatement soit via un compte prépayé) par le lecteur ou son représentant et à usage exclusif de ce lecteur. Un service de fourniture de documents est spécialisé dans la gestion des transactions. Il est généralement distinct de l’éditeur ou du premier hébergeur du contenu en texte intégral. Hébergeur de contenu en texte intégral / Full-text host Un vendeur, sous contrat avec un éditeur pour accueillir le texte intégral des publications dans une base de données unique. L’accès à cette base de données est activé par les abonnements à des titres individuels ou via la fourniture de documents article, plutôt que via une licence pour la base de données entière ou leurs parties. Index, Résumés, et Contenu en texte intégral / Indexes, abstracts, and full-text content Les index contiennent le titre de l’article, l’auteur et des informations bibliographiques sur le contenu du périodique (par exemple : titre de la revue, volume, numéro, année, et numéros de page). Une base de données de résumés et d’indexation contient les informations d’indexation précédentes assorties d’un résumé pour chacun des articles. Le contenu en texte intégral est le texte complet de l’article, et n’est généralement accessible que chez l’éditeur ou autres fournisseurs ou agrégateurs de contenu sous contrat avec l’éditeur. Libre accès / Open Access Modèle selon lequel le contenus en texte intégral sont gratuits à leur point d’accès, c’est-à-dire que les utilisateurs n’ont pas besoin de s’abonner ni souscrire de licence pour accéder au texte intégral. Licence / License Engagement contractuel entre un fournisseur de contenus et une bibliothèque ou un consortium. Parmi d’autres closes spécifiques, la licence détermine l’étendue des contenus disponibles en ligne (par exemple : l’utilisateur a accès aux numéros d’un périodique du volume X au volume Y). La licence peut aussi définir une période d’accès (par exemple : la licence est active pendant trois ans, période après laquelle il faut renouveler la licence pour bénéficier à nouveau de l’accès aux ressources). Les termes d’une licence sont propres à chaque établissement et seront enregistrés dans la base de connaissances locale. Lien au niveau de l’article / Article-level link URL qui conduit directement l’utilisateur à l’article recherché et non à la revue, au fascicule ou au numéro dans lequel l’article est publié. Un lien au niveau de l’article peut conduire l’utilisateur au résumé ou au texte intégral si l’utilisateur y a l’accès. Le lien au niveau de l’article peut être intégré à un lien OpenURL, sans que cela soit systématiquement le cas.

43

Liens au niveau du titre du périodique / Title-level links Une URL qui emmène un utilisateur sur le site du périodique qui les intéresse, plutôt qu’à un volume, à un numéro ou article spécifique. Les liens au niveau titre ne sont pas forcément au format OpenURL. Liens entrants (syntaxe) / Inbound linking (syntax) Les liens entrants sont les liens des pages de sites externes créant un lien vers votre site. Un fournisseur de contenus autorise les liens hypertextes entrants si il rend publique une syntaxe de lien qui autorise les autres à prédire l’adresse sur leur site, et ce, à différents niveaux (par exemple : les pages d’accueil de périodiques, les tables des matières, ou des articles spécifiques). Logiciel de management de ressources électronique / Electronic Resource Management (ERM) Terme large décrivant l’ensemble des outils logiciels utilisés par une bibliothèque pour gérer ses ressources électroniques. En français, on utilisera aussi l’acronyme ERM ou ERMS. Métadonnées / Metadata Les “données à propos des données”, c’est-à-dire les informations qui décrivent le contenu. Pour un article, ce seront son titre, les noms de ses auteurs, le titre de la revue dont il est originaire, le volume, le numéro et la page. OpenURL La norme OpenURL (ANSI/NISO Z39.88-2004, The OpenURL Framework for Context-Sensitive Services) détaille la syntaxe pour l’acheminement de métadonnées depuis les ressources informationnelles (les sources) jusqu’au résolveur de liens institutionnel, et de là, jusqu’aux services de la bibliothèque (les cibles). Paiement à la consultation / Pay-per-view Paiement en ligne en échange de la permission de lire le contenu d’un document individuel. C'est le moyen standard par lequel les lecteurs peuvent obtenir un article individuel ou un livre (ou le chapitre d'un livre) si eux ou leur établissement ne possèdent pas d’abonnement à la ressource contenant le document. Ce service est fourni par les éditeurs et les hébergeurs de contenu en texte intégral. Personalisation / Customization Processus par lequel une institution personnalise les informations contenues dans la base de connaissances du logiciel du résolveur de liens afin de refléter ses collections propres et les services qu’elle propose. La personnalisation comprendra les restrictions dans l’utilisation des collections, les services proposés, les accès par groupe ou par département. Egalement couramment désigné par les termes “localisation” et “configuration locale”.

44

Résolution d’un DOI / DOI resolution Les DOI sont enregistrés dans une base de données avec les métadonnées qui décrivent l’objet identifié et une URL actuelle pour cet objet. Les DOI peuvent être résolus en les concaténant à l’URL de base “http://dx.doi.org”. Le lien est utilisé pour interroger la base de données centrale des DOI, qui recherche l’URL courante associé à l’objet et rediriger le navigateur de l’utilisateur vers son emplacement. CrossRef (http://www.crossref.org/) est l’organisme officiel d’enregistrement des liens DOI pour les publications savantes et professionnelles. Résolveur de liens / Link resolver Un "résolveur de liens” ou “serveur de liens”, est un outil logiciel qui analyse une OpenURL, en extrait les éléments qui décrivent un article de périodique donné, et les utilise pour créer un lien prévisible vers le ou les services appropriés, identifiés par la bibliothèque de l'utilisateur. SFX C’est le premier et l’un des nombreux résolveurs de liens commerciaux disponibles sur le marché. SFX a été développé par Herbert van de Sompel, puis commercialisé par Ex Libris. Vous trouverez une liste des autres résolveurs disponibles aujourd’hui sur : http://www.loc.gov/catdir/lcpaig/openurl.html. Site passerelle / Gateway Un site qui redirige les utilisateurs vers des documents en texte intégral, sans héberger lui-même ces documents. Par exemple, un site d’agence d’abonnements qui authentifie l’utilisateur et le redirige vers le texte intégral sur le site de l’éditeur. Source / Source C’est la ressource qui crée une OpenURL et, de là, mène à un résolveur de liens. La source peut être un site dans son ensemble (par exemple une base de données, la plateforme d’un éditeur, etc.) ou une référence bibliographique donnée, sur ce site. Syntaxe d’un lien / Link-to syntax La formule par laquelle des liens vers des pages spécifiques dans un site Web peuvent être construits. Ces liens sont habituellement constitués d’une adresse hypertexte de base et d’une série de métadonnées / identifiants. Certains fournisseurs de contenus respectent la syntaxe OpenURL pour permettre les liens entrants, d’autres basent leur syntaxe sur des identifiants propriétaires mais prévisibles. Système Intégré de Gestion de Bibliothèque (SIGB) / Integrated Library System (ILS) Un ensemble intégrés de logiciels pour gérer les différentes tâches d’une bibliothèque.

45

10.1. Bibliographie Chandler, Adam. “Results of L’Année philologique online OpenURL Quality Investigation.” In Mellon Planning Grant Final Report. February 2009. Disponible sur : http://metadata.library.cornell.edu/oq/files/200902%20lannee-mellonreportopenurlquality- final.pdf CrossRef. Disponible sur : http://www.crossref.org COinS Generator. Disponible sur : http://generator.ocoins.info Culling, J. Link Resolvers and the Serials Supply Chain. Oxford: Scholarly Information Strategies, 2007. Disponible sur : http://www.uksg.org/projects/linkfinal ISSN International Centre. Disponible sur : http://www.issn.org ISO 8601:2004 Data elements and interchange formats -- Information interchange -- Representation of dates and times. Geneva: International Organization for Standardization, 2004. Library of Congress. US ISSN Center Homepage. Disponible sur : http://www.loc.gov/issn Library of Congress, Portal Applications Issues Group. OpenURL Resolver Products & Vendors. Disponible sur : http://www.loc.gov/catdir/lcpaig/openurl.html National Information Standards Organization (U.S.). ANSI/NISO Z39.84-2005, Syntax for the Digital Object Identifier. Bethesda, Md.: NISO, 2005. Disponible sur : http://www.niso.org/standards/z39-84-2005/ National Information Standards Organization (U.S.). ANSI/NISO Z39.88-2004, The OpenURL Framework for Context-Sensitive Services. Bethesda, Md.: NISO, 2004. Disponible sur : http://www.niso.org/standards/z39-88-2004 NISO. KBART (Knowledge Base And Related Tools) Working Group. Disponible sur : http://www.niso.org/workrooms/kbart. Voir aussi : http://www.uksg.org/kbart NISO. OpenURL Quality Metrics Working Group. Disponible sur : http://www.niso.org/workrooms/openurlquality OCLC (OpenURL Maintenance Agency). Registry for the OpenURL Framework - ANSI/NISO Z39.88-2004. Disponible sur : http://openurl.info/registry

46

47

The British Library. ISSN UK Centre. Disponible sur : http://www.bl.uk/bibliographic/issn.html The University of Melbourne. OpenURL Generator Help. Disponible sur : http://search.lib.unimelb.edu.au/help/openurlgen.html UKSG. KBART: Knowledge Bases And Related Tools Working Group. Disponible sur : http://www.uksg.org/kbart. Voir aussi : http://www.niso.org/workrooms/kbart