Les modèles d’ontologies permettant la définition de OCNC fournissent des constructeurs pour construire des concepts définis dans une ontologie à partir d’autres concepts primitifs et/ou définis. Nous présentons dans les sections suivantes les modèles d’ontologies OWL et F-Logic qui offrent cette possi-bilité de différentes manières. Le modèle PLIB est en cours d’extension pour supporter cette possibilité.
3.2.1 OWL
Afin d’étendre le pouvoir d’expression de RDF-Schema, deux initiatives ont été lancées. La première est une initiative américaine lancée par la DARPA (Defense Advanced Research Projects Agency) qui a permis la spécification du langage DAML-ONT [Stein et al., 2000]. La seconde est une initiative sponsorisée par la communauté européenne qui a permis la spécification du langage OIL [Fensel et al., 2001]. La fusion de ces deux langages a donné naissance à DAML+OIL [Connolly et al., 2001] qui a servi de base pour la conception du langage OWL standardisé par le W3C.
Un objectif important de OWL est de pouvoir assurer que les raisonnements qui peuvent être réali-sés sur des ontologies conçues avec un sous-ensemble de ce langage soit décidables, c’est-à-dire qu’il soit possible de concevoir un algorithme qui puisse garantir de déterminer, dans un temps fini, si oui ou non les définitions fournies par une ontologie OWL peuvent être déduites à partir de celles d’une autre ontologie [Horrocks et al., 2003]. L’impossibilité d’obtenir un langage à la fois compatible avec RDF-Schema et dont les raisonnements associés soit décidables a poussé les concepteurs de OWL à en spécifier trois versions : OWL Lite, OWL DL et OWL Full. Ces trois versions offrent une expressivité croissante (OWL Lite ⊂ OWL DL ⊂ OWL Full). Les raisonnements associés à OWL Lite et OWL DL sont décidables mais ne sont pas, par contre, compatibles avec RDF-Schema car ils restreignent les ca-pacités des constructeurs de ce modèle. Par exemple, OWL Lite et OWL DL ne permettent pas qu’une classe soit une instance d’une autre classe ce qui est possible en RDF-Schema. En conséquence, toutes ontologies RDF-Schema n’est pas forcément une ontologie OWL Lite ou OWL DL. A l’opposé OWL Full est compatible avec RDF-Schema mais les raisonnements associés ne sont pas forcément décidables. Nous décrivons dans ce qui suit les constructeurs offerts par OWL DL. Nous préciserons ensuite les li-mitations de OWL Lite par rapport à ces constructeurs ainsi que les libertés permises par OWL Full.
– Constructeur d’ontologies. OWL permet de construire une ontologie comme étant un ensemble de définitions de classes et de propriétés regroupées dans un ou plusieurs espaces de noms. OWL fournit de nombreux attributs permettant de caractériser une ontologie comme par exemple owl:versionInfoqui indique son numéro de version.
– Constructeur de classes. owl:Class permet de définir des classes. Chaque classe est identifiée par un URI, elle est décrite de façon textuelle comme une classe RDF-Schema (rdfs:label et rdfs:comment). Ces classes peuvent être organisées dans une hiérarchie en utilisant le construc-teur rdfs:subClassOf de RDF-Schema. Il existe deux classes prédéfinies nommées owl:Thing et owl:Nothing. La classe owl:Thing est la super-classe de toutes les autres classes. Ainsi, toutes les instances appartiennent à cette classe. A l’opposé, owl:Nothing est une sous-classe de toutes les autres classes. Elle ne possède aucune instance.
sur les classes (owl:unionOf, owl:intersectionOf, et owl:complementOf), des restrictions permettant de définir en intention les instances d’une classe (owl:allValuesFrom, owl:some-ValuesFromet owl:hasValue) et un constructeur permettant de définir une classe en énumérant ses instances (owl:oneOf). Si C, P, I et V sont respectivement l’ensemble des classes, des pro-priétés, des instances et des valeurs de propriétés d’une ontologie, les signatures des constructeurs fournis pour définir des classes définies sont les suivantes :
– owl : unionOf : Cn → C permet de définir une classe comme étant l’union de plusieurs classes. Par exemple, la classe Human peut être définie comme étant l’union des classes Manet Woman ;
– owl : intersectionOf : Cn → C permet de définir une classe comme étant l’intersection de plusieurs classes. Par exemple, la classe Man peut être définie comme étant l’intersection des classes Human et Male ;
– owl : complementOf : C → C permet de définir une classe comme étant le complémen-taire d’une autre classe. Par exemple, la classe NonHuman peut être définie comme étant l’ensemble des instances qui n’appartiennent pas à la classe Human ;
– owl : allValuesFrom : P × C → C permet de définir une classe comme étant l’ensemble des instances qui ne prennent comme valeur d’une propriété que des instances d’une classe donnée. Par exemple, la classe DriverOfCarOnly peut être définie comme étant l’en-semble des instances qui ont pour valeur de la propriété vehicle des instances de la classe Carseulement ;
– owl : someValuesFrom : P × C → C permet de définir une classe comme étant l’ensemble des instances qui prennent comme valeurs d’une propriété au moins une instance d’une classe donnée. Par exemple, la classe DriverOfCar peut être définie comme étant l’en-semble des instances qui ont pour valeur de la propriété vehicle au moins une instance de la classe Car ;
– owl : hasValue : P × V → C permet de définir une classe comme étant l’ensemble des ins-tances qui prennent une certaine valeur pour une propriété donnée. Par exemple, la classe Male peut être définie comme l’ensemble des instances qui prennent la valeur M pour la propriété gender ;
– owl : oneOf : In→ C permet de définir une classe en extension, c’est-à-dire en indiquant la liste de ses instances. Par exemple, la classe Capital peut être définie par la liste des instances Paris, London, etc.
– Constructeur de propriétés. owl:ObjectProperty et owl:DatatypeProperty spécialisent le constructeur RDF-Schema rdf:Property pour permettre de définir des propriétés. Ces deux constructeurs sont fournis afin de distinguer les propriétés en fonction de leur codomaine. owl:Ob-jectProperty permet de définir des propriétés dont le codomaine est une classe tandis que owl:DatatypePropertypermet de définir une propriété dont le codomaine est un type de don-nées. Quel que soit son type, une propriété est définie comme une propriété RDF-Schema, c’est-à-dire par un domaine (rdfs:domain) qui peut être l’intersection de plusieurs classes, par un codo-maine (rdfs:range) et par sa place dans la hiérarchie des propriétés (rdfs:subPropertyOf). OWL permet également de qualifier une propriété. Ainsi, deux propriétés peuvent être définies
comme étant l’inverse l’une de l’autre (owl:inverseOf). Une propriété peut être définie comme étant symétrique (owl:SymmetricProperty), transitive (owl:TransitiveProperty), injec-tive (owl:InverseFunctionalProperty) ou comme étant une fonction (owl:Functional-Property). La signification de ces caractéristiques est celle qui en est donnée en mathématique. – Constructeur de types de données. Le type de données d’une propriété
owl:DatatypeProper-typeut être le type RDF-Schema rdfs:Literal ou un des types simples définis pour les XML Schéma dont la liste est donnée dans [Smith et al., 2004].
– Constructeur d’instances. Comme pour RDF-Schema, une instance OWL est définie en utilisant le constructeur RDF rdf:type, elle est identifiée par un URI et peut appartenir à plusieurs classes non liées par la relation de subsomption. Une instance est caractérisée par un ensemble de valeurs de propriétés.
– Constructeur d’axiomes. OWL permet de préciser le nombre de valeurs qu’une instance peut prendre pour une propriété donnée grâce aux axiomes owl:minCardinality, owl:cardinali-tyet owl:maxCardinality. L’axiome owl:equivalentClass indique que deux classes sont équivalentes, c’est-à-dire qu’elles possèdent les mêmes instances. A l’inverse, l’axiome owl:dis-jointWithindique que les extensions de deux classes données sont disjointes, c’est-à-dire qu’elles n’ont aucune instance en commun. De même, OWL permet d’indiquer que deux propriétés sont équivalentes, c’est à dire qu’elles présentent des valeurs pour les mêmes instances et que ces va-leurs sont identiques pour les mêmes instances, par l’axiome owl:equivalentProperty. En OWL, deux instances d’une ontologie ayant des identifiants différents peuvent être le même élé-ment. Ainsi, OWL ne fait pas l’hypothèse d’unicité des noms qui consiste à considérer que les identifiants permettent d’identifier de manière unique un élément dans une ontologie. En consé-quence, il propose les axiomes owl:sameAs, owl:differentFrom et owl:AllDifferent per-mettant d’indiquer l’égalité ou l’inégalité des instances.
Exemple. L’exemple suivant présente la définition de la classe PostAdministrator contenant l’en-semble des messages créés par un administrateur, et la classe PostUser contenant les autres mes-sages.
Class (PostAdministrator complete Post
restriction (has_creator allValuesFrom (Administrator))) Class (PostUser complete Post complementOf (PostAdministrator))
Explication. Cet exemple utilise la syntaxe abstraite de OWL [Patel-Schneider et al., 2004], plus lisible que la syntaxe RDF/XML. La classe PostAdministrator est définie comme étant équivalente à (complete) l’intersection de la classe Post et de l’ensemble des instances qui prennent une instance de la classe Administrator comme valeur de la propriété has_creator (PostAdministrator). La classe PostUser est définie comme étant équivalente à l’intersection de la classe Post et du complémentaire de la classe PostAdministrator.
Les constructeurs de OWL-DL, présentés précédemment, ont été choisis de manière à ce que les raisonnements associés à ce langage restent décidables. Le problème d’inférence en OWL DL a ainsi pu être classé comme étant aussi difficile que ce problème dans les langages des logiques de description de la famille SH OI N (D). Des travaux ont montré que ces langages sont de complexité au pire des cas de temps exponentiel non déterministe (NExpTime) [Tobies, 2001]. En pratique, il n’existe pas d’algorithme
connu pour implanter un moteur d’inférence sur de tels langages satisfaisant aux exigences usuelles en termes de qualité et temps de réponse [Horrocks et al., 2003]. C’est pour cela, que certains constructeurs ont été simplifiés ou supprimés pour obtenir une version de OWL DL allégée nommée OWL Lite. Voici ces simplifications :
– la création de classes par les opérations booléennes owl:unionOf et owl:complementOf ou par énumération de ses individus est interdite ;
– la restriction owl:hasValue ne peut pas être utilisée ;
– les axiomes de cardinalité owl:minCardinality, owl:cardinality et owl:maxCardinality sont limités à prendre la valeur 0 ou 1.
Le troisième niveau de OWL se nomme OWL Full. Il se caractérise par une compatibilité totale avec RDF et RDF-Schema. En conséquence, cette version permet de traiter une instance comme une classe. Elle autorise également l’utilisation des constructeurs OWL comme paramètres de ses propres constructeurs. Il est par exemple possible d’indiquer qu’une classe donnée ne doit pas avoir plus de 2 super-classes. Ce pouvoir d’expression fait que les raisonnements associés à OWL Full ne sont pas décidables.
Nous venons de voir que le modèle d’ontologies OWL se focalise sur la définition de concepts définis, c’est-à-dire appartenant à une OCNC. Les constructeurs offerts par ce modèle sont issus des logiques de description. Dans la section suivante, nous présentons le modèle d’ontologies F-Logic qui se focalise également dans la définition de OCNC mais, cette fois-ci, en définissant des constructeurs issus de la logique des frames.
3.2.2 F-Logic
F-Logic (Frame Logic) [Kifer et al., 1995] est un langage de modélisation de connaissances qui combine les capacités de modélisation des modèles orientés-objets avec l’expressivité de la logique. Cette combinaison permet d’obtenir un langage disposant des constructeurs suivants.
– Constructeur de classes. F-Logic permet de définir des classes. Ces classes peuvent être or-ganisées dans une hiérarchie en utilisant l’héritage multiple (opérateur ::). Par exemple, pour définir que la classe Homme est une sous classe de la classe Humain, nous écrivons en F-Logic Homme:: Humain. Contrairement aux modèles d’ontologies précédents, les classes ne sont pas identifiées de manière universelle via des mécanismes comme les BSU en PLIB ou les espaces de noms en OWL. Cependant, OntoBroker8 une des implantations les plus connues de F-Logic supporte le mécanisme d’espaces de noms.
– Constructeur de propriétés. F-Logic permet de définir des propriétés monovaluées (⇒) et mul-tivaluées (⇒⇒ ). Ces propriétés doivent être définies en même temps que leur classe de définition. Par exemple, l’expression Homme[nom ⇒ string] permet de définir la propriété nom définie sur la classe Homme. Il permet également de définir des méthodes. Les auteurs de F-Logic précisent qu’il n’y a pas de différence essentielle entre les propriétés et les méthodes, ces dernières permettent simplement de caractériser une instance par une valeur en fonction d’autres valeurs appelées
guments. Par exemple, l’expression Homme[salaire@date ⇒ integer] permet de définir une méthode salaire pour la classe Homme dont la valeur dépend d’une date.
– Constructeur de types de données. Les types de données sont utilisés en F-Logic pour définir le codomaine des propriétés ainsi que les arguments d’une méthode. F-Logic permet d’utiliser des types primitifs (integer, real, string et date) et les classes comme types de données. Il supporte les collections de type ensemble.
– Constructeur d’instances. Une instance F-Logic est caractérisée par les classes auxquelles elle appartient (multi-instanciation) ainsi que ses valeurs de propriétés. Par exemple, l’expression Bob: Homme[nom → ”bob”] indique que l’instance de la classe Homme dont l’identifiant est Bob possède la valeur "bob" pour la propriété nom. Comme pour RDF-Schema, F-Logic permet qu’une instance soit traitée comme une classe et ainsi elle peut avoir des instances. Cette capacité est qualifiée de méta-modélisation.
– Constructeur de règles Pour offrir des capacités déductives, F-Logic est équipé d’un langage de règles. Une règle F-Logic se présente sous la forme conclusion ← precondition. La pré-condition est appelée le corps de la règle. Elle est composée d’expressions F-Logic indiquant l’appartenance d’une instance à une classe, une valeur de propriété ou une méthode. Ces expres-sions peuvent comporter des variables quantifiées avec l’opérateur existentiel (∃) ou universel (∀) et peuvent être composées par les opérateurs booléens ( ∨, ∧ et ¬). La conclusion est appelée la tête de la règle. Elle est également composée d’une expression F-Logic du même type que celles présentes dans la précondition. Les variables utilisées dans la tête de la règle doivent être utili-sées dans la précondition. L’exécution d’une règle consiste à rechercher les valeurs des variables qui permettent de satisfaire la précondition. Les faits déduits sont ceux obtenus en remplaçant les variables de la conclusion par les valeurs qui satisfont la précondition.
Le langage de règles de F-Logic permet d’introduire des concepts définis dans une ontologie. Voici deux exemples illustrant cette capacité.
Exemple. Définir la classe PostDupont comme étant les messages écrits par l’utilisateur Dupont. P: PostDupont ← P : Post ∧ P[has_creator → U[last_name → ”Dupont”]]
Explication. La précondition de cette règle introduit la variable P instance de la classe Post. Par dé-faut, la quantification de cette variable est universelle. Pour chaque variable P dont le créateur (has_creator → U) est Dupont ([last_name → ”Dupont”]), la conclusion est déduite. Celle-ci indique que la variable P appartient à la classe PostDupont.
Exemple. Définir la propriété author qui indique le nom de l’utilisateur qui a créé un message. P[author → N] ← P : Post ∧ N : String ∧ P[has_creator → U[last_name → N]]
Explication. La précondition introduit les variables P et N représentant respectivement une instance de la classe Personne et une chaîne de caractères (String). Pour chaque post P qui a comme créateur U, le nom de U est recherché (N). La conclusion indique que l’auteur du message P est le nom N.
Nous venons de voir que le langage F-Logic se focalise sur la définition de OCNC en permettant d’utiliser un langage de règles. Nous abordons maintenant le cas des OL.