Recommander

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

  • Dernière Modification
    jeudi 27 septembre 2012

 

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.

5.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 oeuvre. 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.

5.2 L’échange

5.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.

FTP[note1] 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 5.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 5.3.1.2.

5.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.

5.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 développeurs de bases de connaissances. Un lien vers le formulaire web sera fourni sur les pages Web du site KBART.

5.3 Les données

5.3.1 Le format des données

5.3.1.1 Les fournisseurs de contenus fourniront des métadonnées dont les valeurs seront délimitées par des tabulations[note2]. 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 virgules[note3]. 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és[note4].

5.3.1.2 Le fichier sera nommé “[NomDufournisseur]_AllTitles_[AAAA-MM-JJ].txt”. Par exemple : JSTOR_AllTitles_2008-12-01.txt.

5.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é.

5.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.
Les fournisseurs et les bénéficiaires peuvent convenir à l'avance de la meilleure façon de présenter les noms de collections complexes. 

5.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.

5.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.

5.3.1.7 Chaque ligne du fichier contiendra une publication, avec une colonne pour chaque champ indiqué dans le chapitre 5.3.2 qui décrit les champs de données.

5.3.1.8 Les données seront fournies avec des en-têtes de colonne (voir le chapitre 5.3.2) et sans ligne vide entre l'en-tête de colonne et la première ligne de contenu.

5.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.

5.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 5.3.2.

5.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.

5.3.2 Les champs de renseignements

5.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

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”.

5.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.

5.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 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.

5.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.

5.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.

5.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.

5.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.

5.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.

5.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.

5.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.

5.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.

5.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.

5.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.

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.

5.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.

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.

5.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 :

  • fulltext[note5] : 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 articles[note6] : 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).
  • abstracts[note7] : 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 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”.

5.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.

5.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.