FR2991077A1 - Systeme interactif de resolution contextuelle d'informations provenant d'un systeme semantique - Google Patents
Systeme interactif de resolution contextuelle d'informations provenant d'un systeme semantique Download PDFInfo
- Publication number
- FR2991077A1 FR2991077A1 FR1201505A FR1201505A FR2991077A1 FR 2991077 A1 FR2991077 A1 FR 2991077A1 FR 1201505 A FR1201505 A FR 1201505A FR 1201505 A FR1201505 A FR 1201505A FR 2991077 A1 FR2991077 A1 FR 2991077A1
- Authority
- FR
- France
- Prior art keywords
- identified
- action
- value
- user
- attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/279—Recognition of textual entities
- G06F40/289—Phrasal analysis, e.g. finite state techniques or chunking
- G06F40/295—Named entity recognition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/487—Arrangements for providing information services, e.g. recorded voice services or time announcements
- H04M3/493—Interactive information services, e.g. directory enquiries ; Arrangements therefor, e.g. interactive voice response [IVR] systems or voice portals
- H04M3/4936—Speech interaction details
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- User Interface Of Digital Computer (AREA)
Abstract
La présente invention concerne un procédé de traitement d'une saisie en langage naturel caractérisé en ce qu'il comprend des étapes de : (a) Saisie d'une phrase via une interface de saisie d'un équipement informatique ; (b) Découpage par des moyens de traitement de l'équipement de la phrase de façon à en extraire une pluralité d'entités sémantiques (E), l'une des entités sémantiques (E) étant identifiée comme une action (A), et les autres étant identifiées comme des valeurs (Bs) d'au moins un attribut (B) associé à l'action (A) identifiée ; (c) Proposition d'une valeur (Bs) par les moyens de traitement pour au moins un attribut (B) associé à l'action (A) pour lequel aucune valeur (Bs) n'a encore été identifiée et/ou proposée, en fonction des valeurs (Bs) déjà identifiées et/ou proposées et d'éléments contextuels dont dispose l'équipement ; (d) Validation par l'utilisateur des solutions (Bs) identifiées et/ou proposées. L'invention concerne en outre un produit programme d'ordinateur.
Description
DOMAINE TECHNIQUE GENERAL La présente invention concerne le domaine de la reconnaissance du langage.
Plus précisément, elle concerne un procédé de traitement d'une saisie en langage naturel. ETAT DE L'ART Les interfaces utilisateur modernes des logiciels offrent des moyens d'interaction peu ergonomiques, qui se réduisent le plus souvent à des combinaisons de clics de souris et à des saisies de textes dans de nombreux champs. Des opérations anodines comme la création d'une entrée dans un agenda, le renseignement d'une fiche dans un carnet de contacts, le remplissage d'un formulaire ou même la prise de notes en général, sont artificiellement complexifiées. Une proposition attrayante pour remplacer ces interfaces est le traitement du langage naturel. L'objectif est d'arriver comme un humain le ferait à tirer les informations nécessitées par l'interface d'une source vocale, textuelle ou graphique en langage naturel, par exemple la phrase « réunion avec Bill demain » tapée au clavier. Le traitement d'une telle saisie est confronté à de nombreux défis. En effet, il est nécessaire de comprendre l'intention de l'utilisateur au-delà de la compréhension de la phrase. Par exemple, une phrase telle que « réunion téléphonique demain avec Bill » est de nature ambigüe pour un système informatique. Pour l'utilisateur, Bill décrit une personne connue, alors pour un système informatique, cette référence peut s'appliquer à tout Bill présent dans le carnet d'adresses, voire à un Bill inconnu. La personne à laquelle on fait référence peut en outre être dans le carnet d'adresse, mais sous un autre nom (William). Par ailleurs le terme de réunion téléphonique peut perturber un système informatique, qui ne comprendra pas forcément qu'il s'agit d'un appel et non d'une réunion où les personnes sont présentes physiquement. Pour toutes ces raisons, il serait souhaitable de disposer d'un procédé de traitement d'une saisie en langage naturel aux performances améliorées. PRESENTATION DE L'INVENTION Selon un premier aspect, la présente invention se rapporte donc à un 10 procédé de traitement d'une saisie en langage naturel caractérisé en ce qu'il comprend des étapes de : (a) Saisie d'une phrase via une interface de saisie d'un équipement informatique stockant une liste d'actions pouvant être exprimées dans ladite phrase saisie et une liste d'attributs, chaque action étant 15 associée à une pluralité d'attributs pour chacun desquels une ou plusieurs valeurs sont attendues afin de caractériser l'action ; (b) Découpage par des moyens de traitement de l'équipement de la phrase de façon à en extraire une pluralité d'entités sémantiques, l'une des entités sémantiques étant identifiée comme une action, et 20 les autres étant identifiées comme des valeurs d'au moins un attribut associé à l'action identifiée ; (c) Proposition d'une valeur par les moyens de traitement pour au moins un attribut associé à l'action pour lequel aucune valeur n'a encore été identifiée et/ou proposée, en fonction des valeurs déjà identifiées 25 et/ou proposées et d'éléments contextuels dont dispose l'équipement ; (d) Validation par l'utilisateur des solutions identifiées et/ou proposées. Selon d'autres caractéristiques avantageuses et non limitatives de la 30 méthode selon le premier ou le deuxième aspect : - le procédé comprend lors de l'étape (c) la reformulation d'au moins une valeur identifiée et/ou proposée en fonction desdits éléments contextuels disponibles ; - l'étape (c) est répétée de façon itérative, soit jusqu'à ce qu'au moins une valeur soit identifiée et/ou proposée pour chaque attribut associé à l'action, soit jusqu'à ce qu'un état stationnaire soit atteint ; - chaque attribut est défini soit comme étant obligatoire soit comme étant optionnel, l'étape (c) est répétée de façon itérative, soit jusqu'à ce qu'au moins une valeur soit identifiée et/ou proposée pour chaque attribut associé à l'action défini comme obligatoire, soit jusqu'à ce qu'un état stationnaire soit atteint ; - l'utilisateur a la possibilité à l'étape (d) de modifier une valeur obtenue et/ou de résoudre un ou plusieurs attributs pour lesquels aucune valeur n'a été proposée ; - les étapes (c) et suivantes sont mises à nouveau en oeuvre si au moins une des valeurs n'est pas validée et/ou modifiée par l'utilisateur ; - l'équipement comprend une interface de sortie, les solutions étant appliquées sur l'interface de sortie lors de l'étape (d) de validation.
Un deuxième aspect de l'invention concerne un produit programme d'ordinateur comprenant une liste d'attributs, une liste d'actions chacune associées à au moins un d'attribut, et des instructions de code de programme qui lorsqu'elles sont exécutées, mettent en oeuvre le procédé selon le premier aspect de l'invention.
PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : la figure 1 est un schéma de l'architecture d'un équipement informatique dans lequel est mis en oeuvre le procédé selon l'invention ; la figure 2 est un schéma représentant un exemple d'un ensemble de listes de données et leur interaction lors de la mise en oeuvre du procédé selon l'invention ; la figure 3 représente un exemple d'interface graphique pour la mise en oeuvre du procédé selon l'invention ; les figures 4a-h représentent les étapes d'un exemple détaillé de mise en oeuvre du procédé selon l'invention. DESCRIPTION DETAILLEE Principe de la méthode Comme expliqué précédemment, lors de l'étude d'une phrase par un système informatique, certains éléments apparaissent ambigus, mais d'autres ne le sont pas. Ainsi, dans la phrase « réunion téléphonique demain avec Bill » bien qu'on peut avoir des doutes sur qui est Bill, on peut sans risque affirmer qu'il s'agit d'une personne. Le procédé selon l'invention vise à apporter un résultat pas forcément exact, mais cohérent avec les attentes de l'utilisateur. Pour cela, il comprend quatre étapes, mises en oeuvre grâce à un équipement informatique 10 tel que représenté sur la figure 1. Cet équipement 10, qui peut être par exemple un ordinateur de bureau, comprend une interface de saisie 11, des moyens de traitement 12, un espace de stockage 14, une interface de sortie 13. L'interface de saisie 11 consiste le plus souvent en un clavier par lequel l'utilisateur peut saisir une phrase, mais ils peuvent alternativement consister en un microphone associé à un module de reconnaissance vocale ou un scanner associé un module de reconnaissance optique de caractères (ROC). En d'autres termes, on comprendra que l'invention peut s'adapter à toute interface 11 qui permette la saisie d'une phrase en langage naturel et son acquisition (et éventuellement sa conversion sous une forme exploitable, par exemple en chaîne de caractères). L'interface de sortie 13 consiste le plus souvent en un écran, qui affiche les données, mais on peut imaginer des haut-parleurs qui prononcent les informations. Les moyens de traitement 12 consistent par exemple en un processeur, et l'espace de stockage 14 par exemple en un disque dur. Y sont stockées une ou plusieurs bases de données, comprenant entre autres une liste LA d'actions A et une liste LB d'attributs B.
Par « action », on comprend une fonctionnalité, ou un type de fonctionnalité, que l'utilisateur pourrait faire via une interface classique, et qu'il cherche à signifier via une saisie en langage naturelle via l'interface de saisie 11 que le procédé selon l'invention vise à traiter. En d'autres termes, on peut faire l'hypothèse qu'une action est exprimée dans chaque phrase saisie pour laquelle le procédé est mise en oeuvre. Par exemple, dans l'exemple « réunion téléphonique demain avec Bill », l'action A est « réunion téléphonique », ce qu'il faut comprendre par « action de créer dans mon agenda électronique une entrée relative à une réunion téléphonique ».
Ainsi la liste LA comprend une pluralité d'actions A (ou plutôt une pluralité de façon d'exprimer des actions A) qui peuvent être relatives à un logiciel ou un domaine sémantique. Par exemple, si le logiciel est un agenda électronique (en d'autres termes le domaine sémantique de l'emploi du temps) la liste LA comprendra par exemple les actions « réunion », « présentation », « réunion téléphonique », « déplacement », « congés », « bureau », etc. Les possibilités sont infinies. Chaque action A est associée à une pluralité d'attributs B. Par « attribut », on entend toute donnée à renseigner pour personnaliser l'action A. En effet, dire « j'ai une réunion » ne signifie rien. Pour que cette information soit exploitable, il est nécessaire de préciser au moins un « lieu », une « date », et au moins un « participant ». Les attributs B correspondent typiquement aux champs à remplir dans une interface classique, champs pour lesquels on attend une ou plusieurs « valeurs » Bs de l'attribut B afin de caractériser l'action A. La difficulté est que la valeur Bs d'un attribut B peut être exprimée sous une pluralité de formes qui peuvent pourtant être comprises pareillement. Par exemple, si l'attribut B est « date », les valeurs Bs « jeudi prochain », « le 1' septembre » ou « 01/09/11 » sont autant de valeurs admissibles qui couvrent en fait la même chose. Saisie et analyse sémantique Le procédé selon l'invention commence par une étape (a) de saisie d'une phrase via l'interface 11 de saisie. Comme expliqué il peut s'agir d'une saisie d'une chaîne de caractères au clavier, mais ce peut être alternativement la reconnaissance vocale d'une phrase parlée ou la reconnaissance optique d'une phrase inscrite sur une feuille. La phrase est ensuite découpée par les moyens 12 de traitement de données. Il s'agit d'une étape (b) d'analyse sémantique, qui permet de convertir un contenu en langage naturel en un ensemble d'entités sémantiques E, hors contexte. Par exemple, la phrase « réunion demain avec Bill » comprend trois entités sémantiques : E1= « réunion », E2= « demain », E3 = « Bill ». Par entité sémantique, il faut comprendre unité de sens. Il s'agit le plus souvent d'un mot, mais « réunion téléphonique » est par exemple une seule entité. De nombreux moteurs d'analyse sémantique permettant cette analyse sont connus. On peut citer par exemple le moteur Unitex. Des graphes linguistiques et des dictionnaires associés permettent de « comprendre » chaque entité sémantique E. En d'autres termes l'une des entités sémantiques E est identifiée comme une action A, et les autres étant identifiées comme des valeurs Bs d'au moins un attribut B associé à l'action A identifiée.
Ainsi en reprenant notre exemple, en parcourant la liste LA des actions, en s'aperçoit que l'action de la phrase est E1, c'est-à-dire « réunion ». E2 et E3 sont donc des valeurs Bs d'au moins un attribut B.
Grâce à la liste LA, on constate que cette action est l'action A3 (comme représenté sur la figure 2). Dans cet exemple, on voit que l'action est associée aux attributs B1, B2 et B4 de la liste LB, par exemple « lieu », « date » et « participant ». Les moyens de traitement 12 identifient alors rapidement que E2= « demain » est une date (en d'autres termes la solution Bs2 de l'attribut B2) et que E3= « Bill » est un participant (en d'autres termes la solution Bs4 de l'attribut B4). Les graphes linguistiques permettent cette identification, par exemple grâce au vocabulaire (« demain » fait partie du champ lexical de la date) ou aux mots de liaisons (« avec » sous-entend que le mot suivant à des chances d'être le nom d'une personne). On constate alors que l'attribut B1, en l'occurrence le lieu, est manquant. La liste L* est la liste des attributs B pour lesquels une valeur Bs est manquante. Les graphes linguistiques est dictionnaires sont associés à une langue donnée et le plus souvent à un champ lexical donné, sous peine d'être très volumineux. Par exemple, si le procédé selon l'invention est destiné à être utilisé dans un plugin d'un logiciel d'agenda électronique, on peut se limiter au vocabulaire des réunions et rendez-vous évoqué plus haut. Le procédé selon l'invention peut être utilisé pour n'importe quel logiciel à condition de disposer des bons graphes. On comprendra qu'il n'est en aucune manière limité aux agendas électroniques, mais peut parfaitement être utilisé pour les logiciels de gestion, pour les logiciels de bases de données, voire pour la prise de notes avec un outil bureautique standard si les graphes et dictionnaires sont prévus pour le vocabulaire que l'on va être amené à prendre en note. Si l'on veut pouvoir saisir des phrases dans une autre langue, il faut alors installer un module comprenant les graphes et les dictionnaires associés à cette langue. On notera qu'un attribut B peut avoir plusieurs valeurs Bs. Par 30 exemple, si la phrase d'exemple est « réunion demain avec Bill et Bob », on a une quatrième entité E4= « Bob », qui est une deuxième solution Bs4' de l'attribut B4 « participant » Ajout d'informations contextuelles Le procédé selon l'invention comprend alors ensuite une étape (c) de proposition d'une valeur Bs par les moyens 12 de traitement pour au moins un attribut B associé à l'action A pour lequel aucune valeur (Bs) n'a encore été identifiée et/ou proposée (l'attribut « lieu » dans notre exemple), en fonction des valeurs Bs déjà identifiées et/ou proposées et d'éléments contextuels dont dispose l'équipement 10.
Par « éléments contextuels », il faut comprendre toutes données ou préférences qui pourraient aider à comprendre les informations déjà fournies et compléter les informations manquantes. En effet, l'idée est de supposer que si l'utilisateur ne les a pas précisées dans la phrase saisie, c'est qu'elles sont « implicites », et qu'elle peuvent donc être déduites. Les 15 éléments contextuels peuvent être de plusieurs ordres : - contexte général : date et heure courante, etc. - contexte spécifique à l'utilisateur : calendrier, carnet d'adresses, localisation, météo pour cette localisation, conditions de trafic autour de cette localisation, etc. 20 A titre d'exemple, si l'on cherche à renseigner l'attribut « lieu », les éléments contextuels peuvent comprendre des données de géolocalisation. La valeur Bs proposée sera alors par exemple le lieu actuel. Alternativement, s'il est renseigné dans un agenda électronique (les éléments contextuels sont alors les fichiers de données de l'agenda 25 associés au profil de l'utilisateur) que l'utilisateur sera demain dans le lieu « Paris », alors la valeur Bs proposée sera ce lieu. Les éléments contextuels peuvent par ailleurs inclure les historiques de traitements du langage naturel précédemment mis en oeuvre. Ainsi, en remarquant que l'utilisateur est toujours dans le même lieu lorsqu'il met en oeuvre l'action 30 « réunion », en l'occurrence son bureau, à défaut d'autres informations la valeur Bs proposée pourra être la même qu'auparavant. On peut également envisager des valeurs Bs par défaut : par exemple, si un attribut B « durée » était associé à l'action A « réunion », en l'absence d'informations on peut décider qu'une durée de 1h est mise par défaut. Cette étape peut en outre comprendre la reformulation d'au moins une valeur Bs déjà identifiée et/ou proposée en fonction desdits éléments contextuels disponibles. Par exemple la valeur « demain » peut être reformulée en la date de demain, connaissant grâce à l'horloge de l'équipement 10 la date d'aujourd'hui. Certains modes de réalisation de cette étape de proposition de valeurs Bs seront décrits plus en détail plus loin dans la présente 10 description. Validation utilisateur La dernière étape du procédé selon l'invention consiste en une étape 15 (d) de validation par l'utilisateur des solutions Bs identifiées et/ou proposées. La résolution est en effet heuristique (algorithme qui fournit en temps polynomial une solution d'approximation à un problème NP-difficile) et ne peut donc être garantie absolument comme étant la résolution optimale. C'est pour cela que la solution est « proposée » et doit être 20 validée. Il y a en effet une possibilité d'erreur dès lors où les moyens de traitement 12 sont conduits à faire des hypothèses. L'utilisateur a avantageusement en outre la possibilité à cette étape de modifier une valeur Bs obtenue s'il la juge inexacte, et/ou de résoudre un ou plusieurs attributs B pour lesquels aucune valeur Bs n'a été proposée. 25 Dans ce tout dernier cas, on peut imaginer que l'utilisateur soit invité à trancher dans le cas d'une incertitude. Par exemple, en ce qui concerne la valeur d'attribut « Bill », si le carnet d'adresse de l'utilisateur comprend plusieurs personnes pouvant être Bill, si aucun élément contextuel ne permet de trancher, alors un choix multiple peut être soumis à l'utilisateur. 30 Pour plus d'ergonomie les solutions Bs sont appliquées sur l'interface de sortie 14 lors de cette étape. La figure 3 représente à ce titre une interface graphique affichée sur un écran. On y voit l'utilisateur résolvant la valeur Bs « Mark » de l'attribut B « participant ». Résolution itérative Comme expliqué précédemment, une valeur d'attribut manquante est le plus souvent résolue grâce à la combinaison d'une valeur Bs déjà identifiée et d'un élément contextuel. C'est pourquoi l'étape (c) de proposition d'au moins une valeur Bs 10 manquante est avantageusement répétée de façon itérative. En d'autres termes, l'algorithme tente tout d'abord de proposer une valeur Bs d'attribut B manquant (i.e. un des attributs dans la liste L*) à partir des seules valeurs identifiées. Cet attribut, nouvellement « résolu » est retiré de la liste L*. Ensuite, on tente de proposer une valeur pour un autre attribut manquant, 15 ce en tenant compte non seulement des valeurs initialement identifiées, mais également de la valeur nouvellement proposée. On réduit à chaque itération l'ambigüité, et on augmente les chances d'une résolution complète. L'étape (c) est donc répétée soit jusqu'à ce qu'au moins une valeur Bs soit identifiée et/ou proposée pour chaque attribut B associé à l'action A 20 (en d'autre termes une résolution complète), soit jusqu'à ce qu'un état stationnaire soit atteint (en d'autres termes que ni les valeurs identifiées et/ou résolues ni les éléments contextuels ne permettent de résoudre l'une des valeurs encore manquantes). Il est dans ce dernier cas demandé à l'utilisateur de résoudre lui-même au moins l'une des valeurs Bs 25 manquantes. Sachant qu'à chaque itération on réduit la taille de la liste L* d'une unité, ce processus est très rapide et complètement transparent pour l'utilisateur. Il peut ainsi être mis en oeuvre en temps réel, au fur et à mesure qu'il saisit sa phrase. L'utilisateur est ainsi conscient au premier regard que 30 sa phrase ne comprend pas assez d'information, et a la possibilité de la compléter.
Ainsi, avantageusement, les étapes (c) et suivantes sont mises à nouveau en oeuvre à chaque action de l'utilisateur, en particulier si au moins une des valeurs Bs n'est pas validée et/ou modifiée. En effet, la modification d'une valeur d'un attribut peut remettre en cause toutes les autres. Par exemple, si l'utilisateur change la date. Toutes les valeurs sont alors recalculées depuis le début (i.e. on recommence toutes les itérations). Comme représenté sur la figure 3, peut cliquer sur des icônes représentant chacun des attributs pour ouvrir une fenêtre lui proposant la correction. Il est à noter que les attributs B peuvent être définis comme obligatoires ou optionnels. Par exemple, un attribut « sujet » peut être rajouté à l'action « réunion », attribut qui sera résolu si la phrase saisie comprend les informations pour, mais qui sera laissé vide sinon. L'étape (c) est alors répétée de façon itérative seulement jusqu'à ce qu'au moins une valeur Bs soit identifiée et/ou proposée pour chaque attribut B associé à l'action A défini comme obligatoire. Exemple Les figures 4a à 4h représentent 8 étapes détaillées de mise en 20 oeuvre d'un mode de réalisation particulièrement préféré du procédé selon l'invention pour l'exemple « réunion téléphonique demain avec Bill ». En référence à la figure 4a, l'utilisateur saisit le premier mot, « réunion ». L'équipement 10 identifie l'action A réunion et affiche l'ensemble des attributs B associés à cette action. Les valeurs Bs de tous 25 ces attributs B sont manquantes. Comme représenté sur la figure 4b, une résolution contextuelle est mise en oeuvre en fonction de l'agenda de l'utilisation (date et heure) et de ses préférences (lieu et durée par défaut). L'utilisateur a pendant ce temps continué sa saisie, et a terminé le 30 mot « téléphonique », comme l'on voit sur la figure 4c. Une nouvelle action, « appel » est identifiée, et l'ensemble des nouveaux attributs B associés à cette action est affiché. Il n'y a par exemple plus l'attribut « lieu ». Une nouvelle réunion contextuelle est mise en oeuvre (fig 4d). En référence à la figure 4e, la saisie continue, et l'entité « demain » est détectée, et identifiée comme une valeur Bs qui permet de résoudre l'attribut « date ». On modifie la valeur résolue par défaut par la valeur identifiée. On relance une résolution contextuelle sur les autres attributs. Par exemple, l'heure change ici en fonction des créneaux horaires disponibles de l'utilisateur. L'utilisateur saisit ensuite « avec Bill » (fig 4f), entité identifiée comme une valeur possible pour l'attribut « avec ». Cette valeur est néanmoins ambigüe vis-à-vis du carnet d'adresse de l'utilisateur. Une résolution probable (« William S. ») est proposée. Les autres attributs sont éventuellement modifiés contextuellement. Sur la figure 4g, l'utilisateur indique qu'il n'accepte pas la résolution de « Bill » en « William S. ». Un menu déroulant s'ouvre, dans lequel la liste des « Bill » possibles est proposée. Parmi ceux-ci, l'utilisateur choisit « Bill S. » (fig 4h). On relance une résolution contextuelle sur les autres attributs, cette fois en plus en fonction d'éléments de contextes liés à « Bill S. » (son agenda par exemple). Cela entraîne une modification de l'horaire suggéré.
L'utilisateur valide alors l'interprétation de la saisie par l'équipement 10, c'est-à-dire l'ensemble des solutions Bs identifiées et/ou proposées. Une entrée renseignée est créée dans l'agenda de l'utilisateur. Produit programme d'ordinateur Selon un deuxième aspect, l'invention concerne un produit programme d'ordinateur comprenant une liste LB d'attributs B, une liste LA d'actions A chacune associées à au moins un d'attribut B, et des instructions de code de programme qui lorsqu'elles sont exécutées, mettent en oeuvre le procédé selon l'une des revendications précédentes. Ce produit programme d'ordinateur est par exemple stocké sur les moyens de stockage 14 de l'équipement informatique.
L'homme du métier comprendra qu'il inclut avantageusement tous les graphes et dictionnaires qui pourraient être utiles pour la mise en oeuvre de l'analyse sémantique.5
Claims (8)
- REVENDICATIONS1. Procédé de traitement d'une saisie en langage naturel caractérisé en ce qu'il comprend des étapes de : (a) Saisie d'une phrase via une interface (11) de saisie d'un équipement informatique (10) stockant une liste (LA) d'actions (A) pouvant être exprimées dans ladite phrase saisie et une liste (LB) d'attributs (B), chaque action (A) étant associée à une pluralité d'attributs (B) pour chacun desquels une ou plusieurs valeurs (Bs) sont attendues afin de caractériser l'action (A) ; (b) Découpage par des moyens (12) de traitement de l'équipement (10) de la phrase de façon à en extraire une pluralité d'entités sémantiques (E), l'une des entités sémantiques (E) étant identifiée comme une action (A), et les autres étant identifiées comme des valeurs (Bs) d'au moins un attribut (B) associé à l'action (A) identifiée ; (c) Proposition d'une valeur (Bs) par les moyens (12) de traitement pour au moins un attribut (B) associé à l'action (A) pour lequel aucune valeur (Bs) n'a encore été identifiée et/ou proposée, en fonction des valeurs (Bs) déjà identifiées et/ou proposées et d'éléments contextuels dont dispose l'équipement (10) ; (d) Validation par l'utilisateur des solutions (Bs) identifiées et/ou proposées. 25
- 2. Procédé selon la revendication 1, comprenant lors de l'étape (c) la reformulation d'au moins une valeur (Bs) identifiée et/ou proposée en fonction desdits éléments contextuels disponibles. 30
- 3. Procédé selon l'une des revendications 1 ou 2, dans lequel l'étape (c) est répétée de façon itérative, soit jusqu'à ce qu'au moinsune valeur (Bs) soit identifiée et/ou proposée pour chaque attribut (B) associé à l'action (A), soit jusqu'à ce qu'un état stationnaire soit atteint.
- 4. Procédé selon l'une des revendications 1 à 3, dans lequel chaque attribut (B) est défini soit comme étant obligatoire soit comme étant optionnel, l'étape (c) est répétée de façon itérative, soit jusqu'à ce qu'au moins une valeur (Bs) soit identifiée et/ou proposée pour chaque attribut (B) associé à l'action (A) défini comme obligatoire, soit jusqu'à ce qu'un état stationnaire soit atteint.
- 5. Procédé selon l'une des revendications 1 à 4, dans lequel l'utilisateur a la possibilité à l'étape (d) de modifier une valeur (Bs) obtenue et/ou de résoudre un ou plusieurs attributs (B) pour lesquels aucune valeur (Bs) n'a été proposée.
- 6. Procédé selon la revendication 5, dans lequel les étapes (c) et suivantes sont mises à nouveau en oeuvre si au moins une des valeurs (Bs) n'est pas validée et/ou modifiée par l'utilisateur.
- 7. Procédé selon l'une des revendications précédentes, dans lequel l'équipement (10) comprend une interface de sortie (13), les solutions (Bs) étant appliquées sur l'interface de sortie (13) lors de l'étape (d) de validation.
- 8. Produit programme d'ordinateur comprenant des portions/moyens/instructions de code pour l'exécution des étapes du procédé selon les revendications (1 à 7) lorsque ledit programme fonctionne sur un ordinateur.30
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1201505A FR2991077A1 (fr) | 2012-05-25 | 2012-05-25 | Systeme interactif de resolution contextuelle d'informations provenant d'un systeme semantique |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1201505A FR2991077A1 (fr) | 2012-05-25 | 2012-05-25 | Systeme interactif de resolution contextuelle d'informations provenant d'un systeme semantique |
Publications (1)
Publication Number | Publication Date |
---|---|
FR2991077A1 true FR2991077A1 (fr) | 2013-11-29 |
Family
ID=48050776
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
FR1201505A Pending FR2991077A1 (fr) | 2012-05-25 | 2012-05-25 | Systeme interactif de resolution contextuelle d'informations provenant d'un systeme semantique |
Country Status (1)
Country | Link |
---|---|
FR (1) | FR2991077A1 (fr) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1187007A2 (fr) * | 2000-07-21 | 2002-03-13 | Matsushita Electric Industrial Co., Ltd. | Méthode pour le contrôle de dialogue |
US20040085162A1 (en) * | 2000-11-29 | 2004-05-06 | Rajeev Agarwal | Method and apparatus for providing a mixed-initiative dialog between a user and a machine |
EP1647971A2 (fr) * | 2004-10-12 | 2006-04-19 | AT&T Corp. | Dispositif et méthode pour la compréhension du language parlé utilisant l'étiquetage de rôle semantique |
-
2012
- 2012-05-25 FR FR1201505A patent/FR2991077A1/fr active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1187007A2 (fr) * | 2000-07-21 | 2002-03-13 | Matsushita Electric Industrial Co., Ltd. | Méthode pour le contrôle de dialogue |
US20040085162A1 (en) * | 2000-11-29 | 2004-05-06 | Rajeev Agarwal | Method and apparatus for providing a mixed-initiative dialog between a user and a machine |
EP1647971A2 (fr) * | 2004-10-12 | 2006-04-19 | AT&T Corp. | Dispositif et méthode pour la compréhension du language parlé utilisant l'étiquetage de rôle semantique |
Non-Patent Citations (2)
Title |
---|
KATRIN ERK ET AL: "SHALMANESER- A Toolchain For Shallow Semantic Parsing", PROCEEEDINGS OF LREC 2006, 26 May 2006 (2006-05-26), Genova, pages 1 - 6, XP055062204 * |
XAVIER CARRERAS ET AL: "Introduction to the CoNLL-2005 Shared Task: Semantic Role Labeling", PROCEEDINGS OF THE 9TH CONFERENCE ON COMPUTATIONAL NATURAL LANGUAGE LEARNING (CONLL), 30 June 2005 (2005-06-30), Ann Arbor, pages 152 - 164, XP055062210 * |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10163440B2 (en) | Generic virtual personal assistant platform | |
US10169471B2 (en) | Generating and executing query language statements from natural language | |
RU2658792C2 (ru) | Определение задач в сообщениях | |
US20190318729A1 (en) | Adaptive interface in a voice-based networked system | |
EP1362343B1 (fr) | Procede, module, dispositif et serveur de reconnaissance vocale | |
EP1364316A2 (fr) | Dispositif d'extraction d'informations d'un texte a base de connaissances | |
EP3053162B1 (fr) | Procede de dialogue entre une machine, telle qu'un robot humanoïde, et un interlocuteur humain, produit programme d'ordinateur et robot humanoïde pour la mise en oeuvre d'un tel procede | |
US20090228270A1 (en) | Recognizing multiple semantic items from single utterance | |
FR2906049A1 (fr) | Procede, mis en oeuvre par ordinateur, de developpement d'une ontologie a partir d'un texte en langage naturel | |
US20170024459A1 (en) | Processing speech to text queries by optimizing conversion of speech queries to text | |
EP2164212A1 (fr) | Procédé et système de communication pour la détermination d'une séquence de services liés à une conversation | |
EP1585110A1 (fr) | Système d'application vocale | |
US20230163988A1 (en) | Computer-implemented system and method for providing an artificial intelligence powered digital meeting assistant | |
FR2876815A1 (fr) | Analyse critique de l'ordre des pronoms clitiques en francais | |
FR3017474A1 (fr) | Saisie assistee de regles dans une base de connaissance | |
US11699430B2 (en) | Using speech to text data in training text to speech models | |
FR2991077A1 (fr) | Systeme interactif de resolution contextuelle d'informations provenant d'un systeme semantique | |
EP2419823A1 (fr) | Procede d'assistance au developpement ou a l'utilisation d'un systeme complexe | |
EP1839213A1 (fr) | Procede de generation d'index textuel a partir d'une annotation vocale | |
EP1981020A1 (fr) | Procédé et système de reconnaissance automatique de la parole adaptés à la détection d'énoncés hors-domaine | |
EP2164237A1 (fr) | Procédé et système de communication pour l'affichage d'un lien vers un service à partir d'une expression énoncée en cours de conversation | |
EP1713243A1 (fr) | Procédé et système de génération automatique de composants logiciels pour la conception de services vocaux | |
FR2986882A1 (fr) | Procede d'identification d'un ensemble de phrases d'un document numerique, procede de generation d'un document numerique, dispositif associe | |
WO2022129760A2 (fr) | Procede de collecte de donnees, procede d'exploitation de donnees collectees, dispositif electronique et produits programme d'ordinateur et support correspondants | |
FR2790586A1 (fr) | Procede et dispositif de reconnaissance vocale |