Caractéristiques attendues du système

Nous décrivons ici les caractéristiques principales qu’offre l’architecture que nous proposons. Elles sont exposées brièvement dans l’objectif de fournir une vue d’ensemble. La section 4.4 détaille chaque élément du système, tout en décrivant comment ces ca-ractéristiques sont adressées.

4.3.1 Vue d’ensemble

La figure 4.1 présente l’architecture et l’illustre sur la base d’un fragment de trois règles (R₁, R₂ et R₃) et permet de comprendre le circuit qu’emprunte chaque type de triple.

L’architecture de notre système de raisonnement incrémental est modulaire. Des mo-dules nommés exécuteurs ont la charge de l’application des règles. Les exécuteurs sont indépendants les uns des autres. Chacun est dédié à une règle du fragment logique consi-déré. Une même règle peut faire l’objet de plusieurs exécuteurs. Un triplestore central est accessible par les modules afin de stocker et partager l’ensemble des connaissances disponibles. Les triples provenant de flux de données sont envoyés au distributeur

général, point d’entrée du système.

Les triples sont générés par des objets connectés, des systèmes de connaissances ouverts, ou d’autres systèmes similaires. Ils sont produits continuellement au cours du temps, constituant autant de flux d’entrée. Le distributeur général transmet les triples arrivant au triplestore pour consignation, ainsi qu’aux buffers (ou espaces tampons) d’une sélection de modules : ceux acceptant ce type de triples en entrée. Lorsqu’un buffer est saturé ou que le délai de temporisation (timeout) est atteint, la règle associée est ap-pliquée sur les triples contenus dans le buffer afin d’extraire les connaissances implicites. Les données présentes dans le triplestore sont utilisées pour l’inférence. Un

distribu-teur est chargé d’enregistrer les triples inférés dans le triplestore et de les redistribuer

aux buffers de la même manière que le distributeur général. Le distributeur

gé-néral est un distributeur auquel sont abonnés tous les buffers. Le fonctionnement de

TRIPLESTORE Flux de triples R₂ R₂ R₁ R₂ R₁ R₃

Distributeur Général Buffers Gestionnaire de

processus légers ^{Distributeurs}

R₁ R₂ R₁ R₃ R₂ Accès concurrent Exécuteurs de règles Distributeur Général ^R2 R₂ R₁ R₃

R

R

R

Figure 4.1 – Architecture proposée pour le raisonnement incrémental sur des flux de triples

4.3.2 Exécution parallèle et passage à l’échelle

L’un des aspects critiques d’un raisonneur est sa capacité à gérer de grands volumes de données. Afin de permettre à notre solution de passer à l’échelle, son architecture a été conçue sous la forme de modules indépendants. Chaque module dispose de son propre processus léger, permettant à l’ensemble des modules de s’exécuter de manière parallèle. Chaque règle d’inférence est associée à un module indépendant. Ils reçoivent les triples pouvant être utilisés par la règle à laquelle ils sont associés et redistribuent les triples inférés aux autres modules afin de continuer l’inférence.

Plusieurs exécutions d’une même règle d’inférence sur différents ensembles de triples peuvent être lancées par un même module. Cela permet d’éviter une attente du système dans le cas où une règle serait particulièrement sollicitée. Si une règle est déjà en cours d’exécution et que d’autres triples compatibles avec ses prémisses arrivent, une nouvelle instance de cette règle pourra être lancée pour ne pas mettre le système en attente.

De manière à s’assurer que chaque triple envoyé dans le raisonneur est traité, un espace tampon associé à chaque règle récupère les triples qui peuvent être utilisés par la règle. Cela permet de gérer le nombre de triples arrivant ou inférés. Le fonctionnement de ces espaces tampons est détaillé dans la section 4.4.2.

4.3.3 Limitation des doublons

Comme cela a été souligné dans différents travaux de l’état de l’art [55, 64, 46, 65], l’un des problèmes majeurs du raisonnement est la génération inévitable de doublons, qui freine le processus d’inférence. Une solution est de supprimer ces doublons au plus tôt, dès leur génération, afin d’empêcher leur dispersion dans le système. Dans notre architecture, chaque module dispose d’un accès concurrent à l’ensemble des données dis-ponibles, stockées dans un triplestore, qu’elles soient inférées ou originaires d’un point d’entrée. Cela permet d’interdire la dispersion d’un triple déjà inféré dans le système. Les doublons sont générés, mais supprimés avant d’être renvoyés dans un autre module du système. De plus, de par son architecture, le triplestore est imperméable aux dou-blons. De manière similaire à la technique présentée dans les travaux de Heino [55], la suppression se fait à deux échelles : au niveau des modules en supprimant les doublons générés à l’intérieur même du module et à un niveau global en vérifiant si les triples inférés dans le module ne sont pas déjà présents dans le triplestore. De cette manière, chaque triple n’est considéré qu’une seule fois, réduisant le risque de redondance dans les triples inférés.

4.3.4 Gestion de flux de données

La nature dynamique du Web [25] a mené à la mise à disposition de données sous forme de flux. Le raisonnement est souvent considéré comme un processus ponctuel, uti-lisant des règles connues par avance. L’évolution constante des bases de connaissances nous impose cependant d’aller vers des systèmes continus et adaptatifs. L’aspect

paral-lèle intrinsèque de notre architecture, gérant des flux de triples circulant à travers les différents modules, lui permet nativement de recevoir des données venant à la fois de sources statiques et de multiples flux de données.

4.3.5 Agnosticisme au fragment

Comme nous l’avons vu dans l’état de l’art, il existe un grand nombre de règles d’inférence, réparties dans différents fragments. Afin de fournir une solution la plus générique possible et apte à répondre à un maximum de besoins, nous proposons une architecture agnostique au fragment. L’accent a été mis sur l’évolutivité du système, plutôt que sur l’optimisation pour un fragment donné. Il est donc possible d’ajouter et/ou de supprimer des règles au fragment utilisé. En plus d’être compatible avec les règles prédéfinies, entre autres par le W3C [77], notre architecture prend en charge toute règle implémentée en suivant une spécification sous la forme d’une interface Java, dont les détails sont donnés dans la section 4.5.2.