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,
- Chris Welty, IBM Research,
- Deborah L. McGuinness, Stanford University,
Veuillez consulter l'errata de ce document,
lequel peut contenir des corrections normatives.
Cf. d'éventuelles traductions.
Copyright © 2004
W3C®
(MIT,
ERCIM,
Keio), tous droits réservés. Les règles
de responsabilité,
de marque commerciale,
d'utilisation des documents
et d'octroi de licences logicielles du W3C s'appliquent.
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 :
- Formaliser un domaine en définissant des classes et propriétés de ces classes,
- Définir des individus et affirmer des propriétés les concernant et
- 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
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 :
- Une ontologie diffère d'un schéma XML en cela qu'elle est une
représentation de connaissances et non un format de message.
La plupart des standards Web issus de l'industrie sont constitués d'une combinaison de formats de messages et de
spécifications de protocoles. Ces formats reçoivent une sémantique opérationnelle telle que
À réception de ce BonDeCommande, transférer Montant Euros de CompteDébit
vers CompteCrédit et expédier Produit
. Mais la spécification ne sera pas conçue pour tenir un raisonnement
hors du contexte de la transaction. Par exemple, on n'aura pas en général de mécanisme concluant que,
si Produit est un type de cépage Chardonnay, alors ça doit aussi être un vin blanc.
- Un avantage des ontologies OWL résidera dans la mise à disposition d'outils capables de raisonner sur elles.
Les outils fourniront une gestion générique non spécifique d'un domaine particulier, ce qui serait le cas
s'il fallait bâtir un système devant raisonner d'après le schéma XML d'une norme industrielle spécifique.
Construire un système de raisonnement solide et utile n'est pas une affaire simple. Inversement, la construction d'une ontologie
est bien plus facile. Nous pensons que beaucoup de groupes se lanceront dans la construction d'ontologies. Il bénéficieront
d'outils développés par des tiers d'après les propriétés formelles du langage OWL, des outils qui offriront
un éventail de fonctionnalités que la plupart des organisations seraient bien en peine de reproduire.
Le langage OWL offre trois sous-langages d'expression croissante conçus pour des communautés de développeurs
et d'utilisateurs spécifiques.
-
Le langage OWL Lite concerne les utilisateurs ayant principalement
besoin d'une hiérarchie de classifications et de mécanismes de contraintes simples.
Par exemple, quoique OWL Lite gère des contraintes de cardinalité, il ne permet que des valeurs de cardinalité de 0 ou 1.
Mettre en œuvre des outils pour OWL Lite devrait être plus simple que pour ses parents d'expression plus grande,
tout comme tracer un chemin de migration rapide pour des thésaurus et autres taxonomies.
-
Le langage OWL DL concerne les utilisateurs souhaitant
une expressivité maximum sans sacrifier la complétude de calcul (toutes les inférences sont sûres d'être prises en compte)
et la décidabilité (tous les calculs seront terminés dans un intervalle de temps fini) des systèmes de raisonnement.
Le langage OWL DL comprend toutes les structures de langage de OWL avec des restrictions comme la
séparation des types (une classe ne peut pas être en même temps un individu ou une propriété, une propriété être un individu ou une classe).
OWL DL se nomme ainsi pour sa correspondance avec la logique de description [Description Logics],
un champs de la recherche portant sur un fragment décidable particulier de la logique de premier ordre.
Le langage OWL DL, conçu pour gérer le secteur existant
de la logique de description, offre les propriétés de calcul souhaitées pour les systèmes de raisonnement.
-
Le langage OWL Full est destiné aux utilisateurs souhaitant
une expressivité maximum et la liberté syntaxique de RDF sans garantie de calcul. Par exemple, dans OWL Full,
on peut simultanément traiter une classe comme une collection d'individus et comme un individu à part entière. Une autre différence
significative par rapport à OWL DL réside dans la possibilité de marquer un objet owl:DatatypeProperty
comme étant un objet owl:InverseFunctionalProperty. Le langage OWL Full permet à une ontologie d'augmenter
la signification du vocabulaire prédéfini (RDF ou OWL). Un système de raisonnement ne pourra probablement pas
mettre en œuvre toutes les caractéristiques de OWL Full.
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.
- Toute ontologie OWL Lite légale est une ontologie OWL DL légale.
- Toute ontologie OWL DL légale est une ontologie OWL Full légale
- Toute conclusion OWL Lite valide est une conclusion OWL DL valide.
- Toute conclusion OWL DL valide est une conclusion OWL Full valide.
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]
.
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.
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.
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#">
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>
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.
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.
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.
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.
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.
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 :
-
Les niveaux de représentation : Dans certains cas, on peut considérer quelque chose, qui est à l'évidence une classe, comme
étant elle-même une instance d'autre chose. Par exemple, dans l'ontologie de vins, il y a la notion d'une classe
Grape
prévue pour représenter l'ensemble de tous les cépages. Un exemple d'instance de cette classe est CabernetSauvignonGrape
qui représente dans ce cas le cépage Cabernet Sauvignon. Toutefois, on peut considérer cette instance CabernetSauvignonGrape
comme une classe à part entière, c'est-à-dire comme l'ensemble de tous les cépages Cabernet Sauvignon réels.
-
La sous-classe versus l'instance : Il est très facile de confondre la relation
instance de
et la relation sous-classe de
.
Par exemple, il peut sembler arbitraire de faire de l'individu CabernetSauvignonGrape une instance de la classe Grape
plutôt qu'une sous-classe de Grape. Ce n'est pas une décision arbitraire. La classe Grape représente
l'ensemble de tous les cépages et, de ce fait, toute sous-classe de Grape devrait représenter un sous-ensemble
de ces cépages. On devrait donc considérer CabernetSauvignonGrape comme une
instance de la classe Grape, et non pas comme une sous-classe
de celle-ci. Ce n'est pas la description d'un sous-ensemble des cépages : c'est un cépage.
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.
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é :
- Les propriétés de types de données,
qui sont des relations entre des instances de classes, des littéraux RDF et des types de donnée du schéma XML ;
- Les propriétés d'objets,
qui sont des relations entre les instances de deux classes. Remarquez que le terme propriété d'objet ne cherche pas à refléter
le terme RDF
rdf:object ([RDF], 5.3.4).
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.
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:string | xsd:normalizedString | xsd:boolean |
| xsd:decimal | xsd:float | xsd:double |
| xsd:integer | xsd:nonNegativeInteger | xsd:positiveInteger |
| xsd:nonPositiveInteger | xsd:negativeInteger |
| xsd:long | xsd:int | xsd:short | xsd:byte |
| xsd:unsignedLong | xsd:unsignedInt | xsd:unsignedShort | xsd:unsignedByte |
| xsd:hexBinary | xsd:base64Binary |
| xsd:dateTime | xsd:time | xsd:date | xsd:gYearMonth |
| xsd:gYear | xsd:gMonthDay | xsd:gDay | xsd:gMonth |
| xsd:anyURI | xsd:token | xsd:language |
| xsd:NMTOKEN | xsd:Name | xsd: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}.
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>
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.
| Relation | Implications |
|---|
| allValuesFrom | Pour tous les vins, s'ils ont des producteurs, tous les producteurs sont des caves vinicoles. |
| someValuesFrom | Pour 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.
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.
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.
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.
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.
| Relation | Implications |
|---|
| subClassOf | TexasThings(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.
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.
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.
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.
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.
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.
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.
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 WinesWinery, 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.
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.
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.
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.
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.
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.
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