Dans cette section, nous présentons les modèles d’ontologies RDF-Schema et PLIB qui permettent essentiellement de définir des OCC.
3.1.1 RDF/ RDF-Schema
RDF [Manola and Miller, 2004] est le premier langage apparu pour définir la sémantique de sources WEB. Sa structure est issue des réseaux sémantiques introduits dans le domaine de la représentation de connaissances. RDF permet d’exprimer des assertions dont la structure est un triplet (sujet, prédicat, objet). Les éléments de ce triplet sont définis comme suit :
– le sujet est un URI (Uniform Resource Identifier) identifiant un élément nommé ressource. Une ressource peut être une page Web, une partie d’une page Web référencée par une ancre ou même un objet quelconque auquel un URI a été attribuée ;
– le prédicat est une propriété permettant de caractériser la ressource. Par exemple une page Web peut être caractérisée par le prédicat créé_par afin d’en définir l’auteur ;
– l’objet est la valeur prise par la propriété. Cette valeur peut être un URI ou une valeur littérale qui peut être non typée ou typée par l’un des types primitifs définis dans XML Schema.
Puisque l’objet d’un triplet peut être le sujet d’un autre, les triplets peuvent être reliés entre eux. En représentant les sujets et objets par des noeuds et les prédicats par des arrêtes, des données RDF se représentent sous la forme d’un graphe. Au niveau sémantique, chaque triplet exprime une assertion. En conséquence, la signification d’un tel graphe est l’ensemble de ces assertions.
RDF n’introduit que très peu de prédicats prédéfinis, ceux-ci pouvant être définis librement. En conséquence, il ne propose pas de constructeurs prédéfinis pour la conception d’ontologies. C’est pour-quoi il a été rapidement étendu par un ensemble de constructeurs permettant la définition d’ontologies. Cette extension de RDF porte le nom de RDF-Schema [Brickley and Guha, 2004]. Les constructeurs (relations ou prédicats) introduits par RDF-Schema sont les suivants.
– Constructeur de classes. rdfs:Class et rdfs:subClassOf permettent de définir des classes et de les organiser dans une hiérarchie dont les liens sont des relations de subsomption. L’héritage multiple5 est autorisé. Ces classes sont identifiées par un URI comprenant un espace de noms afin de pouvoir les référencer de manière unique (RDF-Schema respecte donc bien le critère de référençabilité). rdfs:label et rdfs:comment permettent respectivement de donner des noms aux classes et de les décrire de façon textuelle.
– Constructeur de propriétés. rdfs:domain et rdfs:range permettent respectivement de définir le domaine et le codomaine d’une propriété RDF (rdf:Property). Le domaine d’une propriété RDF-Schema est optionnel. Lorsqu’il n’est pas défini, cette propriété peut être utilisée pour dé-crire n’importe quelle instance appartenant à l’univers du discours conceptualisé par l’ontologie. Un domaine peut être défini par une ou plusieurs classes. Si plusieurs classes sont utilisées, le domaine est composé des instances qui appartiennent à l’intersection de ces classes. La définition du codomaine d’une propriété est similaire à celle de son domaine à part qu’en plus des classes, des types de données sont disponibles pour le définir.
Comme les classes, les propriétés peuvent être d’une part décrites de façon textuelle en utilisant rdfs:labelet rdfs:comment et sont, d’autre part, organisées dans une hiérarchie par des liens de subsomption en utilisant rdfs:subPropertyOf. Si une propriété psubest une sous-propriété d’une propriété p, alors l’extension de psub est contenue dans celle de p, l’extension d’une
priété p étant définie comme l’ensemble des couples (i, v) où l’instance i à la valeur v pour la propriété p. Par exemple, la propriété est_delegue_de est une sous-propriété de est_mem-bre_depuisque tout délégué d’une formation est membre de celle-ci.
– Constructeur de types de données. Les valeurs d’une propriété peuvent être des instances de classes ou des littéraux. Ces littéraux peuvent être typés en utilisant les types prédéfinis de XML Schema. Ceci permet par exemple de représenter des valeurs de types chaîne de caractères, numé-rique ou date. Par ailleurs, RDF-Schema fournit également des types collections (rdfs:Contai-ner). RDF-Schema propose des constructeurs pour construire différentes sortes de collections et en particulier les listes (rdf:List) et les sacs (rdf:Bag).
– Constructeur d’instances. Les instances sont définies, en RDF, par deux types de triplets. Les triplets de la forme (i, rdf:type, C) indiquent que i est une instance de la classe C. RDF-Schema supporte la multi-instanciation qui permet à une instance d’appartenir à plusieurs classes même si ces classes ne sont pas liées par une relation de subsomption. Les autres triplets, de la forme (i, p, v), caractérisent l’instance i par la valeur v pour la propriété p.
L’utilisation conjointe de RDF et Schema permet donc à la fois de représenter (en RDF-Schema) une ontologie et (en RDF) des instances définies en termes de cette ontologie.
Exemple. Les figures 1.5 et 1.6 illustrent cette capacité. Nous avons représenté sur ces figures un ex-trait de l’ontologie SIOC6 conçue, entre autres, par un des auteurs de RDF-Schema. Cet exemple d’ontologie sera utilisé tout au long de ce mémoire.
Explication. Cette ontologie est représentée dans la figure 1.5 sous la forme d’un graphe. Les concepts principaux de cette ontologie sont les suivants. Un forum (Forum) est hébergé sur un site (Site). Il est administré par un modérateur (has_moderator). Des utilisateurs (User) peuvent s’abonner à des forums (subscriber_of) et créer des messages (Post) sur ces forums (has_container). Plusieurs réponses peuvent être données à un message (has_reply).
En dessous de cette ontologie, nous avons représenté des données de cette ontologie. Les URI des instances sont entourées d’un ovale tandis que les valeurs littérales sont représentées dans un rec-tangle. Dans cette partie, une instance de la classe Post est décrite. L’URI de ce message se termine par post-sioc, son titre et son contenu sont définis par des valeurs littérales tandis que son créateur, le forum sur lequel il est créé ainsi que les réponses qui y ont été faites sont définis en référençant d’autres instances.
Enfin, sur la figure 1.6, nous avons indiqué un cours extrait de cette ontologie en RDF/XML, un for-mat XML pour des ontologies RDF-Schema. Nous voyons notamment grâce à cette syntaxe que les classes et propriétés de cette ontologie sont décrites par un nom (<rdfs:label>) et un commentaire (<rdfs:comment>).
Même si ce n’est pas illustré dans cet exemple, le langage RDF-Schema laisse un grand degré de liberté pour représenter une ontologie. En particulier, RDF-Schema n’impose aucune séparation entre les niveaux instance, ontologie et modèle d’ontologies. Ainsi, il permet par exemple qu’une instance soit également une classe et donc, qu’elle puisse elle-même avoir des instances. Il permet aussi qu’une propriété soit également une classe et donc qu’elle puisse être elle-même le domaine d’autres propriétés.
Site Space Forum Container User Item Resource Post name String first_name last_name email String title note content has_container has_creator has_host has_moderator subscriber_of (collection) has_reply http://rdfs.org/sioc/ns http://lisi .../post-sioc title
« Creating connections between discussion with SIOC »
http://lisi.../weblog http://lisi .../cloud
http://lisi.../comment-123928
« SIOC provides a unified vocabulary for content and interaction description: a semantic layer that can co-exist with existing discussion platforms .» content has_creator has_reply has_container héritage propriété valeur de propriété Légende : Ontologie Données
F. 1.5 – Un extrait de l’ontologie SIOC représentée sous forme graphique
Ontologie :
<rdfs:Class rdf:about="http://rdfs.org/sioc/ns#Forum"> <rdfs:label>Forum</rdfs:label>
<rdfs:comment>
A discussion area on which Posts or entries are made. </rdfs:comment> <rdfs:subClassOf > <rdfs:Class rdf:about="http://rdfs.org/sioc/ns#Container"/> </rdfs:subClassOf>> </rdfs:Class> <rdf:Property rdf:about="http://rdfs.org/sioc/ns#has_host"> <rdfs:label>has host</rdfs:label> <rdfs:comment>
The Site that hosts this Forum </rdfs:comment>
<rdfs:domain rdf:resource="http://rdfs.org/sioc/ns#Forum"/> <rdfs:range rdf:resource="http://rdfs.org/sioc/ns#Site"/> </rdf:Property>
Données :
<sioc:Post rdf:about="http://lisi .../post -sioc/"> <sioc:title>
Creating connections between discussion with SIOC </sioc:title>
<sioc:has_container rdf:resource="http://lisi .../weblog"/> <sioc:has_creator>
<sioc:User rdf:about="http://lisi.../author/cloud"/> </sioc:has_creator>
<sioc:content>
SIOC provides a unified vocabulary for content and interaction description: a semantic layer that can co-exist with existing discussion platforms .
</sioc:content> <sioc:has_reply> <sioc:Post rdf:about="http://lisi.../comment-928"> </sioc:Post> </sioc:has_reply> </sioc:Post>
Notons que RDF-Schema ne contient aucune primitive explicite permettant de décrire des équiva-lences conceptuelles7. C’est la raison pour laquelle nous considérons que ce modèle est orienté vers les OCC. Dans la section suivante nous présentons le modèle PLIB également spécialisé dans la définition de OCC.
3.1.2 PLIB
PLIB (Parts LIBrary) est un projet initié en 1987 au niveau européen [42, 1998, ISO13584-25, 2004] et élevé au niveau ISO en 1990. Son objectif était de permettre une modélisation informatique des catalogues de composants industriels afin de les rendre échangeables entre fournisseurs et utilisa-teurs. Pour atteindre cet objectif, le langage de modélisation EXPRESS a été utilisé pour représenter un catalogue sous forme d’instances d’un modèle. Un tel catalogue propose une classification des classes de composants industriels représentés, ainsi qu’une description de toutes les propriétés s’appliquant à celles-ci. En conséquence, un catalogue contient à la fois une ontologie permettant de représenter une partie des concepts présents dans un domaine inclus dans celui des composants industriels et des ins-tances de cette ontologie. Le modèle publié en 1998 [ISO13584-42, 1998] et complété récemment par des extensions dans les normes ISO 13584-24 et -25 est donc un modèle d’ontologies et un modèle d’instances de classes des ontologies.
Partant du constat que les termes primitifs d’un domaine technique sont très nombreux et difficiles à appréhender, l’objectif du modèle PLIB est de permettre de définir de tels concepts avec la plus grande précision possible. Le modèle PLIB permet ainsi de créer des OCC avec les constructeurs suivants.
– Constructeur de classes. PLIB propose le constructeur item_class pour définir des classes. Ces classes, tout comme les autres éléments d’une ontologie, sont identifiées par un BSU (Basic Semantic Unit). Ce BSU est construit à partir de l’identifiant universel de l’organisation qui est la source de l’ontologie (supplier). Les classes PLIB peuvent être décrites par une description tex-tuelle (nom, noms synonymes, définition, note, remarque) éventex-tuellement dans plusieurs langues naturelles. Cette description peut aussi être complétée par des documents. Deux opérateurs sont disponibles pour organiser ces classes dans une hiérarchie. Le premier est l’opérateur is_a. Cet opérateur est l’opérateur d’héritage simple qui implique l’héritage des propriétés définies par les classes subsumantes. Le second opérateur, nommé case_of, permet la subsomption multiple et n’implique pas implicitement l’héritage de propriétés. Pour hériter d’une propriété d’une de ses classes subsumantes, une classe doit explicitement indiquer l’importation de cette propriété dans sa définition. Une classe peut donc hériter d’une partie des propriétés des classes subsumantes. L’objectif de cet opérateur est de permettre la construction modulaire d’ontologies de domaine. – Constructeur de propriétés. Les propriétés en PLIB sont définies avec le constructeur
non_de-pendent_pdet. Comme les classes, elles sont identifiées par un BSU et décrites par une défi-nition textuelle et/ou graphique. Le champ d’application d’une propriété est défini par son do-maine (scope). En pratique, ce champ d’application est souvent composé de plusieurs classes qui peuvent se trouver dans plusieurs branches de la hiérarchie. Pour résoudre ce problème, PLIB propose de qualifier les propriétés de la façon suivante :
7Il est à noter qu’il est possible d’utiliser la relation de subsomption de RDF-Schema pour définir des équivalences concep-tuelles. Par exemple, si une classe c1est subsumée par c2et que c2est subsumée par c1, alors c1et c2sont équivalentes.
– une propriété est définie sur une classe C au plus haut niveau de la hiérarchie où elle peut être définie sans ambiguïté ; elle est dite visible pour toutes les sous-classes de C ;
– une propriété visible sur une classe C peut devenir applicable sur cette classe, c’est-à-dire que toute instance de C doit présenter une caractéristique ou une grandeur qui représente cette propriété.
PLIB propose un autre constructeur de propriété, nommé dependent_P_DET, pour les propriétés dont l’évaluation dépend de paramètres de contexte (condition_DET). Par exemple, la durée de vie d’un roulement à bille dépend de la charge qu’il supporte ainsi que de la vitesse à laquelle il est utilisé. De même, la résistance d’un transistor dépend de la température à laquelle elle est mesurée.
– Constructeur de types de données. Le modèle PLIB fournit des types de données primitifs tels que les entiers ou les réels. Ces derniers peuvent être associés à une unité de mesure (mea-sure_type) ou à une monnaie (currency_type). Le type class_instance_type permet d’uti-liser une classe comme un type de données. PLIB fournit également le type aggregate_ty-pe pour pouvoir créer des collections. Plusieurs types collections sont disponibles comme par exemple les listes, les tableaux ou les ensembles. La cardinalité de ces collections peut être défi-nie. Enfin, le modèle d’ontologies PLIB permet de créer des types de données utilisateurs comme par exemple des types énumérés (non_quantitative_code_type).
– Constructeur d’instances. Une instance PLIB est définie par sa classe de base et l’ensemble de ses valeurs de propriétés. PLIB ne permet donc pas la multi-instanciation. A la place, PLIB offre le mécanisme d’agrégation d’instance. Pour cela, PLIB propose de distinguer les propriétés essentielles d’une classe de celles qui dépendent d’un point de vue sur le concept représenté. Cette distinction est mise en place via les trois constructeurs de classes suivants :
– les classes de définition (item_class) qui contiennent les propriétés essentielles d’une classe ;
– les classes de représentation (functional_model_class) qui contiennent les propriétés qui n’ont de sens que par rapport à un point de vue ;
– les classes de vue (functional_view_class) qui définissent la perspective ou le point de vue selon lequel sont définies les propriétés des classes de représentation.
Ainsi, une instance peut appartenir non seulement à sa classe de base mais également aux classes de représentation attachées à cette classe de base par la relation is_view_of. Pour éviter toute redondance au niveau des valeurs des propriétés des instances, les propriétés définies sur la classe de base et sur les classes de représentation sont disjointes.
Remarque. Il est à noter que, contrairement à la modélisation orientée-objet, une instance n’a pas besoin de fournir une valeur pour l’ensemble des propriétés applicables sur sa classe de base. Ainsi, une propriété applicable peut ou non être utilisée dans la représentation d’une instance particulière dans un univers formel particulier (base de données, échange informatisé, etc.).
Exemple. L’exemple suivant présente l’ajout de la classe Administrator à l’ontologie SIOC en utili-sant le modèle PLIB.
is_case_of : User imported_properties : first_name, last_name, email definition : ’a person responsible for the administration of forums’ remark : ’an administrator is allowed to banish an user from a forum’ icon : ’logo_administrator.jpg’
dependent_P_DET :
salary : real_currency_type currency : .USD. depends_on : date condition_DET :
date : string_type )
Explication. Les ontologies PLIB sont habituellement représentées sous la forme de fichiers physiques EXPRESS. Dans cet exemple, nous utilisons notre propre syntaxe par soucis de lisibilité. Ainsi, la classe Administrator est définie comme étant subsumée par la classe User en utilisant l’opérateur case_of. L’utilisation de cet opérateur permet de n’importer que les propriétés de la classe User per-tinentes pour la classe Administrator. Ainsi, la propriété subscriber_of n’a pas été importée, considérant que l’on ne s’intéresse pas aux forums auxquels l’administrateur d’un forum particulier peut, par ailleurs, être abonné. La classe Administrator est décrite par une définition et une re-marque. Une icône lui est également associée sous la forme d’une image. Cette icône pourra, par exemple, être affichée lorsqu’un administrateur interviendra sur un forum. La classe Administra-torest le domaine de définition de la propriété salary. Le codomaine de cette propriété est le type réel associé à une unité de monnaie (real_currency_type). L’unité de mesure associée à ce type est le dollar (code .USD.). Les valeurs de cette propriété dépendent de la date à laquelle le salaire d’un administrateur est considéré. Ceci est représenté en PLIB en définissant salary comme une propriété dépendante du paramètre de contexte date.
Le modèle d’ontologies PLIB permet donc de définir avec précision des concepts primitifs. Sa spécificité est de permettre de représenter le contexte dans laquelle une ontologie est définie [Pierra, 2007, Pierra, 2003]. Dans une ontologie PLIB, la représentation du contexte est exprimée aux trois ni-veaux suivants :
– explicitation du contexte de définition des classes et des propriétés. Une propriété doit être définie dans le contexte d’une classe et, afin de minimiser sa sensibilité au contexte, une classe doit définir l’ensemble des propriétés essentielles pour ses instances. Par contre, une instance d’une classe ne fournit pas nécessairement de valeur à toutes les propriétés de la classe ;
– explicitation du point de vue selon lequel un objet du mode réel est défini. Un même objet peut être représenté par plusieurs instances de classes correspondant aux différents points de vue. Chaque instance utilise des propriétés définies sur la classe correspondant à son point de vue ;
– explicitation du contexte d’évaluation des valeurs. Les valeurs permettant de caractériser les ins-tances de classes peuvent être associées à des unités de mesure ainsi qu’à des paramètres influant sur leur évaluation.
Comme RDF-Schema, PLIB ne contient aucun opérateur permettant de définir des équivalences conceptuelles.