FR3108747A1 - Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants. - Google Patents

Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants. Download PDF

Info

Publication number
FR3108747A1
FR3108747A1 FR2003082A FR2003082A FR3108747A1 FR 3108747 A1 FR3108747 A1 FR 3108747A1 FR 2003082 A FR2003082 A FR 2003082A FR 2003082 A FR2003082 A FR 2003082A FR 3108747 A1 FR3108747 A1 FR 3108747A1
Authority
FR
France
Prior art keywords
file
data model
description
identifier
digital
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2003082A
Other languages
English (en)
Other versions
FR3108747B1 (fr
Inventor
Philippe RAIPIN
Pierre Obame Meye
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Priority to FR2003082A priority Critical patent/FR3108747B1/fr
Publication of FR3108747A1 publication Critical patent/FR3108747A1/fr
Application granted granted Critical
Publication of FR3108747B1 publication Critical patent/FR3108747B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]

Landscapes

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

Abstract

L’invention concerne un procédé de gestion d’un fichier numérique de description d’un modèle de données, ledit fichier comprenant des éléments de description dudit modèle de données. Ledit procédé comprend :- une obtention (22) d’un identifiant dudit fichier par génération d’une empreinte numérique desdits éléments de description du modèle de données, et- un stockage (24) dudit fichier à au moins une adresse de stockage, ladite adresse de stockage étant associée audit identifiant. FIGURE 3

Description

Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants.
Domaine technique de l'invention
Le domaine de l’invention est celui du stockage de modèles de données ou d’informations dans des fichiers numériques. Plus précisément, l’invention concerne une technique de gestion de l’identification, de l’accès à de tels fichiers et de l’utilisation des modèles de données qu’ils contiennent.
Art antérieur
Le Web sémantique, ou toile sémantique, est une extension du Web standardisée par le World Wide Web Consortium (W3C). Un tel standard encourage l'utilisation de formats de données et de protocoles d'échange normés sur le Web, en s'appuyant sur un modèle de type Resource Description Framework (RDF). Selon le W3C, le Web sémantique fournit un modèle qui permet aux données d'être partagées et réutilisées entre plusieurs applications, entreprises et/ou groupes d'utilisateurs.
Dans le web sémantique, mais aussi dans le domaine de l’intelligence artificielle, le génie logiciel et plus généralement l’informatique, on considère un modèle de données particulier appelé ontologie. L'ontologie constitue en soi un modèle de données représentatif d'un ensemble de concepts dans un domaine, ainsi que des relations entre ces concepts. Autrement dit, une ontologie donne du sens aux données, aux relations entre elles et définit des contraintes sur leur utilisation. Elle permet aux programmes informatiques qui ont connaissance de cette ontologie de traiter correctement les données qu’elle décrit. D’une certaine manière, on peut dire que l’« ontologie est aux données ce que la grammaire est au langage ».
Les concepts définis par une ontologie sont par exemple organisés dans un graphe dont les relations peuvent être :
- des relations sémantiques ;
- des relations de subsomption.
Les ontologies décrivent généralement des:
- individus : les objets de base ;
- classes : ensembles, collections, ou types d'objets1 ;
- attributs : propriétés, fonctionnalités, caractéristiques ou paramètres que les objets peuvent posséder et partager ;
- relations : les liens que les objets peuvent avoir entre eux ;
- événements : changements subis par des attributs ou des relations ;
- méta-classes : des collections de classes qui partagent certaines caractéristiques.
Les ontologies sont généralement décrites dans un langage de type « Ontology Web Language ». Elles sont identifiées et localisées sur Internet grâce à une adresse de type URL (pour « Uniform Resource Locator », en anglais). Plus précisément, on utilise une adresse IRI (pour « Internationalized Resource Identifier », en anglais), qui présente l’avantage de prendre en compte les divers alphabets utilisés dans les différentes langues du monde, contrairement aux adresses URL qui sont limitées au jeu de caractères ASCII (les nombres, les lettres de « a » à « z » sans accent ni autre diacritique, éventuellement en majuscules, plus quelques signes).
Une URL ou IRI est une adresse complète qui permet d'accéder à un espace de stockage d’un fichier comprenant une ontologie. Une telle URL contient un nom de domaine, ainsi que d'autres éléments permettant de localiser le fichier en question.
Un inconvénient est que le nom de domaine, qu’il soit public ou privé, peut être perdu et de ce fait l’accès à l’ontologie devenir indisponible. Dans ce cas, il est nécessaire d’obtenir une copie du fichier comprenant l’ontologie pour pouvoir continuer à l’utiliser. Le fichier copié pourra alors être de nouveau accessible, mais via une autre IRI, ce qui implique de mettre à jour les applications logicielles et programmes informatiques qui l’utilisent.
Un autre inconvénient est que si le propriétaire du nom de domaine modifie le contenu de l’ontologie, son IRI ne s’en trouve pas pour autant changée, ce qui fait que les applications logicielles et programmes informatiques qui l’utilisent sans être informés de ces modifications peuvent être exposés à des incohérences mettant en péril leur bonne exécution et donc la fonction qu’ils rendent.
Il existe des méthodes pour indiquer qu’une ontologie est disponible sous une nouvelle version, mais du fait qu’elles sont à la charge du concepteur, elles ne sont pas souvent mises en œuvre. Au surplus, quand elles le sont, il n’est pas pour autant facile pour un utilisateur de trouver la bonne version de l’ontologie à partir des données de description qu’elle contient. En effet, les concepts de classes de l’ontologie sont généralement inchangés d’une version à l’autre et il est souvent nécessaire d’examiner en détails toutes les données de description des différentes versions disponibles pour déterminer la version dont on dispose.
Il existe donc un besoin d’une solution de gestion des ontologies qui soit plus efficace et, en particulier, qui garantisse un accès et une utilisation plus sûrs et maîtrisés de ces ontologies pour le traitement informatique de données.
L’invention vient améliorer la situation.
Présentation de l'invention
L’invention répond à ce besoin en proposant un procédé de gestion d’un fichier numérique de description d’un modèle de données, ledit fichier comprenant des éléments de description dudit modèle de données.
Ledit procédé comprend :
- une obtention d’un identifiant dudit fichier par génération d’une empreinte numérique desdits éléments de description du modèle de données, et
- un stockage dudit fichier à au moins une adresse de stockage, ladite adresse de stockage étant associée audit identifiant.
Ainsi l’invention repose sur une approche tout à fait nouvelle et inventive de la gestion du stockage d’un fichier de description d’un modèle de données et de l’accès à ce fichier. En effet, une telle technique de gestion du stockage d’un fichier de description d’un modèle de données repose sur la génération d’un identifiant unique du fichier de description d’un modèle de données, basé sur les éléments de description qu’il contient.
De la sorte, et contrairement à l’art antérieur, cet identifiant change dès qu’un élément de description du modèle est modifié dans le fichier ce qui facilite le suivi des modifications apporté au modèle de données et donc une meilleure gestion de son évolution dans le temps. En outre, le fait d’associer l’identifiant à l’adresse de stockage du fichier de description du modèle de données, par exemple dans une table d’association clé-valeur, permet un accès à ce fichier à partir de son identifiant, ce qui garantit d’obtenir la bonne version du modèle de données., indépendamment du nom du modèle de données ou du fichier qui le décrit
En outre, le fait de décorréler l’identification d’un fichier de description de son adresse de stockage rend possible une duplication de ce fichier et un stockage des copies à des adresses de stockage distinctes éventuellement gérées par des serveurs de fichiers distincts. De cette manière, un accès rapide au fichier de description du modèle de données est garanti même lorsque le nombre de requêtes d’accès augmente, ce qui permet un passage à l’échelle.
Selon un aspect de l’invention, le modèle de description comprenant des éléments de description structurants et des éléments de description non structurants, l’obtention d’un identifiant comprend une élimination des éléments de description non structurants, un tri des éléments de description dudit modèle selon au moins une règle prédéterminée et une génération de l’empreinte numérique des éléments de description triés.
Un avantage est que l’empreinte générée est la même pour deux fichiers de description de modèles de données comprenant les mêmes éléments de description structurants, quel que soit l’ordre adopté par le concepteur du modèle pour lister ces éléments de description du modèle, ce qui garantit une reproductibilité de l’empreinte. Les éléments non structurants appelés aussi éléments de description non sémantiques, ne contribuent pas à la définition proprement dite du modèle, comme par exemple les commentaires et peuvent donc être éliminés.
Un autre avantage est que seules les données structurantes pour le modèle de données sont prises en compte pour générer l’empreinte numérique du fichier, à l’exclusion des commentaires ou autres données, ce qui garantit encore un niveau plus élevé de reproductibilité de l’empreinte générée et donc une gestion encore plus sûre des modifications apportées à un modèle de données et donc des différentes versions de fichiers de description d’un modèle de données.
Selon un autre aspect de l’invention, l’empreinte numérique ID est générée à l’aide d’une fonction de hachage.
Un avantage est qu’avec la valeur de hachage (le hash), on peut discriminer deux modèles de données apparemment proches, ce qui peut être notamment utilisé pour garantir l’intégrité d’un modèle, autrement dit sa non modification par un tiers. Dans ce cas, on peut mettre en œuvre une vérification d’identifiant qui prend en entrée le modèle de données et produit en sortie l’empreinte correspondante. Si elle est identique à l’identifiant du modèle, alors celui-ci est intègre.
Selon encore un autre aspect de l’invention, le procédé comprend un renommage du modèle de données décrit dans le fichier, indépendant de ladite adresse de stockage.
Contrairement à l’art antérieur qui désigne classiquement un modèle de données par l’adresse de stockage de son fichier, de type URL, l’invention propose avantageusement de lui attribuer un nouveau nom qui est décorrélé de son adresse de stockage. Ceci permet d’éviter qu’une mise à jour du fichier de description d’un modèle de données vienne écraser les versions précédentes de ce modèle. Les versions successives de ce modèle peuvent ainsi être stockées dans différents fichiers et accédées par une seule requête basée sur le nom du modèle.
Selon encore un autre aspect, le modèle est nommé à l’aide d’une ressource de nommage présentant une syntaxe d’adresse de localisation.
Avantageusement, une ressource de type URN (pour “Uniform Ressource Name”, en anglais) est utilisée. Elle comprend une syntaxe de chaîne de caractères et identifie une ressource telle qu’un document, une image, un enregistrement sonore, indépendamment de sa localisation ou de son accessibilité. Cette syntaxe est normalisée par le document RFC 2141 URN Syntax publié en 1997 par l'Internet Engineering Task Force. Un avantage est qu’une telle syntaxe s’apparente à celle des URL et qu’elle est donc interprétée correctement par la plupart des outils de manipulation d’ontologies, sans mise à jour préalable.
Selon encore un autre aspect, le procédé met en œuvre un traitement d’une requête d’obtention dudit fichier de description en provenance d’un équipement client, ladite requête comprenant ledit identifiant du fichier, ledit traitement comprenant l’obtention de l’adresse de stockage associée à l’identifiant dans ladite table, et une transmission audit équipement client d’une réponse comprenant ledit fichier ou l’adresse de stockage dudit fichier.
Avec l’association unique proposée par l’invention, l’équipement client accède au bon fichier de description du modèle de données sans erreur possible sur la version. Le serveur de fichier peut répondre en envoyant directement le fichier au client si ce fichier est stocké localement ou en lui transmettant son adresse de stockage si elle est accessible depuis un réseau de télécommunications public.
L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de gestion selon l’invention, tel que décrit précédemment, lorsqu’il est exécuté par un processeur.
L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés les programmes d’ordinateur tels que décrits ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, 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 clé USB ou un disque dur.
D'autre part, un tel support d'enregistrement 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, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargés sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement 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é de gestion précité.
L’invention concerne aussi un dispositif de gestion d’un fichier de description d’un modèle de données, ledit fichier comprenant des données de description dudit modèle de données.
Ledit dispositif est configuré pour :
- obtenir un identifiant du fichier de description du modèle de données par génération d’une empreinte numérique desdits éléments de description compris dans ledit fichier, et
- stocker ledit fichier à au moins une adresse de stockage, ladite adresse de stockage étant associée audit identifiant.
Avantageusement, ledit dispositif est configuré pour mettre en œuvre le procédé de gestion d’un fichier de description d’un modèle de données précité, selon ses différents modes de réalisation.
Avantageusement, ledit dispositif est intégré dans un équipement serveur de fichiers, configuré pour se connecter à un réseau de communication et pour gérer le stockage et l’accès à des fichiers de description de modèle de données. Il s’agit par exemple d’un équipement dédié ou bien d’un équipement terminal, tel que par exemple téléphone intelligent ou un ordinateur.
Le serveur de fichier, le dispositif de gestion d’un fichier de description d’un modèle de données et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé précité selon les différents modes de réalisation de la présente invention.
Corrélativement, l’invention concerne aussi un procédé d’utilisation d’un fichier de description d’un modèle de données par un équipement client connecté à un réseau de télécommunications et configuré pour exécuter un programme informatique.
Ledit procédé met en œuvre :
- l’obtention dans ledit programme informatique, d’une instruction comprenant un élément de description d’un modèle de données, ledit élément de description étant associé dans ladite instruction à un identifiant dudit fichier de description dudit modèle de données, ledit identifiant ayant été obtenu par génération d’une empreinte numérique des éléments de description compris dans le fichier de description dudit modèle ;
-une obtention dudit identifiant à partir de ladite instruction ;
- une résolution d’une adresse de localisation d’un équipement serveur stockant ledit fichier, à partir dudit identifiant;
- une obtention du fichier par transmission d’une requête à l’adresse de localisation résolue, ladite requête comprenant ledit identifiant ; et
- une exécution de ladite instruction conformément au modèle de données compris dans le fichier obtenu.
Ainsi, l’invention propose une approche tout-à-fait nouvelle et inventive de l’utilisation d’un modèle de données par un programme informatique. En effet, dès lors qu’un élément de description de ce modèle est utilisé dans ce programme informatique en association avec une empreinte numérique identifiant de façon unique le fichier de description de ce modèle de données, la solution de traitement proposée consiste à exploiter cet identifiant pour accéder au bon fichier comprenant la bonne version du modèle, indépendamment du nom utilisé pour désigner le modèle de description de données dans le programme informatique. De la sorte, le programme informatique s’exécute conformément aux règles et relations entre concepts envisagées par le concepteur pour ce modèle, sans risque d’incohérences.
Selon un aspect de l’invention, ce procédé met en œuvre une vérification de l’identifiant à partir du fichier obtenu, par génération d’une empreinte numérique des éléments de description du modèle de données qu’il contient et comparaison de l’empreinte numérique générée à l’identifiant (ID).
Si l’identifiant et l’empreinte coïncident, alors le fichier est intègre et les éléments de description du modèle qu’il contient peuvent être utilisés en toute sécurité.
Selon un autre aspect de l’invention, ladite instruction comprend ledit élément de description précédé d’au moins une partie de l’identifiant du fichier de description.
Un avantage de préfixer l’élément de description du modèle de données par l’empreinte numérique de ce modèle est que cette empreinte numérique est obtenue très facilement et qu’elle ne masque pas l’élément de description utilisé.
L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé d’utilisation d’un fichier de description d’un modèle de données selon l’invention, tel que décrit précédemment, lorsqu’il est exécuté par un processeur.
L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés les programmes d’ordinateur tels que décrits ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, 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 clé USB ou un disque dur.
D'autre part, un tel support d'enregistrement 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, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargés sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement 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é d’utilisation précité.
L’invention concerne aussi un dispositif d’utilisation d’un fichier de description d’un modèle de données par un équipement client connecté à un réseau de télécommunications et configuré pour exécuter un programme informatique, caractérisé en ce qu’il est configuré pour :
- obtenir dudit programme informatique au moins une instruction comprenant un élément de description d’un modèle de données, ledit élément de description étant associé dans ladite instruction à un identifiant du fichier de description dudit modèle de données, ladite empreinte numérique ayant été générée à partir des éléments de description compris dans ledit fichier ;
-résoudre une adresse de localisation d’un équipement serveur stockant ledit fichier à partir dudit identifiant ;
- obtenir ledit fichier par transmission d’une requête à l’adresse de localisation résolue, ladite requête comprenant ledit identifiant; et
- exécuter ladite instruction conformément au modèle de données compris dans le fichier numérique obtenu.
Avantageusement, ledit dispositif est configuré pour mettre en œuvre le procédé d’utilisation d’un fichier de description d’un modèle de données précité, selon ses différents modes de réalisation.
Avantageusement, ledit dispositif est intégré dans un équipement client, configuré pour se connecter à un réseau de communication pour requérir l’accès à un fichier de description de modèle de données en vue de son utilisation dans un programme informatique. Il s’agit par exemple d’un objet connecté, tel qu’un capteur, un terminal d’utilisateur tel qu’un ordinateur ou un téléphone mobile de type téléphone intelligent.
L’équipement client, le dispositif d’utilisation d’un fichier de description d’un modèle de données et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé précité selon les différents modes de réalisation de la présente invention.
Corrélativement, l’invention concerne enfin un système de gestion d’un fichier de description d’un modèle de données dans un réseau de télécommunications. Un tel système comprend, connectés audit réseau, au moins un équipement serveur précité configuré pour stocker ledit fichier à une adresse de stockage en association avec un identifiant de ce fichier, au moins un serveur de résolution d’adresses configuré pour résoudre une adresse de localisation dudit équipement serveur et au moins un équipement client précité, configuré pour requérir ledit fichier auprès dudit au moins un équipement serveur à l’aide de son identifant et pour utiliser ledit fichier dans un programme informatique.
Brève description des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
: présente un exemple d’architecture d’un système de gestion d’un fichier de description d’un modèle de données connecté à un réseau de télécommunications selon un mode de réalisation de l’invention ;
: illustre de façon schématique la structure matérielle d’un équipement serveur intégrant un dispositif de gestion d’un fichier de description d’un modèle de données selon un mode de réalisation de l’invention ;
: décrit sous forme d’un logigramme les étapes d’un procédé de gestion du stockage d’un fichier de description d’un modèle de données, selon un exemple de réalisation de l’invention ;
: détaille, pour ce procédé, l’étape d’identification du modèle de données contenu dans le fichier numérique selon un exemple de réalisation de l’invention ;
: illustre de façon schématique un exemple de structure de table associant un identifiant d’un fichier de description d’un modèle de données à une adresse de stockage selon un exemple de réalisation de l’invention ;
: illustre de façon schématique la structure matérielle d’un équipement serveur intégrant un dispositif de gestion d’un fichier de description d’un modèle de données selon un mode de réalisation de l’invention ;
: décrit sous forme d’un logigramme les étapes d’un procédé d’utilisation d’un fichier de description d’un modèle de données, selon un exemple de réalisation de l’invention ;
: illustre de façon schématique la structure matérielle d’un dispositif de gestion d’un fichier de description d’un modèle de données selon un autre mode de réalisation de l’invention ; et
: illustre de façon schématique la structure matérielle d’un dispositif d’utilisation d’un fichier de description d’un modèle de données selon encore un autre mode de réalisation de l’invention.
Description détaillée de l’invention
Le principe général de l’invention repose sur la génération d’une empreinte numérique unique à partir des éléments de description d’un modèle de données contenu dans un fichier numérique, sur l’identification du modèle de données à l’aide de cette empreinte et sur le stockage du fichier de description de ce modèle à une adresse de stockage, en association avec cet identifiant.
L’invention concerne aussi une utilisation de ce fichier par un équipement client pour l’exécution d’un programme informatique comprenant au moins une instruction comprenant un élément de description du modèle de données contenu dans ce fichier. Tout ou partie de l’identifiant du modèle étant inséré dans l’instruction avec l’élément de données, l’invention propose de l’exploiter pour obtenir le fichier de description de données correspondant.
De la sorte, le modèle de données auquel se référer pour utiliser l’élément de description en question est identifié sans ambiguïté, ce qui permet une exécution conforme et sécurisée du programme informatique par l’équipement client.
Cette invention trouve de nombreuses applications par tout type d’équipement client connecté à un réseau de télécommunications et mettant en œuvre des programmes informatiques tels que des applications logicielles pour fonctionner et rendre les services pour lesquels il a été conçu. Elle s’applique particulièrement aux objets connectés faisant partie de l’internet des objets ou IoT (pour « Internet of Things », en anglais), tel qu’un capteur, une montre connectée et plus généralement tout type d’équipement terminal d’un utilisateur, tel qu’un téléphone intelligent, une tablette, un ordinateur portable, etc.
On présente désormais, en relation avec lafigure 1, une architecture d’un système de gestion 10 d’un fichier de description d’un modèle de données dans un réseau de télécommunications distant RT selon un mode de réalisation de l’invention. Un tel système 10 comprend au moins un équipement serveur de fichiers SF1 connecté au réseau de télécommunications RT. Ce serveur de fichiers est configuré pour stocker des fichiers de description de modèles de données, comme par exemple le fichier FD. On note que la figure 1 présente un deuxième équipement serveur de fichiers SF2 et que ce serveur est configuré pour stocker lui aussi une copie du fichier de description d’un modèle de données FD.
Le système comprend en outre au moins un équipement serveur de résolution d’adresses SR configuré pour résoudre une adresse de localisation du fichier de description FD à partir d’un identifiant ID du modèle de données qu’il décrit. Ce serveur SR est lui aussi connecté au réseau de télécommunications RT.
On considère aussi des équipements clients, tels que des téléphones intelligents 1, 5 (pour «smartphone », en anglais), une tablette 2, un ordinateur personnel 3, configurés pour se connecter audit réseau distant RT via un réseau d’accès, tel qu’un réseau local LAN ou un réseau cellulaire RC. Par exemple le téléphone intelligent 1, la tablette 2 et l’ordinateur 3 sont connectés par un lien sans fil, par exemple de type Wifi, au réseau local LAN opéré par un point d’accès AP1, tel qu’une passerelle résidentielle, et le terminal intelligent 5 est connecté au réseau distant RT via le réseau cellulaire RC.
On considère enfin un capteur 4, tel qu’un capteur de température, par exemple connecté au réseau cellulaire RC. Bien sûr, ceci n’est qu’un exemple illustratif, il pourrait tout aussi bien être connecté au réseau local LAN.
Lafigure 2représente une architecture de l’équipement serveur SF1, selon un mode de réalisation de l’invention. Selon cet exemple de réalisation de l’invention, l’équipement serveur SF1 comprend un dispositif 100 de gestion d’un fichier de description FD d’un modèle de données MD selon l’invention, configuré pour identifier le modèle de données contenu dans ce fichier numérique et stocker ce fichier à une adresse de stockage, en association avec cet identifiant. Ce fichier FD peut être enregistré par exemple dans une mémoire MEM du serveur de fichiers SF1ou dans une mémoire distante, par exemple organisée comme une base de données, à laquelle le serveur de fichiers SF1 peut accéder. Cette mémoire distante peut être intégrée à un autre serveur de fichier, tel que le serveur SF2.
En particulier, le dispositif de gestion 100 comprend un module d’obtention OBT FD d’un fichier FD de description d’un modèle de données MD, un module GN ID de génération d’un identifiant du modèle de données MD à partir des données de description contenues dans le fichier FD et un module de stockage STC FD du fichier nommé à ladite adresse de stockage, en association avec ledit identifiant. Le dispositif 100 met ainsi en œuvre le procédé de gestion selon l’invention qui sera détaillé ci-après en relation avec lafigure 3.
Avantageusement, le dispositif 100 comprend en outre un module RNM de renommage du fichier de description FD, un module de traitement TRT RQ d’une requête d’accès au modèle de description de données en provenance d’un équipement client, ladite requête comprenant l’identifiant du et un module de transmission d’une réponse à ladite requête comprenant ledit fichier.
On présente désormais, en relation avecla figure 3, sous une forme de logigramme, un premier exemple de mise en œuvre d’un procédé de gestion d’un fichier de description d’un modèle de données selon un mode de réalisation de l’invention.
Au cours d’une étape20, un fichier de description FD d’un modèle MD de données numériques est obtenu. Il contient des éléments de description ED du modèle. Ces éléments de description ED sont analysés pour générer en21une empreinte numérique ID du fichier FD et il est stocké en23à ladite adresse de stockage @ST, qui peut être locale ou distante, en association avec ledit identifiant.
Avantageusement le modèle de données considéré définit une ontologie, par exemple une ontologie informatique destinée à être utilisée par le capteur de températures 4 ou tout autre équipement client 1, 2, 3 ou 5. A cet égard, l’annexe 1 présente un exemple de fichier de description d’un modèle de données nommé « temperature.owl ». Cette ontologie comprend trois concepts qui sont une classe « Sensor », une classe « TemperatureSensor » sous-classe de la classe « Sensor » et une propriété nommée « id » destinée à s’appliquer à des objets de la classe « Sensor ». On notera que cette propriété « id » s’applique aussi bien aux instances de la classe « Sensor » qu’à celles de sa sous-classe « TemperatureSensor ».
L’ontologie « temperature.owl » est écrite dans un langage standardisé, en l’espèce le langage Ontology Web Langage (OWL).
En relation avec lafigure 4, on détaille maintenant l’étape21de génération d’une empreinte numérique ID du modèle de données MD contenu dans le fichier de description FD selon un mode de réalisation de l’invention. Dans l’exemple illustré par cettefigure 4, on présente un premier fichier FD1 d’entrée et un deuxième fichier FD2 d’entrée. Ils décrivent tous les deux la même ontologie, mais de façon différente, par exemple parce qu’ils ont été créés par deux personnes distinctes ou à partir d’outils de création de modèles de données différents.
La génération 21 de cette empreinte numérique ID comprend avantageusement:
- un reformatage 210 du fichier de description FD1, FD2 dans un format standard prédéterminé ;
- un nettoyage 211 du fichier FD1r, FD2r de description du modèle de données reformaté ;
- un tri 212 des éléments de description ED contenus dans ce fichier FD1r, FD2r ; et
- un calcul 213 de l’empreinte numérique ID à partir des éléments de description triés.
Cette étape de reformatage 210 peut être réalisée en utilisant le format du fichier source ou en convertissant le fichier d’entrée dans un autre format prédéfini. Quel que soit le format de sortie choisi, elle consiste à appliquer strictement les conventions bien définies de ce format. En effet, il arrive souvent qu’un développeur ou un créateur d’ontologie ne respecte pas à la lettre ces conventions, et utilise à la place sa propre règle d’indentation des données de description du modèle de données. Le reformatage sert donc à modifier la forme du fichier de description de sorte à le rendre conforme aux conventions associées à son format.
Optionnellement, le fichier d’entrée peut être converti dans un autre format choisi parmi plusieurs formats dits de sérialisation texte, connus en soi. On cite à titre d’exemples, les format RDF/XML, Turtle, Json-LD, etc…
Dans l’exemple de réalisation considéré, Le ficher « temperature.owl » est converti au format RDF/XML présenté enannexe 1.
Chaque format de sérialisation texte présente des avantages et utilise une convention qui lui est propre, par exemple pour indenter les éléments de description du modèle de données ou identifier les données non sémantiques, comme les commentaires.
Dans le format « Turtle » par exemple, une ligne de commentaire commence par un caractère#et prend fin avec la ligne courante. Selon le format RDF/XML, les commentaires sont encadrés par une balises de début<!—et une balise de fin—>. De la sorte, tous les caractères entre ces deux balises sont considérés comme des commentaires.
Chaque format de sérialisation est plus ou moins concis. Par exemple, le format Turtle est réputé plus concis que le format RDF/XML.
On note toutefois que l’invention est indépendante du format de sérialisation utilisé.
Le nettoyage ou élimination211consiste ensuite à supprimer les données non sémantiques contenues dans le fichier, c’est-à-dire les données qui ne contribuent pas à définir le modèle et ne sont pas utilisables en tant que telles par un programme informatique, tels que les commentaires.
Une fois ces éléments identifiés, ils sont supprimés du fichier de description reformaté FD1r, FD2r.
Ainsi, selon un mode de réalisation, on peut regrouper les étapes de reformatage 210 et de nettoyage 211 et les représenter comme suit:
cleaned_ontology = clean(format, « temperature.owl »)
où :
clean désigne la fonction qui exécute l’étape de nettoyage ;
« temperature.owl »désigne le fichier de description du modèle de données d’entrée ;
format: le format de sérialisation, par exemple conforme à la norme Turtle, RDF/XML etc
cleaned_ontology: le fichier de description FD1r, FD2r reformaté au format choisi ;
A titre illustratif, l’annexe 2 présente un exemple de fichier , nommé cleaned_temperature.ttl, reformaté au format Turtle (extension .ttl) puis nettoyé de ses données non sémantiques selon ce mode de réalisation de l’invention.
A cet égard, on notera que les lignes qui comprennent le champ « comment » ne sont pas des lignes de commentaires. En effet, comme déjà évoqué, selon le format Turtle, les lignes de commentaires commencent par la balise #.
Ce fichier nettoyé est ensuite utilisé dans l’étape212de tri des éléments de description sémantiques.
Lors de la création d’un modèle de données, comme par exemple une ontologie, il n’y a pas d’ordre à respecter pour déclarer des concepts. Autrement dit, l’ordre des concepts n’influe pas sur la sémantique de l’ontologie. Par exemple, dans l’exemple du fichier « temperature.owl » de l’annexe 1, les propriétés sont déclarées avant les classes, mais l’ordre inverse ne changerait en aucun cas la sémantique de l’ontologie. En revanche, on obtiendrait un fichier sérialisé différent en termes d’octets.
Le tri212vise donc à passer d’une première représentation de l’ontologie, par exemple selon le fichier reformaté et nettoyé « cleaned_temperature.ttl », à une deuxième représentation, triée et unique pour tous les fichiers de description de cette même ontologie.
Cette étape de tri peut être représentée comme suit:
sorted_ontology = sort(algo, strategy, sortOrder, cleaned_temperature.ttl)
où
- sort désigne la fonction qui exécute la fonction de tri ;
- cleaned_ontology.ttl: le fichier à trier ;
- algo: l’algorithme de tri. A cet égard, il convient de noter que l’algorithme de tri utilisé n‘a pas d’influence sur le résultat final. En effet, n’importe quel algorithme de tri peut être utilisé, quelle que soit la technologie sous-jacente. Par exemple, des algorithmes de type « merge sort », tri à bulle, etc sont tout-à-fait adaptés. Cependant, les algorithmes peuvent consommer plus ou moins de ressources de calcul et de mémoire, être plus ou moins rapides, ou encore plus ou moins échelonnables. Par exemple, certains algorithmes comme « external merge sort » sont capables de trier des fichiers plus grands que la mémoire disponible localement en ayant recours à une autre mémoire, telle qu’un disque dur.
Le choix d’un algorithme particulier pourra donc être fait notamment en fonction de la taille du fichier d’entrée, des ressources de calcul et de mémoire RAM (pour « Random Access Memory », en anglais) disponibles;
- strategy: la stratégie de tri à effectuer. En effet, plusieurs stratégies de tri sont possibles. On peut par exemple trier les éléments de description du fichier ligne par ligne ou caractère par caractère, par ordre alphabétique etc ;
- sortOrder: l’ordre de tri à savoir si le tri est ascendant ou descendant ;
- sorted_ontology: le résultat du tri, à savoir le fichier de description du modèle de données trié FD1rs, FD2rs.
A titre d’exemple illustratif, l’annexe 3présente un fichier trié nommé sorted_temperature.txt, résultat d’un tri descendant ligne par ligne et par ordre alphabétique.
Selon ce mode de réalisation de l’invention, un identifiant ou empreinte numérique ID de l’ontologie est calculé en213à partir du fichier trié obtenu précédemment. Cette étape peut être représentée comme suit :
ID = computeID(algo, sorted_ontology)
où:
- computeID: la fonction qui implémente le calcul de l’identifiant ;
- algo: l’algorithme utilisé par cette fonction pour calculer l’identifiant. Cet algorithme peut être n’importe quelle fonction de hachage connue en soi, telle que par exemple md5, sha1, sha256, etc.
- sorted_ontology: le fichier trié présenté en entrée ;
- ID: l’empreinte numérique générée par l’algorithme pour le fichier d’entrée décrivant l’ontologie temperature.owl.
Par exemple, l’empreinte numérique obtenue pour l’ontologie temperature.owl avec l’algorithme sha1 et à partir du fichier sorted_ontology est 929e308ae7038bd46ac3fb4dc2188a776501b002.
A l’issue de cette étape213de génération d’une empreinte numérique ID, on obtient, comme illustré par lafigure 4, un identifiant ID1 pour le premier fichier d’entrée FD1 et un deuxième identifiant ID2, distinct de ID1, pour le deuxième fichier d’entrée FD2.
Renommage d’un fichier de description
Classiquement, selon l’art antérieur pour donner un nom à un modèle de données ou une ontologie, on utilise une adresse de type IRI, mais l’inconvénient est qu’elle indique avant tout l’adresse de stockage de son fichier de description FD. A la place, l’invention propose de recourir à d’autres moyens de nommage, distincts et indépendants de la véritable adresse de stockage de ce fichier.
Par exemple, on nomme le modèle de données à l’aide d’une ressource de type URN (pour « Uniform Resource Name », en anglais) ou d’un autre type, telle que par exemple selon la norme utilisée par le langage Java pour nommer des packages ou par d’autres langages de programmation connus en soi.
Optionnellement, selon un mode de réalisation de l’invention, l’ontologie « temperature.owl » est renommée en 22 à l’aide de la ressource URN suivante :
urn:com.project.ontology.temperature.owl.
Cette URN n’est pas une adresse. Elle ne permet pas de localiser le fichier de description du modèle de données qui porte son nom. Néanmoins, elle respecte une syntaxe particulière qui présente l’avantage de présenter les mêmes caractéristiques que celles des ressources IRI utilisées selon l’art antérieur pour désigner un modèle de données. Un avantage est de rendre cette structure de nom compatible avec les outils existants de création et de manipulation d’ontologies (pour « parsing », en anglais). A titre d’exemple, on cite l’outil owl.api. Autrement dit, les outils existants restent utilisables sur les modèles de données lorsqu’ils sont désignés par le nom qui leur a été attribué en 22 selon l’invention.
Une fois renommée urn:com.project.ontology.temperature.owl, l’ontologie “temperature.owl » peut être décrite par plusieurs fichiers distincts, identifiés chacun par leur propre identifiant et stockés à des adresses de stockage distinctes, associées respectivement aux identifiants de chacun des fichiers de description.
Comme précédemment évoqué, cette adresse de stockage @ST correspond à un espace mémoire d’un support de stockage géré par le serveur de fichier SF1, SF2. Ce support de stockage peut être local, comme par exemple une mémoire MEM, par exemple une mémoire flash ou un disque dur de type SSD (pour « Solid State Drive », en anglais), qui peut être de type NVME (pour « Non Volatile Memory Express », en anglais) pour un accès rapide aux informations stockées en mémoire. etc.
En variante, le support de stockage peut aussi être distant, c’est-à-dire externe au serveur de fichiers, mais accessible par le réseau de télécommunications. Selon une première option, il s’agit d’un support de stockage mis à disposition par un équipement informatique distant appartenant à un même réseau privé que le serveur de fichier SF1, SF2, comme par exemple un serveur de stockage en réseau de type NAS (pour « Network Attached Storage », en anglais). Selon une deuxième option, le support distant est mis à disposition dans un réseau de télécommunication public, par exemple selon la technologie connue en soi de l’informatique du nuage (pour « cloud computing », en anglais) ou sur un serveur mettant en œuvre le protocole de communication FTP (pour « File Transfer Protocol », en anglais), destiné au partage de fichiers sur un réseau de type TCP/IP ou encore par l’intermédiaire d’un réseau de pairs ou P2P (pour « Peer to Peer », en anglais).
Avantageusement et comme illustré par lafigure 5, le serveur de fichier SF1 construit une table T comprenant des entrées E1, E2,…, EN, avec N entier non nul, chaque entrée associant l’empreinte numérique ID1, ID2, …, IDN d’un fichier FD1, FD2,…,FDN de description d’un modèle de données à son adresse de stockage @ST1, @ST2,..,@STN. Cette table T d’association est destinée être utilisée par le serveur de fichiers SF1, SF2 pour traiter une requête REQ d’accès à une ontologie reçue en provenance d’un équipement client et comprenant l’empreinte numérique ID du fichier requis.
Une telle table d’association peut être implémentée de plusieurs manières. Par exemple, elle prend la forme d’un fichier de type Json qui associe une clé, en l’espèce l’identifiant ID du fichier FD de description du modèle de données, à une valeur, ici l’adresse de stockage @ST de ce fichier.
En variante, la table T présente la structure d’une base de données, c’est-à-dire que les données stockées sont indexées de façon à être accessibles facilement, par exemple à partir de la valeur de l’identifiant ID, sans avoir à parcourir tous les enregistrements de la base de données.
Selon une autre variante, la table T prend la forme d’une table de hachage. Il s’agit d’une table dont les entrées ne sont pas indexées par un entier comme c’est le cas dans une table classique, mais par la valeur résultant du hachage de l’identifiant ID par une fonction de hachage prédéterminée. Ainsi l’index obtenu pointe directement sur la zone mémoire où est enregistrée l’adresse de stockage @ST associée à l’identifiant ID. La position des paires identifiant ID – adresse de stockage @ST étant pseudo aléatoire, cette structure n’est pas adaptée au feuilletage (pour « browsing », en anglais) de données voisines. Néanmoins, ce type de table est utile lorsque le nombre de paires est très important.
Ainsi, si un équipement client souhaite obtenir une ontologie à partir de son empreinte numérique ID, il transmet par exemple une requête de type http GET au serveur de fichiers SF1, SF2 en précisant l’empreinte numérique ID du fichier de description de l’ontologie souhaité. A titre d’exemple, on présente ci-dessous une requête utilisant l’outil url en ligne de commande :
curl https://ontologies.org/download?footprint=929e308ae7038bd46ac3fb4dc2188a776501b002.
Dans l’exemple de requête ci-dessus, on utilise une interface en ligne de commande, appelée cURL, qui permet de récupérer le contenu d'une ressource désignée à l'aide d'une URL et accessible par un réseau informatique.
Avantageusement, le serveur de fichiers SF1, SF2 peut préalablement extraire des informations du fichier FD de description de l’ontologie à partir d’outils standards de manipulation de modèles de données de type OWL, connus en soi, tels que l’application OWL API déjà évoqué, et indexer les informations extraites de sorte à fournir aux utilisateur un moteur de recherche sur les fichiers de description de modèles de données dont il gère le stockage. De telles informations comprennent par exemple, le nom de l’ontologie, son titre, le nom de son créateur, etc.
Il devient alors possible de requérir une ontologie en transmettant au serveur de fichiers SF1, SF2 la requête RQ suivante :
curl https://ontologies.org?name=urn%3Acom.project.ontology.temperature.owl
En retour, on obtient les fichiers de description de toutes les ontologies disponibles ayant pour nom nom urn:com.project.ontology.temperature.owl.
A cet égard, on note que, selon les cas, la réponse du serveur de fichiers SF1, SF2 à la requête d’un équipement client peut prendre au moins les deux formes suivantes :
- la réponse RSP comprend le ou les fichiers de description FD requis. C’est notamment le cas, lorsqu’il est stocké localement dans le serveur de fichiers SF1, SF2 ;
- la réponse RSPcomprend un lien ou une adresse, de type URL, où récupérer le fichier FD requis. Cette deuxième option est envisageable lorsque le fichier de description d’un modèle de données est stocké à une adresse accessible publiquement, par exemple sur un serveur FTP ou dans le cloud.
On note que dans la spécification d’une ressource de type URL, certains caractères sont spéciaux ou réservés parce qu’ils ont un sens particulier selon les protocoles standardisés de traitement de ces ressources. Par exemple le / permet de séparer des parties d’une URL.
Ainsi, pour pouvoir utiliser de tels caractères spéciaux différemment, il convient de préalablement les encoder afin qu’ils ne soient pas interprétés selon les règles standards par l’équipement client. Cet encodage est appelé URL encoding ou percent-encoding.
En particulier, le caractère spécial « : » est préalablement « url encodé » pour être valide dans l’URL indiqué dans la requête.
On comprend que la réponse à cette requête comprendrait toutes les différentes versions de l’ontologie portant ce nom. L’utilisateur pourrait ensuite sélectionner celle qui lui convient
En variante, un équipement client pourrait requérir toutes les ontologies créées par le même créateur.
Historique d’une ontologie
Deux fichiers de description d’une même ontologie, c’est-à-dire qui indiquent le même nom d’ontologie parmi les informations de description qu’ils contiennent, décrivent chacun une version différente de la même ontologie, dès lors qu’ils sont associés à des identifiants différents.
Néanmoins, Il se peut que l’ontologie décrite dans un tel fichier n’ait pas de nom.
Dans ce cas en particulier, mais aussi plus généralement, les différentes versions d’une ontologie peuvent aussi être gérées de façon externe par un système dédié de type Git par exemple. Un tel système indexe les fichiers en fonction d’une somme de contrôle calculée avec une fonction de hachage telle que SHA-1. Quand un fichier n'est pas modifié, la somme de contrôle ne change pas et le fichier n'est stocké qu'une seule fois. En revanche, si le fichier est modifié, les deux versions sont stockées sur le disque.
L’historique des versions de l’ontologie peut aussi être établi à partir des éléments de description contenus dans chaque fichier et leurs différences d’un fichier à l’autre.
Mise à disposition d’une nouvelle version d’une ontologie
On note que, selon l’invention, le fichier de description d’un modèle de données peut avoir été préalablement chargé (pour « upload » en anglais) à l’adresse de stockage @ST par un équipement client, dont l’utilisateur a créé ou modifié l’ontologie, par exemple à l’aide d’une requête de type HTTP POST. Dans ce cas l’adresse de stockage en question est l’URL d’accès à l’équipement serveur de fichier SF1, SF2, par exemple https://ontologies.org. Une telle requête peut par exemple prendre la forme ci-dessous :
curl -F "file=@temperature.owl" https://ontologies.org/upload
Elle comprend le nom « temperature.owl » du fichier.
On suppose maintenant que le serveur de fichiers SF1, SF2 reçoit d’un équipement client un fichier de description correspondant à une nouvelle version V2 d’une ontologie dont il gère le stockage et l’accès. Par exemple, il reçoit une requête de mise à jour du type :
curl -F « file=@temperature-v2.owl" https://ontologies.org/929e308ae7038bd46ac3fb4dc2188a776501b002.
929e308ae7038bd46ac3fb4dc2188a776501b002 est l’empreinte numérique ID de la version V2 de l’ontologie. Le nom du fichier à stocker est par exemple temperature-v2.owl.
On notera toutefois que le nom choisi pour le fichier de description d’un modèle de données n’a pas d’impact sur l’invention.
Identification et utilisation d’un concept de l’ontologie
Un fichier de description d’un modèle de données est généralement mis en œuvre par un programme informatique comprenant des instructions de code de programme. Plus précisément, une ou plusieurs instructions de ce programme font appel à un concept du modèle de données.
On considère par exemple un équipement client, tel que le capteur de température 5, le téléphone intelligent, la tablette ou l’ordinateur portable, représentéfigure 1.
Dans la suite, on considère que cet équipement client intègre un dispositif 200 d’utilisation d’un fichier de description FD d’un modèle de données MD selon l’invention, configuré pour obtenir, par exemple lire, une instruction de code d’un programme informatique comprenant un élément de description du modèle de données et exécuter ladite instruction conformément au modèle de données compris dans le fichier.
Selon cet exemple de réalisation de l’invention illustré par lafigure 6, le dispositif 200 comprend un module d’obtention OBT INST d’une instruction de code de programme comprenant un élément de description d’un modèle de données, ledit élément de description étant associé dans ladite instruction à une empreinte numérique d’un fichier de description dudit modèle de données, ladite empreinte numérique ayant été générée à partir des éléments de description compris dans ledit fichier, un module de résolution d’une adresse de stockage d’un fichier numérique comprenant ledit modèle de données à partir de ladite empreinte numérique, un modèle d’obtention OBT FD dudit fichier à l’adresse de stockage résolue et un module d’exécution EXC INST de ladite instruction conformément au modèle de données compris dans le fichier numérique obtenu.
Avantageusement, le dispositif 200 comprend en outre un module de vérification de l’ID à partir du fichier de description de données obtenu.
Le fichier FD reçu peut être enregistré par exemple dans une mémoire MEM de l’équipement client ou dans une mémoire distante, à laquelle l’équipement client peut accéder.
Bien sûr, il est envisageable d’interroger le serveur de fichiers sur la base d’autres informations que l’empreinte numérique ID d’une ontologie, pourvu que le serveur de fichiers SF1, SF2 dispose d’un moteur de recherche et de table d’association clé-valeur basées sur d’autres types d’indexation des fichiers dont il gère le stockage et l’accès, comme décrit précédemment.
On présente désormais, en relation avecla figure 7, sous une forme de logigramme, un exemple de mise en œuvre d’un procédé d’utilisation d’un fichier de description d’un modèle de données, selon un mode de réalisation de l’invention.
Au cours d’une étape 30, on lit parmi des instructions de code d’un programme informatique une instruction d’utilisation d’un élément de description d’un modèle de données.
Dans cette instruction, ledit élément de description est associé à une empreinte numérique ID d’un fichier de description dudit modèle de données.
Selon l’art antérieur, l’identifiant complet d’un concept d’une ontologie est communément composé de son adresse de stockage IRI, suivi d’un caractère de séparation qui est généralement un # ou un/.Selon l’invention, on utilise le nom de l’ontologie, si elle en possède un, et par exemple le # comme caractère de séparation.
Si on considère l’exemple précédent de l’ontologie température, le concept TemperatureSensor a pour identifiant complet : urn:com.project.ontology.temperature#TemperatureSensor.
Afin d’éviter toute ambiguïté sur la version de l’ontologie à utiliser, l’invention propose d’introduire l’empreinte numérique ID de l’ontologie dans l’identifiant de chacun de ses concepts.
Pour ce faire, plusieurs solutions sont envisagées. Selon un premier exemple, tout ou partie de l’identifiant de l’ontologie est utilisé, par exemple les 6 premiers caractères. L’empreinte numérique partielle ou complète de l’ontologie est ensuite ajoutée comme préfixe de l’identifiant complet du concept séparé par un caractère de séparation tel que:ou.,ou une combinaison de caractères de séparations.
Plusieurs exemples de mise en œuvre sont présentés ci-après :
- l’empreinte numérique complète ID est placée comme préfixe et séparée de l’identifiant du concept par le caractère :
929e308ae7038bd46ac3fb4dc2188a776501b002:urn:com.project.ontology.temperature#TemperatureSensor;
- une empreinte numérique partielle ID (les 6 premiers caractères) est placée comme préfixe et séparée de l’identifiant du concept par le caractère :
929e30:urn:com.project.ontology.temperature#TemperatureSensor
- une empreinte numérique partielle ID (les 7 derniers caractères) est placée comme préfixe et séparée de l’identifiant du concept par le caractère :
501b002:urn:com.project.ontology.temperature#TemperatureSensor
- une empreinte numérique partielle ID (les 6 premiers caractères) est insérée dans l’URN de l’ontologie
urn:501b002:com.project.ontology.temperature#TemperatureSensor
- une empreinte numérique partielle ID (les 7 derniers caractères) est insérée dans l’URN de l’ontologie :
urn:929e308ae7038bd46ac3fb4dc2188a776501b002:com.project.ontology.temperature#TemperatureSensor.
Avantageusement, un tel préfixe ne réduit pas la visibilité du nom du concept.
En variante, l’identifiant ID du fichier de description de l’ontologie peut être ajoutée de façon partielle ou complète comme suffixe de l’identifiant du concept.
Selon le format du programme informatique qui fait appel aux concepts du modèle de données, un mécanisme de définition préalable d’un champ de données « préfixe » peut aussi être utilisé aussi pour raccourcir l’identifiant du concept à utiliser dans les instructions du programme informatique :
prefix = urn:929e308ae7038bd46ac3fb4dc2188a776501b002:com.project.ontology.temperature.owl#
L’utilisation du préfixe dans une instruction se fait ensuite simplement comme suit : prefix:TemperatureSensor.
Un premier avantage est que les instructions du programme informatique s’en trouvent allégées. Un deuxième avantage c’est que cette définition préalable du préfixe permet de prendre en compte le fait que les formats de modèles de données, tels que Turtle ou XML/RDF déjà cités, ont chacun leur propre convention d’utilisation des préfixes.
En 31, l’identifiant ou la partie d’identifiant est extrait de l’instruction INST.
A ce stade, deux cas sont envisagés :
- l’équipement client dispose déjà du fichier de description correspondant à l’identifiant ou à la partie d’identifiant extrait et il est stocké dans une mémoire locale ; ou
- il ne dispose pas de ce fichier.
Dans ce deuxième cas, l’identifiant extrait est utilisé en 32 pour obtenir une adresse de stockage du modèle de données, par exemple celle d’un serveur de fichier en charge de la gestion et de l’accès à ce fichier de description de modèle de données. Par exemple, cette adresse est obtenue en émettant une requête de résolution d’adresse à un serveur de résolution d’adresse, tel que le serveur SR.
En 33, l’équipement client transmet une requête à l’adresse du serveur de fichier obtenue du serveur de résolution, par exemple le serveur de fichiers SF1. Comme décrit précédemment la requête comprend l’identifiant ID, ce qui permet au serveur de fichier d’identifier sans ambiguïté le fichier de description de modèle de données à transmettre dans sa réponse à l’équipement client. Une fois identifié, le fichier FD est transmis en 34 à l’équipement client.
Optionnellement, en 35, l’équipement client peut vérifier l’intégrité de l’ontologie en calculant de son côté une empreinte numérique ID’ de ce fichier, selon la même technique que celle utilisée par le serveur de fichiers SF1 et la comparer à celle qu’il a utilisée pour sa requête. Si les deux empreintes numériques ID, ID’ sont identiques, alors le fichier de description de l’ontologie est intègre et peut être utilisé en toute sécurité, sinon il ne l’est pas.
Enfin, ladite instruction est exécutée conformément au modèle de données compris dans le fichier obtenu.
A titre d’exemple illustratif,l’annexe 4présente un exemple de programme informatique utilisant un concept d’ontologie comme précédemment décrit.
Le fichier temperature_sensor.ttl définit un exemple de programme qui utilise l’ontologie urn:com.project.ontology.temperature pour définir le comportement d’un premier capteur de température dont l’identifiant est 00UIOPP. Le préfixe tp0 est ajouté à l’identifiant du concept TemperatureSensor pour permettre une identification sans ambiguïté de l’ontologie à laquelle se rapporte le concept utilisé.
On note que le programme déclare et utilise un deuxième capteur de température, identifié par IYRVHGY, correspondant à une ancienne version de modèle de capteur, donc à une version antérieue de la même ontologie urn:com.project.ontology.temperature.
Dans cet exemple, le programme utilise un préfixe « tpo-old-version » pour désigner l’ancienne version de l’ontologie :
@prefix tpo-old-version: <b27040e593c414172b50aa1df8372474b8e3607d:urn:com.project.ontology.temperature#> ;
et le préfixe @prefix tpo: <929e308ae7038bd46ac3fb4dc2188a776501b002:urn:com.project.ontology.temperature#> , pour désigner la plus récente.
On note que le deuxième capteur de température utilise une propriété id définie comme un entier, alors que le premier capteur, correspondant à une version plus récente de l’ontologie utilise cette propriété id, mais définie comme une chaîne de caractères (pour « string », en anglais).
Comme chaque utilisation de cette propriété est précédée du préfixe correspondant à l’ontologie à laquelle elle se rapporte, il n’y a aucune ambiguïté sur la définition de la propriété id qui s’applique.
Cet exemple illustre bien le fait que, contrairement à l’art antérieur, l’invention permet d’utiliser dans un même programme deux versions d’une même ontologie sans introduire d’incohérence dans l’exécution de ce programme. Elle garantit une gestion et une utilisation sûres et maîtrisées d’un modèle de description de données et de ses évolutions.
On présente maintenant, en relation avec lafigure 8, un autre exemple de structure matérielle d’un dispositif 100 de gestion du stockage d’un fichier de description d’un modèles de données selon l’invention, comprenant, comme illustré par le premier exemple de lafigure 2, au moins un module d’obtention OBT MD d’un modèle de données MD, un module GN ID de génération d’un identifiant du modèle de données MD à partir des données de description qu’il contient et un module de stockage STC FD du fichier FD dans une mémoire locale ou distante, l’adresse de stockage du fichier étant associée à l’identifiant ID.
Avantageusement, le dispositif 100 comprend en outre un module de traitement TRT RQ d’une requête d’accès audit fichier de description en provenance d’un équipement client et un module de transmission TRS RSP d’une réponse audit équipement client comprenant le fichier requis ou l’adresse de stockage dudit fichier.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg, représentatif des modules de comparaison et de sélection, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 103 avant d'être exécutées par le processeur de l'unité de traitement 102. La mémoire vive 103 peut aussi contenir le fichier de description du modèle de données FD et une table comprenant une entrée associant un nom du modèle de données à un identifiant dudit modèle.
Lafigure 8illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 100 afin qu’il effectue les étapes du procédé de gestion du stockage et de l’accès à un fichier de description d’un modèle de données tel que détaillé ci-dessus, en relation avec les figures3 et 4dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 100 intégré dans un serveur de fichiers SF1, SF2 connecté au réseau de télécommunications RT, mais il peut aussi être intégré à tout autre équipement connecté au réseau de télécommunications RT, comme par exemple un terminal utilisateur.
Selon la variante de réalisation de l’invention illustrée par la figure2, le dispositif 100 s’appuie sur la structure matérielle du serveur de fichier SF1, qui a dans cet exemple la structure matérielle d’un ordinateur et comprend plus particulièrement un processeur, une mémoire vive, une mémoire morte, une mémoire flash non volatile ainsi que des moyens de communication sans fil qui lui permettent de communiquer avec l’équipement client 1, 2, 3, 4, 5 et le serveur SR de résolution d’adresses, via le réseau de communication. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur et sur lequel est enregistré le programme d’ordinateur Pg1 conforme à l’invention, comportant des instructions pour l’exécution du procédé de gestion du stockage d’un fichier de description d’un modèle de données selon l’invention.
On présente enfin, en relation avec lafigure 9, un autre exemple de structure matérielle d’un dispositif 200 d’utilisation d’un fichier de description d’un modèles de données selon l’invention, comprenant, comme illustré par l’exemple de lafigure 6, au moins un module de lecture OBT INST d’une instruction de code de programme comprenant un élément de description ED d’un modèle de données MD, ledit élément de description étant associé dans ladite instruction à une empreinte numérique ID d’un fichier de description dudit modèle de données, ladite empreinte numérique ayant été générée à partir des éléments de description compris dans ledit fichier, un module de résolution RS @SF d’une adresse de localisation d’un équipement serveur stockant le fichier numérique comprenant ledit modèle de données, à partir de ladite empreinte numérique, un modèle d’obtention OBT FD dudit fichier à l’adresse de localisation résolue et un module d’exécution EXC INST de ladite instruction conformément audit modèle de données MD.
Avantageusement, le dispositif comprend en outre un module CHK ID de vérification de l’identifiant à partir du fichier FD obtenu.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 200 comprend une mémoire vive 203 (par exemple une mémoire RAM), une unité de traitement 202 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg, représentatif des modules de lecture, de résolution d’une adresse de stockage, d’obtention du fichier de description du modèle de données et d’exécution de l’instruction conformément audit modèle de données, stocké dans une mémoire morte 201 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 203 avant d'être exécutées par le processeur de l'unité de traitement 202. La mémoire vive 203 peut aussi contenir le fichier de description du modèle de données FD obtenu et le programme informatique.
Lafigure 9illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 200 afin qu’il effectue les étapes du procédé d’utilisation d’un fichier de description d’un modèle de données tel que détaillé ci-dessus, en relation avec la figure6dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 200 intégré dans un équipement client 1, 2, 3, 4, 5 connecté au réseau de télécommunications RT, mais il peut aussi être intégré à tout autre équipement connecté au réseau de télécommunications RT, pourvu qu’il exécute un programme informatique comprenant des instructions faisant appel à des concepts d’un modèle de données.
Selon la variante de réalisation de l’invention illustrée par la figure6, le dispositif 200 s’appuie sur la structure matérielle de l’équipement client dans lequel il est embarqué, lequel a ici la structure matérielle d’un ordinateur et comprend plus particulièrement un processeur, une mémoire vive, une mémoire morte, une mémoire flash non volatile ainsi que des moyens de communication sans fil qui lui permettent de communiquer avec le serveur de fichier et un serveur de résolution d’adresses via le réseau de télécommunications. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur et sur lequel est enregistré le programme d’ordinateur Pg2 conforme à l’invention, comportant des instructions pour l’exécution du procédé d’utilisation d’un fichier de description d’un modèle de données selon l’invention.
L’invention qui vient d’être décrite dans ses différents modes de réalisation présente de nombreux avantages. En particulier, le nouveau mode d’identification d’un fichier de description d’un modèle de données et de stockage à une adresse de stockage associé à cet identifiant, ainsi que le nouveau mode de désignation des concepts d’un tel modèle dans un programme informatique, proposés par l’invention, permettent une gestion et une utilisation des modèles de données et de leurs différentes versions, qui sont plus efficaces, plus sûres et mieux maîtrisées.
ANNEXE 1 : exemple de fichier de description d’un modèle de données au format RDF/XML
<?xml version="1.0"?>
<rdf:RDF xmlns=""
xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#
xmlns:terms=http://purl.org/dc/terms/
xmlns:owl=http://www.w3.org/2002/07/owl#
xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#
xmlns:vann=http://purl.org/vocab/vann/
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<owl:Ontology rdf:about="urn:project.ontology.temperature">
<foaf:primaryTopic>Temperature sensor</foaf:primaryTopic>
<terms:issued>2020-03-09</terms:issued>
<owl:versionInfo>0.0.1</owl:versionInfo>
<terms:description>This is an ontology example for temperature sensor</terms:description>
<vann:preferredNamespacePrefix>temperature-sensor</vann:preferredNamespacePrefix>
<terms:creator rdf:datatype="http://www.w3.org/2001/XMLSchema#xsd#string"> Pierre Meye </terms:creator>
<terms:title>Temperature sensor ontology</terms:title>
</owl:Ontology>
<!--
///////////////////////////////////////////////////////////////////////////////////////
//
// Data properties
//
///////////////////////////////////////////////////////////////////////////////////////
-->
<!-- urn:project.ontology.temperature#id -->
<owl:DatatypeProperty rdf:about="urn:project.ontology.temperature#id">
<rdfs:domain rdf:resource="urn:project.ontology.temperature#Sensor"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">ID of a sensor.</rdfs:comment>
<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">id</rdfs:label>
</owl:DatatypeProperty>
<!--
///////////////////////////////////////////////////////////////////////////////////////
//
// Classes
//
///////////////////////////////////////////////////////////////////////////////////////
-->
<!-- urn:project.ontology.temperature#Sensor -->
<owl:Class rdf:about="urn:project.ontology.temperature#Sensor">
<rdfs:comment>An electronic device</rdfs:comment>
<rdfs:label>Sensor</rdfs:label>
</owl:Class>
<!-- urn:project.ontology.temperature#TemperatureSensor -->
<owl:Class rdf:about="urn:project.ontology.temperature#TemperatureSensor">
<rdfs:subClassOf rdf:resource="urn:project.ontology.temperature#Sensor"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A temperature sensor</rdfs:comment>
<rdfs:label>TemperatureSensor</rdfs:label>
</owl:Class>
</rdf:RDF>
<!-- Generated by the OWL API (version 4.2.8.20170104-2310) https://github.com/owlcs/owlapi -->
ANNEXE 2 : exemple de fichier de description d’un modèle de données reformaté et nettoyé
prefix : <urn:project.ontology.temperature#> .
@prefix terms: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vann: <http://purl.org/vocab/vann/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<urn:project.ontology.temperature>
a owl:Ontology ;
terms:creator " Pierre Meye "^^<http://www.w3.org/2001/XMLSchema#xsd#string> ;
terms:description "This is an ontology example for temperature sensor" ;
terms:issued "2020-03-09" ;
terms:title "Temperature sensor ontology" ;
vann:preferredNamespacePrefix "temperature-sensor" ;
owl:versionInfo "0.0.1" ;
foaf:primaryTopic "Temperature sensor" .
:TemperatureSensor a owl:Class ;
rdfs:comment "A temperature sensor" ;
rdfs:label "TemperatureSensor" ;
rdfs:subClassOf :Sensor .
:Sensor a owl:Class ;
rdfs:comment "An electronic device" ;
rdfs:label "Sensor" .
:id a owl:DatatypeProperty ;
rdfs:comment "ID of a sensor." ;
rdfs:domain :Sensor ;
rdfs:label "id" ;
rdfs:range xsd:string .
ANNEXE 3 : exemple de fichier de description d’un modèle de données trié
a owl:Ontology ;
foaf:primaryTopic "Temperature sensor" .
owl:versionInfo "0.0.1" ;
rdfs:comment "A temperature sensor" ;
rdfs:comment "An electronic device" ;
rdfs:comment "ID of a sensor." ;
rdfs:domain :Sensor ;
rdfs:label "TemperatureSensor" ;
rdfs:label "Sensor" .
rdfs:label "id" ;
rdfs:range xsd:string .
rdfs:subClassOf :Sensor .
terms:creator " Pierre Meye "^^<http://www.w3.org/2001/XMLSchema#xsd#string> ;
terms:description "This is an ontology example for temperature sensor" ;
terms:issued "2020-03-09" ;
terms:title "Temperature sensor ontology" ;
vann:preferredNamespacePrefix "temperature-sensor" ;
:Sensor a owl:Class ;
:TemperatureSensor a owl:Class ;
:id a owl:DatatypeProperty ;
<urn:project.ontology.temperature>
@prefix : <urn:project.ontology.temperature#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix terms: <http://purl.org/dc/terms/> .
@prefix vann: <http://purl.org/vocab/vann/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
ANNEXE 4 : exemple de fichier temperature_sensor.ttl comprenant un programme informatique utilisant un modèle de données identifié par son empreinte numérique selon l’invention
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix tpo: <929e308ae7038bd46ac3fb4dc2188a776501b002:urn:com.project.ontology.temperature#> .
@prefix tpo-old-version: <b27040e593c414172b50aa1df8372474b8e3607d:urn:com.project.ontology.temperature#> .
http://www.project.com/temperature-sensor/00UIOPP
a <tpo:TemperatureSensor> ;
<tpo#id> "00UIOPP"^^xsd:string .
http://www.project.com/temperature-sensor/IYRVHGY
a <tpo-old-version:TemperatureSensor> ;
<tpo-old-version#id> "1234"^^xsd:integer .

Claims (15)

  1. Procédé de gestion d’un fichier numérique (FD) de description d’un modèle de données (MD), ledit fichier comprenant des éléments de description dudit modèle de données,
    caractérisé en ce queledit procédé comprend :
    - une obtention (21) d’un identifiant (ID) dudit fichier par génération (21) d’une empreinte numérique desdits éléments de description du modèle de données, et
    - un stockage (23) dudit fichier à au moins une adresse de stockage, ladite adresse de stockage étant associée audit identifiant.
  2. Procédé de gestion d’un fichier numérique de description d’un modèle de données selon la revendication précédente,caractérisé en ce que, le modèle de description comprenant des éléments de description structurants et des éléments de description non structurants, l’obtention d’un identifiant comprend une élimination (210) des éléments de description non structurants, un tri (211) des éléments de description dudit modèle selon au moins une règle prédéterminée et une génération (212) de l’empreinte numérique des éléments de description triés.
  3. Procédé de gestion d’un fichier numérique de description d’un modèle de données selon l’une des revendications précédentes,caractérisé en ce quel’empreinte numérique ID est générée à l’aide d’une fonction de hachage.
  4. Procédé de gestion d’un fichier numérique de description d’un modèle de données selon l’une quelconque des revendications précédentes,caractérisé en ce qu’il comprend un renommage 22 du modèle de données, qui est indépendant de ladite au moins une adresse de stockage (@ST).
  5. Procédé de gestion d’un fichier de description d’un modèle de données selon la revendication précédente,caractérisé en ce quele modèle est nommé à l’aide d’une ressource de nommage (URN) présentant une syntaxe d’adresse de localisation (URL).
  6. Procédé de gestion d’un fichier numérique de description d’un modèle de données selon l’une quelconque des revendications précédentes,caractérisé en ce qu’il met en œuvre un traitement d’une requête d’obtention dudit fichier de description en provenance d’un équipement client (1, 2, 3, 4, 5), ladite requête comprenant ledit identifiant(ID) , ledit traitement comprenant l’obtention de l’adresse de stockage (@ST) associé à l’identifiant (ID) dans ladite table, et une transmission audit équipement client d’une réponse comprenant ledit fichier ou l’adresse de stockage dudit fichier (@ST).
  7. Procédé d’utilisation d’un fichier numérique de description d’un modèle de données par un équipement client connecté à un réseau de télécommunications et configuré pour exécuter un programme informatique,caractérisé en ce queledit procédé met en œuvre :
    - l’obtention (30) dans ledit programme informatique, d’une instruction (INST) comprenant un élément de description (ED) d’un modèle de données, ledit élément de description (Ed) étant associé dans ladite instruction à un identifiant (ID) dudit fichier de description dudit modèle de données, ledit identifiant ayant été obtenu par génération d’une empreinte numérique des éléments de description compris dans le fichier de description dudit modèle ;
    -une obtention (31) dudit identifiant à partir de ladite instruction ;
    - une résolution (32) d’une adresse de localisation (@SF1) d’un équipement serveur (SF1) stockant ledit fichier (FD), à partir dudit identifiant (ID) ;
    - une obtention (33) du fichier par transmission d’une requête (RQ) à l’adresse de localisation de résolue (@SF1) de l’équipement serveur, ladite requête comprenant ledit identifiant, ledit fichier étant stocké à une adresse de stockage associée audit identifiant (ID) ; et
    - une exécution (35) de ladite instruction (INST) conformément au modèle de données compris dans le fichier obtenu.
  8. Procédé d’utilisation d’un fichier numérique de description d’un modèle de données selon la revendication 7,caractérisé en ce qu’ilmet en œuvre une vérification (34) de l’identifiant (ID) à partir du fichier obtenu, par génération d’une empreinte numérique (ID’) des éléments de description du modèle de données qu’il contient et comparaison de l’empreinte numérique (ID’) générée à l’identifiant (ID).
  9. Procédé d’utilisation d’un fichier numérique de description d’un modèle de données selon l’une des revendications 7 et 8,caractérisé en ce queladite instruction comprend ledit élément de description précédé de d’au moins une partie de l’identifiant (ID) du fichier de description.
  10. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 9, lorsqu’il est exécuté par un processeur.
  11. Dispositif (100) de gestion d’un fichier numérique de description d’un modèle de données, ledit fichier comprenant des données de description dudit modèle de données,
    caractérisé en ce queledit dispositif est configuré pour :
    - obtenir un identifiant (ID) du fichier de description du modèle de données par génération d’une empreinte numérique desdits éléments de description compris dans ledit fichier, et
    - stocker ledit fichier à au moins une adresse de stockage (@ST), ladite adresse de stockage étant associée audit identifiant.
  12. Dispositif (200) d’utilisation d’un fichier numérique de description d’un modèle de données par un équipement client connecté à un réseau de télécommunications (RT) et configuré pour exécuter un programme informatique,caractérisé en ce qu’ilest configuré pour :
    - obtenir dudit programme informatique au moins une instruction comprenant un élément de description d’un modèle de données, ledit élément de description étant associé dans ladite instruction à un identifiant du fichier de description dudit modèle de données, ladite empreinte numérique ayant été générée à partir des éléments de description compris dans ledit fichier ;
    -résoudre une adresse de localisation (@SF) d’un équipement serveur stockant ledit fichier à partir dudit identifiant ;
    - obtenir ledit fichier par transmission d’une requête (RQ) à l’adresse de localisation résolue de l’équipement serveur, ladite requête comprenant ledit identifiant (ID), ledit fichier étant stocké à une adresse de stockage associée audit identifiant (ID) ; et
    - exécuter ladite instruction conformément au modèle de données compris dans le fichier numérique obtenu.
  13. Equipement client (1, 2, 3, 4, 5) apte à se connecter à un réseau de télécommunications,caractérisé en ce qu’il comprend un dispositif (100) d’utilisation d’un fichier numérique de description d’un modèle de données selon la revendication12.
  14. Equipement serveur (SF1, SF2) connecté à un réseau de télécommunications, comprenant un module de stockage de fichiers numériques de description de modèles de données dans une mémoire,caractérisé en ce qu’il comprend en outre un dispositif (200) de gestion d’un fichier de description dudit modèle de données selon la revendication11.
  15. Système de gestion (10) d’un fichier numérique (FD) de description d’un modèle de données dans un réseau de télécommunications,caractérisé en ce qu’il comprend, connectés audit réseau, au moins un équipement serveur (SF1, SF2) selon la revendication 14 configuré pour stocker ledit fichier en association avec un identifiant (ID) de ce fichier, au moins un serveur de résolution d’adresses configuré pour résoudre une adresse de localisation (@SF1, @SF2) dudit équipement serveur (SF1) à partir dudit identifiant (ID) dudit fichier et au moins un équipement client (1-5) selon la revendication13configuré pour requérir ledit fichier auprès dudit au moins un équipement serveur (SF1, SF2) et utiliser ledit fichier.
FR2003082A 2020-03-27 2020-03-27 Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants. Active FR3108747B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2003082A FR3108747B1 (fr) 2020-03-27 2020-03-27 Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2003082A FR3108747B1 (fr) 2020-03-27 2020-03-27 Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants.
FR2003082 2020-03-27

Publications (2)

Publication Number Publication Date
FR3108747A1 true FR3108747A1 (fr) 2021-10-01
FR3108747B1 FR3108747B1 (fr) 2023-01-27

Family

ID=72709409

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2003082A Active FR3108747B1 (fr) 2020-03-27 2020-03-27 Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants.

Country Status (1)

Country Link
FR (1) FR3108747B1 (fr)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KUHN TOBIAS ET AL: "Making Digital Artifacts on the Web Verifiable and Reliable", IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, IEEE SERVICE CENTER, LOS ALAMITOS, CA, US, vol. 27, no. 9, 1 September 2015 (2015-09-01), pages 2390 - 2400, XP011665198, ISSN: 1041-4347, [retrieved on 20150804], DOI: 10.1109/TKDE.2015.2419657 *
QIN L ET AL: "Evaluating the validity of data instances against ontology evolution over the Semantic Web", INFORMATION AND SOFTWARE TECHNOLOGY, ELSEVIER, AMSTERDAM, NL, vol. 51, no. 1, 1 January 2009 (2009-01-01), pages 83 - 97, XP025710571, ISSN: 0950-5849, [retrieved on 20080126], DOI: 10.1016/J.INFSOF.2008.01.004 *
YORK SURE ET AL: "The Ontology - Semantic Web for Research Communities", 1 January 2005, PROGRESS IN ARTIFICIAL INTELLIGENCE LECTURE NOTES IN COMPUTER SCIENCE;LECTURE NOTES IN ARTIFICIAL INTELLIG ENCE;LNCS, SPRINGER, BERLIN, DE, PAGE(S) 218 - 231, ISBN: 978-3-540-30737-2, XP019025224 *

Also Published As

Publication number Publication date
FR3108747B1 (fr) 2023-01-27

Similar Documents

Publication Publication Date Title
EP0599706B1 (fr) Dispositif de traitement de l&#39;information permettant la gestion d&#39;une ressource informatique par un système d&#39;administration
FR2738649A1 (fr) Procede de conversion d&#39;objets d&#39;un espace plat a un espace structure en classes
WO2014114861A1 (fr) Procédé de vérification de l&#39;intégrité d&#39;un bloc de données numériques
EP1096394A1 (fr) Système et procédé de gestion de la persistance des composants EJB dans un annuaire accédé par LDAP
WO2006111452A1 (fr) Procédé d&#39;optimisation de la gestion d&#39;un cache de serveur pouvant être consulté par des terminaux clients de caractéristiques différentes
CN106611008B (zh) 一种互联网内容标签的管理方法及装置
US20180089243A1 (en) Bloom filter index for device discovery
FR2906383A1 (fr) Referentiel semantique de services web et procede utilisant ce referentiel
EP2553584A1 (fr) Procede, programme d&#39;ordinateur et dispositif de validation d&#39;execution de taches dans des systemes informatiques evolutifs
EP3343409A1 (fr) Procédé et plateforme pour l&#39;élévation des données sources en données sémantiques interconnectées
WO2015173500A1 (fr) Base de fichiers relationnelle et interface graphique de gestion d&#39;une telle base
FR3108747A1 (fr) Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants.
US20150347402A1 (en) System and method for enabling a client system to generate file system operations on a file system data set using a virtual namespace
EP1054332B1 (fr) Système et procédé de gestion d&#39;attributs dans un environnement orienté objet
EP1559003A2 (fr) Carte a microcircuit comportant des moyens de publication de ses objets informatiques
EP3643043B1 (fr) Dispositifs et procédés de communication
EP4028888A1 (fr) Procédé de communication entre des entités logicielles via une api
WO2023247172A1 (fr) Système de gestion de jumeaux numériques, procédé de gestion associé
FR3041450A1 (fr) Architecture client/serveur pour l&#39;administration d&#39;un supercalculateur
FR2795535A1 (fr) Procede d&#39;execution a distance d&#39;une fonction sur un objet informatique dans un reseau de communication
WO2024083978A1 (fr) Procédé de traitement d&#39;une requête d&#39;exécution d&#39;un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d&#39;ordinateur correspondants
FR3085076A1 (fr) Procede de notarisation de masse sans recu de notarisation et decentralise en blokchains et espace a adressage par contenu.
FR3094509A1 (fr) Système de stockage redondant de données, procédé et programme d’ordinateur correspondants.
FR2795536A1 (fr) Procede de traduction, de transfert et de mise a jour d&#39;un objet informatique sur un reseau de communication informatique
WO2012149977A1 (fr) Procede et systeme correspondant de generation d&#39;une application logicielle manipulant des donnees structurees.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20211001

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5