Import depuis un modèle concret vers un modèle abstrait

La section “6.3.1. Principe et spécifications” présente la fonction d'import que j'ai écrite et qui est basée sur Structure_map. Cette fonction effectue une analyse de type top-down avec retour sur trace [backtracking] et a une complexité exponentielle. La section “6.3.2. Complétude” montre que cette fonction est complète au sens où tous les EAs qui peuvent être extraits de son entrée sont effectivement extraits.

6.3.1. Principe et spécifications

Dans cette thèse, un processus d'import prend en entrée des éléments textuels ou graphiques et a en sortie des EAs (cf. section “3.1. Import de connaissances”). Ainsi, un tel processus extrait des EAs pour un modèle abstrait particulier à partir d'un texte ou d'un graphique. L'import fonctionne comme l'export mais en sens inverse. Comme le montre la figure ci-après, un processus d'import exploitant KRLO peut utiliser les spécifications de notations des types d'EAs concernés pour extraire des instances de ces types.

118/ 154 Comme SRS ne prend en entrée que des RichGraph, SRS ne peut pas être directement utilisé directement pour l'import. SRS pourrait être utilisé dans un processus d'import où le texte (ou le graphique) en entrée serait d'abord importé dans un RichGraph. Par exemple, chaque terme pourrait être importé dans une unique jb#List puis cette liste pourrait être donnée en entrée à SRS. Un tel import (vers une jb#List) peut être réalisé via un tokenizer. Le principe de l'import depuis cette liste vers un EA structuré est décrit dans le paragraphe suivant.

Pour chaque EA du modèle (donné en paramètre de l'import), la spécification d'export pour la notation (donné en paramètre de l'import) est testée via une “fonction d'import”. Cette “fonction d'import” spécifie i) le parcours de la spécification d'EC (par exemple : List(f_OP_from_(?ae) "(" f_ARGS_from_(?ae) ")"), cf. 4.1.3.3. et 4.1.4.), ii) développe puis compare chaque élément ainsi parcouru au token courant dans la chaîne de caractère en entrée. Cette comparaison permet soit d'invalider la règle testée, soit de poursuivre le test sur le token suivant.

J'ai écrit des fonctions en FL pour importer des EAs structurés depuis une liste d'ECs non structurés. Ces fonctions sont décrites ci-après. Dans son implémentation actuelle, SRS peut théoriquement traiter ces fonctions. En pratique, je dois d'abord i) optimiser le code afin de diminuer temps de calcul, et ii) terminer le développement de TPatternBuilder.

jb#f_import_list_of_token_to_AE

input: 1 List ?list_of_token, param: 1 KRL_model ?model 1 KRL_notation ?notation, output: 1 AE, := jb#f_import_fct _(?list_of_token, ?model, ?notation).first;

jb#f_import_fct //retourne une liste dont le premier élément est un EA structuré //et donc le second élément est la liste restante des tokens à importer input: 1 List ?list_of_token,

param: 1 KRL_model ?model 1 KRL_notation ?notation, output: 1 List,

:= jb#Simple_graph_map _(jb#f_all_possible_new_AE_instances _(?model, ?notation), ^( jb#f_test_spec input: ?list_of_token ?model ?notation),

jb#f_thing_that_does_not_have_for_r-part_a_parse_error );//si aucune règle //valide renvoie null //f_all_possible_new_AE_instances créée et renvoie une liste d'individus.

//Chaque individu de cette liste a pour type l'un des types d'AEs de ?model. jb#f_all_possible_new_AE_instances

param: 1 KRL_model ?model 1 KRL_notation ?notation, output: 1 List, := jb#Simple_graph_map _( ?model.r_KRL_type_of,

^(jb#fquery_has_specs input: ?notation), jb#fquery_build_list_of_instances_of_AE ); jb#fquery_has_specs

input: 1 AE ?ae 1 KRL_notation ?notation,

:= [ [?ae rc_spec: (a List r_2nd_arg: (?notationSet r_member: ?notation))] ]; jb#fquery_build_list_of_instances_of_AE

input: 1 AE ?ae, output: 1 List ?result, := [ [?result head: (Individual type: ?ae), tail: 1 List] ];

//f_test_spec construit les parties (operateur et arguments) d'un AE suivant

//les spécifications de notations et la liste de tokens à importer ou renvoie une erreur jb#f_test_spec

input: 1 AE ?ae 1 List ?list_of_token, param: 1 KRL_model ?model 1 KRL_notation ?notation, output: 1 List,

:= jb#Simple_graph_map _( jb#fc_find_specs _(?ae, ?notation)

^(jb#f_compare_spec_element_with_string_token input: ?list_of_token.head, ?ae,

//f_compare_spec_element_with_string_token i) compare chaque élément de la liste de spécifications //avec le token courant, ii) créée les relations entre l'EA courant et ses parties,

//et iii) détecte les erreurs

jb#f_compare_spec_element_with_string_token

input: 1 List_or_string ?spec_element //e.g. result of f_op_from_(?ae) or "(" 1 String ?string_token 1 AE ?ae 1 List ?list_of_token,

param: 1 KRL_model ?model 1 KRL_notation ?notation,

:= if_then_else _([?spec_element.first < r_part], //si ?spec_element spécifie un rôle pour l'EC

/*then*/if_then_else _([?spec_element.second = ?string_token], //si ?string_token est une notation //spécifiée par défaut dans KRLO //le test ci-dessus ne renvoie "vrai" que si i) ?spec_element.first = r_operator et // ii) ?spec_element.second renvoie le résultat de rc_operator_name

/*then*/jb#f_add_operator_name _(?ae, ?string_token), /*else*/if_then_else _([?spec_element.first = r_args],

/*then*/ jb#f_create_args _(?ae, ?list_of_token, ?spec_element),

/*else*/if_then_else _(jb#fc_find_specs(jb#f_such_AE_part(?ae, ?spec_element.first), ?model,

?notation),

/*then*/jb#f_test_spec _(jb#f_build_AE _( ?ae, ?spec_element.first ), ?list_of_token),

/*else*/ jb#f_add_relation_to_Type_as_AE _( ?string_token, ?spec_element ) ) ) ) //ci-dessous, ?spec_element est un string car ne défini pas de rôle

/*else*/if_then_else([?spec_element = ?string_token]

/*then*/List(null, ?list_of_token.tail), //aucune erreur mais pas d'EA à importer /*else*/List(jb#parse_error, ?string_token) ) );//la règle courante n'est pas applicable jb#f_add_operator_name

< Generation_function,

input: 1 AE ?ae 1 String ?string_token 1 List ?list_of_token, output: 1 List, := List( (?ae rc_operator_name: ?string_token)

?list_of_token.tail );

jb#f_create_args //cherche un élément de sucre syntaxique qui sépare la séquence d'argument du prochain AE //et ajoute une relation r_arg depuis ?ae vers chacun des arguments importés

< Generation_function,

input: 1 AE ?ae 1 List ?list_of_token,

param: 1 List_or_string ?spec_element 1 KRL_model ?model 1 KRL_notation ?notation, output: 1 List,

:= if_then_else_([?list_of_token.head = ?spec_element.nextElement] /*then*/List(?ae ?list_of_token),

/*else*/jb#f_create_args _( (?ae r_arg: jb#f_import_fct _(?list_of_token, ?model, ?notation).first), jb#f_import_fct _(?list_of_token, ?model, ?notation).second,

?spec_element ) ); jb#f_such_AE_part

input: 1 AE ?ae 1 r_part ?rel, output: 1 AE ?result, := [ ?ae ?rel: ?result ]; //e.g. AE@FL r_op: 1 Concept_node jb#f_build_AE

< Generation_function,

input: 1 AE ?ae 1 r_part ?rel, := (AE ?rel: ?ae);

jb#f_add_relation_to_Type_as_AE < Generation_function,

input: 1 String ?string_token 1 function_or_string ?spec_element 1 AE ?ae, output: 1 List, := List( (?ae ?spec_element.first: (Type_as_AE

r_description_instrument of: find_content(?string_token)) ) ?list_of_token.tail);

120/ 154

6.3.2. Complétude

Définition

Complétude d'une fonction d'import : tous les EA qui peuvent être extraits de l'entrée de la fonction sont en sortie, en supposant que l’ontologie de LRCs en paramètre soit complète.