====== 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 [[:nomointerpreter#l_interface_avec_nomointerpreter|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. ==== La base de données ==== 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 : {{ :nomosdk:share:tables.png?700 |}} 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 et la visualisation ==== 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. {{ :nomosdk:fr:log_fr.png?500 |}} **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 [[nomoSDK:bancs_essais#description_des_donnees_et_leurs_visualisation|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. ==== Exemples de requête ==== 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 {{ :nomosdk:fr:SQL_2_fr.png?325}}{{:nomosdk:fr:SQL_1_fr.png?325|}} 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 {{ :nomosdk:fr:SQL_3_fr.png?325}}{{:nomosdk:fr:SQL_4_fr.png?325|}} 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 {{ :nomosdk:fr:SQL_6_fr.png?325}}{{:nomosdk:fr:SQL_5_fr.png?325|}} 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 {{ :nomosdk:fr:SQL_8_fr.png?325}}{{:nomosdk:fr:SQL_7_fr.png?325|}} 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' {{ :nomosdk:fr:SQL_9_fr.png?325}}{{:nomosdk:fr:SQL_10_fr.png?325|}} 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'