La section “6.2.1. Nécessité d'une traduction entre EAs” donne plus de détails sur la nécessité de traduire des EAs d'un modèle vers un autre.
3) Language_element = sbvr:Expression
Dans KRLO_2014, sbvr:Expression et Language_element sont équivalents. Or, en vérité, ces concepts ne sont pas équivalents. En effet, Language_element réfère à des EAs et des ECs et, comme expliqué dans le paragraphe ci-dessous, sbvr:Expression ne réfère qu'à des ECs. Donc, pour une phrase donnée, un analyseur [parser] exploitant SBVR plutôt que KRLO ne peut extraire qu'une unique structure pour cette phrase et cette structure est un CST. Dans la correction que j'ai apportée, sbvr:Expression est équivalent à Concrete_element.
Dans la documentation de SBVR, sbvr:Expression a la définition suivante : “ something that expresses or communicates, but considered independently of its interpretation”. Cette documentation fournit également les exemples suivants : “the sequence of characters "car" ”, “the entire text of a book”, “a diagram”. Les seules spécialisations de sbvr:Expression fournies sont sbvr:Text – toute chaîne de caractères –, sbvr:URI – un sous-type de sbvr:Text – et sbvr:Signifier – un sous-type de sbvr:Expression utilisé pour représenter un concept. Entre ces quatres types (sbvr:Expression, sbvr:Text, sbvr:URI, sbvr:Signifier), seules des relations de spécialisation sont écrites dans la documentation. Ainsi, un analyseur [parser] exploitant SBVR pour importer des phrases écrites dans un LRC ne peut extraire que des éléments de ces quatre types et des relations structurelles "r_part" entre ces éléments. De plus, ces éléments sont des éléments de notation.
4) Export incorrect vers JSON-LD+OWL/JSON-LD_notation
Une proposition de Philippe Martin pour les spécifications de présentation des EAs de JSON-LD+OWL/JSON-LD_notation était incorrecte. En exploitant ces spécifications, une fonction d'export avec en entrée la phrase “Toute entreprise a au moins un employé” a la sortie ci-après.
{ "@id": "Company";
"owl:subClassOf": { "@type": "owl:Restriction",
"hasEmployee": { "@type": "Person" } } }
Cette notation ne peut pas être interprétée par un importeur OWL. Une notation correcte est présentée ci-dessous.
{ "@id": "Company",
"owl:subClassOf": { "@type": "owl:Restriction", "owl:onProperty": "hasEmployee", "owl:someValuesFrom": "Person"} }
5) Nommage ambiguë d'une fonction
Dans KRLO_2014, une fonction “partition_except_for_(Thing)” est utilisée pour spécifier une partition entre Concept_type et Relation_type à l'exception du type Thing. J'ai fait remarquer à Philippe Martin que l'utilisation du type Thing comme paramètre de cette fonction pouvait porter à confusion. En effet, un utilisateur pourrait croire que la sémantique de cet appel serait d'exclure toute instance du type Thing et donc toute l'ontologie.
Dans KRLO_2015+, “partition_except_for_(Thing)” n'est plus utilisé, un commentaire indique le concept Thing est une exception dans toutes les partitions.
4.2.2. Spécifications de notations des éléments de modèle abstrait dans KRLO_2014
Dans KRLO_2014, j'ai spécifié des représentations concrètes d'EAs dans les notations CLIF, RIF-PS et dans la notation de JSON-LD. Ces descriptions sont données ci-dessous.JSON-LD_model r_only_such_part_of_that_type:
^(Phrase rc_type: fc_infix_list-like_frame_type _(List(JSON-LD_notation),"","{",",\n","}")) ^(Link rc_type: fc_half-link_type _(List(JSON-LD_notation),"",": ","",""))
^(Fterm_or_variable > Constant_or_set_or_closed_list)
^(Set rc_type: fc_list_type _(List(JSON-LD_notation),"[",",","]")) //by default in JSON-LD //(but not in JSON) ^(Constant_predefined_in_a_KRL > r_header r_name r_base r_language r_type r_value r_container r_list r_set r_graph
r_inverse r_index r_vocab, rc_type: fc_string_type _(List(JSON-LD_notation),""@","",'"') ) ^(Concrete-term_for_constant_or_name rc_type: ^(string rc_notation_type: .{JSON-LD_notation}, rc_parts_begin-mark: '"', rc_parts_separator: ":", rc_parts_end-mark: '"'));
74/ 154
CL r_only_such_part_of_that_type: ^(Quantification
rc_type: (fc_list-like_prefix-fct_type _(List(CLIF),"","("," ",")") rc_quantified_variable_begin_mark: "(",
rc_quantified_variable_end_mark: ")", rc_separator: " "))
^(Logical_equivalence rc_type: (fc_list-like_prefix-fct_type _(List(CLIF),"iff","("," ",")") rc_separator: " "))
^(Logical_implication rc_type: (fc_list-like_prefix-fct_type _(List(CLIF),"if","("," ",")") rc_separator: " "))
^(Atomic_formula
> (cl#Atomic_sentence < Positional-or-name-based_formula),
rc_type: (fc_list-like_prefix-fct_type _(List(CLIF),"","("," ",")") rc_separator: " "))
^(Class-membership_formula rc_type: fc_list_type _(List(CLIF),"("," ",")")) ^(Frame = Frame_as_conjunction_of_links_from_a_same_source)
^(Gterm_reference > Constant_gTerm)
^(Constant_concrete_term > (KIF#Name > Numeral Single-or-double_quoted_string)); RIF+OWL r_only_such_part_of_that_type:
^(RIF_annotation rc_type: fc_list_type _(List(RIF-PS),"(*","","*)"))
^(Conjunction_phrase rc_type: (fc_prefix-fct-like_type _(List(RIF-PS),"","("," ",")") rc_separator: " "))
^(Quantification > Classic_quantification,
rc_type: (fc_prefix-fct-like_type _(List(RIF-PS),"","(","",")") rc_separator: " "))
^(Rule rc_type: (fc_list-like_infix-fct_type _(List(RIF-PS),":-","","","") rc_separator: " ")) // FORMULA ':-' FORMULA
^(Logical_equivalence rc_type: fc_prefix-fct-like_type _(List(RIF-PS),
"owl:equivalentClassOf","("," ",")")) ^(Equality_formula rc_type: fc_list-like_infix-fct_type _(List(RIF-PS),"=","","",""))
^(Class-membership_formula rc_type: (fc_list-like_infix-fct_type _(List(RIF-PS),"#","","","") rc_separator: ""))
^(Subclass_formula rc_type: fc_list-like_infix-fct_type _(List(RIF-PS),"##","","","")) ^(Half_link rc_type: (fc_half-link_type _(List(RIF-PS),"","->","","")))
^(Collection > List);
4.2.3. Spécifications de notations des éléments de modèle abstrait dans KRLO_2015+
Dans KRLO_2015+, j'ai décrit des spécifications de notations d'EAs du modèle JSON-LD pour la notation de JSON-LD et des spécifications de notations d'EAs du modèle KIF pour la notation de KIF. Les extraits ci-dessous présentent ces spécifications.// 1. concrete specifications for KIF abstract elements in KIF notation Abstract_element@KIF_model ?a
rc_spec: fc_spec _( List( "(" f_OP_from _(?a) f_ARGS_from _(?a) ")" ), List( KIF_notation ));
// 2. concrete specifications for JSON-LD abstract elements in JSON-LD notation ^(Conjunction_phrase@JSON-LD_model not < NR_frame) ?cp
rc_spec: fc_spec _( List( "[" f_ARGS_from _(?cp,",") //"," is the argument separator "]" ),
List( JSON-LD_notation )); Minimal-frame_as_NR-phrase@JSON-LD_model ?mf
rc_spec: fc_spec _( List( "{" f_ARGS_from _(?mf,",") "}" ), List( JSON-LD_notation ));
Minimal_half-link@JSON-LD_model ?mh
rc_spec: fc_spec _( List( f_OP_from _(?mh) ":" f_ARG _(?mh.r_link_destination) ), List( JSON-LD_notation ));
4.3. Expressivité
Cette section fournit des détails sur l'expressivité requise pour décrire KRLO. La spécification de règles pour la traduction d'EAs nécessite une expressivité supérieure à RIF-BLD. Cependant, l'expressivité de RIF-BLD est suffisante pour décrire les éléments de LRCs (c'est à dire, les ECs, les EAs, les modèles et les notations) et pour que ces descriptions puissent être exploitées par ces règles.
KRLO est un modèle conceptuel, ce qui facilite le partage et la réutilisation des descriptions. Ainsi, l'expressivité des descriptions dans KRLO n'est pas limitée à l'expressivité d'un LRC exécutable. La section “2.2.2. Création directe d'un modèle exécutable via un LRC exécutable” fournit des détails sur les difficultés résultant de l'utilisation d'un modèle exécutable pour le partage et la réutilisation des connaissances. Une description de KRLO en FL est accessible depuis cette page : http://www.webkb.org/kb/it/o_knowledge/o_KRL/o_knowledge/o_KRL/. FL est un LRC avec une notation de haut niveau et de second ordre (voir la définition de notation de 2nd-ordre). Pour décrire la version actuelle de KRLO (KRLO_2015+), une notation de premier ordre suffit.
Le schéma ci-dessous présente les différents niveaux d'expressivités requis pour l'import, l'export et les transformations entre EAs.
Figure 4.9. Expressivité nécessaire pour importer, exporter et transformer des EAs.
L'expressivité de certaines descriptions dans KRLO peut dépasser celle de OWL2-RL. Par exemple, les types d'EAs sont très souvent organisés dans des partitions, c'est à dire, des unions disjointes. Dans ce cas, pour les outils d'import ou d'export exploitant KRLO, cette précision peut être ignorée sans risque d'erreur pour l'import ou l'export de connaissances. Par exemple, les partitions peuvent être traitées comme des disjonctions. Ainsi, pour améliorer les performances lors de l'import ou de l'export de connaissances, quel que soit le LRC utilisé pour l'entrée ou la sortie, KRLO pourrait être traduite en OWL2-RL. En effet, l'expressivité de OWL2-RL est suffisante pour relier les types d'éléments de LRCs par des relations subtype et définir des relations structurelles pour les instances d'un type. Dans KRLO, ces relations sont r_result, r_args et r_operator. Pour décrire ces relations, seuls les constructeurs de logiques de descriptions suivants sont nécessaires :
• sous-typage et équivalence de types, • intersection et union de types, • cardinalité maximale 0/1.
Pour éviter d'utiliser les cardinalités 0..*, des listes de types particuliers sont nécessaires. À titre d'exemple, une liste de Link est définie ci-après en OWL2-RL/OWL_Functional-style.
76/ 154
owl2:EquivalentClasses( jb:Link_list
owl2:ObjectIntersectionOf( jb:List
owl2:ObjectAllValuesFrom( jb:r_member krlo:Link) )
OWL2-RL est un sous-langage de OWL2 qui peut être entièrement défini en RIF-BLD [OWL2 in RIF, 2013]. OWL2-RL peut être implémenté dans un raisonneur basé sur des règles capable de gérer l'expressivité de RIF-BLD, c'est à dire, l'expressivité de règles de Horn strictes [definite Horn rules] avec l'égalité et une sémantique du premier ordre standard. Plus précisément, OWL2 et RIF sont interopérables uniquement pour les sous-langages OWL2-RL et RIF-BLD. En effet, pour RIF-BLD, la “sémantique OWL2 directe” [OWL2 direct semantics, 2012] et la “sémantique basé sur RDF” [OWL2 RDF-Based semantics, 2012] peuvent être utilisées comme détaillé dans [OWL2-RL to RIF-BLD, 2013]. Lorsque KRLO est exploitée pour l'import ou l'export de connaissances, KRLO ne nécessite pas davantage d'expressivité que OWL2-RL et RIF-BLD. Ainsi, KRLO i) permet de réutiliser les graphes RDF, ii) peut être traduite dans des LRCs moins expressifs mais interprétables par beaucoup de raisonneurs sans conséquence pour l'import ou l'export, et iii) permet le passage à l'échelle des mécanismes d'inférences [OWL2, 2012] [Krötzsch et al., 2013].
La traduction entre EAs nécessite une expressivité supérieure à RIF-BLD. En effet, certaines des règles de traduction spécifiées dans KRLO nécessitent une variable existentiellement quantifiée. La section “6.2. Traduction entre éléments abstraits” donne des détails sur les règles de traduction spécifiées dans KRLO.
La traduction entre LRCs présentée dans cette thèse conserve en sortie toutes les informations en entrée. Lorsque le modèle source a une expressivité supérieure à celle du modèle cible, ce dernier est complété via des relations spéciales du modèle IKLmE – une extension du modèle d'IKL qui défini ces relations spéciales [Martin & Bénard, 2017b]. Ces relations permettent de représenter des EAs de la phrase source. Dans l'exemple ci-dessous, la relation spéciale IKLmE:_100pc est utilisée pour représenter un quantificateur universel. Cet exemple montre que l'usage des relations spéciales de IKLmE permet des représentations concises et lisibles. Les relations spéciales d'IKLmE sont binaires ; elles peuvent donc être exportées sans transformation vers toute notation supportant des relations binaires et donc vers toute notation.