La présente invention concerne un système de publication et de souscription de données. L'invention s'applique notamment à la mise en relation de plusieurs dispositifs de communication différents comprenant chacun des services de publication et de souscription de données.

Une application informatique connectée à un réseau et communiquant à travers des mécanismes de type publication/souscription, regroupe souvent les données à échanger par sujets. Un sujet est un identificateur, par exemple un nom commun, qui définit une catégorie de donnée selon, par exemple, un classement thématique, chronologique ou autre. Or, un grand nombre de ces applications existantes ont été développées indépendamment les unes des autres. Aussi, les sujets employés diffèrent d'une application à l'autre car les modes de classement et/ou la syntaxe utilisée pour désigner une catégorie de donnée n'est pas la même. Dès lors, des limites syntaxiques s'opposent aux échanges de données entre ces applications. En effet, la publication d'une donnée par une première application sous un sujet, par exemple le sujet spécifié par l'identificateur « bicyclettes », ne sera pas consommée par une autre application ayant souscrite au sujet « véhicules à deux roues » car même si du point de vue sémantique, une « bicyclette » est un « véhicule à deux roues », les deux sujets sont différents du point de vue syntaxique.

Parfois, les applications indiquent également le type de la donnée publiée et/ou à souscrire, c'est à dire leur format, lequel peut être décrit par un document de définition de type de donnée. Là encore, les définitions de document ne sont pas nécessairement identiques, même si elles correspondant de facto au même type de donnée.

La demande de brevet publié sous la référence WO2005/0721 14 propose une méthode pour rendre des producteurs de données interopérables avec des applications consommatrices. Cependant, cette méthode ne fournit une interface qu'avec un seul service de partage de données. Elle ne permet pas de répartir la charge de calcul à mettre en œuvre pour distribuer des données et oblige à redonder le point unique de partage pour assurer une haute disponibilité du service de partage. Les infrastructures de communications actuelles basées sur la publication et la souscription de données, telles que JMS (« Java Message Service ») ou DDS (« Data Distribution System ») ne permettent pas de résoudre le problème d'interopérabilité précité. Elles imposent une définition précise de bas niveau des sujets et des types de données échangées, constituant ainsi un obstacle à toute intégration d'applications hétérogènes.

Un but de l'invention est de proposer une infrastructure de communication permettant à des applications hétérogènes de publication et souscription de données regroupées par sujets d'échanger des données. A cet effet, l'invention a pour objet un système de souscription et de publication de données comprenant au moins un émetteur publiant des données et un récepteur souscrivant à des données, les données étant libellées par un ou plusieurs identificateurs, les émetteurs et récepteurs étant interconnectés via un réseau, ledit système étant caractérisé en ce qu'il comporte une base de connaissances ontologique commune aux dits émetteurs et récepteurs, au moins un émetteur et récepteur de données comprenant chacun un module sémantique connecté à ladite base et adapté à analyser une requête sémantique pour produire des identificateurs en adéquation sémantique avec ladite requête, ledit émetteur publiant et ledit récepteur souscrivant à des données via lesdits identificateurs.

Contrairement aux systèmes de l'art antérieur dans lesquels les identificateurs constituent un frein au découplage entre émetteurs et récepteurs, le système selon l'invention, permet, en découplant les identificateurs, de découpler davantage les émetteurs des récepteurs de données. Le système selon l'invention permet une meilleure interopérabilité entre des applications consommatrices ou productrices de données.

Selon un mode de réalisation du système selon l'invention, la base de connaissances ontologique définit des concepts sémantiques liés entre eux par des relations de dépendance, chacun des identificateurs susceptibles d'être publiés ou souscrits par un émetteur ou un récepteur étant référencé, via des moyens d'association, par au moins un concept ou une instance de concept dans ladite base, le module sémantique comprenant un raisonneur adapté à rechercher dans ladite base tous les identificateurs en adéquation sémantique avec une requête sémantique. Selon un mode de réalisation du système selon l'invention, les émetteurs et récepteurs de données sont des terminaux informatiques, une application consommatrice et/ou productrice de données étant exécutée sur chacun desdits terminaux, ladite application de chaque terminal informatique étant connectée au module sémantique, lequel est pourvu d'un accès à la base de connaissances ontologique via le réseau.

Des moyens d'associations pour référencer les identificateurs susceptibles d'être publiés ou souscrits par un émetteur ou un récepteur par au moins un concept ou une instance de concept de la base de connaissance peuvent être compris par chaque émetteur et récepteur, lesdits moyens comprenant un ou plusieurs fichiers de correspondance entre les concepts de ladite base et lesdits identificateurs.

Selon un mode de réalisation du système selon l'invention, au moins un émetteur et un récepteur comprend un module de traduction exécutant un premier script de transformation d'une donnée formatée dans un langage propre au dit émetteur ou au dit récepteur, en donnée formatée dans un format pivot propre à la base de connaissances, le module de traduction étant pourvu d'un second script de transformation d'une donnée formatée dans un format pivot propre à la base de connaissances en donnée formatée dans un langage propre au dit émetteur ou au dit récepteur.

Le découplage des types de données ainsi obtenu permet de découpler encore davantage les émetteurs et les récepteurs de données.

Par ailleurs, les relations de dépendance entre les concepts de la base de connaissances ontologique peuvent être spécifiées, par exemple, dans le langage « Resource Description Framework » ou le langage « Web Ontology Language ».

L'invention a également pour objet un procédé de souscription et de publication de données dans un système comprenant au moins un émetteur publiant des données et un récepteur souscrivant à des données, les données étant libellées par un ou plusieurs identificateurs, ledit procédé comprenant au moins une étape de publication d'un ou de plusieurs identificateurs de données par un émetteur et une étape de souscription à un ou plusieurs identificateurs par un récepteur, ladite étape de souscription comprenant au moins les sous-étapes suivantes : • référencer, par des moyens d'association, les identificateurs susceptibles d'être souscrits par ledit récepteur à une spécification sémantique ;

• un module sémantique compris dans ledit récepteur de données reçoit une requête sémantique ;

• le module sémantique interroge une base de connaissances ontologique commune aux récepteurs et émetteurs dudit système pour trouver des concepts sémantiques en adéquation sémantique avec ladite requête ; - le module sémantique traduit lesdits concepts en identificateurs en utilisant les moyens d'association,

• exécuter une requête de souscription pour chacun desdits identificateurs fournis par le module sémantique.

Selon une mise en œuvre du procédé de souscription et de publication de données selon l'invention, ladite étape de publication comprend au moins les sous-étapes suivantes :

• référencer, par des moyens d'association, les identificateurs susceptibles d'être publiés par ledit émetteur à une spécification sémantique ; - un module sémantique compris dans ledit émetteur de données reçoit une requête sémantique ;

• le module sémantique interroge une base de connaissances ontologique commune aux récepteurs et émetteurs dudit système pour trouver des concepts en adéquation sémantique avec ladite requête ;

• le module sémantique traduit lesdits concepts en identificateurs en utilisant les moyens d'association,

• exécuter une requête de publication pour chacun desdits identificateurs fourni par le module sémantique. Les requêtes sémantiques peuvent être formulées dans le langage « Simple Protocol And RDF Query Language », plus simplement désigné par l'acronyme SPARQL. D'autres caractéristiques apparaîtront à la lecture de la description détaillée donnée à titre d'exemple et non limitative qui suit faite en regard de dessins annexés qui représentent :

- la figure 1 , un schéma illustrant un premier mode de réalisation du système de publication et souscription de données selon l'invention,

- la figure 2, un schéma illustrant les étapes exécutées lors de la souscription d'un sujet dans un procédé selon l'invention,

- la figure 3, un schéma illustrant les étapes exécutées lors de la publication d'un sujet dans un procédé selon l'invention, - la figure 4, un schéma illustrant un deuxième mode de réalisation du système de publication et souscription de données selon l'invention.

La figure 1 illustre, à travers un schéma, un premier mode de réalisation du système de publication/souscription de données selon l'invention. Des émetteurs 11 1 , 1 12 de données et des récepteurs 121 , 122,

123 de données, par exemple des terminaux informatiques, sont connectés via un réseau 130. Chacun de ces terminaux informatiques 11 1 , 1 12, 121 , 122, 123 exécute au moins une application 141 , 142, 151 , 152, 153, chacune de ces applications pouvant être différente l'une de l'autre. Chaque application 141 , 142, 151 , 152, 153 communique avec une infrastructure 160 de publication et souscription de données, laquelle infrastructure 160 est un module logiciel installé sur chacun des terminaux informatiques interconnectés 1 1 1 , 1 12, 121 , 122, 123 et qui permet de publier des données et de souscrire à des données en spécifiant des sujets d'intérêt libellant ces données. Une infrastructure 160 de type connu peut être employée, comme, par exemple, DDS (« Data Distribution Service »), l'infrastructure « Java Message Service » spécifié par le Java Community Process ou l'infrastructure WS-notification (« Web Services notification ») normalisée par l'organisme de standardisation OASIS (« Organization for the Advancement of Structured Information Standards »).

Un même terminal informatique peut être à la fois émetteur de données pour un premier ensemble de sujets et récepteur de données pour un second ensemble de sujets. Dans un souci de clarté, les terminaux informatiques 1 1 1 , 1 12, 121 , 122, 123 de l'exemple ne cumulent pas les fonctions d'émetteur et de récepteur de données et ne comprennent chacun qu'une seule application accédant à l'infrastructure de publication et souscription de données.

Chaque application 141 , 142, 151 , 152, 153 peut publier ou souscrire à un certain nombre de sujets, les sujets manipulés étant différents d'une application à l'autre. Pour permettre néanmoins aux applications 141 , 142, 151 , 152, 153 de pouvoir échanger des données concernant un sujet, un module sémantique 170 est exécuté par chacun des terminaux informatiques 1 1 1 , 1 12, 121 , 122, 123. Ce module sémantique 170 comprend un raisonneur, autrement dit, un algorithme de résolution des requêtes sémantiques qui permet d'analyser une telle requête en prenant en compte sa signification et pas seulement sa forme.

En outre, le module sémantique 170 est connecté à une base de connaissances ontologique 180 commune aux terminaux émetteurs et aux terminaux récepteurs. Dans l'exemple, cette base de connaissances ontologique 180 est centralisée et accessible par les terminaux informatiques 11 1 , 1 12, 121 , 122, 123 via le réseau 130. Selon un autre mode de réalisation dans lequel chaque terminal informatique dispose de ressources suffisantes en termes de mémoire et de capacités de calcul, la base de connaissances 180 est répliquée sur chaque terminal informatique 1 1 1 , 1 12, 121 , 122, 123, ce qui permet d'éviter d'accéder au réseau pour accéder au contenu de ladite base de connaissance 180. La base de connaissances 180 est, par exemple, développée par des experts oeuvrant dans les domaines concernés par les applications 141 , 142, 151 , 152, 153, puis standardisée de manière à pouvoir être partagée par le maximum d'applications. Elle contient, pour chaque domaine de connaissance à traiter, un modèle de données comprenant un ensemble de concepts liés les uns aux autres par des relations sémantiques, ces relations étant définies, par exemple, via un langage de spécification sémantique tel que RDF (« Resource Description Framework ») ou OWL (« Web Ontology Language »). Chaque concept peut également comporter une ou plusieurs instances, c'est à dire des éléments appartenant à ce concept. Le module sémantique 170 est adapté à interroger la base de connaissances 180 pour récupérer les concepts et/ou instances relatifs à la requête sémantique formulée.

Par ailleurs, des moyens d'association entre la base de connaissances 180 et les sujets susceptibles d'être publiés ou souscrits par une application 141 , 142, 151 , 152, 153 sont créés. Ces moyens d'association, qui permettent de lier les concepts et instances de la base de connaissances 180 aux sujets connus d'une application 141 , 142, 151 , 152, 153, peuvent prendre la forme, par exemple, d'un fichier de correspondance présent dans chaque terminal informatique 1 1 1 , 1 12, 121 , 122, 123 ou d'une base de données commune à tous les terminaux informatiques et accessible par le réseau 130. Dans l'exemple décrit, l'association entre la base de connaissances 180 et les sujets susceptibles d'être souscrits ou publiés est effectuée, pour chaque application 141 , 142, 151 , 1 52, 153 de chaque terminal informatique 1 1 1 , 1 12, 121 , 122, 123, via un fichier accessible du module sémantique 170. Ce fichier contient des correspondances entre sujets et concepts de la base de connaissances 180.

Dans un terminal informatique émetteur 1 1 1 , 1 12, le module sémantique 170 permet de publier tous les sujets relatifs à une requête sémantique. De manière analogue, dans un terminal informatique récepteur 121 , 122, 123, le module sémantique 170 permet de souscrire à tous les sujets relatifs à une requête sémantique.

Les étapes de transfert de données entre un émetteur et un récepteur de données comprennent : - une première étape au cours de laquelle un émetteur souscrit à un sujet T,

• une seconde étape au cours de laquelle un récepteur publie sur le sujet T,

• une troisième étape au cours de laquelle les données associées au sujet T sont acheminées de l'émetteur vers le récepteur.

Les étapes de publication et souscription dans un procédé selon l'invention sont explicitées ci-après en figures 2 et 3.

La figure 2 illustre les étapes exécutées lors de la souscription d'un sujet dans un procédé selon l'invention. Ces étapes sont décrites en relation avec l'exemple du premier récepteur 121 du système présenté en figure 1 . Dans un premier temps 201 , l'application 151 exécutée par le récepteur 121 formule une requête sémantique 212 au module sémantique 170. Cette requête sémantique 212 peut être définie grâce à un langage approprié, par exemple SPARQL, sigle anglo-saxon pour « Simple Protocol and RDF Query Language ». Dans un deuxième temps 202, la requête sémantique 212 est interprétée par le module sémantique 170 qui interroge la base de connaissances 180, contrairement à une requête classique qui serait uniquement traitée dans sa forme. Des paramètres peuvent également être associés à la requête sémantique 212 pour modifier le comportement du raisonneur, par exemple, pour contrôler le périmètre de recherche dans la base de connaissances 180.

Dans un troisième temps 203, le module sémantique 170 récupère de la base de connaissances 180 les concepts et/ou instances de concept concernés par la requête sémantique 212, c'est-à-dire les concepts et/ou instances de concept en adéquation sémantique avec la requête sémantique

212.

Dans un quatrième temps 204, pour chaque concept et/ou instance récupéré par le traitement de la requête sémantique 212, le ou les sujets 222 associés à ce concept ou à cette instance sont produits en utilisant les moyens d'association 215 — dans l'exemple, un fichier de correspondances — entre sujets manipulés par l'application 151 et concepts de la base de connaissances 180.

Dans un cinquième temps 205, l'infrastructure 160 souscrit aux sujets 222 produits par le module sémantique 170, par exemple, via des appels successifs à une fonction classique de souscription disponible dans l'infrastructure 160.

La figure 3 illustre les étapes exécutées lors de la publication d'un sujet dans un procédé selon l'invention. Ces étapes sont décrites en relation avec l'exemple du premier émetteur 1 1 1 du système présenté en figure 1.

Dans un premier temps 301 , l'application 141 exécutée par l'émetteur 1 1 1 formule une requête sémantique 312 au module sémantique

170. Cette requête peut être formulée, par exemple, dans le même langage que celui dans lequel sont formulées les requêtes de souscription au niveau des terminaux récepteurs 121 , 122, 123.

Dans un deuxième temps 302, la requête sémantique 312 est interprétée par le module sémantique 170 qui interroge la base de connaissances 180.

Dans un troisième temps 303, le module sémantique 170 reçoit les concepts et/ou instances de concept concernés par la requête sémantique 312 de la base de connaissances 180, c'est-à-dire les concepts et/ou instances de concept en adéquation sémantique avec la requête sémantique 312.

Dans un quatrième temps 304, pour chaque concept et/ou instance récupéré par le traitement de la requête sémantique 312, le ou les sujets 322 associés à ce concept ou à cette instance sont produits, en utilisant les moyens d'association 315.

Dans un cinquième temps 305, l'infrastructure 160 publie les sujets 322 produits par le module sémantique 170, par exemple, via des appels successifs à une fonction classique de publication disponible dans l'infrastructure 160.

Hormis la notion de sujets qui permet de différentier les données, dans certains systèmes de publication et souscription de données, le contenu des données échangées est défini par un type, autrement dit, par une description formelle du format des données échangées. Le type des données peut être défini par des langages de descriptions connus tels que

OMG IDL (« Interface Description Language »), XSD (« XML Schéma

Description ») ou par un diagramme UML (« Unified Modeling Language »).

Or, outre le couplage trop important provoqué dans l'art antérieur par la prise en compte uniquement de l'aspect syntaxique des sujets, la définition commune des types de données à échanger induit également des couplages entre émetteurs et récepteurs de données. Un deuxième mode de réalisation du système selon l'invention, présenté ci-après, se propose de résoudre ce deuxième aspect du problème de couplage en permettant à chaque terminal informatique présent sur l'infrastructure de publication et souscription de données de gérer ses propres types de données, l'infrastructure prenant en charge la traduction d'un type de données à l'autre.

La figure 4 illustre, à travers un schéma, un deuxième mode de réalisation du système de publication et souscription de données selon l'invention. Pour éviter que les types de données constituent un obstacle à l'interopérabilité entre applications, la base de connaissances 180 est utilisée comme pivot pour les applications 141 , 142, 151 , 152, 153 publiant ou souscrivant des données via l'infrastructure 160. En effet, la base de connaissances 180 définit un modèle de données commun à toutes ces applications 141 , 142, 151 , 152, 153.

Un module de traduction 270, relié à la base de connaissances 180 via le réseau 130, est implanté au moins dans chaque terminal informatique 1 1 1 , 1 12, 121 , 122, 123, ledit module de traduction 270 étant adapté, au niveau d'un terminal émetteur 1 1 1 , 112, à traduire une donnée exprimée à l'aide du type de donnée issu d'une application 141 , 142 exécutée par ledit terminal émetteur 1 1 1 , 1 12 vers une donnée au format de donnée pivot de la base de connaissances 180, et au niveau d'un terminal récepteur 121 , 122, 123, à traduire la donnée au format de donnée pivot vers une donnée exprimée à l'aide du type de donnée issu d'une application exécutée 151 , 152, 153 par ledit terminal récepteur 121 , 122, 123.

Les traductions peuvent être effectuées par l'exécution de scripts. Dans l'exemple, deux scripts peuvent être exécutés par le module de traduction 270, le premier script étant employé pour traduire une donnée d'un type de données issu d'une application vers le format pivot, et le second script étant employé pour traduire une donnée dans le format pivot vers la même donnée exprimée dans un type de données issu d'une application. Par exemple, lorsque pour une application, les types de données sont décrits via le langage XSD et que la base de connaissances est réalisée en utilisant le langage OWL ou RDF/S, alors des scripts XSLT (« Extensible Stylesheet Language Transformations ») peuvent être utilisés.

Les étapes nécessaires pour traduire une donnée exprimée dans le modèle pivot vers la même donnée exprimée dans le type de donnée propre à une application 141 , 142, 151 , 152, 153, ou pour traduire une donnée exprimée dans le type de donnée propre à une application 141 , 142, 151 , 152, 153 vers une donnée exprimée dans le modèle pivot, diffèrent selon le langage de description dudit format. A titre d'illustration, pour un langage de description tel que XSD, IDL ou un modèle de données décrit par un diagramme UML (« Unified Modeling Language »), la traduction d'une donnée est effectuée en trois étapes lors du transfert de cette donnée d'une application émettrice 141 , 142 vers l'infrastructure 160 ou de l'infrastructure 160 vers une application réceptrice 151 , 152, 153 : • dans un premier temps, le script de traduction correspondant au type de donnée d'origine (dans le cas d'une traduction vers le format pivot) ou au type de donnée cible (dans le cas d'une traduction à partir du format pivot) est fourni, par exemple, par la base de connaissance 180. Le script de traduction est choisi, par exemple, à partir d'un système d'annotation spécifié dans un document de définition du type de donnée, ce système d'annotation référençant la base de connaissances 180 ;

• dans un deuxième temps, le script de traduction fourni précédemment est exécuté sur la donnée d'origine pour exprimer cette donnée dans le format cible ;

• dans un troisième temps, la donnée d'origine est remplacée par la donnée dans le format cible ; ainsi, une donnée est publiée dans le format pivot et souscrite dans le format propre à l'application consommatrice 151 , 152, 153.

A titre d'illustration, la figure 5 présente un exemple d'une base de connaissances ontologique 180. Dans l'exemple de la figure 5, la base de connaissances 180 correspond au domaine militaire et comprend trois concepts principaux 501 , 502, 503 correspondant respectivement aux effets 501 d'une attaque, aux unités humaines 502, et au terrain 503 considéré. Chacun de ces concepts comprend plusieurs instances et/ou concepts liés.

Ainsi, les effets 501 sont liés par la relation sémantique « est un » 541 au concept de renseignement 51 1 , au concept de destruction 512 et au concept d'arrêt 513 ; puis le renseignement 51 1 peut être de type « attaque d'un réseau informatique » 513 ; lequel peut être une intrusion dans un réseau informatique 514, un déni de service 515 ou une destruction d'un réseau informatique 516. Le concept d'effets 501 est également lié au concept d'unités humaines 502 par la relation sémantique « produit par » 542. Les unités humaines 502 sont, dans l'exemple, des unités militaires 521 , des unités paramilitaires 522 ou des unités civiles 523 ; les unités militaires pouvant être par exemple des bataillons 524, les unités paramilitaires pouvant prendre la forme d'une force de sécurité 525 ou d'une unité de guérilla 526 et les unités civiles pouvant être des « Organisations Non Gouvernementales » 527. Enfin, les terrains 503 peuvent être déclinés, par exemple, dans les instances suivantes : montagne 531 , désert 532 et zone urbaine 533.

Lorsqu'une requête de publication ou de souscription, par exemple la requête 540 « arrêter une unité de guérilla en zone urbaine » est traitée par le module sémantique 170, les concepts en adéquation avec cette requête, en l'espèce, les concepts « arrêt » 513, « unité de guérilla » 526 et « zone urbaine » 533 sont considérés. Ces trois concepts 513, 526, 533 sont sémantiquement mis en relation par l'intermédiaire de la requête sémantique 540. La publication ou la souscription peut alors être réalisée sur un ensemble de sujets couvrant ces trois concepts. Dans un système de publication et souscription classique, une telle requête n'aurait aboutit à aucune transmission de données entre émetteurs et récepteurs, à cause de sa spécificité.

Un avantage du procédé selon l'invention est qu'il peut être mis en œuvre sur des systèmes existants sans nécessiter de modifications lourdes dudit système, l'infrastructure de publication/souscription pouvant être réutilisée et enrichie par la base de connaissances ontologique. Les interfaces d'appel de l'infrastructure déjà en place peuvent être réutilisées, ce qui facilite la mise en œuvre du procédé selon l'invention.

Un autre avantage de la méthode selon l'invention est que le code des applications échangeant des données via le système de publication et souscription n'est pas impacté puisque les scripts de traduction sont définis de manière externe aux dites applications et que ces scripts sont utilisés au moment des appels de publication ou souscription par l'infrastructure.