Lisez-moi S.V.P. 
W3C

Le langage d'ontologie Web OWL
Guide

Recommandation du W3C du 10 février 2004

Cette version :
http://www.w3.org/TR/2004/REC-owl-guide-20040210/
Dernière version :
http://www.w3.org/TR/owl-guide/
Version précédente :
http://www.w3.org/TR/2003/PR-owl-guide-20031215/
Rédacteurs :
Michael K. Smith, Electronic Data Systems, Michael dot Smith at e d s dot com
Chris Welty, IBM Research, Chris dot Welty at u s dot ibm dot com
Deborah L. McGuinness, Stanford University, d l m at k s l dot stanford dot edu

Veuillez consulter l'errata de ce document, lequel peut contenir des corrections normatives.

Cf. d'éventuelles traductions.


Résumé

Le World Wide Web dans son état actuel ressemble à une géographie avec de mauvaises cartes. Notre compréhension des documents et les moyens dont nous disposons reposent sur des recherches par mots-clés, que confortent une utilisation astucieuse de la connectivité des documents et les habitudes. Cette masse énorme de données est ingérable sans l'aide d'un outil puissant. Pour une cartographie plus précise de ce territoire, les agents de traitement ont besoin de descriptions du contenu interprétables par des machines et de ressources accessibles par le Web. Ces descriptions doivent venir en plus des informations des versions lisibles par des humains.

Le langage d'ontologie Web OWL est conçu pour décrire des classes et leurs relations, lesquelles sont inhérentes aux documents et applications Web.

Ce document démontre l'utilisation du langage OWL afin de :

  1. Formaliser un domaine en définissant des classes et propriétés de ces classes,
  2. Définir des individus et affirmer des propriétés les concernant et
  3. Raisonner sur ces classes et individus dans la mesure où le permet la sémantique formelle du langage OWL.

Les chapitres sont organisés afin de présenter une définition incrémentielle d'un ensemble de classes, propriétés et individus, en commençant par les fondamentaux puis en avançant vers des composants de langage plus complexes.

Statut de ce document

Ce document revu par les membres du W3C et des tiers intéressés a été approuvé par le Directeur comme recommandation du W3C. Le rôle du W3C en produisant la recommandation consiste à attirer l'attention sur la spécification et à en promouvoir un large déploiement. Cela contribue à améliorer la fonctionnalité et l'interopérabilité du Web.

Le document représente l'une des six parties composant la recommandation du W3C pour le langage d'ontologie Web OWL. Il a été développé par le groupe de travail Ontologie Web, rattaché à l'activité Web sémantique du W3C (cf. le rapport d'activité, et la charte du groupe) et publié le 10 février 2004.

Le concept de OWL exprimé dans les versions précédentes de ces documents a été largement revu et il satisfait aux impératifs techniques fixés par le groupe de travail. Celui-ci a pris en compte toutes les remarques reçues et effectué les changements nécessaires. Les modifications apportées au document depuis la version au stade recommandation proposée sont consignées dans le journal des changements.

Les remarques sont les bienvenues sur la liste de diffusion public-webont-comments@w3.org (cf. archives), les débats généraux sur les technologies apparentées se tenant sur www-rdf-logic@w3.org (cf. archives).

Une liste des mises en œuvre est disponible.

Le W3C tient une liste des éventuelles divulgations de brevets concernant ce travail.

Cette section décrit le statut de ce document au jour de sa publication. D'autres documents peuvent venir le remplacer. On trouvera une liste des publications actuelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Table des matières

1. Introduction

Dites-moi quels vins acheter pour accompagner chaque plat du menu suivant. Et, en passant, je n'aime pas le Sauternes !

À l'heure actuelle, il serait difficile de construire un agent Web capable de rechercher sur le Web les vins correspondant à cette requête. De même, imaginez que vous deviez réellement confier à un agent logiciel la tâche de préparer un itinéraire de voyage cohérent. (Pour d'autres scénarios, cf. le document des conditions requises pour OWL).

Pour réaliser ce type de calcul, il faut aller au-delà des mots-clés et définir la signification des ressources décrites sur le Web. Cette sur-couche d'interprétation saisit la sémantique des données.

Le langage d'ontologie Web OWL définit et instancie des ontologies Web. Le terme ontologie, emprunté à la philosophie, désigne la science décrivant les types d'entités dans le monde et la façon dont elles sont reliées. Une ontologie OWL peut contenir des descriptions de classes, de propriétés et de leurs instances. Pour une telle ontologie, la sémantique formelle OWL indique comment déduire ses conséquences logiques, c'est-à-dire les faits non pas littéralement présents dans l'ontologie mais qui découlent de la sémantique. Ces inférences peuvent être fondées sur un seul document ou sur plusieurs documents répartis combinés à l'aide de mécanismes OWL définis.

Ce document constitue un composant de la description du langage d'ontologie Web OWL produit par le groupe de travail Ontologie Web (WebOnt) du W3C. Le chapitre La cartographie du document de la vue d'ensemble ([Overview], 1.1) décrit chacune des différentes parties et leur classement.

Lorsqu'un nouveau standard XML/Web est décrit ressurgit la question suivante : Qu'est-ce que ça m'apporte et que XML et XML Schema ne peuvent pas ? Il y a deux réponses :

1.1. Les espèces de OWL

Le langage OWL offre trois sous-langages d'expression croissante conçus pour des communautés de développeurs et d'utilisateurs spécifiques.

Chaque sous-langage représente une extension par rapport à son prédécesseur plus simple, à la fois en ce qu'on peut légalement exprimer et en ce qu'on peut conclure de façon valide. Les relations suivantes sont vraies, pas leurs symétriques.

Les développeurs d'ontologies adoptant OWL devraient évaluer quel sous-langage convient le mieux à leurs besoins. Le choix entre OWL Lite et OWL DL dépendra de la mesure où les utilisateurs auront besoin des structures de restriction plus expressives de OWL DL. Les moteurs de raisonnement OWL Lite auront les propriétés de calcul souhaitables. Les moteurs de raisonnement OWL DL, tout en ayant un sous-langage décidable, seront soumis à une complexité dans l'éventualité du pire plus élevée. Le choix entre OWL DL et OWL Full dépendra principalement des besoins des utilisateurs en ce qui concerne les facilités de métamodélisation offertes par le schéma RDF (par exemple, pour définir des classes de classes). Entre une utilisation de OWL Full comparée à OWL DL, la prise en charge du raisonnement est moins prévisible. Pour des précisions sur cette question, cf. le document de la sémantique de OWL.

Les utilisateurs migrant de RDF vers OWL DL ou OWL Lite doivent s'assurer que le document original RDF satisfasse aux contraintes imposées par OWL DL et OWL Lite. Ces contraintes sont détaillées dans l'annexe E de la référence OWL.

Lorsque nous introduirons des structures seulement permises dans OWL DL ou OWL Full, nous les marqueront par [OWL DL].

1.2. La structure de ce document

Afin d'offrir un ensemble d'exemples cohérent tout au long de ce guide, nous avons créé une ontologie de vins et d'aliments. C'est une ontologie OWL DL. Certaines explications seront concentrées sur les capacités de OWL Full et elles seront signalées comme telles. L'ontologie de vins et d'aliments représente une modification importante d'un élément de la bibliothèque d'ontologies DAML qui a une longue histoire. Elle fut développée à l'origine par McGuinness comme exemple de logique de description dans le langage CLASSIC puis transformée en un tutoriel de la logique de description et enfin transformée en un tutoriel des ontologies.

Dans ce document, nous présenterons des exemples dans la syntaxe RDF/XML ([RDF], 5), en présupposant la familiarité du langage XML du plus grand nombre. La syntaxe d'échange OWL normative est RDF/XML. Remarquez que le langage OWL a été conçu pour une compatibilité maximale avec RDF et le schéma RDF. Ces formats XML et RDF font partie du standard OWL.

Tous les exemples présentés dans ce document proviennent des ontologies contenues dans les documents wine.rdf et food.rdf, sauf ceux signalés par un  ¬  (symbole non) au coin inférieur droit.

2. La structure des ontologies

Le langage OWL est un composant de l'activité Web Sémantique. Cet effort vise à rendre les ressources Web plus volontiers accessibles aux processus automatisés en ajoutant des informations sur les ressources qui décrivent ou fournissent un contenu Web. Comme le Web sémantique est fondamentalement réparti (ou distribué), le langage OWL doit permettre de réunir des informations en provenance de sources réparties. On y parvient en partie en permettant aux ontologies d'être reliées, y compris en important explicitement des informations d'autres ontologies.

En outre, le langage OWL présuppose un monde ouvert. C'est-à-dire que les descriptions de ressources ne se réduisent pas à un seul fichier ou à une seule influence. Bien que la définition originale d'une classe C1 puisse se trouver dans l'ontologie O1, on peut l'étendre dans d'autres ontologies. Les conséquences de ces propositions supplémentaires sur C1 sont monotoniques. Les nouvelles informations ne peuvent pas désavouer les précédentes. Elles peuvent être contradictoires mais les faits et les inférences peuvent seulement s'ajouter, et jamais s'annuler.

Le concepteur d'une ontologie doit tenir compte de la possibilité de telles contradictions. Les outils devraient pouvoir aider à détecter ces cas.

Pour écrire une ontologie interprétable sans ambiguïté et utilisable par des agents logiciels, nous avons besoin d'une syntaxe et d'une sémantique formelle pour OWL. OWL est une extension [RDF Semantics] du vocabulaire de RDF. La sémantique de OWL est définie dans le document La sémantique et la syntaxe abstraite du langage d'ontologie Web OWL.

2.1. Les espaces de nommage

Avant de pouvoir utiliser un ensemble de termes, nous devons avoir une indication précise des vocabulaires spécifiques utilisés. Le composant initial standard d'une ontologie comprend un ensemble de déclarations d'espace de nommage XML, contenues dans une balise ouvrante rdf:RDF. Ces déclarations permettent d'interpréter les identificateurs sans ambiguïté et de rendre la suite de la présentation de l'ontologie bien plus lisible. Une ontologie OWL typique commence par une déclaration d'espace de nommage semblable à la suivante. Bien sûr, les adresses URI des ontologies définies ne seront normalement pas des références w3.org.

<rdf:RDF 
    xmlns     ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" 
    xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"       
    xml:base  ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"       
    xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#"    
    xmlns:owl ="http://www.w3.org/2002/07/owl#"
    xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:xsd ="http://www.w3.org/2001/XMLSchema#"> 

Les deux premières déclarations identifient l'espace de nommage associé à cette ontologie. La première en fait l'espace de nommage par défaut, en déclarant que les noms qualifiés sans préfixe se rapportent à l'ontologie courante. La deuxième identifie l'espace de nommage de l'ontologie courante au préfixe vin:. La troisième identifie l'adresse URI de base de ce document (cf. ci-dessous). La quatrième identifie l'espace de nommage de l'ontologie d'appoint food au préfixe food:.

La cinquième déclaration établit que les éléments préfixés par owl: dans ce document doivent s'interpréter comme se référant à des objets issus de l'espace de nommage appelé http://www.w3.org/2002/07/owl#. C'est une déclaration OWL conventionnelle introduisant le vocabulaire OWL.

Le langage OWL dépend de structures définies par RDF, RDFS et les types de données du schéma XML. Dans ce document, le préfixe rdf: désigne des objets issus de l'espace de nommage appelé http://www.w3.org/1999/02/22-rdf-syntax-ns#. Les deux déclarations d'espace de nommage suivantes font la même chose en ce qui concerne les espaces de nommage du schéma RDF (rdfs:) et les types de données du schéma XML (xsd:).

Pour faciliter l'écriture des adresses URL, il est souvent plus pratique de fournir un ensemble de définitions d'entités dans une déclaration de type de document (DOCTYPE) précédant les définitions d'ontologies. Les noms définis par les déclarations d'espace de nommage n'ont de signification que pour les balises XML. Les valeurs d'attribut ne sont pas sensibles aux espaces de nommage. Dans OWL, on désigne pourtant fréquemment les identificateurs d'ontologies au moyen de valeurs d'attributs. On peut les écrire dans leur forme entièrement développée, par exemple http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot. Sinon on peut définir des abréviations en utilisant une définition d'entité, par exemple :

<!DOCTYPE rdf:RDF [
    <!ENTITY vin  "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" >
    <!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" > ]>

À la suite de cette paire de déclarations d'entités, nous pourrions écrire la valeur &vin;merlot, laquelle se développerait en http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot.

Le point le plus important peut-être : on peut alors simplifier les déclarations d'espaces de nommage rdf:RDF, de telle sorte que les changements faits dans les déclarations d'entités se propageront uniformément dans toute l'ontologie.

<rdf:RDF 
    xmlns     ="&vin;" 
    xmlns:vin ="&vin;" 
    xml:base  ="&vin;" 
    xmlns:food="&food;"
    xmlns:owl ="http://www.w3.org/2002/07/owl#"
    xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:xsd ="http://www.w3.org/2001/XMLSchema#"> 

2.2. Les en-têtes des ontologies

Une fois les espaces de nommage établis, on introduit normalement un ensemble d'assertions sur l'ontologie regroupées dans une balise owl:Ontology. Ces balises se chargent de tâches critiques communes comme les commentaires, le contrôle de version et l'inclusion d'autres ontologies.

<owl:Ontology rdf:about=""> 
  <rdfs:comment>Un exemple d'ontologie OWL</rdfs:comment>
  <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/PR-owl-guide-20031215/wine"/> 
  <owl:imports rdf:resource="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food"/> 
  <rdfs:label>Ontologie sur le vin</rdfs:label> 
  ...

Notez notre utilisation de ... pour signaler l'existence d'un texte non apparent pour les besoins de l'exemple.

L'élément owl:Ontology rassemble la plupart des métadonnées OWL du document. Il ne garantit pas que le document décrive une ontologie au sens traditionnel. Dans certaines communautés, les ontologies ne traitent pas d'individus mais seulement de classes et de propriétés définissant un domaine. Lorsqu'on emploie le langage OWL pour décrire un ensemble de données d'instance, la balise owl:Ontology peut être nécessaire pour enregistrer les informations de version et importer les définitions dont le document dépend. Ainsi, dans OWL, le terme ontologie a été élargi afin d'inclure les données d'instance (cf. précédemment).

L'attribut rdf:about fournit le nom ou une référence de l'ontologie. Lorsque sa valeur est "", le cas habituel, le nom de l'ontologie correspond à l'adresse URI de base de l'élément owl:Ontology. C'est normalement l'adresse URI du document contenant l'ontologie. Une exception serait un contexte présentant un attribut xml:base, lequel peut assigner à un élément une adresse URI de base différente de celle du document courant.

L'élément rdfs:comment fournit évidemment la capacité d'annotation nécessaire d'une ontologie.

L'élément standard owl:priorVersion fournit un connecteur pour les systèmes de contrôle de versions fonctionnant avec les ontologies. Le versionnage des ontologies est abordé plus loin en détails.

L'élément owl:imports fournit un mécanisme de type include. L'élément owl:imports admet un seul argument, identifié par l'attribut rdf:resource.

L'importation d'une autre ontologie reporte le jeu entier de ses assertions dans l'ontologie courante. Pour la bonne utilisation de cette ontologie importée, elle devrait normalement être coordonnée à une déclaration d'espace de nommage. Notez la distinction entre ces deux mécanismes. Les déclarations d'espace de nommage représentent un moyen commode d'appeler des noms définis dans d'autres ontologies OWL. Conceptuellement, on fournit l'élément owl:imports pour montrer son intention d'inclure les assertions de l'ontologie cible. Importer une autre ontologie O2 importera également toutes celles que O2 elle-même importe.

Remarquez que l'élément owl:imports ne réussira pas toujours. Comme on peut s'y attendre avec le Web sémantique, l'accès aux ressources réparties dans le Web n'est pas toujours possible. Les outils répondront à cette situation à leur façon.

Notez que pour utiliser le vocabulaire OWL il n'est pas nécessaire d'importer l'ontologie owl.rdf. En fait, cette importation n'est pas recommandée.

On pourrait raisonnablement inclure ici quelques balises de l'ensemble de métadonnées communes du Dublin Core. Ce sous-ensemble comprend les balises acceptant des types simples ou des chaînes comme valeurs. Par exemple, Title, Creator, Description, Publisher et Date (cf. les déclarations RDF).

Les propriétés utilisées comme annotations devraient être déclarées à l'aide de l'élément owl:AnnotationProperty. Par exemple :

<owl:AnnotationProperty rdf:about="&dc;creator" />

Le langage OWL offre plusieurs autres mécanismes pour assembler l'ontologie courante aux ontologies importées (cf. l'application des ontologies).

Nous ajoutons aussi un élément rdfs:label pour contenir une étiquette en langue naturel pour notre ontologie.

La définition de l'en-tête de l'ontologie s'achève par la balise suivante :

</owl:Ontology>

Ce prélude est suivi par les définitions effectives constituant l'ontologie, laquelle est finalement close par :

</rdf:RDF>

2.3. L'agrégation des données et la vie privée

La capacité de OWL d'exprimer des informations ontologiques à propos d'instances apparaissant dans plusieurs documents permet avec des principes de relier des données de sources diverses. La sémantique sous-jacente autorise à partir de ces données des inférences pouvant aboutir à des résultats inattendus. En particulier, la possibilité d'exprimer des équivalences avec l'élément owl:sameAs peut servir à déclarer des individus apparemment différents comme étant en réalité les mêmes. L'élément Owl:InverseFunctionalProperty peut également servir à relier des individus. Par exemple, si une propriété telle que NuméroDeSécuritéSociale est de type owl:InverseFunctionalProperty, on pourrait en conclure que deux individus séparés sont identiques, puisqu'ils auront la même valeur pour cette propriété. Si on détermine par ces moyens que des individus sont les mêmes, on peut rapprocher des informations les concernant issues de sources différentes. Cette agrégation peut servir à établir des faits non représentables directement par une seule source.

La capacité du Web sémantique à relier des informations provenant de plusieurs sources est une caractéristique souhaitable et puissante, qui peut être mise à profit dans beaucoup d'applications. Néanmoins, la capacité à réunir des données issues de plusieurs sources combinée au pouvoir de déduction de OWL peut entraîner des abus. Les utilisateurs de OWL devraient avoir conscience des implications potentielles pour la vie privée. Le groupe de travail n'a pas été jugé compétent pour préciser des mesures de sécurité. Quelques organisations abordent ces problèmes avec des solutions de sécurité et des approches différentes. Cf. par exemple SAML et P3P.

3. Les éléments de base

La plupart des éléments d'une ontologie OWL concerne des classes, des propriétés, des instances de classes et les relations entre ces instances. Ce chapitre présente les composants de langage essentiels pour introduire ces éléments.

3.1. Les classes simples et les individus

Dans beaucoup de cas, l'utilisation d'une ontologie dépendra de la capacité à raisonner sur les individus. Afin d'y parvenir utilement, il est nécessaire de disposer d'un mécanisme permettant de décrire les classes auxquelles les individus appartiennent et les propriétés dont ils héritent en vertu de l'appartenance à ces classes. On peut toujours affirmer des propriétés spécifiques à propos des individus, mais la grande force des ontologies tient au raisonnement basé sur des classes.

Nous mettrons parfois l'accent sur la distinction entre une classe en tant qu'objet et une classe en tant qu'ensemble d'éléments. On appellera l'ensemble des individus membres d'une classe l'extension de la classe.

3.1.1. Les classes nommées simples
Class, rdfs:subClassOf

Les concepts les plus élémentaires dans un domaine devraient correspondre aux classes racines des divers arbres taxonomiques. Chaque individu du monde OWL est membre de la classe owl:Thing. Chaque classe définie par l'utilisateur est donc implicitement une sous-classe de owl:Thing. On définit les classes racines spécifiques d'un domaine en déclarant simplement une classe nommée. Le langage OWL définit également une classe vide : owl:Nothing.

Pour notre domaine de vins en exemple, nous avons créé trois classes racines : Winery, Region et ConsumableThing.

<owl:Class rdf:ID="Winery"/> 
<owl:Class rdf:ID="Region"/> 
<owl:Class rdf:ID="ConsumableThing"/> 

Remarquez que l'on a seulement dit qu'il existait des classes ayant ces noms, ce qu'indique la syntaxe rdf:ID=. Formellement, on ne sait presque rien au sujet de ces classes si ce n'est qu'elles existent, hormis utiliser des termes familiers comme étiquettes. Et quoique les classes existent, elles peuvent n'avoir aucun membre. D'après ce que nous savons pour l'instant, nous aurions très bien pu appeler ces classes Thing1, Thing2 et Thing3.

Il faut se rappeler que les définitions peuvent être incrémentielles et réparties. En particulier, nous en dirons plus au sujet de Winery par la suite.

On utilise la syntaxe rdf:ID='Region' pour introduire un nom, comme partie de sa définition. Il s'agit de l'attribut rdf:ID ([RDF], 7.2.22), semblable à l'attribut ID familier défini par XML. On peut maintenant appeler la classe Region au sein du document par #Region, par exemple rdf:resource='#Region'. D'autres ontologies peuvent appeler ce nom par sa forme complète http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Region.

Une autre forme d'appel utilise la syntaxe rdf:about='#Region' afin d'étendre la définition d'une ressource. Cette utilisation de la syntaxe rdf:about='&ont;#x' revêt une importance critique pour la création d'une ontologie répartie. Elle permet d'étendre la définition de la classe x importée sans modifier le document original et permet la construction incrémentielle d'une ontologie plus vaste.

Il est maintenant possible d'appeler les classes que l'on a définies dans d'autres constructions OWL par l'identificateur donné. Pour la première classe au sein de ce document, on peut utiliser l'identificateur relatif #Winery. D'autres documents sont également susceptibles d'appeler cette classe. La façon la plus raisonnable de le faire est de fournir un espace de nommage et des définitions d'entités qui inclueront le document de définition comme source :

...
<!ENTITY vin  "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" >
<!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" >
...
<rdf:RDF xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
         xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" ... >
...

À partir de ces définitions, on peut appeler la classe Winery soit par le balisage XML vin:Winery, soit par la valeur d'attribut &vin;Winery. Littéralement, on peut toujours appeler une ressource par son adresse URI complète, ici http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Winery.

Le constructeur taxonomique fondamental des classes est la relation rdfs:subClassOf. Il relie une classe spécifique à une classe plus générale. Si X est une sous-classe de Y, alors chaque instance de X est également une instance de Y. La relation rdfs:subClassOf est transitive. Si X est une sous-classe de Y et Y une sous-classe de Z, alors X est une sous-classe de Z.

<owl:Class rdf:ID="PotableLiquid"> 
  <rdfs:subClassOf rdf:resource="#ConsumableThing" />
  ...
</owl:Class> 

On définit PotableLiquid, les liquides consommables, comme étant une sous-classe de ConsumableThing, les choses consommables.

Dans le monde des ontologies Web, on pourrait définir ces deux classes dans une ontologie séparée qui fournirait les blocs de construction élémentaires pour une large gamme d'ontologies d'aliments et de vins, et c'est ce que nous avons fait : elles sont définies dans l'ontologie food, laquelle est importée dans l'ontologie wine. L'ontologie d'aliments comprend un certain nombre de classes, par exemple Food, EdibleThing, MealCourse et Shellfish, qui n'ont rien à voir avec une collection de traits se rapportant au vin, mais qui doivent être associées au vocabulaire de wine si l'on doit faire des raisonnements utiles. Les ontologies d'aliments et de vins dépendent mutuellement l'une de l'autre afin de satisfaire à notre besoin d'identifier des correspondances vin/aliment.

Une définition de classe se compose de deux parties : une introduction (ou un appel) de nom et une liste de restrictions. Chaque expression contenue immédiatement dans la définition de classe restreint encore plus les instances de la classe définie. Les instances de la classe appartiennent à l'ensemble d'intersection des restrictions. (Cf. le détail de la relation owl:equivalentClass). Nous avons vu jusqu'ici des exemples contenant une seule restriction, forçant la nouvelle classe à être une sous-classe d'une autre classe nommée.

À ce stade, il est possible de créer une définition simple (et incomplète) de la classe Wine, laquelle est aussi de la classe PotableLiquid. On définit également la classe Pasta comme étant de la classe EdibleThing.

<owl:Class rdf:ID="Wine"> 
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> 
  <rdfs:label xml:lang="en">wine</rdfs:label> 
  <rdfs:label xml:lang="fr">vin</rdfs:label> 
  ...  
</owl:Class> 

<owl:Class rdf:ID="Pasta">
  <rdfs:subClassOf rdf:resource="#EdibleThing" />
  ...
</owl:Class>

L'élément rdfs:label donne à cette classe un nom optionnel lisible par un humain. Les outils de présentation peuvent s'en servir. L'attribut lang permet de gérer plusieurs langues. Une étiquette est comme un commentaire et ne contribue en rien à l'interprétation logique d'une ontologie.

Notre définition de vins est encore très incomplète. Nous ne savons rien à propos des vins, sauf que ce sont des choses et des liquides consommables, mais nous disposons de suffisamment de renseignements pour créer des individus et raisonner sur eux.

3.1.2. Les individus

Outre les classes, on veut pouvoir décrire leurs membres. On pense habituellement à eux comme à des individus dans notre univers de choses. Il suffit de déclarer un individu comme membre d'une classe pour l'introduire.

<Region rdf:ID="CentralCoastRegion" /> 

Remarquez que l'exemple suivant est identique au précédent du point de vue de la signification.

<owl:Thing rdf:ID="CentralCoastRegion" /> 

<owl:Thing rdf:about="#CentralCoastRegion"> 
   <rdf:type rdf:resource="#Region"/> 
</owl:Thing>

L'élément rdf:type est une propriété RDF liant un individu à une classe dont il est membre.

Il faut signaler les points suivants ici. Premièrement, on a décidé que CentralCoastRegion (une aire particulière) est membre de Region, la classe contenant toutes les régions géographiques. Deuxièmement, dans l'exemple en deux parties précédent, les deux éléments ne doivent pas forcément être adjacents l'un par rapport à l'autre, ou même se trouver dans le même fichier (auquel cas, il faudrait étendre les noms par une adresse URI). Les ontologies Web sont conçues pour être réparties. On peut les importer et les étendre, et créer ainsi des ontologies dérivées.

Afin de disposer de quelques classes supplémentaires pour les propriétés à introduire dans les chapitres suivants, nous définissons une branche de la taxonomie Grape, c'est-à-dire avec un individu représentant la variété de raisin (ou cépage) Cabernet Sauvignon. Les raisins sont définis dans l'ontologie d'aliments :

<owl:Class rdf:ID="Grape">
  ...
</owl:Class>

Dans l'ontologie de vins, on a ensuite :

<owl:Class rdf:ID="WineGrape">
  <rdfs:subClassOf rdf:resource="&food;Grape" />
</owl:Class>

<WineGrape rdf:ID="CabernetSauvignonGrape" />

Comme expliqué dans le chapitre suivant, CabernetSauvignonGrape est un individu car il désigne un seul cépage.

3.1.3. Une conception pour une utilisation

La distinction dans OWL entre une classe et un individu soulève des questions importantes. Une classe est simplement un nom et une collection de propriétés décrivant un ensemble d'individus. Les individus sont les membres de cet ensemble. Ainsi, les classes devraient correspondre aux ensembles d'éléments qui apparaissent naturellement dans un domaine de discours, et les individus aux entités réelles qui peuvent être regroupées dans ces classes.

Dans la construction des ontologies, cette distinction devient souvent floue pour deux raisons :

Remarquez que la même distinction surgit pour le traitement de la classe Wine. La classe Wine représente en réalité l'ensemble de toutes les variétés de vin (ou appellations), et non l'ensemble des bouteilles réelles qu'une personne achète. Dans une ontologie de remplacement, chaque instance de la classe Wine de l'ontologie courante pourrait à la place désigner la classe constituée de toutes les bouteilles de vin de ce type. Il est facile d'imaginer un système d'information, comme le système d'inventaire d'un marchand de vin, qui doive tenir compte de chaque bouteille de vin individuellement. Dans son état actuel, l'ontologie de vins nécessiterait de pouvoir traiter les classes comme étant des instances pour mettre en œuvre une telle interprétation. Remarquez que le langage OWL Full autorise ce niveau d'expression, en permettant de traiter simultanément une instance de cépage comme étant une classe dont les instances sont des bouteilles de vin.

Dans le même ordre d'idée, les vins produits par une cave vinicole (N.d.T. winery) au cours d'années spécifiques sont également des millésimes (N.d.T. vintages). Pour traduire la notion de millésime, il faut déterminer où la placer dans l'ontologie courante. Une instance de la classe Wine, comme expliqué précédemment, représente un seul cépage produit par une seule cave vinicole, par exemple FormanChardonnay (un Chardonnay de chez Forman).

Ajouter que le vin produit au cours de l'année 2000 est un millésime constitue un défi car on n'a aucun moyen de représenter un sous-ensemble d'un vin individuel donné. Ce millésime n'est pas une nouvelle appellation, c'est un sous-ensemble particulier du vin, produit en 2000. Une option consisterait à employer le langage OWL Full et à traiter les instances de vin comme des classes ayant des sous-classes (sous-ensembles) désignant des millésimes. Une solution de rechange consiste à considérer Vintage comme une classe séparée dont les instances ont une relation avec le vin (Wine) dont c'est un millésime. Par exemple, l'entrée FormanChardonnay2000 est une instance individuelle de la classe Vintage avec une propriété vintageOf dont la valeur est le vin (Wine) FormanChardonnay. La définition de la classe Vintage suit.

Le but de cette discussion est de faire remarquer que le développement d'une ontologie devrait absolument avoir lieu en fonction de l'utilisation qui en est prévue. Ces questions sous-tendent également une différence majeure entre les langages OWL Full et OWL DL. Le langage OWL Full permet d'utiliser des classes comme instances, pas OWL DL. L'ontologie de vins est conçue pour fonctionner dans OWL DL, par conséquent, les individus comme FormanChardonnay ne sont pas traités simultanément comme des classes.

3.2. Les propriétés simples

Ce monde de classes et d'individus seraient très ennuyeux si on pouvait seulement y définir des taxonomies. Les propriétés nous permettent d'affirmer des faits généraux sur les membres des classes et des faits particuliers sur les individus.

3.2.1. La définition des propriétés
ObjectProperty, DatatypeProperty, rdfs:subPropertyOf,
rdfs:domain, rdfs:range

Une propriété est une relation binaire. On distingue deux types de propriété :

Lorsqu'on définit une propriété, il existe plusieurs façons de restreindre la relation. On peut définir un domaine et une image. On peut définir la propriété comme une spécialisation (sous-propriété) d'une propriété existante. Des restrictions plus élaborées sont possibles, et on les décrira plus tard.

<owl:ObjectProperty rdf:ID="madeFromGrape"> 
  <rdfs:domain rdf:resource="#Wine"/>
  <rdfs:range rdf:resource="#WineGrape"/> 
</owl:ObjectProperty> 

<owl:ObjectProperty rdf:ID="course">
  <rdfs:domain rdf:resource="#Meal" />
  <rdfs:range rdf:resource="#MealCourse" />
</owl:ObjectProperty>

Dans OWL, une séquence d'éléments sans opérateur explicite représente une conjonction implicite. La propriété madeFromGrape a pour domaine la classe Wine et pour image la classe WineGrape. C'est-à-dire qu'elle relie des instances de la classe Wine à des instances de la classe WineGrape. Plusieurs domaines signifient que le domaine de la propriété est constitué par l'intersection des classes identifiées (idem pour les images).

De même, la propriété course relie une instance de Meal à une instance de MealCourse.

Remarquez que l'utilisation des informations d'image et de domaine dans OWL diffère de l'utilisation des informations de type dans un langage de programmation. Entre autres choses, les types servent à vérifier la cohérence dans le langage de programmation. Dans OWL, on peut utiliser une image pour inférer un type. Soit, par exemple :

<owl:Thing rdf:ID="LindemansBin65Chardonnay">
  <madeFromGrape rdf:resource="#ChardonnayGrape" />
</owl:Thing>                                              ¬ 

On peut déduire que LindemansBin65Chardonnay est un vin parce que le domaine de la propriété madeFromGrape est la classe Wine.

Les propriétés tout comme les classes peuvent être arrangées en une hiérarchie.

<owl:Class rdf:ID="WineDescriptor" />

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor" />
  ...
</owl:Class>

<owl:ObjectProperty rdf:ID="hasWineDescriptor">
  <rdfs:domain rdf:resource="#Wine" />
  <rdfs:range  rdf:resource="#WineDescriptor" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasColor">
  <rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" />
  <rdfs:range rdf:resource="#WineColor" />
  ...
</owl:ObjectProperty>

Les propriétés de la classe WineDescriptor relient les vins à leur couleur et aux composants de leur goût, comprenant le degré, le corps et l'arôme. La propriété hasColor est une sous-propriété de hasWineDescriptor, dont l'image est en outre restreinte à la classe WineColor. La relation rdfs:subPropertyOf signifie ici que tout ce qui a une propriété hasColor dont la valeur est X a aussi une propriété hasWineDescriptor de valeur X.

On introduit ensuite la propriété locatedIn reliant les objets aux régions où on les trouvent.

<owl:ObjectProperty rdf:ID="locatedIn">
  ...
  <rdfs:domain rdf:resource="http://www.w3.org/2002/07/owl#Thing" />
  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

Notez la façon de définir le domaine et l'image de la propriété locatedIn. Le domaine admet n'importe quel objet dans une région, y compris les régions elles-mêmes. Et la composition transitive de cette relation crée essentiellement un maillage géographique de sous-régions et d'objets. Les objets sans contenu peuvent appartenir à n'importe quelle classe, tandis que ceux contenant d'autres objets sont obligatoirement des régions.

Il est maintenant possible d'étendre la définition de la classe Wine afin d'y inclure la notion selon laquelle un vin est produit avec au moins un cépage (WineGrape). Comme pour les définitions de propriétés, les définitions de classes se composent de plusieurs sous-parties implicitement conjointes.

<owl:Class rdf:ID="Wine"> 
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> 
  <rdfs:subClassOf>
    <owl:Restriction> 
      <owl:onProperty rdf:resource="#madeFromGrape"/>
      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction> 
  </rdfs:subClassOf>
  ...  
</owl:Class>

Soit la sous-classe de restriction mise en exergue précédemment :

    <owl:Restriction> 
      <owl:onProperty rdf:resource="#madeFromGrape"/>
      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction> 

Elle définit une classe sans nom représentant l'ensemble des objets avec au moins une propriété madeFromGrape. On les appelle des classes anonymes. L'introduction de cette restriction dans la définition du corps de la classe Wine de déclare que les objets qui sont des vins sont aussi membres de cette classe anonyme. C'est-à-dire que chaque vin individuel doit participer à au moins une relation madeFromGrape.

On peut maintenant décrire la classe des millésimes (Vintage), abordée précédemment.

<owl:Class rdf:ID="Vintage"> 
  <rdfs:subClassOf>
    <owl:Restriction> 
      <owl:onProperty rdf:resource="#vintageOf"/>
      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>                                              ¬ 

La propriété vintageOf lie une instance de Vintage à une instance de Wine.

<owl:ObjectProperty rdf:ID="vintageOf">
  <rdfs:domain rdf:resource="#Vintage" />
  <rdfs:range  rdf:resource="#Wine" />
</owl:ObjectProperty>                                     ¬ 

On reliera les millésimes (Vintage) à leurs années dans la section suivante.

3.2.2. Les propriétés et les types de données

On distingue les propriétés selon qu'elles relient des individus à des individus (propriétés d'objets) ou des individus à des types de données (propriétés de types de données). Les propriétés de types de données recouvrent des littéraux RDF ou des types simples définis conformément aux types de données du schéma XML.

Le langage OWL utilise la plupart des types de données intégrés du schéma XML. Les appels de ces types de données se font au travers de la référence d'adresse URI du type de donnée http://www.w3.org/2001/XMLSchema. L'utilisation des types de données suivants est recommandée avec OWL :

xsd:stringxsd:normalizedStringxsd:boolean
xsd:decimalxsd:floatxsd:double
xsd:integerxsd:nonNegativeIntegerxsd:positiveInteger
xsd:nonPositiveIntegerxsd:negativeInteger
xsd:longxsd:intxsd:shortxsd:byte
xsd:unsignedLongxsd:unsignedIntxsd:unsignedShortxsd:unsignedByte
xsd:hexBinaryxsd:base64Binary
xsd:dateTimexsd:timexsd:datexsd:gYearMonth
xsd:gYearxsd:gMonthDayxsd:gDayxsd:gMonth
xsd:anyURIxsd:tokenxsd:language
xsd:NMTOKENxsd:Namexsd:NCName

Les types de données précédents plus le type rdfs:Literal constituent les types de données intégrés du langage OWL. Tous les moteurs de raisonnement OWL doivent obligatoirement reconnaître les types de données xsd:integer et xsd:string.

On peut utiliser les autres types de données intégrés du schéma XML avec le langage OWL Full, toutefois en tenant compte des mises en garde décrites dans la documentation de La sémantique et la syntaxe abstraite du langage d'ontologie Web OWL.

<owl:Class rdf:ID="VintageYear" />

<owl:DatatypeProperty rdf:ID="yearValue">
  <rdfs:domain rdf:resource="#VintageYear" />    
  <rdfs:range  rdf:resource="&xsd;positiveInteger"/>
</owl:DatatypeProperty> 

La propriété yearValue relie les éléments de la classe VintageYear à des valeurs entières positives. On introduira plus loin la propriété hasVintageYear qui relie une instance de Vintage à une instance de VintageYear.

Le document La référence du langage d'ontologie Web OWL ([Reference], 6.2) décrit l'utilisation de la propriété owl:oneOf, et de rdf:List et rdf:rest pour définir un type de donnée énuméré. Un exemple y montre la façon de construire la propriété tennisGameScore de type owl:DatatypeProperty dont l'image est l'ensemble des éléments de la liste de valeurs entières {0, 15, 30, 40}.

3.2.3. Les propriétés des individus

Nous décrivons d'abord les individus des classes Region et Winery puis nous définissons notre premier vin, un Cabernet Sauvignon.

<Region rdf:ID="SantaCruzMountainsRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />
</Region>

<Winery rdf:ID="SantaCruzMountainVineyard" />

<CabernetSauvignon
  rdf:ID="SantaCruzMountainVineyardCabernetSauvignon" >
  <locatedIn   rdf:resource="#SantaCruzMountainsRegion"/>  
  <hasMaker    rdf:resource="#SantaCruzMountainVineyard" />   
</CabernetSauvignon>

La définition est toujours incomplète. D'autres aspects concernant les arômes du vin sont définis dans l'ontologie complète. Toutefois, les pièces finissent par s'ajuster. On pourrait commencer à raisonner sur les éléments du menu de notre ontologie d'aliments que ce vin pourra accompagner. Nous savons d'après la définition précédente que le vignoble de Santa Cruz Mountain convient. Comme c'est un Cabernet Sauvignon (cf. wine.rdf), nous savons qu'il s'agit d'un vin rouge sec.

On peut ajouter des propriétés de types de données aux individus de la même façon. Nous décrivons ci-dessous une instance de la classe VintageYear et nous la lions à une valeur spécifique de type &xsd:positiveInteger.

<VintageYear rdf:ID="Year1998">
  <yearValue rdf:datatype="&xsd;positiveInteger">1998</yearValue>
</VintageYear> 

3.3. Les caractéristiques de propriété

Les chapitres suivants décrivent les mécanismes utilisables pour définir des propriétés supplémentaires. Il est possible d'ajouter des caractéristiques de propriété, qui fournissent un mécanisme puissant pour améliorer le raisonnement sur la propriété en question.

3.3.1. TransitiveProperty

Si on définit une propriété P comme transitive, alors pour tout x, y, z :

P(x,y) et P(y,z) implique P(x,z)

La propriété locatedIn (est située dans) est transitive :

<owl:ObjectProperty rdf:ID="locatedIn">
  <rdf:type rdf:resource="&owl;TransitiveProperty" />
  <rdfs:domain rdf:resource="&owl;Thing" />
  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

<Region rdf:ID="SantaCruzMountainsRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />
</Region>

<Region rdf:ID="CaliforniaRegion">
  <locatedIn rdf:resource="#USRegion" />
</Region>

Comme la région SantaCruzMountainsRegion est située dans la région CaliforniaRegion, alors elle doit aussi être située dans USRegion, puisque la propriété locatedIn est transitive.

3.3.2. SymmetricProperty

Si une propriété P est symétrique, alors pour tout x, y :

P(x,y) iff P(y,x)

La propriété adjacentRegion est marquée comme symétrique, tandis que locatedIn ne l'est pas. Plus précisément, la propriété locatedIn n'est pas prévue pour être symétrique. Rien dans l'ontologie de vins ne l'empêche d'être symétrique pour le moment.

<owl:ObjectProperty rdf:ID="adjacentRegion">
  <rdf:type rdf:resource="&owl;SymmetricProperty" />
  <rdfs:domain rdf:resource="#Region" />
  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

<Region rdf:ID="MendocinoRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />
  <adjacentRegion rdf:resource="#SonomaRegion" />
</Region>

La région MendocinoRegion est adjacente à la région SonomaRegion, et vice versa. La région MendocinoRegion est située dans la région CaliforniaRegion, l'inverse n'est pas vrai.

3.3.3. FunctionalProperty

Si une propriété P est marquée comme fonctionnelle, alors pour tout x, y, z :

P(x,y) et P(x,z) implique y = z 

Dans notre ontologie de vins, la propriété hasVintageYear est fonctionnelle. Un vin est d'un millésime unique. C'est-à-dire, on ne peut associer un individu Vintage donné qu'à une seule année au travers de la propriété hasVintageYear. Il n'est pas obligatoire pour un type owl:FunctionalProperty que tous les éléments du domaine aient une valeur. Cf. la discussion sur la cardinalité de la classe Vintage.

<owl:Class rdf:ID="VintageYear" />

<owl:ObjectProperty rdf:ID="hasVintageYear">
  <rdf:type rdf:resource="&owl;FunctionalProperty" />
  <rdfs:domain rdf:resource="#Vintage" />
  <rdfs:range  rdf:resource="#VintageYear" />
</owl:ObjectProperty>

3.3.4. inverseOf

Si une propriété P1 est marquée comme étant l'inverse de P2, alors pour tout x, y :

P1(x,y) iff P2(y,x)

Remarquez que la syntaxe de la propriété owl:inverseOf impose un nom de propriété comme argument. La notation A iff B signifie que (A implique B) et (B implique A).

<owl:ObjectProperty rdf:ID="hasMaker">
  <rdf:type rdf:resource="&owl;FunctionalProperty" />
</owl:ObjectProperty>
  
<owl:ObjectProperty rdf:ID="producesWine">
  <owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>

Les vins de la classe Wine ont des producteurs, qui se limitent aux caves vinicoles de la classe Winery dans la définition de la classe Wine. Puis chaque cave vinicole Winery produit un ensemble de vins l'identifiant comme producteur.

3.3.5. InverseFunctionalProperty

Si une propriété P est marquée comme fonctionnelle symétrique, alors pour tout x, y, z :

P(y,x) et P(z,x) implique y = z

Notez que la propriété producesWine précédente est fonctionnelle symétrique. Cela est justifié par le fait que la fonction symétrique d'une propriété fonctionnelle est obligatoirement fonctionnelle symétrique. On aurait pu définir les propriétés hasMaker et producesWine comme suit et obtenir un résultat identique à l'exemple précédent :

<owl:ObjectProperty rdf:ID="hasMaker" />
  
<owl:ObjectProperty rdf:ID="producesWine">
  <rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
  <owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>                                     ¬ 

Il faut voir les éléments de l'image d'une propriété fonctionnelle symétrique comme définissant une clé unique au sens d'une base de données. Le type owl:InverseFunctional implique que les éléments de l'image fournissent un identificateur unique pour chaque élément du domaine.

Dans le langage OWL Full, on peut étiqueter une propriété de type DatatypeProperty comme étant fonctionnelle symétrique. Cela permet d'identifier une chaîne comme clé unique. Dans le langage OWL DL, les littéraux sont disjoints par rapport à la classe owl:Thing, et c'est la raison pour laquelle OWL DL ne permet pas l'application du type InverseFunctional aux propriétés de type DatatypeProperty.

3.4. Les restrictions de propriété

Outre indiquer des caractéristiques de propriété, il est possible de contraindre de plusieurs façons l'image d'une propriété en fonction de contextes particuliers. Nous le faisons avec des restrictions de propriété. On ne peut employer les diverses formes décrites ci-dessous que dans le contexte d'un élément owl:Restriction. L'élément owl:onProperty désigne la propriété restreinte.

3.4.1. allValuesFrom, someValuesFrom

Nous avons déjà étudié une façon de restreindre les types des éléments composant une propriété. Jusqu'à présent, les mécanismes étaient globaux et agissaient sur toutes les instances de la propriété. Au contraire, les deux restrictions allValuesFrom et someValuesFrom sont locales et ne concernent que la définition de la classe qui les contient.

La restriction owl:allValuesFrom impose, pour chaque instance de la classe ayant des instances de la propriété indiquée, que les valeurs de la propriété soient toutes membres de la classe désignée par la clause owl:allValuesFrom.

<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
  ...
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasMaker" />
      <owl:allValuesFrom rdf:resource="#Winery" />
    </owl:Restriction>
  </rdfs:subClassOf>
  ...
</owl:Class>

Un producteur de vin de la classe Wine doit être une cave vinicole de la classe Winery. La restriction allValuesFrom se trouve sur la propriété hasMaker de cette seule classe Wine. Les producteurs de la classe Cheese ne sont pas concernés par cette restriction locale.

La restriction owl:someValuesFrom est similaire. Si on remplace la restriction owl:allValuesFrom par owl:someValuesFrom dans l'exemple précédent, alors au moins une des propriétés hasMaker d'une classe Wine doit pointer vers un individu de la classe Winery.

<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasMaker" />
      <owl:someValuesFrom rdf:resource="#Winery" />
    </owl:Restriction>
  </rdfs:subClassOf>
  ...
</owl:Class>                                             ¬ 

La différence entre les deux formulations est celle existant entre une quantification universelle et une quantification existentielle.

RelationImplications
allValuesFromPour tous les vins, s'ils ont des producteurs, tous les producteurs sont des caves vinicoles.
someValuesFromPour tous les vins, ils ont au moins un producteur qui est une cave vinicole.

La première relation n'impose pas qu'un vin ait un producteur. Si ce vin a un ou plusieurs producteurs, alors tous sont des caves vinicoles. La seconde impose qu'au moins un producteur soit une cave vinicole, mais il peut exister des producteurs qui ne soient pas des caves vinicoles.

3.4.2. La cardinalité

Nous avons déjà vu des exemples de contraintes de cardinalité. Jusqu'à présent, il s'agissait d'assertions à propos d'une cardinalité minimale. Plus simple encore, il y a la restriction owl:cardinality, laquelle permet d'indiquer exactement le nombre d'éléments dans une relation. Par exemple, on définit la classe Vintage comme ayant exactement un seul individu VintageYear.

<owl:Class rdf:ID="Vintage"> 
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasVintageYear"/>  
      <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

On définit la propriété hasVintageYear comme étant fonctionnelle, ce qui revient à dire que chaque millésime (Vintage) est associé à une année (VintageYear) au plus. L'application de cette propriété sur Vintage avec la restriction de cardinalité affirme quelque chose de plus fort, que chaque millésime Vintage a exactement une année VintageYear.

Les expressions de cardinalité ayant des valeurs limitées à 0 ou 1 font partie du langage OWL Lite. Elles permettent à l'utilisateur de signifier au moins un, pas plus d'un et exactement un. Le langage OWL DL admet d'autres valeurs entières positives en plus de 0 et 1. L'élément owl:maxCardinality peut servir à fixer une borne supérieure et l'élément owl:minCardinality à fixer une borne inférieure. On peut utiliser les deux en combinaison pour limiter la cardinalité de la propriété à un intervalle numérique.

3.4.3. hasValue [OWL DL]

La restriction hasValue permet de définir des classes selon l'existence de valeurs de propriétés particulières. Ainsi, un individu sera membre d'une telle classe à condition qu'au moins une des valeurs de la propriété en question soit égale à la ressource hasValue.

<owl:Class rdf:ID="Burgundy">
  ...
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasSugar" />
      <owl:hasValue rdf:resource="#Dry" />
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

Dans cette partie, on déclare que tous les vins de la classe Burgundy sont des vins secs. C'est-à-dire que leur propriété hasSugar doit avoir au moins une valeur égale à Dry.

Comme allValuesFrom et someValuesFrom, il s'agit d'une restriction locale. Elle se vérifie lorsque la propriété hasSugar est appliquée aux vins de la classe Burgundy.

4. L'application des ontologies

Pour un impact maximal, les ontologies doivent être largement partagées. Pour réduire les investissements intellectuels nécessités par le développement des ontologies, il faut pouvoir les réutiliser. Dans le meilleur des mondes possible, il faudrait les composer. Par exemple, on pourrait adopter une ontologie de dates provenant d'une source et une ontologie d'emplacements physiques prise ailleurs puis on étendrait la notion d'emplacement pour inclure l'intervalle de temps au cours duquel cet emplacement est valide.

Il faut comprendre que l'essentiel de l'effort consacré au développement d'une ontologie consiste à associer les classes et les propriétés pour en maximiser les implications. On veut que les assertions simples pour l'appartenance à une classe aient des implications étendues et utiles. C'est la partie la plus difficile du développement d'une ontologie. Si on peut trouver une ontologie déjà soumise à des tests et des ajustements complets, il est raisonnable de l'adopter.

Réaliser un assemblage d'ontologies restera un défi. Il faudra presque toujours faire appel à un outil pour conserver une cohérence.

4.1. L'équivalence entre les classes et les propriétés
equivalentClass, equivalentProperty

Pour lier un ensemble d'ontologies composantes comme partie d'une troisième, il se révèle souvent utile de pouvoir indiquer qu'une classe (ou une propriété) particulière dans une ontologie est équivalente à une classe (ou une propriété) dans une autre. L'utilisation de cette possibilité demande des précautions. Si les ontologies combinées sont contradictoires (tous les A sont des B opposé à tous les A ne sont pas des B), alors aucune extension (pas d'individu ni de relation) ne satisfera à la combinaison résultante.

Dans l'ontologie d'aliments, nous voulons relier les caractères des vins dans les descriptions de plats composant le repas à l'ontologie de vins. Un façon d'y parvenir consiste à définir une classe dans l'ontologie d'aliments (&food;Wine) et à la déclarer ensuite équivalente à une classe de vin existant dans l'ontologie de vins.

<owl:Class rdf:ID="Wine">
  <owl:equivalentClass rdf:resource="&vin;Wine"/>
</owl:Class>

La propriété owl:equivalentClass sert à indiquer que deux classes ont précisément les mêmes instances. Remarquez que dans OWL DL les classes représentent simplement des ensembles d'individus et qu'elles ne sont pas elles-mêmes des individus. Par contre, dans OWL Full, on peut employer la propriété owl:sameAs entre deux classes pour indiquer qu'elles sont identiques en tous points.

Bien sûr, l'exemple précédent est quelque peu forcé, dans la mesure où nous pouvons toujours utiliser &vin;Wine partout où nous aurions pu utiliser #Wine, et nous aurions obtenu le même résultat sans redéfinition. Cette utilisation aurait été plus probable au cas où nous aurions dépendu de deux ontologies développées indépendamment et remarqué qu'elles utilisaient les adresse URI O1:foo et O2:bar pour appeler la même classe. Nous aurions alors pu employer la propriété owl:equivalentClass pour fusionner ces classes afin de combiner les déductions des deux ontologies.

Nous avons déjà vu des expressions de classe qui pouvaient être les cibles de constructeurs rdfs:subClassOf. Elles peuvent également être les cibles d'une propriété owl:equivalentClass. Encore une fois, cela évite d'avoir à forcer les noms de chaque expression de classe et fournit une capacité de définition puissante fondée sur la satisfaction d'une propriété.

<owl:Class rdf:ID="TexasThings"> 
  <owl:equivalentClass>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#locatedIn" />
      <owl:someValuesFrom rdf:resource="#TexasRegion" />
    </owl:Restriction>
  </owl:equivalentClass>
</owl:Class>                                                ¬ 

La classe TexasThings représente exactement ces objets situées dans la région TexasRegion. Ici la différence entre l'utilisation des propriétés owl:equivalentClass et rdfs:subClassOf est celle qui existe entre une condition nécessaire et une condition nécessaire et suffisante. Avec la propriété subClassOf, les objets situés au Texas ne sont pas nécessairement des objets de la classe TexasThings. Par contre, en utilisant owl:equivalentClass, si un objet est situé au Texas, alors il doit appartenir à la classe TexasThings.

RelationImplications
subClassOfTexasThings(x) implique locatedIn(x,y) et TexasRegion(y)
equivalentClass  TexasThings(x) implique locatedIn(x,y) et TexasRegion(y)
locatedIn(x,y) et TexasRegion(y) implique TexasThings(x)

De la même façon, nous utilisons owl:equivalentProperty pour lier des propriétés.

4.2. L'identité entre individus
sameAs

Ce mécanisme est similaire à celui pour les classes, mais déclare deux individus identiques. Voici un exemple :

<Wine rdf:ID="MikesFavoriteWine"> 
  <owl:sameAs rdf:resource="#StGenevieveTexasWhite" /> 
</Wine>                                                  ¬ 

Ce n'est pas d'une grande utilité. Tout ce qu'on en retire c'est que Mike aime un vin de pays pas cher. Une utilisation typique de la relation sameAs aurait été d'associer des individus définis dans des documents différents à un autre individu, dans l'unification de deux ontologies.

Ce qui soulève un point important. Le langage OWL ne fait pas de présomption d'unicité des noms. Que deux noms soient juste différents ne signifie pas qu'ils se rapportent à des individus qui le sont.

Dans l'exemple précédent, nous avons affirmé une identité entre deux noms distincts. Mais ce type d'identité peut tout aussi bien se déduire. Rappelez-vous les implications dérivées d'une propriété fonctionnelle. Soit la propriété fonctionnelle hasMaker, il n'y a pas forcément conflit dans ce qui suit :

<owl:Thing rdf:about="#BancroftChardonnay">
  <hasMaker rdf:resource="#Bancroft" />
  <hasMaker rdf:resource="#Beringer" />
</owl:Thing>                                             ¬ 

Sauf à contredire d'autres informations dans notre ontologie, cela signifie simplement que Bancroft = Beringer.

Remarquez que l'utilisation de la relation sameAs pour associer deux classes n'est pas la même chose que les associer avec equivalentClass : cela conduit plutôt à interpréter les classes comme des individus et suffit donc à catégoriser une ontologie comme de type OWL Full. Dans OWL Full, la relation sameAs peut servir à associer n'importe quoi, une classe et un individu, une propriété et une classe, etc. et ses deux arguments s'interprètent alors comme des individus.

4.3. Les individus différents
differentFrom, AllDifferent

Ce mécanisme a l'effet opposé de celui de la relation sameAs.

<WineSugar rdf:ID="Dry" />

<WineSugar rdf:ID="Sweet">  
  <owl:differentFrom rdf:resource="#Dry"/>  
</WineSugar> 

<WineSugar rdf:ID="OffDry">
  <owl:differentFrom rdf:resource="#Dry"/> 
  <owl:differentFrom rdf:resource="#Sweet"/> 
</WineSugar>

C'est un moyen d'affirmer que ces trois valeurs sont mutuellement distinctes. Il sera parfois important de s'assurer que des identités sont distinctes. Sans ces assertions, nous pourrions décrire un vin à la fois sec (Dry) et doux (Sweet). Nous avons déclaré que la propriété hasSugar appliquée à un vin n'a pas plus d'une valeur. Si nous nous étions trompé en affirmant qu'un vin était en même temps Dry et Sweet, sans les éléments differentFrom précédents, cela impliquerait que Dry et Sweet sont identiques. Avec ces éléments, nous aurions eu une contradiction à la place.

Il existe un mécanisme plus pratique pour définir un ensemble d'individus mutuellement distincts. Ce qui suit fait valoir que Red, White et Rose sont distincts deux à deux.

<owl:AllDifferent>
  <owl:distinctMembers rdf:parseType="Collection">
    <vin:WineColor rdf:about="#Red" />
    <vin:WineColor rdf:about="#White" />
    <vin:WineColor rdf:about="#Rose" />
  </owl:distinctMembers>
</owl:AllDifferent>

Remarquez qu'on ne peut utiliser l'élément owl:distinctMembers qu'en combinaison avec la relation owl:AllDifferent.

Dans l'ontologie de vins, nous associons une assertion owl:AllDifferent à tous les membres de la classe WineDescriptor. Nous déclarons aussi que les caves vinicoles (Winery) sont toutes différentes. Si nous avions voulu ajouter une nouvelle cave vinicole à une autre ontologie, en faisant valoir que cette cave vinicole était disjointe par rapport à toutes celles déjà définies, il aurait fallu faire un copier-coller de l'assertion owl:AllDifferent originale et ajouter ce nouveau producteur à la liste. Il n'existe pas de moyen plus simble d'étendre un ensemble owl:AllDifferent dans le langage OWL DL. Avec OWL Full, d'autres approches sont possibles en utilisant des triplets RDF et des structures rdf:List.

5. Les classes complexes [OWL DL]

Le langage OWL offre d'autres constructeurs pour former des classes. Ces constructeurs peuvent servir à créer ce que l'on appelle des expressions de classes. Le langage OWL reconnaît les opérations élémentaires sur les ensembles, à savoir l'union, l'intersection et la complémentarité, nommées respectivement owl:unionOf, owl:intersectionOf et owl:complementOf. Les classes peuvent en outre être énumérées. On peut déclarer explicitement les extensions de classes au moyen du constructeur oneOf. Et il est possible de faire valoir qu'elles doivent être disjointes.

Remarquez que les expressions de classes peuvent s'imbriquer sans qu'il soit besoin de créer des noms pour chaque classe intermédiaire. Cela permet d'utiliser des opérations d'ensembles pour bâtir des classes complexes à partir de classes anonymes ou de classes avec des restrictions de valeur.

5.1. Les opérateurs d'ensembles
intersectionOf, unionOf, complementOf

Il faut se rappeler que les extensions de classes OWL sont des ensembles composés des individus membres de la classe. Le langage OWL permet de manipuler les extensions de classes au moyen des opérateurs d'ensembles de base.

5.1.1. L'intersection [quelques utilisations de OWL DL]

Les exemples suivants montrent l'utilisation du constructeur intersectionOf.

<owl:Class rdf:ID="WhiteWine">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine" />
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasColor" />
      <owl:hasValue rdf:resource="#White" />
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

Les classes construites par des opérations d'ensembles ressemblent le plus à des définitions que tout ce que nous avons pu voir jusqu'à présent. Les membres de la classe sont entièrement définis par l'opération d'ensembles. La construction précédente déclare que la classe des vins blancs (WhiteWine) correspond exactement à l'intersection de la classe Wine et de la classe des objets de couleur blanche (White). Si quelque chose est blanche et si c'est un vin, alors c'est une instance de la classe WhiteWine. Sans cette définition, nous pouvons savoir que les vins blancs sont des vins et sont blancs, mais pas l'inverse. C'est un outil important pour catégoriser des individus. (Remarquez que la déclaration rdf:parseType='Collection' est un élément syntaxique obligatoire).

<owl:Class rdf:about="#Burgundy">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine" />
    <owl:Restriction>
      <owl:onProperty rdf:resource="#locatedIn" />
      <owl:hasValue rdf:resource="#BourgogneRegion" />
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

Nous définissons ici la classe Burgundy pour y inclure exactement les vins ayant au moins une relation locatedIn avec la région Bourgogne. Nous aurions pu déclarer une nouvelle classe ThingsFromBourgogneRegion et l'utiliser comme classe dans la construction owl:intersectionOf. Mais puisque cette classe ThingsFromBourgogneRegion n'a pas d'autre emploi, la déclaration précédente présente l'avantage d'être plus concise et n'oblige pas à créer un nom forcé.

<owl:Class rdf:ID="WhiteBurgundy">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Burgundy" />
    <owl:Class rdf:about="#WhiteWine" />
  </owl:intersectionOf> 
</owl:Class>

Enfin la classe WhiteBurgundy représente exactement l'intersection de la classe des vins blancs (WhiteWine) et de celle des vins de Bourgogne (Burgundy). Les vins de la classe Burgundy, quant à eux, sont produits en Bourgogne, une région de France, et sont des vins secs. Tous les vins individuels qui satisfont à ces critères font partie de l'extension de classe WhiteBurgundy.

5.1.2. L'union [OWL DL]

L'exemple suivant illustre l'utilisation du constructeur unionOf. On l'utilise exactement comme le constructeur intersectionOf :

<owl:Class rdf:ID="Fruit">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#SweetFruit" />
    <owl:Class rdf:about="#NonSweetFruit" />
  </owl:unionOf>
</owl:Class>

La classe Fruit comprend à la fois l'extension de classe SweetFruit et l'extension de classe NonSweetFruit.

Remarquez comme cette construction de type union diffère complètement de la suivante :

<owl:Class rdf:ID="Fruit">
  <rdfs:subClassOf rdf:resource="#SweetFruit" />
  <rdfs:subClassOf rdf:resource="#NonSweetFruit" />
</owl:Class>                                             ¬ 

Cela veut dire que les instances de la classe Fruit sont un sous-ensemble de l'intersection de la classe des fruits sucrés (SweetFruit) et de la classe des fruits non sucrés (NonSweetFruit), qui est manifestement l'ensemble vide.

5.1.3. Le complémentaire [OWL DL]

Le constructeur complementOf sélectionne tous les individus dans le domaine de discours n'appartenant pas à une certaine classe. Cela se rapportent en général à un ensemble très grand d'individus :

  <owl:Class rdf:ID="ConsumableThing" />

  <owl:Class rdf:ID="NonConsumableThing">
    <owl:complementOf rdf:resource="#ConsumableThing" />
  </owl:Class>

La classe des choses non consommables (NonConsumableThing) a pour membres tous les individus n'appartenant pas à l'extension de la classe des choses consommables (ConsumableThing). Cet ensemble comprend tous les individus de la classe Wines Winery, Region, etc. C'est littéralement la différence d'ensembles entre owl:Thing et ConsumableThing. Aussi, le modèle d'utilisation typique du constructeur complementOf combine d'autres opérateurs d'ensembles :

<owl:Class rdf:ID="NonFrenchWine">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine"/>
    <owl:Class>
      <owl:complementOf>
        <owl:Restriction>
          <owl:onProperty rdf:resource="#locatedIn" />
          <owl:hasValue rdf:resource="#FrenchRegion" />
        </owl:Restriction>
      </owl:complementOf>
    </owl:Class>
  </owl:intersectionOf>
</owl:Class>                                             ¬ 

C'est une définition de la classe des vins non français (NonFrenchWine), c'est-à-dire l'intersection de la classe des vins (Wine) et de l'ensemble de toutes les choses non situées en France.

5.2. Les classes énumérées
oneOf [OWL DL]

Le langage OWL permet de définir une classe par énumération directe de ses membres. C'est l'affaire du constructeur oneOf. Notamment, cette énumération définit complètement l'extension de classe, de sorte qu'on ne peut pas déclarer d'autre individu appartenir à la classe.

Voici la définition de la classe WineColor dont les membres sont les individu White, Rose et Red.

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor"/>
  <owl:oneOf rdf:parseType="Collection">
    <owl:Thing rdf:about="#White"/>
    <owl:Thing rdf:about="#Rose"/>
    <owl:Thing rdf:about="#Red"/>
  </owl:oneOf>
</owl:Class>

La première chose à retenir ici, c'est qu'aucun autre individu ne sera valide pour cette classe WineColor puisque la classe a été définie par énumération.

Chaque élément de la construction oneOf doit être un individu déclaré de façon valide. Un individu doit appartenir à une classe. Dans l'exemple précédent, chaque individu est appelé par son nom. Nous avons employé la classe owl:Thing comme un clin d'œil pour introduire ces références. Sinon nous aurions pu appeler les éléments de l'ensemble conformément à leur type particulier (WineColor) de cette façon :

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor"/>
  <owl:oneOf rdf:parseType="Collection">
    <WineColor rdf:about="#White" />
    <WineColor rdf:about="#Rose" />
    <WineColor rdf:about="#Red" />
  </owl:oneOf>
</owl:Class>

Le constructeur oneOf admet d'autres descriptions d'individus plus complexes, par exemple :

<WineColor rdf:about="#White">
  <rdfs:label>White</rdfs:label>
</WineColor>                                             ¬ 

Cf. d'autres exemples d'utilisation de oneOf dans la référence OWL.

5.3. Les classes disjointes
disjointWith [OWL DL]

On peut définir le caractère disjoint d'un ensemble de classes au moyen du constructeur owl:disjointWith. Il garantit que l'individu membre d'une classe ne puisse pas être simultanément l'instance d'une autre classe définie.

<owl:Class rdf:ID="Pasta">
  <rdfs:subClassOf rdf:resource="#EdibleThing"/>
  <owl:disjointWith rdf:resource="#Meat"/>
  <owl:disjointWith rdf:resource="#Fowl"/>
  <owl:disjointWith rdf:resource="#Seafood"/>
  <owl:disjointWith rdf:resource="#Dessert"/>
  <owl:disjointWith rdf:resource="#Fruit"/>
</owl:Class>

L'exemple de la classe des pâtes (Pasta) montre plusieurs classes disjointes. Remarquez que la définition fait seulement valoir que la classe Pasta est disjointe par rapport à toutes les autres classes. Elle ne fait pas valoir, par exemple, que les classes Meat et Fruit sont disjointes. Pour que les classes d'un ensemble soit mutuellement disjointes, il faut une assertion owl:disjointWith pour chaque couple de classes.

Il est souvent besoin de définir une classe comme étant l'union d'un ensemble de sous-classes mutuellement disjointes :

<owl:Class rdf:ID="SweetFruit">
  <rdfs:subClassOf rdf:resource="#EdibleThing" />
</owl:Class>

<owl:Class rdf:ID="NonSweetFruit">
  <rdfs:subClassOf rdf:resource="#EdibleThing" />
  <owl:disjointWith rdf:resource="#SweetFruit" />
</owl:Class>

<owl:Class rdf:ID="Fruit">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#SweetFruit" />
    <owl:Class rdf:about="#NonSweetFruit" />
  </owl:unionOf>
</owl:Class>

Nous avons défini ici la classe Fruit comme étant exactement l'union des classes SweetFruit et NonSweetFruit. Et nous savons qu'elles partagent exactement la classe Fruit en deux sous-classes distinctes car elles sont disjointes. Avec l'augmentation du nombre de classes mutuellement disjointes n, le nombre des assertions de disjonction va croître en proportion du carré de n. Quoiqu'il en soit, ce nombre n reste petit dans les cas d'utilisation étudiés.

Lorsque n est grand, on peut utiliser d'autres approches pour éviter cette croissance au carré du nombre d'assertions à déclarer. La suite de tests OWL illustre l'une de ces méthodes.

La méthode illustrée est la suivante. On décrit une classe parente dont les éléments ont une propriété de cardinalité égale à un. C'est-à-dire que chaque instance doit avoir une valeur, et seulement une, pour la propriété. Puis, pour chaque sous-classe du parent, on impose que leurs instances aient une valeur unique particulière pour la propriété. Auquel cas, les sous-classes distinctes ne peuvent pas avoir de membres communs.

6. Le versionnage des ontologies

Les ontologies tout comme les logiciels sont suivies et elles évolueront donc au cours du temps. Au sein d'un élément owl:Ontology (vu précédemment), on peut avoir un lien vers une version précédente de l'ontologie en cours de définition. La propriété owl:priorVersion, chargée de fournir ce lien, peut servir à retracer l'historique d'une ontologie.

<owl:Ontology rdf:about=""> 
  ...
  <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/CR-owl-guide-20030818/wine"/> 
  ...
</owl:Ontology>

L'ontologie désignée est une version précédente de celle en cours de définition.

Les versions d'une ontologie peuvent être incompatibles de l'une à l'autre. Par exemple, une version précédente peut recéler des déclarations contredisant la version courante. Au sein de l'élément owl:Ontology, nous utilisons les étiquettes owl:backwardCompatibleWith et owl:incompatibleWith pour indiquer la compatibilité ou l'absence de compatibilité avec les versions précédentes de l'ontologie. Pas de compatibilité sans étiquette owl:backwardCompatibleWith déclarée. L'étiquette owl:versionInfo offre en outre un connecteur utilisable par les systèmes de versionnage. Au contraire des trois étiquettes précédentes, l'objet de l'étiquette owl:versionInfo est un littéral, et on peut s'en servir pour annoter les classes et les propriétés en plus des ontologies.

Dans beaucoup de cas, le suivi des versions au niveau de granularité d'une ontologie dans son entier ne suffit pas. Les personnes chargées du suivi sont susceptibles de vouloir conserver des informations de version sur les classes, les propriétés et les individus, et même cela peut se révéler encore insuffisant. La nature incrémentielle des expressions de classes dans OWL peut faire qu'une ontologie ajoute des restrictions à une classe (nommée) définie dans une autre ontologie, et ces restrictions supplémentaires peuvent nécessiter à leur tour des informations de version.

Le pouvoir d'expression du langage OWL Full est tel qu'il permet de faire n'importe quelle assertion à propos d'une classe, c'est-à-dire qu'elle est l'instance d'une autre classe, ou qu'elle (et pas ses instances) a une propriété et une valeur pour celle-ci. Ce cadre peut servir à construire une ontologie de classes et de propriétés pour le suivi des informations de version. L'espace de nommage OWL inclut deux classes prédéfinies qu'on peut utiliser dans ce but : owl:DeprecatedClass et owl:DeprecatedProperty. Elles servent à indiquer que la classe ou la propriété sont amenées à changer de manière incompatible dans la version à venir :

...
  <owl:DeprecatedClass rdf:ID="&vin;JugWine" />
  <owl:DeprecatedProperty rdf:ID="&vin;hasSeeds" />
...                                                            ¬ 

Il importe de noter que les classes owl:DeprecatedClass et owl:DeprecatedProperty n'ont pas d'autre signification et les développeurs d'outils et les utilisateurs de OWL doivent s'assurer de les employer comme prévu.

7. Exemples d'utilisation

Une fois l'ontologie initiale d'un domaine disponible, on peut développer un grand nombre d'applications pour l'exploiter. Dans ce chapitre, nous décrivons quelques exemples d'utilisation dans le domaine des vins.

7.1. Un portail des vins

Il existe aujourd'hui plusieurs sites autoproclamés des portails de vins. Le moteur de recherche Google, par exemple, produit 152000 correspondances pour la requête portail de vins. Dans les tous premiers résultats, un site intitulé Wine-Portal.com, permet d'accéder à plusieurs sites. Beaucoup de sites se proclamant des portails de vins sont essentiellement des sites d'information. Par exemple, le premier site répertorié par wine-portal.com, intitulé la cuisine du liège (www.corkcuisine.com/), fournit des informations concernant l'assortiment des vins aux aliments, les vins à offrir, etc.

En parcourant attentivement chacune des rubriques, on trouve un ensemble de pages offrant des renseignements et parfois des services relatifs au sujet. Par exemple, la rubrique Accessoires et cadeaux (N.d.T. accessories et gifts) répertorie des renseignements sur les points à considérer lorsqu'on achète des articles particuliers pour le vin ainsi qu'une liste significative de détaillants en ligne. Une autre rubrique de premier niveau, intitulée Acheter (N.d.T. shopping), contient une sous-rubrique, intitulée Acheter du vin (N.d.T. wine shopping), d'après laquelle un utilisateur peut trouver des magasins en ligne ou les adresses de magasins réels (classés par pays). Ces sites constituent juste deux exemples à l'heure actuelle parmi beaucoup d'autres et ils sont représentatifs de la notion générale de portail de vins en fournissant un ensemble de renseignements et de services lié à un espace thématique particulier.

Lorsqu'on étudie ces sites en détails, on ne sait pas aujourd'hui dans quelle mesure ils dépendent d'ontologies. Par exemple, l'examen de la source de la page HTML ne révèle aucune trace d'utilisation ontologique. Quoiqu'il en soit, il est clair que ces sites auraient pu exploiter des ontologies si des ontologies de vins avaient été disponibles.

Une utilisation simple des ontologies touche à l'organisation des sites portails et leur navigation. La liste des catégories précédentes aurait pu être générée depuis les quelques classes de niveau supérieur liées au vin. Les interrogations pourraient exploiter des ontologies de vins pour récupérer des renseignements pertinents sur les vins. Si on effectuait une recherche sur un terme contenu dans l'ontologie, la recherche pourrait se décomposer en sous-classes d'information afin de trouver des réponses plus pertinentes. On pourrait réaliser des portails qui se mettraient automatiquement à jour d'après des informations (candidates) concernant le domaine thématique. Avec des capacités de raisonnement puissantes, ils pourraient même identifier des sites susceptibles de vendre du vin puis négocier avec eux pour les inclure.

7.2. Un agent de vins

Nous avons commencé l'étude d'un agent de vins pour les besoins de l'exposé. Dans l'étude initiale, la fonction de l'agent de vins consiste à recommander des vins pour accompagner les plats d'un repas. Cette application exploite l'ontologie servant de fondement à ce guide. Cette ontologie de vins se trouve dans la bibliothèque d'ontologies DAML et elle s'intitule wines.

Un agent de vins personnalisé peut rendre plusieurs services à un humain.
L'agent peut recommander des vins en fonction d'un ensemble de contraintes (tel que le plat servi), il peut rechercher des renseignements concernant un vin particulier ou une classe de vins particulière, il peut rechercher des accessoires adéquats pour le vin (telle qu'un type de verre particulier convenant à cette variété de vin), etc.

Nous décrivons ci-dessous un exemple de système prototype simple en cours d'écriture comme projet d'étude.

Considérons le scénario suivant :
Quelqu'un prévoit un diner et l'un des invités au moins est un connaisseur des vins. L'hôte voudrait servir du vin pour bien accompagner le(s) plat(s) du menu. L'hôte voudrait également donner l'impression de connaître les vins servis à cette occasion. Il voudrait aussi s'équiper correctement en accessoires pour le diner. L'hôte a décidé de servir une sauce tomate spéciale avec des pâtes fraîches en plat principal.

Pour servir les vins appropriés à cette gastronomie, l'hôte a besoin de renseignements concernant l'assortiment des vins aux aliments. Pour avoir l'air d'être un connaisseur, l'hôte voudrait tirer profit des renseignements concernant les vins choisis pour l'événement. Pour avoir les accessoires adéquats du vin, l'hôte aurait besoin de renseignements concernant les accessoires adaptés à la situation (et dans sa gamme de prix).

D'après une ontologie de vins et une description de repas donnée, un agent de vins peut suggérer le type de vin à servir avec le repas. Par exemple, l'agent de vins pourra suggérer un cépage zinfandel. Toujours d'après une ontologie, l'agent de vins pourra indiquer un zinfandel particulier, par exemple, un zinfandel de chez Marietta. Après avoir déterminé que le vin devrait être un zinfandel, l'agent de vins pourra rechercher un magasin où acheter une sélection de zinfandels, ou bien rechercher un zinfandel particulier, par exemple, provenant de la cave Marietta. Pour peu que l'ontologie sous-jacente contienne les sources appropriées pour acheter du vin (éventuellement établies en fonction des situations géographiques respectives de l'hôte et du marchand de vin), l'agent de vins pourrait se rendre sur un site comme celui de wine.com pour y effectuer une recherche sur zinfandel, en renvoyant une liste des zinfandels mis en vente sur ce site. L'agent de vins pourrait essayer de trouver une bouteille de Zinfandel Marietta auprès du producteur, ou bien auprès de revendeurs. Par exemple, il pourrait trouver (via une recherche par le moteur de recherche Google ou via une recherche structurée sur des sites Web sélectionnés) que le site winelibrary.com propose un rabais sur un zinfandel millésime 1999 de chez Marietta au prix de $13.99. En outre, l'agent de vins pourrait effectuer un filtrage supplémentaire, par exemple, d'après la gamme de prix indiquée par le consommateur ou bien celle déterminée d'après le cépage.

L'agent de vins peut maintenant essayer de fournir des renseignements concernant le zinfandel en général ou le zinfandel Marietta en particulier. Il pourrait faire appel à une ontologie de sites de vin pour rechercher des renseignements sur des vins particuliers. Par exemple, étudier la description du zinfandel la plus récente fournie par la cave vinicole. Ou encore, parcourir les critiques provenant de sources respectées comme le Wine Spectator. Et si le site de critiques de vins préféré n'a pas d'avis sur le zifandel Marietta, évaluer des informations approchantes telles que les critiques de zinfandels issus de la même région, ici les zinfandels de Sonoma County en Californie.

Les informations générales de base peuvent également être utiles. L'hôte voudra peut-être aussi se documenter et il sera peut-être intéressé par des livres sur le vin en général ou sur les zinfandels en particulier. Par exemple, l'hôte trouvera peut-être un intérêt dans les livres sur le zinfanderl proposés par le site Amazon.com. L'hôte s'intéressera peut-être aussi aux informations concernant les vins d'une même région, notamment les zinfandels de la région de Sonoma. L'agent de vins disposera peut-être d'informations de base typiques liées à ses domaines d'expertise principaux. Par exemple, cet agent de vins traite de l'assortiment des vins aux aliments, et il est donc susceptible d'avoir des renseignements gratuits ou onéreux sur ce thème comme un article du Wine Spectator sur l'association des aliments et du vin.

L'hôte voudra peut-être aussi acheter des accessoires appropriés pour le vin avant l'événement. Le vin est servi dans des verres à vin différents selon les cépages. Par exemple, si l'hôte choisit un plat qui sera bien accompagné par un zinfandel, il sera ravi d'apprendre que Riedel est une fabrique d'articles en verre bien connue. L'hôte voudra aussi certainement se connecter au Wine Enthusiast (un fournisseur d'équipements pour le vin renommé) pour s'entendre dire que le Wine Enthusiast propose le jeu de quatre verres Vinum Zinfandel de Riedel à $63.95 (et en promotion à $59.95 pour l'achat de deux jeux). L'hôte sera aussi intéressé d'apprendre que le site Amazon.com vend le verre à pied Sommelier Zinfandel de Riedel au prix de $49.99 (en annonçant un prix courant de $65.00). Amazon propose également le même verre Vinum par jeu de six (au lieu de quatre chez Wine Enthusiast) au prix de $79.99 (en annonçant un prix courant de $119.40). Un agent de vins pourrait présenter une liste de verres, associée au repas (c'est-à-dire, des verres propres au service d'un zinfandel) puis comparée en fonction du prix ou d'autres critères choisis parmi les propriétés de l'ontologie.

L'hôte voudra peut-être d'autres accessoires pour le vin. Par l'ontologie, on sait que les tire-bouchons font partie des accessoires pour le vin. L'ontologie de base peut définir des sous-classes de tire-bouchons, mais ces renseignements peuvent tout aussi bien provenir de sites dédiés au vin. Le Wine Enthusiast vend une gamme de tire-bouchons recommandés (avec les descriptions des modèle et les gammes de prix). Le vendeur distingue également les tire-bouchons par type (à plat, de sommelier, fixe, à torsion ou à levier) dont l'hôte voudra peut-être savoir de quoi il s'agit.

L'agent de vins peut se placer à divers degrés de sophistication, selon l'expertise de l'ontologie de base dans le domaine et selon les renseignements et services fournis par les sites. Dans cet exemple, nous avons seulement exploité des renseignements concernant les vins, les cépages, l'association des aliments et des vins, quelques accessoires pour le vin, et les propriétés qui les relient. Bien entendu, nous pourrions l'affiner plus encore pour y inclure d'autres informations et plus de contraintes du consommateur.

Un exemple évolutif de cet agent de vins est disponible.

Remerciements

Ce document est le résultat de débats approfondis au sein du groupe de travail Ontologie Web dans son ensemble. Les participants à ce groupe de travail comprenaient : Yasser alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, Frederik Brysse, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther, Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, Jérôme Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Francesco Iannuzzelli, Rüdiger Klein, Natasha Kravtsova, Ora Lassila, Massimo Marchiori, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael Sintek, Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace, Christopher Welty, Charles White et John Yanosy.

Raphael Volz, Forschungszentrum Informatik (FZI), a écrit une partie du texte précurseur critique traitant des restrictions complexes. Le document DAML+OIL Walkthru a été une grande source d'inspiration. Jeremy Carroll, Jerome Euzenat, Jeff Heflin, Kevin Page et Peter F. Patel-Schneider ont revus en détails le document. Lors de la réunion face-à-face du groupe de travail le 8 octobre 2002, Stephen Buswell, Ruediger Klein, Enrico Motta et Evan Wallace ont fourni des révisions détaillées de l'ontologie qui ont amené des changements importants. Lors de la réunion face-à-face du groupe de travail le 10 janvier 2003, Jonathan Dale, Bernard Horan, Guus Schreiber et Jeff Heflin ont produit une critique détaillée du guide qui a également amené des changements. Les commentaires publics ont proposés de nombreuses suggestions et corrections utiles.

Le glossaire de OWL

Appel d'adresse URI
Comme dans RDF
Attribut
Comme dans XML
Classe
Comme dans RDF
Classe anonyme
Une classe OWL sans identificateur associé, ce sont normalement les composants de restrictions.
Classe nommée
Une classe OWL avec un identificateur associé
Classe OWL
Une classe RDFS qui appartient à l'extension de classe de owl:Class
Clotûre des importations
Les informations contenues dans un document d'ontologie, plus celles issues de la clotûre des importations de documents d'ontologie importés par ce document
Composant
Désigne une partie de définition, par exemple, les arguments de la propriété intersectionOf dans une définition de classe
Concept
Un terme informel pour les abstractions du monde réel décrites par les ontologies
Contrainte
Un terme informel pour décrire l'effet d'une restriction
Déclaration
Comme dans les graphes RDF
Définition de classe
Un terme informel pour un élément owl:Class
Définition de propriété
Un terme informel pour un élément owl:ObjectProperty et/ou un élément owl:DatatypeProperty
Description de classe
Décrit une classe OWL soit avec un nom de classe, soit en définissant une extension de classe d'une classe anonyme
Document d'ontologie
Un document Web qui contient une ontologie, signalée en général dans le document par la présence d'un élément owl:Ontology
Élément
(1) comme dans XML
(2) un membre d'un ensemble
Ensemble
Un ensemble mathématique
Entité
Comme dans XML
Individu
Une instance d'une classe OWL, c'est-à-dire une ressource appartenant à l'extension de classe d'une classe OWL
Instance
Un membre de l'extension de classe d'une class OWL
Instance de
La relation entre un individu et une classe
Nœud
Comme dans les graphes RDF
Nom
Comme dans les espaces de nommage XML
Nom de classe
Un terme informel pour la valeur de l'attribut rdf:ID d'un élément owl:Class.
Objet
(1) l'objet d'un triplet RDF
(2) un autre terme pour individu (conservé pour des raisons historiques)
Ontologie
(1) un ensemble d'informations contenant généralement des informations à propos de classes et de propriétés
(2) les informations contenues dans un document d'ontologie
Propriété à valeur de donnée
Un autre terme pour propriété de type de donnée
Propriété à valeur individuelle
Un autre terme pour propriété d'objet
Propriété d'objet
Une propriété OWL qui relie des invidus à d'autres individus
Propriété de type de donnée
Une propriété OWL qui relie des individus à des valeurs de données
Ressource
Un élément du domaine de discours RDF
Restriction
Généralement une partie d'expression de classe, une déclaration qui exprime une contrainte locale implicite
Restriction globale
Réservé aux discussions concernant le domaine et l'image des propriétés
Restriction locale
[cf. ci-dessus]
Type
Comme dans RDF (rdf:type)
Type de donnée
Un type de donnée RDFS, presque toujours l'un des types de données intégrés non listés du schéma XML
Vocabulaire
Un ensemble d'addresses URI

Index des termes et références croisées

Index des termes

TermeChapitre
cardinalité3.4.2.
classe3.1.3.
classe anonyme3.2.1.
classe de restriction3.4.1.
complémentarité5.1.3.
déduit1.
domaine3.2.1.
énuméré5.
extension3.1.
image3.2.1.
individu3.1.3.
imports2.2.
instance3.1.3.
instance de3.1.3.
intersectionOf5.1.1.
monde ouvert2.
monotonique2.
noms uniques4.2.
ontologie1.
OWL DL1.1.
OWL Full1.1.
OWL Lite1.1.
propriété3.2.1.
propriété de type de donnée3.2.1.
propriété d'objet3.2.1.
type de donnée3.2.1.
union5.1.2.


Références croisées entre le guide, la référence et la sémantique

Guide OWLRéférence OWLSémantique OWL
owl:AllDifferent / 4.3. owl:AllDifferent owl:AllDifferent
owl:allValuesFrom / 3.4.1. owl:allValuesFrom owl:allValuesFrom
owl:AnnotationProperty / 2.2. owl:AnnotationProperty owl:AnnotationProperty
owl:backwardCompatibleWith / 6. owl:backwardCompatibleWith owl:backwardCompatibleWith
owl:cardinality / 3.4.2. owl:cardinality owl:cardinality
owl:Class / 3.1.1. owl:Class owl:Class
owl:complementOf / 5.1.3. owl:complementOf owl:complementOf
owl:DataRange owl:DataRange
owl:DatatypeProperty / 3.2.2. owl:DatatypeProperty owl:DatatypeProperty
owl:DeprecatedClass / 6. owl:DeprecatedClass
owl:DeprecatedProperty / 6. owl:DeprecatedProperty
owl:differentFrom / 4.3. owl:differentFrom owl:differentFrom
owl:disjointWith / 5.3. owl:disjointWith owl:disjointWith
owl:distinctMembers / 4.3. owl:distinctMembers owl:distinctMembers
owl:equivalentClass / 4.1. owl:equivalentClass owl:equivalentClass
owl:equivalentProperty / 4.1. owl:equivalentProperty owl:equivalentProperty
owl:FunctionalProperty / 3.3. owl:FunctionalProperty owl:FunctionalProperty
owl:hasValue / 3.4.3. owl:hasValue owl:hasValue
owl:imports / 2.2. owl:imports owl:imports
owl:incompatibleWith / 6. owl:incompatibleWith owl:incompatibleWith
owl:intersectionOf / 5.1.1. owl:intersectionOf owl:intersectionOf
owl:InverseFunctionalProperty / 3.3. owl:InverseFunctionalProperty owl:InverseFunctionalProperty
owl:inverseOf / 3.3. owl:inverseOf owl:inverseOf
owl:maxCardinality / 3.4.2. owl:maxCardinality owl:maxCardinality
owl:minCardinality / 3.4.2. owl:minCardinality owl:minCardinality
owl:Nothing / 3.1.1. owl:Nothing owl:Nothing
owl:ObjectProperty / 3.2.1. owl:ObjectProperty owl:ObjectProperty
owl:oneOf / 5.2. owl:oneOf owl:oneOf
owl:onProperty / 3.4. owl:onProperty owl:onProperty
owl:Ontology / 2.2. owl:Ontology owl:Ontology
owl:OntologyProperty owl:OntologyProperty
owl:priorVersion / 6. owl:priorVersion owl:priorVersion
owl:Restriction / 3.4. owl:Restriction owl:Restriction
owl:sameAs / 4.2. owl:sameAs owl:sameAs
owl:someValuesFrom / 3.4.1. owl:someValuesFrom owl:someValuesFrom
owl:SymmetricProperty / 3.3. owl:SymmetricProperty owl:SymmetricProperty
owl:Thing / 3.1.1. owl:Thing owl:Thing
owl:TransitiveProperty / 3.3. owl:TransitiveProperty owl:TransitiveProperty
owl:unionOf / 5.1.2. owl:unionOf owl:unionOf
owl:versionInfo / 6. owl:versionInfo owl:versionInfo
rdf:List
rdf:nil
rdf:type rdf:type
rdfs:comment / 2.2. rdfs:comment
rdfs:Datatype / 3.2.2. rdfs:Datatype
rdfs:domain / 3.2.1. rdfs:domain rdfs:domain
rdfs:label / 3.1.1. rdfs:label
rdfs:Literal / 3.3. rdfs:Literal
rdfs:range / 3.2.1. rdfs:range rdfs:range
rdfs:subClassOf / 3.1.1. rdfs:subClassOf rdfs:subClassOf
rdfs:subPropertyOf / 3.2.1. rdfs:subPropertyOf rdfs:subPropertyOf

Références

OWL

[OWL Semantics and Abstract Syntax]
La sémantique et la syntaxe abstraite du langage d'ontologie Web OWL, Peter F. Patel-Schneider, Patrick Hayes et Ian Horrocks, rédacteurs. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-owl-semantics-20040210/.
Dernière version disponible à http://www.w3.org/TR/owl-semantics/.
[OWL Overview]
Vue d'ensemble du langage d'ontologie Web OWL, Deborah L. McGuinness et Frank van Harmelen, rédacteurs. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-owl-features-20040210/.
Dernière version disponible à http://www.w3.org/TR/owl-features/.
[OWL Reference]
La référence du langage d'ontologie Web OWL, Mike Dean et Guus Schreiber, rédacteurs. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
Dernière version disponible à http://www.w3.org/TR/owl-ref/.
[OWL Requirements]
Les cas et conditions d'utilisation du langage d'ontologie Web OWL, Jeff Heflin, rédacteur. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-webont-req-20040210/.
Dernière version disponible à http://www.w3.org/TR/webont-req/.
[OWL Test Cases]
Les jeux d'essais du langage d'ontologie Web OWL, Jeremy J. Carroll et Jos De Roo, rédacteurs. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-owl-test-20040210/.
Dernière version disponible à http://www.w3.org/TR/owl-test/.

Les standards apparentés du W3C

[RDF]
La spécification du modèle et de la syntaxe du cadre de description de ressources (RDF), Ora Lassila, Ralph R. Swick, rédacteurs. Recommandation du W3C de 1999,
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
Dernière version disponible à http://www.w3.org/TR/REC-rdf-syntax/.
[RDFS]
Le langage de description de vocabulaire RDF 1.0 : le schéma RDF, Dan Brickley et R.V. Guha, rédacteurs. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ .
Dernière version disponible à http://www.w3.org/TR/rdf-schema/.
[RDF Concepts]
Le cadre de description de ressources (RDF) : les concepts et la syntaxe abstraite, Graham Klyne et Jeremy J. Carroll, rédacteurs. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.
Dernière version disponible à http://www.w3.org/TR/rdf-concepts/.
[RDF Semantics]
La sémantique RDF, Patrick Hayes, rédacteur. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.
Dernière version disponible à http://www.w3.org/TR/rdf-mt/.
[RDF Syntax]
La spécificaiton de la syntaxe RDF/XML (révision), Dave Beckett, rédacteur. Recommandation du W3C du 10 février 2004,
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/.
Dernière version disponible à http://www.w3.org/TR/rdf-syntax-grammar.
[URI]
Les identificateurs de ressource uniformes (URI) : la syntaxe générique, T. Berners-Lee, R. Fielding et L. Masinter, IETF Draft Standard August, 1998 (RFC 2396).
[XML Base]
XML Base, Jonathan Marsh, rédacteur. Recomandation du W3C du 27 juin 2001,
http://www.w3.org/TR/2001/REC-xmlbase-20010627/.
Dernière version disponible à http://www.w3.org/TR/xmlbase/.
[XML Namespaces]
Les espaces de nommage dans XML, Tim Bray, Dave Hollander, Andrew Layman, rédacteurs. Recommandation du W3C de janvier 1999,
http://www.w3.org/TR/1999/REC-xml-names-19990114/.
Dernière version disponible à http://www.w3.org/TR/REC-xml-names.
[XML]
Le langage de balisage extensible (XML) 1.0, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, rédacteurs. Recommandation du W3C du 10 février 1998,
http://www.w3.org/TR/1998/REC-xml-19980210.
Dernière version disponible à http://www.w3.org/TR/REC-xml.
[XML Schema 1]
XML Schema tome 1 : les structures, Henry S. Thompson, David Beech, Murray Maloney et Noah Mendelsohn, rédacteurs. Recommandation du W3C du 2 mai 2001,
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.
Dernière version disponible à http://www.w3.org/TR/xmlschema-1/.
[XML Schema 2]
XML Schema tome 2 : les types de données, Paul V. Biron, Ashok Malhotra, rédacteurs. Recommandation du W3C du 2 mai 2001,
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
Dernière version disponible à http://www.w3.org/TR/xmlschema-2/.

Exemples d'ontologies et d'applications

[Integrating Applications]
L'intégration des applications dans le Web sémantique, James Hendler, Tim Berners-Lee et Eric Miller. Journal of the Institute of Electrical Engineers of Japan, Vol 122(10), octobre 2002, p. 676-680.
[VerticalNet]
La gestion de qualité industrielle des ontologies, Aseem Das, Wei Wu et Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-09 2001. Dans Proceedings of the International Semantic Web Working Symposium, Stanford, CA, juillet 2001.
[Wine Ontology From Daml.org]
http://www.daml.org/ontologies/76
[Wine Ontology / CLASSIC Tutorial]
Un tutoriel du système classique de représentation des connaissances, Deborah L. McGuinness, Peter F. Patel-Schneider, Richmond H. Thomason, Merryll K. Abrahams, Lori Alperin Resnick, Violetta Cavalli-Sforza et Cristina Conati. AT&T Bell Laboratories et University of Pittsburgh, 1994.
[Wine Ontology Tutorial]
Le développement d'une ontologie facile : le guide de création de votre première ontologie, Natalya Fridman Noy et Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 et Stanford Medical Informatics Technical Report SMI-2001-0880, mars 2001.
[Wine Ontology in CLASSIC]
Au sein de CLASSIC : quand et comment utiliser un langage du type KLONE, Ronald J. Brachman, Deborah L. McGuinness , Peter F. Patel-Schneider , Lori Alperin Resnick et Alex Borgida. Dans Principles of Semantic Networks: Explorations in the representation of knowledge, John Sowa, rédacteur. Morgan-Kaufmann, San Mateo, California, 1991, pages 401-456.

Les recherches apparentées d'un langage de représentation des connaissances

[DAML+OIL]
La soumission du W3C de DAML+OIL, comprend une description de références, une sémantique du modèle théorique et une sémantique axiomatique, une revue de projet annotée et des exemples.
Le balisage d'ontologie DAML+OIL annoté, Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah McGuinness, Peter F. Patel-Schneider, Lynn Andrea Stein. Décembre 2001.
[DAML-ONT]
La parution initiale de DAML-ONT à http://www.daml.org/2000/10/daml-ont.html.
[DAML-ONT KIF]
L'axiomatisation partielle de DAML-ONT à http://www.daml.org/2000/10/DAML-Ont-kif-axioms-001107.html.
Défini dans KIF (http://logic.stanford.edu/kif/kif.html).
[Description Logics]
The Description Logic Handbook: Theory, Implementation and Application, Franz Baader, Diego Calvanese, Deborah L. McGuinness, Daniele Nardi et Peter F. Patel-Schneider, rédacteurs. Cambridge University Press, 2002.
[MCF]
Le cadre du contenu meta avec XML, R.V. Guha and Tim Bray. Netscape Communications, 6 juin 1997.
[Part Whole]
A Taxonomy of Part-Whole Relations. M. Winston, R. Chaffin & D. Herrmann. Cognitive Science, 11:417-444, 1987.
[XOL]
XOL : un langage pour l'échange d'ontologies basé sur XML, Peter D. Karp, Vinay K. Chaudhri et Jerome F. Thomere. Technical Report 559. AI Center, SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025, juillet 1999.

Informations de base et pages d'accueil

[Dublin Core]
Les métadonnées Dublin Core sur la page d'accueil, http://dublincore.org/.
[Dublin Core XML]
L'expression du Dublin Core au moyen de RDF/XML, Dave Beckett, Eric Brickley et Dan Brickley.
Dublin Core Metadata Initiative, 31 juillet 2002,
http://dublincore.org/documents/2001/11/28/dcmes-xml/.
[KAON]
L'ensemble d'outils pour les ontologies et le Web sémantique de Karlsruhe à http://kaon.semanticweb.org.
[OIL]
La page d'accueil de OIL à http://oil.semanticweb.org/.
[Ontobroker]
La page d'accueil de Ontobroker à http://ontobroker.aifb.uni-karlsruhe.de/index_ob.html.
Institute AIFB, University of Karlsruhe.
[Ontoknowledge]
La page d'accueil de Ontoknowledge à http://www.ontoknowledge.org/.
[RDF Home]
RDF : le cadre de description de ressources. Informations de base à http://www.w3.org/RDF/.
[SHOE]
La page d'accueil pour les extensions d'ontologies HTML simples (SHOE) à http://www.cs.umd.edu/projects/plus/SHOE/. University of Maryland.
[KR]
La page d'accueil de KR à http://kr.org/.

Annexe A : L'essentiel de XML + RDF

Cette annexe donne une liste de liens vers des introductions aux standards dont dépend OWL.

Afin de comprendre parfaitement la syntaxe et la sémantique de OWL, chacun devrait se familiariser avec les concepts essentiels des standards apparentés du W3C et de l'IETF listés ci-dessous. Les deux premiers liens fournissent un guide minimal des langages XML et RDF.

Annexe B : Historique

Le cadre de description de ressources (RDF) a été le premier langage spécifié par le W3C pour représenter des informations sémantiques à propos de ressources arbitraires. Le schéma RDF (RDFS) est une recommandation candidate du W3C permettant d'étendre RDF pour décrire des vocabulaires RDF. On peut employer RDFS pour créer des ontologies, mais il est léger à dessein et son pouvoir d'expression est inférieur à celui de OWL.

Tout comme OWL, RDFS comprend des classes et des propriétés ainsi que des contraintes de domaine et d'image sur les propriétés. Il offre une hiérarchie d'héritage à la fois pour les classes et les propriétés. Dès sa parution, les utilisateurs ont réclamé des fonctionnalités supplémentaires, dont les types de données, les énumérations et la possibilité de définir plus rigoureusement les propriétés.

D'autres équipes de recherche examinaient déjà des fonctionnalités de ce type. Pour ceux qui souhaiteraient approfondir cette question, voici une liste non exhaustive des projets et des langages à l'étude :

Plutôt que de poursuivre avec des langages d'ontologie séparés pour le Web sémantique, un groupe de chercheurs, dont beaucoup de participants majeurs aux efforts OIL et DAML-ONT, a formé un Comité mixte É.U./U.E. pour le langage de balisage d'agent ad hoc afin de créer un nouveau langage d'ontologie Web. Ce langage DAML+OIL, s'appuyant à la fois sur OIL et DAML-ONT, a été soumis au W3C en tant que proposition de base à OWL puis sélectionné comme point de départ de OWL.

Outre les langages d'ontologie, des taxonomies diverses et des ontologies existantes font déjà l'objet d'une utilisation commerciale. Dans les sites de commerce en ligne, elles facilitent les échanges via une machine entre les acheteurs et les vendeurs, autorisent une intégration verticale des marchés et permettent la réutilisation des descriptions dans des places de marché différentes. Voici des sites utilisant effectivement des ontologies de façon commerciale :

Diverses ontologies médicales ou liées à la pharmacie ont été développées afin d'aider à la gestion de la masse actuelle énorme de données issues de la recherche médicale ou biochimique, parfois difficiles à rassembler en un tout cohérent. Le consortium Gene Ontology est une ressource majeure qui définit des ontologies pour :

Ce site propose également des pointeurs vers des ontologies pour :

Il existe actuellement de grandes taxonomies en usage qui seraient mûres pour une extension dans l'espace OWL. Par exemple, le système de classification des industries d'Amérique du Nord (NAICS) définit une hiérarchie de plus de 1900 articles identifiant les types d'industrie. Le système NAICS est également relié au système de classification industrielle standard international (ISIC, 3eme révision), développé et entretenu par l'Organisation des Nations Unies.

Annexe C : Journal des modifications depuis la recommandation proposée du 15 décembre 2003