Les jeux d'essais du langage d'ontologie Web OWL

Recommandation du W3C du 10 février 2004

Cette version :: http://www.w3.org/TR/2004/REC-owl-test-20040210/
Dernière version :: http://www.w3.org/TR/owl-test/
Version précédente :: http://www.w3.org/TR/2003/PR-owl-test-20031215/
Rédacteurs :: Jeremy J. Carroll, HP <jjc@hpl.hp.com>; Jos De Roo, AGFA,<jos.deroo@agfa.com>

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

Cette version normative est un document composé. Les versions non normatives, constituées de fichiers HTML seuls, sont disponibles en trois tailles : moyenne, large, et extra large. Les tests de ce document sont également disponibles dans les formats non normatifs suivants : archive zip des tests approuvés, le site de test sur le web.

Cf. également 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.

Résumé

Ce document contient et présente les jeux d'essais du langage d'ontologie Web (OWL) approuvés par le groupe de travail Ontologie Web. Beaucoup de jeux d'essais illustrent l'utilisation correcte du langage d'ontologie Web OWL et la signification formelle de ses structures. D'autres jeux d'essais illustrent la résolution des problèmes étudiés par le groupe de travail. On définit la conformité des documents OWL et des vérificateurs de document OWL.

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 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.

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

En accompagnement de la définition du langage d'ontologie Web (OWL), le groupe de travail Ontologie Web fournit un ensemble de jeux d'essais, présentés dans ce document. Ces jeux d'essais fournissent des exemples et des éclaircissements concernant la définition normative du langage OWL, décrit dans le document [OWL Semantics and Abstract Syntax], dont le présent document est subsidiaire.

Ce document est un composant de la description du langage d'ontologie Web OWL développé par le groupe de travail Ontologie Web du W3C. Le chapitre traitant de la cartographie du document [OWL Overview] décrit les différents composants et comment ils s'organisent.

Ce document décrit les divers types de tests utilisés et le format dans lequel ces tests se présentent. L'ensemble de tests est également proposé dans d'autres formats. Ils sont conçus pour les développeurs OWL dans le cadre de tests automatisés, éventuellement comme partie d'un processus de développement dirigé par des tests, tel que l'Extreme Programming [XP]. Le format des fichiers Manifest utilisés dans ces autres formats est décrit.

Le processus de création et d'approbation de ces tests est également décrit dans les annexes non normatives.

1.1. La conformité et sa portée

Toutefois, les jeux d'essais ne constituent pas une suite de tests de conformité du langage OWL, car ils sont muets concernant plusieurs problèmes importants. Ce document ne saurait être considéré comme une définition complète du langage OWL.

Les tests illustrent les résolutions de problème ainsi que l'utilisation et la signification des termes dans l'espace de nommage OWL.

D'autres tests divers existent : certains survenant dans la littérature et dans les systèmes préexistants, d'autres servant à montrer la difficulté de la mise en œuvre complète du langage OWL Full.

2. Les produits délivrables (normatif)

Remarque : On peut trouver d'autres fichiers qui ne font pas partie des produits délivrables en aval de l'adresse URL du site.

2.1. Le statut normatif

Seuls sont normatifs parmi les produits délivrables les tests inclus dans ce document. Tous les autres produits délivrables sont informatifs. En outre, le document de la recommandation est informatif à l'exception des déclarations de conformité, des données de test (définies dans RDF/XML [RDF Syntax]) et de la documentation justificative.

2.2. Les tests à crédit supplémentaire

Le groupe de travail Ontologie Web a vu une expérience de mise en œuvre adéquate pour la plupart des tests dans ce document. Toutefois, certains sont particulièrement difficiles à mettre en œuvre efficacement. Ils sont marqués comme tests à crédit supplémentaire. Ces tests indiquent la sémantique OWL mais ils peuvent utiliser des caractéristiques dont la mise en œuvre n'est pas suffisamment répandue pour fournir une bonne interopérabilité.

Un cas général de tests à crédit supplémentaire est celui selon lequel tous les tests de non-inférence et de cohérence OWL Full sont des tests à crédit supplémentaire. Pour la raison que les mises en œuvre OWL Full habituelles peuvent prouver les inférences mais pas les non-inférences.

Les tests à crédit supplémentaire sont étiquetés EC au sein de ce document et ont le statut EXTRACREDIT dans les fichiers Manifest.

Le nom indique que l'on n'attend pas d'une mise en œuvre qu'elle passe ces tests avec succès, par contre celle qui y parvient y gagnera un crédit supplémentaire.

3. Les types de tests (normatif)

Chaque test se compose d'un ou de plusieurs documents RDF/XML et d'un fichier Manifest. Les tests d'un document indiquent une propriété de ce document lorsqu'il est interprété comme une base de connaissances OWL. Les tests de deux documents (ou plus) indiquent une relation entre les documents lorsqu'ils sont interprétés comme des bases de connaissances OWL.

Le fichier Manifest se nomme ManifestNNN.rdf (où NNN représente le numéro du test). Il contient des métadonnées (dans RDF) indiquant le type du test et décrivant le test.

Les métadonnées indiquent également le niveau de langage approprié de chaque test, et de chaque document dans chaque test. Pour chaque document RDF/XML, un niveau de langage est indiqué, à savoir OWL Lite, OWL DL ou OWL Full, d'après les règles syntaxiques définies dans le document [OWL Semantics and Abstract Syntax]. Pour les tests sémantiques, on indique un ou deux niveaux de langage. Si on mentionne le niveau de langage OWL Full pour un test sémantique, alors le test a lieu conformément à la sémantique du modèle théorique compatible avec RDF définie dans [OWL Semantics and Abstract Syntax]. Si on mentionne le niveau de langage OWL Lite ou OWL DL pour un test sémantique, alors le test a lieu conformément à la sémantique du modèle théorique direct, décrite dans [OWL Semantics and Abstract Syntax]. Si on mentionne le niveau de langage OWL Lite pour un test sémantique, alors le test n'utilise que des caractéristiques propres au sous-langage OWL Lite.

3.1. Les tests d'utilisation incorrecte de l'espace de nommage OWL

Ces tests utilisent un seul document nommé badNNN.rdf. Ce document contient une utilisation de l'espace de nommage OWL dont le nom local n'est pas défini par la recommandation OWL. Un vérificateur de syntaxe OWL devrait produire une mise en garde.

Remarque : Ces tests sont destinés à faciliter la migration depuis le langage DAML+OIL [DAML+OIL], les noms locaux choisis sont définis en effet dans l'espace de nommage DAML+OIL.

3.2. Les tests d'inférence

Ces tests utilisent deux documents : l'un nommé premisesNNN.rdf, l'autre conclusionsNNN.rdf. Les conclusions sont inférées par les prémisses. On définit une telle inférence avec la sémantique OWL [OWL Semantics and Abstract Syntax] (cf. également l'inférence dans OWL Full).

3.3. Les tests de non-inférence

Ces tests utilisent deux documents : l'un nommé premisesNNN.rdf, l'autre nonconclusionsNNN.rdf. Les non-conclusions ne sont pas inférées par les prémisses. On définit une telle inférence avec la sémantique OWL [OWL Semantics and Abstract Syntax] (cf. également l'inférence dans OWL Full).

3.4. Les tests de vérité

Ces tests utilisent un document nommé conclusionsNNN.rdf. Les conclusions découlent de la sémantique OWL [OWL Semantics and Abstract Syntax]. Ces tests sont des cas particuliers de tests d'inférence où les prémisses sont vides.

3.5. Le langage OWL des tests OWL

Ces tests utilisent un seul document, nommé conclusionsNNN.rdf. Ce sont des cas particuliers de tests de vérité. Les conclusions découlent de la sémantique OWL Full [OWL Semantics and Abstract Syntax]. Ces tests servent à illustrer comment utiliser OWL Full pour décrire ses propres propriétés et classes.

3.6. Les tests de cohérence

3.7. Les tests d'incohérence

3.8. Les tests d'inférence des importations

Ces tests utilisent plus de deux documents : l'un se nomme premisesNNN.rdf, un autre se nomme conclusionsNNN.rdf et les autres ont des noms tels que supportNNN-A.rdf. Les documents support se trouvent dans la clotûre des importations du document des prémisses. Les conclusions sont inférées par la clotûre des importations des prémisses. On définit une telle inférence avec la sémantique OWL [OWL Semantics and Abstract Syntax] (cf. également l'inférence dans OWL Full).

3.9. Les tests de niveau d'importation

Ces tests utilisent deux documents : l'un nommé importsNNN.rdf, l'autre nommé mainNNN.rdf. Ces tests indique l'interaction entre la structure owl:imports et les niveaux de sous-langage du document principal (N.d.T. main).

4. La conformité (normatif)

4.1. La conformité du document

4.1.1. La conformité syntaxique

4.1.2. La conformité sémantique

4.2. La conformité du vérificateur de document

Ce chapitre utilisent les mots-clés DOI(VEN)T, NE DOI(VEN)T PAS, DEVRAI(EN)T et PEU(VEN)T selon leur définition dans le document [RFC 2119].

4.2.1. Le vérificateur de syntaxe

Un vérificateur de syntaxe OWL reçoit un document en entrée et retourne l'un des mots suivants : Lite, DL, Full ou Other.

En outre, un vérificateur de syntaxe OWL DEVRAIT produire une mise en garde si le graphe RDF [RDF Concepts] correspondant au document utilise des appels d'adresses URI préfixés par http://www.w3.org/2002/07/owl#, à l'exception de ceux trouvés dans le schéma RDF de OWL [RDF Schema for OWL].

Un vérificateur de syntaxe OWL DEVRAIT signaler les erreurs de réseau survenant pendant le calcul de la clotûre des importations.

4.2.2. Le vérificateur de cohérence

Un vérificateur de cohérence OWL reçoit un document en entrée et retourne l'un des mots suivants : Consistent, Inconsistent ou Unknown.

Un vérificateur de cohérence OWL DEVRAIT signaler les erreurs de réseau survenant pendant le calcul de la clotûre des importations.

Un vérificateur de cohérence OWL DOIT être logique : il ne doit retourner Consistent que si le document en entrée est cohérent et, inversement, retourner Inconsistent que si le document en entrée est incohérent par rapport à l'application de type de donnée du vérificateur.

Un vérificateur de cohérence OWL est complet et terminant, si, avec des ressources suffisantes (néanmoins finies, par exemple, des cycles de traitement et de la mémoire) et sans erreur de réseau, il retourne toujours les mots-clés Consistent ou bien Inconsistent. Il est démontré qu'il est possible de construire un vérificateur de cohérence complet et terminant pour OWL Lite et OWL DL (les langages étant décidables), et que cela ne l'est pas pour OWL Full (le langage étant indécidable) [Practical Reasoning]).

Un vérificateur de cohérence OWL NE DEVRAIT PAS retourner le mot-clé Unknown. Quoique nécessaire parfois, il ne représente pas une réponse souhaitable.

5. Le test d'une mise en œuvre OWL (informatif)

5.1. Les vérificateurs de syntaxe OWL

5.2. Le vérificateur de cohérence OWL

On peut tester un vérificateur de cohérence OWL avec les tests de cohérence et d'incohérence appropriés. Ces tests sont ceux appropriés à un niveau et dont la gestion des types de données par le vérificateur est appropriée. Le niveau du test indique la théorie sémantique utilisée, qui peut différer de celle du niveau du fichier. Par exemple, le test Thing-004 contient un fichier OWL DL qui est cohérent comme test de cohérence OWL DL mais incohérent comme test de cohérence OWL Full.

Les tests d'incohérence correspondants doivent retourner le mot-clé Inconsistent ou bien Unknown.

Les contraintes précédentes s'appliquent également aux tests à crédit supplémentaire. Les vérificateurs de cohérence retournant la bonne réponse (c'est-à-dire pas Unknown) gagnent le crédit supplémentaire.

6. Les fichiers Manifest (informatif)

Le fichier Manifest suit le schéma RDF développé pour les jeux d'essais RDF [RDF Tests].

En particulier, chaque test a son propre fichier Manifest, et il est identifié par l'appel d'adresse URI formé à partir de l'adresse URL du fichier Manifest avec le fragment test.

Le préfixe otest est lié à l'espace de nommage http://www.w3.org/2002/03owlt/testOntology# et le préfixe rtest à http://www.w3.org/2000/10/rdf-tests/rdfcore/testSchema#.

Le nom de l'auteur original du test est décrit par une propriété dc:creator, cf. [Dublin Core].

Une description du test (avec un balisage XHTML [XHTML]) est donnée comme valeur de la propriété rtest:description.

Un problème, le cas échéant, pris dans la liste des problèmes OWL [OWL Issues], est la valeur d'une propriété rtest:issue.

Le cas échéant, on indique une caractéristique de langage appropriée, issue de l'espace de nommage OWL, comme valeur de la propriété otest:feature.

Les documents en entrée avec les données de test sont indiqués par la valeur de la propriété rtest:inputDocument ou bien par la valeur des deux propriétés rtest:premiseDocument et rtest:conclusionDocument. Les fichiers d'appoint des tests d'inférence d'importation, des tests de niveau d'importation et du test imports-002 apparaissent comme valeurs de la propriété otest:importedPremiseDocument.

Les niveaux de conformité associés à la fois aux fichiers et aux tests sont donnés par la propriété otest:level. La valeur de chaque document est l'une des suivantes : otest:Full, otest:DL, otest:Lite ou otest:Other. Chaque test est explicitement associé à un ou deux niveaux. S'il est associé à otest:Lite, alors il convient implicitement pour otest:DL.

Les types de données utilisés dans le test sont donnés par la propriété otest:usedDatatype ou par l'une de ses sous-propriétés : otest:supportedDatatype ou otest:notSupportedDatatype. Elles indiquent que le test est seulement valide si le type de donnée est respectivement géré ou pas par l'application de type de donnée utilisée.

La propriété rtest:status du test reflète le processus décrit dans l'annexe A. Il indique l'un des niveaux suivants :

7. Les tests OWL (normatif)

7.3. Les autres tests de logique de description

Ces tests proviennent de la littérature consacrée (par exemple, les tests de [Heinsohn et al.]) ou de suites de tests contribuées par Network Inference ou développées par le groupe de travail.

Le préfixe d'espace de nommage supplémentaire suivant est utilisé dans ce chapitre :

Dans la syntaxe N3 [N3] utilisée pour les déclarations d'espace de nommage, il apparaît de cette façon ::

7.4. Les tests divers

Ces tests ne trouvent place dans aucune autre catégorie. Quelques tests proviennent du guide OWL [OWL Guide]. D'autres reflètent les divers aspects de OWL, qui n'étaient pas des problèmes formels traités par le groupe de travail.

7.5. Le crédit supplémentaire

On n'espère pas qu'une mise en œuvre réussisse à passer les tests dans cette section ; celle qui y parvient augmentera son crédit.

Le but est d'illustrer la sémantique du langage OWL, notamment le langage OWL Full, telle que définie dans le document [OWL Semantics and Abstract Syntax], l'objectif particulier étant de montrer qu'il est possible d'affirmer des choses dont on ne peut pas raisonnablement attendre d'une mise en œuvre qu'elle les comprennent entièrement.

A. La création, l'approbation et la modification des tests (historique et informatif)

Cette annexe décrit le processus suivi pour le développement de cette suite de tests.

A.1. La création

Les tests sont créés par les membres du groupe de travail. Un éditeur de tests (optionnel) est fourni pour cela. Les tests sont ensuite placés dans le répertoire approprié du site Web de test, avec un accès CVS au serveur CVS du W3C [W3C CVS].

À leur création, les tests reçoivent le statut PROPOSED. L'auteur du test crée un fichier Manifest dans le répertoire du nouveau test, qui identifie :

A.2. L'approbation

À la discrétion du président [du groupe de travail], les tests individuels ou les groupes de tests sont soumis au groupe de travail lors de la téléconférence hebdomadaire ou lors d'une réunion face-à-face.

Les tests sont approuvés par décision du groupe de travail avec un statut APPROVED ou EXTRACREDIT. Le groupe de travail peut prendre en compte les verdicts favorables aux tests ou les rapports de mise en œuvre, ainsi que d'autres facteurs.

Si le groupe de travail approuve le test, il est alors inclus dans le document de jeux d'essais.

Le groupe de travail peut rejeter le test, auquel cas son statut change pour REJECTED. Cela n'indique pas que le réciproque du test a été acceptée. Il peut y avoir des raisons de style ou d'autres raisons au rejet d'un test techniquement correct.

Le groupe de travail a tout pouvoir pour approuver ou rejeter les tests, indépendamment de leur conformité à ce processus ou aux versions préliminaires du langage OWL.

À la lumière de nouvelles informations et à la discrétion du président, le groupe de travail peut revoir une décision précédente vis-à-vis de n'importe quel jeu d'essais. Un statut OBSOLETED peut être établi dès que le test n'est plus approprié.

A.3. La modification

Les rédacteurs peuvent effectuer des corrections sur les tests approuvés ou proposés. Elles comprennent :

B. Les préférences de style (informatif)

Les règles de style suivantes ont la préférence. Aucune n'est obligatoire mais les créateurs de tests devraient avoir à l'esprit que le respect de ces règles facilitera le gain du consensus du groupe de travail.

B.1. L'utilisation de RDF/XML

B.2. L'utilisation de l'attribut xml:base

Les fichiers de test et Manifest devraient avoir un attribut xml:base sur l'élément document. Il devrait indiquer l'adresse URL préférée du document, où on peut effectivement le récupérer.

B.3. L'utilisation du suffixe .rdf

Les fichiers de test et Manifest devraient utiliser le suffixe .rdf. Pas les adresses URI. L'adresse URL des déclarations xml:base n'a pas de suffixe.

B.4. L'utilisation des domaines example

Toutes les adresses URL dans les fichiers de test et Manifest devraient être celles de ressources récupérables sur le Web, sauf celles utilisant des noms de domaine example comme pénultième composant (par exemple, http://www.example.org/ontology#prop).

B.5. Les droits d'auteurs

Les déclarations de droits d'auteurs suivantes devraient figurer dans chaque fichier de test sous la forme d'un commentaire XML :

B.6. La description

La description devrait figurer sous la forme d'un commentaire XML dans chaque fichier de test et être incorporée comme contenu RDF dans le fichier Manifest.

B.7. La structure du répertoire

Les tests concernant principalement une certaine propriété ou classe OWL devraient être placés dans un répertoire nommé d'après le nom local de cette propriété ou classe.

Sinon les tests concernant un problème devraient être placés dans un répertoire nommé, par exemple I3.4, et dont le numéro provient de la liste de problèmes OWL [OWL Issues].

B.8. Le numérotage des tests

Chaque répertoire devrait contenir des tests numérotés successivement en commençant à 001.

Chaque fichier dans un test devrait avoir le numéro du test à la fin de son nom, avant le suffixe.

Remarque : Les numéros de tests approuvés dans un répertoire ne se suivront pas forcément.

Remarque : Il diffère des conventions de numérotage des jeux d'essais de RDF Core.

B.9. Le format des triplets des données de test

Les tests approuvés et proposés se présentent en même temps dans le langage RDF/XML, qui est leur forme normative, et dans un format de triplets. C'est une liste de triplets sujet, prédicat, objet, similaire au format des N-triplets décrit dans le document [RDF Tests]. Les autres conventions suivantes sont utilisées :

Dans la syntaxe N3 [N3] utilisée dans les déclarations d'espaces de nommage, les quatre premiers apparaissent comme suit :

D'autres espaces de nommage sont listés explicitement avec les données de test.

D. Remerciements (informatif)

Les personnes suivantes ont fournis les tests de ce document : Sean Bechhofer, Ian Horrocks, Peter F. Patel-Schneider, Jeff Heflin, Dan Connolly, les rédacteurs du guide, Jonathan Borden, Charles White, Martin Dürst, Masayasu Ishikawa, Jim Hendler, Herman ter Horst, Dave Reynolds, et les rédacteurs.

Ian Horrocks a contribué au chapitre de ce document traitant de la conformité.

Sandro Hawke a créé la page des résultats de tests, qui a beaucoup servi dans la phase de recommandation candidate.

Nous remercions les personnes qui ont fait des rapports de test et d'autres commentaires dans la phase de recommandation candidate : Ken Baclawski, Sean Bechhofer, Ian Dickinson, Michael Grove, Sandro Hawke, Ian Horrocks, Minsu Jang, Gary Ng, Mehrdad Omidvari, Bijan Parsia, Peter F. Patel-Schneider, Dave Reynolds, Rob Shearer, Evren Sirin, Charles White et Youyong Zou. Nous remercions également les nombreuses autres personnnes qui ont aidé à développer les systèmes pour produire ces rapports.

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, 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, Rüdiger 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.

E. Les changements depuis la recommandation proposée

On utilise le terme application de type de donnée au lieu de théorie de type de donnée, pour la cohérence avec les sémantiques OWL et RDF. Cela à plusieurs reprises, y compris dans les descriptions des tests miscellaneous-204, miscellaneous-205 et I5.8-012. Ce dernier a nécessité de ce fait des récritures mineures.

Ajouté un paragraphe vers la fin du chapitre 4.2.2, en précisant que l'application de type de donnée d'un vérificateur de cohérence OWL Full (qui est une application de type de donnée de la sémantique RDF) DOIT contenir une entrée pour le type rdf:XMLLiteral. Cela rend explicite une condition déjà implicite dans le document de la recommandation proposée. Précisé également que l'application de type de donnée dans la définition d'un document cohérent OWL Full est comme celle définie dans la sémantique RDF, en changeant le lien.

Par conséquent, rendu explicite la référence de la sémantique RDF (celle-ci était implicite dans la recommandation proposée des jeux d'essais OWL).

Corrigé une erreur dans les métadonnées du test miscellaneous-205, qui ne s'applique pas à OWL Full, puisque le type rdf:XMLLiteral est obligatoire pour OWL Full. Ce changement est visible du fait de la suppression du mot Full dans l'en-tête du test.

Cette erreur dans les recommandations candidate et proposée des jeux d'essais OWL semble avoir été relativement bénigne :