aucun commentaire

Thing’in, la plateforme du graphe des objets

Les écoliers n’ont plus guère besoin d’apprendre l’arithmétique élémentaire, qu’ils ne pratiquent plus. Ils devraient désormais plutôt apprendre la théorie des graphes, qu’ils pratiquent déjà tous les jours avec les réseaux sociaux ! Comme les réseaux sociaux sont des « graphes de personnes », Thing’in, une plateforme intégrative de recherche initiée par Orange, est un « graphe d’objets », un graphe dont les nœuds sont, au lieu de personnes, des objets et entités physiques de toute nature.

Figure 1 Un graphe de réseau social comparé à un graphe d’objets et entités physiques, »à la Thing’in » !

Thing’in n’ouvre rien de moins qu’un nouveau domaine d’application de cette vénérable et foisonnante théorie des graphes, qui, issue des mathématiques pures, avait depuis longtemps essaimé vers de nombreux domaines des sciences et de l’ingénierie.

Les réseaux sociaux ont également, parmi bien d’autres, popularisé la notion de plateforme multi-faces. A l’instar des réseaux sociaux, Thing’in joue, sur la base du graphe qui en constitue le cœur, un rôle de médiation d’information entre différentes catégories d’utilisateurs (les « faces » de la plateforme). Les développeurs d’applications de l’Internet des Objets seront les utilisateurs présents à la face supérieure de la plateforme, tandis que les fournisseurs de données sur la face inférieure de la plateforme, sont, pour Thing’in, les réseaux ou plateformes classiques de l’Internet des Objets (IoT) que Thing’in a vocation à élargir et fédérer, dans un sens que nous allons expliciter.

Figure 2 : Les « faces » de la plateforme Thing’in

Dépasser l’Internet des Objets « à l’ancienne »

L’internet des Objets et le M2M ont d’abord cherché à relier à des réseaux, au sens classique des télécoms, de nouvelles catégories d’objets promus au rang d’ « objets connectés ».

Dans l’analogie avec les réseaux sociaux, cela correspondrait à un stade où on représenterait comme nœuds de ces réseaux non pas les personnes elles-mêmes, mais les smartphones ou PC (devices)  que ces personnes utilisent pour s’y connecter. Bien sûr les réseaux sociaux ont depuis longtemps dépassé ce stade : on ne sait pas en général quels moyens de connexion relient effectivement les nœuds de ces réseaux et ils peuvent même être des événements, des productions artistiques ou des personnages historiques non équipés de smartphones !

Dans une vision que nous avons mise en avant de longue date, Thing’in va également bien au delà des devices connectés de l’IoT classique (typiquement capteurs ou actionneurs en réseau), pour intégrer les objets et entités physiques de toute nature (par exemple des pièces dans l’exemple de la figure 1) qui sont observés par ces capteurs, ou commandés par ces actionneurs : ce sont en fait ces entités-non-directement-connectées qui seront les nœuds primitifs du graphe, les devices connectés leur servant seulement d’intermédiaires.

Un graphe, oui, mais de quoi ?

La structure, l’abord !

Le graphe Thing’in n’est donc pas, au premier chef, un graphe de connectivité au sens des réseaux télécoms. Les nœuds primitifs du graphe composent une description structurelle d’un environnement, vu comme un système décrit par les relations entre ses composants ou sous-systèmes. Sur les exemples d’un bâtiment aux figures 3 et 4, les nœuds principaux du graphe sont les pièces, ou des sur-ensembles de celles-ci comme des étages, et ces pièces contiennent elles-mêmes des objets de toute nature comme des chaises et des tables. Les relations entre ces objets sont décrites par des arcs dont le type définit la nature : « est_contenu_dans », « est_un_sous-système_de » ou « est_adjacent_à ». Les devices  au sens IoT (capteurs et actionneurs connectés) sont bien sûr également présents dans le graphe, comme montrés sur les exemples. Ils peuvent être associés (via des relations) à des entités auxquelles ils apportent une présence sur le réseau, comme un smartphone apporte la connectivité à un membre d’un réseau social. Sur le premier exemple ci-dessous, un capteur de température connecté et une lampe connectée sont respectivement des capteurs et actionneurs associés à une pièce de bureau. L’ensemble de ces relations va permettre de distinguer, dans la structure de la pièce en tant que système, comment elle comprend un certain nombre de parties qui peuvent en être des sous-systèmes, c’est à dire des composants inhérents comme les portes ou les fenêtres, ou des objets simplement contenus comme des chaises ou des tables qu’on voit représentés dans le 2e exemple ci-dessous.

Figure 3 : exemple d’un sous-ensemble de graphe de bâtiment avec objets connectés (lien avec démonstration sur la plateforme Thing’in)

Figure 4 : exemple d’un sous-ensemble de graphe de bâtiment avec objets non-connectés (lien avec démonstration sur la plateforme Thing’in)

Ces diagrammes donnent deux exemples de représentations du graphe plaqué sur un plan en perspective, avec les nœuds correspondants à deux pièces dans leur environnement, et les entités associées. La visualisation directe du graphe correspondant à partir de la plateforme Thing’in offerte en hyperlien permet de voir l’identité des nœuds et les arcs en les survolant, tandis qu’un clic droit permet d’obtenir toute l’information détaillée stockée dans la base.

La sémantique, ensuite !

Dans le graphe Thing’in, on peut dire que la structure précède la sémantique. Le graphe Thing’in n’est pas seulement une base de connaissances, comme le célèbre « Knowledge Graph » de Google. Il est également bien distinct dans le principe des graphes basés sur le méta-modèle RDF, qui sont d’abord destinés à représenter des données comme « atomes de connaissance ». Un graphe RDF comporte un seul type d’arcs, correspondant à des prédicats au sens de la logique du premier ordre.  Le graphe Thing’in fait appel en au contraire à un méta-modèle plus expressif et mieux adapté à la représentation d’une structure de données complexe indépendamment de sa sémantique. Ce méta-modèle, appelé couramment « property graph » (plus précisément un multigraphe orienté, marqué & attribué) est issu des bases de données orientées-graphes, et fait une distinction entre  les relations entre objets qui sont les nœuds principaux du graphe, et les propriétés, sous forme d’attributs clés-valeurs qui peuvent être associées à ces nœuds du graphe, mais aussi à ses relations, voire aux propriétés elles-mêmes (ce qui, d’un point de vue théorique, correspondrait à de la logique du 2e ordre). Ces propriétés ont une pour cible un nombre ou une chaîne de caractère (un littéral au sens de RDF, et de la programmation), mais pas une autre entité. Elles comprennent à la fois des caractéristiques instantanées de chaque entité (la température moyenne d’une pièce ou son état d’occupation), mais aussi des caractéristiques permanentes (la surface ou la destination de la pièce).

La sémantique apparaît d’abord dans le graphe Thing’in par une assignation  systématique de toute entité (nœud), propriété ou relation à une classe ou catégorie analogue aux types des langages de programmation, avec la contrainte que ces types ne sont pas définis au cas par cas, mais doivent, suivant les bonnes pratiques issues du web sémantique, être issues d’ontologies ou vocabulaires formellement définis, publiques et si possible « bien connus ». Les mini-démonstrations de la plateforme Thing’in montrées à la section précédente illustrent cette différence entre le type « informel » en langage naturel associé à un nœud (celui qu’on voit par survol du nœud) et le type formellement défini par une URI associée à une ontologie, qu’on obtient par clic droit. Une autre bonne pratique, moins évidente, de la modélisation sémantique, qui la distingue aussi de la modélisation de données basique utilisée en programmation est que l’information doit toujours être « remontée » au niveau le plus général possible. Ainsi, une information qui peut être définie pour une catégorie (comme l’association de l’unité °C à une mesure de température) devient ainsi une connaissance, et n’a plus besoin d’être associée à chaque instance d’information correspondant à cette catégorie. Une contrainte réciproque est que la définition d’une catégorie ne doit pas contenir quoi que ce soit de spécifique à une instance ou une sous-catégorie.

Cette sémantique n’est pas première dans le graphe Thing’in. Ceci veut dire qu’elle n’est pas un prérequis obligatoire à l’acquisition de données dans le graphe; et aussi et surtout qu’elle peut être vue comme l’aboutissement d’un processus incrémental et itératif, dans lequel la structure du graphe génère sa propre sémantique, ainsi que les graphes des moteurs de recherche du web et des réseaux sociaux ont su le faire depuis longtemps. Ainsi un membre d’un réseau social ne fournit en général pas explicitement une information de type « sémantique » sur des « catégories » auxquelles il s’auto-assignerait, et cependant le recoupement de ses préférences et celles de ses relations  permet aux gestionnaires des réseaux sociaux de recouper précisément cette information à l’insu de leurs membres, et de les utiliser lucrativement, comme on sait….D’une manière moins inquiétante pour la vie privée des personnes, le graphe Thing’in peut, dans l’ exemple de la figure 4, catégoriser automatiquement un nœud « pièce » correspondant à une salle de réunion par rapport à l’autre nœud correspondant à un bureau  en les distinguant par les liens avec les objets chaises et tables qu’ils contiennent, et ce même si la catégorie sémantique de ces pièces n’avait pas été fournie au départ de manière explicite et formelle en les créant dans la base de données.

Pour faire quoi?

La figure 2 illustre le positionnement relatif de Thing’in par rapport aux plateformes pour l’Internet des Objets plus classiques comme FIWARE ou DataVenue. Ces plateformes servent de source de données à Thing’in, mais elles sont aussi, à la différence de Thing’in,  « en coupure » entre les sources de données IoT et les applications qui les utilisent : les données issues des réseaux de capteurs IoT sont concentrées, consolidées et stockées dans ces plateformes avant d’être relayées vers les applications. Thing’in n’a, au contraire, pas vocation à stocker ces données brutes, mais uniquement l’information structurelle et sémantique sur la configuration de l’environnement dont ces données sont issues. Thing’in serait donc plutôt utilisé dans la configuration d’une application, pour la relier aux sources de données pertinentes pour elle sur la base de l’information stockée sur le graphe Thing’in, qui permet de trouver les sources de données pertinentes à partir de requêtes haut-niveau supposant un minimum de connaissance a priori, comme le fait un moteur de recherche.

Thing’in peut également importer et exporter des données à partir du web des données en général, en effectuant une conversion entre le modèle RDF et le modèle « property graph » le cas échéant. Même si Thing’in joue déjà le rôle d’une plateforme fédératrice, elle peut donc aussi, à ce niveau, être vue comme un élément de la plateforme fédératrice ultime qu’est le web des données.

Laissez-nous votre commentaire