FR2883082A1 - Planification d'actions sur des concepts dans une base de donnees de concepts - Google Patents

Abstract

Un système planifie temporellement depuis un terminal de planification (TP) des actions de concept dans une base de données de concepts (BDC) liée à un serveur (SB). Des modules (MCR, MM, MS) préparent des actions sélectionnées pour créer, modifier, ou supprimer des concepts de la base (BDC). Une date d'exécution (DE) est attribuée à l'action sélectionnée qui est ensuite transmise et mémorisée avec des données (DO) définissant l'action sélectionnée dans un fichier numérique (FN) dans le serveur. L'action est alors exécutée automatiquement à la date d'exécution. Le fichier de planification obtenu est alors plus compact qu'un fichier de sauvegarde traditionnel et offre une diminution des sauvegardes des états de la base ainsi qu'une possibilité de réviser toute évolution de la base.

Description

Planification d'actions sur des concepts

dans une base de données de concepts La présente invention concerne une planification temporelle d'actions sur des concepts dans une base de données de concepts.

Actuellement, les logiciels d'édition d'états de base de données de concepts agissent sur une base de données pour sauvegarder l'état courant de la base en tant que version de celle-ci dans une mémoire d'un serveur de gestion gérant la base de données de concepts. Le choix de sauvegarder une version de la base doit être fait lorsque la base de données de concepts est dans l'état que l'on souhaite sauvegarder comme version particulière.

Toute modification apportée à un concept de la base modifie l'état de celle-ci. La capacité de la mémoire du serveur de gestion étant limitée, celle-ci ne peut pas sauvegarder les nombreux états de la base pour toutes les modifications de données effectuées dans la base par le gestionnaire de la base. Ce dernier méconnaît ainsi des états intermédiaires entre les états sauvegardés.

Avec ces logiciels d'édition d'états de base, il est possible de revenir seulement sur des états antérieurs de la base que le serveur a sauvegardés. Il est donc impossible de se projeter dans un état futur de la base pour visualiser une représentation des modifications apportées.

L'invention a pour objectif de planifier temporellement depuis un terminal des actions relatives à des concepts dans une base de données de concepts, en les rendant effectives à des dates d'exécution respectives déterminées et ainsi en les exécutant automatiquement aux dates d'exécution respectives. Grâce à la mémorisation de données de planification relatives à l'exécution d'actions dans la base de données de concepts, l'invention ne requiert pas de nombreuses sauvegardes des états de la base à différentes dates antérieures ou postérieures pour connaître précisément les caractéristiques de ces états et ainsi ne requiert pas une mémoire de capacité élevée dans le serveur gérant la base.

Pour atteindre cet objectif, un procédé pour planifier depuis un terminal des actions relatives à des concepts dans une base de données de concepts liée à un serveur, comprenant une sélection dans le terminal d'une action parmi une création, une modification et une suppression de concept, est caractérisé en ce qu'il comprend les étapes de: préparer dans le terminal l'action sélectionnée, attribuer dans le terminal une date d'exécution à l'action sélectionnée, transmettre la date d'exécution attribuée et des données définissant l'action sélectionnée depuis le terminal au serveur, mémoriser dans le serveur la date d'exécution attribuée en correspondance avec les données de l'action sélectionnée dans un fichier numérique, et exécuter l'action sélectionnée à la date d'exécution dans la base de données de concepts.

Selon une autre caractéristique de l'invention, le procédé peut comprendre une étape de mémoriser une date de préparation en correspondance avec l'action sélectionnée dans le fichier numérique.

Il en résulte ainsi une sauvegarde de la liste des actions correspondant à une base de données de concepts. L'ensemble des actions courantes est sauvegardé dans une mémoire du serveur dans un fichier accessible et en relation avec la base de données de concepts. Cette sauvegarde des actions a l'avantage d'être plus compacte qu'une sauvegarde des états de la base, généralement d'usage dans la plupart des logiciels.

Ainsi, ces actions mémorisées constituent une planification temporelle d'évolution de la base de données de concepts, afin de réviser la base depuis son origine jusqu'à la dernière évolution planifiée.

L'invention offre aussi la possibilité de revenir sur tout état antérieur de la base de données puisque toute modification d'un concept est associée à une action de concept planifiée et mémorisée. En outre, l'invention autorise une réflexion ultérieure sur des intentions d'évolution de la base afin de changer éventuellement une planification qui n'est plus approuvée.

L'invention concerne également un système de planification d'une base de données de concepts liée à un serveur, comprenant un terminal pour planifier des actions relatives à des concepts dans la base de données de concepts, le terminal comprenant un moyen pour sélectionner une action parmi une création, une modification et une suppression de concept, caractérisé en ce que le terminal comprend un moyen pour préparer l'action sélectionnée, un moyen pour attribuer une date d'exécution à l'action sélectionnée, et un moyen pour transmettre la date d'exécution attribuée et des données définissant l'action sélectionnée au serveur, et le serveur comprend un moyen pour mémoriser la date d'exécution attribuée en correspondance avec les données de l'action sélectionnée dans un fichier numérique afin d'exécuter l'action sélectionnée à la date d'exécution dans la base de données de concepts.

Pour obtenir une base de données de concepts fonctionnelle, les actions sont exécutées afin de créer ladite base dans un format cible qui sera utilisé par le système informatique.

L'invention a trait aussi à un terminal de planification d'une base de données de concepts liée à un serveur, pour planifier des actions relatives à des concepts dans la base de données de concepts, et comprenant un moyen pour sélectionner une action parmi une création, une modification et une suppression de concept, caractérisé en ce qu'il comprend un moyen pour préparer l'action sélectionnée, un moyen pour attribuer une date d'exécution à l'action sélectionnée, et un moyen pour transmettre la date d'exécution attribuée et des données définissant l'action sélectionnée au serveur, afin que le serveur mémorise la date d'exécution attribuée en correspondance avec les données de l'action sélectionnée dans un fichier numérique, et exécute l'action sélectionnée à la date d'exécution dans la base de données.

D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention, données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels: - la figure 1 est un bloc-diagramme schématique d'un système de planification selon l'invention; et - la figure 2 est un algorithme schématique du procédé de planification selon l'invention.

De manière générale, l'invention décrite ci-après est relative à une planification temporelle des états d'une base de données de concepts pour être édités à tout moment.

Une base de données de concepts est par exemple une base de connaissances sémantiques, utilisée pour un système d'Intelligence Artificielle (IA) ou le Web Sémantique. Des concepts d'un domaine de connaissance sont organisés et représentés dans une base de données en vue de partager ou rechercher des informations ou de raisonner sur des connaissances.

Une base de connaissances sémantiques concerne des concepts représentés par des signes et/ou des mots. Par exemple le concept de "chien" est représenté par un dessin ou logotype de chien ou de tête de chien indépendant de langues, ou une onomatopée "ouah, ouah", ou un mot dans une langue donnée. Tout concept a un identificateur IC et des attributs At comprenant des données d'interprétation.

Selon l'exemple précédent, les attributs du concept "chien" sont la race, la taille, le club de protection de la race, etc. La planification d'une telle base de données de concepts couvre des actions de création, de modification et suppression de concepts pour compléter ou traduire l'évolution des connaissances relatives à la base à des dates données.

Le système de planification mettant en oeuvre le 35 procédé de planification selon une réalisation préférée de l'invention repose sur une architecture client-serveur et comprend au moins un terminal de planification TP d'un utilisateur US, en tant que terminal client, et un serveur SB gérant une base de données de concepts BDC. Des composants logiciels relatifs à des fonctionnalités de l'invention sont essentiellement installés dans le terminal de planification TP, tel qu'un ordinateur personnel ou un terminal intelligent, pouvant communiquer avec le serveur de gestion de base de données SB, comme illustré à la figure 1.

Le terminal de planification TP est connecté à un réseau d'accès RA à travers une liaison de télécommunications LT. La liaison LT et le réseau RA peuvent être classiquement une ligne téléphonique et le réseau téléphonique commuté RTC lui-même connecté à un réseau de télécommunications RT de type internet. Selon d'autres variantes, la liaison de télécommunications LT est une ligne xDSL (Digital Subscriber Line) ou une ligne RNIS (Réseau Numérique à Intégration de Services) reliée au réseau d'accès correspondant. Le terminal de planification TP est par exemple un ordinateur personnel relié directement par modem à la liaison LT. Le terminal de planification et les réseaux d'accès ne sont pas limités aux exemples ci-dessus et peuvent être constitués par d'autres terminaux et réseaux d'accès connus.

Le serveur de gestion de base de données SB est relié au réseau de télécommunications RT. Le serveur SB et le terminal TP communiquent à travers les réseaux RA et RT.

Dans une variante, le serveur SB est à proximité du terminal TP et la liaison LT est par exemple une liaison câblée classique ou une liaison radio de faible portée.

Le serveur de gestion de base de données SB gère au moins une base de données de concepts BDC à laquelle le terminal de planification TP se connecte. Le serveur SB comprend un module d'identification MID, des modules d'attribut MA, un module de génération MG et une mémoire MEM comprenant au moins un fichier numérique FN.

Le serveur SB reçoit des requêtes selon le protocole de transport utilisé par le terminal de planification TP, interprète et traite les requêtes en coopération avec les modules MID et MA, forme des réponses selon ledit protocole de transport, et transmet les réponses au terminal de planification TP.

Dans la suite de la description, le terme module peut désigner un dispositif, un logiciel ou une combinaison de matériel informatique et de logiciel, configuré pour exécuter au moins une tâche particulière.

Le module d'identification MID est relatif à la dénomination d'un concept de la base BDC en associant un identificateur de concept IC au concept. Le module MID commande une application pour la création d'un nouveau concept en mémorisant un identificateur de concept IC dans la base BDC, ou une application pour la sélection d'un identificateur de concept IC afin de modifier ou supprimer le concept existant désigné par l'identificateur de concept. Par exemple, pour une entreprise commerciale offrant des prêts à la consommation, un concept "prêt-express-auto" est créé et appartient alors à une classe prédéterminée de la base BDC afin d'établir différentes catégories de concept, sous forme de hiérarchie par exemple, nécessaires à la gestion de toute base de données de concepts. Une modification de l'identificateur IC peut conduire à une suppression du concept correspondant, puisque celui-ci n'est plus identifié, afin de préserver la cohérence de la lecture de la base de données de concepts.

Chaque module d'attribut MA concerne des attributs At d'un concept respectif comprenant des données d'interprétation nécessaires à la gestion de la base de données de concepts BDC. Comme le module MID, le module MA commande une application nécessaire à la création d'attributs At d'un nouveau concept ou à la modification d'attributs At d'un concept existant afin de mémoriser les nouveaux attributs de concept dans la base BDC.

De préférence, le procédé de la présente invention s'applique à des bases de connaissances sémantiques. Dans ce cas, le module d'attribut MA peut comprendre plusieurs sous-modules correspondant chacun à un attribut At particulier d'un concept. Par souci de clarté, le concept sur lequel un utilisateur travaille sera désigné par le concept CO dans le paragraphe suivant, afin de le distinguer d'autres concepts avec lesquels il est en relation.

Ainsi, un sous-module de verbalisation associe au moins une expression linguistique au concept CO, à l'aide de laquelle le système désigne le concept CO, par exemple l'expression "Prêt Express Auto ". Un sous-module de relation met en relation un concept CO avec un autre concept. Via ce sous-module, l'utilisateur sélectionne un concept existant auquel le concept CO est rattaché, notamment pour établir une hiérarchie dans la base de connaissances. Par exemple, le concept "prêt-express-auto" dépend d'un concept existant "prêt-express" de la même classe tout en étant relatif à un autre concept existant "auto". Un sous-module d'interprétation concerne des expressions linguistiques, ou mots-clés, nécessaires au système pour comprendre et identifier le concept CO. Par exemple, pour le concept CO ayant l'identificateur IC "prêt-express-auto", des mots-clés associés choisis par un utilisateur sont "prêt express automobile", "emprunt express voiture" ou encore "prêt express voiture". Les sous-modules sont invoqués afin de couvrir l'ensemble des actions usuelles pour la gestion de la base de données de concepts.

Le terminal de planification TP relatif à un utilisateur US comprend une unité centrale de traitement UT incluant une interface de communication avec le réseau d'accès RA, un module de création de concept MCR, un module de modification de concept MM, un module de suppression de concept MS, un module de planification MP, un module de validation MVA, un module de consultation MCO, et une interface d'utilisateur comportant un clavier CL et un écran de visualisation EC.

Le module de création MCR, le module de modification MM et le module de suppression MS effectuent, c'est-à-dire préparent et exécutent des actions sur des concepts dans la base de données de concepts BDC. Une action de concept effectuée par le module de création MCR est une création d'un nouveau concept en définissant un identificateur IC du nouveau concept ainsi que des attributs At du nouveau concept. Des actions de concept effectuées par le module de modification MM et le module de suppression MS sont respectivement une modification au moins d'un attribut At d'un concept et une suppression d'un concept, c'est-à- dire une suppression de l'identificateur IC et de tous les attributs At du concept.

Le module de planification MP associe une date d'exécution DE à chaque action de concept effectuée par un des modules de création, de modification ou de suppression.

Le procédé de planification selon la réalisation préférée de l'invention comprend principalement des étapes El à E6, précédées d'étapes préliminaires E01 et E02, montrées à la figure 2.

Dans cette réalisation préférée, l'objectif de l'utilisateur US du terminal de planification TP est de planifier temporellement les évolutions d'une base de données de concepts en associant une date d'exécution DE à chaque action de concept caractérisant une évolution de la base.

A l'étape E01, le terminal de planification TP, à la demande de l'utilisateur US, lance une application logicielle sur l'écran EC du terminal TP, invitant l'utilisateur à sélectionner une base de données de concepts BDC.

A l'étape E02, le terminal de planification TP se connecte au serveur de base de données de concepts SB, gérant la base de données de concepts BDC sélectionnée et invitant l'utilisateur à s'identifier. Une fois l'utilisateur identifié, une session entre le terminal TP et le serveur SB débute.

A l'étape El, une action est sélectionnée pour traiter un ensemble de tâches et requêtes, correspondant à une action de concept, à appliquer à la base de données de concepts BDC à une date d'exécution DE. L'action de concept est une action de création de concept C, ou une action de modification de concept M, ou une action de suppression de concept S. Suivant l'action sélectionnée, trois séries d'étapes E211-E212, E221-E222E223 et E23 se présentent pour préparer l'action sélectionnée.

Si une action de création C est sélectionnée, à l'étape E211, le module de création MCR commande automatiquement l'ouverture d'une fenêtre de détermination d'identificateur à l'unité centrale de traitement UT pour créer un nouveau concept. L'utilisateur est alors invité à déterminer un identificateur IC du nouveau concept, par exemple en le saisissant et le validant au clavier CL. A l'étape E212, une fenêtre de détermination d'attributs est ensuite automatiquement commandée par l'unité UT pour déterminer des attributs At du concept, nécessaires à la cohérence du concept dans la base BDC.

Si une action de modification M est sélectionnée, le module de modification MM requiert automatiquement auprès de l'unité centrale de traitement UT à l'étape E221, la transmission d'une requête au serveur SB qui traite et interprète la requête en coopération avec le module d'identification MID. Le serveur SB forme alors une réponse incluant des identificateurs de concept fournis par le module d'identification MID et transmet la réponse au terminal de planification TP. L'unité UT reçoit la réponse et commande au module de modification MM l'ouverture d'une fenêtre contenant la liste des identificateurs de concept, pour sélectionner un identificateur de concept IC dans ladite liste. , A l'étape E222, le module MM transmet automatiquement une autre requête incluant l'identificateur sélectionné et validé IC au serveur SB qui traite et interprète la requête en coopération avec le module d'attribut MA relatif au concept désigné par l'identificateur sélectionné IC. Le module MM reçoit une réponse formée par le serveur SB et commande l'ouverture d'une fenêtre pour une sélection d'attribut dans une liste d'attributs de concept afin de modifier et valider au moins un attribut du concept désigné par l'identificateur sélectionné IC. A l'étape E223, l'utilisateur US modifie partiellement ou entièrement l'attribut At sélectionné au moyen du clavier CL dans une fenêtre de modification. Chaque action de modification ainsi préparée nécessite la réalisation des trois étapes précitées E221, E222 et E223.

Si une action de suppression S est sélectionnée, le module de suppression MS requiert automatiquement auprès de l'unité centrale de traitement UT à l'étape E221 la transmission d'une requête au serveur SB et reçoit une réponse du serveur SB commandant l'ouverture d'une fenêtre pour une sélection d'identificateur dans une liste d'identificateurs de concept.

Un premier ensemble de contrôles de cohérence est réalisé par l'unité centrale de traitement UT au moment d'une détermination d'identificateur ou d'attribut, par exemple lorsque l'utilisateur effectue une modification, en vérifiant l'existence de concepts invoqués.

Dans les trois cas, à l'étape E3 succédant l'une des étapes E212, E223 et E23, un deuxième ensemble de contrôles de cohérence est réalisé par l'unité centrale de traitement UT pour vérifier la cohérence des dates d'exécution, par exemple si une suppression de concept n'a pas été décidée antérieurement à une modification du concept. Puis le module de planification MP invite l'utilisateur à attribuer une date d'exécution DE à l'action de concept sélectionnée préparée, en sélectionnant une date d'exécution DE dans un calendrier affiché à l'écran EC par exemple, ou en saisissant directement une date dans champ affiché au moyen du clavier CL. La date d'exécution DE et la transcription numérique de l'action de concept ainsi préparée sous la forme d'un identificateur IA de l'action, de l'identificateur IC du concept sur lequel est appliquée l'action et éventuellement les attributs sélectionnés At du concept sont alors mémorisées provisoirement dans une mémoire du terminal TP sous forme de données d'action DO. Il sera entendu que la date d'exécution DE doit être postérieure à la date courante à laquelle la date d'exécution DE est déterminée; sinon un message d'erreur apparaît sur l'écran EC.

Pour chaque action de concept, le module de validation MVA demande à l'utilisateur une validation, à l'étape E4. S'il n'y a pas de validation d'une action de création, un nouvel identificateur de concept IC est à déterminer par l'utilisateur en retournant à l'étape E211. S'il n'y a pas validation d'une action de modification ou de suppression, l'unité UT invite l'utilisateur à sélectionner de nouveau l'identificateur IC d'un concept à modifier à l'étape E221 ou d'un concept à supprimer à l'étape E23.

A l'étape E5, l'unité UT du terminal TP transmet au serveur SB les données d'action DO(DE, IA, IC, At) comprenant notamment la date d'exécution DE sélectionnée en correspondance avec l'identificateur IA de l'action de concept précédemment préparée.

A l'étape E6, le serveur SB mémorise les données d'action DO dans un fichier numérique FN dans la mémoire de serveur MEM. Le serveur SB identifie la date courante afin de mémoriser dans la mémoire MEM également une date de préparation DP, identique à la date courante, en association avec la donnée DO de l'action sélectionnée dans le fichier FN. Par exemple, le fichier FN est un sous-fichier "log" établissant un historique des actions courantes effectuées par des utilisateurs relativement à un concept, et plusieurs sous-fichiers associés respectivement à des concepts contribuent à former par association d'identificateurs de concept IC et d'action IA aux dates d'exécution DE un fichier de planification de la base BDC. Le fichier de planification est alors plus compact qu'un fichier de sauvegarde traditionnel contenant les données et les instructions relatives à un état de la base de données de concepts BDC à une date antérieure à la date courante.

En variante, l'unité centrale de traitement UT associe la date de préparation DP à la donnée DO dès l'étape ES, avant de transmettre la donnée DO au serveur SB.

Dans une autre variante, un identificateur d'utilisateur est mémorisé par l'unité UT ou le serveur SB en association aux données DO, afin d'identifier l'auteur de chaque action de concept.

Par la suite, en fonction des dates d'exécution respectives, les actions préparées sont exécutées dans la base de données de concepts BDC à des étapes d'exécution E7 respectivement en fonction de leurs dates d'exécution, puis les données DO de chaque action exécutée peuvent être conservées ou effacées dans la mémoire MEM. En parallèle aux étapes d'exécution E7, comme indiqué en traits pointillés à la suite de l'étape E6 dans la figure 2, les étapes El à E6 sont réitérées si l'utilisateur souhaite planifier de nouveau une action de concept. Par exemple, un concept pour lequel une action comme une création ou une modification a été sélectionnée et préparée auparavant, est sélectionné après l'étape de mémoriser E6 pour modifier la date d'exécution DE de l'action de concept sélectionnée.

L'utilisateur a également la possibilité de visualiser une représentation schématique d'un état de la base de données de concepts BDC à une date d'exécution sélectionnée DE antérieure ou postérieure à la date courante à une étape E8. Dans ce cas, en réponse à une requête de représentation schématique, le serveur SB lance une application de génération d'état de base lue dans le module de génération d'état de base MG pour automatiquement réaliser les étapes suivantes.

sauvegarder l'état courant de la base à la date courante, générer progressivement des états intermédiaires de la base depuis l'état courant de la base à la date courante jusqu'à atteindre l'état désiré de la base à la date d'exécution sélectionnée en fonction des diverses données de concept lues dans les fichiers FN dans la mémoire MEM du serveur et respectivement incluant des dates d'exécution intermédiaires entre la date courante et la date d'exécution sélectionnée, et déduire dudit état de base désiré la représentation schématique de celui-ci à transmettre au terminal pour l'afficher.

Ainsi l'invention ne recourt pas à de nombreuses sauvegardes exigeant une capacité de mémoire très élevée dans le serveur et est capable de déduire automatiquement n'importe quel état de la base BDC en fonction du seul état courant de celle-ci.

L'utilisateur peut encore consulter des actions de concept mémorisées dans un fichier FN.

En outre, une visualisation des résultats des dernières exécutions d'actions de concept est accessible, afin de constater si des erreurs se sont produites par exemple.

Le module de consultation MCO présente à l'utilisateur des états de la base de données de concepts BDC à une date d'exécution DE ou des actions de concept mémorisées dans un ou plusieurs fichiers FN. L'utilisateur visualise un état de la base BDC à une date DE antérieure ou ultérieure à la date courante. Si en visualisant un état futur de la base de données de concepts BDC, l'utilisateur n'est pas satisfait de cet état futur de la base BDC, un ou plusieurs fichiers FN sont consultable suite à une requête transmise au serveur SB. Le contenu de ladite requête conduit le serveur SB à modifier des actions de concept mémorisées dans le fichier FN, ou à réviser la planification de celles-ci en affectant une autre date d'exécution associée, ou encore à annuler des actions de concept qui se sont avérées inadéquates.

Par ailleurs, un troisième ensemble de contrôles de cohérence est réalisé par l'unité centrale de traitement UT lors d'une visualisation d'un état futur de la base.

L'invention décrite ici concerne un procédé et un système informatique pour planifier depuis un terminal des actions relatives à des concepts dans une base de données de concepts liée à un serveur.

Selon une implémentation préférée, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans un dispositif tel qu'un terminal de planification ou un support d'informations. Le programme comporte des instructions de programme qui, lorsque ledit programme est chargé et exécuté dans le dispositif dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon l'invention.

En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur sur ou dans un support d'informations, adapté à mettre en oeuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter le procédé selon l'invention.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage ou support d'enregistrement, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type internet. Alternativement, le support d'informations peut être un circuit intégré

dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé selon l'invention.

Claims (1)

19 REVENDICATIONS

1 - Procédé pour planifier depuis un terminal (TP) des actions relatives à des concepts dans une base de données de concepts (BDC) liée à un serveur (SB), comprenant une sélection (El) dans le terminal d'une action parmi une création, une modification et une suppression de concept, caractérisé en ce qu'il comprend les étapes de: préparer (E211-E212, E221- E222-E223, E23) dans le terminal l'action sélectionnée, attribuer (E3) dans le terminal une date d'exécution (DE) à l'action sélectionnée, transmettre (E5) la date d'exécution attribuée et des données (DO) définissant l'action sélectionnée depuis le terminal au serveur (SB), mémoriser (E6) dans le serveur (SB) la date d'exécution (DE) attribuée en correspondance avec les données (DO) de l'action sélectionnée dans un fichier numérique (FN), et exécuter (E7) l'action sélectionnée à la date d'exécution dans la base de données de concepts.

2 - Procédé conforme à la revendication 1, comprenant en outre les étapes suivantes (E8) dans le serveur: sauvegarder l'état courant de la base à la date courante, générer des états intermédiaires de la base depuis un état courant de la base à une date courante jusqu'à atteindre un état désiré de la base à une date d'exécution sélectionnée en fonction de données de concept lues dans le serveur et respectivement incluant des dates d'exécution intermédiaires entre la date courante et la date d'exécution sélectionnée, et déduire dudit état désiré une représentation de celui-ci à transmettre au terminal.

3 - Procédé conforme à la revendication 1 ou 2, selon lequel, lorsque l'action sélectionnée est une création de concept, l'étape de préparer comprend une détermination (E211-E212) d'un identificateur de concept (IC) à créer et d'attributs de concept.

4 - Procédé conforme à l'une quelconque des revendications 1 à 3, selon lequel, lorsque l'action sélectionnée est une modification de concept, l'étape de préparer comprend une sélection (E221-E222) d'un identificateur de concept à modifier et d'un attribut de concept, et une modification (E223) de l'attribut de concept.

5 - Procédé conforme à la revendication à l'une quelconque des revendications 1 à 4, selon lequel, lorsque l'action sélectionnée est une suppression de concept, l'étape de préparer comprend une sélection (E23) d'un identificateur de concept à supprimer.

6 - Procédé conforme à l'une quelconque des revendications 1 à 5, comprenant une étape de mémoriser (E6) une date de préparation (DP) en correspondance avec l'action sélectionnée dans le fichier numérique (FN).

7 - Procédé conforme à l'une quelconque des revendications 1 à 6, comprenant une modification de la date d'exécution (DE) de l'action sélectionnée après l'étape de mémoriser (E6).

8 - Système de planification d'une base de données de concepts (BDC) liée à un serveur (SB), comprenant un terminal (TP) pour planifier des actions relatives à des concepts dans la base de données de concepts (BDC), le terminal comprenant un moyen (UT) pour sélectionner une action (C, M, S) parmi une création, une modification et une suppression de concept, caractérisé en ce que le terminal (TP) comprend un moyen (MCR, MM, MS) pour préparer l'action sélectionnée, un moyen (MP) pour attribuer une date d'exécution (DE) à l'action sélectionnée, et un moyen (UT) pour transmettre la date d'exécution attribuée et des données (DO) définissant l'action sélectionnée au serveur (SB), et le serveur (SB) comprend un moyen (MEM) pour mémoriser la date d'exécution (DE) attribuée en correspondance avec les données (DO) de l'action sélectionnée dans un fichier numérique (FN) afin d'exécuter l'action sélectionnée à la date d'exécution dans la base de données de concepts.

9 - Système conforme à la revendication 8, le serveur comprend en outre un moyen (MG) pour: sauvegarder l'état courant de la base à la date courante, générer des états intermédiaires de la base depuis un état courant de la base à une date courante jusqu'à atteindre un état désiré de la base à une date d'exécution sélectionnée en fonction de données de concept lues dans le serveur et respectivement incluant des dates d'exécution intermédiaires entre la date courante et la date d'exécution sélectionnée, et déduire dudit état désiré une représentation de celui-ci à transmettre au terminal.

- Terminal de planification d'une base de données de concepts (BDC) liée à un serveur (SB), pour planifier des actions relatives à des concepts dans la base de données de concepts (BDC), et comprenant un moyen (UT) pour sélectionner une action (C, M, S) parmi une création, une modification et une suppression de concept, caractérisé en ce qu'il comprend un moyen (MCR, MM, MS) pour préparer l'action sélectionnée, un moyen (MP) pour attribuer une date d'exécution (DE) à l'action sélectionnée, et un moyen (UT) pour transmettre la date d'exécution attribuée et des données (DO) définissant l'action sélectionnée au serveur (SB), afin que le serveur (SB) mémorise (E6) la date d'exécution (DE) attribuée en correspondance avec les données (DO) de l'action sélectionnée dans un fichier numérique (FN), et exécute (E7) l'action sélectionnée à la date d'exécution dans la base de données de concepts.

11 - Programme d'ordinateur sur un support d'informations pour planifier depuis un terminal (TP) des actions relatives à des concepts dans une base de données de concepts (BDC) liée à un serveur (SB), ledit programme comprenant des instructions de programme qui, lorsque le programme est chargé et exécuté sur ledit support d'informations dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes suivantes de: sélectionner (El) une action parmi une création, une modification et une suppression de concept, préparer (E211-E212, E221E222-E223, E23) l'action sélectionnée, attribuer (E3) une date d'exécution (DE) à l'action sélectionnée, et transmettre (E5) la date d'exécution attribuée et des données (DO) définissant l'action sélectionnée au serveur (SB) afin que le serveur (SB) mémorise (E6) la date d'exécution (DE) attribuée en correspondance avec les données (DO) de l'action sélectionnée dans un fichier numérique (FN), et exécute (E7) l'action sélectionnée à la date d'exécution dans la base de données de concepts.