Création d'une ontologie en OWL avec Protégé 4 Rémy Choquet AP-HP & Inserm U872 remy.choquet@gmail.com Réalisé d'après le document « A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools », disponible à l'adresse suivante : http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial-p4.0.pdf

Plan Quelques connaissances sur OWL Création d'un canevas d'ontologie La hiérarchie des classes et sous classes La disjonction Les relations Les différentes caractéristiques Le domaine et la portée Les restrictions Les restrictions existentielles Les restrictions universelles Les classifieurs

Les 3 versions d'OWL OWL-Lite OWL-DL OWL-Full Simple hérarchie de concepts et peu de contraintes Organisation hiérarchique de thésauri OWL-DL Fondé sur les logiques de description Implémente un fragment de la logique du premier ordre Vérifie la hiérarchie des concepts et détecte les inconsistances OWL-Full Langage le plus expressif A utiliser dans des situations où l'expressivité est plus importante que la complétude et la décidabilité -> pas de raisonnement automatique

Quels sont les composants d'OWL? (1)‏ Les instances de classes (individuals)‏ Ce sont les objets du domaine qui nous souhaitons modéliser Ex : Pierre, Thierry, Marie, Italie, USA... Les propriétés ou relations (properties)‏ « Slots » dans Protégé Ce sont des relations binaires entre des instances de classes Ex : [Marie] (hasChild)[Pierre] Caractéristiques Inverses : hasOwner/isOwnedBy Fonctionnelle : une seule valeur Transitive Symétrique

Quels sont les composants d'OWL? (2)‏ Les concepts ou classes Ce sont des ensembles d'instances Ex : le concept Pays est constitué de la France, l'Italie, les USA... Les classes sont construites à partir de descriptions qui contraignent les conditions d'appartenance d'une instance à une classe -> Sujet du tutoriel

Avant de commencer... Protégé 4 : éditeur d'ontologies gratuit et “open source” qui permet de structurer une base de connaissances http://protege.stanford.edu/ Téléchargement du logiciel http://protege.stanford.edu/download/protege/4.0/installanywhere / Installation

Création d'une nouvelle ontologie avec Protégé 4 (1) Démarrer Protégé 4 Dans la fenêtre « Welcome to Protégé », choisissez « Create new OWL ontology »

Création d'une nouvelle ontologie avec Protégé 4 (2) Dans la fenêtre « Create Ontology wizard », changez l'adresse URI par http://www.pizza.com/ontologies/pizza.owl

Résultat

Création d'une nouvelle ontologie avec Protégé 4 (3) Dans la fenêtre suivante, pensez à sauver votre ontologie en nommant votre fichier « pizza.owl » 06/10/09

Résultat

Format de sauvegarde de l’ontologie

Création d'une nouvelle ontologie avec Protégé 4 (4)

1. Ajouter un commentaire à l'ontologie Assurez-vous que l' onglet ‘Active Ontology’ est sélectionné Dans la partie dédiée à ‘Ontology Annotations’, double cliquez sur le signe + à droite d'Annotations. Une fenêtre éditable apparaît. Entrez un commentaire tel que « A pizza ontology that describes various pizzas based on their toppings» dans le champ « description ». Cliquez sur OK. 06/10/09

Fig 1: The Ontology Annotations View Résultat Fig 1: The Ontology Annotations View

L'onglet Classes / The Classes Tab Fig 2: The Classes Tab

Icônes pour créer une hiérarchie de classes Ajouter une sous classe Ajouter une classe sœur Effacer une classe Fig 3 – Icônes des classes

2. Création des classes Pizza, Pizza Topping et PizzaBase Assurez-vous que l'onglet ‘Classes Tab’ est sélectionné. Pressez le bouton d'ajout d'une classe. Une nouvelle classe apparaît comme sous classe de celle que vous avez sélectionnée. Une boîte de dialogue apparaît et vous permet de saisir le nom de votre nouvelle classe. Tapez Pizza. Répétez l'opération pour les classes PizzaTopping et PizzaBase. Assurez-vous que ces classes apparaissent sous la classe Thing dans la hiérarchie. → Vocabulaire : Une hiérarchie de classe peut également être appelée une taxinomie.

Résultat Fig 4: Class Name Dialog Fig 5: The Initial Class Hierarchy

Idée Après avoir créé Pizza, plutôt que de sélectionner Thing et d'utiliser le bouton de création d'une sous classe, vous pouvez utiliser le bouton de création d'une classe sœur (cf. Figure 3) pour créer PizzaTopping et PizzaBase. Il faut dans ce cas sélectionner la classe Pizza.

3. Classes disjointes Faire de Pizza, PizzaTopping et PizzaBase des classes disjointes les unes des autres Sélectionnez la classe Pizza dans la hiérarchie. Pressez le bouton ‘Disjoint classes’ dans la partie ‘class description’. Une fenêtre s'ouvre et vous permet de choisir les classes qui doivent être disjointes. Si vous le faites pour une des classes (par exemple PizzaBase), l'action sera automatiquement propagée sur les autres classes sélectionnées. Résultat Sélectionnez la classe PizzaBase. Notez que cette classe est maintenant disjointe de Pizza et PizzaTopping. Risque : si on déplace ensuite les classes, on crée facilement des incohérences

Qu'est ce que cela signifie? En OWL, les classes, par définition, se chevauchent. Nous ne pouvons pas donc pas supposer qu'un(e) individu/instance n'est pas membre d'une classe particulière simplement parce qu'il n'a pas été défini comme étant un membre de cette classe. Pour séparer un groupe de classes, nous devons les déclarer comme disjointes les unes des autres. Cela assure qu'un individu créé comme membre d'une classe du groupe ne peut pas être membre d'une autre classe de ce même groupe. Dans notre exemple précédent, Pizza, PizzaTopping et PizzaBase sont disjointes entre elles. Cela signifie qu'aucun individu ne peut être à la fois une Pizza et une PizzaBase.

Peupler une ontologie : créer des classes avec les outils OWL Les outils OWL mis à disposition dans cette version de Protégé sont des plugins. Ils servent à simplifier des traitements répétitifs et longs. Dans le 4e exercice, nous allons utiliser l'outil ‘Create Class Hierarchy’ pour ajouter des sous classes à la classe PizzaBase. Fig 6: Menu Create Class Hierarchy 06/10/09

Fig 7: Create Class Hierarchy: Select class page

Fig 8: Create Class Hierarchy: Enter classes page

4. Utiliser l'outil ‘Create Class Hierarchy’ pour créer les sous classes de PizzaBase : ThinAndCrispy et DeepPan(1) Sélectionnez la classe PizzaBase dans la hiérarchie. L'outil vu Figure 7 apparaît. Puisque nous avons présélectionné la classe PizzaBase, l'outil devrait nous inciter à créer les classes sous la classe PizzaBase. Si nous n'avions pas présélectionné PizzaBase avant de lancer l'outil, la hiérarchie pourrait être utilisée pour choisir la bonne classe mère. Pressez le bouton ‘Continue’. La page vue Figure 8 apparaît. Nous devons maintenant indiquer les sous classes de PizzaBase que nous souhaitons créer. Dans la zone de texte, tapez ThinAndCrispyBase (pour une pizza à pâte fine) et DeepPanBase (pâte épaisse). Le résultat est visible Figure 8 .

4. Utiliser l'outil ‘Create Class Hierarchy’ pour créer les sous classes de PizzaBase : ThinAndCrispy et DeepPan(2) Pressez le bouton 'Continue'. L'outil vérifie que les noms saisis correspondent au style prédéfini (pas d'espace, pas d'accent...). Il vérifie également que ces noms n'existent pas déjà. Cochez le bouton radio ‘Make all new classes disjoint’.

5. Créer des garnitures (toppings) pour votre pizza Les classes de garnitures que nous allons créer doivent être structurées en catégories meat toppings, vegetable toppings, cheese toppings, seafood toppings. Fig 9: Topping Hierarchy

6. Créer des sous-classes de PizzaTopping (1) Sélectionnez la classe PizzaTopping dans la hiérarchie. Lancez l'outil ‘Create class hierarchy...’ comme dans l'exercice 4. Assurez-vous que PizzaTopping est sélectionné et pressez le bouton ‘Continue’. Nous voulons que les noms des nouvelles classes terminent tous par 'topping'.Dans la zone de texte intitulée 'Suffix', tapez 'Topping'. L'outil ajoutera automatiquement cette terminaison à l'ensemble des noms de classes que vous allez créer.

6. Créer des sous classes de PizzaTopping (2) L'outil permet de créer une hiérarchie de classes en utilisant les indentations. En utilisant la zone de texte, entrez les noms des classes comme indiqué Figure 9. Notez que les noms des classes doivent être indentés en utilisant la touche 'tabulation'.

Résultat Fig 10: La hiérarchie des classes

De l’intension à l’extension Des Ce à quoi vous pensez en fabriquant une ontologie est l’intension des concepts Ce que vous fabriquez dans Protégé respecte une logique des prédicats. Sans le savoir vous traitez vos concepts d’une manière logique donc ensembliste et ils existent par les objets, les instances, qui appartiennent à la classe Vous passez de l’intension à l’extension Vous devez vous en souvenir pour comprendre certains comportements de l’outil et des plugins de raisonnement.

La signification des sous-classes PizzaTopping VegetableTopping TomatoTopping Fig 11: Tous les individus (instances) qui sont membres de la classe TomatoTopping sont également membres de la classe VegetableTopping et membres de la classe PizzaTopping car TomatoTopping est une sous-classe de VegetableTopping qui est une sous-classe de PizzaTopping.

Le point Nous avons créé quelques classes simples, certaines sont des sous classes dans la hiérarchie. Jusqu'ici la construction de la hiérarchie des classes peut sembler facile et intuitive. Cependant, qu'est-ce que cela signifie d'être une sous-classe d'une autre en OWL? Par exemple, qu'est ce que cela implique pour VegetableTopping d'être une sous classe de PizzaTopping, ou pour TomatoTopping d'être une sous classe de VegetableTopping? En OWL être une sous-classe a nécessairement des implications. En d'autres termes, si VegetableTopping est une sous- classe de PizzaTopping alors toutes les instances de VegetableTopping sont des instances de PizzaTopping, sans exception — si quelque chose est un VegetableTopping alors c'est aussi un PizzaTopping comme vu Figure 11.

Les relations en OWL / OWL Properties Fig 12: The PropertiesTab

7. Créer une relation nommée hasIngredient Allez sur l'onglet ‘Object Properties’. Utilisez le bouton ‘Add Object Property’ pour créer une nouvelle relation. Nommez la nouvelle propriété hasIngredient en remplissant la boîte de dialogue ‘Property Name Dialog’ qui s'affiche.

8. Créer hasTopping et hasBase comme sous relations de hasIngredient Le langage OWL permet de définir des sous relations et donc de créer des hiérarchies de relations comme on a des hiérarchies de classes. Les sous relations (propriétés) sont des spécialisations de leur relation mère. Par exemple, la relation hasMother, entant que sous relation, spécialise la relation hasParent. Pour créer la relation hasTopping property comme sous relation de la relation hasIngredient, sélectionnez la relation hasIngredient dans la hiérarchie qui s'affiche dans l'onglet ‘Object Properties’. Pressez le bouton ‘Add subproperty’ et nomdialogue qui apparaît à l'écran. Validez. Répétez l'opération pour créer la relation hasBase.

Les différentes caractéristiques des relations en OWL Fonctionnelle Une relation est déclarée fonctionnelle lorsqu'un seul individu au plus peut y être relié. Jean hasBirthMother Catherine. HasBirthMother est fonctionnelle. Inverse Chaque relation peut avoir une relation inverse La relation hasParent a pour inverse la relation hasChild, et réciproquement. Inverse et fonctionnelle Exemple : isBirthMotherOf Transitive Peter hasAncestor Mat. Mat hasAncestor Jim => Peter hasAncestor Jim. Symétrique Mat hasSibling Jim => Jim hasSibling Mat. Asymétrique Robert isChildOf Peter => Peter is not a child of Robert. Réflexive versus Irréflexive

9. Créer des relations inverses Pour créer une ontologie complète, nous allons spécifier les relations inverses correspondantes à celles existantes. Créez la relation isIngredientOf qui deviendra l'inverse de hasIngredient. Pressez le bouton ‘Add inverse property’ (cf. Fig 13). Cette action ouvre une boîte de dialogue dans laquelle vous allez devoir sélectionner la relation inverse (ici hasIngredient). Créez la relation isBaseOf qui deviendra l'inverse de hasBase. Déclarez la inverse. Répétez l'opération en créant isToppingOf, l'inverse de la relation hasTopping.

Fig 13: The Inverse Property View

Fig 14: La hiérarchie des relations Résultat Fig 14: La hiérarchie des relations

10. Indiquer que la relation hasIngredient est transitive

11. Indiquer que la relation hasBase est fonctionnelle Cela fonctionne de la même manière que les relations inverses.

12. Spécifier le domaine et la portée (range) de la relation hasTopping En OWL les relations sont binaires et interviennent pour mettre en relation deux individus (cf. Figure 15) [Domaine] (Relation) [Portée] [Pizza] (hasTopping) [PizzaTopping] Sélectionnez la relation hasTopping dans la hiérarchie Fixez la portée : pressez le bouton 'Add' (+) en face de 'Ranges' dans la partie description de l'interface (cf. Figure 16) Fixez le domaine : pressez le bouton 'Add' (+) en face de 'Domains' dans la partie description de l'interface (cf. Figure 17)

Fig 15: Le domaine et la portée de la relation hasTopping et de son inverse isToppingOf

Résultat Fig 16: La portée de la relation hasTopping Fig 17: Le domaine de la relation hasTopping

13. Spécifier le domaine et la portée de la relation hasBase et de son inverse isBaseOf Sélectionnez la relation hasBase Spécifiez Pizza comme domaine et PizzaBase comme portée Sélectionnez la relation inverse isBaseOf Spécifiez PizzaBase comme domaine et Pizza comme portée

Le point Si l'on reprend l'exemple de la relation hasTopping Les individus qui appartiennent à la partie gauche de la relation sont interprétés comme étant membres de la classe Pizza. Les individus qui apparaissent dans le contexte droit de la relation sont compris comme appartenant à la classe PizzaTopping. Nous venons de créer un certain nombre de relations. Nous allons maintenant les utiliser pour décrire et spécifier le fonctionnement des classes de notre ontologie.

Les deux types de restrictions (1) Restriction existentielle (some) Les restrictions existentielles sont les plus courantes dans les ontologies OWL Cette restriction décrit une classe d'individus qui entretient au moins une (some) relation avec un individu membre d'une classe spécifique Fig 18: La restriction hasTopping some Mozarella.

Les deux types de restrictions (2) La restriction universelle (only) Cette restriction décrit des classes d'individus qui pour une relation donnée n'ont de lien qu'avec les individus d'une classe spécifique Par exemple, la classe des individus qui n'ont comme garniture (hasTopping) que les individus appartenant à la classe des légumes (VegetableTopping).

14. Ajouter une restriction spécifiant que Pizza doit avoir une PizzaBase Sélectionnez la classe Pizza dans l'onglet 'Classes' Sélectionnez la ligne 'Superclasses' dans la partie 'Class Description' Pressez le bouton + (Add) sur cette ligne. Cela ouvre une boîte de dialogue contenant le 'Class expression editor' dans lequel vous allez saisir votre restriction. Vous pouvez soit écrire hasBase soit faire un « drag and drop ». Attention, la manière d'écrire le mot doit être la même que celle existante. Écrivez ensuite le type de restriction, ici « some ». Enfin, écrivez PizzaBase. Vous devez avoir sur la même ligne (cf. Fig 20 et 21) hasBase some PizzaBase

Résultat Fig 20 : Le 'class expression editor' Fig 21 : La restriction dans son aspect final

15. Créer la classe MargheritaPizza Sélectionnez la classe Pizza dans la hiérarchie Ajoutez une sous classe nommée 'NamedPizza' Créez une sous classe de NamedPizza que vous appellerez 'MargheritaPizza' Ajoutez un commentaire à cette classe en précisant qu'il s'agit d'une pizza composée de mozarella et de tomato toppings

16. Créer une restriction existentielle pour définir la MargheritaPizza Sélectionnez MargheritaPizza dans la hiérarchie Suivez les instructions de l'exercice précédent pour décrire cette classe comme ayant, comme garniture, de la mozarella HasTopping some MozarellaTopping Répétez l'opération pour dire qu'elle a aussi de la tomate HasTopping some TomatoTopping Attention, cela veut dire que la Margherita contient au moins (au minimum) de la mozarella et de la tomate mais ... elle peut contenir également d'autres garnitures.

Fig 22 : Les restrictions pour la MargheritaPizza Résultat Fig 22 : Les restrictions pour la MargheritaPizza

Monde ouvert vs monde fermé Des Une Margherita contient au moins (au minimum) de la mozarella et de la tomate mais ... elle peut contenir également d'autres garnitures. Ce n’est pas parce que quelque chose n’a pas été dit, qu’il est faux. Tout peut être vrai tant qu’il n’a pas été déclaré faux. Nous sommes dans l’hypothèse du monde ouvert quand nous créons des ontologies. Si l’on veut que quelque chose soit faux nous devons explicitement le dire. C’est le contraire de ce qui se passe dans une base de données. Dans une base de données, si une réponse à une requête ne ramène rien, alors la requête est falsifiée : ce qui n’est pas trouvé est faux. Dans une base de données, nous sommes dans l’hypothèse du monde fermé. Pour reproduire ce comportement dans une ontologie, il faut créer un axiome de clôture, une restriction universelle (only)

17. Arbres versus treillis (1/2) Créer les attributs d’ingrédients piquants, Epice, Moyen, Doux, ExtraDoux et la relation aPourQualiteDEtreEpice. Faites-en une value partition Créer les attributs d’ingrédients maigres, TresCalorique, MoyennementCalorique, PeuCalorique et la relation aPourQualiteDEtreCalorique. Faites-en une value partition Déclarez une Pizza définie, comme épicée si sa qualité est Epice Déclarez une Pizza définie comme calorique si sa qualité est TresCalorique 58

17. Arbres versus treillis (2/2) Précisez que la GarnitureBoeufEpice est Epice. Idem pour GarniturePoivreVert Précisez que GarnitureAnchoix et GarnitureFruits sont PeuCalorique Affichez l’arbre des GarniturePizza avant classification puis après classification Discutez 59

05/10/10

05/10/10

Les concepts différentiels vs formels Différentiel et Primitif ne sont pas des notions homologues du niveau différentiel au niveau formel Ils forment un arbre organisé par genre et différence donc de notions exclusives les unes des autres Leur image au niveau formel forme évidemment un arbre Ce sont, au début de la construction du niveau formel, des concepts primitifs 05/10/10

Les concepts différentiels vs formels Différentiel et Primitif ne sont pas des notions homologues du niveau différentiel au niveau formel Les concepts issus du niveau différentiel forment logiquement un arbre de concepts formels disjoints De nouveaux concepts, définis, viennent compléter l'arbre précédent L'image, au niveau formel, de certains concepts différentiels, peut devenir, pour les nécessités de la modélisation, des concepts définis La classification de l'ensemble des concepts (primitifs et définis) ne modifie pas l'ordre des concepts différentiels les uns par rapport aux autres L'ensemble des concepts forme un treillis de notions pas toutes disjointes 05/10/10

18. Créer une restriction universelle sur la MargheritaPizza Sélectionnez la MargheritaPizza dans la hiérarchie Suivez les instructions de l'exercice précédent pour décrire cette classe comme ayant absolument une MozarellaTopping or une TomatoTopping et rien d’autre. 64

Fig 19: Les restrictions de la classe MargheritaPizza

19. Créer une AmericanaPizza Sélectionnez la MargheritaPizza dans la hiérarchie Enlevez l’axiome de clôture Sélectionnez, dans le menu 'Edit', l'opération 'Duplicate selected class'. Renommez cette seconde classe en AmericanaPizza. Ajoutez deux restrictions à la classe AmericanaPizza Elle est composée (en plus de mozarella et de tomates) de Pepperoni hasTopping some PepperoniTopping

Résultat

20. Créer une AmericanHotPizza et une SohoPizza L'AmericanHotPizza est presque la même que l'AmericanaPizza. Dupliquez l'AmericanaPizza, renommez-la et ajouter une restriction existentielle comme suit : hasTopping some JalapenoPepperTopping La SohoPizza est une MargheritaPizza mais à, comme garniture supplémentaire, des olives et du parmezan : hasTopping some OlivesTopping hasTopping some ParmezanTopping

Résultat

20. Déclarer les sous-classes de NamedPizza disjointes des unes des autres MargheritaPizza SohoPizza AmericanaPizza AmericanHotPizza

21. Classes inconsistantes Pour démonter l’utilité du raisonneur dans la détection d’inconsistances, nous allons créer une classe qui est une sous classe de CheeseTopping et aussi de VegetableTopping. Sélectionnez la classe CheeseTopping Créez une sous classe nommée ProbeInconsistentTopping Sélectionnez ProbeInconsistentTopping dans la hiérarchie et sélectionnez « Superclasses » dans le panel à droite Cliquez sur le ‘+’ et sélectionnez la classe VegetableTopping. Validez. La classe VegetableTopping a normalement été ajoutée à la liste des superclasses de ProbeInconsistentTopping Lancer le raisonneur

Lancez le classifieur/raisonneur

Résultat : la classe ProbeInconsistent Topping est inconsistante

Signification La classe ProbeInconsistentTopping est définie comme étant à la fois du fromage et des légumes. Or, aucune instance du monde ne peut être les deux à la fois. Cela dit, pour le raisonneur le nom des classes n’a pas de signification. L’inconsistance est détectée car nous avons déclaré les deux classes mères, CheeseTopping et VegetableTopping comme étant disjointe l’une de l’autre. Autrement dit, les individus membres de la classe CheeseTopping ne peuvent pas être membres de la classe VegetableTopping et vice-versa.

Enlever l’indication de disjonction Enlever l’indication de disjonction entre VegetableTopping et CheeseTopping Relancer le classifieur Normalement, la classe ProbeInconsistentTopping n’est plus inconsistante et n’est plus en rouge Désormais un individu du monde décrit peut être à la fois un membre de la classe CheeseTopping et un membre de la classe VegetableTopping Il convient donc d’être très prudent quand on spécifie (ou non) une disjonction. Remettre l’indication de disjonction.

Quand c’est “rouge”, que faire ? Une incohérence se propage. Remonter à la source Une classe peut avoir une condition non satisfaite dans une condition existentielle (some) Chaque sous-classe d’une classe insatisfiable est elle-même insatisfiable Quelques possibilités Violations des axiomes d’exclusion mutuelle Expressions insatisfiables En particuler, confusion entre “and” et “or” Violation d’une contrainte universelle (only), y compris domaine et co-domaine Insatisfaction de contraintes de (co-)domaines

Disjonction, exhaustivité et arbre Des Mettre des relations de disjonctions entre les concepts primitifs doit être fait quand on commence à penser que l’ontologie a une structure un peu stable Faire cela suppose qu’on a un arbre de concepts primitifs C’est pragmatique mais surtout épistémologiquement fondé : les objets n’ont qu’une seule essence, une seule manière d’être. Ces disjonctions n’empêchent pas d’utiliser 2 concepts exclusifs les uns des autres pour construire une représentation Une pizza et une garniture de pizza n’ont rien à voir l’une avec l’autre. Il n’y a pas d’instance qui soit à la fois Pizza et garniture mais une MargheritaPizza est bien une pizza avec une garniture (de fromage ou tomate).

22. Créez une CheesyPizza Créer une CheesyPizza comme sous-classe de Pizza (elle a donc pour classe sœur NamedPizza) Définissez-la comme étant une pizza avec du fromage hasTopping some CheeseTopping Cela signifie qu’une pizza contenant du fromage peut être une CheesyPizza -> nous souhaitons modifier la définition pour dire qu’une pizza au fromage a comme condition nécessaire et suffisante de contenir du fromage

Critère nécessaire et suffisant -> classe définie Sélectionnez CheesyPizza dans la hiérarchie Sélectionnez ‘hasTopping some CheeseTopping’ dans les restrictions au niveau du panel de droite Faites un cliquez-déposez de la ligne et amenez la au dessus de « Equivalent class » Sélectionnez ensuite la classe Pizza dans le panel de droite Faites un cliquez-déposez de cette classe au dessus de ‘hasTopping some CheeseTopping’

Résultat Ensuite, relancer le classifieur

Résultat pour la CheesyPizza Pourquoi?

Conditions nécessaires vs nécessaires et suffisantes I Des Jusqu’à la CheesyPizza, les conditions exprimées dans les descriptions de classes ont été des conditions nécessaires. Pour ces classes, ces conditions sont celles qu’une instance doit remplir pour être un membre de la classe. Pour certaines classes, e.g. CheesyPizza, ces conditions représentent la superclasse de la classe. Autrement dit, dans quelle classe mettre une instance dont on connaît les conditions exactes qu’elle remplit ? On la met dans une classe décrite par conditions nécessaires et suffisantes, une classe définie. OWL supporte ces conditions nécessaires et suffisantes qui permettent de déterminer que toute instance qui satisfait ces conditions peut être rangée, par inférence, dans la classe définie par ces mêmes conditions

Conditions nécessaires vs nécessaires et suffisantes II Des On oppose ainsi les classes primitives, définies par conditions nécessaires, aux classe définies, définies par conditions nécessaires et suffisantes. Les classes qui ont seulement des conditions nécessaires supportent une description, les classes qui ont des conditions nécessaires et suffisantes ont une définition. Une distinction peut être faite entre les informations axiomatiques (asserted) et les informations inférées (inferred).