nomoSDK : la journalisation

L'exploitation de la journalisation repose sur une base de données constituée d'une part par les informations sur les types avec leurs items ainsi que leurs composantes s'il y a lieu, le nom des règles initiales et, d'autre part, les informations issues de la journalisation au cours de l'interprétation.

Cette organisation permet d'effectuer des requêtes à l'aide du langage SQL (correspondant à celui de SQLite) et de visualiser les résultats sous la forme soit d'un tableau, soit d'un graphique.

Plus précisément, la base de données repose sur neuf tables. Chaque table correspond à un fichier CSV, la relation entre les tables correspond aux liens de la figure ci-dessous, où les champs en gras indiquent la clé primaire :

Une base de données minimales correspond aux quatre tables générées à l'édition des liens d'une unité au même endroit que le fichier .seed, soit : type, item, component et rule.

Les champs model, program et scheme sont structuré de la manière suivante :

• Le champ model se définit comme la liste des bases parents du modèle séparées par un espace jusqu'à au nom du modèle prototype suivi de ”:” puis le nom de l'instance, soit : [base ]prototype:instance.
• Le champ program se définit comme le nom du programme principal suivi de la liste des programmes séparés par un espace et identifié par le couple programme prototype suivi de ”:” puis le nom de l'instance, soit : program[ prototype:instance].
• Le champ scheme se définit comme la liste des schèmes parents des programmes séparés par un espace, le premier étant obligatoirement identique au nom du programme.

Une journalisation partielle correspond uniquement à la table log. Une journalisation complète rajoute à cette dernière les tables suivantes : input, output, premise, conclusion.

À noter, le champ specificity_log correspond à deux fois le logarithme de base dix de la spécificité de la prémisse sans la racine de deux Pi.

L'interface se décompose en quatre partie : la gestion de la base, l'espace pour formuler la requête, la gestion de la visualisation et en dessous l'espace de visualisation comme l'illustre la figure ci-dessous.

L'ouverture d'une base de données passe par la désignation du répertoire contenant obligatoirement les fichiers type.csv, item.csv, component.csv et rule.csv. Si les fichiers correspondant aux autres tables sont également présents, ils seront automatiquement pris en compte.

L'ajout d'un fichier de journalisation (.pr ou .fr) complétera les tables déjà créées ou créera les tables nécessaires.

La réinitialisation correspond à la suppression des fichiers log.csv, premise.csv, input.csv, conclusion.csv, output.csv se trouvant dans le répertoire et, au rechargement des fichiers type.csv, item.csv, component.csv et rule.csv.

L'espace de requête avec le langage SQL peut être chargé par l'ouverture d'un fichier .sql. La validation de la requête s'effectue au moment du choix du type de visualisation.

La visualisation d'un tableau ou d'un graphique peut s'agrémenter de couleurs avec les conventions suivantes :

La présence des trois colonnes hue, saturation et luminance indique la couleur des lignes de données sans faire partie, en tant que valeur, de la vue. Sauf, si hue, saturation et luminance sont les seules colonnes pour une visualisation par tableau, si hue, saturation et luminance sont les seules colonnes plus une pour une visualisation par graphique.

La présence d'une colonne nommée color indique la couleur des lignes de données sans faire partie, en tant que valeur, de la vue. Sauf, si color est la seule colonne pour une visualisation par tableau ou color est la seconde colonne pour une visualisation par graphique.

La visualisation par graphique n'est possible que pour des données possédant au moins deux colonnes ; sinon la visualisation se trouve automatiquement convertie en tableau.

Par convention, la colonne nommée time sert d'abscisse. Si cette colonne n'apparaît pas, alors toutes les combinaisons graphiques deux à deux sont présentées. Ce dernier mode de représentation convient, par exemple à la visualisation des vecteurs d'entrées comme pour la représentation des nuages de points du banc d'essai.

L'exportation d'une vue tableau se traduit par un fichier au format CVS et l'exportation d'une vue graphique se traduit par un fichier au format SVG.

Les quatre premiers exemples d'une visualisation en mode tableau illustre l'emploi de la convention pour la colorisation sur la table type concernant le champ name.

La figure de gauche, ci-dessous, colorise le nom des types en fonction de l'identifiant du type avec la requête SQL suivante :

SELECT name, type_id AS color FROM type

La figure de droite, ci-dessous, colorise le nom des types en fonction de la colorisation des types définie lors de leur édition avec la requête SQL suivante :

SELECT name, hue, saturation, luminance FROM type

La figure de gauche, ci-dessous, colorise les champs des types sauf les champs définissant la couleur (hue, saturation et luminance) avec la requête SQL suivante :

SELECT * FROM type

Visualiser également les champs hue, saturation et luminance nécessite de dupliquer ces colonnes comme dans la requête SQL suivante :

SELECT name, hue, saturation, luminance, hue, saturation, luminance FROM type

Les six exemples qui suivent illustrent la convention utilisée pour la visualisation graphique.

La figure de gauche, ci-dessous, affiche la credibility et la relevance des règles journalisées dans la table log avec la requête SQL suivante :

SELECT credibility, relevance FROM log

La figure de droite, ci-dessous, affiche la credibility et la relevance des règles journalisées en fonction du temps time dans la table log avec la requête SQL suivante :

SELECT time, credibility, relevance FROM log

La figure de gauche, ci-dessous, affiche la credibility des règles journalisées en fonction du temps time dans la table log avec une colorisation en fonction de l'identifiant des règles, soit la requête SQL suivante :

SELECT time, credibility, rule_id AS color FROM log

La figure de droite, ci-dessous, affiche la credibility des règles journalisées en fonction du temps time après 560s dans la table log avec une colorisation en fonction de l'identifiant des règles, soit la requête SQL suivante :

SELECT time, credibility, rule_id AS color FROM log WHERE time > 560000 

La figure de gauche, ci-dessous, affiche la credibility des règles journalisées en fonction du temps time après 560s dans la table log avec une colorisation en fonction de la couleur du type. Cette dernière information se trouve dans la table type, il faut donc effectuer des jointures. La première jointure s'effectue entre la table log et la table rule ; comme les champs d’appariement possèdent des noms identiques, une jointure naturelle est utilisée. La jointure entre la table rule et type ne peut être naturelle car elles possèdent des champs de même nom mais pas de même signification, il est alors nécessaire de préciser les champs sur lesquels repose la jointure. Soit la requête SQL suivante :

SELECT time, credibility, hue, saturation, luminance
FROM log NATURAL JOIN rule
JOIN type ON type.type_id = rule.type_id
WHERE time > 560000

La figure de droite, ci-dessous, affiche la credibility des règles journalisées en fonction du temps time dans la table log de type perception avec le nom “hue” selon une colorisation en fonction de l'identifiant des règles. Soit la requête SQL suivante, à noter la désambiguïsation du champ name :

SELECT time, credibility, rule_id AS color
NATURAL JOIN rule
JOIN type ON type.type_id = rule.type_id
WHERE category = 'perception' AND type.name = 'hue'

Pour la visualisation de prémisses d'entrée ou de conclusion avec un vecteur de sortie, l'utilisation de requêtes imbriquées est inévitable, par exemple pour une entrée avec deux composantes 'x' et 'y' :

SELECT xLocal.time AS time,
       xLocal.value AS x,
       yLocal.value AS y
FROM (SELECT time, value FROM input WHERE INDEX=1) AS xLocal,
     (SELECT time, value FROM input WHERE INDEX=2) AS yLocal
WHERE xLocal.time = yLocal.time")

Les exemples qui suivent concernent les requêtes portant sur les champs complexes comme program, scheme ou model. Ces exemples s'appuient sur l'emploi de la fonction SQL de SQLite “LIKE” qui analyse les chaînes de caractères.

L'opérateur LIKE correspond à un opérateur de comparaison. L'opérande à droite de l'opérateur LIKE contient le motif et l'opérande de gauche contient la chaîne à faire correspondre le motif. Un symbole pour cent (”%”) pour l'opérateur LIKE correspond à une séquence de zéro ou plusieurs caractères de la chaîne. Un trait de soulignement (“_”) correspond à tout caractère unique dans la chaîne.

Rechercher tous les types appartenant à un modèle dont la base racine se nomme 'exemple' :

SELECT name FROM type WHERE model LIKE 'exemple %'

Rechercher tous les types appartenant à un modèle dont une base se nomme 'exemple' :

SELECT name FROM type WHERE model LIKE '%exemple %'

Rechercher tous les types appartenant à un modèle dont le prototype se nomme 'exemple' :

SELECT name FROM type WHERE model LIKE '%exemple:%'

Rechercher tous les types appartenant à un modèle dont l'instance se nomme 'exemple' :

SELECT name FROM type WHERE model LIKE '%:exemple'