WO2007088254A1 - Systeme d'information structure, relationnel et incremental - Google Patents

Systeme d'information structure, relationnel et incremental Download PDF

Info

Publication number
WO2007088254A1
WO2007088254A1 PCT/FR2006/000230 FR2006000230W WO2007088254A1 WO 2007088254 A1 WO2007088254 A1 WO 2007088254A1 FR 2006000230 W FR2006000230 W FR 2006000230W WO 2007088254 A1 WO2007088254 A1 WO 2007088254A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
database
criterion
criteria
interface
Prior art date
Application number
PCT/FR2006/000230
Other languages
English (en)
Inventor
Boris Solinski
Original Assignee
Boris Solinski
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Boris Solinski filed Critical Boris Solinski
Priority to PCT/FR2006/000230 priority Critical patent/WO2007088254A1/fr
Publication of WO2007088254A1 publication Critical patent/WO2007088254A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2246Trees, e.g. B+trees

Definitions

  • the invention relates to a structured, relational and incremental information system, and more particularly to the combination of a database, an indexing and search engine, and modeling, input and consultation interfaces. Datas.
  • These links are designed to establish equivalences between data for when a user . launches a search in the database, to maximize the efficiency or the speed of a search engine able to navigate in the graph, for a research as efficient as possible.
  • the present invention aims at least one of those of making reliable and accelerating the input of information, optimizing the performance of the search, increasing the number of competitively searchable criteria, allowing searches by indirection and multilingual queries without translation, to allow not only an interrogation of the data of the database but also of the links that exist between them, and to use less storage space.
  • the invention proposes a structured and relational information system intended to be implemented in a computing environment comprising processing means and storage means, comprising:
  • an indexing and search engine for information in the data graph, and an interface for consulting the database
  • Said information system is characterized in that it furthermore comprises means for incrementally managing the information entered, able to detect partial or total correspondences between information being inputted and data already present in the database, creating dynamic references based on said correspondences, and storing captured information having such correspondences in the form of said dynamic references, to thus gradually capitalize the data present in the database.
  • this information system makes it possible to model and then to enter links between the data already present in the database and the new information to be entered which authorize the user, thanks to the implementation of the search engine in the background capture, reuse, in whole or in part, the data present in the database to accelerate and make reliable the capture, but also to establish correspondences or references between the data to increase the performances, the possibilities and the depth search for these data at the consultation.
  • links or references are not used to establish equivalences between tables, but instead replace the data itself so that information, even several times in the database, does not exist. it is stored only by a single record designating the original datum and by as many references to this original datum as there are occurrences of it in the database.
  • the management means are able to store, together with the references, associated data reflecting the differences between said information entered with respect to said present data, giving thus their dynamic nature to said references.
  • the management means are capable of performing the detection of correspondence in the background during the input of the information, and are also able to generate a signaling in the event of detected correspondence, said dynamic references being created after validation by the user in response to such signaling.
  • the database has a hierarchical structure, and a single dynamic reference to a data, which is associated with data of lower hierarchical degree, also constitutes a dynamic reference to said data of lower hierarchical degree.
  • the system also comprises means for traversing the data graph by using said dynamic references in the opposite direction, namely by starting from said data already present in the database to the newly entered information.
  • the database has a hierarchical and tree structure of criteria, the criteria being nested in strata where each stratum depends on an upper stratum and is entirely contained in it, and so on up to a so-called stratum parent stratum which contains all the others, and the system includes means for establishing recurrences between criteria so as to minimize the number of criteria in the structure, the reuse of a criterion already existing in the structure causing the establishment of such a criterion. recurrence in the form of a correspondence of nature between the criterion created and the already existing criterion.
  • a format is applied to each of said criteria including, in addition to the known formats, a link to a given file, an alphanumeric string with validation key, a digital with a convertible unit, a reference pointing to another criterion of the structure, or a container for delimiting sets of criteria.
  • the input interface defines input means comprising at least one of:
  • each criterion is associated with an indicator of necessity, distributed on a decreasing scale of N grades, and chosen when the criterion is created in the structure of the database; the system then comprises means associated with the input interface to control the presence by default, in active or inactive form, of said criteria at the input, the possibility or not to delete said criteria to the input, or the generation or not signaling at the input and replay, in the input interface according to the indicators of necessity associated with said criteria.
  • the system comprises means associated with the input interface for pre-filling input fields according to a predetermined pattern, so as to reuse previously entered data to form a dynamic template some fields are already completed by default under form of references, this template can be stored as such and reused later alternately with others.
  • the interface for consulting the database are associated search means implementing a single query composed of keywords and able to browse the graph of data to report on the one hand results corresponding directly to the crossing keywords of the query, and secondly results that are related to the keywords of the query via dynamic references or links between layers, and regardless of the language of the query or that of graph data.
  • the search means are capable of performing a search on the graph of weighted nodes, said weighting varying according to the criterion specifically associated with the node and depending on the nature of the request.
  • * at the interface for the consultation of the database are associated firstly means for automatically attaching an entered keyword to a given criterion of the structure according to at least one process selected from the group comprising the 'phonemic analysis of the indexed information, the determination of the position of the keyword in the query, the taking into account of a hierarchy of criteria according to a predetermined weighting, the analysis of previously performed queries and their results, and on the other hand means of dialogue with the user to remove the ambiguity in the case where no criterion could be attached to a keyword according to the process or processes in question.
  • phonemic simplification means keywords at the interface for the consultation of the database are associated phonemic simplification means keywords, said means being able to browse a tree of possibilities corresponding to a predefined language of the user, and to compare the phonemes possible with a phonemic lexicon established from the information of the database.
  • associated sorting means obtained results able to operate when the number of results is greater than a threshold, the sort being performed according to a criterion depending on the criteria used in the query applied to the search engine, selected in descending order of weight.
  • FIG. 1 represents the general architecture of a database system according to the invention, allowing the data entry, their storage in the database, and the consultation of said database for an information search.
  • Figure 2 is a block diagram illustrating a first simple data capitalization method according to the invention.
  • Figure 3 is a block diagram illustrating a second method of capitalization, chained this time, of nested data according to the invention.
  • a “tree” refers to a nested, non-cyclic structure of one or more objects, consisting of links and nodes.
  • a “base” refers to the database, that is to say all the referenced information.
  • a "field” refers to a container associated with a node for one or more values in the form of alphanumeric data, numeric data, dates, etc.
  • a “criterion” refers to the name of a node or a field, regardless of its position in the graph.
  • a "document” refers to the medium used as the source of the information to be referenced.
  • a "format” refers to a category of data that can be entered into a field.
  • a “graph” refers to all the trees that make up the structure of the database and links, cyclical or otherwise, that exist between them.
  • An "identifier” designates the unique code that makes it possible to instantly locate a node in a graph.
  • An “indirection” refers to an alphanumeric reference of one or more data to other data. Indirectness, stored as such and not as autonomous data, is the basis of the "relational" structure of the information system of the present invention.
  • a “node” designates a criterion located in the graph. It contains the metadata relating to the associated field (type, identifier, weight %) as well as the field itself.
  • An “object” refers to a container that allows a set of fields or objects to be grouped according to a semantic unit.
  • an “address” object includes the objects “postal address” and “telephone address”, the latter object grouping together the fields “fax”, “telephone”, etc.
  • a "recovery” is a similarity between data belonging to different objects of the same type. For example, the same work can be edited by several different editors or a format be that of several books, etc.
  • the modeling is the analysis and the factorization of these recoveries which allows the categorization of the data.
  • a “reference” refers to a match between two fields or objects, stored only as a path to the original field or object.
  • a “type” is an alphanumeric code that uniquely defines a criterion. detailed description
  • the system according to the invention which aims to enable the creation, exploitation, processing and consultation of incremental databases, includes a database, an indexing and search engine, consultation interfaces. , data entry and modeling.
  • the database may be stored in a non-volatile memory or other type of memory, and may be exploited, locally or remotely, through software interfaces implemented in a computing environment.
  • the input is achieved by means of input devices, such as a keyboard, a mouse, a touch screen, or others.
  • the base is modeled according to FIG. 1 around a model or architecture, whose predetermined configuration of various criteria defines recurrences of information useful for the capitalization of the input and constituting what is here referred to as engineering.
  • the input allows to store information extracted from source documents in the form of categorized data (Data) which are fully indexed in a Lexicon also containing frequency information of their appearances, and referenced in an index according to their location (parent nodes) and their format in order to constitute a graph of data offered in course to the requests of consultation.
  • Data categorized data
  • Lexicon also containing frequency information of their appearances, and referenced in an index according to their location (parent nodes) and their format in order to constitute a graph of data offered in course to the requests of consultation.
  • the model is arranged to allow:
  • the model leads to a database having a hierarchical and tree structure of criteria, the criteria being nested in strata where each stratum depends on an upper stratum and is entirely contained in it, and so on until a so-called parent stratum which contains all the others.
  • a format is applied to each of said criteria including, in addition to the known formats, a link to a given file, an alphanumeric string format with validation key, a numerical format with a convertible unit, a reference pointing to another criterion of the structure , or a container to delimit sets of criteria.
  • the data is organized into a graph, resulting from the aforementioned hierarchical and tree structure and the creation of additional links within this structure, as described below.
  • Each data item stores one or more information of a source document, a unique identifier corresponding to their location in the graph, the type and the format of the criterion they provide.
  • Recurring data is stored only in the form of a link (or reference) to the original data, namely an identifier that corresponds to the link itself and a coded reference.
  • the Lexicon stores the entirety of the words present in the database in a simplified form phonemically and accompanied by its identifier. Each of the simplified forms points to a list of words, classified by frequency, of which it can be the phonemic simplification. Those skilled in the art will be able to use without difficulty for this purpose the existing phonemic simplification and classification algorithms.
  • the system according to the invention also comprises an inverted index of the data which lists the nodes of the graph, namely the different criteria located in the database. Each of these nodes has an identifier containing information relating to the location of the node in the graph, the path to the original computer file that contains the node, and its position in this file. Each node also includes information about his or her parents, as well as the type and format of the criterion to which it corresponds.
  • the Indexing Engine allows you to create the Lexicon by listing all the constituent terms of the Data as well as their frequency. Using the Model and Engineering, the Indexing Engine creates a reverse graph of data that allows each element of the Lexicon to be placed in the graph. The refreshing of the inverted index is then performed incrementally.
  • the Statistical Search Engine for Nested Objects This search engine is of a statistical nature and uses a predetermined weighting of the links that exist between the nodes to accelerate the graph's journey. This weighting varies according to the criterion of the structure specifically associated with the node and according to the nature of the search query, whether in input mode or in consultation mode. a) being seized
  • the use of the Search Engine in the background during data entry limits the creation of data to only new entries, as it allows redundant entries with identical pre-existing data to generate only references to these entries. data or equivalent objects already present in the database. This method thus makes it possible to capitalize the information in order to accelerate and make the entry more reliable, while eliminating any possibility of duplication (see also FIG. 2 and FIG. 3).
  • the engine makes real-time notifications and suggestions, and the user validates them as they appear during the input process. b) in consultation with the database
  • the Search Engine uses the Lexicon to carry out a fuzzy search based on phonemic simplifications of the terms of the request, in order to bypass possible typing errors and the multiplicity of orthographic declensions. Each term, or set of terms of the query, is assigned one or more types of possible criteria.
  • a Type Conflict Search is then performed using the inverted index of the data, in order to assign a term to a criterion, then the Model, in order to find the lowest common denominator, allows you to choose between several probable criteria assignments.
  • a manual disambiguation interface is proposed to the user, who then knowingly chooses between each of the dubious criteria of his request, according to the recovery rate of the possible types of criteria. To do this, the number of occurrences in the basis of each of these criteria is mentioned in the Disambiguation interface and, depending on the structure of the Model and the content of the Engineering, an automatic suggestion is made to the user.
  • the potential results retained are then located in the data graph (Search for occurrences) by converting the terms of the query into identifiers, carried out during the Search for Type Conflicts by means of the inverse graph of the data. .
  • the "search for occurrences" is then done with maximum relevance.
  • a Ventilation step is implemented so as to allow a quantification of the distribution of the results by using the Model trees and the nature of the request. It is the user who chooses the preferred ventilation through the consultation interface, the interface indicating for each possible "breakdown" the number of expected results.
  • a Dynamic Formatting mechanism manages the dynamic display of the results according to predetermined constraints. These constraints are preferably encoded in the manner of macros, and are outsourced with tool libraries (not shown). Lists of results are sorted by relevance, empty fields are not displayed, some fields can be designated by a label and others not, the labels are preferably tuned in kind and in number according to the content of the field, from genre information stored in the database for some data, etc. It is important to note here that the formatting engine used to present the results as described above is further advantageously used to generate the input interface. These interfaces will now be described in more detail.
  • the input interface can be local or remote, single or multi-station, and allow the competitive entry of data, thanks to the incremental indexing of the database.
  • the interface is optimized for input and thus presents the fields of the database in an order that optimizes the relevance of the search engine, facilitating "ghost" entries as will be described below.
  • the input interface can define input means comprising at least one manual input, a selection in a static or dynamic list, closed or open, a selection in a hierarchical list and tree, closed or open, a route of a graph of data.
  • Means can also be associated with the input interface to pre-fill input fields according to a predetermined pattern, so as to reuse previously entered data to form a dynamic template. some fields are already filled by default as references.
  • This template can be stored as such and reused later or alternatively with others.
  • An option of the system according to the invention is to associate each criterion with a necessity indicator, distributed on a decreasing scale of N grades, and chosen during the creation of said criterion in the structure of the database.
  • necessity indicators may exist: “required” (making it necessary to enter data),
  • Means are also associated with the input interface to control the presence by default, in active or inactive form, of said criteria to the input, the possibility or not to delete said criteria to the input, or the generation or not of signaling at the input and replay, in the input interface according to the necessity indicators associated with said criteria.
  • the Lookup Interface differs from the Input Interface in that it allows you to enter only search queries. These queries can be here of five types: simple (fast), advanced, specialized, thematic or statistical. Unlike the input, the data is displayed according to the logic of the object to be displayed, in order to facilitate readability.
  • the Consulting Interface is associated with the search tools described above; it is implemented from a single query composed of keywords, and is able to traverse the data graph to report:
  • the Consultation Interface also includes:
  • the interface for consulting the database can also be associated with tools for analyzing the data found by the research, making it possible, for example, to determine the type and number of data, their completeness, the links that unite them to the data. other data and their layout on the interface compared to other data.
  • the interface for the consultation can also be associated with phonemic simplification means keywords, these means being able to browse a tree of possibilities corresponding to a predefined language of the user, and to compare the possible phonemes with the Lexicon (see above) based on information from the database.
  • the interface for the consultation can be associated with means for sorting the results obtained able to operate when the number of results is greater than a threshold, the sorting being performed according to a criterion depending on the criteria used in the application applied to the search engine, selected in descending order of weight.
  • the consultation interface can in particular be associated with quantitative interrogation means which make it possible to obtain a count and a classification of the objects of the database by means of a single request containing:
  • the incremental entry solicits in real time and in the background the statistical search engine for nested objects, which itself relies on the search processes. illustrated in the central region of Figure 1 and as described above.
  • the search engine detects no correspondence (or similarity) partial or total between the information being input and data already present in the database: the information entered is new because it is not in the database, in which case it is stored as it was entered, with its type and unique identifier.
  • the search engine detects partial or total correspondences (or similarities) between the information being inputted and data already present in the database.
  • the search engine then performs (in addition to a possible completion of a word being entered), in the case where the field for which the entry is made corresponds to a node which has child nodes (nested fields), a suggestion which includes a display, in the input interface, of the similar data detected at the corresponding node of the graph, as well as data corresponding to the different child nodes, all in ad hoc fields of the input interface.
  • the system through the input tool, creates, if appropriate after validation by the user, one or more dynamic references according to said correspondences.
  • the system stores together with said dynamic references data associated with said references and reflecting the differences in the information entered with respect to the data present. These associated data may be able to reflect additions, deletions or replacements.
  • the system does not store the information entered as data, but stores it only as a dynamic reference to the pre-existing similar data.
  • the user can progressively capitalize the data present in the database: only one or more links are therefore created, the information entered is not stored in duplicate (these links can, however, as we saw above). above contain data that alter the data pointed by adding information to it, by masking it or partially overloading it).
  • the object A contains the objects B, B 'and B ", which each contain in turn an object, respectively C, C and C, as for the object A ', it contains only the objects B' and B ", identical to the first ones.
  • Figure 2B shows the use of references (links) in substitution of the object itself when a data being input is identical or similar to a pre-existing data in the database.
  • the search may be necessary to apply the search in a decreasing way to the architecture, as shown schematically in Figure 3. More precisely, if a C object is contained in a object B itself contained in an object A (here three layers), the system is preferably able to perform a similarity search by successive layers. Thus, in the case of the entry of a field C, the first search is here performed on the object A, and it is only if it remains unsuccessful that a second search is performed on the object B, which if it fails in turn is finally done on the object C itself.
  • the system makes it possible to ensure that the success of the intersection of the city does not prevent the overlapping of the complete record, much more interesting.
  • the score, scanned or not, is the source document.
  • the model of this partition is defined as follows, in descending order: commercial article (group), physical partition (physical unit), version / edition (form), musical work (conceptual unit), movement (elementary unit). The input follows the same order. If the commercial article and the physical partition are unique each time, since referencing is a cataloging that involves entering the same product only once, it is different from:
  • Vivaldi has composed more than a thousand works, the system allows to reuse his record at least as many times. In addition, as many of his works have been published several times by different publishers, the possibilities of reuse of data concerning him are increased tenfold. Of course, the efficiency of the incremental capture system is even greater than the composer has composed much, which the case of Vivaldi.
  • the search engine would not have immediately crossed the result, knowing that we are looking for a work here and not composer. He would have started by announcing a very high number of solutions to research, say 342, which correspond to the number of works of Vivaldi present in the database.
  • the search in consultation uses according to the present invention the same general means as the search in the background while typing, but the problem is radically different. Indeed, it is not a question here to report a file already entered to accelerate the entry, but to list all possible results present in the database, proposing a ranking by relevance.
  • the search is not done from categorized fields (composer, title, tone) but from an indeterminate single search window. Imagine for example that the operator has entered in this window: "violin baroc four sesons" (sic) indicating further that it is a partition he is looking for. According to the above general description, the following steps will be observed:
  • the search yields too many results, and the system automatically offers a breakdown.
  • the operator may be offered the option of deleting partitions with only extracts from the works he is looking for, such as the compilation previously evoked, or in the case of homonymous parts of the same period to keep only The four seasons of Vivaldi, those he seeks, etc.
  • this breakdown is directly related to the content and structure of the database. 6.
  • a formatting of the sorted data is then performed and presented to the user via the consultation interface. In the first place appear the French editions whose title of the scores is strictly identical to that of the research which is in French. Then foreign publications, then finally those with a different title, whose relevance with research is less strong.
  • the present invention is particularly applicable to a database restricted to a specific data domain, so that the data of the database have strong conceptual links with each other, thus implying a high recovery rate during a search implemented.
  • One of said data domains may thus be chosen, in a non-exhaustive manner, from the following fields: culture (music such as a score database as given in the preceding example, records, books, films, etc.), health (drugs %), cataloging consumer products (wine, ready-to-wear %), spare parts and other areas in general.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un système d'information structuré et relationnel destiné à être mis en oevre dans un environnement informatique comprenant des moyens de traitement et des moyens de mémorisation, comprenant : - des moyens de conception d'une structure hiérarchique de base de données constituée en graphe de noeuds, - une interface de saisie des informations destinées à constituer la base de données, - un moteur d'indexation et de recherche des informations dans le graphe de données, et - une interface pour la consultation de la base de données, caractérisé en ce qu'il comprend en outre des moyens de gestion incrémentale des informations saisies, aptes à détecter des correspondances partielles ou totales entre des informations en cours de saisie et des données déjà présentes dans la base de données, à créer des références dynamiques en fonction desdites correspondances, et à stocker des informations saisies ayant de telles correspondances sous forme desdites références dynamiques, pour ainsi progressivement capitaliser les données présentes dans la base de données.

Description

« SYSTEME D'INFORMATION STRUCTURE, RELATIONNEL ET INCREMENTAL »
DOMAINE DE L'INVENTION
L'invention concerne un système d'information structuré, relationnel et incrémental, et plus particulièrement la combinaison d'une base de données, d'un moteur d'indexation et de recherche, et d'interfaces de modélisation, de saisie et de consultation des données.
ETAT DE LA TECHNIQUE
De nombreuses techniques d'acquisition, d'organisation, de traitement et de consultation de données sont connues.
Il est aussi connu de concevoir des modèles de bases de données ayant une architecture en graphe de nœuds, à travers laquelle les données, éventuellement traitées, ont des liens entre elles.
Ces liens sont conçus de sorte à établir des équivalences entre des données pour, lorsqu'un utilisateur. lance une recherche dans la base de données, maximiser l'efficacité ou la rapidité d'un moteur de recherche apte à naviguer dans le graphe, pour une recherche la plus performante possible.
La performance de la recherche et du stockage de données dans ces systèmes existants de bases de données est ralentie voire incapable de donner des résultats en raison de la complexité des requêtes à plusieurs mots-clés concurrentiels, des problèmes et des contraintes de diversité de langues, des sources et formats des données à référencer dans la base, de contraintes inconciliables liées à la fiabilité et à la rapidité de saisie des données, et/ou d'une nécessité quelquefois de créer des masques de consultation spécifiques trop volumineux ou trop complexes. De plus, les informations contenues dans ces types de base sont souvent redondantes, et conduisent à des bases de données très volumineuses, difficilement gérables.
La présente invention a pour objectif au moins l'un parmi ceux consistant à fiabiliser et à accélérer la saisie d'information, à optimiser les performances de la recherche, à accroître le nombre de critères interrogeables de façon concurrentielle, à autoriser des recherches par indirection et des requêtes multilingues sans traduction, à permettre non seulement une interrogation des données de la base mais aussi des liens qui existent entre elles, et à utiliser moins d'espace de stockage.
RESUME DE L'INVENTION
Pour atteindre ce but, l'invention propose un système d'information structuré et relationnel destiné à être mis en œuvre dans un environnement informatique comprenant des moyens de traitement et des moyens de mémorisation, comprenant :
- des moyens de conception d'une structure hiérarchique de base de données constituée en graphe de nœuds,
- une interface de saisie des informations destinées à constituer la base de données,
- un moteur d'indexation et de recherche des informations dans le graphe de données, et - une interface pour la consultation de la base de données,
Ledit système d'information est caractérisé en ce qu'il comprend en outre des moyens de gestion incrémentale des informations saisies, aptes à détecter des correspondances partielles ou totales entre des informations en cours de saisie et des données déjà présentes dans la base de données, à créer des références dynamiques en fonction desdites correspondances, et à stocker des informations saisies ayant de telles correspondances sous forme desdites références dynamiques, pour ainsi progressivement capitaliser les données présentes dans la base de données.
Plus précisément, ce système d'information permet de modéliser puis de saisir des liens entre les données déjà présentes dans la base et les nouvelles informations à entrer qui autorisent l'utilisateur, grâce à la mise en œuvre du moteur de recherche en tâche de fond à la saisie, à réutiliser, en tout ou partie, les données présentes dans la base afin d'accélérer et de fiabiliser la saisie, mais aussi d'établir des correspondances ou références entre les données pour accroître les performances, les possibilités et la profondeur de recherche de ces données à la consultation.
A la différence d'une base de données relationnelle classique, les liens ou références ne servent pas à établir des équivalences entre des tables, mais se substituent aux données elles-mêmes afin qu'une information, même présente plusieurs fois dans la base, ne soit stockée que par un seul enregistrement désignant la donnée originale et par autant de références vers cette donnée originale qu'il existe d'occurrences de celle-ci dans la base.
Certaines caractéristiques préférées mais non limitatives de ce système d'information sont :
* en présence de correspondance partielle entre les informations saisies et les données présentes dans la base de données, les moyens de gestion sont aptes à stocker, conjointement aux références, des données associées reflétant les différences entre lesdites informations saisies par rapport auxdites données présentes, donnant ainsi leur caractère dynamique auxdites références.
* lesdites données associées sont aptes à refléter des ajouts, des suppressions ou des remplacements.
* les moyens de gestion sont aptes à effectuer la détection de correspondances en tâche de fond pendant la saisie des informations, et sont également aptes à engendrer une signalisation en cas de correspondance détectée, lesdites références dynamiques étant créées après validation par l'utilisateur en réponse à une telle signalisation.
* la base de données présente une structure hiérarchique, et une seule référence dynamique vers une donnée, à laquelle sont associées des données de degré hiérarchique inférieur, constitue également une référence dynamique vers lesdites données de degré hiérarchique inférieur.
* le système comprend également des moyens pour parcourir le graphe de données en utilisant lesdites références dynamiques en sens inverse, à savoir en partant desdites données déjà présentes dans la base de données vers les informations nouvellement saisies.
* la base de données présente une structure hiérarchique et arborescente de critères, les critères étant imbriqués en strates où chaque strate dépend d'une strate supérieure et est intégralement contenue dans celle-ci, et ainsi de suite jusqu'à une strate dite strate mère qui contient donc toutes les autres, et le système comprend des moyens pour établir des récurrences entre critères de façon à minimiser le nombre de critères dans la structure, la réutilisation d'un critère déjà existant dans la structure provoquant l'établissement d'une telle récurrence sous forme d'une correspondance de nature entre le critère créé et le critère déjà existant.
* un format est appliqué à chacun desdits critères comprenant, outre les formats connus, un lien vers un fichier donné, une chaîne alphanumérique avec clef de validation, un numérique avec une unité convertible, une référence pointant sur un autre critère de la structure, ou un conteneur permettant de délimiter des ensembles de critères.
* l'interface de saisie définit des moyens de saisie comprenant au moins un moyen parmi :
- l'entrée manuelle, - la sélection dans une liste statique ou dynamique, fermée ou ouverte, - la sélection dans une liste hiérarchique et arborescente, fermée ou ouverte,
- le parcours d'un graphe de données.
* à chaque critère est associé un indicateur de nécessité, réparti sur une échelle décroissante de N grades, et choisi lors de la création dudit critère dans la structure de la base de données ; le système comprend alors des moyens associés à l'interface de saisie pour contrôler la présence par défaut, sous forme active ou inactive, desdits critères à la saisie, la possibilité ou non de supprimer lesdits critères à la saisie, ou encore la génération ou non de signalisations à la saisie et à la relecture, dans l'interface de saisie en fonction des indicateurs de nécessité associés auxdits critères.
* le système comprend des moyens associés à l'interface de saisie pour effectuer un préremplissage de champs de saisie selon un canevas prédéterminé, de manière à permettre de réutiliser des données précédemment saisies pour constituer un gabarit dynamique dont certains champs sont déjà complétés par défaut sous forme de références, ce gabarit pouvant être stocké en tant que tel et réutilisé ultérieurement alternativement avec d'autres. * à l'interface pour la consultation de la base de données sont associés des moyens de recherche mettant en œuvre une requête unique composée de mots-clés et apte à parcourir le graphe de données pour rapporter d'une part des résultats correspondant directement au croisement des mots-clés de la requête, et d'autre part des résultats qui sont liés aux mots-clés de la requête par l'intermédiaire de références dynamiques ou de liens entre strates, et ce indifféremment de la langue de la requête ou de celle des données du graphe.
* les moyens de recherche sont aptes à effectuer une recherche sur le graphe de nœuds pondérés, ladite pondération variant en fonction du critère spécifiquement associé au nœud et en fonction de la nature de la requête. * à l'interface pour la consultation de la base de données sont associés d'une part des moyens pour rattacher automatiquement un mot-clé saisi à un critère donné de la structure en fonction d'au moins un processus choisi dans le groupe comprenant l'analyse phonémique des informations indexées, la détermination de la position du mot-clé dans Ia requête, la prise en compte d'une hiérarchie des critères en fonction d'une pondération prédéterminée, l'analyse de requêtes effectuées antérieurement et de leurs résultats, et d'autre part des moyens de dialogue avec l'utilisateur pour lever l'ambiguïté dans le cas où aucun critère n'a pu être rattaché à un mot-clé selon le ou les processus en question.
* à l'interface pour la consultation de la base de données sont associés des moyens de simplification phonémique des mots-clés, lesdits moyens étant aptes à parcourir un arbre de possibilités correspondant à une langue prédéfinie de l'utilisateur, et à comparer les phonèmes possibles avec un lexique phonémique établi à partir des informations de la base de données.
* à l'interface pour la consultation de la base de données sont associés des moyens de tri des résultats obtenus aptes à opérer lorsque le nombre de résultats est supérieur à un seuil, le tri étant effectué selon un critère dépendant des critères utilisés dans la requête appliquée au moteur de recherche, sélectionné selon un ordre décroissant de poids.
* à l'interface pour la consultation de la base de données sont associés des moyens d'analyse des données permettant de déterminer au moins une caractéristique des données telle que Ie genre des données, leur nombre, leur complétude, et les liens qu'elles possèdent avec autres données.
* à l'interface de consultation sont associés des moyens d'interrogation quantitatifs aptes à produire un dénombrement et un classement des objets à partir d'un ou de plusieurs critères de classement indiqués en même temps qu'une requête de recherche. BREVE DESCRIPTION DES FIGURES
D'autres caractéristiques, buts et avantages de l'invention apparaîtront dans la description qui va maintenant en être faite en référence aux figures annexées qui en représentent à titre indicatif mais non limitatif, un mode de réalisation possible. Sur les dessins :
La figure 1 représente l'architecture générale d'un système de bases de données selon l'invention, permettant la saisie de données, leur stockage dans la base, et la consultation de ladite base pour une recherche d'informations.
La figure 2 est un schéma fonctionnel illustrant un premier procédé simple de capitalisation des données selon l'invention.
La figure 3 est un schéma fonctionnel illustrant un second procédé de capitalisation, enchaînée cette fois, de données imbriquées selon l'invention.
DESCRIPTION DETAILLEE DE L'INVENTION
Définitions préliminaires
Dans le présent mémoire, les termes suivants seront utilisés : Un « arbre » désigne une structure imbriquée et non cyclique d'un ou plusieurs objets, constituée de liens et de nœuds.
Une « base » désigne la base de données, c'est-à-dire l'ensemble des informations référencées.
Un « champ » désigne un conteneur associé à un nœud pour une ou plusieurs valeurs sous forme de données alphanumériques, numériques, dates, etc.
Un « critère » désigne l'appellation d'un nœud ou d'un champ, indifféremment de sa position dans le graphe.
Un « document » désigne le support utilisé comme source des informations à référencer. Un « format » désigne une catégorie de données qui peut être saisie dans un champ.
Un « graphe » désigne l'ensemble des arbres qui constituent la structure de la base de données et des liens, cycliques ou non, qui existent entre eux.
Un « identifiant » désigne le code unique qui permet de localiser instantanément un nœud dans un graphe.
Une « indirection » désigne une référence alphanumérique d'une ou plusieurs données à d'autres données. L'indirection, stockée en tant que telle et non en tant que donnée autonome, est la base de la structure « relationnelle » du système d'information de la présente invention.
Un « nœud » désigne un critère localisé dans le graphe. Il contient les métadonnées relatives au champ associé (type, identifiant, poids...) ainsi que le champ lui-même.
Un « objet » désigne un conteneur qui permet de regrouper un ensemble de champs ou d'objets selon une unité sémantique. Par exemple un objet « adresse » comprend les objets « adresse postale » et « adresse téléphonique », ce dernier objet regroupant les champs « fax », « téléphone », etc.
Un « recouvrement » désigne une similarité entre des données appartenant à des objets différents de même type. Par exemple, une même œuvre peut être éditée par plusieurs éditeurs différents ou un format être celui de plusieurs livres, etc. La modélisation est l'analyse et la factorisation de ces recouvrements qui permet la catégorisation des données.
Une « référence » désigne une correspondance entre deux champs ou objets, stockée seulement sous la forme d'un chemin vers le champ ou l'objet original. Un « type » désigne un code alphanumérique qui définit de façon unique un critère. Description détaillée
Le système selon l'invention, qui a pour but de permettre la création, l'exploitation, le traitement et la consultation de bases de données incrémentales, comporte une base de données, un moteur d'indexation et de recherche, des interfaces de consultation, de saisie et de modélisation des données.
La base de données peut être stockée dans une mémoire non volatile ou autre type de mémoire, et peut être exploitée, de façon locale ou distante, par l'intermédiaire d'interfaces logicielles mises en œuvre dans un environnement informatique.
La saisie est réalisée au moyen de périphériques d'entrée, tels qu'un clavier, une souris, un écran tactile, ou autres.
L'organisation de la base de données
La base est modélisée selon la figure 1 autour d'un Modèle ou architecture, dont la configuration prédéterminée de différents critères définit des récurrences d'informations utiles à la capitalisation de la saisie et constitutives de ce qu'on désigne ici par Ingénierie.
La saisie permet de stocker les informations extraites de documents sources sous forme de données catégorisées (Données) qui sont intégralement répertoriées dans un Lexique contenant également une information de fréquence de leurs apparitions, et référencées dans un index selon leur localisation (nœuds parents) et leur format afin de constituer un graphe de données offert en parcours aux requêtes de consultation.
Le Modèle est agencé pour permettre :
- de constituer, à partir d'un nombre restreint de critères sélectionnés selon leur pertinence et leur taux de recouvrement, une structure complexe ; et - d'attribuer à chaque critère des caractéristiques intrinsèques qui commanderont Ie traitement et l'exploitation desdits critères à la saisie comme à la recherche.
Avantageusement, le Modèle conduit à une base de données ayant une structure hiérarchique et arborescente des critères, les critères étant imbriqués en strates où chaque strate dépend d'une strate supérieure et est intégralement contenue dans celle-ci, et ainsi de suite jusqu'à une strate dite strate mère qui contient donc toutes les autres. Un format est appliqué à chacun desdits critères comprenant, outre les formats connus, un lien vers un fichier donné, un format de chaîne alphanumérique avec clef de validation, un format numérique avec une unité convertible, une référence pointant sur un autre critère de la structure, ou un conteneur permettant de délimiter des ensembles de critères.
L'Ingénierie permet d'attribuer, s'il y a lieu, à chaque critère une couche de données récurrentes qui définissent les contenus possibles, extensibles ou non, de chacun d'entre eux.
Ces récurrences entre critères vont permettre de minimiser le nombre de critères dans la structure, Ia réutilisation d'un critère déjà existant dans Ia structure provoquant l'établissement d'une telle récurrence sous forme d'une correspondance de nature entre le critère créé et le critère déjà existant.
Les Données sont organisées en graphe, résultant de la structure hiérarchique et arborescente précitée et de la création de liens additionnels au sein de cette structure, comme cela est décrit par la suite.
Chaque donnée stocke une ou plusieurs informations d'un document source, un identifiant unique correspondant à leur localisation dans le graphe, le type et le format du critère qu'elles renseignent. Les données récurrentes ne sont stockées que sous la forme d'un lien (ou référence) vers la donnée originale, à savoir un identifiant qui correspond au lien lui-même et une référence codée.
Le Lexique stocke l'intégralité des mots présents dans la base sous une forme simplifiée phonémiquement et accompagnée de son identifiant. Chacune des formes simplifiées pointe vers une liste de mots, classés par fréquence, dont elle peut être la simplification phonémique. L'homme du métier saura utiliser sans difficulté à cet effet les algorithmes de simplification et de classification phonémiques existants. Le système selon l'invention comprend également un index inversé des données qui répertorie les nœuds du graphe, à savoir les différents critères localisés dans la base. Chacun de ces nœuds possède un identifiant contenant des informations relatives à la localisation du nœud dans le graphe, le chemin vers le fichier informatique d'origine qui contient le nœud, et sa position dans ce fichier. Chaque nœud comprend également des informations sur son ou ses parents, ainsi que le type et le format du critère auquel il correspond.
On va maintenant décrire en détail les différents éléments « actifs » du système tels qu'illustrés sur la figure 1.
Le Moteur d'indexation
Le Moteur d'indexation permet de créer le Lexique en répertoriant tous les termes constitutifs des Données ainsi que leur fréquence. En utilisant le Modèle et l'Ingénierie, le Moteur d'indexation crée un Graphe inverse des données qui permet de replacer chacun des éléments du Lexique dans le graphe. L'actualisation de l'index inversé est ensuite effectuée de façon incrémentale.
Le Moteur de recherche statistique des objets imbriqués Ce Moteur de recherche est de nature statistique et utilise une pondération prédéterminée des liens qui existent entre les nœuds pour accélérer le parcours du graphe. Cette pondération varie en fonction du critère de la structure spécifiquement associé au nœud et en fonction de la nature de la requête de recherche, que ce soit en mode saisie ou en mode consultation. a) en cours de saisie
L'utilisation du Moteur de recherche en tâche de fond à la saisie permet de limiter les créations de données aux seules entrées nouvelles, dans la mesure où il permet que des entrées redondantes avec des données identiques pré-existantes ne génèrent que des références vers ces données ou les objets équivalents déjà présents dans la base. Ce procédé permet ainsi de capitaliser les informations pour accélérer et fiabiliser la saisie, tout en supprimant toute éventualité de doublon (voir aussi figure 2 et figure 3). Le moteur effectue ses signalisations et ses suggestions en temps réel, et l'utilisateur les valide au fur et à mesure qu'elles apparaissent au cours du processus de saisie. b) en consultation de la base de données Le Moteur de recherche utilise le Lexique pour effectuer une recherche floue à partir de simplifications phonémiques des termes de la requête, cela afin de passer outre d'éventuelles erreurs de frappe et la multiplicité des déclinaisons orthographiques. Chaque terme, ou ensemble des termes de la requête, se voit attribuer un ou plusieurs types de critères possibles.
Dans le cas où plusieurs types de critères sont possibles pour un terme ou un ensemble de termes donnés, une Recherche des conflits de types est alors effectuée en utilisant l'index inversé des données, afin d'attribuer un terme à un critère, puis le Modèle, afin de trouver le plus petit dénominateur commun, permet de choisir entre plusieurs attributions probables de critères. Dans le cas ou des ambiguïtés de critères ne pourraient être tranchées automatiquement, une interface de Désambiguïsation manuelle est proposée à l'utilisateur, qui choisit alors sciemment entre chacun des critères douteux de sa requête, selon le taux de recouvrement des types de critères possibles. Pour ce faire, le nombre d'occurrences dans la base de chacun de ces critères est mentionné dans l'interface de Désambiguïsation et, en fonction de la structure du Modèle et du contenu de l'Ingénierie, une suggestion automatique est faite à l'utilisateur. Les résultats potentiels retenus sont alors localisés dans le graphe de données (Recherche des occurrences) grâce à la conversion des termes de la requête en identifiants, effectuée à l'occasion de la Recherche des conflits de types par l'intermédiaire du Graphe inverse des données. La « recherche des occurrences » se fait alors avec une pertinence maximale.
Si le nombre de résultats est supérieur à un nombre seuil prédéterminé, une étape de Ventilation est mise en oeuvre de sorte à permettre une quantification de la répartition des résultats en utilisant les arborescences du Modèle et selon la nature de la requête. C'est l'utilisateur qui choisit à travers l'Interface de consultation la ventilation préférée, l'interface lui indiquant pour chaque « ventilation » possible le nombre de résultats attendus.
Le Moteur de mise en forme
Une fois la dernière étape de la recherche effectuée (en mode consultation), un mécanisme de Mise en forme dynamique (cf. figure 1) gère l'affichage dynamique des résultats selon des contraintes prédéterminées. Ces contraintes sont de préférence encodées à la façon de macros, et sont externalisées avec des bibliothèques d'outils (de façon non illustrée). Les listes de résultats sont classées par ordre de pertinence, les champs vides ne sont pas affichés, certains champs peuvent être désignés par une étiquette et d'autres non, les étiquettes sont de préférence accordées en genre et en nombre selon le contenu du champ, à partir d'informations de genre mémorisées dans la base pour certaines données, etc. II est important de noter ici que le Moteur de mise en forme utilisé pour présenter les résultats comme décrit ci-dessus est en outre avantageusement utilisé pour générer l'Interface de saisie. On va maintenant décrire plus en détail ces interfaces.
L'Interface de saisie
Elle permet d'entrer dans la base les informations extraites des documents sources (en général des documents papier ou numérisés) pour les stocker sous la forme de données. L'Interface de saisie peut être locale ou distante, monoposte ou multiposte, et permettre la saisie concurrentielle des données, grâce à l'indexation incrémentale de la base.
Plusieurs assistants, selon des facteurs prédéterminés dans le Modèle, permettent de guider, sécuriser et accélérer la saisie. L'interface est optimisée pour la saisie et présente donc les champs de la base selon un ordre qui permet d'optimiser la pertinence du moteur de recherche, en facilitant les saisies par « fantôme » telles qu'on va les décrire plus loin.
Ainsi, l'interface de saisie peut définir des moyens de saisie comprenant au moins une entrée manuelle, une sélection dans une liste statique ou dynamique, fermée ou ouverte, une sélection dans une liste hiérarchique et arborescente, fermée ou ouverte, un parcours d'un graphe de données.
Des moyens peuvent aussi être associés à l'interface de saisie pour effectuer un préremplissage de champs de saisie selon un canevas prédéterminé, de manière à permettre de réutiliser des données précédemment saisies pour constituer un gabarit dynamique dont certains champs sont déjà complétés par défaut sous forme de références.
Ce gabarit peut être stocké en tant que tel et réutilisé ultérieurement ou alternativement avec d'autres. Une option du système selon l'invention est d'associer chaque critère à un indicateur de nécessité, réparti sur une échelle décroissante de N grades, et choisi lors de la création dudit critère dans la structure de la base de données.
Par exemple, les indicateurs de nécessité suivants peuvent exister : « requis » (rendant indispensable la saisie d'une donnée),
« obligatoire » (rendant nécessaire la saisie d'une donnée, mais dont la validation peut toutefois être forcée), « recommandé » (une alerte est déclenchée si la donnée n'est pas saisie, mais la saisie peut être validée par l'utilisateur), « facultatif » (est proposé à la saisie mais ne déclenche pas d'alerte), « exceptionnel » (n'est pas proposé à la saisie, mais peut être créé par le personnel de saisie).
Des moyens sont en outre associés à l'interface de saisie pour contrôler la présence par défaut, sous forme active ou inactive, desdits critères à la saisie, la possibilité ou non de supprimer lesdits critères à la saisie, ou encore la génération ou non de signalisations à la saisie et à la relecture, dans l'interface de saisie en fonction des indicateurs de nécessité associés auxdits critères.
Ces indicateurs de nécessité peuvent donc aider à la saisie, et peuvent aussi être par exemple associés à des moyens de signalisation d'un blocage de la saisie dans certains cas (par exemple, si un champ
« requis » ou « obligatoire » n'est pas saisi, la saisie peut rester bloquée tant que l'utilisateur ne l'aura pas rempli).
L'Interface de consultation
L'Interface de consultation se distingue de l'Interface de saisie en ce qu'elle ne permet d'entrer que des requêtes de recherche. Ces requêtes peuvent être ici de cinq types : simple (rapide), avancé, spécialisé, thématique ou statistique. A la différence de la saisie, les données sont affichées selon la logique propre à l'objet à afficher, afin d'en faciliter la lisibilité. L'Interface de consultation est associée aux outils de recherche décrits plus haut ; elle est mise en oeuvre à partir d'une requête unique composée de mots-clés, et est apte à parcourir le graphe de données pour rapporter :
- des résultats correspondant directement au croisement des mots-clés de la requête, et
- des résultats qui sont liés aux mots-clés de la requête par l'intermédiaire de références dynamiques ou de liens entre strates.
Ceci est réalisé indifféremment de la langue de la requête ou de celle des données du graphe.
L'Interface de consultation comprend également :
- des moyens pour rattacher automatiquement un mot-clé saisi à un critère donné de la structure en fonction d'un processus d'analyse phonémique des informations indexées (cf. Recherche floue phonémique des termes sur la figure 1), de détermination de la position du mot-clé dans la requête, de prise en compte d'une hiérarchie des critères en fonction d'une pondération prédéterminée, et/ou d'analyse de requêtes effectuées antérieurement et de leurs résultats, et - de moyens de dialogue avec l'utilisateur pour lever l'ambiguïté dans le cas où aucun critère n'a pu être rattaché à un mot-clé selon le ou les processus en question (cf. Recherche des conflits de types et Désambiguïsation sur la figure 1).
L'interface pour la consultation de la base de données peut aussi être associée à des outils d'analyse des données trouvées par la recherche, permettant de déterminer par exemple Ie genre et le nombre des données, leur complétude, les liens qui les unissent aux autres données et leur disposition sur l'interface par rapport aux autres données.
L'interface pour la consultation peut aussi être associée à des moyens de simplification phonémique des mots-clés, ces moyens étant aptes à parcourir un arbre de possibilités correspondant à une langue prédéfinie de l'utilisateur, et à comparer les phonèmes possibles avec le Lexique (cf. plus haut) établi à partir des informations de la base de données.
En outre, l'interface pour la consultation peut être associée à des moyens de tri des résultats obtenus aptes à opérer lorsque le nombre de résultats est supérieur à un seuil, le tri étant effectué selon un critère dépendant des critères utilisés dans Ia requête appliquée au moteur de recherche, sélectionné selon un ordre décroissant de poids.
L'interface de consultation peut en particulier être associée à des moyens d'interrogation quantitatifs qui permettent d'obtenir un dénombrement et un classement des objets de la base par l'intermédiaire d'une requête unique contenant :
- un critère obligatoire de questionnement sur lequel porte la réponse recherchée et optionnellement une valeur pour ce critère,
- un ou plusieurs critères facultatifs de filtre qui circonscrivent la question et optionnellement une valeur pour ceux-ci, et
- un critère facultatif de classement qui donne l'ordre de classement de Ia réponse et l'entrée optionnelle d'une valeur pour celui-ci.
Le procédé de saisie incrémentale
Comme illustré sur la figure 1 , la saisie incrémentale sollicite en temps réel et en tâche de fond le Moteur de recherche statistique des objets imbriqués, qui lui même s'appuie sur les processus de recherche illustrées dans la région centrale de la figure 1 et tels qu'on les a décrits plus haut.
Lorsque l'utilisateur saisit une information dans un champ, deux cas de figure peuvent se présenter : 1. le Moteur de recherche ne détecte aucune correspondance (ou similitude) partielle ou totale entre les informations en cours de saisie et des données déjà présentes dans la base de données : l'information saisie est alors nouvelle car ne se trouvant pas dans la base, auquel cas elle est stockée comme elle a été saisie, avec son type et son identifiant unique.
2. le Moteur de recherche détecte des correspondances (ou similitudes) partielles ou totales entre les informations en cours de saisie et des données déjà présentes dans la base de données. Le moteur de recherche effectue alors (outre une éventuelle complétion d'un mot en cours de saisie), dans le cas où le champ pour lequel la saisie est effectuée correspond à un nœud qui possède des nœuds enfants (champs imbriqués), une suggestion qui comprend un affichage, dans l'interface de saisie, de la donnée similaire détectée au nœud correspondant du graphe, ainsi que des données correspondant aux différents nœuds enfants, le tout dans des champs ad hoc de l'Interface de saisie.
Dans ce cas, le système, au travers de l'outil de saisie, crée, le cas échéant après validation par l'utilisateur, une ou plusieurs références dynamiques en fonction desdites correspondances. En présence de correspondance partielle entre les informations saisies et les données présentes dans la base de données, le système mémorise conjointement avec lesdites références dynamiques des données associées auxdites références et reflétant les différences dans les informations saisies par rapport aux données présentes. Ces données associées peuvent être aptes à refléter des ajouts, des suppressions ou des remplacements. En cas de donnée saisie strictement identique à une donnée préexistante, Ie système ne stocke pas l'information saisie sous forme de donnée, mais la stocke uniquement sous forme de référence dynamique à la donnée similaire préexistante. Ainsi, l'utilisateur peut progressivement capitaliser les données présentes dans la base de données : seuls un ou plusieurs liens sont donc créés, l'information saisie n'étant pas stockée en double (ces liens pouvant toutefois comme on l'a vu ci-dessus contenir des données qui altèrent la donnée pointée en lui ajoutant des informations, en la masquant ou en la surchargeant partiellement).
En référence à la figure 2A, on a illustré des objets imbriqués dans l'architecture selon l'invention : l'objet A contient les objets B, B' et B", qui chacun contiennent à leur tour un objet, respectivement C, C et C ; quant à l'objet A', il contient seulement les objets B' et B", identiques aux premiers.
En admettant au moins un champ par objet, la saisie des objets A et A' représenterait pas moins de 12 champs à remplir.
La figure 2B montre l'utilisation de références (liens) en substitution de l'objet lui-même lorsqu'une donnée en cours de saisie est identique ou similaire à une donnée préexistante dans la base. On comprend que grâce à ce mécanisme d'indirection l'opérateur n'a plus qu'à remplir 7 champs soit, dans ce cas précis, une économie de plus de 40%.
L'intérêt de ces liens va bien au-delà pour des bases de données contenant des millions de données avec un fort taux de recouvrement, où les gains de temps peuvent être considérables.
Enfin on comprend qu'une référence interdit les doublons et les erreurs de saisie. En effet, si une erreur est détectée, il suffit de corriger l'objet originel et tous les champs pointant sur lui sont instantanément corrigés, facilitant d'autant la maintenance. Ce procédé est donc aussi intéressant qualitativement que quantitativement. La capitalisation par fantôme
Pour obtenir les bénéfices maximaux de ce procédé à la saisie, il peut s'avérer nécessaire d'appliquer de manière décroissante la recherche à l'architecture, comme illustré schématiquement sur la figure 3. Plus précisément, si un objet C est contenu dans un objet B lui-même contenu dans un objet A (ici trois strates), le système est de préférence apte à effectuer une recherche de similarité par strates successives. Ainsi, dans le cas de la saisie d'un champ C, la première recherche est ici effectuée sur l'objet A, et ce n'est que si elle reste sans succès qu'une seconde recherche est effectuée sur l'objet B, qui si elle échoue à son tour se fait enfin sur l'objet C lui-même.
L'intérêt de cette précaution est de s'assurer, puisque tous les objets sont imbriqués, que le recoupement de données s'effectue toujours de la façon la plus efficace possible, au niveau le plus pertinent.
En effet, si nous prenons un exemple dans lequel l'objet A est une fiche d'identité, l'objet B une adresse et l'objet C une ville, le système permet d'assurer que le succès du recoupement de la ville n'empêche pas le recoupement de la fiche complète, beaucoup plus intéressant.
Or, il est nécessaire d'attendre la saisie de la ville pour s'assurer qu'il s'agisse bien des mêmes coordonnées.
Exemple
On va maintenant donner un exemple concret de mise en oeuvre de la présente invention, en observant tout d'abord que l'application de l'invention à une base multilingue est particulièrement pertinente, car plusieurs langues impliquent un taux de recouvrement très fort dans la mesure où les mêmes données, même en plusieurs langues, sont par essence identiques. On va ainsi décrire l'application de l'invention à une base de données de partitions de musique, les partitions étant notoirement diffusées telles quelles dans le monde entier sans traduction (Ia notation musicale étant universelle), d'où un fort taux de recouvrement de mêmes objets dans des langues différentes.
A) A la saisie
La partition, numérisée ou non, est le document source. Le modèle de cette partition est défini comme il suit, par ordre décroissant : article commercial (groupe), partition physique (unité physique), version/édition (forme), oeuvre musicale (unité conceptuelle), mouvement (unité élémentaire). La saisie suit le même ordre. Si l'article commercial et la partition physique sont à chaque fois uniques, puisque le référencement est un catalogage qui consiste à entrer qu'une seule fois le même produit, il en est différemment de :
• la version, qui peut être une réédition d'une œuvre existante ;
• l'œuvre, qui peut être publiée sous différentes formes chez plusieurs éditeurs (arrangements, transcriptions, réductions, etc.) ; • le mouvement qui peut être produit seul en tant qu'extrait d'une œuvre.
Dès lors, si par exemple on souhaite saisir une partition des Quatre Saisons, une œuvre de Vivaldi publiée par des dizaines d'éditeurs dans le monde, et en admettant que l'œuvre en tant que telle est déjà dans la base, il suffit d'entrer par exemple la bonne référence au catalogue universel des œuvres, qui liste l'ensemble des œuvres de Vivaldi et qui figure en couverture d'une partition, noté RV suivi de 3 chiffres, pour que le moteur de recherche propose immédiatement la bonne œuvre (titre, tonalité, instrumentation, date de composition...), ainsi que le compositeur correspondant avec toute sa fiche (prénom, nom, biographie, œuvres composées...). Ainsi pour un critère entré, il est possible d'en récolter des dizaines proposés automatiquement par le moteur de recherche. C'est l'intérêt d'une base dont le taux recouvrement est fort : Vivaldi ayant composé plus d'un millier d'œuvres, le système permet de réutiliser sa fiche au moins autant de fois. En outre, comme nombre de ses œuvres ont été publiées plusieurs fois par des éditeurs différents, les possibilités de réutilisations des données le concernant en sont décuplées. Bien entendu, l'efficacité du système de saisie incrémentale est d'autant plus grande que le compositeur a beaucoup composé, ce qui le cas de Vivaldi. Comme décrit en référence à la figure 3, si l'opérateur avait commencé par entrer le nom du compositeur dans un objet œuvre, le moteur de recherche n'aurait pas croisé immédiatement le résultat, sachant que l'on recherche ici une œuvre et non un compositeur. Il aurait commencé par annoncer un nombre très élevé de solutions à la recherche, mettons 342, qui correspondent au nombre d'oeuvres de Vivaldi présentes dans la base. La liste étant trop importante, l'opérateur aurait continué à saisir l'oeuvre, par exemple avec la tonalité (sol majeur), ce qui aurait permis au moteur de conserver par exemple 53 concertos dans la tonalité choisie qui répondent à la fois aux deux critères. L'opérateur aurait ensuite saisi l'instrumentation (combien d'instruments et lesquels), ce qui aurait donné par exemple 2 œuvres. L'opérateur aurait alors demandé l'affichage des résultats et retrouvé Les Quatre Saisons.
On constate à partir de cet exemple que l'ordre des critères est fondamental pour obtenir un résultat exploitable rapidement, et que cet ordre doit être en fonction du déterminisme de chaque critère (critère plus ou moins qualifiant) et non des critères logiques de la consultation. Entrer le titre aurait pu paraître logique mais n'est pas pertinent dans une base multilingue, dont les titres sont forcément différents. Dans le présent exemple, une simple recherche textuelle par titre sur Les quatre saisons n'aurait pas permis de déceler II Quatro Stagioni qui est pourtant le titre italien original de l'œuvre. B) A la consultation
La recherche à la consultation utilise selon la présente invention les mêmes moyens généraux que la recherche en tâche de fond en cours de saisie, mais la problématique en est radicalement différente. En effet, il ne s'agit pas ici de rapporter une fiche déjà entrée afin d'accélérer la saisie, mais de lister tous les résultats possibles présents dans la base, en proposant un classement par pertinence. D'autre part, la recherche s'effectue non pas à partir de champs catégorisés (compositeur, titre, tonalité) mais à partir d'une fenêtre de recherche unique indéterminée. Imaginons par exemple que l'opérateur ait saisi dans cette fenêtre : « violon baroc quatre sésons » (sic) en indiquant en outre que c'est une partition qu'il recherche. Selon la description générale qui précède, les étapes suivantes vont être observées :
1. La recherche phonémique floue va rétablir « saisons » et « baroque », et retrouver l'identifiant de chaque terme.
2. La recherche des conflits de type va détecter dans un premier temps une ambiguïté entre : a.« Les saisons + 4 violons baroques » b.« Les quatre saisons + baroque + violon » (ce qu'ici l'opérateur cherche) c.« Les saisons baroques + 4 violons » d. « Les quatre saisons + violon baroque » e.« Les quatre saisons baroques + violon ».
En fait si chaque critère peut être un élément d'un titre, « violon » va être détecté comme instrument (Ie plus probable) et « saisons », qui ne peut pas être autre chose, comme un titre. Le doute subsiste pour « baroque », qui peut être le qualificatif de l'instrument violon ou de l'époque musicale (période 1600-1750), et le chiffre 4 qui peut être le nombre d'instruments ou de saisons. 3. Comme il existe des titres de compositions intitulées « saisons », une désambiguïsation est alors demandée à l'utilisateur : recherche-t-il une composition pour « quatre violons baroques » ou « quatre violons » ou « violon baroque » ou « violon ». L'utilisateur qui cherche Les quatre saisons indique « violon ». L'utilisation d'une analyse syntaxique peut être mise en œuvre optionnellement et permet alors de supprimer automatiquement l'ambiguïté portant sur « quatre », le terme étant situé avant saisons au pluriel et après violon au singulier.
4. La recherche des occurrences est alors effectuée par le système après avoir attribué « violon » au champ instrument, « 4 saisons » au champ titre de l'œuvre et « baroque » à l'époque musicale (on observera ici que puisque Ie titre « quatre saisons baroques » n'existe pas, il ne peut y avoir ambiguïté sur ce point).
Tous ces critères sont donc croisés, en même temps que leurs identifiants respectifs, avec les œuvres contenues dans la base. En effet, si l'opérateur recherche des partitions, c'est par l'unité conceptuelle (à savoir l'œuvre), toujours identique et donc présentant un fort taux de recouvrement, qu'une recherche exhaustive peut être effectuée. La recherche peut ainsi rapporter des résultats en italien (II Quatro Stagioni), en anglais (The Four Seasons), en allemand (Die Wier Jahreszeit), et ainsi de suite, mais aussi une compilation française intitulée Les grands concertos baroques car elle comporte le concerto L'été qui fait partie de l'œuvre Les quatre saisons. L'intérêt de ce procédé ne réside donc pas seulement dans son application à une base multilingue, mais surtout parce qu'il peut rapporter des résultats dont l'entrée de fiche porte un intitulé complètement différent. Il s'agit donc bien d'une recherche exhaustive.
5. Sur une pièce aussi connue que Les Quatre Saisons, la recherche donne de trop nombreux résultats, et le système propose alors automatiquement une ventilation. L'opérateur peut par exemple se voir proposé de supprimer les partitions ne comportant que des extraits des œuvres qu'il cherche, comme la compilation précédemment évoquée, ou dans le cas de pièces homonymes de la même époque de ne conserver que Les quatre saisons de Vivaldi, celles qu'il cherche, etc. On l'aura compris, cette ventilation est directement liée au contenu et à Ia structure de la base de données. 6. Une mise en forme des données triées est alors opérée et présentée à l'utilisateur via l'interface de consultation. En premier lieu apparaissent les éditions françaises dont le titre des partitions est strictement identique à celui de la recherche qui est en français. Ensuite les publications étrangères, puis enfin celles comportant un titre différent, dont la pertinence avec la recherche est moins forte.
La présente invention s'applique particulièrement à une base de données restreinte à un domaine de données précis, de sorte que les données de la base aient de forts liens conceptuels entre elles, impliquant ainsi un fort taux de recouvrement lors d'une recherche mise en œuvre au moyen d'un moteur de recherche dans un graphe selon l'invention.
Un desdits domaines de données peut ainsi être choisi, de façon non exhaustive, parmi les domaines suivants : culture (musique telle qu'une base de partitions comme donné dans l'exemple qui précède, disques, livres, films...), santé (médicaments...), catalogage de produits de grande consommation (vin, prêt-à-porter...), de pièces détachées et autres domaines de façon générale.

Claims

REVENDICATIONS
1. Système d'information structuré et relationnel destiné à être mis en œuvre dans un environnement informatique comprenant des moyens de traitement et des moyens de mémorisation, comprenant :
- des moyens de conception d'une structure hiérarchique de base de données constituée en graphe de nœuds,
- une interface de saisie des informations destinées à constituer la base de données,
- un moteur d'indexation et de recherche des informations dans le graphe de données, et
- une interface pour la consultation de la base de données, caractérisé en ce qu'il comprend en outre des moyens de gestion incrémentale des informations saisies, aptes à détecter des correspondances partielles ou totales entre des informations en cours de saisie et des données déjà présentes dans la base de données, à créer des références dynamiques en fonction desdites correspondances, et à stocker des informations saisies ayant de telles correspondances sous forme desdites références dynamiques, pour ainsi progressivement capitaliser les données présentes dans la base de données.
2. Système selon la revendication 1, caractérisé en ce que, en présence de correspondance partielle entre les informations saisies et les données présentes dans la base de données, les moyens de gestion sont aptes à stocker conjointement avec lesdites références dynamiques des données associées auxdites références et reflétant les différences dans lesdites informations saisies par rapport auxdites données présentes.
3. Système selon la revendication 2, caractérisé en ce que lesdites données associées sont aptes à refléter des ajouts, des suppressions ou des remplacements.
4. Système selon l'une des revendications précédentes, caractérisé en ce que les moyens de gestion sont aptes à effectuer la détection de correspondances en tâche de fond pendant la saisie des informations, et en ce qu'ils sont également aptes à engendrer une signalisation en cas de correspondance détectée, lesdites références dynamiques étant créées après validation par l'utilisateur en réponse à une telle signalisation.
5. Système selon l'une des revendications précédentes, caractérisé en ce que la base de données présente une structure hiérarchique, et en ce qu'une seule référence dynamique vers une donnée à laquelle sont associées des données de degré hiérarchique inférieur constitue également une référence dynamique vers lesdites données de degré hiérarchique inférieur.
6. Système selon l'une des revendications précédentes, caractérisé en ce qu'il comprend également des moyens pour parcourir le graphe de données en utilisant lesdites références dynamiques en sens inverse, à savoir en partant desdites données déjà présentes dans la base de données vers les informations nouvellement saisies.
7. Système selon l'une des revendications précédentes, caractérisé en ce que la base de données présente une structure hiérarchique et arborescente de critères, les critères étant imbriqués en strates où chaque strate dépend d'une strate supérieure et est intégralement contenue dans celle-ci, et ainsi de suite jusqu'à une strate dite strate mère qui contient donc toutes les autres, et en ce qu'il comprend des moyens pour établir des récurrences entre critères de façon à minimiser le nombre de critères dans la structure, la réutilisation d'un critère déjà existant dans la structure provoquant l'établissement d'une telle récurrence sous forme d'une correspondance de nature entre le critère créé et le critère déjà existant.
8. Système selon la revendication précédente caractérisé en ce qu'un format est appliqué à chacun desdits critères comprenant, outre les formats connus, un lien vers un fichier donné, une chaîne alphanumérique avec clef de validation, un numérique avec une unité convertible, une référence pointant sur un autre critère de la structure, ou un conteneur permettant de délimiter des ensembles de critères.
9. Système selon l'une des revendications précédentes, caractérisé en ce que l'interface de saisie définit des moyens de saisie comprenant au moins un moyen parmi :
- l'entrée manuelle,
- la sélection dans une liste statique ou dynamique, fermée ou ouverte,
- la sélection dans une liste hiérarchique et arborescente, fermée ou ouverte,
- le parcours d'un graphe de données.
10. Système selon l'une des revendications 7 et 8, ou selon la revendication 9 prise dans la dépendance des revendications 7 et 8, caractérisé en ce qu'à chaque critère est associé un indicateur de nécessité, réparti sur une échelle décroissante de N grades, et choisi lors de la création dudit critère dans la structure de la base de données, et en ce qu'il comprend des moyens associés à l'interface de saisie pour contrôler la présence par défaut, sous forme active ou inactive, desdits critères à la saisie, la possibilité ou non de supprimer lesdits critères à la saisie, ou encore la génération ou non de signalisations à la saisie et à la relecture, dans l'interface de saisie en fonction des indicateurs de nécessité associés auxdits critères.
11. Système selon l'une des revendications précédentes, caractérisé en ce qu'il comprend des moyens associés à l'interface de saisie pour effectuer un préremplissage de champs de saisie selon un canevas prédéterminé, de manière à permettre de réutiliser des données précédemment saisies pour constituer un gabarit dynamique dont certains champs sont déjà complétés par défaut sous forme de références, ce gabarit pouvant être stocké en tant que tel et réutilisé ultérieurement alternativement avec d'autres.
12. Système selon l'une des revendications précédentes, caractérisé en ce qu'à l'interface pour la consultation de la base de données sont associés des moyens de recherche mettant en œuvre une requête unique composée de mots-clés et aptes à parcourir le graphe de données pour rapporter d'une part des résultats correspondant directement au croisement des mots-clés de la requête, et d'autre part des résultats qui sont liés aux mots-clés de la requête par l'intermédiaire de références dynamiques ou de liens entre strates, et ce indifféremment de la langue de la requête ou de celle des données du graphe.
13. Système selon la revendication 12, caractérisé en ce que les moyens de recherche sont aptes à effectuer une recherche sur un graphe de nœuds pondérés, ladite pondération variant en fonction du critère de la structure spécifiquement associé au nœud et en fonction de la nature de la requête.
14. Système selon l'une des revendications 12 et 13, caractérisé en ce qu'à l'interface pour la consultation de la base de données sont associés d'une part des moyens pour rattacher automatiquement un mot-clé saisi à un critère donné de la structure en fonction d'au moins un processus choisi dans le groupe comprenant l'analyse phonémique de mots-clés de la requête, la détermination de la position de ce mot- clé au sein de la requête, la prise en compte d'une hiérarchie des critères en fonction d'une pondération prédéterminée, l'analyse de requêtes effectuées antérieurement et de leurs résultats, et d'autre part des moyens de dialogue avec l'utilisateur pour lever l'ambiguïté dans le cas où aucun critère n'a pu être rattaché à un mot-clé selon le ou les processus en question.
15. Système selon l'une des revendications 12 à 14, caractérisé en ce qu'à l'interface pour la consultation de la base de données sont associés des moyens de simplification phonémique des mots-clés, lesdits moyens étant aptes à parcourir un arbre de possibilités correspondant à une langue prédéfinie de l'utilisateur, et à comparer les phonèmes possibles avec un lexique phonémique établi à partir des informations de la base de données.
16. Système selon l'une des revendications 12 à 15, caractérisé en ce qu'à l'interface pour la consultation de la base de données sont associés des moyens de tri des résultats obtenus aptes à opérer lorsque le nombre de résultats est supérieur à un seuil, le tri étant effectué selon un critère dépendant des critères utilisés dans la requête appliquée au moteur de recherche, sélectionné selon un ordre décroissant de poids.
17. Système selon l'une des revendications 12 à 16, caractérisé en ce qu'à l'interface pour la consultation de la base de données sont associés des moyens d'analyse des données permettant de déterminer au moins une caractéristique des données telle que le genre des données, leur nombre, leur complétude, et les liens qu'elles possèdent avec les autres données.
18. Système selon l'une des revendications 12 à 17, caractérisé en ce qu'à l'interface de consultation sont associés des moyens de recherche aptes à produire un dénombrement et un classement des résultats d'une requête d'interrogation quantitative contenant un critère de questionnement, avec le cas échéant une valeur imposée, et au moins un critère facultatif de filtre et/ou de classement.
PCT/FR2006/000230 2006-02-02 2006-02-02 Systeme d'information structure, relationnel et incremental WO2007088254A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/FR2006/000230 WO2007088254A1 (fr) 2006-02-02 2006-02-02 Systeme d'information structure, relationnel et incremental

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FR2006/000230 WO2007088254A1 (fr) 2006-02-02 2006-02-02 Systeme d'information structure, relationnel et incremental

Publications (1)

Publication Number Publication Date
WO2007088254A1 true WO2007088254A1 (fr) 2007-08-09

Family

ID=37460255

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/000230 WO2007088254A1 (fr) 2006-02-02 2006-02-02 Systeme d'information structure, relationnel et incremental

Country Status (1)

Country Link
WO (1) WO2007088254A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105320658A (zh) * 2014-06-04 2016-02-10 北京军区政治部文化工作和网络宣传教育中心 一种卡拉ok节目数据存储方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0597630A1 (fr) * 1992-11-04 1994-05-18 Conquest Software Inc. Procédé pour résoudre des demandes en langage naturel dans des bases de données de textes
US5937422A (en) * 1997-04-15 1999-08-10 The United States Of America As Represented By The National Security Agency Automatically generating a topic description for text and searching and sorting text by topic using the same
WO2000079436A2 (fr) * 1999-06-24 2000-12-28 Simpli.Com Interface pour moteur de recherche

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0597630A1 (fr) * 1992-11-04 1994-05-18 Conquest Software Inc. Procédé pour résoudre des demandes en langage naturel dans des bases de données de textes
US5937422A (en) * 1997-04-15 1999-08-10 The United States Of America As Represented By The National Security Agency Automatically generating a topic description for text and searching and sorting text by topic using the same
WO2000079436A2 (fr) * 1999-06-24 2000-12-28 Simpli.Com Interface pour moteur de recherche

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105320658A (zh) * 2014-06-04 2016-02-10 北京军区政治部文化工作和网络宣传教育中心 一种卡拉ok节目数据存储方法

Similar Documents

Publication Publication Date Title
US10445359B2 (en) Method and system for classifying media content
US20050289111A1 (en) Method and apparatus for processing metadata
FR2821186A1 (fr) Dispositif d'extraction d'informations d'un texte a base de connaissances
CN102640145A (zh) 可信查询系统和方法
EP1515239A1 (fr) Procédé et systéme de manipulation de données issues de bases de données multidimensionnelles à l'aide d'un tableur
CN102810114A (zh) 基于本体的个人计算机资源管理系统
US8589413B1 (en) Concept-based method and system for dynamically analyzing results from search engines
EP0988607A1 (fr) Dispositif d'analyse et d'organisation de donnees
Meder et al. Automatic enrichment and classification of folktales in the Dutch Folktale Database
WO2021111095A1 (fr) Sauvegarde de documents en blocs
Kushmerick Finite-state approaches to web information extraction
CN100361126C (zh) 使用本体论和用户查询处理技术解决问题的方法
WO2007088254A1 (fr) Systeme d'information structure, relationnel et incremental
JPH09223150A (ja) 情報分類処理方法
Thollot et al. Text-to-query: dynamically building structured analytics to illustrate textual content
JPH1166078A (ja) 検索要求具体化方法及び装置及び検索要求具体化プログラムを格納した記憶媒体
FR3101166A1 (fr) Procédé et système pour éditorialiser des contenus d’enregistrements audio ou audiovisuels numériques d’une intervention orale
CN107818126A (zh) 一种面向Mongo数据库的全文信息检索方法
JP2001318935A (ja) 情報処理装置及び方法、情報処理用ソフトウェアを記録した記録媒体並びにリレーショナルデータベース
FR3096157A1 (fr) procédé d’indexation multidimensionnelle de contenus textuels
Thottempudi A visual narrative of ramayana using extractive summarization topic modeling and named entity recognition
FR3032290A1 (fr) Procede de production automatique d'une base de donnees a partir d'un modele de donnees generique et d'une taxinomie
WO2024146958A1 (fr) Procede pour ameliorer l'exploitation de donnees partagee par une pluralite d'utilisateurs
FR3136298A1 (fr) Procede d’association d’une donnee a un document numerique, systeme associe
WO2020169898A1 (fr) Procédé de fourniture d'une information pertinente associée à un brevet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06709222

Country of ref document: EP

Kind code of ref document: A1