Fiche technique : indexation

Dans l’environnement Web, tout mot et tout groupe de mots présents dans un instrument de recherche constituent potentiellement des « points d’accès » à cet instrument, puisque la recherche en plein texte permet de retrouver directement toutes les occurrences de ces mots et groupes de mots. La recherche en plein texte présente l’avantage de l’exhaustivité, mais n’assure pas nécessairement la pertinence des réponses : chaque mot y est traité de manière « automatique » comme une simple suite de caractères, indépendamment de sa sémantique, par opposition à l’opération d’indexation qui reflète un choix délibéré de la part du catalogueur.

C’est pourquoi l’élaboration d’une véritable indexation normalisée représente une phase importante de la création d’un instrument de recherche, car elle permet de rendre ce dernier plus facilement exploitable par l’utilisateur, par le biais de critères de recherche spécifiques clairement définis (recherche sur les titres, sur les sujets, sur les noms de personnes, etc.).

L’indexation ouvre en outre aux instruments de recherche des perspectives riches d’avenir. En offrant la possibilité de les mettre explicitement en relation avec des fichiers d’autorité qui associent des identifiants susceptibles d’être utilisés comme des URI à des noms de personnes, de collectivités, de concepts, etc., elle rend ces instruments de recherche potentiellement accessibles aux applications du « web sémantique ».

L’indexation consiste à utiliser des balises spécifiques pour encadrer les valeurs qui doivent alimenter les index. Ces balises d’indexation peuvent être posées par le catalogueur au fil du texte, dès la première occurrence d’un terme correspondant à une notion que le catalogueur souhaite indexer, ou être regroupées à part dans un ou des éléments Vedettes et accès contrôlés <controlaccess>.

Bonne pratique

Il est fortement déconseillé d’utiliser l’élément Index <index> et les éléments subordonnés Entrée d’index <indexentry> et Groupe de noms <namegrp>.

Les éléments Index <index> et Entrée d’index <indexentry> semblent à première vue, à en juger par leurs noms, se rapporter à l’activité d’indexation. Ils servent en réalité à introduire, dans le corps même d’un instrument de recherche, du texte qui a l’apparence visuelle et la fonctionnalité d’un index traditionnel tel qu’on peut en trouver dans un ouvrage imprimé ou un document dactylographié, c’est-à-dire une liste de termes associant à chacun de ces termes la localisation de chacune de ses occurrences au sein du document.

S’il s’agit bien d’un « index » au sens habituel de ce mot, il ne s’agit pas d’une « indexation » au sens informatique, puisque la création d’un tel index n’est pas liée à la création de points d’accès contrôlés : il ne s’agit que d’établir manuellement des liens entre différentes parties d’un instrument de recherche.

Un élément Index <index> contient une succession d’éléments Entrée d’index <indexentry> dont chacun est associé à un ou plusieurs éléments de lien pointant vers les composants <c> où figure la valeur que l’on souhaite voir apparaître dans l’index. Ces liens sont créés manuellement au moyen des éléments Référence <ref> et Pointeur <ptr> dont l’attribut TARGET contient l’identifiant (valeur de l’attribut ID) de chacun des composants vers lesquels devra renvoyer l’index. La création manuelle des liens au sein d’un élément <index> est donc coûteuse en temps de travail, est source d’erreurs, et représente un risque de non-pérennité des index si, pour une raison ou pour une autre, les identifiants des composants <c> sont amenés à changer au cours du temps, ou si une information est transférée d’un composant à un autre.


Bonne pratique

Les points d’accès sont encodés au fil du texte chaque fois que la possibilité existe.

C’est seulement lorsque l’encodage complet au fil du texte est impossible que les points d’accès sont inclus dans l’élément <controlaccess>, répétable et placé à la fin du <c>.

Il s’agit notamment des cas suivants :

  • le format EAD ne le permet pas (par exemple, <persname> ne peut être contenu dans <title>)
  • quand une entité indexée nécessiterait au moins deux attributs ROLE différents. Elle est alors indexée à la fois au fil du texte avec un attribut ROLE et dans <controlaccess> avec l’autre ou les autres valeurs d’attributs ROLE (cf. ex. 2).
  • quand le terme ne figure pas expressément dans la notice (expression trop générique ou terme déduit du contexte). Cf. ex. 3 et 4.

Exemples


1.  La DTD ne permet pas d'inclure un élément <persname> dans l'élément <title>
<c>
   <did>
      <unittitle><persname role="070" normal="Pagnerre, Louis (1845-19..)" source="BnF_catalogue_général" authfilenumber="ark:/12148/cb13005468h">Pagnerre, Louis</persname> : <title role="titre">Charles Gounod, sa vie et ses oeuvres</title></unittitle>
   </did>
   […]
   <controlaccess><persname role="sujet" normal="Gounod, Charles (1818-1893)" source="BnF_catalogue_général" authfilenumber="ark:/12148/cb138946384">Gounod, Charles (1818-1893)</persname></controlaccess>
</c>

2. Un même élément ne peut pas avoir plus d'un attribut ROLE à la fois ; ici l'auteur est aussi sujet du document décrit.
<c>
   <did>
      <unittitle>Autobiographie de la <persname role ="070" normal="Chesard de Matel, Jeanne-Marie">Mère Jeanne de Jésus Chesard de Matel</persname>, fondatrice de la congrégation du Verbe incarné au très-saint Sacrement de l'autel</unittitle>
    </did>
    […]
    <controlaccess><persname role="sujet" normal="Chesard de Matel, Jeanne-Marie">Chesard de Matel, Jeanne-Marie</persname></controlaccess>
</c>
3. Il n’est pas possible d'encoder des termes génériques dans un élément <persname> ; ici les termes "abesse de Montmartre" et "Reine, mère du Roy" peuvent correspondre à de nombreux noms de personnes.
<c>
   <did>
       <unittitle>La <title role="titre" normal="Vie de saint Denis">Vie de sainct Denis</title>, apostre de la France, faicte en vers françois, dédiée à la Reine, mère du Roy, par Madame l'abesse de Montmartre. Composée par M. <persname role="070" normal="Courtot, P.">P. Courtot</persname>, advocat au Parlement, en 1629</unittitle>
   </did>
   […]
    <controlaccess><persname role="070">Beauvilliers, Marie de (1598-1657)</persname></controlaccess>
    <controlaccess><persname role="280" normal="Marie de Médicis (reine de France ; 1573-1642)" source="BnF_catalogue_général" authfilenumber="ark:/12148/cb12545791d">Marie de Médicis (reine de France ; 1573-1642)</persname></controlaccess>
</c>
4.

<did>
   <unittitle>"Mission à <geogname role="sujet" normal="Vienne (Autriche)" source="BnF_catalogue_général" authfilenumber="ark:/12148/cb15238451r">Vienne</geogname>, 1867"</unittitle>
   <origination><persname normal="Dupont, Jean (18.. - .... ; secrétaire d'ambassade)">Dupont, Jean (18.. - .... ; secrétaire d'ambassade)</persname</origination>
</did>
[…]
<scopecontent><p>Une note d'une autre main, au verso de la page de titre, précise : "Carnet tenu par le secrétaire personnel de l'ambassadeur de France à Vienne, en poste de 1867 à 1869".</p></scopecontent>
<controlaccess><geogname role="sujet" normal="Autriche-Hongrie" source="RAMEAU" authfilenumber="ark:/12148/cb123809301">Autriche-Hongrie</geogname></controlaccess>
<controlaccess><persname role="sujet" normal="François-Joseph I (empereur d'Autriche ; 1830-1916)" source="BnF_catalogue_général" authfilenumber="ark:/12148/cb12239721g">François-Joseph I (empereur d'Autriche ; 1830-1916)</persname></controlaccess>

Normalisation des valeurs indexées

Les éléments qui comportent un attribut NORMAL (<corpname>, <date>, <famname>, <function>, <genreform>, <geogname>, <name>, <occupation>, <persname>, <subject>, <title>, <unitdate>) permettent de dissocier la forme affichée et la forme normalisée qui sert à alimenter les index informatiques.

Afin d’assurer la cohérence des index, il est primordial de remplir l’attribut NORMAL avec une valeur normalisée issue d’un référentiel clairement identifiable ou créée selon les normes. Il est donc recommandé, dans la mesure du possible, de s’appuyer sur les fichiers d’autorité disponibles dans la communauté des bibliothèques, qu’il s’agisse de fichiers gérés par l’établissement lui-même, ou de fichiers extérieurs (fichier d’autorité de la Bibliothèque nationale de France, du SUDOC, fichier national d’autorité-matière RAMEAU, etc.). Cette recommandation concerne tout particulièrement les noms de personnes <persname>, de collectivités <corpname>, de familles <famname>, de lieux <geogname>, les sujets <subject> et les noms non spécifiés <name>, et dans une moindre mesure les titres d’oeuvres <title>, lorsque ces titres sont contrôlés. Dans le cas de l’élément Genre et caractéristiques physiques <genreform>, on peut se contenter d’une simple liste fermée de valeurs autorisées, définie au sein de l’établissement ou du réseau.

Lorsqu’une valeur que l’on souhaite indexer n’est pas présente dans le fichier d’autorité auquel on fait habituellement appel, il faut toujours normaliser cette valeur selon les normes en usage dans les bibliothèques françaises (par exemple : NF Z 44-060 pour les noms de collectivités, NF Z 44-061 pour les noms de personnes et les titres).

Pour les éléments <date> et <unitdate>, il suffit de remplir l’attribut NORMAL avec des formes de dates normalisées selon la norme ISO 8601.

Lorsque l’attribut NORMAL est rempli au moyen d’une forme trouvée dans un référentiel, ce référentiel doit toujours être identifié au moyen de l’attribut SOURCE de l’élément d’indexation, et le numéro de la notice d’autorité concernée doit être indiqué dans l’attribut AUTHFILENUMBER. On peut s’appuyer sur ces attributs pour définir des spécifications informatiques permettant par exemple : de répercuter automatiquement dans les instruments de recherche les modifications apportées dans le fichier d’autorité ; d’enrichir les index au moyen des formes rejetées présentes dans les notices d’autorité ; d’établir des liens hypertextuels entre les instruments de recherche et le fichier d’autorité ; de remplir automatiquement un élément Biographie ou histoire <bioghist> avec les données présentes dans le fichier d’autorité ; de rendre les instruments de recherche accessibles aux applications du « web sémantique » par l’intermédiaire du fichier d’autorité, etc. (bien d’autres exploitations de ces données pourraient être envisagées).

Remarques

  1. L’élément Langue <language> ne comporte pas d’attribut NORMAL. Cependant, son indexation normalisée est effectuée grâce à l’attribut spécifique LANGCODE sous la forme d’un code unique normalisé. Cet élément comporte en outre un attribut spécifique SCRIPTCODE qui permet l’indexation d’un code d’écriture pour cette même langue.
  2. Concernant la constitution des « index de chaînes de caractères », qui permettent à l’utilisateur de formuler des recherches de type « par début de », il est à noter que la DTD EAD ne permet pas de gérer l’exclusion des premiers caractères d’une chaîne (par exemple : l’exclusion de l’article initial des titres, qui fait qu’un titre comme Le Rouge et le noir est classé à la lettre R et non à la lettre L). Il n’y a pas de moyen idéal de remédier à cet état de fait :
    • l’omission pure et simple des caractères à exclure (par exemple : NORMAL= »Rouge et le noir ») ou le rejet en fin de chaîne des caractères à exclure (par exemple : NORMAL= »Rouge et le noir (Le) ») risquent de rendre les index peu lisibles
    • l’indexation de l’article initial (par exemple : NORMAL= »Le Rouge et le noir ») est contraire aux traditions de catalogage.

Utilisation de l’attribut ROLE

Les éléments d’indexation <corpname>, <famname>, <geogname>, <name>, <persname>, <title> possèdent un attribut ROLE. Pour les valeurs de cet attribut, il faut se référer à la liste fermée de valeurs en usage dans l’établissement ou le réseau auquel il participe, par exemple dans le CGM-CCFr et dans Calames on utilise des listes restreintes de codes de fonctions Unimarc, enrichies de valeurs textuelles pour certains codes absents de la liste Unimarc (par exemple : role= »sujet ») ; à la BnF, ce sont les codes de fonctions Intermarc qui sont utilisés.

Mécanismes d’héritage

La notion d’héritage des informations du niveau le plus élevé de la structure hiérarchique de la description vers le niveau le plus bas est une notion importante en archivistique, qui est affirmée dès le paragraphe 2.4 de la norme ISAD(G) :

Non-répétition des informations. Au niveau adéquat le plus élevé, donner les informations communes aux différentes subdivisions. Ne pas répéter à un niveau inférieur l’information déjà présente au niveau supérieur.

DéMArch (§1.4) : « Dans une description à plusieurs niveaux, les informations fournies à chaque niveau hiérarchique concernent le niveau décrit et, par héritage, ses niveaux subordonnés. Le principe selon lequel une information doit être adaptée à son niveau de description implique que les informations communes aux composants doivent être données au plus haut niveau approprié — sans les répéter aux niveaux inférieurs — et que, à l’inverse, une information relative à l’un des composants doit être donnée uniquement au niveau de ce composant et non au niveau supérieur. »

La DTD EAD est donc conçue pour permettre d’appliquer ce principe d’héritage. En conséquence, le catalogueur doit garder présent à l’esprit que toute l’indexation qu’il établit à un niveau donné de l’instrument de recherche se répercute par héritage sur l’ensemble des niveaux subordonnés. Cf. fiche Surbalisage.


Print Friendly, PDF & Email