1. DEFINITION DU BESOIN ESSENTIEL
1.1 RECHERCHE DES INFORMATIONS
1.1.1 Cavités
1.1.2 Bibliographie
1.2 IMPORTATION DES INFORMATIONS
1.3 EXPORTATION DES INFORMATIONS
1.4 MISE A JOUR
1.5 PERENNITE
2. ANALYSE DES BASES DE DONNEES EXISTANTES
2.1 BASE DE DONNEE DE CAVITES
2.1.1 Système BALSAN
2.1.2 Fiches BRGM
2.1.3 Inventaire spéléo
2.1.4 Projet Bifteck
2.2 INDEX BIBLIOGRAPHIQUE
2.2.1 Bulletin Bibliographique Spéléologique
2.2.2 Index de revues spéléologiques
2.3 ANALYSE DE CES STRUCTURES PAR RAPPORT AU BESOIN
2.3.1 Recherche des informations
2.3.2 Importation des informations
2.3.3 Exportation des informations
2.3.4 Mise à jour
2.3.5 Pérennité
2.3.5.1 Pérénité de la structure
2.3.5.2 Pérénité des informations
2.3.6 Bilan
3. ETUDE D'UN SYSTEME DE BASE DE DONNEE REPONDANT AU BESOIN.
3.1 FAISONS SIMPLE
3.2 QUE REPRESENTE UNE LIGNE
3.2.1 Typiquement, dans les BDS, une ligne représente une cavité. Est ce le bon choix ?
3.2.2 Pourquoi tout le monde utilise-t-il cette structure ?
3.2.3 Que doit représenter une ligne ?
3.3 QUE REPRESENTE CHAQUE COLONNE
3.3.1 Une seule colonne est-elle suffisante ?
3.3.2 Quelles colonnes sont indispensables au besoin ? (voir chapitre 1.1)
3.3.2.1 Pour les cavités :
3.3.2.2 Pour la bibliographie :
3.3.3 Quelques explications sur les liens
3.3.4 Les autres besoins
3.3.4.1 Importation des informations
3.3.4.2 Exportation des informations
3.3.4.3 Mise à jour
3.4 QUE MET-ON DANS LES CASES
3.5 ETHIQUE SPELEO
4. DESCRIPTION ET UTILISATION DU SYSTEME DE BASE DE DONNEES A L'USAGE DES SPELEOLOGUES
4.1 DESCRIPTION DES CHAMPS
4.1.1 Champ : INDEX
4.1.2 Champ : CORRECTION
4.1.3 Champ : ENTREE
4.1.4 Champ : JONCTION
4.1.5 Champ : NOM
4.1.6 Champ : COORDONNEES
4.1.7 Champ : XLONGIT
4.1.8 Champ : YLATIT
4.1.9 Champ : ZALTIT
4.1.10 Champ : DENIVELÉ
4.1.11 Champ : POINTBAS
4.1.12 Champ : DEVELOPPEMENT
4.1.13 Champ : COMMUNE
4.1.14 Champ : MASSIF
4.1.15 Champ : DEPARTEMENT
4.1.16 Champ : PAYS
4.1.17 Champ : VALIDITÉ
4.1.18 Champ : ARCHIVEUR
4.1.19 Champ : ORIGINE
4.1.20 Champ : LANGUE
4.1.21 Champ : OUVRAGE
4.1.22 Champ : TITRE
4.1.23 Champ : AUTEUR
4.1.24 Champ : PARUTION
4.1.25 Champ : CLEFS
4.1.26 Champ : INFORMATIONS
4.2 UTILISATION DE LA BASE
4.2.1 Consultation de la base
4.2.2 Ajout d'enregistrements dans la base
4.2.3 Mise à jour, fusion de deux bases de données
4.2.4 Création d'une nouvelle base de données
4.2.5 Gestion des bases de données
4.3 REGLES D'UTILISATIONS
4.3.1 Accès à la base de données
4.3.2 Copyright
4.3.3 Vente d'informations
Cette question est tout à fait logique, je me la suis posé il y a quelques années, et, en tant que spéléologue explorateur, j'ai commencé par chercher une base de données contenant les informations que je recherche.
Sur le Vercors, je l'ai trouvée chez Pelloche, elle contient plus de 3200 phénomènes karstiques. Pour la Chartreuse, il y a l'inventaire papier " Chartreuse souterraine " de 1985. Pour la bibliographie, il y a aussi l'index des " Scialet " (revue du CDS38), et l'incontournable BBS. Pour l'ensemble de l'Isère, l'inventaire de Choppy est ancien (1964), mais peut apporter des informations.
Finalement, c'est dommage que toutes ces informations ne soient pas regroupées dans une même base de données, ce serait plus simple. Il suffirait que chacun rentre les informations dont il dispose, et qui ne sont pas encore rentrées, pour que progressivement la base s'enrichisse.
Ainsi, j'ai voulu ajouter dans la base de données de Pelloche, les informations de quelques ouvrages rares de ma bibliothèque.
Cependant, il y a un problème, si je mets à jour la base de données, et que Pelloche fait de même de son coté, comment va-t -on pouvoir les réunir sans perdre le travail de l'un, ou de l'autre ? En fait, si ce n'est pas prévu au départ, il est à peu près impossible de travailler à plusieurs en même temps sur une base de données.
J'ai donc cherché une base de données prévue pour travailler à plusieurs en même temps, et je n'ai rien trouvé. J'ai par contre eu l'occasion de discuter avec de nombreux spéléos sur les bases de données, cela m'a permis d'avoir une vue d'ensemble sur ce qui existe, et les particularités souvent très intéressantes des différentes structures.
J'avais beaucoup d'espoir dans le projet Bifteck, mais il inclut lui aussi la notion de base de données maître au niveau départemental, et esclave. On ne peut saisir des données sans passer par une mise en cohérence dans la BD maître. Par contre, la structure de Bifteck résulte d'une analyse très complète des informations utiles aux spéléologues, elle est pour cela très intéressante.
Le but de cet article est donc de définir le système de base de données qui repond à mon besoin, mais aussi au besoin des autres spéléos, et qui permette de travailler ensemble.
Je veux pouvoir sélectionner un ou plusieurs gouffres par leur nom ou leurs coordonnées et obtenir :
Je veux pouvoir obtenir une liste des cavités d'un massif, d'une commune, d'un département.
Je veux pouvoir la trier par développement ou profondeur.
Je veux pouvoir sélectionner des articles par une recherche sur le titre, par mot-clef, par auteur, ou par ouvrage, et obtenir :
Je veux pouvoir trier les résultats par ordre chronologique de parution.
Il existe déjà des informations sur les gouffres provenant d'autres bases de données ou inventaires, je veux pouvoir les incorporer à ma base de donnée sans pertes d'informations.
Je veux pouvoir donner ces informations à d'autres spéléos qui n'ont ni le même ordinateur (ils n'en ont peut-être même pas !), ni le même logiciel, ni les mêmes besoins.
Les utilisateurs doivent pouvoir enrichir le système avec des informations sans dépendre d'un responsable, pas de base de données maître ou esclaves.
La structure doit être très simple pour être accessible à tous.
La fusion de deux bases de données doit s'effectuer sans provoquer de conflits ou pertes d'informations, chaque base de données s'enrichit des nouvelles informations apportées par l'autre.
Le système ne doit pas être dépendant d'un logiciel ou d'un ordinateur, leur duré de vie est trop courte. Il doit plutôt être considéré comme un format d'échange compatible avec toutes les bases de données existantes.
De nombreux inventaires sont basés sur le système BALSAN.
(BALSAN L. - 1946, Spéléologie du département de l'Aveyron; Mém. Soc. Lettres Sc. Arts Aveyron t. 26, 5-315)
Liste des paragraphes du système Balsan pour chaque cavité :
Le format des paragraphes est relativement libre.
Chaque cavité est repertorié par une fiche recto-verso plus d'eventuelles annexes.
Cette fiche est inspirée du système BALSAN, les paragraphes sont détaillés par de très nombreuses lignes à completer, c'est une façon d'indiquer les informations à y mettre.
Elle comprend des informations particulières :
Typiquement un inventaire spéléo comprend les informations suivantes :
Mais aussi, pour les grandes cavités :
Avec parfois :
Lorsque ces inventaires sont sous forme papier, ils sont complétés par des listes alphabétiques, et des listes triées par coordonnées facilitant les recherches.
Le paragraphe bibliographie peut être constitué de numéros faisant référence à une liste d'ouvrages bibliographiques.
Le projet Bifteck est un projet informatique d'organisation et de consultation des données spéléologiques. Il en est actuellement à la phase de définition d'un cahier des charges de réalisation d'un outil informatique. Ce cahier des charges sera transmi à des professionnels pour la réalisation du projet.
La structure utilisée est celle d'une base de données relationelle, c'est à dire qu'elle est constituée de tables qui contiennent des champs, et qui sont liées entre elles par des relations.
Une trentaine de tables sont déjà définies (cavités, partie de cavité, captages, communes, etc...)
Chaque table contient jusqu'à une quinzaine de champs (Situation, courant d'air, etc...)
Des relations relient le tout (cavités " lié à " points, salle, puits, siphon, partie de cavité, etc...)
Autant dire que la structure est assez complexe et indescriptible en un simple paragraphe, une interface ergonomique est prevue pour que cette complexité soit transparente pour l'utilisateur.
La définition de cette structure est le fruit d'une analyse très profonde, les points intéressants soulevés sont :
Ce bulletin recense toutes les articles relatifs à la spéléologie parus chaque année dans le monde entier, environ 4000 références.
Sa structure est simple, par article elle décrit :
Les index de revues peuvent être orientés vers la recherche de cavité ou d'articles.
Index de recherche de cavité, elles sont classées par ordre alphabétique, l'index contient :
Index de recherche d'articles, ils sont classés par auteur, sujet, régions, l'index contient :
Les chapitres qui suivent font référence aux chapitres de définission du besoin.
Dans l'ensemble des structures existantes, la recherche de l'information est relativement facile.
Toutefois, lorsque l'on recherche une bibliographie relative à une cavité, les références indiquées ne permettent pas toujours de faire ressortir les articles les plus importants.
L'importation des données d'une structure dans une autre se limite aux champs qui sont communs aux deux structures, les autres données sont perdues.
Les données des structures faisant appel à des tables (example : liste de références bibliographiques) sont très difficiles à importer.
Dans toutes les structures, l'importation de nouvelles données provoque des conflits.
Par example : Une cavité a un jeu de coordonnées. Si une donnée importée concerne la même cavité, mais avec d'autres coordonnées, il faut faire un choix, donc intervention de l'utilisateur qui doit rechercher quelles sont les bonnes, cela peut être long et fastidieux.
Si le support est informatique, l'exportation des données est en général facile, il est possible de générer des listes de données classées et sélectionées pour une utilisation spécifique.
Toutes les structures actuelles nécéssitent une base de données maître sur laquelle les informations sont rentrées. La saisie peut éventuellement être faites sur des bases de données esclaves, mais leur intégration dans la base doit se faire sur la BD maître par un responsable chargé de regler les conflits au fur et à mesure qu'il apparaissent.
Le seul moyen de ne pas avoir de conflits est de séparer la base de données en sous bases en veillant à ce qu'elle ne se recouvrent pas. Par exemple, le BBS est divisé en régions pour la saisie des publications.
Pour les cavités la séparation par région est moins facile, car si une region peu esperer recenser l'ensemble des publications régionales, elle ne peut pas recenser l'ensemble des informations parues à travers le monde sur les cavités qu'elle contient. La décentralisation de la saisie des données pour le BBS est donc difficilement transposable pour une base de données de cavités.
Les structures de base de données spéléo sont généralement simples, il est aisé de les adapter à un gestionnaire de bases de données quelquonque, la pérénité de la structure est donc assurée.
Certaines bases de données comme le projet Bifteck, ont une structure plus complexe, si le logiciel créé devient obsolete, il peut être plus difficile de transferer sont contenu vers un autre gestionnaire de base de données.
Sur toutes les structures de base de données de cavités, la mise à jour continuelle des informations entraîne une perte d'information. Par exemple, si un gouffre accroit son développement de 48256m à 51369m, la mise à jour supprime l'information qu'il faisait 48256m, ce qui est dommage puisque cette information est utile pour celui qui veut connaitre la première qui a été faite chaque année.
Sur les bases de données bibliographiques, il n'y a pas ce problème.
Aucune base de données analysée au chapitre 2 ne répond correctement au besoin défini au chapitre 1. Les points faibles sont :
Ce chapitre présente les raisonnements qui ont permis de définir le système de base de données spéléo. Il est assez rébarbatif et déstructuré, il s'adresse à ceux qui veulent avoir une justification des choix qui ont été fait.
Pour tous ceux qui s'intéressent plus au résultat, le système est décrit complètement dans le chapitre 4.
Le projet d'un système répondant complètement au besoin peut sembler utopique, mais essayons quand même de le définir.
Pour être compréhensible par tous, portable sur toutes les machines, utilisable avec tous les logiciels de base de données, voire même sur un simple tableur ou un traitement de texte, la structure de BD doit être le plus simple possible, c'est-à-dire un fichier de texte ou chaque ligne représente un enregistrement, et les champs sont délimités par des tabulations. C'est le format de base d'échange de données entre SGBD hétérogène (SGBD : système de gestion de base de données).
Il reste à définir ce que représente une ligne, ce que représente chaque colonne, et ce que l'on met dans les cases.
Après analyse des bases de données existantes, on voit que le principal problème vient de la perte d'informations.
Ce problème vient du fait que l'élément de base de la BD (la ligne) est la cavité.
Une cavité peut changer de nom, de coordonnées, de développement, etc... Cela oblige à surcharger les champs (nom+synonyme, liste biblio), ou à changer le contenu des champs, donc pertes de l'information qu'ils contenaient au départ.
C'est historique, dans les bases de données papier, on recherche des informations sur les cavités, donc une fiche représente une cavité. Dans les BD informatiques, il n'y a plus aucune raison de faire coïncider la structure interne de la base avec le format de sortie (une fiche par cavité)
Pour éliminer le problème de perte d'informations, il faut que la base de données s'enrichisse par ajout d'informations et non par des mises à jour d'informations. Chaque ligne doit donc représenter une information valable sans limitation de temps.
Par exemple : dans le périodique " SCIALET N°25 " le gouffre " Scialet JUJU " a pour coordonnées " 849,95 ; 323,242 ; 1198 " , développement " 2173m ", etc...
Le nombre de colonnes doit être réduit pour garder une structure simple. Elles doivent contenir toutes les informations nécessaires pour répondre au besoin.
Ce serait parfait, mais ce n'est pas pratique. Si, par exemple, on veut trier les gouffres en fonction de leurs coordonnées il faut :
Le plus simple est donc de créer un champ pour chaque élément d'information sur lequel le besoin demande un tri, une sélection, ou une classification.
Ce dernier champ peut être remplacé par le contenu du chapitre suivant.
Ce dernier champ peut être remplacé par le contenu du chapitre précédent, les deux chapitres sont complémentaires, il est intéressant de les fusionner.
Chaque ligne est donc composé de champs concernant la référence bibliographie, et de champs concernant les informations sur la cavité contenues dans la référence bibliographique.
Dans les champs précédents, on éprouve le besoin de relier une information ou une cavité à une autre information, cela s'appelle un lien.
Pour qu'un lien puisse pointer sur une information ou une cavité, il faut les identifier par un code unique.
Par exemple :
Malheureusement, le besoin exprimé plus haut, demande que plusieurs spéléos puissent enrichir la base de donnée sans avoir besoin de se concerter.
Comment garantir qu'ils ne choisissent pas le même numéro ?
La solution parfaite n'existe pas, le seul compromis possible est de diminuer ce risque en choisissant des numéros d'enregistrement avec beaucoup de chiffres, je propose :
19980316234208 si l'information est enregistrée le 16/03/1998 à 23:42:08
Ce type de codage permet, de plus, le tri des enregistrements par ordre chronologique.
De la même façon, une cavité sera identifiée par le numéro du premier enregistrement qui y fait référence (d'ou l'intérêt de l'ordre chronologique).
Le but est de rapatrier le contenu des autres bases de données existantes, qui n'ont pas la même structure, sans perte d'informations, et sans conflits.
Le principe est de bricoler pour faire rentrer, au mieux, les informations dans les champs correspondants, de créer les numéros d'enregistrements de chaque information, et d'y ajouter les informations manquantes (pays, département, ...).
La plupart de ses opérations peut être plus ou moins automatiques en fonction des outils informatiques dont on dispose.
Les informations qui ne correspondent à aucun champ peuvent être enregistrée dans un champ " informations diverses ", elles peuvent conserver une structure dans ce champ spécifique en utilisant un caractère séparateur comme une barre verticale " | "
Si un champ de la base importée contient des informations à placer dans plusieurs colonnes différentes, l'idéal est de séparer les différentes informations pour les ranger dans les colonnes correspondantes, mais il est également possible de ranger ces informations dans plusieurs colonne en même temps (colonnes utilisées pour la recherche) ou de laisser les colonnes vides (colonnes utilisée pour le tri).
Les conflits sont par principe impossibles puisque l'on ajoute des informations qui sont indépendantes de celles présentent dans la base. Au pire, si l'information a déjà été enregistrée par un autre spéléo, elle apparaîtra deux fois dans la base.
La phase la plus longue de l'importation d'une nouvelle base est d'établir les liens de cavités avec la base existante. Cette phase nécessite de comparer les noms et les cordonnées pour trouver d'éventuels homonymes ou synonymes. Elle est facilitée si l'on utilise les possibilités de tri ou de sélection d'un SGBD.
De même que pour les autres structures, l'exportation vers une autre base de données, ou vers un support papier, ne pose pas de problème.
Problème de la redondance des informations :
Chaque cavité peut faire référence à de nombreuses informations. Cependant, si l'on veut obtenir juste une liste de cavités avec leurs coordonnées, il faut faire un choix parmi toutes les informations présentes dans la base.
Le meilleur critère est de dire que les informations les plus récentes sont les plus à jours, c'est la date de l'information qui compte et non la date de la publication de cette information. Il faut donc rajouter un champ à la structure : la date de validité de l'information (a ne pas confondre avec la date d'enregistrement, ou d'édition).
Le format peut être " 1998 " ou " 199803 " il permet une classification chronologique en utilisant un tri alphabétique.
Dans le principe, la mise à jour de sa propre base de donnée est relativement simple, mais dans la pratique, des problèmes peuvent survenir.
Que faire si une information de la base est fausse ?
Que faire si une information publiée est fausse ?
Comment faire pour connaître le code d'une cavité qui n'est pas dans la base ?
Comment faire si, lors d'une fusion de deux BD, le code d'une cavité et différent entre les deux bases ?
Comment connaître la validité d'une information ?
S'il reste un doute sur une information qui peut être, importante, il est possible de la vérifier à partir de la source d'information, ou auprès de celui qui l'a rentrée dans la base. Pour connaître cet " archiveur " il faut prévoir un champ spécifique supplémentaire.
Les cases contiennent du texte. Ce texte est codé informatiquement suivant l'alphabet ISO-Latin-1 (ISO 8859-1), c'est un standard très répandu comprenant tous les caractères accentués utilisés dans les langues occidentales.
Des caractères sont réservés, les " a la ligne " (décimal 10) et " tabulation horizontale " (décimal 09) sont utilisés pour séparer les enregistrement et les champs (ligne et colonnes), ils ne peuvent donc pas apparaître dans les cases.
Pour définir une structure de données dans la colonne " informations diverses " il est possible d'utiliser un caractère séparateur quelconque comme la " barre verticale " (décimal 124)
La colonne " informations diverses " peut également inclure du texte au format HTML (remplacer les caractères réservés par des espaces), ce format permet d'inclure des documents avec mise en page, image, tableaux, etc... Les images sont stockées en dehors de la base, dans un répertoire informatique " IMAGES " placé au même endroit que la base de donnée. Le fichier contenant l'image, a un nom commençant par le numéro de l'enregistrement qui y fait référence (le système informatique utilisé doit savoir gérer des noms de fichiers d'au moins 15 caractères).
Les cases des colonnes utilisées pour trier les enregistrements doivent être homogène pour une zone géographique donnée.
Les autres cases doivent suivre, dans la mesure du possible, le même format.
De nombreux exemples montrent que le travail des spéléologues est souvent exploité à des fins mercantile, voire même contre leur propre intérêt. Il n'est donc pas souhaitable pour les spéléologues de diffuser de façon totalement libre le contenu des bases de données. Des limites doivent être établies.
La structure de la base de données est un simple tableau. Les lignes de ce tableau ne doivent jamais être modifiées ou supprimées, la mise à jour de la base de données se fait en rajoutant des lignes.
Les champs sont nombreux, mais beaucoup peuvent être remplis automatiquement au recopiés lors d'une saisie.
La structure de la base de données est définie sous forme d'un texte, elle peut donc être importée sur tous les systèmes de gestion de base de données (SGBD), il est ainsi possible d'intervenir sur cette base avec un outil bien adapté.
Pour rechercher toutes les informations concernant une entrée de cavité, il faut commencer par trouver un enregistrement concernant cette cavité (recherche par nom). Les champs ENTRÉE et JONCTION contiennent respectivement les numéros d'identification de l'entrée de la cavité et d'une autre entrée jonctionnant avec la cavité, il est ainsi possible de sélectionner les enregistrements contenant ces numéros, et de recommencer si de nouveaux numéros apparaissent.
Certains enregistrements contiennent des bibliographies qui font référence à des listes incluses dans la base de données.
Pour trier les enregistrements concernant une cavité, il faut utiliser la colonne VALIDITÉ, les informations les plus à jour sont les plus récentes.
Les enregistrements existants ne doivent jamais être modifiés, seuls certains champs vides peuvent être remplis.
L'enrichissement de la base se fait en ajoutant de nouveaux enregistrements.
Les formats et contenus des champs doivent être respectés. (voir chapitre : Description des champs)
Les champs ENTRÉE et JONCTION doivent être remplis à partir des index définis dans la base de données de la zone géographique. Si cette base n'existe pas, il faut laisser les champs vides en attendant qu'elle soit créée.
Les informations complémentaires sont placé dans les champs CLEFS et INFORMATIONS. Dans la mesure du possible, il faudra y inscrire :
L'opération consiste à regrouper les deux bases de données en éliminant les doublons. Un doublon est une paire d'enregistrement ayant le même champ INDEX, plusieurs cas peuvent se présenter :
Avant toute mise à jour, il est souhaitable, si l'on a les informations, de remplir les champs ENTRÉE et JONCTION sur les enregistrements ayant le champ NOM rempli.
Pour avoir une base saine, la création d'une nouvelle base de données sur une zone géographique doit être la synthèse du plus grand nombre possible d'informations. Le but est de définir une liste d'index comprenant la plupart des cavités, cette liste permet de remplir les champs ENTRÉE et JONCTION lors des mises à jour ultérieures de cette base.
La création d'une base commence donc par une phase de recherche des autres bases, des inventaires, topoguides, index, ouvrages sur une zone, liste de cavités prospectées sur un secteur, etc...
De préférence, on créera une base par département, en concertation avec le Comité Départemental Spéléologique local.
La gestion de cette structure de base de données est grandement simplifiée par l'absence de base de données maître, chacun est libre de l'enrichir à partir des informations dont il dispose.
Les nouvelles informations rentrées se propagent d'une base à l'autre par des fusions. Une information sur une cavité locale mais publiée dans une autre zone, pourra ainsi parvenir dans la base de données locale à la suite d'une ou plusieurs fusions de base de données.
RÈGLE DE BASE : Cette structure de base de données est conçue pour la communauté des spéléologues, les règles de son utilisation doit être guidée par le souci de maximiser l'intérêt de l'ensemble des spéléologues et non un intérêt individuel. Les informations contenues dans cette base ne doivent être diffusée qu'avec la certitude qu'elles ne seront pas utilisées contre ou aux dépend des spéléologues.
Les règles précises sont à définir par la structure spéléologique locale, les chapitres suivant en définissent les grandes lignes.
Il n'est pas souhaitable de faire connaître l'existence de cette base de données en dehors du milieu spéléologique, ceci afin d'éviter d'éventuelles convoitises nuisibles.
Trois niveaux de confidentialité sont définis : Accès libre, accès limité, accès privé.
Les champs suivants sont en accès libre :
Les informations suivantes ne doivent pas être incluses dans la base, sauf pour un usage strictement privé :
La base de donnée n'est accessible qu'aux spéléologues agréés par la structure spéléologique locale (CDS). Pour être agréé il faut :
L'accès est gratuit pour les spéléologues agréés.
Les informations de cette base ne sont pas du domaine public, en cas de litiges, la loi sur la protection des droits d'auteur s'applique.
Les textes, dessins, photos, doivent conserver le nom de l'auteur dans la base de données.
Les informations de cette base ne doivent pas être publiées dans un ouvrage grand public (topoguide par exemple) sans l'accord des auteurs.
Réciproquement, la vente d'un ouvrage grand public ne doit pas être perturbée par l'incorporation de son contenu dans la base de données.
Le CDS peut vendre les informations de son département extraite de la base en respectant les règles. (Intérêt communautaire, copyright)
Des exemples d'enregistrements suivant cette structure en html, ou un fichier Excel 5 à télécharger