Toward a Formal Common Information Model Ontology

La problématique posée dans cet article est la suivante:
Comment rendre un système d'administration auto-administrable?
Un tel système est chargé de piloter un ensemble d'équipements ou nœuds hétérogènes (du point de vue fonctionnel, matériel, logiciel, modèle de donnée, propriétés). Ces équipements varient des petits capteurs (température, luminosité etc) vers des routeurs tout en passant par des téléphones portables.
Une opération d'administrations peut être par exemple l'ajout d'une nouvelle fonctionnalité sur un téléphone mobile afin que son utilisateur puisse piloter le déclenchement du ballon l'eau chaude à distance (en dehors de son domicile).
Cette opération nécessite un déploiement de code entre autre sur le téléphone mobile et la gateway responsable de la gestion des équipements de la maison par exemple afin d'arriver au but.

L'auto administration du système peut être par exemple l'amélioration des performances du système pendant une période de pointe toute en proposant une autre configuration du réseau en utilisant au mieux les ressources disponibles.

Le modèle CIM (Common Information Model) est un standard qui a pour but d'avoir un modèle de donnée commun à tout les équipements disponibles dans le système. Ceci permet d'avoir une vue unifiée qui facilitera l'administration de ces équipements sans se préoccuper du protocole d'administration et modèle de donnée utilisés.

Bien que tout ces équipements sont spécifiques à un data model et un protocole d'administration, l'interopérabilité entre data model ne suffit pas pour avoir un système auto-administrable.
En effet, un système auto-administrable doit être en mesure de prendre des "décisions" pour améliorer les performances ou répondre à des critères bien définis.
Or afin d'arriver à cela on a besoin d'exprimer un ensemble de règles, de contraintes et des axiomes afin de permettre au système de raisonner et prendre des "décisions".

Les ontologies sont appliquées dans le Web afin d'améliorer l'expressivité et d'introduire la sémantique dans la description et la présentation des donnée. Ces langages d'ontologies permettent également de formaliser les contraintes, description et axiomes afin de permettre au système de les traiter. L'utilisation des ontologies permet donc de se rapprocher vers l'auto-administration des systèmes.

CIM est positionné d'après cet article dans la classe de "Semi formal ontology", c.à.d CIM manque d'expressivité sur les contraintes, axiomes et règles. En plus, CIM utilise XML et XML Schéma pour représenter et modéliser les données. Or, l'utilisation de ces outils nécessite un travail d'interprétation en avant afin de pouvoir extraire les informations utiles et nécessaires contenues dans les balises (Parsing). Ceci dit, l'échange d'information entre deux entités peut prendre place sauf si ses deux entités ont l'interprétation prédéfini afin d'extraire l'information utile des balises.

Quirolgico et al. proposent de mapper CIM vers du RDF/S (Resource description framework)/Schema). Donc CIM sera écrit en utilisant RDF/S afin de passer d'une semi ontologie vers une ontologie plus ou moins complète. RDF/S étendra CIM pour supporter d'autres proporiétés manquantes comme les axiomes et les contraintes.
RDF est un langage d'assertion qui definit des constructeurs sémantique afin d'exprimer des propositions. Ceci est réalisé à travers 3-tuples (sujet, relation, sujet).



L'utilisation de RDF/S permettra:

1. d'échanger des informations et raisonner sans avoir une sémantique prédéfini comme dans le cas d'XML (balises).
2. Ajouter des règles et axiomes pour améliorer le raisonnement du système.
3. Permettre aux données de l'ontologie CIM d'être combinées avec d'autres vocabulaires ou ontologies "plus facilement".
   

CIM schéma est décrit en UML alors le mapping de CIM vers RDF/s se basent sur des travaux antérieurs [1, 2, 3] qui proposent des méthodes de translation pour passer d'UML (Unified Modeling Language) vers un language d'ontologie comme RDF/S (Resource description framework)/schéma et OWL (Web Ontology Lanaguage).

La construction de l'ontologie CIM en RDF/S est abandonnée car RDF/S ne permet pas d'exprimer des contraintes sur la cardinalité. En plus ne permet pas de représenter certain aspects spécifiques ) CIM comme "Key qualifier" c.à.d un attribut à valeur unique.
On peut rajouter également que RDF/S ne permet pas d'exprimer des contraintes sur les propriétés, comme par exemple la transitivité si a R b et b R c alors a R c, ou la fonction inverse. etc.

OWL (Web Ontologie Language) qui offre une meilleure expressivité est choisi pour représenter l'ontologie de CIM. OWL ajoutera de la sémantique sur les relations qui relient les classes CIM à travers des propriétés comme owl:TransitiveProperty, owl: inverseOf, owl: EquivalentProperty et d'autres.
Ces propriétés faciliteront le mapping entre deux ontologies présentées en OWL. Par exemple
C1 est_sous_composant_de C2 dans l'ontologie 1 est équivalent à C2 est_composant_père_de C1 dans l'ontologie 2. Donc est_sous_composant_de est une propriété inverse de est_composant_père_de (owl: inverseOf).
Cette translation encore une fois sera basée sur le mapping entre UML et OWL [4].

La construction de l'ontologie CIM avec OWL présente également des limites, quelques aspects dans CIM n'existent pas en UML, RDF/S et OWL comme la valeur par défaut d'un attribut.
En plus, OWL ne permet pas de décrire des clasess abstraites (contrairement à CIM et UML).
Évidemment, on peut rajouter les concepts à l'ontologie mais ceci revient au même cas qu'avec XML/S où on a de la connaissance prédéfini qui doit être partagée par deux ou plusieurs entités afin de pouvoir extraire les informations utiles.


Conclusions:
CIM est bien spécifique au domaine de l'administration des équipements alors que les ontologies sont très génériques parfois et ne permettent pas d'exprimer tout les concepts et propriétés sans avoir de la connaissance prédéfini ou pré partagé afin d'interpréter les informations.

Références:

1. Baclawski et al.: Extending UML to support ontology engineering for the semantic web. Lecture Notes in Computer Science 2185 (2001).
2. Chang et al: A discussion of the relationship between RDF-schema and UML, W3C Note (1998).
3. Cranefield, S.: Networked knowledge representation and exchange using UML and RDF. Journal of Digital Information 1 (2001)
4. AT&T: OWL Full and UML 2.0 compared. Whitepaper (2004)
   

Review: An ontology-based method to merge and map management information models

La problématique est toujours la même: l'interopérabilité des modèles de donnée. Ceci facilite la gestion du système tout en offrant à un administrateur une vue unifiée des entités présentes dans le système. Une vue unifiée permet d'agir sur le système indépendamment de la topologie, architecture (matérielle/logicielle) ou protocole d'administration utilisés derrière.

L'interopérabilité est réalisée par des approches syntaxiques et ne permet pas de garder le sens ou autrement dit la sémantique lors du passage d'un modèle de donnée à un autre. Par conséquence, le mapping réalisé n'est pas complet et les entités translatées sont détachées de leur modèle de donnée de base et perdent leur sens.
Alors, une des approches est d'avoir recours aux ontologies afin de préserver au maximum le sens et d'avoir une translation efficace entre deux data model.

Cet article décrit en bref les étapes essentielles pour faire un mapping entre deux data model.
Pour commencer Vergara et al proposent de translater les modèles de données vers une même ontologie. Ils utilisent DAML+OIL un langage d'ontologie. (DAML+OIL a été remplacé par OWL plus tard). Ils appliquent cette approche sur CIM et Host-REssource-MIB qui sont deux modèles de données et les mappent vers une ontologie commune.
voir figure, clic pour agrandir:
Ces élements sont écrits dans le même language d'ontologie DAML+OIL,
les 3 premiers éléments sont des entités CIM et les 2 dernières des entités Host-Ressource-MIB.




Une fois la réécriture des deux data model en DAML+OIL, ils appliquent leur méthode M&M (Merge & Map) qui d'après eux met en œuvre les deux process en parallèle. Cette méthode utilise un ensemble de règles pour déterminer un match entre deux entités de deux méta model différents.

Ces règles sont basées sur des techniques de mapping et alignement des ontologies, comme par exemple:

• un mapping syntaxique: deux entités ont le même nom, partagent un même préfixe, suffixe etc.
  
• des règles sur le type de données afin de déterminer s'il y a un mapping,
  
• deux entités appartiennent au même domaine (ou class).
• mapping par hiérarchie: si deux entités ont un mapping alors il y a une forte probabilité que leurs attributs ou sous-entités soient compatibles pour un mapping.
• une attention est également accordée pour la conversion des unités (par exemple Bit et Octet, etc) et pour la concaténation des entités, par exemple (Consommation d'energie = consommation écran+ consommation PC).
  

Une fois le mapping entre les deux modèles de donnée est réalisé, on procède à la translation entre les deux modèles avec des formules écrites en MapTrans (langage fictif similaire à JavaScript). Les formules permettent la translation dans les deux sens.
voir figure, clic pour agrandir:
Une formule écrite en MapTrans, où KernelModeTime(CIM) et UserModeTime(CIM) sont tout les deux mappés vers hrSWRunPerfCPU(Host-resources-MIB).
La règle de conversion est hrSWRunPerfCPU = (KernelModeTime +UserModeTime)*10.





Cette solution nécessite l'intervention/supervision d'un humain pour valider les différentes étapes de mapping "automatique" entre les ontologies. Ce qui peut demander du temps mais ceci reste moins lourd que de faire un mapping à la main.
voir figure, clic pour agrandir, les étapes en gris sont menées par un utilisateur (administrateur) et celles en blanc par le système.

Review: Applying the Web Ontology Language to management information definitions

Jorge Vergara et al proposent d'utiliser le langage des ontologies "Web Ontology Language" OWL pour donner plus de sémantique et d'expressivité aux modèles de données.

Ils proposent d'utiliser OWL pour les raisons suivantes:

1. OWL est basé sur du RDFS et RDF
   
2. RDFS et RDF sont basés sur du XML et offrent un ensemble structuré de termes: hierarchie des classes, domaine et contraintes.
   
3. XML (eXtended Markup Language) est largement utilisé comme format d'échange, de représentation et d'interprétation d'information. L'utilisation d'XML est favorisée par l'existence d'un grand nombre d'outils et librairies qui faciliteront la validation (DTD) et le traitement des informations. En plus , XML peut être utilisé afin de représenter l'information autrement dans un scénario d'interopérabilité des protocoles d'administrations.

Jorge insiste sur le besoin d'introduire de la sémantique dans les data model existants afin d'arriver à passer de l'un à l'autre facilement. Actuellement, le passage entre 2 data models se fait par du recast autrement dit un mapping syntaxique plutôt manuel.
L'idée est de traduire les data models en OWL.
En effet, les data model actuels sont vu comme des ontologies 'light" puisqu'ils présentent entre autre un ensemble de concepts (class, attributs etc) et d'instance de concepts ainsi que des relations (sous-class, association de class etc). Cependant ces data models ne sont pas assez expressifs, pas de possibilité d'écrire des axiomes.

Or OWL est un langage d'ontologie général et lui manque quelques aspects pour pouvoir traduire les models de données en OWL. Les droits d'accès (Lecture, écriture) , les unités de mesures (Bit/seconde) ainsi que les valeurs par défaut pour les attributs. Les auteurs étendent OWL avec ces aspects tout en se basant sur du RDFS. (voir Fig, clic pour agrandir)




Conclusion:
Cet article présente une approche pour une interopérabilité entre data model tout en se basant sur OWL. Ce langage est basé sur du RDFS qui est capable de décrire un data model par des class, propriété, hiérarchie, domaine et types.
RDFS lui même est basé sur du XML ce qui facilite l'échange et le traitement d'information par des outils déjà existants.
Des extensions ont été ajoutées à OWL (en utilisant RDFS) afin d'arriver à traduire tous les aspects d'un modèle de donnée vers OWL.
Ils proposent également de formuler avec du SWRL (Semantic Web Rule Langage) des règles et des axiomes (plus de détails bientôt).

Review: Ontologies: Giving Semantics to Network Management Models

Cet article expose la même problématique concernant l'hétérogénéité des data model et l'insuffisance de la translation syntaxique d'un data model à un autre.

Pour commencer il expose l'intérêt d'ajouter de la sémantique tout en passant par les ontologies. Le papier continue par présenter les data model/les Information Model (GDMO, SMI, MIF, IDL, SMIng et CIM). Ensuite, l'auteur continue par une comparaison qui va permettre de savoir si on peux passer d'un modèle de données à un autre facilement. ça sera le cas si les deux data model supportent les même critères (d'ontologie).

Le modèle de donnée CIM (Common Information Model) est le candidat qui répond le mieux aux critères de comparaison (Inspirés par [1] et [2]), du point de vue Meta classes, Partitions, Attributs, Facets, Taxonomies, Relations et Comportement (Axiom et roles). En plus, CIM est le langage qui a le plus d'expressivité sémantique parmi les autres. Mais CIM a besoin des extensions.

Afin d'intégrer les ontologies aux modèles de données, les auteurs proposent deux approches:

1. Effectuer un mapping entre chaque deux modèle de données.
   
2. Définir un modèle de donnée (final ou pivot) qui inclut les autres modèles de données existants.

La seconde approche parait la plus adaptée dans le cas où le nombre des modèles de données est élevé.
Ils proposent de modifier la seconde approche car les sous-ensemble communs entre les modèles de données n'ont pas tous le même poids.
Donc ils prendront le modèle de données le plus grand, celui qui couvre le mieux le domaine d'administration. Ensuite, appliquer une extension avec les petites parties qu'il ne supportent pas afin de définir un modèle de données final.

Ce modèle de données final ou l'ontologie globale est CIM dont on va ajouter les extensions afin qu'il couvre d'autres aspects comme les axiomes et le comportement, contraintes etc. Le but est de pouvoir exprimer des contraintes comme par exemple: "L'espace libre d'une instance CIM_FileSystem doit être plus grande de 10% que la taille d'un sytème de fichier."


Conclusions:
CIM est un modèle de donnée avec une expressivité sémantique plus avancée que les autres modèles de données (GDMO, SMI, MIF, IDL, SMIng). Cependant, il lui manque la définition des taxonomies (subclass of, Not subclass of, composition disjointe (entre deux concepts), etc) et les relations afin de pouvoir exprimer des contraintes.
Lors du mapping entre les modèle de données, on peut utiliser les outils des ontologies déjà existants. D'après les auteurs, cette solution nécessite une intervention manuelle pour valider certaines taches, ce qui peut prendre un temps non négligeable lors de son application à des larges modèles de données.
Mais cette solution reste mieux adaptée que de faire le mapping à la main.

Références:
1 - A roadmap to ontology specification languages, Corcho et al., EKAW'2000.
2 - Ontology based integration of information - a survey on exisiting approaches, Wache et al, IJCAI 2001

Intéopérabilité du nommage et désignation

Contexte:
On s'intéresse particulièrement au problème du nommage et désignation dans les protocoles d'administrations.
Un protocole d'administration est un protocole qui gère un ensemble de fonctions entre deux ou plusieurs entités. Comme par exemple la gestion d'énergie, la qualité de service, le diagnostic, la mise à jour logicielle etc.

Les entités varient des petits devices comme les téléphones portables jusqu'au gros serveurs d'autoconfiguration.
Ces devices supportent un modèle de donnée/ data model/ Information Model spécifique à un protocole d'administration. Le data model spécifie la représentation des données manipulées (Hiérarchique par exemple) et les formes d'accès au valeurs et données (Père.Fils.Class.Paramètre etc).

Les protocoles d'administration sont de plus en plus nombreux et agissent sur un domaine d'administration spécifique. La diversité des protocoles est traduite par une diversité des data model.
Le domaine d'administration représenté par un data model possède le plus souvent un ou plusieurs sous-ensemble qui sont communs aux différents protocoles d'administrations.


Problématique:
Un opérateur de service est amené parfois à administrer des équipements qui ne supportent pas le modèle de donnée spécifique à son protocole d'administration. Alors afin d'arriver à son but d'administration des équipement hétérogènes, une translation entre data model s'impose.
Cependant, la translation syntaxique entre les data model n'est pas suffisante car on perd le sens de la désignation. D'ou la nécessité d'introduire de la sémantique dans les modèles de donnée.

Une piste à explorer est l'utilisation des ontologies. C.à.d mapper les modèles de données vers un langage d'ontologie (OWL) pour ensuite faire le matching entre les deux ontologies. Une fois le matching est effectué, la translation aura lieu.