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: 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