Lisez-moi S.V.P. 
W3C

Les cas et conditions d'utilisation du langage d'ontologie Web OWL

Recommandation du W3C du 10 février 2004

Cette version :
http://www.w3.org/TR/2004/REC-webont-req-20040210/
Dernière version :
http://www.w3.org/TR/webont-req/
Version précédente :
http://www.w3.org/TR/2003/PR-webont-req-20031215/
Rédacteur :
Jeff Heflin (Lehigh University) heflin@cse.lehigh.edu

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

Cf. également d'éventuelles traductions.


Résumé

Ce document définit les scénarios d'utilisation, les objectifs et les conditions requises d'un langage d'ontologie Web. Une ontologie définit formellement un ensemble commun de termes servant à décrire et représenter un domaine. Les ontologies peuvent être utilisées par des outils automatiques pour actionner des services évolués comme la recherche plus précise d'informations sur le Web, les agents logiciels intelligents ou la gestion de connaissances.

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

Le Web sémantique est une vision du Web futur où les informations reçoivent une signification explicite, facilitant ainsi le traitement et l'intégration automatiques des informations disponibles sur le Web par des machines. Le Web sémantique s'appuiera sur la capacité du langage XML à définir des schémas de balisage personnalisés [XML] et sur l'approche flexible du langage RDF [RDF Concepts] pour représenter des données. L'élément suivant nécessaire pour le Web sémantique est un langage d'ontologie Web qui puisse décrire formellement la sémantique des classes et propriétés utilisées dans les documents Web. Pour que les machines puissent utilement effectuer des tâches de raisonnement sur ces documents, ce langage doit dépasser la sémantique élémentaire du schéma RDF [RDF Vocabulary].

Ce document constitue l'une des parties de la spécification du langage d'ontologie Web OWL. Le chapitre La cartographie du document de la vue d'ensemble OWL décrit chaque partie. Le présent document énumère les conditions requises pour un langage d'ontologie Web selon la perception du groupe de travail. Toutefois, on espère que d'autres langages futurs étendront le langage OWL pour lui apporter, entre autres choses, des possibilités logiques supérieures et la capacité d'établir la confiance dans le Web sémantique.

Nous motivons la besoin d'un langage d'ontologie Web en décrivant six cas d'utilisation. Certains s'inspirent d'efforts entrepris actuellement dans l'industrie et le monde universitaire, d'autres démontrent des possibilités à échéances plus lointaines. Ces cas d'utilisation sont suivis par les buts de conception qui décrivent les objectifs et les directives de niveau supérieur du développement du langage. Ces buts de conception seront pris en compte pour l'évaluation des caractéristiques proposées. Le chapitre Les conditions requises présente l'ensemble de caractéristiques qui devraient se trouver dans le langage et donne les justifications de ces caractéristiques. Le chapitre Les objectifs décrit une liste de caractéristiques qui pourraient se révéler utiles dans beaucoup de cas d'utilisation mais qui ne sont pas forcément prises en compte par le groupe de travail.

La charte du groupe de travail Ontologie Web charge celui-ci de produire cette sémantique plus expressive et de définir les mécanismes permettant au langage de fournir des relations plus complexes entre les entités, dont : des méthodes pour limiter les propriétés des classes concernant le nombre et le type, des méthodes pour inférer que des éléments avec diverses propriétés sont membres d'une classe particulière, un modèle bien défini d'héritage des propriétés, et des extensions sémantiques similaires des langages de base. La spécification détaillée du langage d'ontologie Web prendra en considération :

1.1 Qu'est-ce qu'une ontologie ?

Une ontologie définit les termes servant à décrire et représenter un champ de connaissance. Les ontologies sont utilisées par les personnes, les bases de données et les applications qui ont besoin de partager des informations de domaine (un domaine est juste un sujet ou un champ de connaissance particuliers, comme la médecine, la fabrication d'outils, l'immobilier, la réparation automobile, la gestion financière, etc.). Les ontologies incluent les définitions utilisables par l'ordinateur des concepts élémentaires du domaine et leurs relations (remarquez ici et dans tous le document que le terme définition n'est pas employé au sens technique compris des logiciens). Elles codent les connaissance dans un domaine et aussi les connaissances recouvrant plusieurs domaines. Elles permettent ainsi de réutiliser des connaissances.

Le mot ontologie a été utilisé pour décrire des artéfacts avec différents degrés de structure. Ils couvrent les taxonomies simples (telle que la hiérarchie du portail Yahoo), les schémas de métadonnées (tel que le système Dublin Core), jusqu'aux théories logiques. Le Web sémantique a besoin d'ontologies avec un degré de structure important. Il faut qu'elles définissent les descriptions des types de concepts suivants :

On exprime habituellement les ontologies dans un langage logique, de façon à pouvoir faire des distinctions détaillées, précises, cohérentes, rationnelles et significatives entre les classes, les propriétés et les relations. Certains outils d'ontologie peuvent effectuer un raisonnement automatique en utilisant des ontologies, et donc fournir des services évolués aux applications intelligentes tels que recherche et récupération conceptuelle/sémantique, agents logiciels, aide à la décision, reconnaissance de la parole et de la langue, gestion des connaissances, bases de données intelligentes et commerce électronique.

Les ontologies figurent en bonne place dans le Web sémantique en devenir comme solution pour représenter la sémantique des documents et pour en permettre l'exploitation par les applications Web et les agents intelligents. Les ontologies peuvent se révéler très utiles à une communauté pour structurer et définir la signification des termes de métadonnées en cours de collecte et de normalisation. Grâce aux ontologies, les applications de demain deviendront intelligente, dans le sens où elles pourront fonctionner plus exactement au niveau conceptuel humain.

Les ontologies sont critiques pour les applications qui recherchent ou rassemblent des informations provenant de communautés diverses. Bien que les définitions DTD XML et les schémas XML suffisent pour échanger des données entre des parties accordées au préalable sur les définitions, les lacunes de leurs sémantiques empêchent les machines d'accomplir cette tâche de façon fiable avec les nouveaux vocabulaires XML. Un même terme peut avoir une signification différente (parfois subtile) dans des contextes différents, et inversement, des termes différents peuvent servir pour des éléments avec une même signification. Le langage RDF et le schéma RDF s'attaquent à ce problème en permettent d'associer une sémantique simple à des identificateurs. Avec le schéma RDF, on peut définir des classes qui ont plusieurs sous-classes et superclasses, et des propriétés qui peuvent avoir des sous-propriétés, des domaines et des images. Dans ce sens, le schéma RDF est un langage d'ontologie simple. Toutefois, pour faire coopérer plusieurs schémas, développés et gérés indépendamment, une sémantique plus riche est nécessaire. Par exemple, le schéma RDF ne peut pas établir que les classes Personne et Voiture sont disjointes, ou qu'un quatuor à cordes se compose d'exactement quatre musiciens.

L'un des buts de ce document est de définir ce qui est nécessaire dans un langage d'ontologie Web. Ces conditions seront motivées par des cas d'utilisation probables et des buts de conception généraux tenant compte des difficultés d'application de la notion standard des ontologies à l'environnement unique du Web.

2 Les cas d'utilisation

Les ontologies peuvent servir à améliorer des applications existantes basées sur le Web et permettre de nouvelles utilisations du Web. Dans ce chapitre, on décrit six cas d'utilisation représentatifs d'ontologies Web. Remarquez que cette liste n'est pas exhaustive et il s'agit plutôt d'une vue transversale de cas d'utilisation intéressants. Ces cas ont guidé le choix des conditions requises pour le langage OWL (cf. le chapitre 4). Ces conditions ont été sélectionnées par rapport aux aspects des cas d'utilisation jugés les plus importants par le groupe de travail, tout en considérant les limites de la charte OWL et d'autres contraintes de conception. On ne devrait donc pas supposer que OWL prendra directement en compte tous les aspects de ces cas d'utilisation.

2.1 Les portails Web

Un portail Web est un site Web qui offre un contenu d'informations concernant un thème commun, par exemple, une ville ou un domaine d'intérêt particuliers. Un portail Web permet aux personnes intéressées par ce thème de recevoir des nouvelles, de trouver et parler à quelqu'un, de bâtir une communauté et de trouver des liens vers d'autres ressources Web d'intérêt commun.

Pour réussir, un portail doit être un point de départ vers du contenu intéressant. Ce contenu est fourni habituellement par les membres de la communauté, qui souvent le rangent dans un sous-thème. Une autre méthode de collecte repose sur un étiquetage du contenu par les fournisseurs d'information qui peut servir à syndiquer ce contenu. Cet étiquetage prend habituellement la forme de balises de métadonnées simples qui identifient le sujet du contenu, etc.

Toutefois, un simple index de domaines sera peut-être insuffisant pour rechercher le contenu demandé par les membres de la communauté. Pour une meilleure syndication, le portail Web peut définir une ontologie pour la communauté. Cette ontologie peut fournir une terminologie pour décrire le contenu et des axiomes pour définir des termes d'après les autres termes de l'ontologie. Par exemple, une ontologie pourrait inclure une terminologie avec les termes journal, publication, personne et auteur. Elle pourrait ensuite inclure des définitions telles que tous les journaux sont des publications, ou les auteurs de toutes les publications sont des personnes. Combinées à des faits, ces définitions permettent d'inférer d'autres faits forcément vrais. À leur tour, ces inférences permettent aux utilisateurs d'obtenir des résultats de recherche auprès du portail impossibles à obtenir avec des systèmes de repérage conventionnels. Cette technique repose sur les fournisseurs d'information utilisant le langage d'ontologie Web pour saisir des relations d'ontologies de qualité, et un but de OWL est de permettre un contenu de métadonnées suffisamment riche et utile pour motiver cet effort nécessaire. C'est un autre défi que de minimiser cet effort, et un langage d'ontologie aura vraisemblablement un impact plus grand s'il facilite la saisie non intrusive des métadonnées au cours du processus de création de l'information.

Un exemple de portail basé sur une ontologie est OntoWeb. Ce portail sert la communauté universitaire et industrielle intéressée par la recherche sur les ontologies. Un autre exemple de portail utilisant les technologies du Web sémantique et pouvant tirer avantage d'un langage d'ontologie est le projet The Open Directory Project, un annuaire complet et gigantesque du Web, rédigé par des humains. Une communauté globale immense de rédacteurs bénévoles le construit et l'entretient. Des clichages RDF de la base de données Open Directory sont disponibles en téléchargement.

2.2 Les collections multimédias

Les ontologies peuvent servir pour l'annotation sémantique des collections d'images, de sons ou d'autres objets non textuels. Il est encore plus difficile pour les machines d'extraire une sémantique significative d'objets multimédias que d'un texte en langue naturelle. Ainsi, ces types de ressources sont habituellement identifiés par des légendes ou des balises de métadonnées. Par contre, puisque les personnes décriront peut-être différemment ces objets non textuels, il importe que les installations de recherche offrent plus qu'une simple correspondance de mots-clés. Idéalement, les ontologies devraient saisir une connaissance supplémentaire à propos du domaine pouvant servir à améliorer la récupération des images.

Les ontologies multimédias peuvent être de deux types : spécifiques du média ou spécifiques du contenu. Les ontologies spécifiques du média peuvent avoir des taxonomies des différents types de média, et décrire les propriétés des différents médias. Par exemple, une vidéo peut inclure des propriétés pour identifier la longueur du clip et les changements de plan. Les ontologies spécifiques du contenu décrivent le sujet de la ressource, tels que la mise en scène ou les participants. Comme ces ontologies ne s'adressent pas à un média particulier, elles peuvent être réutilisées par d'autres documents portant sur le même domaine. Cette réutilisation améliorerait une recherche simple d'informations concernant un domaine particulier, indépendamment du format de la ressource. Les recherches où le type du média est important peuvent combiner les ontologies spécifiques du média et celles spécifiques du contenu.

Comme exemple de collection multimédia, prenons une archive d'images de meubles anciens. Une ontologie du mobilier ancien serait très utile pour effectuer des recherches dans une telle archive. On peut utiliser une taxonomie pour classer les différents types de meubles. Il serait aussi utile que l'ontologie puisse exprimer une connaissance de définition. Par exemple, si un indexeur sélectionne la valeur Georgien tardif comme style/période d'un coffre ancien à tiroirs, on devrait pouvoir inférer que l'élément de donnée date.création a une valeur comprise entre 1760 et 1811, et que l'élément de donnée culture a pour valeur britannique. La disponibilité de ce type de connaissance de fond augmente beaucoup les possibilités de l'indexation comme de la recherche. Une autre caractéristique qui peut se révéler utile est la prise en charge de la représentation d'une connaissance implicite. Comme exemple de connaissance de ce type, un coffre à tiroirs du Georgien tardif qui sans information supplémentaire sera supposé fabriqué en acajou. Cette connaissance est cruciale pour les requêtes sémantiques réelles, par exemple, une requête d'utilisateur pour un meuble de rangement ancien en acajou pourrait correspondre aux images de coffres à tiroirs du Georgien tardif, même sans mention du bois dans l'annotation de l'image.

2.3 L'administration d'un site Web d'entreprise

Les grandes entreprises ont habituellement beaucoup de pages Web concernant des sujets comme les communiqués de presse, les offres de produits et d'études de cas, les procédures d'entreprise, les présentations et comparatifs de produits internes, les documents techniques et les descriptions de processus. Les ontologies peuvent servir à indexer ces documents et fournir de meilleures méthodes de récupération. Bien que nombre de grandes entreprises disposent d'une taxonomie d'organisation des informations, souvent ça ne suffit pas. Une seule ontologie est souvent limitative car les catégories constituantes sont vraisemblablement contraintes à celles représentant une seule vue et une seule granularité d'un domaine ; la possibilité de travailler simultanément avec plusieurs ontologies enrichirait les descriptions. En outre, la possibilité d'effectuer une recherche sur les valeurs de différents paramètres est souvent plus utile qu'une recherche par mots-clés avec des taxonomies.

Un site Web utilisant des ontologies est susceptible d'intéresser :

Pour chacun de ces types d'utilisateur, le problème habituel est qu'ils ne peuvent pas partager de terminologie avec les auteurs des contenus demandés. Le vendeur peut ignorer le terme technique d'une caractéristique souhaitée, ou les techniciens dans différents domaines de compétence peuvent employer des termes différents pour le même concept. Pour ces problèmes, il serait utile que chaque classe d'utilisateurs dispose d'ontologies de termes différentes, mais que les ontologie soient interreliées, de façon à pouvoir effectuer automatiquement des traductions.

Le cadrage des requêtes au bon niveau d'abstraction soulève un autre problème. Un chef de projet recherchant un expert en systèmes d'exploitation devrait, par exemple, pouvoir trouver un employé expert à la fois d'Unix et de Windows.

Un aspect d'une grande entreprise de services est qu'elle peut offrir un large éventail de compétences. Mais pour réaliser des contrats importants, il faut parfois assembler ces savoir-faire autrement et innover. Souvent, aucun projet antérieur seul ne correspondra. Le défi tient dans le raisonnement sur la manière de réassembler les modèles et documents passés en configurations nouvelles, tout en satisfaisant à un ensemble de conditions préalables diverses.

2.4 La documentation d'un concept

Ce cas d'utilisation correspond à un corps volumineux de documents techniques, comme ceux trouvés dans l'industrie aérospatiale. Cette documentation peut être de plusieurs types différents, comprenant la documentation de conception, la documentation de fabrication et la documentation d'essai. Ces ensembles de documents ont chacun une structure hiérarchique différente d'un ensemble à l'autre. Il existe aussi un ensemble d'axes implicites reliant les ensembles de documentation. Par exemple, dans des documents de conception aéronautique, un élément longeron d'aile pourrait être présent dans chaque ensemble.

Les ontologies peuvent servir à bâtir un modèle informationnel permettant l'exploration de l'espace d'informations selon les éléments représentés, les associations entre éléments, les propriétés des éléments et les liens vers la documentation qui les décrit et définit (c'est-à-dire, la justification externe de l'existence de l'élément dans le modèle). Cela veut dire aussi que l'ontologie et la taxonomie ne sont pas indépendantes des éléments physiques qu'elles représentent mais qu'elles peuvent être développées/explorées en tandem.

Un exemple concret de ce cas d'utilisation est celui de la documentation de conception dans le domaine aérospatial utilisée habituellement par :

Pour gérer ce type d'utilisation, il est importe de pouvoir définir des contraintes. Ces contraintes peuvent être utilisées pour améliorer la recherche ou pour vérifier la cohérence. Un exemple de contrainte serait le suivant :

biplan(X) => CardinalityOf(aile(X)) = 2
longeronAile(X) AND aile(Y) AND isComponentOf(X,Y) => length(X) < length(Y)

Une autre utilisation courante de ce type d'ontologie est de permettre la visualisation et l'édition de tableaux montrant des instantanés de l'espace d'informations centrés sur un concept particulier (par exemple, une classe ou une instance). Ce sont généralement des diagrammes d'activités/règles, ou des diagrammes entités-relations.

2.5 Les agents et services

Le Web sémantique peut offrir aux agents la capacité de comprendre et d'intégrer des ressources d'information diverses. Un exemple spécifique est celui d'un planificateur d'activités sociales qui utilisera ces données pour organiser la soirée de l'utilisateur selon ses préférences (quels types de films aime-t-il, quelle est sa cuisine favorite, etc.). La tâche de planification de cette soirée dépendra de la richesse de l'environnement de services offerts et des besoins de l'utilisateur. Pendant le processus de détermination/filtrage du service, des services de notation et de critiques peuvent également être consultés pour approcher au mieux les préférences de l'utilisateur (par exemple, les critiques et les notations de films ou de restaurants pour trouver le meilleur).

Ce type d'agent a besoin d'ontologies de domaines pour représenter les termes spécifiques aux restaurants, aux hôtels, etc. et d'ontologies de services pour représenter les termes employés par les services réels. Ces ontologies permettront la saisie des informations nécessaires aux applications pour discriminer et évaluer les préférences de l'utilisateur. Ces informations peuvent être fournies par des sources diverses, tels que des portails, des sites à service spécifique, des sites de réservation, et du Web en général.

L'entreprise Agentcities est un exemple d'initiative étudiant l'utilisation d'agents dans un environnement de services répartis dans l'Internet. Elle impliquera de construire un réseau de plateformes d'agents représentant des villes réelles ou virtuelles, telles que San Francisco ou la Bay Area, et de les garnir avec les services de ces villes. Pour commencer, ce seront des services orientés grand public, tels que hôtels, restaurants, loisirs, etc. qui s'étendront éventuellement aux services interentreprises, telle la gestion salariale, et aux services aux entreprises.

Cela nécessitera plusieurs ontologies de domaines et de services différentes. Les questions-clés comprennent :

2.6 L'informatique omniprésente

L'informatique omniprésente est un paradigme émergeant de l'informatique personnelle, caractérisé par un glissement d'une machinerie informatique dédiée vers des capacités informatiques envahissantes intégrées dans nos environnements quotidiens. Caractéristiques de l'informatique omniprésente, les appareils miniaturisés, portables et sans fil. La prolifération et la nature sans fil des appareils imposent aux architectures de réseaux de prendre en charge une configuration automatique ad hoc. Une autre raison au développement d'une configuration automatique tient au fait cette technologie vise les consommateurs ordinaires.

Une technologie-clé de réseaux vraiment ad hoc est la découverte de service, une fonctionnalité au travers de laquelle des services (c'est-à-dire, les fonctions offertes par divers appareils tels que les téléphones portables, les imprimantes, les capteurs, etc.) peuvent être décrits, annoncés et détectés par d'autres. Tous les mécanismes actuels de découverte de service et de description de capacité (par exemple, JINI de la société Sun, UPnP de la société Microsoft) se fondent sur des systèmes de représentation ad hoc et s'appuient fortement sur une normalisation (c'est-à-dire, sur une identification a priori de toutes les choses susceptibles d'être communiquées ou discutées).

La question-clé (et le but) de l'informatique omniprésente est l'interopérabilité fortuite, une interopérabilité dans des conditions non chorégraphiées, c'est-à-dire que les appareils non conçus pour fonctionner obligatoirement ensemble (tels ceux construits pour d'autres usages, par des fabricants différents, à d'autres époques, etc.) devraient être capables de détecter leurs caractéristiques mutuelles et d'en tirer profit. Pouvoir comprendre les autres appareils et raisonner sur leurs services/fonctionnalités est nécessaire, puisque les scénarios à terme de l'informatique omniprésente mettent en scène des dizaines voire des centaines d'appareils, et qu'une normalisation a priori des scénarios d'utilisation n'est pas concevable.

Les scénarios d'interopération sont par nature dynamiques (c'est-à-dire que les appareils apparaissent et disparaissent à n'importe quel moment, car leurs propriétaires les transportent d'une pièce ou d'un bâtiment à un autre) et ne donnent lieu à aucune intervention humaine pour la (re)configuration. L'utilisation des services implique des phases de découverte, de passage de contrat et de composition. Le passage de contrat de services peut impliquer une représentation d'informations concernant la sécurité, la vie privée et la confiance, ainsi que les détails d'une compensation (un fournisseur de services peut recevoir une rémunération pour les services rendus). En particulier, un but est d'exprimer les politiques de sécurité d'entreprises ou d'organisations dans une forme neutre pour les applications, qui permet ainsi une représentation des contraintes entre les divers mécanismes d'exécution (par exemple, les pare-feux, les filtres/scanners, les dispositifs de surveillance du trafic, les routeurs au niveau de l'application et les répartisseurs de charge).

On utilisera donc un langage d'ontologie pour décrire les caractéristiques des appareils, les méthodes pour accéder à ces appareils, la politique d'utilisation de l'appareil établie par son propriétaire et les autres contraintes et conditions techniques qui affectent l'incorporation de l'appareil dans un réseau de type informatique omniprésente. Les besoins définis pour le langage DAML-S (notamment les questions tournant autour de l'expressivité du langage) et pour les systèmes basés sur RDF pour représenter des informations au sujet des caractéristiques des appareils (à savoir, le standard Les profils composites de capacités/préférences (CC/PP) du W3C et le profil d'agent utilisateur (UAProf) du WAP Forum), sont directement en rapport avec ce cas d'utilisation et avec l'infrastructure de ressources gérant les applications qui négocieront et configureront dynamiquement les réseaux ad hoc.

3 Les buts de conception

Les buts de conception décrivent les motivations générales du langage qui ne correspondent pas forcément à un seul cas d'utilisation. Accompagnant les cas d'utilisation, ils sont à l'origine des conditions requises et des objectifs des chapitres 4 et 5. Dans ce chapitre, on décrit huit buts de conception du langage d'ontologie Web, en particulier :

Pour chaque but, nous décrivons les tâches qui lui reviennent et en donnons la justification. Nous décrivons également le degré de prise en charge du but par le langage RDF et le schéma RDF.

3.1 Les ontologies partagées

Les ontologies devraient être publiquement disponibles, et des sources de données différentes devraient pouvoir renvoyer à la même ontologie pour une signification partagée. Elles devraient également pouvoir étendre d'autres ontologies afin de fournir des définitions supplémentaires.

Tâches à gérer :
Tous cas d'utilisation où des sources de données réparties utilisent une terminologie partagée.

Justification :
L'interopérabilité impose de s'accorder sur les définitions des identificateurs. Les ontologies peuvent fournir des ensembles d'identificateurs normalisés et des descriptions de ces indicateurs. Les sources de données renvoyant à la même ontologie acceptent explicitement d'utiliser les mêmes identificateurs avec les mêmes significations.

Souvent, les ontologies partagées ne suffisent pas. Une organisation trouvera peut-être qu'une ontologie existante couvre 90 % de ses besoins, mais les 10 % restants sont critiques. Auquel cas, l'organisation ne devrait pas être obligée de créer une nouvelle ontologie depuis le début, et devrait plutôt pouvoir en créer une, qui étende une ontologie existante et ajoute tous les identificateurs et définitions souhaités.

Gestion RDF(S) :
Dans le langage RDF, chaque schéma a son propre espace de nommage identifié par une adresse URI. Chaque ressource dans le schéma a un identificateur ID, et on peut créer un identificateur unique global en combinant cet ID et l'adresse URI de l'espace de nommage. Toute ressource utilisant cette adresse URI appelle le terme comme il est défini dans le schéma en question. Cependant, le langage RDF reste vague en ce qui concerne une définition de terme avec des définitions partielles provenant de plusieurs schémas. La spécification du langage semble suggérer que la définition du terme est l'union de toutes les descriptions utilisant le même identificateur, indépendamment de la source. Toutefois, cela peut poser des problèmes dans un environnement répartie, où des schémas peuvent contenir des définitions fausses ou erronées. Dans RDF, une ressource n'a aucun moyen d'indiquer à quel ensemble de définitions elle appartient.

3.2 L'évolution des ontologies

Une ontologie peut changer pendant son existence. Une source de données devrait préciser la version de l'ontologie à laquelle elle renvoie.

Un problème important est de savoir si les documents renvoyant à une version de l'ontologie sont compatibles avec ceux renvoyant à une autre version. Les révisions compatibles et incompatibles devraient être toutes permises, mais il faudrait pouvoir les distinguer. Remarquez, puisque les descriptions formelles n'offrent que des approximations des significations de la plupart des identificateurs, qu'une révision peut changer la signification attendue d'un identificateur sans en changer la description formelle. Déterminer la rétrocompatibilité sémantique impose ainsi plus que de simplement comparer les descriptions de termes. Les créateurs d'ontologies ont donc besoin de pouvoir indiquer explicitement ces changements.

Tâches à gérer :
Tous cas d'utilisation où l'ontologie est susceptible de changer, en particulier ceux où le possesseur de l'ontologie n'est pas le fournisseur d'informations.

Justification :
Puisque le Web croît et change de façon continue, nous devons nous attendre à ce que les ontologies changent aussi. Les ontologies sont susceptibles de changer aux raisons que les versions précédents contenaient des erreurs, ou qu'une nouvelle modélisation du domaine est à la mode, ou qu'une nouvelle terminologie est créée (par exemple, suite à l'invention d'une nouvelle technologie). Un langage d'ontologie Web doit être capable de satisfaire à la révison d'une ontologie. Remarquez que l'évolution d'une ontologie diffère de l'extension d'une ontologie, laquelle ne modifie pas l'ontologie originale.

Gestion RDF(S) :
La spécification du schéma RDF recommande que chaque version d'un schéma soit une ressource séparée avec sa propre adresse URI. Les propriétés rdfs:subClassOf et rdfs:subPropertyOf peuvent servir à relier les nouvelles versions des classes et propriétés aux anciennes versions. Toutefois, cela a pour inconvénient qu'on ne peut pas rétracter les définitions erronées. Par exemple, supposons que dans le schéma v1 on ait v1:Dauphin rdfs:subClassOf v1:Poisson. Lorsque cette erreur est repérée, la nouvelle version du schéma appelée v2 déclare v2:Dauphin rdfs:subClassOf v2:Mammifère. Par contre, si on fait v2:Dauphin rdfs:subClassOf v1:Dauphin, on déclare également que v2:Dauphin rdfs:subClassOf v1:Poisson, et on perpétue l'erreur.

3.3 L'interopérabilité des ontologies

Des ontologies différentes peuvent modéliser les mêmes concepts de façons différentes. Le langage devrait offrir des primitives pour relier des ontologies différentes, en permettant ainsi de convertir les données vers d'autres ontologies et en instituant un réseau d'ontologies.

Tâches à gérer :
Tous cas d'utilisation où il faut intégrer des données provenant de fournisseurs différents avec des terminologies différentes.

Justification :
Bien que le partage et l'extension des ontologies permettent un certain degré d'interopérabilité entre des organisations et des domaines différents, on peut souvent modéliser les mêmes informations de plusieurs façons. Cela peut être à cause des perspectives différentes d'organisations, de métiers, de nationalités, etc. différents. Pour que les machines puissent intégrer les informations renvoyant à des ontologies hétérogènes, il est nécessaire d'avoir des primitives permettant aux ontologies de relier des concepts à leurs équivalents dans d'autres ontologies.

Gestion RDF(S) :
Le langage RDF offre une gestion minimale de l'interopérabilité avec les propriétés rdfs:subClassOf et rdfs:subPropertyOf.

3.4 La détection des incohérences

Des ontologies ou des sources de données différentes peuvent être contradictoires. Il devrait être possible de détecter ces incohérences.

Tâches à gérer :
Tous cas d'utilisation où la décentralisation des données et l'absence d'une autorité de contrôle peuvent amener des contradictions dans les données. Toute tâche d'extension d'une ontologie susceptible de produire des descriptions incohérentes (peut-être par l'extension d'une ontologie qui a généré un concept surcontraint).

Justification :
Le Web décentralisé permet à chacun de dire ce qu'il veut. Par conséquent, des points de vue différents peuvent se contredire, ou même des informations fausses s'échanger. Pour éviter que les agents ne combinent des données incompatibles, ou ne prennent des données cohérentes pour les faire évoluer vers un état incohérent, il importe que les incohérences puissent être détectées automatiquement.

Gestion RDF(S) :
RDF et RDFS interdisent l'expression des incohérences.

3.5 L'équilibre entre expressivité et hiérarchisation

Le langage devrait être capable d'exprimer des connaissances très diverses, mais il devrait aussi fournir des méthodes efficaces pour raisonner sur elles. Comme ces deux conditions sont habituellement opposées, le but du langage d'ontologie Web est de trouver un équilibre qui permette d'exprimer les types de connaissances les plus importants.

Tâches à gérer :
Tous cas d'utilisation utilisant de grandes ontologies ou de grands ensembles de données et nécessitant la représentation de connaissances diverses.

Justification :
Il existe plus d'un milliard de pages sur le Web, et l'application possible du Web sémantique aux appareils et agents intégrés entraîne encore plus d'informations à gérer. Le langage d'ontologie Web devrait gérer les systèmes de raisonnement qui s'adaptent bien. Toutefois, le langage devrait également être aussi expressif que possible, afin que les utilisateurs puissent déclarer les types de connaissances qui sont importants pour leurs applications.

L'expressivité détermine ce qu'on peut dire avec le langage, et donc son pouvoir d'inférence et les capacités de raisonnement attendues des systèmes le mettant en œuvre complètement. Un langage expressif contient un riche ensemble de primitives qui permet de formaliser des connaissances très diverses. Au contraire, un langage trop peu expressif ne permettra pas suffisamment d'opportunités de raisonnement pour être d'une grande utilité, et n'apportera peut-être rien par rapport aux langages existants.

Gestion RDF(S) :
Le langage RDF est très extensible (hormis une syntaxe XML extrêmement verbeuse) mais pas très expressif.

3.6 La facilité d'utilisation

Le langage devrait avoir un seuil d'apprentissage bas et avoir des concepts et une signification clairs. Les concepts devraient être indépendants de la syntaxex.

Tâches à gérer :
Le balisage et la requête de documents Web sémantique par les utilisateurs, que ce soit directement ou indirectement.

Justification :
Bien qu'idéalement les utilisateurs soient pour la plupart isolés du langage par des applications frontales, la philosophie élémentaire du langage doit être naturelle et facilement assimilable. En outre, les utilisateurs précoces, les développeurs d'outils et les utilisateurs confirmés travailleront peut-être directement avec la syntaxe, et il est donc souhaitable qu'elle soit lisible (et rédigeable) par un humain.

Gestion RDF(S) :
Le langage RDF est assez facile à utiliser, mais le schéma RDF est plus complexe. La syntaxe semble une barrière infranchissable pour beaucoup.

3.7 La compatibilité avec les autres standards

Le langage devrait être compatible avec les autres standards courants du Web et de l'industrie. En particulier, avec le langage XML et les standards apparentés (tels que XML Schema et RDF), et potentiellement avec d'autres standards de modélisation tel que UML.

Tâches à gérer :
L'échange d'ontologies et de données dans un format normalisé.

Justification :
La compatibilité avec les autres standards facilite le développement d'outils et le déploiement du langage.

Gestion RDF(S) :
Le langage RDF a une syntaxe de sérialisation XML [RDF Syntax].

3.8 L'internationalisation

Le langage devrait gérer le développement d'ontologies multilingues, et potentiellement offrir différentes vues des ontologies selon les cultures.

Tâches à gérer :
Les tâches où la même ontologie sert pour plusieurs pays ou cultures.

Justification :
Le Web est un outil international. Le Web sémantique devrait faciliter les échanges d'idées et d'informations entre les différentes cultures et donc faciliter l'utilisation de mêmes ontologies par les membres de nations différentes.

Gestion RDF(S) :
Dans la mesure de la prise en compte de l'internationalisation par XML, de même pour RDF.

4 Les conditions requises

Les cas d'utilisation et les buts de conception motivent un certain nombre des conditions requises d'un langage d'ontologie Web. Le groupe de travail a aujourd'hui le sentiment que les conditions requises décrites ci-dessous sont essentielles au langage. Chaque condition, présentée brièvement, est motivée par un ou plusieurs des buts de conception décrits dans le chapitre précédent.

R1. Les ontologies comme ressources distinctes

Les ontologies doivent être des ressources ayant leur identificateur unique propre, tel qu'un appel d'adresse URI.

Motivation : Les ontologies partagées

R2. L'appel univoque des concepts par des adresses URI

Deux concepts dans des ontologies différentes doivent avoir des identificateurs absolus distincts (quoiqu'ils puissent avoir des identificateurs relatifs identiques). Il doit être possible d'identifier un concept de façon unique dans une ontologie avec un appel d'adresse URI.

Motivation : Les ontologies partagées, L'interopérabilité des ontologies

R3. L'extension explicite des ontologies

Les ontologies doivent être capable d'étendre explicitement d'autres ontologies pour réutiliser les concepts et ajouter de nouvelles classes et propriétés. L'extension d'ontologie est une relation transitive : si l'ontologie A étend l'ontologie B, et B étend C, alors l'ontologie A étend aussi implicitement l'ontologie C.

Motivation : Les ontologies partagées

R4. Le renvoi aux ontologies

Les ressources doivent être capable de renvoyer explicitement à des ontologies spécifiques, en indiquant précisément quels ensembles de définitions et de postulats ont été posés.

Motivation : Les ontologies partagées

R5. Les métadonnées d'ontologies

Il doit être possible de fournir des métadonnées pour chaque ontologie, tels que son auteur, sa date de publication, etc. Ces propriétés peuvent être empruntées ou non au jeu d'éléments Dublin Core.

Motivation : Les ontologies partagées

R6. Les informations de versionnage

Le langage doit fournir des méthodes afin de comparer et relier les versions différentes d'une même ontologie. Cela devrait inclure des méthodes pour relier les révisions aux versions précédentes, des déclarations explicites de rétrocompatibilité et une possibilité de contre-indiquer les identificateurs (c'est-à-dire les déclarer seulement disponibles pour des raisons de rétrocompatibilité, et qu'on ne devraient pas s'en servir dans les nouveaux documents/applications).

Motivation : L'évolution des ontologies

R7. Les primitives des définitions de classe

Le langage doit être capable d'exprimer des définitions de classe complexes. Cela inclut, mais sans s'y limiter, le sous-classage et les combinaisons booléennes d'expressions de classes (c'est-à-dire l'intersection, l'union et la complémentarité).

Motivation : L'équilibre entre expressivité et hiérarchisation, L'interopérabilité des ontologies, La détection des incohérences

R8. Les primitives des définitions de propriétés

Le langage doit être capable d'exprimer les définitions de propriétés. Cela inclut, mais sans s'y limiter, les sous-propriétés, les contraintes de domaine et d'image, et les propriétés de transitivité et de symétrie.

Motivation : L'équilibre entre expressivité et hiérarchisation, L'interopérabilité des ontologies, La détection des incohérences

R9. Les types de données

Le langage doit fournir un ensemble de types de données normalisés. Ces types de données peuvent être basés sur ceux du schéma XML [XML-SCHEMA2].

Motivation : La compatibilité avec les autres standards, La facilité d'utilisation

R10. L'équivalence des classes et des propriétés

Le langage doit inclure des méthodes pour déclarer que deux classes ou propriétés sont équivalentes.

Motivation : L'interopérabilité des ontologies

R11. L'équivalence des individus

Le langage doit inclure des méthodes pour déclarer que des couples d'identificateurs représentent le même individu (remarquez que, conformément à la terminologie employée dans les autres documents OWL, un individu désigne ici toute instance d'une classe OWL et pas forcément une personne). À cause de la nature répartie du Web, il est probable qu'un même individu puisse recevoir des identificateurs différents. L'utilisation d'une adresse URL standard ne résoud pas ce problème car certains individus peuvent avoir plusieurs adresses URL, comme une personne peut avoir des pages Web ou des adresses électroniques personnelles et professionnelles.

Motivation : L'interopérabilité des ontologies

R12. L'association d'informations aux déclarations

Le langage doit fournir une méthode pour étiqueter les déclarations avec d'autres informations, tels que source, estampille, degré de confiance, etc. Le langage n'a pas besoin de fournir un ensemble de propriétés standard pour cet usage, mais devrait plutôt fournir un mécanisme général permettant aux utilisateurs d'associer ces informations. La réification RDF est une voie possible pour satisfaire à cette condition, quoique cette caractéristique soit quelque peu controversée.

Motivation : Les ontologies partagées, L'interopérabilité des ontologies

R13. Les classes comme instances

Le langage doit offrir la possibilité de traiter les classes comme des instances. Parce que souvent le même concept peut être assimilé à une classe ou à un individu, selon le point de vue de l'utilisateur. Par exemple, dans une ontologie biologique, la classe Orang-outan peut contenir des animaux individuels comme instances. Par contre, la classe Orang-outan peut elle-même être une instance de la classe Espèces. Remarquez que Orang-outan n'est pas une sous-classe de Espèces, car alors cela voudrait dire que chaque instance de Orang-outan (un animal) est une instance de Espèces.

Motivation : L'interopérabilité des ontologies

R14. Les contraintes de cardinalité

Le langage doit gérer les restrictions de cardinalité définies sur les propriétés. Ces restrictions fixent le nombres minimaux et maximaux d'individus que la propriété en question peut relier à un seul individu.

Motivation : L'équilibre entre expressivité et hiérarchisation, La détection des incohérences

R15. La syntaxe XML

Le langage devrait avoir une syntaxe de sérialisation XML. Le langage XML est largement répandu dans l'industrie et beaucoup d'outils de traitement XML ont été développés. Si le langage d'ontologie Web a une syntaxe XML, ces outils peuvent alors être étendus et réutilisés.

Motivation : La compatibilité avec les autres standards

R16. Les étiquettes affichables à l'utilisateur

Le langage devrait gérer la définition de plusieurs étiquettes de remplacement, affichables à l'utilisateur, des ressources indiquées par une ontologie. Cela peut servir, par exemple, à voir l'ontologie dans des langues différentes.

Motivation : L'internationalisation, La facilité d'utilisation

R17. La gestion d'un modèle de caractères

Le langage devrait gérer l'utilisation de jeux de caractères multilingues.

Motivation : L'internationalisation, La compatibilité avec les autres standards

R18. La gestion de l'unicité des chaînes Unicode

Dans certains codages de caractères, par exemple, les codages basés sur Unicode, deux séquences de caractères différentes peuvent parfois sembler identiques, et beaucoup d'utilisateurs penseront qu'elles sont égales. Un exemple serait l'utilisation d'une forme précomposée (un seul caractère c cédille ç) comparée à celle d'une forme décomposée (un caractère c suivi par un caractère cédille). Puisque le groupe de travail I18N du W3C a décidé que l'approche habituelle pour résoudre ce problème est la normalisation uniforme précoce (dans la forme C normale Unicode), toute autre solution devra être justifiée.

Motivation : L'internationalisation, La compatibilité avec les autres standards

5 Les objectifs

Outre l'ensemble de caractéristiques qui devraient se trouver dans le langage (comme défini dans le chapitre précédent), il existe d'autres caractéristiques qui seraient utiles dans beaucoup de cas d'utilisation. Ces fonctionnalités seront traitées par le groupe de travail si possible, mais il peut estimer qu'il y a de bonnes raisons de les exclure du langage, ou d'en laisser le développement à un groupe de travail ultérieur. Quelques objectifs ne sont pas complètement définis et nécessitent donc d'autres éclaircissements pour leur prise en compte par le langage. Remarquez que l'ordre d'apparition des objectifs ci-dessous n'implique pas une priorité relative ou un degré de consensus.

O1. L'organisation en couches des caractéristiques du langage

Le langage peut gérer des niveaux de complexité différents pour la définition des ontologies. Les applications peuvent être conformes à une couche particulière sans mettre en œuvre le langage entier. Un guide d'identification des couches peut se baser sur une caractéristique trouvée dans différents types de bases de données et systèmes de base de connaissances.

Motivation : L'équilibre entre expressivité et hiérarchisation

O2. Les valeurs de propriétés par défaut

Le langage devrait gérer la définition de valeurs de propriétés par défaut. Ces valeurs pourraient être utilisées pour faire des inférences à propos de membres typiques de classes. Toutefois, les valeurs par défaut véritables (comme celles utilisées pour un raisonnement d'héritage réversible) ne sont pas monotoniques, ce qui peut se révéler problématique sur le Web où de nouvelles informations sont constamment découvertes ou ajoutées. En outre, il n'y a pas de méthode communément admise pour interpréter les valeurs par défaut. Une alternative est que la spécification du langage recommande des méthodes pour les utilisateurs afin qu'ils créent leurs propres mécanismes par défaut.

Motivation : L'équilibre entre expressivité et hiérarchisation

O3. La possibilité de déclarer des mondes clos

Du fait de la dimension et du rythme de variation du Web, l'hypothèse du monde clos (selon laquelle tout ce qui ne peut pas être inféré est supposé faux) ne convient pas. Cependant, il existe beaucoup de situations où une information de monde clos serait utile. Le langage doit donc être capable de déclarer une ontologie donnée à considérer comme complète. Des inférences supplémentaires tirées de cette ontologie seraient alors sanctionnées. La sémantique exacte d'une telle déclaration (et de l'ensemble d'inférences correspondant) reste à définir, mais des exemples pourraient l'inclure, en supposant des informations de propriétés complètes à propos des individus, en supposant l'intégralité classe-sujets et en supposant l'exhaustivité des sous-classes.

Motivation : Les ontologies partagées, La détection des incohérences

O4. Les contraintes d'image sur les types de données

Le langage devrait offrir la possibilité de définir des gammes de valeurs des propriétés. Ce mécanisme peut s'inspirer des types de données du schéma XML [XML-SCHEMA2].

Motivation : La détection des incohérences

O5. Les propriétés chaînées

Le langage peut gérer la composition de propriétés dans les déclarations à propos des classes et des propriétés. Un exemple de composition de propriétés serait l'assertion selon laquelle une propriété appelée oncleDe est identique à la composition des propriétés pèreDe et frèreDe.

Motivation : L'équilibre entre expressivité et hiérarchisation

O6. La procédure de décision effective

Le langage devrait être décidable.

Motivation : L'équilibre entre expressivité et hiérarchisation

O7. Le renvoi à des portions d'ontologies

Le langage devrait offrir la possibilité de renvoyer sur des portions d'une ontologie, ainsi que le renvoi à l'ontologie entière. Toutefois, on ne sait pas quelle granularité utiliser ici. Les options possibles sont les suivantes : choisir un sous-ensemble des concepts avec leurs définitions entières ou bien choisir des morceaux de définitions individuelles. Remarquez qu'emprunter des définitions partielles de concepts entraîne de résoudre les problèmes d'interopérabilité potentiels susceptibles de se produire, puisque des applications différentes utiliseront le même identificateur pour signifier des choses différentes.

Motivation : Les ontologies partagées

O8. Un mécanisme de vues

Le langage devrait offrir la possibilité de créer des vues d'une ontologie, dans lesquelles on peut définir des sous-ensembles d'ontologie ou assigner des noms de remplacement aux concepts. Cela est particulièrement utile pour développer des versions multiculturelles d'une ontologie. Remarquez que cette condition peut être satisfaite en ayant plusieurs ontologies et en utilisant un mécanisme de correspondance d'ontologies.

Motivation : L'internationalisation, L'interopérabilité des ontologies

O9. L'intégration de signatures numériques

La spécification des signatures numériques XML du W3C est un bloc d'assemblage important de l'échange entre propriétés non certifiées, qui importe dans beaucoup d'applications d'ontologie. Le langage d'ontologie Web devrait être conçu de façon à pouvoir utiliser directement les signatures XML.

Motivation : La compatibilité avec les autres standards

O10. Les primitives arithmétiques

Le langage devrait gérer l'utilisation de fonctions arirthmétiques. Elles peuvent servir aux traductions entre différentes unités de mesure.

Motivation : L'interopérabilité des ontologies

O11. La manipulation des chaînes

Le langage devrait gérer la concaténation de chaînes et un filtrage simple. Ces caractéristiques peuvent être utilisées pour établir une interopérabilité entre les ontologies traitant des informations complexes comme une seule chaîne formatée et celles ayant des propriétés distinctes pour chaque composant. Par exemple, une ontologie peut représenter une adresse de courrier électronique par une seule chaîne, tandis qu'une autre peut la diviser en deux chaînes, une pour le nom d'utilisateur et une pour le nom du serveur. Pour intégrer les deux ontologies, il faudrait définir que la concaténation du nom de l'utilisateur, du caractère perluète @ et du nom du serveur équivaut à la seule valeur utilisée par la première ontologie.

Motivation : L'interopérabilité des ontologies

O12. L'agrégation et le regroupement

Le langage devrait offrir la possibilité d'agréger les informations de façon similaire à la clause GROUP BY du langage SQL. Il devrait aussi permettre les dénombrements, les sommes et les autres opérations à effectuer pour chaque groupe. Cela permettrait une interopérabilité entre des ontologies représentant des informations à différents niveaux de granularité et, par exemple, pourrait relier des choses comme les totaux des catégories d'un budget aux montants des articles des lignes du budget, ou encore le nombre du personnel aux données individuelles des employés.

Motivation : L'interopérabilité des ontologies

O13. L'attachement procédural

Le langage devrait gérer l'utilisation d'un code exécutable pour évaluer des critères complexes. Les attachements procéduraux étendent significativement l'expressivité du langage mais ne sont pas adaptés à la sémantique formelle. Un mécanisme d'attachement procédural pour ontologies Web devrait indiquer comment trouver et exécuter la procédure. Un langage candidat potentiel pourrait être Java, que est déjà bien adapté au partage intraplateforme sur le Web.

Motivation : L'interopérabilité des ontologies

O14. Les présomption d'unicité des noms locaux

En général, le langage ne fera pas de présomption d'unicité des noms. À savoir, les identificateurs distincts ne sont pas censés se rapporter à des individus différents (cf. la condition R11). Toutefois, la présomption d'unicité des noms pourrait être utile dans beaucoup d'applications. Les utilisateurs devraient avoir une option pour indiquer que tous les noms d'un espace de nommage particulier désignent des individus distincts

Motivation : La détection des incohérences

O15. Les types de données complexes

Le langage devrait gérer la définition et l'utilisation de types de données complexes/structurés. On peut les utiliser pour définir des dates, des couples de coordonnées, des adresses, etc.

Motivation : La compatibilité avec les autres standards, La facilité d'utilisation


Références

[DWM]
Industrial Strength Ontology Management, Aseem Das, Wei Wu et Deborah L. McGuinness. In Isabel Cruz, Stefan Decker, Jerome Euzenat et Deborah L. McGuinness, rédacteurs. The Emerging Semantic Web. IOS Press, 2002. http://www.ksl.stanford.edu/people/dlm/papers/ontologyBuilderVerticalNet-abstract.html
[Hef]
Towards the Semantic Web: Knowledge Representation in a Dynamic, Distributed Environment, Jeff Heflin. Ph.D. Thèse, University of Maryland, College Park. 2001. http://www.cse.lehigh.edu/~heflin/pubs/#heflin-thesis
[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 Syntax]
La spécicification de la syntaxe RDF/XML (révisée), 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/ .
[RDF Vocabulary]
Le langage de description du 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/ .
[XML]
Le langage de balisage extensible (XML 1.0 (deuxième édition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, rédacteurs, recommandation du W3C du 6 octobre 2000, http://www.w3.org/TR/2000/REC-xml-20001006
Dernière version disponible à http://www.w3.org/TR/REC-xml .
[XML-SCHEMA2]
Le schéma XML partie 2 : Les types de données, Paul V. Biron et 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/ .

Annexe A : Le journal des changements

Les changements survenus depuis la version de recommandation proposée sont listés en ordre chronologique inverse.

Remerciements

Raphael Volz et Jonathan Dale ont grandement contribué à la rédaction de ce document et ont été co-rédacteurs avec le rédacteur actuel des documents de travail initiaux. L'effort initial pour identifier les buts de conception et les conditions requises a été co-dirigé par Deborah McGuinness et le rédacteur. Certaines conditions fournies directement par le docteur McGuinness [DWM] sont fondées sur plus de dix ans d'expérience dans l'élaboration de systèmes à ontologies. D'autres conditions font partie de la thèse de doctorat du rédacteur portant sur la construction d'un prototype de système de Web sémantique [Hef]. Michael Smith a écrit une version préliminaire du chapitre L'administration d'un site Web d'entreprise.

Le contenu de 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 étaient les suivants : Yasser alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, 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, Ruediger Klein, Natasha Kravtsova, Ora Lassila, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, 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, Frederik Brysse, Francesco Iannuzzelli, Massimo Marchiori, Michael Sintek et John Yanosy.