L'adoption de solutions qui améliorent des outils déjà existants est plus simple que l'adoption de solutions entièrement nouvelles. Certaines notations créées via un métalangage sont i) standardisées par des organismes comme le W3C ou l'OMG, et ii) utilisées par un grand nombre de personnes. Les outils d'import ou d'export exploitant ces notations sont eux aussi assez répandus. KRLO et les outils qui l'exploitent n'ont pas actuellement ces avantages mais en ont d'autres (cf. section ci-dessous).
3.1.4.3) Désavantages par rapport à un processus d'import exploitant KRLO
Les notations de description de structure – comme celles créées via XML – n'offrent que des relations structurelles entre leurs éléments. Ainsi, les outils pour importer des RCs depuis ces langages peuvent difficilement extraire des relations sémantiques à partir des représentations textuelles ou graphiques. Par exemple, un analyseur lexico-syntaxique standard pour XML tel que SAX n'est pas capable d'extraire un ASG à partir d'une description écrite en RDF/XML, ni même à partir d'une description écrite en XML et suivant la norme Alternating Normal Form (cf. section 2.2.3.1.1.1). Pour extraire de telles relations, ces outils doivent être adaptés via des tâches de programmation. Pour plus de détails concernant la difficulté de ces tâches, le lecteur peut consulter ces parties : “2.2. Difficulté des tâches de modélisation et/ou de programmation pour le partage de connaissances” et “2.2.3.2. Le langage utilisé pour créer le modèle exécutable est un langage de programmation”). Les outils disponibles pour importer depuis ou exporter vers ces langages ne réalisent pas d'inférence logique. Les conséquences de ces inférences doivent donc être programmées.
Le point précédent est aggravé par le fait que les descriptions sont souvent i) trop peu concises pour être facilement compréhensible par un humain, ou ii) de trop bas niveau pour être utilisées directement. Par exemple, nous ne connaissons aucun SGBC (Système de gestion de BC) utilisant des objets XML en interne.
L'approche décrite dans cette section n'élimine pas la nécessité de créer des analyseurs et des fonctions ou règles d'exports pour plusieurs notations. Certains outils pour le MDE sont décrits comme ayant des notations en entrée extensibles, par exemple, BAM [Feja et al., 2011] dans le domaine de la modélisation de processus (process modelling). En réalité, ils gèrent un modèle expressif qui inclut les primitives pour plusieurs langages de modélisation de processus déjà existants. Ainsi, ils peuvent gérer chacun d'eux. Des traductions depuis ou vers d'autres modèles ou notations restent nécessaires.
3.1.5. Import exploitant une ontologie de modèles abstraits de LRCs
(cf. figure 3.1, “Semantic-model_based_DSeI_without_notation_ontology”)
3.1.5.1) Description
Via une ontologie de modèles abstraits, une fonction d'import peut être paramétrée de sorte que toute RC puisse être importée vers tout modèle abstrait représenté dans cette ontologie. Cependant, sans une ontologie de notations, un langage particulier est nécessaire pour spécifier des notations particulières pour des EAs. A notre connaissance, aucune ontologie – autre que KRLO – définissant des notations n'existe. Des ontologies de modèles abstraits autres que KRLO existent ; par exemple, l'OMG (Object Management Group) a publié un modèle UML et un modèle XML pour ODM (Ontology Definition Meta-model) [ODM, 2014]. L'utilisation de telles ontologies pour la traduction est présentée dans la section “3.3.4. Spécifications de traductions exploitant une ontologie de langage existante”.
Un outil d'import exploitant l'ontologie de modèles abstraits LATIN Atlas of logics [Codescu et al., 2011] – qui organise des EAs de plusieurs logiques et LRCs – est présenté dans la section ci-dessous. La section “3.3.4.3. HETS avec LATIN et DOL” donne plus de détails sur la conception de l'ontologie LATIN et sur l'organisation des EAs dans cette ontologie.
3.1.5.2) Exemple
MMT (Meta-Meta-Theory) [Rabe & Kohlhase, 2013] est un langage qui permet de spécifier des modèles de LRCs et des notations pour des EAs de ces modèles via une méta-théorie. Pour éviter de gérer des spécifications de notation concurrentes, MMT permet également à l'utilisateur d'utiliser des relations “précédence” depuis une spécification de notation vers un entier. L'utilisateur peut ainsi ordonner les spécifications de notation de façon absolue. Une spécification d'un LRC nommé Logic et une spécification d'un LRC nommé PLSyntax (Propositional Logic Syntax) sont présentées ci-dessous. Ces spécifications sont extraites de la documentation en ligne de MMT (cf. http://uniformal.github.io/doc/tutorials/jedit/2theories.html). Pour clarifier ces spécifications, j'ai ajouté des commentaires délimités par les symboles “/*” et “/*”.
/*Extrait 1 : définition d'un nouveau LRC nommé “Logic”
avec la méta-théorie LF (Logical Framework) [Harper et al., 1987] */
theory Logic : ur:?LF = /*ur est l'espace de noms http://cds.omdoc.org/urtheories*/ /*Les spécifications ci-dessous sont structurées de la façon suivante :
spécification d'un EA pour le LRC Logic # spécification de la notation de cet EA */
prop : type # o /*l'EA prop (proposition) est un type (défini dans LF) et est noté “o”*/
proof : o → type # ⊢ 1 prec -100 /*l'EA proof a pour : partie une proposition, résultat un type, notation :
le symbole ⊢ suivi par
la notation de sa première partie*/ /*Extrait 2 : définition d'un nouveau LRC nommé “PLSyntax”
avec la méta théorie LF */
theory PLSyntax : ur:?LF = include ?Logic
True : o # ⊤ /*l'EA True est une proposition (le type proposition est défini dans le LRC Logic) et a pour notation “⊤”*/ False : o # ⊥
not : o → o # ¬ 1 prec 50
and : o → o → o # 1 ∧ 2 prec 45 /*l'EA and a pour :
partie deux propositions, résultat une proposition, notation :
la notation de sa première partie suivie par le symbole “∧” suivi par
la notation de sa seconde partie*/ or : o → o → o # 1 ∨ 2 prec 40
imp : o → o → o # 1 ⇒ 2 prec 35 equiv : o → o → o # 1 ⇒ 2 prec 30
Comme le montre l'extrait ci-dessus, la notation MMT est très concise mais a les défauts suivants.
• Entre un EA et ses parties, la notation MMT ne permet de spécifier que peu de relations sémantiques. En effet, seules des relations part et result peuvent être spécifiées. À titre de comparaison, trois principaux types de relations et plusieurs sous-types sont spécifiés dans KRLO (cf. “4.1.1.2. Opérateur, arguments et résultat”).
• Entre un EA et un EC, la notation MMT permet de spécifier qu'une relation structurelle, elle ne permet pas de spécifier une relation sémantique.
• La notation MMT ne permet pas de spécifier des notations de façon modulaire car les parties relatives à la notation ne peuvent être isolées des parties relatives au modèle. Ainsi, pour chaque notation, un utilisateur doit spécifier un nouveau LRC.
38/ 154
3.1.5.3) Désavantages par rapport à un processus d'import exploitant une ontologie telle que KRLO (i.e. une
ontologie de modèles abstraits et de notations)
Puisqu'une ontologie de définitions de notations n'est pas utilisée, la spécification de notations ne peut être faite que via un langage particulier (cf. exemple ci-dessus). Les spécifications ne sont donc interprétables que par quelques outils qui exploitent un interpréteur pour ce langage. Ceci est une limite à la réutilisabilité de ces spécifications. De plus, comme les spécifications de notations ne sont pas organisées dans une ontologie, elles peuvent difficilement être comparées (cf. comparaison sémantique) et donc retrouvées (cf. réutilisabilité sémantique). Ainsi, sans ontologie de notations, un utilisateur ne peut pas facilement rechercher des spécifications de notations particulières et donc les réutiliser, par exemple pour spécifier de nouvelles notations via l'héritage et/ou le paramétrage d'une spécification existante.
3.2. Export de connaissances
Dans cette thèse, un processus d'export est un processus qui prend en entrée des EAs et a en sortie un fichier contenant des éléments textuels ou graphiques. La figure ci-dessous présente quelques types de processus d'exports avec quelques relations telles que les relations has_input ou has_output.
Figure 3.2. Représentation d'une tâche d'export en pm#UML.
Comme indiqué dans la figure ci-dessus, un processus d'export sémantique direct basé sur un modèle sémantique prend en paramètre une ontologie de modèles abstraits et de notation de LRCs. Ainsi, un tel processus peut être utilisé pour exporter des RCs depuis tout modèle représenté dans cette ontologie vers toute notation également représentée dans cette ontologie. En dehors de KRLO, nous n'avons trouvé aucune ontologie de notation même pour un LRC standard tel que RDF. Par conséquent, il apparait qu'il n'y a également aucun autre exporteur sémantique basé sur un modèle sémantique.
Dans quelques outils – tel Centaur – des fonctions d'export prennent en paramètre des modèles concrets et abstraits qui sont décrits via un langage de description de structure. Par exemple, dans Centaur, des fonctions d'export prennent en paramètre des grammaires abstraites on concrètes. Comme expliqué dans la section “2.2.3. Création directe d'un modèle exécutable via un langage qui n'est pas un LRC”, ces modèles abstraits ou concrets sont difficilement réutilisables pour le partage de connaissances et nécessitent des tâches de programmation qui peuvent être longues et difficiles.
Certains modèles de LRCs ont une notation basée sur un méta-langage de description de structure comme MOF ou XML. Dans ce cas, des langages de manipulation de structure spécifique comme Mof2Text [Mof2Text, 2008], XSLT et CSS peuvent être utilisés pour spécifier des fonctions d'export. Ainsi, plusieurs auteurs ont proposé des langages pour spécifier la façon dont des EAs de RDF peuvent être présentés : dans une certaine notation, dans un certain ordre, en gras, dans une fenêtre, etc. Xenon [Quan, 2005], Fresnel [Pietriga et al., 2006], OWL-PL [Brophy & Helfin, 2009] et SPARQL Template [Corby & Faron-Zucker, 2015] [Corby et al., 2015] sont des exemples de tels langages. Comme expliqué dans la section “2.2.3.1. Le langage utilisé pour créer le modèle exécutable est un langage de description dont la structure peut être manipulée via des outils ou un langage”, les fonctions d'export ainsi spécifiées sont difficilement réutilisables et peuvent nécessiter des tâches de programmation.
40/ 154 KRLO ne dépend pas d'un langage ou LRC particulier. Certains des langages listés dans le paragraphe précédent pourraient donc être utilisés conjointement à KRLO. Par exemple, des EAs de KRLO peuvent être utilisés dans des requêtes SPARQL Template. Pour cela, KRLO doit être représenté en RDF+OWL2-RL [OWL2, 2012] ou SWRL [Horrocks et al., 2004] qui est un LRC basé sur RDF pour représenter des règles de Horn. Les règles de traduction représentées dans KRLO ne peuvent cependant pas etre représentéees en RDF+OWL2-RL car elles nécessitent l'emploi d'un quantificateur existentiel dans la partie conclusion de la règle.
Si aucune description du modèle abstrait et du modèle concret n'est fournie, un programmeur doit spécifier une fonction d'export via un langage de programmation. Les difficultés liées à l'écriture de ces spécifications et à leur réutilisation sont décrites dans la section “2.2.3.2. Le langage utilisé pour créer le modèle exécutable est un langage de programmation.”
3.3. Traductions
Dans cette thèse, un processus de traduction sémantique (entre EAs) prend en entrée un modèle source, a en sortie un modèle cible. D'autres types de processus de traductions existent. Par exemple, [Euzénat, 2001b] distingue les types de processus de traduction suivants : “traduction lexicale”, “traduction syntaxique”, “traduction sémantique” et “traduction sémiotique” (traduction pragmatique). La traduction sémiotique/pragmatique réfère aux bonnes pratiques d'écriture de RCs et dépasse donc le cadre de cette thèse. La figure ci-dessous présente les différents types de processus de traduction qui seront comparés dans cette section (3.3).
Figure 3.3. Représentation de tâches de traduction en pm#UML.
Comme le montre la figure ci-dessus, des fonctions ou règles de traduction lexicale ont en entrée et en sortie des éléments graphiques ou des éléments textuels. Des fonctions ou règles de traduction syntaxique ont en entrée et en sortie des ECs ou des
EAs liés à la syntaxe et généralement organisés dans un AST. Des fonctions ou règles de traduction sémantique ont en entrée et en
sortie des EAs typiquement organisés dans un ASG. Cette section (3.3.) décrit les approches existantes pour les traductions syntaxiques ou sémantiques d'EAs.