Doc/Champs et Index

Les concepts de champs et d'index sont ambigus et souvent mal employés. Voici la définition qui en est donnée dans la <ref>Fichier:AJLSM-Pleade-3-Manuel-d'administration.pdf</ref>.

Concepts

Champ

Dans Pleade, un champ est lié à la recherche : il s'agit d'un contenu qui peut être recherché individuellement. Toutes les recherches s'effectuent dans des champs, y compris la recherche « plein texte » qui s'effectue dans le champ nommé « fulltext » et qui n'a rien de particulier.

C'est au moment de la publication que Pleade « remplit » les champs avec des valeurs issues des documents EAD. Donc toute modification à la configuration des champs nécessite une republication pour en voir les effets.

Il y a différents types de champs, les plus courants étant les champs de type « mot » (« word ») ou les champs de type « valeur » (« field »).

Type « mot » (« word »)

Les champs de type « mot » sont destinés à des recherches de type « libre », c'est-à-dire où une analyse des mots est effectuée (suppression des mots vides, des majuscules, des accents, etc.) et où on exprime des requêtes constituées de un ou plusieurs mots ou expressions.

Type « valeur » (« field »)

Les champs de type « valeur » sont destinés à une recherche exacte, la plupart du temps depuis une liste de valeurs possibles.

Exemple de type de champs

Par exemple, si l'on considère la chaîne de caractères « François-René de Chateaubriand », on obtient :

• pour un champ de type « mot » : francois, rene, chateaubriand
• pour un champ de type « valeur » : François-René de Chateaubriand

Index

Les index dans Pleade servent à la navigation dans le cadre de gauche de la fenêtre de consultation des documents EAD. Pour que les index fonctionnent, des champs de recherche associés sont également nécessaires.

Les index peuvent aussi servir à la recherche. Dans ce cas ils sont considérés comme des champs comme tous les autres.

Paramétrage

Champs Simples

Remarques : Le fichier qui définit les champs simples est module-eadeac/conf/ead-fieldlist-base.xconf.

On peut se reporter à l’Doc/Annexe 1 pour la Doc/Annexe 1#liste des principaux champs de base. On peut également ouvrir le fichier ci-dessus pour observer, en particulier la syntaxe qui les définit.

Par exemple, le champ intitulé, construit à partir de l’élément <unittitle> est défini de la manière suivante :

<field name="unittitle" type="word"/>

On a donc un élément XML qui a pour nom <field>. Il a deux attributs :

1. Un attribut name qui a pour valeur le nom du champ qui, rappelons-le, est le plus souvent le nom de l’élément EAD correspondant. Ce nom sera réutilisé lorsqu’on aura besoin d’exploiter ce champ. Ce nom doit être unique pour chaque champ.
2. Un attribut type qui a pour valeur word.

On peut noter, au début de la liste, un champ particulier, que nous avons déjà également évoqué, le champ fulltext, qui est de type word, ce qui ne surprend pas, mais possède un attribut supplémentaire, default avec true comme valeur. Cela signifie qu’il est le champ de recherche par défaut. On n’a pas besoin de préciser que l’on veut chercher dans ce champ comme on peut le faire si l’on veut chercher dans un autre champ avec la syntaxe d’interrogation déjà vue : unittitle:Fortuné. On peut tout à fait imaginer définir un champ de recherche par défaut autre que le champ fulltext.

Revenons un peu plus en détail sur les caractéristiques d’un champ. C’est un élément <field> avec des attributs :

• name : le nom du champ
• type avec les valeurs possibles suivantes :
  • word ;
  • field ;
  • date : les champs correspondants permettent de faire des recherches sur des intervalles
  • unindexed : un tel champ n’est pas chercheable. À quoi sert-il alors ? Il peut être affiché avec les résultats de recherche.
• brief : permet d’indiquer si le champ doit être présent dans les résultats de recherche.
  • la valeur false, (par défaut), le champ n’est pas présent dans les résultats de recherche.
  • la valeur est true, il est présent.

La liste des champs de base n’a pas, a priori, à être modifiée.

Champs Agrégés

Remarques : Le fichier qui définit les champs agrégés est module-eadeac/conf/ead-aggregated-fields.xconf.

Il est possible de créer des champs supplémentaires en agrégeant deux ou plusieurs champs.

Par défaut, Pleade propose un champ « analysetitre » qui agrège l’intitulé et la présentation du contenu. Cela peut permettre, par exemple, d’avoir, dans un formulaire de recherche, une zone « Analyse » pour interroger avec des mots qui se trouveraient soit dans l’intitulé, soit dans la présentation du contenu.

Un deuxième exemple est offert avec un champ qui agrège le champ fulltext et le champ ext qui correspond au texte des documents associés aux descriptions (documents pdf, par exemple).

La syntaxe est simple :

<aggregated-fields>
	<!-- Un champ analyse-titre -->
	<aggregated-field name="analysetitre" type="word">
		<field name="unittitle"/>
		<field name="scopecontent"/>
	</aggregated-field>
	<!-- Un champ texte-plein + texte integral -->
	<aggregated-field name="extfulltext" type="word">
		<field name="ext"/>
		<field name="fulltext"/>
	</aggregated-field>
</aggregated-fields>

Il est possible de créer des champs agrégés supplémentaires, si on en a le besoin, et de rajouter d’autres champs dans un champ agrégé existant.

À titre d’exemple, on pourrait ajouter le champ abstract aux champs unittitle et scopecontent.

Notice :

Il est vivement conseillé de n’agréger que des champs de même type (word dans l’exemple ci-dessus).

Champs Dupliqués

Remarques : Le fichier qui définit les champs agrégés est module-eadeac/conf/ead-duplicated-fields.xconf.

Il s’agit de mettre en œuvre l’héritage : un champ hérité est rempli par le contenu d’un autre champ que l’on trouve dans les unités de descriptions ancêtres. L’élément s’appelle <duplicated-field>, il possède deux attributs :

1. original : champ source de la duplication ;
2. duplicate : champ contenant la duplication.

<duplicated-fields>
	<duplicated-field original="extfulltext" duplicate="hextfulltext"/>
	<duplicated-field original="fulltext" duplicate="hfulltext"/>
</duplicated-fields>

Dans l’exemple ci-dessus, on va placer tous les mots contenus dans les champs fulltext (original) des différentes unités ancêtres de l’unité en cours dans le champ hfulltext (duplicate).

Références

<references/>