OpenText Content Server fournit un langage de requête permettant aux utilisateurs de formuler des requêtes de recherche pouvant être traitées par le moteur de recherche OpenText. Ce « langage de requête dynamique » est communément appelé « LQL ». Ce didacticiel explique comment utiliser le langage LQL pour formuler des requêtes de recherche avancée dans Content Server.
Dans OpenText Content Server 10, le langage de requête de recherche décrit dans ce didacticiel est utilisé lors de la saisie du texte dans la barre de recherche. Content Server fusionnera votre requête de recherche avec les paramètres par défaut et d'autres fonctionnalités de recherche telles que les vues de recherche, affectant ainsi vos résultats de recherche. L'utilisation du langage LQL dans la barre de recherche est similaire au mode de recherche « Requête complexe » de la page Recherche avancée, mais pas identique.
La recherche peut être effectuée dans l'intégralité du contenu texte d'un objet, dans les métadonnées ou dans une combinaison des deux. Dans Content Server, l'administrateur configure le comportement par défaut. Les causes les plus courantes de résultats inattendus avec le langage LQL sont :
la définition des champs de métadonnées (par exemple, nombres entiers et chaînes) ;
la configuration des propriétés de recherche (par exemple, l'activation ou non de « la recherche de radical ») ;
les erreurs dans l'ordre des opérations et l'utilisation des parenthèses.
Le langage LQL définit principalement les termes intéressants, la logique de connexion des termes de recherche, les modificateurs spécifiques et les interprétations des termes de recherche, ainsi que les parties de texte ou des métadonnées devant être prises en compte dans la recherche.
Quelques exemples de requêtes de recherche LQL :
Une requête de recherche est constituée de termes de recherche (tels que "Apollo") connectés par des opérateurs facultatifs (tels que "and-not"") avec des modificateurs facultatifs (tels que "QLPHONETIC") et des restrictions facultatives (telles qu'une recherche limitée au champ "OTDescription").
Lorsque vous formulez une requête de recherche, n'oubliez pas que les moteurs de recherche ne conservent pas la forme exacte de toutes les informations provenant des documents originaux. Ceci peut affecter la recherche.
Certaines informations clés pouvant affecter la recherche :
Le texte figurant dans le corps ou le contenu d'un document est converti en lettres minuscules, et la plupart des accents, caractères spéciaux et signes de ponctuation sont supprimés.
Le texte contenu dans les champs de métadonnées est conservé dans son intégralité pour obtenir des correspondances de chaînes exactes.
Les champs de métadonnées peuvent être définis en tant que texte, nombres ou autres types de données spécifiques. Dans ces cas, l'interprétation des requêtes de recherche peut varier.
Les termes de recherche sont les valeurs principales utilisées par le moteur de recherche pour formuler la requête de recherche.
Les termes de recherche sont les valeurs principales utilisées par le moteur de recherche pour formuler la requête de recherche. Notez que les termes saisis ne sont pas toujours utilisés sous leur forme exacte par le moteur de recherche lorsque celui-ci exécute la requête. En fonction de différents paramètres de configuration, le moteur de recherche est susceptible d'amener des transformations comme la suppression de la ponctuation, la prise en compte du singulier ou du pluriel des mots, ou le renvoi vers un thésaurus pour déterminer quels objets doivent correspondre à une requête donnée.
Dans le premier exemple ci-dessus, lune , rover et Apollo sont tous des termes de recherche.
Pour être techniquement précis, chaque terme doit être placé entre guillemets (par exemple, "lune" "rover" "apollo" ). Vous devez utiliser les guillemets standard figurant sur votre clavier (code ASCII décimal 34 ou hexadécimal 0x22). Si vous copiez/collez du texte à partir d'une application de traitement de texte, assurez-vous que les guillemets sont corrects.
Pour plus de facilité, les guillemets ne sont pas nécessaires pour les cas simples. L'ajout des guillemets aux termes de recherche peut être nécessaire en cas d'ambiguïté, ou bien en cas d'utilisation de caractères spéciaux ou de signes de ponctuation. Par exemple, ci-dessus, si l'objectif avait été de rechercher le terme and-not dans l'index, les guillemets auraient garanti son traitement en tant que terme de recherche. Sans les guillemets, il est reconnu comme mot-clé LQL.
En général, les termes de recherche ne sont pas sensibles à la casse. Il n'y a aucune différence entre lune, Lune, LUNE ou LuNe.
Une chaîne exacte (communément appelée locution) peut être traitée en tant que simple terme de recherche si elle est placée entre guillemets. Dans l'exemple ci-dessus, "machine à remonter le temps" est un simple terme. Une recherche de "machine à remonter le temps" ne correspondrait pas à "temps nécessaire pour la réparation de la machine" ni à "temps machine". Elle correspondrait uniquement à une chaîne contenant l'expression exacte. La plupart des modificateurs (comme QLPHONETIC) ne s'appliquent pas aux locutions.
Il existe des cas particuliers pour les locutions. Si la recherche de radical est activée par défaut, la forme singulier ou pluriel du dernier mot dans une locution va correspondre. Pour désactiver cette fonction, utilisez l'opérateur Egal (="grande roue"). Vous pouvez également utiliser des caractères génériques au début ou à la fin d'une locution : "pommes et banane*".
Les termes de recherche sont modifiés par le système de requête de la même façon que le contenu original a été modifié au moment de l'indexation. Si votre système est optimisé pour convertir les caractères accentués comme é ou õ en e et o, le même traitement est alors appliqué à la requête de recherche afin de garantir une correspondance. Les requêtes sont construites à l'aide du codage UTF-8. Ainsi les caractères de la plupart des langues peuvent être utilisés dans une requête de recherche.
Caractères d'échappement : antislash
L'antislash ('\', code ASCII décimal 92 ou hexadécimal 0x5C) nécessite une prise en compte particulière. Dans le langage LQL, un simple antislash est utilisé pour indiquer que le caractère suivant doit faire partie du terme de recherche. Par exemple, pour rechercher la chaîne exacte "étrange < magique>" dans un champ de métadonnées, utilisez l'antislash pour indiquer que les chevrons font partie de la chaîne, mais pas les séparateurs, comme ci-dessous :
Sans les antislashs, les chevrons sont rejetés. Ceci ne sert habituellement que dans les champs de métadonnées, l'indexation du texte intégral du corps des documents rejetant les caractères spéciaux.
Afin de prendre en compte cette fonction, l'antislash doit également être utilisé comme caractère d'échappement. Utilisez deux antislashs pour rechercher un antislash dans une chaîne. Pour rechercher le texte c:\docs\monfichier, le terme de recherche doit être :
En plus de rechercher les correspondances, le langage LQL prend en charge les opérations d'inégalité. L'opérateur par défaut est Egal, même si la recherche de radical est généralement activée et qu'elle remplace cet opérateur.
Les opérations supérieur à, inférieur à, et différent de sont également possibles (>a, <b, >=c, <=d, !=e). Si votre requête porte uniquement sur les vols spatiaux spécifiques, vous devez rechercher :
Bien entendu, cette recherche ne serait pas utile. Le texte "2 000 000 de personnes veulent se rendre sur la lune, et 0 l'ont fait" correspondrait puisque le texte comprend une valeur supérieure à 1969 et une valeur inférieure à 1972. En général, l'utilisation des comparateurs n'est utile que lorsqu'elle est limitée aux champs de métadonnées ou lorsqu'un intervalle est appliqué à un seul terme. Pour de nombreuses applications, le modificateur QLRANGE s'applique davantage (ce didacticiel le décrit plus loin).
Lors de l'utilisation des comparateurs, il est important de comprendre la représentation des valeurs. Considérons les valeurs 512 et 3650. S'agissant de nombres entiers, il semble évident que 512 < 3650. Si votre recherche est effectuée dans des champs de métadonnées déterminés, comme une heure ou une date, elle se comportera comme prévu.
Cependant, les nombres se trouvent souvent dans le texte et ils sont indexés en tant que valeurs texte. Dans ce cas, une comparaison est effectuée à l'aide de méthodes alphanumériques. Donc 3 650 est INFERIEUR A 512 puisque 3 < 5. Quelques exemples supplémentaires illustrant la comparaison des chaînes de texte :
abcde est inférieur à < abcde1
1 129 467 est inférieur à < 25
Dans l'exemple lune >1969, la plupart des mots dans le texte correspondraient au critère >1969.
Lorsque les caractères codés UTF-8 étendus sont utilisés (en général pour des langues autres que l'anglais), les valeurs Unicode sont utilisées pour déterminer l'ordre de comparaison des chaînes. Pour certaines langues, les résultats produits peuvent sembler incorrects en fonction des attentes de la langue locale. Dans de nombreux cas, les règles d'indexation modifient également le texte (par exemple en supprimant les accents des caractères), ce qui rend les comparaisons Egal quelque peu différentes de celles attendues.
Les opérateurs de recherche sont utilisés pour contrôler la logique qui connecte les termes de recherche. Les opérateurs ne sont pas sensibles à la casse. L'opérateur AND est le connecteur par défaut entre les termes de recherche. Les options suivantes sont équivalentes :
L'opérateur OR est utilisé pour la correspondance à un certain nombre d'éléments. Dans notre exemple, nous voulons peut-être vérifier d'autres noms pour le vaisseau spatial Apollo :
Lune AND rover AND Apollo OR Columbia OR eagle
Dans le langage LQL, l'ordre des opérations va toujours de droite à gauche, tous les opérateurs ayant la même priorité. Pour formuler des recherches plus faciles à comprendre, le langage LQL prend en charge l'utilisation des parenthèses. L'exemple ci-dessus est traité ainsi :
Lune (and rover and (Apollo (or Columbia or eagle)))
L'utilisation des parenthèses permet de contrôler l'exécution des recherches et d'améliorer la lisibilité. Cette même requête pourrait donc être correctement formulée de manières différentes pour obtenir les résultats attendus, notamment :
Lune and rover and (Apollo or Columbia or eagle)
(apollo or Columbia or eagle) and lune and rover
L'opérateur AND-NOT est utilisé pour exclure certains termes. Si vous ne voulez pas exclure les informations concernant la fusée Saturn 5, utilisez l'opérateur and-not :
Lune AND (rover AND (Apollo OR (Columbia OR eagle)))
AND-NOT ("Saturn 5" or "Saturn V")
L'interprète de la barre de recherche traitera l'opérateur not de la même manière que l'opérateur and-not.
L'opérateur exclusive-or (XOR) permet de préciser une correspondance avec A ou B, mais non A et B. Par exemple :
(Recherche XOR requête) and langage
La recherche de texte correspondra à langage, ou requête de langage, mais pas langage de requête de recherche.
Pour les moteurs de recherche, il existe également l'opérateur "synonym or" (SOR). D'un point de vue fonctionnel, il se comporte comme l'opérateur OR. Cependant, il demande au moteur de recherche de calculer la pertinence d'une autre façon. Fondamentalement, le moteur traitera les termes SOR comme des synonymes, ce qui modifie la façon dont la pertinence d'une opération est déterminée. Considérez le texte "le rover lunaire s'est posé sur la lune grâce au module d'exploration lunaire (LEM)".
Lune and rover and (LEM SOR "module d'exploration lunaire")
En utilisant l'opérateur SOR, LEM et "module d'exploration lunaire" sont des synonymes. Ils ne sont comptés qu'une fois. Avec un opérateur OR, le moteur obtiendrait un résultat différent puisqu'il considérerait que deux termes différents ont été trouvés dans le résultat.
Proximité (NEAR, PROX, QLNEAR)
En général, si vous recherchez des documents relatifs à des tapis rouges, le moteur de recherche attribuera des taux de pertinence supérieurs aux objets pour lesquels les termes se trouvent proches l'un de l'autre. Par exemple, si votre requête de recherche est tapis rouges, "dérouler les tapis rouges" donnerait davantage de résultats que "les tapis existent en différentes couleurs, y compris rouge".
Vous pouvez également demander que les termes de recherche soient proches l'un de l'autre pour être considérés comme une correspondance en utilisant l'opérateur de proximité.
Ceci demanderait que les mots tapis et rouges soient compris dans un intervalle de trois mots l'un par rapport à l'autre. Ceci correspond à "tapis verts et rouges" ou "tapis avec du rouge" mais pas à "les tapis sont disponibles en plusieurs couleurs, y compris rouge".
Si l'ordre est important, ceci peut également être précisé. Un second paramètre facultatif de l'opérateur PROX est un indicateur vrai/faux (T ou F) qui nécessite l'application de l'ordre. L'exemple suivant ne correspondrait plus à "tapis avec du rouge".
Pour plus de facilité, la configuration relativement commune PROX[10, F] est accessible grâce à NEAR ou QLNEAR.
Pour rechercher des opérateurs, placer les opérateurs entre guillemets pour qu'ils soient traités comme des mots. La requête de recherche :
Le langage de requête expose un certain nombre de modificateurs utiles qui permettent un meilleur contrôle des recherches. Les modificateurs s'appliquent au terme de recherche simple qui suit le modificateur (et non aux locutions exactes).
La recherche de radical permet de trouver les correspondances selon le radical d'un mot. Par défaut, la configuration de recherche de radical dans Content Server consiste à faire correspondre les formes singulier et pluriel des mots. L'algorithme de la recherche de radical est basé sur votre langue de préférence et prend en charge l'anglais, le français, l'allemand, l'espagnol et l'italien.
Le mot-clé QLSTEM est utilisé pour demander que la recherche de radical soit appliquée à un terme. L'exemple ci-dessous correspondra à "tapis rouge" ou à "tapis rouges".
La recherche de radical est souvent activée par défaut. Par conséquent, l'utilisation du modificateur QLSTEM peut ne pas être nécessaire.
L'un des mécanismes de correspondance des termes est basé sur la prononciation similaire des mots. Cet algorithme est conçu spécifiquement pour la correspondance avec les noms de famille. Les noms ne suivent pas nécessairement les conventions et corrections orthographiques. Considérez le cas dans lequel le nom est pris en compte oralement et enregistré sous Dupont. En pratique, l'orthographe de ce nom peut avoir un certain nombre de variantes, y compris Dupond, du Pont, Dupon, etc.
Utilisez l'opérateur QLPHONETIC pour rechercher ces variantes d'un nom.
(Jules OR Jacques) AND QLPHONETIC dupont
Il peut y avoir un grand nombre de correspondances phonétiques potentielles. L'utilisation d'une recherche phonétique sur un grand ensemble de données peut être longue. Et s'il est fortement probable d'obtenir la plupart des correspondances possibles, la précision d'une telle recherche est relativement faible.
L'algorithme actuel mis en œuvre pour l'opérateur QLPHONETIC est une version modifiée de l'algorithme américain Soundex. Cet algorithme fonctionne pour la plupart des langues d'Europe occidentale, bien que la précision diminue lorsque la langue est moins proche de l'anglais.
Le moteur de recherche peut utiliser un thésaurus pour étendre une requête de recherche et rechercher également les synonymes d'un mot. Un thésaurus est spécifique à une langue. Content Server est compatible avec des thésaurus pour plusieurs langues : anglais, français, espagnol et allemand. De plus, il existe un thésaurus multilingue qui combine toutes les langues ci-dessus, offrant une grande facilité de recherche mais diminuant légèrement la précision, selon les mots. Le choix du thésaurus à utiliser est déterminé par l'administrateur au cours de la configuration du système et des préférences de langue.
Pour demander l'utilisation du thésaurus durant une recherche, utilisez le modificateur QLTHESAURUS sur un terme :
La recherche est effectuée à la fois sur "carpette rouge" et "tapis rouge".
L'une des fonctionnalités les plus puissantes dans le langage de requête est la capacité à spécifier des intervalles pour une valeur. Dans l'exemple précédent, (Lune rover >1969 AND <1972), nous avons vu que l'utilisation d'un intervalle n'était pas efficace. La fonction intervalle correspondrait à nos besoins dans les cas suivants :
Lune AND rover AND QLRANGE "1969~1972"
L'opérateur QLRANGE correspondra à un terme donné dans l'intervalle de 1969 à 1972 inclus (ce qui signifie que 1969 et 1972 correspondraient). Les valeurs d'intervalle doivent être indiquées entre guillemets. Comme indiqué dans la rubrique opérateurs, les résultats seront différents si les valeurs sont du texte (plus courant) ou des valeurs numériques (ce qui peut être le cas pour les métadonnées).
L'ordre des objets dans les intervalles est important. QLRANGE "1972~1969", ne donnerait aucun résultat.
Il existe une autre forme de QLRANGE conçue pour faciliter la recherche d'ensembles d'objets :
Voiture and QLRANGE "noir|marron|gris|noir charbon"
Cette recherche doit être formulée de façon à rechercher les documents faisant référence aux voitures de couleur foncée. D'un point de vue fonctionnel, cette forme est équivalente à :
Voiture and (noir or marron or gris or noir charbon)
Le moteur de recherche peut traiter la requête de manière plus efficace sous la forme QLRANGE. Celle-ci est donc recommandée lors de la formulation de requêtes très complexes sur de vastes ensembles de données. Cependant, cette forme n'accepte pas les caractères spéciaux. L'exemple ci-dessous ne donnerait donc pas les résultats attendus :
QLRANGE "bernard.dupont|henri-martin"
Caractères génériques, modèles et expressions régulières
Le langage LQL prend en charge un certain nombre de modèles correspondant à des fonctionnalités de recherche avancée. Les caractères ne sont pas sensibles à la casse.
La troncature à droite est l'utilisation de caractères génériques pour obtenir une correspondance à tout mot commençant par le terme fourni. Pour plus de facilité, utilisez un astérisque. L'exemple suivant donnerait des correspondances avec des mots comme téléphone, téléphones, téléphérique ou téléphériques.
La troncature à gauche est utilisée pour obtenir une correspondance à tout mot se terminant par le terme fourni. Pour plus de facilité, utilisez un astérisque au début du terme. L'exemple suivant donnerait des correspondances avec imagination, expiration ou machination :
Le modèle de mécanisme de correspondance le plus flexible est appelé expressions régulières :
Le modèle qui nous intéresse doit figurer entre guillemets. Cette requête à l'aspect complexe rechercherait les mots commençant par ch (le caractère ^ correspond au début du mot), suivi de tout ensemble de caractères entre 0 et 9 (les ensembles sont entre des crochets) une ou plusieurs fois (signe +), suivi de tout caractère (.) se terminant par r ($ correspond à la fin d'un mot). En d'autres mots, cela correspondrait à :
L'action des expressions régulières peut être très lente. Lorsque c'est possible, identifiez le début de la chaîne à l'aide de l'accent circonflexe pour l'optimisation des performances.
Vous pouvez utiliser les expressions régulières pour comparer les chaînes ayant des formats spécifiques, comme des numéros de pièces ou des adresses e-mail. Par exemple, lorsque vous recherchez "henri dupont" dans une adresse e-mail chez superzoom, de format inconnu, vous devez utiliser quelque chose comme :
qlregex "^h(enri)?.?d(upont)?@super(-)?zoom.(com|net|org)"
Ce qui correspondrait à des possibilités comme :
La troncature et les expressions régulières sont des opérations coûteuses en ressources avec un traitement parfois très long et une importante exploitation du système. Parfois, selon les paramètres de configuration du système et la taille de l'index de recherche, les opérations de recherche peuvent être interrompues.
La troncature à gauche (*mot ) est toujours coûteuse. Le coût des expressions régulières peut être limité grâce à des termes ancrés avec autant de caractères en tête que possible (commencez par ^mo). La troncature à droite (mot*) est la meilleure solution si vous disposez d'autant de caractères en tête que possible (a* est bien plus coûteuse que appl*).
Recherche dans les champs de métadonnées
Par défaut, le langage LQL effectue les recherches dans un ensemble défini de champs de métadonnées (ou régions) et dans l'intégralité du contenu texte. Pour affiner les recherches dans les métadonnées, vous pouvez restreindre les recherches de termes à des champs spécifiques.
[QLREGION "OTDComment"] = "tapis rouge"
Dans ce cas, le moteur de recherche doit rechercher les occurrences de "tapis rouge" dans le champ de métadonnées OTDComment. Les noms de champs de métadonnées sont sensibles à la casse.
Si plusieurs termes de recherche suivent la restriction de région, vous devez utiliser les parenthèses pour spécifier clairement que tous les termes s'appliquent à la région. Par exemple, selon vos objectifs, vous pouvez utiliser :
[QLREGION "OTName"] ("tapis" AND QLSTEM "rouge")
qlstem tapis and [QLREGION "OTName"] "rouge"
Si vous utilisez la forme ci-dessous, la signification n'est pas évidente et le langage LQL peut ne pas l'interpréter comme vous le souhaitez :
[QLREGION "OTName"] ("tapis" AND QLSTEM "rouge")
Vous pouvez créer des requêtes complexes à l'aide de régions multiples. Envisagez la requête suivante pour rechercher des documents dont la taille de fichier est environ 1 Mo, rédigés par bernard dupont et faisant référence aux smartphones :
([QLREGION "OTSize"] QLRANGE "750000~1250000")
and ([QLREGION "OTCreatedByName"] "dupont")
and ([QLREGION "OTData"] QLRANGE "blackberry|iphone")
Les valeurs indexées dans les champs de métadonnées peuvent avoir des attributs. Le plus souvent, les attributs sont utilisés pour les langues, permettant d'obtenir le nom ou la description d'un objet en plusieurs langues. Il est de plus possible de limiter la recherche aux attributs :
[QLREGION "OTName"][QLATTRIBUTE "lang"="fr"] "rouge"
Cette requête correspondrait aux objets dans lesquels le champ OTName comprend le terme rouge, mais seulement si celui-ci est contenu dans un champ doté de l'attribut/de la paire de valeur de langue/français. Il existe un cas spécifique pour tester un attribut non défini :
[qlregion "OTName"][QLATTRIBUTE "lang" EST NUL] *
Ceci permet d'obtenir une correspondance seulement si aucun attribut de langage n'existe. Il n'est PAS nécessaire de préciser le modificateur QLATTRIBUTE si vous souhaitez rechercher toutes les combinaisons attribut/valeur.
En interne, les champs indexés sont contenus dans une large vue de recherche de métadonnées ou de texte intégral. Implicitement, toutes les régions de métadonnées dans Content Server sont contenues dans la vue de recherche "OTMeta". Vous pouvez explicitement indiquer la vue de recherche dans la définition du champ, mais ce n'est généralement pas nécessaire.
[QLREGION "OTMeta":"OTName"] "tapis rouge"
Il existe une vue de recherche réservée au texte intégral : "OTData". Vous pouvez utiliser la fonctionnalité QLREGION pour limiter une recherche aux seules données de texte intégral :
[QLREGION "OTData"] ("tapis" AND QLSTEM "rouge")
Il existe un cas spécifique pour les documents XML indexés dans Content Server. Supposez que vous recherchez tout document XML qui contient "crayon violet" dans la balise XML de "hector". Vous pouvez effectuer votre recherche à l'aide de la syntaxe :
[QLREGION "OTData":"hector"] "crayon violet"
Recherche dans les champs booléens
Un champ de métadonnées peut être de type booléen. Pour vos recherches dans les champs booléens, vous devez limiter vos recherches à la correspondance « true » ou « false ».
Un ensemble relativement courant de cas spécifiques se produit lorsque vous voulez simplement inclure un terme de recherche qui vérifie l'existence d'un champ de métadonnées, sans prendre en compte sa valeur. Par exemple, si vous recherchez les objets pour lesquels une date de création de la version existe, le terme de recherche suivant peut être utilisé :
Quelque chose and [QLREGION "OTVerCDate"] *
Inversement, si vous recherchez uniquement les objets sans cette date, vous utilisez au choix :