Le langage L

7.1.3 Le Langage Naturel . . . 178 7.1.4 Le langage L . . . 179 7.2 Logique interne . . . 187 7.2.1 Structure arborescente . . . 187 7.2.2 Le Semantic Search Engine SQL (SSESQL) . . . 190 7.2.3 Le Semantic Search Engine NoSQL (SSEN oSQL) . . . 194

Le chapitre précédent a permis de décrire la modélisation théorique et l’implémentation du langage L_. Dans ce chapitre, son exploitation à des fins de RI est abordée. Elle se matérialise par le développement des deux moteurs de recherche, le Semantic Search Engine SQL (SSESQL) et le Semantic Search Engine NoSQL (SSEN oSQL). Le langage L_ constitue le cœur de ces deux moteurs dans le sens où toutes leurs logiques d’exécution reposent sur la syntaxe de ce langage.

Aujourd’hui, seul le SSEN oSQL est encore maintenu. Comme expliqué précédemment, ce moteur est utilisé dans divers contextes opérationnels et notamment au sein de notre SI comme moteur de recherche sous-jacent aux outils de RI bibliographiques et mais également dans le cadre du projet de création de l’EDSS confié par le CHU de Rouen à notre équipe de recherche. Bien que le SSESQL ait été initialement le premier à voir le jour, ce dernier a été abandonné afin de palier aux faibles performances des temps de traitements résultant de l’exploitation du SGBDR (cf. chapitre 5).

Bien que basé sur des SGBDs différents, le SSESQL et le SSEN oSQL ont en commun de pouvoir tous deux interpréter et exécuter des L_–requêtes. Néanmoins, la logique d’exécution qu’ils emploient diffèrent. Cette différence s’explique principalement par le fait que le SSESQL traduit ces requêtes en SQL alors que le SSEN oSQLles traduit en une succession d’ordres rendus disponibles par l’API de requêtage du SGBD NINJAC.

Les fonctionnalités du SSESQL sont plus étendues que celles du SSEN oSQL. Fonctionnelle-ment, le SSEN oSQLne peut en effet couvrir la totalité de l’expressivité du langage de requête L contrairement au SSESQL. Ceci s’explique principalement par la « puissance » du langage SQL qui offre nativement les fonctionnalités génériques nécessaires à l’implémentation des fonction-nalités de RI. Le cœur du SSESQL à donc pour principal rôle de transcrire les L–requêtes en requêtes SQL.

fonctionnalités nécessaires à la RI ont dû être développées y compris au niveau de la donnée elle-même par le biais du SGBD NINJAC et notamment de la maintenance des maps de jointure et des index permettant une recherche plein texte. Bien que, la transcription d’une L–requête en requête SQL n’est pas triviale, la logique interne du SSEN oSQLsuppose une plus grande atomicité dans le sens où une L_–requête est exécutée contrainte par contrainte par le SSEN oSQL lui-même (en faisant appel à NINJAC) et non d’un seul bloc par un SGBD tierce.

Le SSESQL et le SSEN oSQL proposent différentes fonctionnalités et notamment des modes d’interrogations différents ainsi que la possibilité de trier les ressources obtenues en sortie.

7.1 Modes de requêtage

Le SSEN oSQL est utilisé pour assurer différents types de RI. Il s’attache premièrement, à permettre une RI documentaire classique dans le cadre de et . Dans un second temps, il assure une RI plus complexe au sein des données patient de l’EDSS du CHU de Rouen. Le langage de requête L_est adapté à ce deuxième cas d’utilisation mais reste inutilement complexe en ce qui concerne la RI documentaire. Afin d’adapter le SSEN oSQL à ces différents contextes d’utilisation, cinq modes d’interrogation ont été proposés. Parmi ces cinq modes, trois correspondent à la possibilité d’utiliser trois langages de requête logiques différents. Pour chacun de ces langages, les outils permettant son exploitation et sa manipulation informatique ont été développés :

Le langage L_ : muni du parser_permettant de générer un objet ™SSEQueryreprésentant une L_–requête.

Le langage L : muni à la fois :

— du parser permettant de générer une objet ™ DCQueryreprésentant infor-matiquement les requêtes écrites dans ce langage que l’on notera L –requêtes ; — d’un convertisseur L → L_ permettant de « traduire » une L –requête

en une L–requête équivalente. Le langage LB : muni :

— du parserB permettant de générer un objet ™ BQueryreprésentant informatique-ment les requêtes écrites dans ce langage que l’on notera LB–requête ;

— d’un convertisseur LB→ L permettant de « traduire » une LB–requête en une L –requête équivalente.

Le moteur de recherche peut également être interrogé par l’intermédiaire de requêtes écrites en langage naturel. Deux modes d’interrogation sont disponibles pour interpréter ces requêtes : Par une conversion L → L_ : Cette méthode permet de définir des syntaxes génériques et paramétrables et d’identifier ces syntaxes au sein des requêtes en langage naturel fournies en entrée du SSESQL. Les requêtes interprétables par cet outil sont donc intrinsèquement écrites dans un langage spécifique que l’on notera par la suite L . L’outil est ainsi assi-milable à un convertisseur L → L_ de L –requête en L_–requête.

Par l’intermédiaire de l’ECMT : Il permet d’annoter sémantiquement les requêtes en lan-gage naturel et d’en construire une L –requête lorsqu’il s’agit d’exploiter le moteur de recherche dans un contexte de RI documentaire.

Dans la pratique, seules les L_–requêtes sont en interne réellement gérées par le moteur de recherche. Son interrogation à l’aide des différents types de requête évoqués dans cette section passe donc par diverses étapes de conversion en L_–requêtes équivalentes. L’organigramme de programmation donné dans la Figure 7.1 indique le processus de gestion d’une requête reçue en entrée du moteur de recherche jusqu’à sa traduction en L_–requête. La gestion d’une requête se fait en deux étapes majeures :

Étape no1 : Identification du type d’une requête (i.e.L_–requête, LB–requête, etc.). Étape no2 : Conversion de cette requête en L_–requête puis enSSEQuery.

Start L–requête ? LB–requête ? parser_B LB→ L L –requête ? parser transformations L → L L –requête ? ECMT parser L → L End

Oui Oui Oui Non

Non Non Non

L–requête L_B–requête

BQuery

L –requête Langage naturel

DCQuery DCQuery L–requête L –requête L–requête SSEQuery

Figure 7.1 – Organigramme de programmation représentant le processus de gestion d’une requête donnée en entrée du moteur de recherche. Les cinq modes d’interrogation possibles (viz. L–requête, L –requête, L_B–requête, L –requête et requête en langage naturel) sont représentés. Le format d’une requête est identifié afin de pouvoir se ramener de manière systématique à une L–requête.

revues universitaires et à d’autres produits, principalement dans le domaine des sciences de la santé. Sa philosophie de requêtage est également très proche de celle du langage de requête proposé par le moteur de recherche de données bibliographiques .

De même que les langages de requête de et , la syntaxe du langage L re-pose sur l’exploitation d’élément syntaxique permettant de créer des contraintes sur des champs de recherche2. Un champ de recherche n’est rien d’autre qu’un attribut ou une méta-donnée d’une ressource documentaire ou bibliographique qu’il est possible d’exploiter dans le cadre de la RI sur ces ressources. Ces champs de recherche peuvent par exemple correspondre au titre, à la date de publication ou encore au nom de l’auteur d’une ressource. Dans le cas du langage L , les contraintes de champs de recherche sont de la forme suivante :

 Syntaxe 10 (contrainte de champs de recherche) : Un contrainte de champs de recherche est de la forme :

VALEUR.code[OPTION1][OPTION2],... où :

code : est un libellé généralement court désignant un champ de recherche d’une ressource documentaire ou bibliographique.

VALEUR : la valeur que doit prendre ce dernier champ de recherche.

[OPTION1][OPTION2],... : est un ensemble de clauses optionnelles d’options permettant de préciser des spécificités dans le processus de recherche de ressources.

La contrainte de champ de recherche VALEUR.code[OPTION] désigne alors l’ensemble des ressources dont l’attribut désigné par code a pour valeur VALEUR.

En plus de ces contraintes de champ de recherche, le langage L permet l’utilisation des parenthèses (i.e. « ( » et « ) ») et des opérateurs Booléens ET, OU et SAUF. On ne dressera pas dans ce mémoire la liste de la totalité des champs de recherche disponibles pour ce langage3 cependant, quelques exemples de requêtes qu’il est possible de former avec ce langage sont donnés ci-dessous :

¸ Exemple 29 :

Le code champ .mc, signifiant Mot Clé permet par exemple de rechercher les ressources indexées avec un concept :

maladie.mc : Désigne l’ensemble des ressources indexées avec les concepts de maladie toutes TOs confondues ou l’un des descendants de ces concepts.

maladie.mc[TER_MSH] : Désigne l’ensemble des ressources indexées avec le concept « ma-ladie » [D004194 (MeSH)] de la terminologie MeSH ou l’un de ses descendants. maladie.mc[TER_MSH][NOEXPL] : Désigne l’ensemble des ressources indexées avec le concept

« maladie » [D004194 (MeSH)] sans nécessairement l’être avec l’un des ses descen-dants (NOEXPL ⇔ pas d’explosion hiérarchique du terme).

De même le code champ .ti désigne le titre d’une ressource :

asthme.mc[TER_MSH] OU asthme.ti : Désigne l’ensemble des ressources indexées avec « ma-ladie » [D004194 (MeSH)] ou contenant le mot « asthme » dans le titre.

asthme.mc[TER_MSH] ET ((nourrisson.ti OU bébé.ti) SAUF enfant.ti) : désigne l’en-semble des ressources indexées avec le concept « maladie » [D004194 (MeSH)] et contenant dans le titre le mot « nourrisson » ou « bébé » mais pas le mot « enfant ».

2. : Ce terme étant une traduction de l’expression « Search Field » utilisé par le moteur de recherche 3. url : La plus grande partie des codes champs disponibles sont cependant décrit à l’url suivante : http://www.chu-rouen.fr/cismef/aide/liste-des-abreviations-des-champs-utilises-dans-doccismef-et-lissa/

Enfin, le code champ .an permet par exemple de cibler des ressources publiées à une année précise :

asthme.mc[TER_MSH] ET 2017.an : Désigne les ressources traitant de l’asthme publiées en 2017.

asthme/diagnostic.mc[TER_MSH] ET diagnostic.ti ET 2015->2018.an : Désigne les res-sources traitant du diagnostic de l’asthme, dans lesquelles le mot « asthme » apparaît dans le titre et publiées entre 2015 et 2018.

Dans le cadre de la RI documentaire classique, le type de ressource renvoyé par un moteur de recherche est toujours le même. Il peut correspondre à des ressources documentaires (e.g. ) ou bien à des ressources bibliographiques (e.g. ). Quoi qu’il en soit, le « type d’objet » obtenu en sortie ne varie pas contrairement au cas d’usage de la RI au sein de l’EDSS qui, elle, peut renvoyer divers types d’objets (e.g. patient mais aussi séjour, analyse biologique, etc.).

Ainsi, le formalisme du langage L n’inclut pas pleinement d’éléments syntaxiques permettant de gérer la notion d’entité. Tous les codes champs désignent des attributs d’un type d’objet mais ce type d’objet est implicitement défini par l’application ou le contexte dans lequel ces codes champs sont employés et non directement exprimés au sein de la requête.

Par exemple, le type de d’objet renvoyé par étant des ressources documentaires et celui de des ressources bibliographiques, le code champ .re correspond à la descrip-tion des ressources documentaires pour alors qu’il désigne l’abstract d’une ressource bibliographique pour . De même le code champ .vol ne renvoie rien pour alors qu’il correspond au volume des ressources bibliographiques pour . Le requêtage d’une telle contrainte ne s’effectue donc pas nécessairement de la même manière suivant que la requête a

été soumise à l’application ou .

En somme, le langage L est basé sur une philosophie et un formalisme orienté attribut. Ce dernier, permet abstraitement de considérer que les différents codes champs cor-respondent à différents attributs (e.g. titre, auteur, date de publication, etc.) se rapportant tous à une même et unique entité définie implicitement (i.e. l’entité de sortie du système) et quelque soit la réalité de la modélisation concrète ou conceptuelle des données sous-jacentes. Ce pa-radigme est la principale différence avec le langage L qui lui est orienté entité et permet d’exprimer au sein des requêtes à la fois les attributs et les entités conceptuelles auxquelles ils se rapportent.

Afin d’assurer la rétro-compatibilitée du moteur de recherche SSEN oSQL avec le langage de requête L , un outil de conversion L → L_ a été développé. Ce dernier prend en paramètre une L –requête mais également le type d’objet implicite définissant le contexte et permettant une « traduction » de la L –requête en L–requête cohérente. Une illus-tration de ce principe est donnée Figure 7.3 p. 175.

2018.an  DOC 2018.an   NLM 2018.an  L → L DOC(2018-01-01 <= DATE_EDITION_TEXT < 2019-01-01) NLM(2018-01-01 <= BDB_ARTICLE_PUB_DATE < 2019-01-01)

Figure 7.3 –Illustration « boîte noire » du convertisseur L → L. La même requête 2018.an est passée en entrée de et . Le convertisseur L → Lest appelé avec la requête d’une part et le type d’entité attendu en sortie d’autre part (i.e. DOC pour et NLM pour ). La L–requête obtenue en sortie est alors différente.