WO2022069564A1 - Procédé et dispositif électronique de génération d'une base structurée de données pertinentes pour la gestion d'une mission, programme d'ordinateur associé - Google Patents

Procédé et dispositif électronique de génération d'une base structurée de données pertinentes pour la gestion d'une mission, programme d'ordinateur associé Download PDF

Info

Publication number
WO2022069564A1
WO2022069564A1 PCT/EP2021/076830 EP2021076830W WO2022069564A1 WO 2022069564 A1 WO2022069564 A1 WO 2022069564A1 EP 2021076830 W EP2021076830 W EP 2021076830W WO 2022069564 A1 WO2022069564 A1 WO 2022069564A1
Authority
WO
WIPO (PCT)
Prior art keywords
extraction
data
database
class
law
Prior art date
Application number
PCT/EP2021/076830
Other languages
English (en)
Inventor
Jaime DIAZ PINEDA
Thomak LEDUC
Aurelien THIRIET
Original Assignee
Thales
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 Thales filed Critical Thales
Priority to EP21786392.7A priority Critical patent/EP4222612A1/fr
Publication of WO2022069564A1 publication Critical patent/WO2022069564A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/254—Extract, transform and load [ETL] procedures, e.g. ETL data flows in data warehouses
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/243—Natural language query formulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471—Distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/256—Integrating or interfacing systems involving database management systems in federated or virtual databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
    • G06F16/367—Ontology

Definitions

  • TITLE Process and electronic device for generating a structured database of relevant data for the management of a mission, associated computer program
  • the present invention relates to a method for generating, from a set of database(s), a structured database associated with a mission, the method being implemented by an electronic generation device.
  • the invention also relates to a computer program comprising software instructions which, when executed by a computer, implement such a generation method.
  • the invention also relates to an electronic generation device configured to generate, from a set of database(s), a structured database associated with a mission.
  • the invention applies to the field of decision support for a user confronted with a critical situation during a mission.
  • a critical situation is understood here in the sense of an event during the mission, for which an action is required in order not to jeopardize the mission.
  • a mission is for example the flight of an aircraft for the transport of passengers between two airports.
  • a critical situation would then be, for example: a breakdown of an aircraft engine, a health problem for a passenger, or bad weather conditions on the route of the aircraft.
  • the perception stage consists in acquiring a set of elements describing the situation. However, the environment then runs the risk of being overloaded with elements of no interest to the operator's activity.
  • the relevance of a datum is understood here in the sense of a characteristic possessed by the datum to be appropriate, or even adapted, for the understanding of the situation.
  • the elements are understood to mean relevant data.
  • the perception step is then essential because an error during this step has repercussions on the comprehension and determination steps, and more particularly on a sub-step of projection of future states during the determination step. In particular, the failure to take into account certain relevant data leads to a misunderstanding of these data, causing potentially inappropriate decisions.
  • some processes offer to automatically extract part of the data from database(s), called source(s), according to pre-established extraction rules.
  • the extracted data is then indexed in a new database, called target, smaller than the source database(s).
  • target a new database
  • the contribution of a structure to the target database, organizing the extracted data makes it possible to represent the links between the extracted data and to simplify the understanding of this data.
  • the extraction and classification method presented makes it possible to constitute a target database comprising a smaller quantity of data than the source database. Moreover, each piece of data in the source database, considered as relevant to the theory of the situation, is present in the target database. Thus the target database is more easily treatable, by a user, for the understanding of the situation and the decision making
  • An object of the invention is then to improve the extraction of data and the generation of the target database.
  • the subject of the invention is a method for generating, from a set of database(s), a structured database associated with a mission, the method being implemented by an electronic device generation and comprising the following steps:
  • each extraction rule comprising a first identifier of a class of the structured data base and a law for extracting data(s) from the database(s), each rule being associated with one or more action(s) ) required,
  • the method according to the invention makes it possible to generate a structured database comprising the data extracted from a set of database(s), also called source(s) database(s).
  • database(s) also called source(s) database(s).
  • the choice of an action required by a user and the selection of extraction rule(s), based on this choice makes it possible to carry out a reduced number of extraction(s) while allowing each extracted data to be appropriate in the context of the required action chosen.
  • each extraction rule of a first class identifier makes it possible to organize the structured database independently of the structure of the or each source database.
  • the step of associating the extraction law with the class of unsuccessful query(s) makes it possible to identify the absence, in the set of source base(s), of data responding to a sent extraction law, which then allows the user of the structured base to differentiate the data absent from the set of source base(s) but considered relevant and sought by a law of extraction, data absent from the structured database because considered irrelevant and for which no extraction law has tried to extract them.
  • the method according to the invention comprises one or more of the following characteristics taken in isolation or in all technically possible combinations:
  • the set of database(s) includes at least two databases, and during the sending step, the extraction law included in each selected extraction rule is sent to each database,
  • the at least two extracted data are, during the storage step, stored in the same class of the structured database, corresponding to the first class identifier associated with said extraction law,
  • each data item received includes:
  • each second identifier corresponding to a respective class of said database from which at least one respective extracted datum originates
  • the set of second identifier(s) and the group of criteria (s) being specific to each database and being generated from the extraction law sent, during the storage step, the set of second identifier(s), the group of criteria ) and the set of data(s) are stored in the class corresponding to the first class identifier associated with said extraction law, during the storage step, at least a first relationship between an extracted data item and a second identifier of class is also stored in said class of the structured base,
  • the mission is the flight of an aircraft, the set of action(s) required preferably comprising: a start-up of the aircraft, a diversion of the aircraft and a bypass by the aircraft of a geographical area,
  • invariant data during the mission are also acquired, and during the sending step, at least one sent extraction law is supplemented by at least one invariant datum at the during the mission, if the mission is the flight of an aircraft, the invariant data during the mission preferably comprising a type or model reference of the aircraft, a flight of an aircraft, a departure airport of the aircraft, an initial quantity of fuel in the aircraft,
  • the method further comprises, after the storage or association step:
  • each extraction law includes a set of keyword(s) capable of being translated into second class identifier(s) of each database during of the sending of said law, if at least two second identifiers, associated with the same keyword of an extraction law, are then received during the storage step, a second relation is stored in the structured base of data.
  • each extraction law sent for which no extracted data is received is qualified as unsuccessful, and each unsuccessful law is associated with the class of request(s) unsuccessful under one of the following two conditions:
  • each keyword of the unsuccessful law is associated with a second identifier
  • the invention also relates to an electronic generation device configured to generate, from a set of database(s), a structured database associated with a mission, the device being able to be connected to a set of database(s), the electronic generation device comprising:
  • an acquisition module configured to acquire a list of action(s) required during the mission, and a group of rule(s) for extracting data from the set of database(s) of data, each extraction rule comprising a first identifier of a class of the structured database and a data extraction law from the database or databases, each rule being associated with one or more action(s) required,
  • a generation module configured to generate a structure of the structured database comprising at least one class for each first distinct class identifier, and a class of unsuccessful request(s),
  • a selection module configured to select one or more extraction rules from among the group of extraction rule(s) acquired, according to a required action chosen by a user from the list of required action(s) ( s),
  • a sending module configured to send the extraction law included in each selected extraction rule, to the set of database(s), and a module for receiving data(s) from the bases of data following this sending,
  • a storage module configured to store the or each data received in the class of the structured database (corresponding to the first class identifier associated with the extraction law in response to which said data was received, and
  • an association module configured to associate each extraction law sent, for which no extracted data is received in response from the set of database(s), to the class of request(s) unsuccessful.
  • Figure 1 is a schematic representation of a system for generating a structured database according to the invention, the system comprising a set of database(s) and an electronic generation device, from the set of database(s), a structured database;
  • Figure 2 is a flowchart of a method, according to the invention, for generating a structured database according to the invention, the method being implemented by the electronic generation device of Figure 1 ;
  • Figure 3 is a schematic representation of a structured database, generated according to the generation process shown in Figure 2.
  • a system 5 for generating a structured database 10 comprises a set 15 of database(s) 20 and an electronic device 25 for generating the structured database 10.
  • the generating device 25 is connected to the set 15.
  • the generation system 5 is typically configured to generate a respective structured base 10 per mission.
  • the mission is for example the flight of an aircraft for the transport of passenger(s).
  • the structured database 10 is for example a knowledge base.
  • the denomination “knowledge base” is understood here in the sense of a structured database, further comprising linking elements, hereinafter called relations, making it possible to establish semantic links between the data of the base, such as defined in the chapter “Knowledge Bases vs Databases” of the book 'On Knowledge Base Management Systems', published in 1986, and written by Michael L. Brodie and John Mylopoulos.
  • the set 15 comprises at least one database 20, each database 20 also being called source base 20 hereafter, and at least one translator 30 specific to each source base 20.
  • the assembly 15 is capable of changing dynamically during the process.
  • the presence of each source base 20 is not determined beforehand.
  • the continuous presence of at least one source base 20 and the associated translator 30 is the only constraint, or requirement, associated with the set 15.
  • the generation device 25 is configured to generate the structured base 10 from said set 15.
  • the generation device 25 comprises an acquisition module 35 configured to acquire at least one list of action(s) required during the mission and a group of extraction rule(s), each comprising a law extraction.
  • the generation device 25 comprises a generation module 40 configured to generate a structure of the structured base 10.
  • the generation device 25 also comprises a selection module 45 configured to select one or more extraction rule(s) from among the group of extraction rule(s) based on a required action chosen by a user 47, a module sending 50 configured to send, to set 15, the extraction law included in each selected extraction rule.
  • a selection module 45 configured to select one or more extraction rule(s) from among the group of extraction rule(s) based on a required action chosen by a user 47
  • a module sending 50 configured to send, to set 15, the extraction law included in each selected extraction rule.
  • the generation device 25 also comprises a storage module 55 configured to store one or more data received in response to the extraction law or laws sent, in the class of the structured base 10 corresponding to a first class identifier of the rule extraction, the extraction rule comprising the extraction law having produced the data or data.
  • each datum in the respective class is understood here as synonymous with an indexing, or even a classification, of said datum in said class.
  • the generation device 25 comprises an association module 60 configured to associate each extraction law sent, with a class of unsuccessful request(s) in the absence of a response to said law, from the together 15.
  • the generation device 25 comprises a retrieval module 65 configured to retrieve a request for data(s) from the user 47, a determination module 70 configured to determine whether or not each requested data item is present in the structured base 10, and a communication module 75 configured to communicate a message from what is determined by the determination module 70.
  • the generation device 25 comprises an information processing unit 80 formed for example of a memory 85 and a processor 90 associated with the memory 85.
  • the acquisition module 35, the generation module 40, the selection module 45, the sending module 50, the storage module 55, the association module 60, as well as as an optional complement, the recovery module 65, the determination module 70 and the communication module 75 are each produced in the form of software, or a software brick, and executable by the processor 90.
  • the memory 85 of the device generation 25 is then able to store software for acquiring the list of required action(s) and the group of extraction rule(s), software for generating a structure of the structured base 10, software for selecting extraction rule(s) from the required action chosen by the user 47, software for sending the extraction law included in each selected extraction rule, software storage in the structured base 10 of the or each extracted data item received, in the class corresponding to the first identifier associated with the extraction law in response to which each datum was received, and association software, in the absence of extracted datum(s) received in response to a respective law d extraction sent, from said extraction law to the class of unsuccessful request(s) from the structured base 10.
  • the memory 85 of the generation device 25 comprises software for recovering the request for data(s) from the user 47, software for determining the presence or not in the structured base 10 of each requested datum, and a message communication software based on what is determined by the determination software.
  • the software bricks are linked by arrows each typically representing a function call.
  • the acquisition module 35, the generation module 40, the selection module 45, the sending module 50, the storage module 55, the association module 60, as well as optionally the recovery module 65, the determination module 70 and the communication module 75 are each made in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array), or else a an integrated circuit, such as an ASIC (Application Specific Integrated Circuit).
  • a programmable logic component such as an FPGA (Field Programmable Gate Array)
  • ASIC Application Specific Integrated Circuit
  • the generation device 25 When the generation device 25 is produced in the form of one or more software(s), that is to say in the form of a computer program, it is also capable of being recorded on a medium, not represented, readable by computer.
  • the computer-readable medium is, for example, a medium capable of storing electronic instructions and of being coupled to a bus of a computer system.
  • the readable medium is an optical disc, a magneto-optical disc, a ROM memory, a RAM memory, any type of non-volatile memory (for example EPROM, EEPROM, FLASH, NVRAM), a magnetic card or an optical card.
  • On the readable medium is then stored a computer program comprising software instructions.
  • Each extraction rule includes an extraction law and a respective first class identifier.
  • Each extraction law includes the set of keyword(s), and at least one specificity respectively specifying a characteristic of each keyword or a dependency of several keywords, if applicable.
  • Each extraction law is for example a textual element forming a sentence in natural language, each specificity being, if necessary, a textual expression semantically linking the keywords.
  • each extraction law is in the form of a graph in which each keyword represents a node, and each dependency specificity being represented by an arc connecting two nodes in the case where the graph includes several nodes.
  • NLU Natural Language Understanding
  • Each source base 20 comprises a set of data, each able to be extracted from the source base 20, following a request in a computer language interpretable by the source base 20.
  • Each source base 20 having its own structure and its own language, the translator 30 specific to each source base 20 is configured to translate a respective extraction law expressed in a so-called natural language, into a respective request expressed in the language of the base source 20 or in a language interpretable by the source database 20.
  • a natural language is understood here in the sense of a written or spoken language, which is not a computer language.
  • the French, English and German languages are non-exhaustive examples of natural languages.
  • the computer language, in which the extraction laws are translated into respective queries is for example the so-called SPARQL language (from the English “SPARQL Protocol And R DF Query Language”).
  • Each translator 30 is configured to generate, from the extraction law received, the request comprising at least one second class identifier and at least one extraction criterion.
  • Each second class identifier also called argument, corresponds to a respective class of the source base 20, and then makes it possible to identify such a class.
  • the second class identifiers are for example identified by a first denomination “SELECT” preceding the second identifier.
  • Each extraction criterion also called condition, corresponds to a discriminating characteristic relating to the data of the class identified by a second respective identifier. Thus, only the data satisfying each extraction criterion are extracted.
  • each extraction criterion is identified by a second name "WHERE" preceding said criterion.
  • each SPARQL query is capable of extracting, from the source database 20, the data corresponding to each second class identifier identified by the first denomination "SELECT" and verifying each extraction criterion, each extraction criterion relating to at least a second class identifier.
  • a specific feature of the SPARQL language is that it is not necessary to introduce, prior to the second designation “WHERE”, each second class identifier to which a respective extraction criterion applies.
  • the translator 30 is of the SPARQL type, specific to a respective source base 20 comprising the "aerodrome” and “airstrip” classes, and is configured to translate the extraction law "Find an airport whose runway length is greater than 1.2 km" into a respective SPARQL query comprising the second "aerodrome” class identifier in the form "SELECT aerodrome”, and comprising the extraction criterion in the form “WHERE ⁇ runway landing > 1.2 km ⁇ ”. Only the data, corresponding to the class identified by the second identifier "aerodrome” and for which the class, identified by the second identifier "airstrip”, includes runways longer than 1.2 km, are extracted by the SPARQL query.
  • the translator 30 is known per se, the SWIP project in particular proposing such a translator 30.
  • the translator 30 of the SWIP project is capable of translating a respective extraction law expressed in natural language, into a respective SPARQL query, through a process of Automatic processing of natural language called "TAL".
  • SPARQL-DL SPARQL-DL
  • Snap SPARQL OWL-QL
  • SQWRL SQWRL
  • the set 15 comprises for example at least one of the following source bases 20:
  • AirM-O ATM Information Reference Model Ontology
  • AIXM Aircraft Information exchange Model
  • IWXXM Independent Metal Exchange Model
  • the acquisition module 35 is configured to acquire the list of action(s) required during the mission.
  • Each required action designates an intention of the user 47 during the mission. This intention is said to be high-level, as opposed to a decision taken by the user 47 after consulting the relevant data.
  • the data relevant to making the decision depends, at least in part, on the required action chosen, i.e. the intention chosen.
  • the list of action(s) required includes for example: a start of the aircraft, a diversion of the aircraft and a bypass by the aircraft of a geographical area.
  • the acquisition module 35 is also configured to acquire the group of extraction rule(s).
  • Each extraction rule is associated with the required action from the list of required action(s).
  • each required action makes it possible to carry out a filtering on the data which will be extracted by the extraction law included in each extraction rule associated with said action.
  • the group of extraction rule(s) typically comprises the rules of extraction associated with the diversion action of the aircraft, the extraction law of each of which is for example the following:
  • the keywords are, for example, “airport” and “runway”.
  • the list of extraction rule(s) typically comprises the extraction rules, associated with the action of circumvention by the aircraft of a geographical area, the extraction law of each of which is for example the following: finding the coordinates of the waypoint(s) of the aircraft for which the meteorological conditions correspond to predefined conditions, and distant from the aircraft by at most a second predefined maximum distance D 2max , and find the coordinates of the point(s) of passage of the aircraft for which(s) an internet coverage of a satellite technology.
  • the mission is the follow-up of patients in a hospital.
  • a respective required action is then for example to detect patients at risk of COVID-19 in an emergency department.
  • the extraction rules are then, for example, the following: select all patients from the emergency department who have not been diagnosed with COVID-19 and are over the age of 60, select patients from the emergency department who have not been diagnosed with COVID-19 and have cardiovascular risks, select patients from the emergency department who have not been diagnosed with COVID-19 and who have shared a room with a patient who has COVID- 19, Select hospital patients whose age is within a predefined age range, such as between 30 and 50 years old.
  • the mission is to control a fire.
  • the action required is then to determine suitable means for the management of this fire.
  • the extraction rules are then, for example: determine the emergency vehicles with fire extinguishing services, determine the emergency vehicles equipped with at least one driver, an approved leader and four team members, and determine emergency vehicles present in the area of the accident.
  • the mission is the management of accidents by an SAMU service.
  • a respective required action is then the search for hospitals to take care of a victim, following an accident.
  • a rule of extraction is then to determine the hospitals having a service adapted to a pathology of a victim to be taken care of.
  • the first class identifier included in each extraction rule corresponds to the class of the structured base 10 in which each extracted data must be stored after sending the respective extraction law. More detailed explanations of the classes of the structured base 10 are provided below.
  • the acquisition module 35 is also optionally configured to acquire a set of invariant data(s) during the mission.
  • the set of invariant data(s) includes, where appropriate, data not changing during the mission and known prior to the mission, as well as the first class identifier associated with each of said data for the storage of said datum in the structured base 10.
  • the set of invariant datum(s) also comprises data absent from the set 15 making it possible to complete the extraction laws.
  • the invariant data include for example: a type or a reference of the aircraft, an initial quantity of fuel in the aircraft, a flight number of the mission and a departure airport of the aircraft.
  • the generation module 40 is connected at the output of the acquisition module 35, and is configured to generate the structure of the structured base 10.
  • the structure of the structured base 10 comprises classes, and in particular a respective class for each first identifier of class of the extraction rule(s) group.
  • each first class identifier is chosen from the following six class names: "subject”, “tool(s)", “community”, “rule(s)”, “division of labor”, “target” .
  • This breakdown into six classes is known per se, and comes from the activity theory proposed by Y. Engeström in 1987 in the document “Learning by expanding: An activity-theoretical approach to developmental research, Helsinki: Orienta-Konsultit”.
  • This decomposition is a generic structure making it possible to describe exhaustively a set of necessary elements of an activity while ensuring an objective distinction between classes.
  • class “rule(s)” refers to the business rules to be applied for the achievement of an objective. These business rules correspond to the extraction rules.
  • the generation module 40 is also configured to generate the class of unsuccessful request(s) in the structured base 10.
  • the selection module 45 is connected at the output of the acquisition module 35, and is configured to select at least one respective extraction rule from among those of the group of extraction rule(s).
  • the selection module 45 is configured to select, from the group of extraction rule(s), each rule associated with said chosen action.
  • the selection module 45 is configured to choose the extraction rules associated with the action of diversion of the aircraft, such as those described above. As a corollary, if the required action chosen is to circumvent the aircraft, the selection module 45 is configured to choose the extraction rules which are associated with this required action.
  • the sending module 50 is connected at the output of the selection module, and is configured to send, to set 15, the extraction law of each selected extraction rule.
  • the sending module 50 is configured to send the extraction law included in each selected extraction rule, to each source base 20, via the translator 30 specific to said source base 20.
  • the sending module 50 is optionally configured to complete before sending, and if necessary, a respective extraction law from the data already stored in the structured base 10.
  • the predefined length is preferably completed automatically according to the invariant datum corresponding to the type or model number of the aircraft.
  • the storage module 55 is connected at the output of the selection module 45, and is configured to receive and store, in the structured base 10, one or more elements of the message or messages received in response to the extraction law or laws sent to the set 15.
  • Each message received comprises for example the following elements: a set of data(s) extracted(s), a set of second class identifier(s), and a group of extraction criteria(s).
  • Each message received more precisely comprises a data field comprising two tables.
  • a first table includes the extracted data set.
  • a second table includes the query in SPARQL language that made it possible to extract the extracted data set. The set of second class identifier(s) and the group of extraction criteria(s) are then included in the second table.
  • the storage module 55 is configured to store each set of extracted data, each set of second identifier(s) and each group of extraction criterion(ies) in the class corresponding to the first identifier associated with the law of original extraction of the received data.
  • Each extracted datum corresponds to a respective datum of a source base 20 in response to the extraction law sent.
  • the storage module 55 is configured to store, in the structured base 10, at least a first relationship between a respective extracted datum and a respective second identifier, or between an extracted datum and a respective extraction criterion.
  • the storage module 55 is preferably configured to store, in the appropriate class, each first relation defining a link between two stored elements.
  • Each first relation is for example a textual element, also called an axiom or semantic data triplet.
  • Each first relation makes it possible to define the semantic link between two elements stored in the structured base 10.
  • Each semantic link makes it possible, for example, to define a link of membership, of interdependence, or even of hierarchy between two elements. Such a hierarchical link can be assimilated to a notion of subclass.
  • the semantic link between an extracted data "Bordeaux" and a second identifier "airport", of the type "Bordeaux is an airport” is equivalent to having in the structured base 10, the subclass "airport" included in one of the classes for example from the theory of activity, and including the data extracted "Bordeaux".
  • Such semantic links then make it possible to qualify the structured base 10 as an ontologically organized base, since it comprises, in addition to data, semantic links between its data.
  • Such an ontologically organized basic formalism is said to be of the OWL type (from the English Ontology Web Language or l/l/eb Ontology Language).
  • each first relationship is deduced from the extraction law included in the extraction rule to which it is relative, and in particular specificities of dependence between each keyword in the said law.
  • the storage module 55 is configured to, in the event of reception of several extracted data following the sending of a respective extraction law, store each extracted data received in the structured base 10.
  • the assembly 15 comprises at least two source bases 20, if extracted data is received from several source bases 20, each extracted data is stored in the class corresponding to the first identifier associated with the extraction law at the origin of the extracted data received.
  • the storage module 55 is configured to, if at least two second identifiers received are associated with the same respective keyword of the extraction law, store a second relation in the structured base 10.
  • the second relation then indicates for example that the two second identifiers are synonymous.
  • the storage module 55 is also configured to store the invariant data during the mission in the classes associated with the first identifier of each, if the set of invariant data has been acquired.
  • the storage module 55 is also configured to store the group of extraction rule(s) in the “rule(s)” class, if the structured base 10 includes such a class.
  • the association module 60 is connected at the output of the selection module 45 and at the output of the set 15 of base(s) source(s) 20.
  • the association module 60 is configured to associate each extraction law, for which no fetched data is received, to the class of unsuccessful request(s).
  • the association module 60 is optionally configured to determine that no extracted data is received following the sending of a respective extraction law if the message or messages received from the set 15 only verify at least the one of the following cases: an error message is received from set 15,
  • the association module 60 is configured to receive the requests in SPARQL language at the output of each translator 30.
  • association module 60 is configured to receive from the set 15, for each source base 20 and for each extraction law sent, the set of second class identifier(s), and the group of extraction criteria(s).
  • the set of second class identifier(s) and the group of extraction criterion(ies) are obtained by the translator 30 specific to each source database 20.
  • the association module 60 is optionally configured to qualify the law sent as unsuccessful.
  • the association module 60 is then preferably configured to associate each unsuccessful law with the class of unsuccessful request(s) by placing in said class the set of second identifier(s) and the group of extraction criterion(ies) associated with said law.
  • An extraction law with no response from a set of data extracted i.e. for which the first table of the message received is empty, is considered unsuccessful.
  • This mechanism refers to an absence of the data(s) sought in the set 15 of base(s) source(s) 20. These data are also called missing data.
  • the association module 60 is optionally configured to store, in the class of unsuccessful request(s): each second identifier absent from the structured base 10, each extraction criterion, and at least one third relation linking a second respective identifier and a respective extraction criterion of the unsuccessful law.
  • the association module 60 is preferably configured to store, for each unsuccessful law, each third relationship linking two elements stored by said module 60 and each third relationship linking a second respective identifier already present in the structured base 10 to another respective stored element. by said module 60.
  • association module 60 is optionally configured to, in the event of qualification of an extraction law as unsuccessful, distinguish the configuration concerned from among the first and second possible configurations.
  • the association module 60 is configured to carry out the storage in this case as described above.
  • no data is received because no source base 20 includes the set of class(es) corresponding to the set of keyword(s) of the extraction law qualified as unsuccessful. .
  • the translator 30 of each source base 20 has not succeeded in translating each keyword of the extraction law into a second class identifier of the source base 20 with which it is associated.
  • the association module 60 is in this case, configured to store in the class of unsuccessful request(s), each second identifier absent from the structured base 10, each keyword of the unsuccessful law not having associated second identifier, each extraction criterion and at least one fourth relationship linking said or one of said keywords to a second identifier of the unsuccessful law.
  • the association module 60 is preferably configured to store, for each unsuccessful extraction law, all the fourth relations existing between each second identifier, each keyword, and each extraction criterion, taken two by two.
  • the recovery module 65 is configured to recover a request for data from the user 47.
  • the recovery module 65 is for example configured to recover the request in textual form.
  • the communication module 75 is connected to the output of the determination module 70 and is configured to communicate the message from what has been determined by the determination module 70, to the user 47 or to an electronic processing device, not represented.
  • the communication module is for example a virtual assistant comprising a chatbot interacting with the user 47 through means of communication such as a display screen, an audio system comprising a microphone and/or a loudspeaker, a haptic sensor and/or actuator, or any possible combination of the aforementioned means of communication.
  • the communication module 75 is configured to communicate each requested data present in the structured base 10 to the user 47 or to the electronic processing device.
  • the communication module 75 is also configured to, if the request relates to a second respective class identifier, or if applicable, a respective keyword of the unsuccessful request class, communicate a message indicating that the data requested relates to a or data missing from the set 15 of base(s) source(s) 20 to the user 47 or to the electronic processing device.
  • the communication module 75 is also configured for, if the requested data is absent from the structured base 10 and does not concern a second respective identifier or a respective keyword of the class of unsuccessful request(s) (s), communicate a respective message indicating that the requested data or data has not yet been retrieved, to the user 47 or to the electronic processing device.
  • the communication module 75 is in this case, typically further configured to send the request to the assembly 15 as an extraction law in order to try to obtain the requested data or data.
  • each action required corresponds to the intention of the user 47 during the mission for which data is extracted in order to help him make a decision.
  • Each extraction rule is associated with the required action, and includes the specific extraction law to be sent to the set 15, as well as the first class identifier.
  • Each extraction law comprises the set of keyword(s) and at least the specificity specifying the characteristic of said keyword, or where applicable, the dependence between two keywords.
  • the first class identifier corresponds to the class of the structured base 10 in which the data from the set 15 are stored, following the sending of the extraction law.
  • Invariant data includes data that does not change during the mission and the first class identifier, specific to each data, indicating the class of the structured base 10 in which said data must be stored.
  • Each class is the element of the structure of the structured base 10 corresponding to the first class identifier included in the extraction rule.
  • the structured base 10 also includes the class of unsuccessful request(s).
  • Each request corresponds to the translation by the translator 30 of the extraction law.
  • Each query includes the set of respective second identifier(s) and the respective extraction criteria group(s).
  • Each second class identifier corresponds to the translation, by the translator 30, of a respective keyword of the extraction law.
  • Each second class identifier identifies the respective class of the source base 20 with which the translator 30 is associated.
  • Each extraction criterion corresponds to the translation by the translator 30, of the specificity into the condition for the extraction of the data from the source base 20 with which the translator 30 is associated.
  • Each message received from set 15 includes the set of second class identifier(s), the group of extraction criteria, and if applicable, the set of extracted data(s).
  • Each data item extracted is the data item from the respective source base 20 extracted by the query.
  • Each first relationship corresponds to the link, stored in the structured database 10, between the extracted data and the second class identifier of the associated request, or between the extracted data and the extraction criterion of said request, or between the second identifier and the extraction criterion, or else, where applicable, between two second identifiers.
  • Each second relation corresponds to the link, stored in the structured base 10, between two second class identifiers specifying that they are synonymous, in the case where the two second identifiers are associated with the same respective keyword.
  • Each third relation corresponds to the link, stored in the structured base 10, between the second identifier and the respective extraction criterion of said request, or the case applicable between two second identifiers of a respective request, in the absence of data extracted by said request.
  • Each fourth relation corresponds to the link, stored in the structured base 10, between a second respective identifier or a respective keyword, and another respective second identifier or another respective keyword or else an extraction criterion, each of the same respective request, in the event of absence of translation of a keyword into a second respective class identifier.
  • FIG. 2 representing a flowchart of the method, according to the invention, for generating the structured base 10 , the method being implemented by the generation device 25.
  • the generation device 25 acquires the list of action(s) required during the mission and the group of rule(s) for extracting data from the together 15, via its acquisition module 35.
  • Each extraction rule is associated with a respective required action.
  • the generation device 25 optionally also acquires the set of invariant data(s) during the mission.
  • the generation device 25 then passes to a generation step 120 in which it generates the structure of the structured database 10, via its generation module 40.
  • the generation device 25 optionally stores the set of invariant data(s) in the classes of the structured base 10, as well as the group of extraction rule(s) in the class “rule(s)” if such a class is present.
  • the generation device 25 then proceeds to a selection step 130 in which it selects, following the choice by the user 47 of the action required from the list of action(s) required(s), the rule(s) of extraction associated with the required action chosen.
  • the generation device 25 then proceeds to a sending step 140 in which, via its sending module 50, it sends each selected extraction law to the set 15.
  • the sending module 50 sends the extraction law included in each selected extraction rule, to each translator 30 of each source base 20.
  • the generation device 25 completes the extraction laws from data already stored in the structured base 10.
  • the generation device 25 then proceeds to a first detection step 150, in which it receives, for each extraction law sent, a message from the set 15, and detects the presence or not of the data set(s) extracted(s) in the message received.
  • the generation device 25 For each message received comprising the set of extracted data(s), the generation device 25 stores, during a storage step 160 and via its storage module 55, each extracted data received in the structured database 10.
  • the generation device 25 stores in the class corresponding to the first identifier associated with the extraction law in response to which the extracted data is received. , each second identifier still absent from the structured base 10, each extraction criterion, each extracted datum, and at least one first respective relationship between a respective extracted datum and a respective second identifier.
  • the generation device 25 preferably stores all the first relations between the extracted data, the second identifiers and the extraction criteria.
  • the generation device 25 stores each extracted data received in the class corresponding to the first identifier associated with said extraction law.
  • the generation device 25 stores a second respective relation in the class corresponding to the first identifier of the rule associated with said law.
  • the generation device 25 For each message received that does not include a set of extracted data(s), the generation device 25 proceeds to an association step 170 in which it associates the extraction law at the origin of said message, with the class of unsuccessful request(s).
  • the generation device 25 qualifies said law as unsuccessful.
  • the generation device 25 ranks in the class of unsuccessful request(s), each second identifier absent from the structured base 10, each extraction criterion and at least one third respective relationship linking two second identifiers together or linking a respective second identifier to a respective extraction criterion.
  • the generation device 25 preferably ranks all the third relationships between each second identifier and each extraction criterion.
  • the device for generation 25 range, in the class of unsuccessful request(s): each second class identifier absent from the structured base 10, each keyword not translated into a respective second identifier, each extraction criterion, at least one fourth respective relation linking a second respective identifier or a respective keyword, to a respective extraction criterion or to a second respective identifier or to a respective keyword.
  • each fourth relationship linking two stored elements is preferably also stored in the structured base 170.
  • the generation device 25 repeats the steps of sending 140, storing 160 and associating 170 regularly, and preferably periodically, for updating the data in the structured database 10 .
  • the generation device 25 then optionally goes into a recovery step 180 during which it recovers, via its recovery module 65, the request for data(s) from the user 47.
  • the generation device 25 then proceeds to a determination step 190 in which it determines, via its determination module 70, whether or not each data item requested is contained in the structured database 10.
  • the generation device 25 For each datum requested, if said datum is contained in the structured base 10, the generation device 25 then proceeds to a first communication step 200 during which it communicates, via its communication module 75, the datum requested to the user 47 or to the electronic processing device.
  • the generation device 25 For each requested piece of data missing from the structured base 10, the generation device 25 passes to a second detection step 210 in which it detects whether the request relates to the element(s) stored in the class of requests (s) unsuccessful(s) by detecting whether the request is associated with a respective second identifier, a respective extraction criterion, a third or a respective fourth relation of the class of unsuccessful request(s).
  • the generating device 25 proceeds to a second communication step 220 in which it communicates a message indicating that the requested data or data are absent from the assembly 15, to the user 47 or to the electronic processing device.
  • the generation device 25 optionally passes to a third communication step 230 during which it communicates a message indicating that the or the requested data has not yet been retrieved from the user 47 or the processing device.
  • the generation device 25 optionally sends the request to the set 15 and returns to the storage step 160 if a respective extracted datum is received in return. Otherwise, the generation device 25 passes to the association step 170. In the event of extracted data received in return, the storage module 55 arranges the various elements in a class of the structured base 10 chosen by the user 47.
  • the required action is for example the diversion of the aircraft.
  • the generation device 25 acquires the extraction rules, linked to the required aircraft diversion action, the extraction laws of which are respectively: “find an airport whose length of the runway is greater than a predetermined length L”, and “find an airport whose meteorological conditions correspond to the CAVOK standard, and distant from the aircraft by at most 50 km", CAVOK (from the English “Cloud And Visibility OK”) corresponding to a meteorological standard in which visibility is considered to be good and in which the presence of clouds is limited.
  • the first identifier contained in each of said extraction rules is “mission”.
  • the keywords are: “airport” and “runway”.
  • the keywords are: “airport”, “weather conditions” and “remote”.
  • the acquisition module 35 also acquires the invariant data relating to the reference of the model of the aircraft, for example “Airbus A350”, and to the airport of origin “airport of 'origin Toulouse', each invariant datum being associated with the first class identifier 'mission'.
  • the generation device 25 During the generation step 120, the generation device 25 generates the structure of the structured database 10.
  • the structure must at least include the “mission” class, because it corresponds to the first class identifier of the acquired extraction rules.
  • the structure includes, for example, the six classes of activity theory: “subject”, “tool(s)”, “community”, “division of labour”, “aim”, and “rule(s)”.
  • the “mission” class then corresponds to the “aim” class, so that the “aim” and “mission” classes form one and the same class.
  • the "subject” class is intended to contain data relating to the pilot of the aircraft
  • the "tool(s)” class is intended to contain data relating to the means for carrying out the mission
  • the "community is intended to contain data relating to other entities or individuals who will participate in the execution of the mission such as the co-pilot, the personnel on board, or to the control towers
  • the "division of labor” class is intended to contain data relating to the sharing of the activity with the community
  • the "targeted” class is intended to contain data relating to the mission.
  • the generated structure further comprises the class of unsuccessful request(s), called “unsuccessful request(s)”.
  • the generation device 25 stores the invariant data in the class indicated by their first class identifier.
  • the generation device 25 places the extraction rules in the “rule(s)” class.
  • the extraction rules are respectively referenced R ⁇ and R 2 .
  • the generation device 25 selects the extraction rules associated with the required action “diversion of the aircraft” chosen by the user 47.
  • the generation device 25 completes the extraction law of the first extraction rule with the invariant datum relating to the model reference of the aircraft, stored in the structured database 10.
  • the extraction law of the first extraction rule therefore becomes, for example, “find an airport whose runway length is greater than 1.2 km”.
  • the generation device 25 sends, to the assembly 15, the extraction laws contained in the first and second extraction rules.
  • the generation device 25 receives for each law sent, a message from the assembly 15 and detects the presence or absence of the extracted data set(s).
  • a first (respectively second) message corresponds to the message received following the sending of the extraction law included in the first (respectively second) extraction rule.
  • the first message includes for example the second identifiers: “aerodrome” and “airstrip”, the extraction criterion “airstrip > 1.2 km” and the set of data(s) extracted “ Bordeaux, Limoges »
  • the generation device 25 stores, in the “mission” class of the structured base 10, the second identifiers, the extraction criterion and the extracted data.
  • the second identifiers, the extraction criterion and the extracted data are respectively represented by dotted line boxes, respectively of elliptical, parallelepiped and rectangular shape.
  • the generation device 25 stores in the structured base 10, the first relations: "aerodrome has landing strip”, “Limoges is an aerodrome”, “Bordeaux is an aerodrome”, “Limoges has airstrip”, “Bordeaux has airstrip”, “airstrip > 1.2 km is a type of airstrip”, “Limoges has airstrip > 1.2 km” and “Bordeaux has an airstrip > 1.2 km”.
  • these first relations are represented by dotted line segments each connecting two boxes.
  • the second “aerodrome” identifier is not stored in the unsuccessful request(s) class because it is already present in the “mission” class.
  • the generation device 25 retrieves the following first and second requests from the user 47: "Which airports have a runway at least 1 km long?" and “Which airports have CAVOK weather and are at a distance of less than 30 km from the aircraft? ".
  • the generation device 25 determines that the first request relates to extracted data present in the structured database 10, unlike the second request. For the first request, during the first communication step 200, the generation device 25 communicates the “Bordeaux” and “Limoges” data to the user 47.
  • the generation device 25 passes to the second detection step 210 in which it detects that the second request relates to the class “unsuccessful request(s)” because if the set 15 does not include any datum verifying the extraction criterion relating to the meteorological conditions and being at a distance of less than 50 km from the aircraft, then the set 15 does not comprise any datum verifying the same criterion on the meteorological conditions and distant by at most 30 km .
  • the generation device 25 communicates to the user 47 a message indicating that the requested data or data are absent from the set 15.
  • the generation method according to the invention then makes it possible to generate the structured base 10 comprising a smaller number of data, each data item of the structured base 10 corresponding to a respective extraction rule.
  • the storage in the structured base 10 of second class identifier(s), extraction criterion(ies), first relation(s), second relation(s), third(s) relation(s) and fourth(s) relation(s) makes it possible to contextualize each extracted data and therefore a better use of the extracted data.
  • These elements are qualified as context element(s). Indeed, this allows a user to not only have access to the data, but also to the context in which they were extracted, and therefore to better understand the origin of each piece of data. This allows, among other things, a user 47 to detect a possible inconsistency in data extracted from a source database 20, which would be impossible, or at the very least more difficult, without said contextual elements.
  • the selection of extraction rules according to the required action chosen by the user 47 makes the extraction more selective, ensuring that the extracted data is useful for the understanding of the situation.
  • the class of unsuccessful request(s) makes it possible to distinguish among the missing data, in the structured base 10, those which are supposed to be irrelevant when establishing the rule(s) of extraction, of those which are absent from the base(s) of source(s) 20.
  • the optional steps of retrieval 180, determination 190 and communication 200 make it possible to communicate to the user 47 the data of the structured base 10 and, thanks to the class of unsuccessful request(s) and the step of association 170, to also inform it more quickly about any missing data from the set 15. Taking into account the absence of certain data(s) from the set 15 then leads to a better understanding from the user 47 of the data that he has at his disposal in the structured database 10.
  • this request is nevertheless preferably taken into account to query the set 15 , allows the user 47 not to be constrained by the only data considered relevant by the group of extraction rule(s).
  • the fact that in the event of reception of distinct data, in response to the same extraction law, the distinct extracted data are stored, during the storage step 160, in the same class of the structured base 10 , makes it possible to leave the validation of the data extracted to the user 47. This also makes it possible not to risk omitting the storage of relevant data in the structured base 10.
  • the method and the generation device 25 according to the invention make it possible to improve the extraction of data from the source database(s) 20, as well as the generation of the structured database 10 which optimizes the response times. to questions from the user 47.

Abstract

L'invention a pour objet un procédé de génération, à partir d'un ensemble (15) de base(s) de données (20), d'une base structurée de données (10) associée à une mission, le procédé comprenant les étapes suivantes: - acquisition (110) d'une liste d'action(s) requise(s) et d'un groupe de règle(s) d'extraction de données comportant une loi d'extraction chacune, - génération (120) d'une structure de la base structurée de données (10) comportant au moins une classe de requête(s) infructueuse(s), - envoi (140) de la loi d'extraction de règle(s) d'extraction, à l'ensemble (15) et réception de donnée(s) extraite(s) depuis l'ensemble (15), - rangement (160) de la ou chaque donnée extraite reçue dans une classe de la base structurée (10), et - pour chaque loi d'extraction envoyée, si aucune donnée extraite n'est reçue en réponse de la part de l'ensemble (15), association (170) de ladite loi à la classe de requête(s) infructueuse(s).

Description

TITRE : Procédé et dispositif électronique de génération d’une base structurée de données pertinentes pour la gestion d’une mission, programme d’ordinateur associé
La présente invention concerne un procédé de génération, à partir d’un ensemble de base(s) de données, d’une base structurée de données associée à une mission, le procédé étant mis en œuvre par un dispositif électronique de génération.
L’invention concerne également un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un tel procédé de génération.
L’invention concerne également un dispositif électronique de génération configuré pour générer, à partir d’un ensemble de base(s) de données, une base structurée de données associée à une mission.
L’invention s’applique au domaine de l’aide à la décision d’un utilisateur confronté à une situation critique lors d’une mission. Une situation critique est entendue ici au sens d’un évènement au cours de la mission, pour lequel une action est requise afin de ne pas mettre en péril la mission.
Dans le domaine aéronautique, une mission est par exemple le vol d’un aéronef pour le transport de passagers entre deux aéroports. Une situation critique serait alors à titre d’exemple : une panne d’un moteur de l’aéronef, un problème de santé d’un passager, ou de mauvaises conditions météorologiques sur le trajet de l’aéronef.
La performance de prise de décision d’un utilisateur dépend de sa capacité à évaluer la situation critique. D’après le document « Toward a theory of situation awareness in dynamic systems » de M.R. Ensley au volume 37 du journal Human Factors The Journal of the Human Factors and Ergonomics Society de 1995, une telle évaluation comprend trois étapes : perception des éléments de la situation, compréhension desdits éléments, et détermination d’une décision la plus appropriée parmi un ensemble de décision(s) possible(s).
L’étape de perception consiste à acquérir un ensemble d'éléments décrivant la situation. Cependant, l’environnement risque alors d’être surchargé par des éléments sans intérêt pour l’activité de l’opérateur. La pertinence d’une donnée est entendue ici au sens d’une caractéristique que possède la donnée à être appropriée, ou encore adaptée, pour la compréhension de la situation. Dans le contexte du document précité, les éléments sont entendus au sens de données pertinentes. L’étape de perception est alors essentielle car une erreur lors de cette étape se répercute sur les étapes de compréhension et de détermination, et plus particulièrement sur une sous-étape de projection des états futurs lors de l’étape de détermination. En particulier, l’absence de prise en compte de certaines données pertinentes conduit à une mauvaise compréhension de ces données, provoquant des décisions potentiellement inappropriées.
Ainsi, lors de la prise de décision face à une situation critique, l’utilisateur ou le système doit être en mesure d’analyser un ensemble de données dont seulement une partie est pertinente. Pour augmenter la probabilité que les données pertinentes soient accessibles, des bases de données ont été constituées regroupant des ensembles de données les plus exhaustifs possibles. A titre d’exemple, la base ICAO Meteorological Exchange Model regroupe des données météorologiques mondiales.
Lorsque la situation rencontrée ne requiert pas une prise de décision rapide, ou que l’utilisateur n’est pas contraint par le stress, la fatigue ou la distraction, il est envisageable pour l’utilisateur de consulter l’ensemble des données. L’utilisateur sélectionne alors les données pertinentes et en déduit la meilleure décision relative à ladite situation.
Néanmoins, face à une situation critique contrainte par le temps, ou que l’utilisateur est contraint par l’un des facteurs précités, il n’est plus envisageable pour l’utilisateur d’analyser l’ensemble des données sans ignorer ou oublier certaines données pourtant pertinentes.
Pour cela, certains procédés proposent d’extraire automatiquement une partie des données de base(s) de données, dite(s) source(s), selon des règles d’extraction préétablies. Les données extraites sont alors indexées dans une nouvelle base de données, dite cible, plus petite que la ou les bases de données sources. L’apport d’une structure à la base de données cible, organisant les données extraites, permet de représenter les liens entre les données extraites et de simplifier la compréhension de ces données.
De tels extractions et indexations sont proposés dans le document « A Method to Identify Relevant Information Sufficient to Answer Situation Dependent Queries » de S. Lu et M. M. Kokar décrivant un procédé de d’extraction automatique d’un ensemble de données d’une base de données source. Le procédé comprend également la création d’une base de données cible et le stockage des données extraites dans cette base. Le choix des données extraites de la base de données source est fonction de la situation rencontrée, et est par exemple déterminé par une analyse basée sur une théorie dite de situation.
Le procédé d’extraction et de classification présenté permet de constituer une base de données cible comprenant une plus faible quantité de données que la base de données source. De plus, chaque donnée de la base de données source, considérée comme pertinente vis-à-vis de la théorie de la situation, est bien présente dans la base de données cible. Ainsi la base de données cible est plus facilement traitable, par un utilisateur, pour la compréhension de la situation et la prise de décision
Néanmoins, le procédé d’extraction et de génération de Lu et Kokar ne permet pas de générer une base de données cible de manière optimale.
Un but de l’invention est alors d’améliorer l’extraction de données et la génération de la base de données cible.
A cet effet, l’invention a pour objet un procédé de génération à partir d’un ensemble de base(s) de données, d’une base structurée de données associée à une mission, le procédé étant mis en œuvre par un dispositif électronique de génération et comprenant les étapes suivantes :
- acquisition d’une liste d’action(s) requise(s) au cours de la mission, et d’un groupe de règle(s) d’extraction de données de l’ensemble de base(s) de données, chaque règle d’extraction comportant un premier identifiant d’une classe de la base structurée de donnée et une loi d’extraction de donnée(s) à partir de la ou des bases de données, chaque règle étant associée à une ou plusieurs action(s) requise(s),
- génération d’une structure de la base structurée de données comportant au moins une classe pour chaque premier identifiant de classe distincte, et une classe de requête(s) infructueuse(s),
- sélection de règle(s) d’extraction parmi le groupe de règle(s) d’extraction acquis, en fonction d’une action requise choisie par un utilisateur parmi la liste d’action(s) requise(s),
- envoi de la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à l’ensemble de base(s) de données, et réception de donnée(s) extraite(s) de la part des bases de données suite à cet envoi,
- rangement de la ou chaque donnée extraite reçue dans la classe de la base structurée correspondant au premier identifiant de classe associé à la loi d’extraction en réponse à laquelle ladite donnée a été reçue, et
- pour chaque loi d’extraction envoyée, si aucune donnée extraite n’est reçue en réponse de la part de l’ensemble de base(s) de données, association de ladite loi à la classe de requête(s) infructueuse(s).
Ainsi, le procédé selon l’invention permet de générer une base structurée de données comprenant les données extraites d’un ensemble de base(s) de données, également appelée(s) base(s) source(s). En outre, le choix d’une action requise par un utilisateur et la sélection de règle(s) d’extraction, basée sur ce choix, permet de réaliser un nombre réduit d’extraction(s) tout en permettant que chaque donnée extraite soit appropriée dans le contexte de l’action requise choisie.
De plus, la présence dans chaque règle d’extraction d’un premier identifiant de classe permet d’organiser la base structurée de données indépendamment de la structure de la ou chaque base source.
De plus, l’étape d’association de la loi d’extraction à la classe de requête(s) infructueuse(s) permet d’identifier l’absence, dans l’ensemble de base(s) source(s), de données répondant à une loi d’extraction envoyée, ce qui permet alors à l’utilisateur de la base structurée de différencier les données absentes de l’ensemble de base(s) source(s) mais considérées comme pertinentes et cherchées par une loi d’extraction, des données absentes de la base structurée car considérées comme non-pertinentes et pour lesquelles aucune loi d’extraction n’a essayé de les extraire.
Suivant d’autres aspect avantageux de l’invention, le procédé selon l’invention comprend une ou plusieurs des caractéristiques suivantes prises isolément ou suivant toutes les combinaisons techniquement possibles :
- suite à l’envoi d’une loi d’extraction, aucune donnée extraite n’est reçue de l’ensemble des base(s) de données si le ou les messages reçus de l’ensemble de base(s) de données vérifient seulement au moins l’un des cas suivants :
- un message d’erreur est reçu de l’ensemble de base(s) de données,
- un message comportant un champ de données vide est reçu de la part de l’ensemble de base(s) de données.
- l’ensemble de base(s) de données comprend au moins deux bases de données, et lors de l’étape d’envoi, la loi d’extraction incluse dans chaque règle d’extraction sélectionnée est envoyée à chaque base de données,
- si les bases de données fournissent au moins deux données extraites différentes en réponse à une même loi d’extraction envoyée, les au moins deux données extraites sont, lors de l’étape de rangement, rangées dans la même classe de la base structurée, correspondant au premier identifiant de classe associé à ladite loi d’extraction,
- suite à l'envoi d’une loi d’extraction, chaque donnée reçue comprend :
- un jeu de donnée(s) extraite(s) d’une base de données (20), en réponse à la loi d’extraction envoyée,
- un ensemble de deuxième(s) identif iant(s) de classe de la base de données depuis laquelle jeu de donnée(s) extraite(s) est issu, chaque deuxième identifiant correspondant à une classe respective de ladite base de données depuis laquelle au moins une donnée extraite respective est issue, et
- un groupe de critère(s) d’extraction de données depuis la base de données dont le jeu de donnée(s) extraite(s) est issu, l’ensemble de deuxième(s) identifiant(s) et le groupe de critère(s) étant propre à chaque base de données et étant générés à partir de la loi d’extraction envoyée, lors de l’étape de rangement, l’ensemble de deuxième(s) identifiant(s), le groupe de critère(s) et le jeu de donnée(s) sont rangés dans la classe correspondant au premier identifiant de classe associé à ladite loi d’extraction, lors de l’étape de rangement, au moins une première relation entre une donnée extraite et un deuxième identifiant de classe est en outre rangé dans ladite classe de la base structurée,
- la mission est le vol d’un aéronef, l’ensemble d’action(s) requise(s) comprenant de préférence : un démarrage de l’aéronef, un déroutement de l’aéronef et un contournement par l’aéronef d’une zone géographique,
- les règles d’extraction associées à l’action requise de déroutement comprennent les lois d’extraction :
- trouver un aéroport dont la longueur de la piste est supérieure à une longueur prédéfinie,
- trouver un aéroport dont les conditions météorologiques correspondent à des conditions prédéfinies,
- trouver un aéroport possédant des services d’urgence, et
- trouver un aéroport distant de l’aéronef d’au plus une distance maximale prédéfinie Dlmax, et dans lequel les règles d’extraction associées à l’action requise de contournement comprennent les lois d’extraction :
- trouver des coordonnées de point(s) de passage de l’aéronef pour le(s)quel(s) les conditions météorologiques correspondent à des conditions prédéfinies, et distant de l’aéronef d’au plus une deuxième distance maximale prédéfinie D2max.
- lors de l’étape d’acquisition, des données invariantes au cours de la mission sont en outre acquises, et lors de l’étape d’envoi, au moins une loi d’extraction envoyée est complétée par au moins une donnée invariante au cours de la mission, si la mission est les vol d’un aéronef, les données invariantes au cours de la mission comprenant de préférence un type ou une référence de modèle de l’aéronef, un numéro de vol d’un aéronef, un aéroport de départ de l’aéronef, une quantité initiale de carburant dans l’aéronef,
- le procédé comprend en outre, après l’étape de rangement ou d’association :
- une étape de récupération d’une demande de la part d’un utilisateur, et
- si la demande concerne une loi d’extraction associée à la classe de requête(s) infructueuse(s), une étape de communication d’un message indiquant que la donnée répondant à la demande est absente de l’ensemble de base(s) de données à l’utilisateur.
En complément facultatif, chaque loi d’extraction comporte un ensemble de mot(s)-clé(s) apte(s) à être traduit(s) en deuxième(s) identif iant(s) de classe de chaque base de données lors de l’envoi de ladite loi, si au moins deux deuxièmes identifiants, associés à un même mot-clé d’une loi d’extraction, sont reçus alors lors de l’étape de rangement, une deuxième relation est rangée dans la base structurée de données.
En complément facultatif encore, lors de l’étape d’association, chaque loi d’extraction envoyée pour laquelle aucune donnée extraite n’est reçue, est qualifiée d’infructueuse, et chaque loi infructueuse est associée à la classe de requête(s) infructueuse(s) selon l’une des deux conditions suivantes :
- si à chaque mot-clé de la loi infructueuse, est associé un deuxième identifiant, alors rangement dans la classe de requête(s) infructueuse(s) de : o chaque deuxième identifiant absent de la base structurée de données, o chaque critère d’extraction absent de la base structurée de données, et o au moins une troisième relation liant un deuxième identifiant respectif à un critère d’extraction respectif, ou deux desdits deuxièmes identifiants si la loi comprend au moins deux mots-clés, si au moins un mot-clé de la loi infructueuse n’est pas associé à un deuxième identifiant, alors rangement dans la classe de requête(s) infructueuse(s) de : o chaque deuxième identifiant absent de la base structurée de données, o chaque mot-clé non-associé à un deuxième identifiant, o chaque critère d’extraction absent de la base structurée de données, dans chaque critère d’extraction relatif à un mot-clé sans deuxième identifiant, le deuxième identifiant étant remplacé par le mot-clé, et o au moins une quatrième relation liant un mot-clé à un critère d’extraction respectif ou à un deuxième identifiant respectif si la loi comprend deux mots-clés. L’invention a également pour objet un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon l’une quelconque des revendications précédentes.
L’invention a également pour objet un dispositif électronique de génération configuré pour générer, à partir d’un ensemble de base(s) de données, une base structurée de données associée à une mission, le dispositif étant apte à être relié à un ensemble de base(s) de données, le dispositif électronique de génération comprenant :
- un module d’acquisition configuré pour acquérir une liste d’action(s) requise(s) au cours de la mission, et un groupe de règle(s) d’extraction de données de l’ensemble de base(s) de données, chaque règle d’extraction comportant un premier identifiant d’une classe de la base structurée de donnée et une loi d’extraction de donnée(s) à partir de la ou des bases de données, chaque règle étant associée à une ou plusieurs action(s) requise(s),
- un module de génération configuré pour générer une structure de la base structurée de données comportant au moins une classe pour chaque premier identifiant de classe distincte, et une classe de requête(s) infructueuse(s),
- un module de sélection configuré pour sélectionner une ou plusieurs règles d’extraction parmi le groupe de règle(s) d’extraction acquis, en fonction d’une action requise choisie par un utilisateur parmi la liste d’action(s) requise(s),
- un module d’envoi configuré pour envoyer la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à l’ensemble de base(s) de données, et un module de réception de donnée(s) de la part des bases de données suite à cet envoi,
- un module de rangement configuré pour ranger la ou chaque donnée reçue dans la classe de la base structurée (correspondant au premier identifiant de classe associé à la loi d’extraction en réponse à laquelle ladite donnée a été reçue, et
- un module d’association configuré pour associer chaque loi d’extraction envoyée, pour laquelle aucune donnée extraite n’est reçue en réponse de la part de l’ensemble de base(s) de données, à la classe de requête(s) infructueuse(s).
Ces caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels :
[Fig 1] la figure 1 est une représentation schématique d’un système de génération d’une base structurée de données selon l’invention, le système comprenant un ensemble de base(s) de données et un dispositif électronique de génération, à partir de l’ensemble de base(s) de données, d’une base structurée de données ; [Fig 2] la figure 2 est un organigramme d’un procédé, selon l’invention, de génération d’une base structurée de données selon l’invention, le procédé étant mis en œuvre par le dispositif électronique de génération de la figure 1 ; et
[Fig 3] la figure 3 est une représentation schématique d’une base structurée de données, générée selon le procédé de génération représenté sur la figure 2.
Sur la figure 1 , un système 5 de génération d’une base structurée 10 de données comprend un ensemble 15 de base(s) de données 20 et un dispositif électronique 25 de génération de la base structurée 10. Le dispositif de génération 25 est connecté à l’ensemble 15. Le système de génération 5 est typiquement configuré pour générer une base structurée 10 respective par mission. La mission est par exemple le vol d’un aéronef pour le transport de passager(s).
La base structurée de données 10 est par exemple une base de connaissances. La dénomination “base de connaissances” est entendue ici au sens d’une base structurée de données, comportant en outre des éléments de liaison, nommés ci-après relations, permettant d’établir de liens sémantiques entre les données de la base, tel que défini dans le chapitre “Knowledge Bases vs Databases" du livre ‘On Knowledge Base Management Systems’, publié en 1986, et écrit par Michael L. Brodie et John Mylopoulos.
L’ensemble 15 comprend au moins une base de données 20, chaque base de données 20 étant également appelée base source 20 par la suite, et au moins un traducteur 30 propre à chaque base source 20.
L’ensemble 15 est susceptible d’évoluer dynamiquement au cours du procédé. Ainsi, la présence de chaque base source 20 n’est pas préalablement déterminée. La présence en continu d’au moins une base source 20 et du traducteur 30 associé, est l’unique contrainte, ou exigence, associée à l’ensemble 15.
Le dispositif de génération 25 est configuré pour générer la base structurée 10 à partir dudit ensemble 15.
Le dispositif de génération 25 comprend un module d’acquisition 35 configuré pour acquérir au moins une liste d’action(s) requise(s) au cours de la mission et un groupe de règle(s) d’extraction, chacune comportant une loi d’extraction. Le dispositif de génération 25 comprend un module de génération 40 configuré pour générer une structure de la base structurée 10.
Le dispositif de génération 25 comprend également un module de sélection 45 configuré pour sélectionner une ou plusieurs règle(s) d’extraction parmi le groupe de règle(s) d’extraction à partir d’une action requise choisie par un utilisateur 47, un module d’envoi 50 configuré pour envoyer, à l’ensemble 15, la loi d’extraction incluse dans chaque règle d’extraction sélectionnée.
Le dispositif de génération 25 comprend également un module de rangement 55 configuré pour ranger une ou des données reçues en réponse à la ou aux lois d’extraction envoyées, dans la classe de la base structurée 10 correspondant à un premier identifiant de classe de la règle d’extraction, la règle d’extraction comprenant la loi d’extraction ayant produit la ou les données.
Le rangement de chaque donnée dans la classe respective est compris ici comme synonyme d’une indexation, ou encore d’un classement, de ladite donnée dans ladite classe.
Le dispositif de génération 25 comprend un module d’association 60 configuré pour associer chaque loi d’extraction envoyée, à une classe de requête(s) infructueuse(s) en l’absence de réponse à ladite loi, de la part de l’ensemble 15.
En complément facultatif, le dispositif de génération 25 comprend un module récupération 65 configuré pour récupérer une demande de donnée(s) de la part de l’utilisateur 47, un module de détermination 70 configuré pour déterminer si chaque donnée demandée est présente ou non dans la base structurée 10, et un module de communication 75 configuré pour communiquer un message à partir ce qui est déterminé par le module de détermination 70.
Dans l’exemple de la figure 1 , le dispositif de génération 25 comprend une unité de traitement d’informations 80 formée par exemple d’une mémoire 85 et d’un processeur 90 associé à la mémoire 85.
Dans cet exemple de la figure 1 , le module d’acquisition 35, le module de génération 40, le module de sélection 45, le module d’envoi 50, le module de rangement 55, le module d’association 60, ainsi qu’en complément facultatif le module de récupération 65, le module de détermination 70 et le module de communication 75, sont réalisés chacun sous forme d’un logiciel, ou d’une brique logicielle, et exécutables par le processeur 90. La mémoire 85 du dispositif de génération 25 est alors apte à stocker un logiciel d’acquisition de la liste d’action(s) requise(s) et du groupe de règle(s) d’extraction, un logiciel de génération d’une structure de la base structurée 10, un logiciel de sélection de règle(s) d’extraction à partir de l’action requise choisie par l’utilisateur 47, un logiciel d’envoi de la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, un logiciel de rangement dans la base structurée 10 de la ou chaque donnée extraite reçue, dans la classe correspondant au premier identifiant associé à la loi d’extraction en réponse à laquelle chaque donnée a été reçue, et un logiciel d’association, en l’absence de donnée(s) extraite(s) reçue(s) en réponse à une loi respective d’extraction envoyée, de ladite loi d’extraction à la classe de requête(s) infructueuse(s) de la base structurée 10. En complément facultatif, la mémoire 85 du dispositif de génération 25 comprend un logiciel de récupération de la demande de donnée(s) de la part de l’utilisateur 47, un logiciel de détermination de la présence ou non dans la base structurée 10 de chaque donnée demandée, et un logiciel de communication du message à partir de ce qui est déterminé par le logiciel de détermination.
Sur la figure 1 , les briques logicielles sont reliées par des flèches représentant chacune typiquement un appel de fonction.
En variante non représentée, le module d’acquisition 35, le module de génération 40, le module de sélection 45, le module d’envoi 50, le module de rangement 55, le module d’association 60, ainsi qu’en complément facultatif le module de récupération 65, le module de détermination 70 et le module de communication 75, sont réalisés chacun sous forme d’un composant logique programmable, tel qu’un FPGA (de l’anglais Field Programmable Gate Array), ou encore d’un circuit intégré, tel qu’un ASIC (de l’anglais Application Specific Integrated Circuit).
Lorsque le dispositif de génération 25 est réalisé sous forme d’un ou plusieurs logiciel(s), c’est-à-dire sous forme d’un programme d’ordinateur, il est en outre apte à être enregistré sur un support, non représenté, lisible par ordinateur. Le support lisible par ordinateur est par exemple, un médium apte à mémoriser les instructions électroniques et à être couplé à un bus d’un système informatique. A titre d’exemple, le support lisible est un disque optique, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, tout type de mémoire non volatile (par exemple EPROM, EEPROM, FLASH, NVRAM), une carte magnétique ou une carte optique. Sur le support lisible est alors mémorisé un programme d’ordinateur comprenant des instructions logicielles.
Chaque règle d’extraction comprend une loi d’extraction et un premier identifiant de classe respectifs.
Chaque loi d’extraction comprend l’ensemble de mot(s)-clé(s), et au moins une spécificité précisant respectivement une caractéristique de chaque mot-clé ou une dépendance de plusieurs mots-clés le cas échéant. Chaque loi d’extraction est par exemple un élément textuel formant une phrase en langage naturel, chaque spécificité étant, le cas échéant, une expression textuelle liant sémantiquement les mots-clés. En variante, chaque loi d’extraction est sous forme d’un graphe dans lequel chaque mot-clé représente un nœud, et, chaque spécificité de dépendance étant représenté par un arc reliant deux nœuds dans le cas où le graphe comprend plusieurs nœuds.
Dans le cas où la loi d’extraction est un élément textuel formant une phrase en langage naturel, des techniques NLU (de l’anglais Natural Language Understanding) permettent d’identifier les mots clés. Ces techniques NLU sont des techniques d’intelligence artificielle, basées sur un modèle informatique de prédiction de mots-clés. Ces modèles sont entraînés à partir d’un ensemble de corpus de textes en entrée, pour lesquels un mot- clé attendu en sortie est fourni.
Chaque base source 20 comprend un ensemble de données, chacune apte à être extraite de la base source 20, suite à une requête dans un langage informatique interprétable par la base source 20.
Chaque base source 20 ayant sa propre structure et son propre langage, le traducteur 30 propre à chaque base source 20 est configuré pour traduire une loi respective d’extraction exprimée dans un langage dit naturel, en une requête respective exprimée dans le langage de la base source 20 ou dans un langage interprétable par la base source 20.
Un langage naturel est compris ici au sens d’un langage écrit ou parlé, qui n’est pas un langage informatique. Ainsi, les langues française, anglaise et allemande sont des exemples non exhaustifs de langages naturels.
Le langage informatique, dans lequel les lois d’extractions sont traduites en requêtes respectives est par exemple le langage dit SPARQL (de l’anglais « SPARQL Protocol And R DF Query Language »).
Chaque traducteur 30 est configuré pour générer, à partir de la loi d’extraction reçue, la requête comportant au moins un deuxième identifiant de classe et au moins un critère d’extraction.
Chaque deuxième identifiant de classe, aussi nommé argument, correspond à une classe respective de la base source 20, et permet alors d’identifier une telle classe. Dans chaque requête informatique en langage SPARQL, les deuxièmes identifiants de classe sont par exemple repérés par une première dénomination « SELECT » précédant le deuxième identifiant.
Chaque critère d’extraction, aussi nommé condition, correspond à une caractéristique discriminante portant sur les données de la classe identifiée par un deuxième identifiant respectif. Ainsi, seulement les données vérifiant chaque critère d’extraction sont extraites. Dans chaque requête SPARQL, chaque critère d’extraction est repéré par une deuxième dénomination « WHERE » précédant ledit critère.
Autrement dit, chaque requête SPARQL est apte à extraire, de la base source 20, les données correspondant à chaque deuxième identifiant de classe repéré par la première dénomination « SELECT » et vérifiant chaque critère d’extraction, chaque critère d’extraction portant sur au moins un deuxième identifiant de classe. Une spécificité du langage SPARQL est qu’il n’est pas nécessaire d’introduire préalablement à la deuxième dénomination « WHERE », chaque deuxième identifiant de classe sur lequel s’applique un critère d’extraction respectif.
A titre d’exemple le traducteur 30 est du type SPARQL, propre à une base source 20 respective comportant les classes « aérodrome » et « piste d’atterrissage », et est configuré pour traduire la loi d’extraction « Trouver un aéroport dont la longueur de la piste est supérieure à 1 ,2 km » en une requête SPARQL respective comportant le deuxième identifiant de classe « aérodrome » sous la forme « SELECT aérodrome », et comportant le critère d’extraction sous la forme « WHERE {piste d’atterrissage > 1 ,2 km} ». Seulement la ou les données, correspondant à la classe identifiée par le deuxième identifiant « aérodrome » et pour lesquelles la classe, identifiée par le deuxième identifiant « piste d’atterrissage », comporte des pistes supérieures à 1 ,2 km, sont extraites par la requête SPARQL.
Le traducteur 30 est connu en soi, le projet SWIP proposant notamment un tel traducteur 30. Le traducteur 30 du projet SWIP est apte à traduire une loi respective d’extraction exprimée en langage naturel, en une requête respective SPARQL, à travers un processus de Traitements Automatique du Langage naturel dit « TAL ».
En outre, d’autres langages informatiques que le langage SPARQL, tels que le « SPARQL-DL », le « Snap SPARQL », le « OWL-QL », le « SQWRL », ou encore le « DL- Query », sont également adaptés pour l’extraction de données.
Selon l’exemple précité dans lequel la mission est le vol d’un aéronef, l’ensemble 15 comprend par exemple au moins l’une des bases sources 20 suivantes :
- « ATM Information Reference Model Ontology » (dite AIRM-O) pour le trafic aérien,
- « Aeronautical Information exchange Model » (dite AIXM) pour la gestion et la distribution de données de services d'informations aéronautiques, ou
- « ICAO Meteorologial Information Exchange Model » (dite IWXXM) pour les données météorologiques.
Le module d’acquisition 35 est configuré pour acquérir la liste d’action(s) requise(s) au cours de la mission. Chaque action requise désigne une intention de l’utilisateur 47 au cours de la mission. Cette intention est dite de haut niveau, en opposition à une décision prise par l’utilisateur 47 après consultation des données pertinentes. Ainsi, les données pertinentes pour prendre la décision dépendent, au moins en partie, de l’action requise choisie, c’est-à-dire de l’intention choisie.
Dans l’exemple précité où la mission est le vol de l’aéronef, la liste d’action(s) requise(s) comprend par exemple : un démarrage de l’aéronef, un déroutement de l’aéronef et un contournement par l’aéronef d’une zone géographique. Le module d’acquisition 35 est également configuré pour acquérir le groupe de règle(s) d’extraction. Chaque règle d’extraction est associée à l’action requise de la liste d’action(s) requise(s). Ainsi chaque action requise permet de réaliser un filtrage sur les données qui seront extraites par la loi d’extraction incluse dans chaque règle d’extraction associée à ladite action.
Dans l’exemple précité où la mission est le vol d’un aéronef, et avec l’exemple précité de liste d’action(s) requise(s), le groupe de règle(s) d’extraction comporte typiquement les règles d’extraction associées à l’action de déroutement de l’aéronef, dont la loi d’extraction de chacune est par exemple la suivante :
- trouver un aéroport dont la longueur de la piste est supérieure à une longueur prédéfinie, trouver un aéroport possédant des services d’urgence, et trouver un aéroport distant de l’aéronef d’au plus une première distance maximale prédéfinie Dlmax.
Dans le cas de la première loi d’extraction citée ci-dessus, les mots-clés sont par exemple, « aéroport » et « piste ».
Dans cet exemple, la liste de règle(s) d’extraction comporte typiquement les règles d’extraction, associées à l’action de contournement par l’aéronef d’une zone géographique, dont la loi d’extraction de chacune est par exemple la suivante : trouver les coordonnées de point(s) de passage de l’aéronef pour le(s)quel(s) les conditions météorologiques correspondent à des conditions prédéfinies, et distant de l’aéronef d’au plus une deuxième distance maximale prédéfinie D2max, et trouver les coordonnées de point(s) de passage de l’aéronef pour le(s)quel(s) une couverture internet d’une technologie satellite.
En variante, la mission est le suivi de patients dans un hôpital. Une action requise respective est alors par exemple de détecter des patients à risque de COVID-19 dans un service d’urgence. Les règles d’extraction sont alors, par exemple, les suivantes : sélectionner tous les patients du service d’urgence n’ayant pas été diagnostiqués porteurs du COVID-19 et âgés de plus de 60 ans, sélectionner les patients du service d’urgence n’ayant pas été diagnostiqués porteurs du COVID-19 et ayant des risques cardio-vasculaires, sélectionner les patients du service d’urgence n’ayant pas été diagnostiqués porteurs du COVID-19 et ayant partagé une chambre avec un patient porteur du COVID-19, sélectionner des patients de l’hôpital dont l’âge est dans un tranche d’âges prédéfinie, telle qu’entre 30 et 50 ans. En variante encore, la mission est le contrôle d’un incendie. L’action requise est alors de déterminer des moyens adaptés pour la gestion de cet incendie. Les règles d’extraction sont alors par exemple : déterminer les véhicules de secours possédant les services d’extinction d’incendie, déterminer les véhicules de secours équipés a minima d’un conducteur, d’un chef agréé et de quatre équipiers, et déterminer les véhicules de secours présents dans la zone de l’accident.
En variante encore, la mission est la gestion des accidents par un service de SAMU. Une action requise respective est alors la recherche d’hôpitaux pour prendre en charge une victime, suite à un accident. Une règle d’extraction est alors de déterminer les hôpitaux possédant un service adapté à une pathologie d’une victime à prendre en charge.
Le premier identifiant de classe inclus dans chaque règle d’extraction correspond à la classe de la base structurée 10 dans laquelle doit être rangée chaque donnée extraite à l’issue de l’envoi de la loi d’extraction respective. Des explications plus détaillées concernant les classes de la base structurée 10 sont fournies ci-après.
Le module d’acquisition 35 est aussi optionnellement configuré pour acquérir un ensemble de donnée(s) invariante(s) au cours de la mission. L’ensemble de donnée(s) invariante(s) comprend, le cas échéant, des données n’évoluant pas au cours de la mission et connues préalablement à la mission, ainsi que le premier identifiant de classe associé à chacune desdites données pour le rangement de ladite donnée dans la base structurée 10. L’ensemble de donnée(s) invariante(s) comprend également des données absentes de l’ensemble 15 permettant de compléter les lois d’extractions.
Dans l’exemple précité où la mission est le vol d’un aéronef, les données invariantes comprennent par exemple : un type ou une référence de l’aéronef, une quantité initiale de carburant dans l’aéronef, un numéro de vol de la mission et un aéroport de départ de l’aéronef.
Le module de génération 40 est connecté en sortie du module d’acquisition 35, et est configuré pour générer la structure de la base structurée 10. La structure de la base structurée 10 comporte des classes, et notamment une classe respective pour chaque premier identifiant de classe du groupe de règle(s) d’extraction.
De manière optionnelle, chaque premier identifiant de classe est choisi parmi les six noms de classe suivants : « sujet », « outil(s) », « communauté », « règle(s) » , « division du travail », « visée ». Cette décomposition en six classes est connue en soi, et provient de la théorie de l’activité proposée par Y. Engestrôm en 1987 dans le document « Learning by expanding: An activity-theoretical approach to developmental research, Helsinki: Orienta- Konsultit». Cette décomposition est une structure générique permettant de décrire de manière exhaustive un ensemble d’éléments nécessaires d’une activité tout en assurant une distinction objective entre les classes.
Si les classes sont les six classes liées à la théorie de l’activité, l’homme du métier observera que la classe « règle(s) » fait référence aux règles métier à appliquer pour la réalisation d’un objectif. Ces règles métier correspondent aux règles d’extraction.
Le module de génération 40 est également configuré pour générer la classe de requête(s) infructueuse(s) dans la base structurée 10.
Le module de sélection 45 est connecté en sortie du module d’acquisition 35, et est configuré pour sélectionner au moins une règle d’extraction respective d’extraction parmi celle(s) du groupe de règle(s) d’extraction.
En fonction de l’action requise choisie par l’utilisateur 47 parmi la liste d’action(s) requise(s), le module de sélection 45 est configuré pour sélectionner, dans le groupe de règle(s) d’extraction, chaque règle associée à ladite action choisie.
Si l’action requise choisie est le déroutement de l’aéronef, le module de sélection 45 est configuré pour choisir les règles d’extraction associées à l’action de déroutement de l’aéronef, telles que celles décrites précédemment. Corollairement, si l’action requise choisie est le contournement de l’aéronef, le module de sélection 45 est configuré pour choisir les règles d’extraction qui sont associées à cette action requise.
Le module d’envoi 50 est connecté en sortie du module de sélection, et est configuré pour envoyer, à l’ensemble 15, la loi d’extraction de chaque règle d’extraction sélectionnée.
Dans le cas où l’ensemble 15 comprend plusieurs bases sources 20, le module d’envoi 50 est configuré pour envoyer la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à chaque base source 20, via le traducteur 30 propre à ladite base source 20.
Le module d’envoi 50 est optionnellement configuré pour compléter avant l’envoi, et le cas échéant, une loi respective d’extraction à partir des données déjà rangées dans la base structurée 10.
Par exemple, pour la loi d’extraction exprimée sous la forme de l’expression textuelle « trouver un aéroport dont la longueur de la piste est supérieure à une longueur prédéfinie », la longueur prédéfinie est de préférence complétée automatiquement en fonction de la donnée invariante correspondant au type ou à la référence de modèle de l’aéronef.
Le module de rangement 55 est connecté en sortie du module de sélection 45, et est configuré pour recevoir et ranger, dans la base structurée 10, un ou des éléments du ou des messages reçus en réponse à la ou aux lois d’extraction envoyées à l’ensemble 15. Chaque message reçu comprend par exemple les éléments suivants : un jeu de donnée(s) extraite(s), un ensemble de deuxième(s) identifiant(s) de classe, et un groupe de critère(s) d’extraction.
Chaque message reçu comprend plus précisément un champ de données comportant deux tableaux. Un premier tableau comprend le jeu de données extraites. Un deuxième tableau comprend la requête en langage SPARQL ayant permis d’extraire le jeu de données extraites. L’ensemble de deuxième(s) identifiant(s) de classe et le groupe de critère(s) d’extraction sont alors inclus dans le deuxième tableau.
Le module de rangement 55 est configuré pour ranger chaque jeu de données extraites, chaque ensemble de deuxième(s) identifiant(s) et chaque groupe de critère(s) d’extraction dans la classe correspondant au premier identifiant associé à la loi d’extraction à l’origine des données reçues.
Chaque donnée extraite correspond à une donnée respective d’une base source 20 en réponse à la loi d’extraction envoyée.
En complément facultatif, le module de rangement 55 est configuré pour ranger, dans la base structurée 10, au moins une première relation entre une donnée extraite respective et un deuxième identifiant respectif, ou entre une donnée extraite et un critère d’extraction respectif. Le module de rangement 55 est préférentiellement configuré pour ranger, dans la classe appropriée, chaque première relation définissant un lien entre deux éléments rangés.
Chaque première relation est par exemple un élément textuel, aussi dit axiome ou triplet de données sémantique. Chaque première relation permet de définir le lien sémantique entre deux éléments rangés dans la base structurée 10. Chaque lien sémantique permet par exemple, de définir un lien d’appartenance, d’interdépendance, ou encore de hiérarchie entre deux éléments. Un tel lien de hiérarchie est assimilable à une notion de sous-classe. Ainsi, par exemple le lien sémantique entre une donnée extraite « Bordeaux » et un deuxième identifiant « aéroport », du type « Bordeaux est un aéroport » est équivalent au fait d’avoir dans la base structurée 10, la sous-classe « aéroport » comprise dans une des classes par exemple issues de la théorie de l’activité, et comprenant la donnée extraite « Bordeaux ». De tels liens sémantiques permettent alors de qualifier la base structurée 10 de base ontologiquement organisée, car elle comprend, outre des données, des liens sémantiques entre ses données. Un tel formalisme de base ontologiquement organisé est dit du type OWL (de l’anglais Ontology Web Language ou l/l/eb Ontology Language).
Les précisions ci-dessus concernant chaque première relation sont également applicables à chaque deuxième, troisième et quatrième relations définies ci-après. Chaque première relation se déduit de la loi d’extraction incluse dans la règle d’extraction à laquelle elle est relative, et notamment des spécificités de dépendance entre chaque mot-clé dans ladite loi.
En complément facultatif, le module de rangement 55 est configuré pour, en cas de réception de plusieurs données extraites suite à l’envoi d’une loi respective d’extraction, ranger chaque donnée extraite reçue dans la base structurée 10. Ainsi, dans le cas où l’ensemble 15 comprend au moins deux bases sources 20, si des données extraites sont reçues de plusieurs bases sources 20, chaque donnée extraite est rangée dans la classe correspondant au premier identifiant associé à la loi d’extraction à l’origine des données extraites reçues.
En complément facultatif encore, le module de rangement 55 est configuré pour, si au moins deux deuxièmes identifiants reçus sont associés à un même mot-clé respectif de la loi d’extraction, ranger une deuxième relation dans la base structurée 10. La deuxième relation indique alors par exemple que les deux deuxièmes identifiants sont synonymes.
En complément facultatif, le module de rangement 55 est également configuré pour ranger les données invariantes au cours de la mission dans les classes associées au premier identifiant de chacune, si l’ensemble de données invariantes a été acquis.
En complément facultatif encore, le module de rangement 55 est également configuré pour ranger le groupe de règle(s) d’extraction dans la classe « règle(s) », si la base structurée 10 comprend une telle classe. Le module d’association 60 est connecté en sortie du module de sélection 45 et en sortie de l’ensemble 15 de base(s) source(s) 20. Le module d’association 60 est configuré pour associer chaque loi d’extraction, pour laquelle aucune donnée extraite n’est reçue, à la classe de requête(s) infructueuse(s).
Le module d’association 60 est optionnellement configuré pour déterminer qu’aucune donnée extraite n’est reçue suite à l’envoi d’une loi respective d’extraction si le ou les messages reçus de l’ensemble 15 vérifient seulement au moins l’un des cas suivants : un message d’erreur est reçu de l’ensemble 15,
- un message comportant un champ de données vide est reçu de la part de l’ensemble 15.
Le module d’association 60 est configuré pour recevoir les requêtes en langage SPARQL en sortie de chaque traducteur 30.
Ainsi le module d’association 60 est configuré pour recevoir de la part de l’ensemble 15, pour chaque base source 20 et pour chaque loi d’extraction envoyée, l’ensemble de deuxième(s) identifiant(s) de classe, et le groupe de critère(s) d’extraction.
L’ensemble de deuxième(s) identifiant(s) de classe et le groupe de critère(s) d’extraction sont obtenus par le traducteur 30 propre à chaque base source 20. En l’absence de réception de données extraites suite à la ou chaque loi d’extraction envoyée, le module d’association 60 est optionnellement configuré pour qualifier d’infructueuse la loi envoyée. Le module d’association 60 est alors de préférence configuré pour associer chaque loi infructueuse à la classe de requête(s) infructueuse(s) en rangeant dans ladite classe, l’ensemble de deuxième(s) identifiant(s) et le groupe de critère(s) d’extraction associés à ladite loi.
Une loi d’extraction sans réponse d’un jeu de donnée(s) extraite(s), c’est-à-dire pour laquelle le premier tableau du message reçu est vide, est considérée comme infructueuse. Ce mécanisme fait référence à une absence des donnée(s) cherchée(s) dans l’ensemble 15 de base(s) source(s) 20. Ces données sont également nommées données manquantes.
Plus spécifiquement, pour chaque loi infructueuse, le module d’association 60 est optionnellement configuré pour ranger, dans la classe de requête(s) infructueuse(s): chaque deuxième identifiant absent de la base structurée 10, chaque critère d’extraction, et au moins une troisième relation liant un deuxième identifiant respectif et un critère d’extraction respectif de la loi infructueuse. Le module d’association 60 est préférentiellement configuré pour ranger, pour chaque loi infructueuse, chaque troisième relation liant deux éléments rangés par ledit module 60 et chaque troisième relation liant un deuxième identifiant respectif déjà présent dans la base structurée 10 à un autre élément respectif rangé par ledit module 60.
En complément facultatif, le module d’association 60 est optionnellement configuré pour, en cas de qualification d’une loi d’extraction comme infructueuse, distinguer la configuration concernée parmi des première et deuxième configurations possibles.
Dans la première configuration, aucune donnée extraite n’est reçue car aucune donnée ne vérifie le groupe de critère(s) d’extraction. Le module d’association 60 est configuré pour effectuer dans ce cas le rangement comme décrit ci-dessus.
Dans la deuxième configuration, aucune donnée n’est reçue car aucune base source 20 ne comporte l’ensemble de classe(s) correspondant à l’ensemble de mot(s) clé(s) de la loi d’extraction qualifiée d’infructueuse. Autrement dit, le traducteur 30 de chaque base source 20 n’a pas réussi à traduire chaque mot-clé de la loi d’extraction en un deuxième identifiant de classe de la base source 20 à laquelle il est associé. Le module d’association 60 est dans ce cas, configuré pour, ranger dans la classe de requête(s) infructueuse(s), chaque deuxième identifiant absent de la base structurée 10, chaque mot-clé de la loi infructueuse n’ayant pas de deuxième identifiant associé, chaque critère d’extraction et au moins une quatrième relation liant ledit ou un desdits mots-clés à un deuxième identifiant de la loi infructueuse. Pour chaque critère(s) d’extraction spécifiant une caractéristique d’un mot-clé non-traduit en deuxième identifiant, le deuxième identifiant est remplacé par ledit mot-clé. Le module d’association 60 est préférentiellement configuré pour ranger, pour chaque loi d’extraction infructueuse, toutes les quatrièmes relations existantes entre chaque deuxième identifiant, chaque mot-clé, et chaque critère d’extraction, pris deux à deux.
Le module de récupération 65 est configuré pour récupérer une demande de données de l’utilisateur 47. Le module de récupération 65 est par exemple configuré pour récupérer la demande sous forme textuelle.
Le module de communication 75 est connecté en sortie du module de détermination 70 et est configuré pour communiquer le message à partir de ce qui a été déterminé par le module de détermination 70, à l’utilisateur 47 ou à un dispositif électronique de traitement, non représenté.
Pour cela, le module de communication est par exemple un assistant virtuel comprenant un dialogueur (de l’anglais chatbot) interagissant avec l’utilisateur 47 au travers de moyens de communication tel qu’un écran d’affichage, un système audio comprenant un microphone et/ou un haut-parleur, un capteur et/ou actionneur haptique, ou toute combinaison possible des moyens de communication précités.
Le module de communication 75 est configuré pour communiquer chaque donnée demandée présente dans la base structurée 10 à l’utilisateur 47 ou au dispositif électronique de traitement. Le module de communication 75 est également configuré pour, si la demande concerne un deuxième identifiant de classe respectif, ou le cas échéant, un mot-clé respectif de la classe de requête infructueuse, communiquer un message indiquant que la ou les données demandées concernent une ou des données absentes de l’ensemble 15 de base(s) source(s) 20 à l’utilisateur 47 ou au dispositif électronique de traitement.
En complément facultatif, le module de communication 75 est également configuré pour, si la ou les données demandées sont absentes de la base structurée 10 et ne concernent pas un deuxième identifiant respectif ou un mot-clé respectif de la classe de requête(s) infructueuse(s), communiquer un message respectif indiquant que la ou les données demandées n’ont pas encore été recherchées, à l’utilisateur 47 ou au dispositif électronique de traitement. Le module de communication 75 est dans ce cas, typiquement configuré en outre pour envoyer la demande à l’ensemble 15 en tant que loi d’extraction afin d’essayer d’obtenir la ou les données demandées.
Ainsi, chaque action requise correspond à l’intention de l’utilisateur 47 au cours de la mission pour laquelle des données sont extraites afin de l’aider à prendre une décision.
Chaque règle d’extraction est associée à l’action requise, et comprend la loi d’extraction propre à être envoyée à l’ensemble 15, ainsi que le premier identifiant de classe. Chaque loi d’extraction comprend l’ensemble de mot(s)-clé(s) et au moins la spécificité précisant la caractéristique dudit mot-clé, ou le cas échéant, la dépendance entre deux mots-clés.
Le premier identifiant de classe correspond à la classe de la base structurée 10 dans laquelle sont rangées les données issues de l’ensemble 15, suite à l’envoi de la loi d’extraction.
Les données invariantes comportent des données n’évoluant pas au cours de la mission et le premier identifiant de classe, propre à chaque donnée, indiquant la classe de la base structurée 10 dans laquelle ladite donnée doit être rangée.
Chaque classe est l’élément de la structure de la base structurée 10 correspondant au premier identifiant de classe inclus dans la règle d’extraction.
La base structurée 10 comprend également la classe de requête(s) infructueuse(s).
Chaque requête correspond à la traduction par le traducteur 30 de la loi d’extraction. Chaque requête comprend l’ensemble de deuxième(s) identif iant(s) respectif et le groupe de critère(s) respectif d’extraction.
Chaque deuxième identifiant de classe correspond à la traduction, par le traducteur 30, d’un mot-clé respectif de la loi d’extraction. Chaque deuxième identifiant de classe identifie la classe respective de la base source 20 à laquelle le traducteur 30 est associé.
Chaque critère d’extraction correspond à la traduction par le traducteur 30, de la spécificité en la condition pour l’extraction la donnée de la base source 20 à laquelle le traducteur 30 est associé.
Chaque message reçu de l’ensemble 15 comprend l’ensemble de deuxième(s) identifiant(s) de classe, le groupe de critère d’extraction, et le cas échéant, le jeu de donnée(s) extraite(s).
Chaque donnée extraite est la donnée de la base source 20 respective extraite par la requête.
Chaque première relation correspond au lien, rangé dans la base structurée 10, entre la donnée extraite et le deuxième identifiant de classe de la requête associée, ou entre la donnée extraite et le critère d’extraction de ladite requête, ou entre le deuxième identifiant et le critère d’extraction, ou encore le cas échéant entre deux deuxièmes identifiants.
Chaque deuxième relation correspond au lien, rangé dans la base structurée 10, entre deux deuxièmes identifiants de classe spécifiant qu’ils sont synonymes, dans le cas où les deux deuxièmes identifiants sont associés à un même mot-clé respectif.
Chaque troisième relation correspond au lien, rangé dans la base structurée 10, entre le deuxième identifiant et le critère d’extraction respectifs de ladite requête, ou le cas échéant entre deux deuxièmes identifiants d’une requête respective, en l’absence de donnée extraite par ladite requête.
Chaque quatrième relation correspond au lien, rangé dans la base structurée 10, entre un deuxième identifiant respectif ou un mot-clé respectif, et un autre deuxième identifiant respectif ou un autre mot-clé respectif ou encore un critère d’extraction, chacun d’une même requête respective, en cas d’absence de traduction d’un mot-clé en un deuxième identifiant de classe respectif.
Le fonctionnement du système de génération 5, et en particulier du dispositif de génération 25 selon l’invention, va être à présent décrit en regard de la figure 2 représentant un organigramme du procédé, selon l’invention, de génération de la base structurée 10, le procédé étant mis en œuvre par le dispositif de génération 25.
Lors d’une étape d’acquisition 1 10, le dispositif de génération 25 acquiert la liste d’action(s) requise(s) au cours de la mission et le groupe de règle(s) d’extraction de données de l’ensemble 15, via son module d’acquisition 35. Chaque règle d’extraction est associée à une action requise respective.
Lors de l’étape d’acquisition 110, le dispositif de génération 25 acquiert optionnellement en outre l’ensemble de donnée(s) invariante(s) au cours de la mission.
Le dispositif de génération 25 passe ensuite à une étape de génération 120 dans laquelle il génère la structure de la base structurée 10, via son module de génération 40.
Lors de l’étape de génération 120, le dispositif de génération 25 range optionnellement l’ensemble de donnée(s) invariante(s) dans les classes de la base structurée 10, ainsi que le groupe de règle(s) d’extraction dans la classe « règle(s)» si une telle classe est présente.
Le dispositif de génération 25 passe ensuite à une étape de sélection 130 dans laquelle il sélectionne, suite au choix par l’utilisateur 47 de l’action requise parmi la liste d’action(s) requise(s), la ou les règles d’extraction associées à l’action requise choisie.
Le dispositif de génération 25 passe ensuite à une étape d’envoi 140 dans laquelle, il envoie via son module d’envoi 50, chaque loi d’extraction sélectionnée à l’ensemble 15. Dans le cas où l’ensemble 15 comporte plusieurs bases sources 20, le module d’envoi 50 envoie la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à chaque traducteur 30 de chaque base source 20.
En complément facultatif, lors de l’étape d’envoi 140, le dispositif de génération 25 complète les lois d’extraction à partir de données déjà rangées dans la base structurée 10.
Le dispositif de génération 25 passe ensuite à une première étape de détection 150, dans laquelle il reçoit, pour chaque loi d’extraction envoyée, un message de la part de l’ensemble 15, et détecte la présence ou non du jeu de donnée(s) extraite(s) dans le message reçu.
Pour chaque message reçu comprenant le jeu de donnée(s) extraite(s), le dispositif de génération 25 range, lors d’une étape de rangement 160 et via son module de rangement 55, chaque donnée extraite reçue dans la base structurée 10.
Comme décrit précédemment pour le module de rangement 55, lors de l’étape de rangement 160, le dispositif de génération 25 range dans la classe correspondant au premier identifiant associé à la loi d’extraction en réponse à laquelle la ou les données extraites sont reçues, chaque deuxième identifiant encore absent de la base structurée 10, chaque critère d’extraction, chaque donnée extraite, et au moins une première relation respective entre une donnée extraite respective et un deuxième identifiant respectif. Lors de l’étape de rangement 55, le dispositif de génération 25 range de préférence toutes les premières relations entre les données extraites, les deuxièmes identifiants et les critères d’extractions.
En complément facultatif, durant l’étape de rangement 160, dans le cas où au moins deux données extraites sont reçues en réponse à la même loi d’extraction envoyée, le dispositif de génération 25 range chaque donnée extraite reçue dans la classe correspondant au premier identifiant associé à ladite loi d’extraction.
En complément facultatif encore, durant l’étape de rangement 160, dans le cas où l’ensemble 15 comprend au moins deux bases sources 20, si deux deuxièmes identifiants associés à un même mot-clé respectif de la loi d’extraction sont reçus, le dispositif de génération 25 range une deuxième relation respective dans la classe correspondant au premier identifiant de la règle associée à ladite loi.
Pour chaque message reçu ne comprenant pas de jeu de donnée(s) extraite(s), le dispositif de génération 25 passe à une étape d’association 170 dans laquelle il associe la loi d’extraction à l’origine dudit message, à la classe de requête(s) infructueuse(s).
En complément facultatif, lors de l’étape d’association 170, le dispositif de génération 25 qualifie ladite loi d’infructueuse. Le dispositif de génération 25 range dans la classe de requête(s) infructueuse(s), chaque deuxième identifiant absent de la base structurée 10, chaque critère d’extraction et au moins une troisième relation respective liant deux deuxièmes identifiants entre eux ou liant un deuxième identifiant respectif à un critère d’extraction respectif. Le dispositif de génération 25 range de préférence toutes les troisièmes relations entre chaque deuxième identifiant et chaque critère d’extraction.
En complément facultatif encore, lors de l’étape d’association 170, si l’absence de donnée extraite est due à l’absence de traduction d’un mot-clé respectif de la loi envoyée en un deuxième identifiant respectif d’une base source 20 respective, alors le dispositif de génération 25 range, dans la classe de requête(s) infructueuse(s) : chaque deuxième identifiant de classe absent de la base structurée 10, chaque mot-clé non traduit en un deuxième identifiant respectif, chaque critère d’extraction, au moins une quatrième relation respective liant un deuxième identifiant respectif ou un mot-clé respectif, à un critère d’extraction respectif ou à un deuxième identifiant respectif ou à un mot-clé respectif. Pour chaque critère d’extraction relatif à chaque mot-clé non-traduit en un deuxième identifiant respectif, le mot-clé remplace le deuxième identifiant. Lors de l’étape d’association 170, chaque quatrième relation liant deux éléments rangés est de préférence rangée également dans la base structurée 170.
Selon une variante non représentée sur la figure 2, le dispositif de génération 25 réitère les étapes d’envoi 140, de rangement 160 et d’association 170 régulièrement, et de préférence périodiquement, pour la mise à jour des données dans la base structurée 10.
Le dispositif de génération 25 passe ensuite optionnellement dans une étape de récupération 180 au cours de laquelle il récupère via son module de récupération 65, la demande de donnée(s) de la part de l’utilisateur 47.
Le dispositif de génération 25 passe ensuite dans une étape de détermination 190 dans laquelle il détermine, via son module de détermination 70, si chaque donnée demandée est contenue ou non dans la base structurée 10.
Pour chaque donnée demandée, si ladite donnée est contenue dans la base structurée 10, le dispositif de génération 25 passe ensuite à une première étape de communication 200 au cours de laquelle il communique, via son module de communication 75, la donnée demandée à l’utilisateur 47 ou au dispositif électronique de traitement.
Pour chaque donnée demandée absente de la base structurée 10, le dispositif de génération 25 passe à une deuxième étape de détection 210 dans laquelle il détecte si la demande est relative au(x) élément(s) rangé(s) dans la classe de requêtes(s) infructueuse(s) en détectant si la demande est associée à un deuxième identifiant respectif, un critère d’extraction respectif, une troisième ou encore une quatrième relation respective de la classe de requête(s) infructueuse(s).
Si la demande est relative à un ou des éléments de la classe de requête(s) infructueuse(s), le dispositif de génération 25 passe à une deuxième étape de communication 220 dans laquelle il communique un message indiquant que la ou les données demandées sont absentes de l’ensemble 15, à l’utilisateur 47 ou au dispositif électronique de traitement.
Si la demande n’est pas relative à un ou des éléments de la classe de requête(s) infructueuse(s), le dispositif de génération 25 passe optionnellement à une troisième étape de communication 230 au cours de laquelle il communique un message indiquant que la ou les données demandées n’ont pas encore été recherchées à l’utilisateur 47 ou au dispositif de traitement.
Lors de la troisième étape de communication 230, le dispositif de génération 25 envoie optionnellement la demande à l’ensemble 15 et retourne à l’étape de rangement 160 si une donnée extraite respective est reçue en retour. Sinon, le dispositif de génération 25 passe à l’étape d’association 170. En cas de donnée extraite reçue en retour, le module de rangement 55 range les différents éléments dans une classe de la base structurée 10 choisie par l’utilisateur 47.
Le fonctionnement du système de génération 5, et plus précisément du dispositif de génération 25, va maintenant être illustré, en référence aux figures 2 et 3, sur un exemple de mission de vol d’un aéronef.
Lors de l’étape d’acquisition 1 10, l’action requise est par exemple le déroutement de l’aéronef.
Lors de l’étape d’acquisition 110, le dispositif de génération 25 acquiert les règles d’extraction, liées à l’action requise de déroutement de l’aéronef, dont les lois d’extraction sont respectivement : « trouver un aéroport dont la longueur de la piste est supérieure à une longueur L prédéterminée», et « trouver un aéroport dont les conditions météorologiques correspondent au standard CAVOK, et distant de l’aéronef d’au plus 50 km», CAVOK (de l’anglais « Cloud And Visibility OK ») correspondant à un standard météorologique dans lequel la visibilité est considérée comme bonne et dans lequel la présence de nuages est limitée. Le premier identifiant contenu dans chacune desdites règles d’extraction est « mission ».
Pour la première loi d’extraction, les mots-clés sont : « aéroport » et « piste ». Pour la deuxième loi d’extraction, les mots-clés sont : « aéroport », « conditions météorologiques » et « distant ».
Lors de l’étape d’acquisition 110, le module d’acquisition 35 acquiert également les données invariantes relatives à la référence du modèle de l’aéronef, par exemple « Airbus A350 », et à l’aéroport d’origine « aéroport d’origine Toulouse », chaque donnée invariante étant associée au premier identifiant de classe « mission ».
Lors de l’étape de génération 120, le dispositif de génération 25 génère la structure de la base structurée 10. La structure doit au moins comprendre la classe « mission », car elle correspond au premier identifiant de classe des règles d’extraction acquises. La structure comprend par exemple les six classes de la théorie de l’activité : « sujet », « outil(s) », « communauté », « division du travail », « visée », et « règle(s)».
Dans cet exemple, la classe « mission » correspond alors à la classe « visée », de sorte que les classes « visée » et « mission » forment une seule et même classe. Dans cet exemple également, la classe « sujet » est destinée à contenir des données relatives au pilote de l’aéronef, la classe « outil(s) » est destinée à contenir des données relatives aux moyens pour réaliser la mission, la classe « communauté » est destinée à contenir des données relatives à d’autres entités ou individus qui vont participer au déroulement de la mission comme le copilote, le personnel à bord, ou aux tours de contrôle, la classe « division du travail » est destinée à contenir des données relatives au partage de l’activité avec la communauté, et la classe « visée » est destinée à contenir des données relatives à la mission.
La structure générée comprend en outre la classe de requête(s) infructueuse(s), appelée « requête(s) infructueuse(s) ».
Sur la figure 3 les classes sont représentées sous forme de cases grisées chacune rattachée à la racine qui est représentée sous forme d’une case hachurée.
Lors de l’étape de génération 120, le dispositif de génération 25 range les données invariantes dans la classe indiquée par leur premier identifiant de classe.
Lors de l’étape de génération 120, le dispositif de génération 25 range les règles d’extraction dans la classe « règle(s) ». Sur la figure 3, les règles d’extraction sont respectivement référencées R± et R2.
Lors de l’étape de sélection 130, le dispositif de génération 25 sélectionne les règles d’extraction associées à l’action requise « déroutement de l’aéronef » choisie par l’utilisateur 47.
Lors de l’étape d’envoi 140, le dispositif de génération 25 complète la loi d’extraction de la première règle d’extraction avec la donnée invariante relative à la référence de modèle de l’aéronef, rangée dans la base structurée 10. La loi d’extraction de la première règle d’extraction devient donc par exemple « trouver un aéroport dont la longueur de la piste est supérieure à 1 ,2 km ».
Lors de l’étape d’envoi 140, le dispositif de génération 25 envoie, à l’ensemble 15, les lois d’extraction contenues dans les première et deuxième règles d’extraction.
Lors de la première étape de détection 150, le dispositif de génération 25 reçoit pour chaque loi envoyée, un message de la part de l’ensemble 15 et détecte la présence ou non du jeu de donnée(s) extraite(s). Un premier (respectivement deuxième) message correspond au message reçu suite à l’envoi de la loi d'extraction inclue dans la première (respectivement deuxième) règle d’extraction.
Le premier message comprend par exemple les deuxièmes identifiants : « aérodrome » et « piste d’atterrissage », le critère d’extraction « piste d’atterrissage > 1,2 km » et le jeu de donnée(s) extraite(s) « Bordeaux, Limoges » Le deuxième message comprend par exemple les deuxièmes identifiants : « aérodrome » et « météo », et « distance », les critères d’extraction « météo =CAVOK» et « distance < 50 km », mais aucun jeu de donnée(s) extraite(s).
Pour le premier message, lors de l’étape de rangement 160, le dispositif de génération 25 range, dans la classe « mission » de la base structurée 10, les deuxièmes identifiants, le critère d’extraction et les données extraites. Sur la figure 3, les deuxièmes identifiants, le critère d’extraction et les données extraites sont respectivement représentés par des cases en trait pointillé, respectivement de forme elliptique, parallélépipédique, et rectangulaire.
Lors de l’étape de rangement 160, le dispositif de génération 25 range dans la base structurée 10, les premières relations : « aérodrome comporte piste d’atterrissage », « Limoges est un aérodrome», « Bordeaux est un aérodrome», « Limoges comporte piste d’atterrissage », « Bordeaux comporte piste d’atterrissage », « piste d’atterrissage> 1,2 km est un type de piste d’atterrissage», « Limoges comporte piste d’atterrissage > 1,2 km » et « Bordeaux comporte piste d’atterrissage > 1,2 km ». Sur la figure 3, ces premières relations sont représentées par des segments en trait pointillé reliant chacun deux cases.
Pour le deuxième message, lors de l'étape d’association, 170, le dispositif de génération 25 qualifie la loi d’extraction d’infructueuse et range dans la classe « requête(s) infructueuse(s) », les deuxièmes identifiants « météo » et « distance », ainsi que les critères d’extraction « météo=CAVOK» et « distance < 50 km ». Le deuxième identifiant « aérodrome » n’est pas rangé dans la classe de requête(s) infructueuse(s) car il est déjà présent dans la classe « mission ».
Le dispositif de génération 25 range, également dans la base structurée 10, les troisièmes relations : « aérodrome comporte météo », « aérodrome est à distance » « distance < 50 km est un type de distance», « météo= CAVOK est un type de météo »
Par souci de lisibilité des dessins, les éléments rangés lors de l’étape d’association 170 ne sont pas représentés sur la figure 3.
Lors de l’étape de récupération 180, le dispositif de génération 25 récupère les première et deuxième demandes suivantes de la part de l’utilisateur 47 : « Quels sont les aéroports ayant une piste longue d’au moins 1 km ? » et « Quels sont les aéroports ayant une météo CAVOK et à une distance inférieure à 30 km de l’aéronef ? ».
Lors de l’étape de détermination 190, le dispositif de génération 25 détermine que la première demande est relative à des données extraites présentes dans la base structurée 10, contrairement à la deuxième demande. Pour la première demande, lors de la première étape de communication 200, le dispositif de génération 25 communique les données « Bordeaux » et « Limoges » à l’utilisateur 47.
Pour la deuxième demande, le dispositif de génération 25 passe à la deuxième étape de détection 210 dans laquelle il détecte que la deuxième demande est relative à la classe « requête(s) infructueuse(s) » car si l’ensemble 15 ne comporte aucune donnée vérifiant le critère d’extraction relatif aux conditions météorologiques et étant à une distance inférieure à 50 km de l’aéronef, alors l’ensemble 15 ne comporte aucune donnée vérifiant le même critère sur les conditions météorologiques et distant d’au plus 30 km.
Lors de la deuxième étape de communication 220, le dispositif de génération 25 communique à l’utilisateur 47 un message indiquant que la ou les données demandées sont absentes de l’ensemble 15.
Le procédé de génération selon l’invention permet alors de générer la base structurée 10 comprenant un nombre plus réduit de données, chaque donnée de la base structurée 10 correspondant à une règle d’extraction respective.
De plus, le rangement dans la base structurée 10 de deuxième(s) identifiant(s) de classe, de critère(s) d’extraction, de première(s) relation(s), deuxième(s) relation(s), troisième(s) relation(s) et de quatrième(s) relation(s) permet de contextualiser chaque donnée extraite et donc une meilleure utilisation des données extraites. Lesdits éléments sont qualifiés d’élément(s) de contexte. En effet, cela permet à un utilisateur d’avoir non seulement accès aux données, mais aussi au contexte dans lequel elles ont été extraites, et donc de mieux comprendre la provenance de chaque donnée. Ceci permet entre autres, à un utilisateur 47 de déceler une éventuelle incohérence d’une donnée extraite d’une base source 20, ce qui serait impossible, ou à tout le moins plus difficile, sans lesdits éléments de contexte.
En outre, le rangement de chacun des éléments de contexte précités, combiné avec la structure issue de la théorie de l’activité, permet de générer une base de données structurée 10 dédiée et exhaustive, à partir d’un procédé générique applicable à différents domaines.
De plus, la sélection de règles d’extraction en fonction de l’action requise choisie par l’utilisateur 47 rend l’extraction plus sélective, s’assurant que les données extraites sont utiles pour la compréhension de la situation.
En outre, la classe de requête(s) infructueuse(s) permet de distinguer parmi les données absentes, dans la base structurée 10, celles qui sont supposées non-pertinentes lors de l’établissement de(s) règle(s) d’extraction, de celles qui sont absente de(s) base(s) de source(s) 20. Les étapes optionnelles de récupération 180, de détermination 190 et de communication 200 permettent de communiquer à l’utilisateur 47 les données de la base structurée 10 et, grâce à la classe de requête(s) infructueuse(s) et l’étape d’association 170, de l’informer en outre plus rapidement quant aux éventuelles données absentes de l’ensemble 15. La prise en compte de l’absence de certaine(s) donnée(s) de l’ensemble 15 conduit alors à une meilleure compréhension de la part de l’utilisateur 47 des données qu’il a à sa disposition dans la base structurée 10.
En outre, le fait qu’en cas de demande ne concernant ni une donnée contenue dans la base structurée 10, ni un élément de la classe de requête(s) infructueuse, cette demande est préférentiellement néanmoins prise en compte pour interroger l’ensemble 15, permet à l’utilisateur 47 de ne pas être contraint par les seules données considérées comme pertinentes de par le groupe de règle(s) d’extraction.
Le fait que les lois d’extraction soient envoyées à l’ensemble 15 dans un langage dit naturel, et que la traduction en langage informatique est effectuée par le traducteur 30 respectif, rend le procédé plus facilement adaptable à différentes bases sources 20 hétérogènes. Il est notamment plus facile d’ajouter une ou plusieurs base sources 20 à l’ensemble 15.
En outre, le fait qu’en cas de réception de données distinctes, en réponse à une même loi d’extraction, les données extraites distinctes soient rangées, lors de l’étape de rangement 160, dans la même classe de la base structurée 10, permet de laisser la validation des données extraites à l’utilisateur 47. Cela permet en outre de ne pas risquer d’omettre le rangement d’une donnée pertinente dans la base structurée 10.
On conçoit ainsi que le procédé et le dispositif de génération 25 selon l’invention permettent d’améliorer l’extraction de données à partir de la ou des bases sources 20, ainsi que la génération de la base structurée 10 qui optimise les temps de réponses aux questionnements de l’utilisateur 47.

Claims

29 REVENDICATIONS
1. Procédé de génération, à partir d’un ensemble (15) de base(s) de données (20), d’une base structurée de données (10) associée à une mission, le procédé étant mis en œuvre par un dispositif électronique de génération (25) et comprenant les étapes suivantes :
- acquisition (110) d’une liste d’action(s) requise(s) au cours de la mission, et d’un groupe de règle(s) d’extraction de données de l’ensemble (15) de base(s) de données (20), chaque règle d’extraction comportant un premier identifiant d’une classe de la base structurée de donnée (10) et une loi d’extraction de donnée(s) à partir de la ou des bases de données (20), chaque règle étant associée à une ou plusieurs action(s) requise(s),
- génération (120) d’une structure de la base structurée de données (10) comportant au moins une classe pour chaque premier identifiant de classe distincte, et une classe de requête(s) infructueuse(s),
- sélection (130) de règle(s) d’extraction parmi le groupe de règle(s) d’extraction acquis, en fonction d’une action requise choisie par un utilisateur (47) parmi la liste d’action(s) requise(s),
- envoi (140) de la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à l’ensemble (15) de base(s) de données (20), et réception de donnée(s) extraite(s) de la part des bases de données (20) suite à cet envoi,
- rangement (160) de la ou chaque donnée extraite reçue dans la classe de la base structurée (10) correspondant au premier identifiant de classe associé à la loi d’extraction en réponse à laquelle ladite donnée a été reçue, et
- pour chaque loi d’extraction envoyée, si aucune donnée extraite n’est reçue en réponse de la part de l’ensemble (15) de base(s) de données (20), association (170) de ladite loi à la classe de requête(s) infructueuse(s).
2. Procédé selon la revendication 1 , dans lequel, suite à l’envoi (140) d’une loi d’extraction, aucune donnée extraite n’est reçue de l’ensemble des base(s) de données (15) si le ou les messages reçus de l’ensemble (15) de base(s) de données (20) vérifient seulement au moins l’un des cas suivants : un message d’erreur est reçu de l’ensemble (15) de base(s) de données (20),
- un message comportant un champ de données vide est reçu de la part de l’ensemble (15) de base(s) de données (20). 30
3. Procédé selon la revendication 1 ou 2, dans lequel l’ensemble de base(s) (15) de données comprend au moins deux bases de données (20), et lors de l’étape d’envoi (140), la loi d’extraction incluse dans chaque règle d’extraction sélectionnée est envoyée à chaque base de données (20).
4. Procédé selon la revendication 3, dans lequel si les bases de données (20) fournissent au moins deux données extraites différentes en réponse à une même loi d’extraction envoyée, les au moins deux données extraites sont, lors de l’étape de rangement (160), rangées dans la même classe de la base structurée (10), correspondant au premier identifiant de classe associé à ladite loi d’extraction.
5. Procédé selon l’une quelconque des revendications précédentes, dans lequel suite à l'envoi (140) d’une loi d’extraction, chaque donnée reçue comprend : un jeu de donnée(s) extraite(s) d’une base de données (20), en réponse à la loi d’extraction envoyée,
- un ensemble de deuxième(s) identif iant(s) de classe de la base de données (20) depuis laquelle jeu de donnée(s) extraite(s) est issu, chaque deuxième identifiant correspondant à une classe respective de ladite base de données (20) depuis laquelle au moins une donnée extraite respective est issue, et un groupe de critère(s) d’extraction de données depuis la base de données (20) dont le jeu de donnée(s) extraite(s) est issu, l’ensemble de deuxième(s) identifiant(s) et le groupe de critère(s) étant propre à chaque base de données (20) et étant générés à partir de la loi d’extraction envoyée, lors de l’étape de rangement (160), l’ensemble de deuxième(s) identifiant(s), le groupe de critère(s) et le jeu de donnée(s) sont rangés dans la classe correspondant au premier identifiant de classe associé à ladite loi d’extraction, lors de l’étape de rangement (160), au moins une première relation entre une donnée extraite et un deuxième identifiant de classe est en outre rangé dans ladite classe de la base structurée (10).
6. Procédé selon l’une quelconque des revendications précédentes, dans lequel la mission est le vol d’un aéronef, l’ensemble d’action(s) requise(s) comprenant de préférence : un démarrage de l’aéronef, un déroutement de l’aéronef et un contournement par l’aéronef d’une zone géographique.
7. Procédé selon la revendication 6, dans lequel les règles d’extraction associées à l’action requise de déroutement comprennent les lois d’extraction :
- trouver un aéroport dont la longueur de la piste est supérieure à une longueur prédéfinie,
- trouver un aéroport dont les conditions météorologiques correspondent à des conditions prédéfinies,
- trouver un aéroport possédant des services d’urgence, et
- trouver un aéroport distant de l’aéronef d’au plus une distance maximale prédéfinie ( max) ; et dans lequel les règles d’extraction associées à l’action requise de contournement comprennent les lois d’extraction : trouver des coordonnées de point(s) de passage de l’aéronef pour le(s)quel(s) les conditions météorologiques correspondent à des conditions prédéfinies, et distant de l’aéronef d’au plus une deuxième distance maximale prédéfinie (D2max).
8. Procédé selon l’une quelconque des revendications précédentes, dans lequel, lors de l’étape d’acquisition (110), des données invariantes au cours de la mission sont en outre acquises, et lors de l’étape d’envoi (140), au moins une loi d’extraction envoyée est complétée par au moins une donnée invariante au cours de la mission, si la mission est les vol d’un aéronef, les données invariantes au cours de la mission comprenant de préférence un type ou une référence de modèle de l’aéronef, un numéro de vol d’un aéronef, un aéroport de départ de l’aéronef, une quantité initiale de carburant dans l’aéronef.
9. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend en outre, après l’étape de rangement (160) ou d’association (170) :
- une étape de récupération (180) d’une demande de la part d’un utilisateur (47), et
- si la demande concerne une loi d’extraction associée à la classe de requête(s) infructueuse(s), une étape (220) de communication d’un message indiquant que la donnée répondant à la demande est absente de l’ensemble (15) de base(s) de données (20) à l’utilisateur (47).
10. Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon l’une quelconque des revendications précédentes.
11. Dispositif électronique de génération (25) configuré pour générer, à partir d’un ensemble (15) de base(s) de données (20), une base structurée de données (10) associée à une mission, le dispositif (25) étant apte à être relié à un ensemble (15) de base(s) de données (20), le dispositif électronique de génération (25) comprenant :
- un module d’acquisition (35) configuré pour acquérir une liste d’action(s) requise(s) au cours de la mission, et un groupe de règle(s) d’extraction de données de l’ensemble (15) de base(s) de données (20), chaque règle d’extraction comportant un premier identifiant d’une classe de la base structurée de donnée (10) et une loi d’extraction de donnée(s) à partir de la ou des bases de données (20), chaque règle étant associée à une ou plusieurs action(s) requise(s),
- un module de génération (40) configuré pour générer une structure de la base structurée de données (10) comportant au moins une classe pour chaque premier identifiant de classe distincte, et une classe de requête(s) infructueuse(s),
- un module de sélection (45) configuré pour sélectionner une ou plusieurs règles d’extraction parmi le groupe de règle(s) d’extraction acquis, en fonction d’une action requise choisie par un utilisateur (47) parmi la liste d’action(s) requise(s),
- un module d’envoi (50) configuré pour envoyer la loi d’extraction incluse dans chaque règle d’extraction sélectionnée, à l’ensemble (15) de base(s) de données (20), et un module de réception de donnée(s) de la part des bases de données (20) suite à cet envoi,
- un module de rangement (55) configuré pour ranger la ou chaque donnée reçue dans la classe de la base structurée (10) correspondant au premier identifiant de classe associé à la loi d’extraction en réponse à laquelle ladite donnée a été reçue, et
- un module d’association (60) configuré pour associer chaque loi d’extraction envoyée, pour laquelle aucune donnée extraite n’est reçue en réponse de la part de l’ensemble (15) de base(s) de données (20), à la classe de requête(s) infructueuse(s).
PCT/EP2021/076830 2020-10-01 2021-09-29 Procédé et dispositif électronique de génération d'une base structurée de données pertinentes pour la gestion d'une mission, programme d'ordinateur associé WO2022069564A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP21786392.7A EP4222612A1 (fr) 2020-10-01 2021-09-29 Procédé et dispositif électronique de génération d'une base structurée de données pertinentes pour la gestion d'une mission, programme d'ordinateur associé

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2010033 2020-10-01
FR2010033A FR3114889A1 (fr) 2020-10-01 2020-10-01 Procede et dispositif electronique de generation d'une base structuree de donnees pertinentes pour la gestion d'une mission, programme d'ordinateur associe

Publications (1)

Publication Number Publication Date
WO2022069564A1 true WO2022069564A1 (fr) 2022-04-07

Family

ID=73793409

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/076830 WO2022069564A1 (fr) 2020-10-01 2021-09-29 Procédé et dispositif électronique de génération d'une base structurée de données pertinentes pour la gestion d'une mission, programme d'ordinateur associé

Country Status (3)

Country Link
EP (1) EP4222612A1 (fr)
FR (1) FR3114889A1 (fr)
WO (1) WO2022069564A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116739646A (zh) * 2023-08-15 2023-09-12 南京易联阳光信息技术股份有限公司 网络交易大数据分析方法及分析系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080040308A1 (en) * 2006-08-03 2008-02-14 Ibm Corporation Information retrieval from relational databases using semantic queries

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080040308A1 (en) * 2006-08-03 2008-02-14 Ibm Corporation Information retrieval from relational databases using semantic queries

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
M.R. ENSLEY: "Toward a theory of situation awareness in dynamic systems", HUMAN FACTORS THE JOURNAL OF THE HUMAN FACTORS AND ERGONOMICS SOCIETY, vol. 37, 1995
PRADEL CAMILLE ET AL: "Swip : une interface Langue Naturelle à SPARQL programmée en SPARQL", 1 May 2014 (2014-05-01), Clermont-Ferrand, France, pages 201 - 212, XP055811746, Retrieved from the Internet <URL:https://hal.inria.fr/hal-01015273/document> *
WANG CHONG ET AL: "PANTO: A Portable Natural Language Interface to Ontologies", 3 June 2007, ICIAP: INTERNATIONAL CONFERENCE ON IMAGE ANALYSIS AND PROCESSING, 17TH INTERNATIONAL CONFERENCE, NAPLES, ITALY, SEPTEMBER 9-13, 2013. PROCEEDINGS; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER, BERLIN, HEIDELBERG, PAGE(S) 473 - 4, ISBN: 978-3-642-17318-9, XP047411390 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116739646A (zh) * 2023-08-15 2023-09-12 南京易联阳光信息技术股份有限公司 网络交易大数据分析方法及分析系统
CN116739646B (zh) * 2023-08-15 2023-11-24 南京易联阳光信息技术股份有限公司 网络交易大数据分析方法及分析系统

Also Published As

Publication number Publication date
EP4222612A1 (fr) 2023-08-09
FR3114889A1 (fr) 2022-04-08

Similar Documents

Publication Publication Date Title
WO2020077350A1 (fr) Systèmes et procédés adaptables de découverte d&#39;intention à partir de données d&#39;entreprise
FR3035534A1 (fr) Procede et systeme de communication et de partage d&#39;informations pour aeronef
EP4222612A1 (fr) Procédé et dispositif électronique de génération d&#39;une base structurée de données pertinentes pour la gestion d&#39;une mission, programme d&#39;ordinateur associé
Bangare et al. The architecture, classification, and unsolved research issues of big data extraction as well as decomposing the internet of vehicles (IoV)
Ma et al. Big data actionable intelligence architecture
EP1045304A1 (fr) Procédé de pilotage d&#39;un processus décisionnel lors de la poursuite d&#39;un but dans un domaine d&#39;application déterminé, tel qu&#39;économique, technique organisationnel ou analogue et système pour la mise en oeuvre du procédé
FR2990547A1 (fr) Systeme de maintenance centralisee parametrable destine a un aeronef
FR3061576A1 (fr) Procede et plateforme pour l&#39;elevation des donnees sources en donnees semantiques interconnectees
Lorini et al. SMDRM: A Platform to Analyze Social Media for Disaster Risk Management in Near Real Time.
FR2950176A1 (fr) Procede et dispositif d&#39;acces a la documentation et performance d&#39;un aeronef selon des alarmes generees dans ce dernier
Mahmood et al. Public bus commuter assistance through the named entity recognition of twitter feeds and intelligent route finding
Han et al. Problem-oriented CBR: Finding potential problems from lead user communities
FR3083897A1 (fr) Systeme de gestion de taches d&#39;un equipage d&#39;aeronef lors d&#39;une mission et procede associe
FR3047340B1 (fr) Systeme d&#39;aide a la decision d&#39;autorisation a partir d&#39;un aeronef, et procede associe
EP1199678A1 (fr) Procédé de pilotago de processus décisionnel lors de la poursuite d&#39;un but dans un domaine d&#39;application déterminé, tel qu&#39;économique, technique, organistionnel ou analogue
WO2023117200A1 (fr) Procédé de traitement de données d&#39;un dispositif d&#39;assistance au pilotage d&#39;aéronefs
Pezanowski et al. Differentiating geographic movement described in text documents
WO2023103814A1 (fr) Extraction d&#39;informations temporelles relatives à une requête de documents textuels non structurés
Pereira et al. A Workflow to Detect Traffic Events Using Multiple Algorithms and Data Sources
WO2020249719A1 (fr) Procede et systeme de fusion d&#39;informations
EP0617349B1 (fr) Procédé et dispositif de reconfiguration en temps réel de la trajectoire d&#39;un véhicule
FR2956499A1 (fr) Procede et dispositif permettant l&#39;exploitation fonctionnelle, dans un aeronef, d&#39;un grand nombre d&#39;informations issues de differentes sources
WO2007088254A1 (fr) Systeme d&#39;information structure, relationnel et incremental
FR3121257A1 (fr) Dispositif d’assistance au pilotage d’aéronefs
Sarthou Knowledge representation and exploitation for interactive and cognitive robots

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21786392

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021786392

Country of ref document: EP

Effective date: 20230502