Jeux d'essais RDF

Recommandation du W3C du 10 février 2004

Cette version :

http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/

Dernière version :

http://www.w3.org/TR/rdf-testcases/

Version précédente :

http://www.w3.org/TR/2003/PR-rdf-testcases-20031215/

Rédacteurs :

Jan Grant, (ILRT, University of Bristol)

Dave Beckett, (ILRT, University of Bristol)

Rédacteur de la série :

Brian McBride (Hewlett Packard Labs)

Veuillez consulter la page des errata →vf de ce document, laquelle peut contenir des corrections normatives.

Cf. également d'éventuelles traductions.

Copyright © 2004 W3C^™ (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

Résumé

Ce document décrit le module livrable (deliverable) des jeux d'essais (test cases) RDF du groupe de travail RDF Core, comme défini dans la charte du groupe de travail.

Table des matières

1. Introduction

Parmi les livrables (deliverables) spécifiés dans la charte du groupe de travail RDF Core, il y a « un ensemble de jeux d'essais exploitables en machine (machine-processable) correspondant aux problèmes techniques traités par le groupe de travail ». Ce document décrit les jeux d'essais qui satisfont à ce livrable mais ne contient pas les jeux d'essais en question. Ceux-ci sont disponibles à http://www.w3.org/2000/10/rdf-tests/rdfcore/.

Le groupe d'intérêt RDF et d'autres membres de la communauté RDF ont identifié des problèmes ou ambiguïtés dans la spécification [RDFMS] et la recommandation candidate [RDF-SCHEMA]. Ces problèmes ont été rassemblés et catégorisés dans le document de suivi des problèmes du groupe de travail RDF Core. Le groupe de travail RDF Core utilise cette liste de problèmes pour guider ses travaux. La liste des problèmes est un document de travail, réactualisé au fur et à mesure que de nouveaux problèmes sont identifiés. Sa mise à jour intervient lors des prises de décisions du groupe de travail, comme documenté à la section À l'attention des développeurs du document de suivi.

La spécification complète de RDF se compose de plusieurs documents :

• Initiation à RDF [RDF-PRIMER] ;
• Concepts et syntaxe abstraite RDF [RDF-CONCEPTS] ;
• Sémantique RDF [RDF-SEMANTICS] ;
• Syntaxe RDF/XML [RDF-SYNTAX] ;
• Langage de description de vocabulaire RDF 1.0 : RDF Schema [RDF-VOCABULARY] ;
• Jeux d'essais RDF (ce document).

1.1. Portée

Une suite de tests approfondis et complets pour RDF devrait couvrir toutes les règles édictées dans la grammaire formelle de RDF. Toutefois, la mission du groupe de travail n'est pas de livrer une telle suite de tests mais plutôt de créer des jeux d'essais pour les problèmes qu'il traite (le cas échéant). Même si le groupe de travail ne crée pas de jeux d'essais pour certaines règles de grammaire (par exemple, la règle [6.1]), si de tels jeux d'essais sont donnés au W3C, le consortium peut les ajouter à cet ensemble de jeux d'essais.

1.2. Errata RDF

L'errata RDF documente les erreurs connues dans [RDFMS]. Puisque les errata sont considérés comme des changements normatifs d'une spécification du W3C et que les décisions du groupe de travail ne sont pas normatives tant qu'une spécification n'est pas une recommandation du W3C, aucune des décisions prises par le groupe de travail RDF Core n'a été répercutée (à ce jour) dans l'errata.

2. Jeux d'essais

Le référentiel de jeux d'essais (test case repository) [REPOSITORY] renferme des sous-répertoires, chacun contenant les jeux d'essais dédiés à un seul problème. Chaque répertoire contient un fichier de manifeste (manifest file) décrivant les tests dans ce répertoire. Si le processus de suivi des problèmes RDF [ISSUES] est à la source du problème, le manifeste le mentionnera.

Le référentiel de jeux d'essais contient des fichiers ZIP de tous les jeux d'essais approuvés [APPROVED] ainsi qu'une archive ZIP de tous les jeux d'essais approuvés et non approuvés [FULLTESTS].

Le fichier Manifest [MANIFEST] contient un manifeste exploitable en machine (machine-readable) des jeux d'essais. Le format de ce fichier est décrit ci-dessous.

2.1. Organisation

Le fichier de manifeste [MANIFEST] contient une description exploitable en machine des jeux d'essais en RDF/XML. Des précautions ont été prises afin de s'assurer que ce fichier suive un format simple pour assister le traitement en machine des jeux d'essais.

Le fichier se compose d'un en-tête (header) simple [MANIFEST-HEAD], des descriptions individuelles des jeux d'essais et d'un bas de page de fermeture (closing footer) [MANIFEST-TAIL].

Les jeux d'essais se rangent dans les catégories suivantes :

Tests d'analyseur positifs (positive parser tests)

Ces tests sont constitués d'un ou de plusieurs documents d'entrée en RDF/XML comme corrigé dans [RDF-SYNTAX]. Le résultat attendu est défini à l'aide de la syntaxe N-Triples (section 3). Un analyseur est considéré comme passant le test s'il produit un graphe équivalent au graphe décrit par le document de sortie N-Triples, conformément à la définition d'équivalence de graphe donnée dans [RDF-CONCEPTS]. Lorsque le ou les documents d'entrée sont du RDF/XML légal et qu'une alerte peut être générée, le manifeste des tests l'indique.

<test:PositiveParserTest rdf:about="http://w3.example.org/test001">

   <test:issue rdf:resource="http://w3.example.org/rdf-tracking/#example1" />
   <test:status>APPROVED</test:status>
   <test:approval rdf:resource="http://rdfcore.example.org/archives/001.html" />
   <test:description>
    This is a simple positive parser test example.
   </test:description>

   <test:inputDocument>
      <test:RDF-XML-Document rdf:about="http://w3.example.org/test001.rdf" />
   </test:inputDocument>

   <test:outputDocument>
      <test:NT-Document rdf:about="http://w3.example.org/test001.nt" />
   </test:outputDocument>

   <test:warning>Some parsers may produce a warning when running this test</test:warning>

</test:PositiveParserTest>

Tests d'analyseur négatifs (negative parser tests)

Ces tests sont constitués d'un seul document d'entrée. Le document n'est pas du RDF/XML légal. Un analyseur est considéré comme passant le test s'il interprète correctement le document d'entrée comme étant erroné.

<test:NegativeParserTest rdf:about="http://w3.example.org/error001">

   <test:issue rdf:resource="http://w3.example.org/rdf-tracking/#example1" />
   <test:status>APPROVED</test:status>

   <test:inputDocument>
      <test:RDF-XML-Document rdf:about="http://w3.example.org/error001.rdf" />
   </test:inputDocument>

</test:NegativeParserTest>

Tests d'implication positifs

Ces tests sont indiqués par un ou plusieurs documents de prémisses (premise document), en RDF/XML ou N-Triples, avec un document d'une seule conclusion. En outre, les règles utilisées pour déterminer l'implication sont indiquées par des éléments <test:entailmentRules>. Si l'élément suivant est présent :

 <test:entailmentRules rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />

alors le test réussit si l'implication se vérifie conformément aux règles d'implication RDF (RDF-entailment), comme défini dans [RDF-SEMANTICS]. Si les deux éléments suivants sont présents :

<test:entailmentRules rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
<test:entailmentRules rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />

alors le test réussit si l'implication se vérifie conformément aux règles d'implication RDFS (RDFS-entailement), comme défini dans [RDF-SEMANTICS]. Pour les jeux d'essais utilisant une implication simple (simple entailment), on utilise le marqueur suivant :

<test:entailmentRules rdf:resource="http://www.w3.org/2000/10/rdf-tests/rdfcore/testSchema#simpleEntailment" />

<test:PositiveEntailmentTest rdf:about="http://w3.example.org/rdfs-domain-and-range/conjunction-test">

   <test:description>
    This test demonstrates the conjunctive nature of range and domain.
   </test:description>

   <test:entailmentRules rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
   <test:entailmentRules rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />

   <test:premiseDocument>
      <test:NT-Document rdf:about="http://w3.example.org/rdfs-domain-and-range/test001.nt" />
   </test:premiseDocument>

   <test:premiseDocument>
      <test:NT-Document rdf:about="http://w3.example.org/rdfs-domain-and-range/test002.nt" />
   </test:premiseDocument>

   <test:premiseDocument>
      <test:NT-Document rdf:about="http://w3.example.org/rdfs-domain-and-range/test003.nt" />
   </test:premiseDocument>

   <test:conclusionDocument>
      <test:NT-Document rdf:about="http://w3.example.org/rdfs-domain-and-range/test004.nt" />
   </test:conclusionDocument>

</test:PositiveEntailmentTest>

Conformément à la spécification [RDF-SEMANTICS], un document de prémisses qui contient une erreur sémantique par rapport à une contrainte imposée par les règles d'implication sélectionnées sera erroné (false) dans toute interprétation (et donc implique toute chose).

La prise en charge de ces situations est donnée par le format de manifeste en déclarant un pseudo-document de prémisses ou de conclusion comme suit :

   <test:conclusionDocument>
      <test:False-Document/>
   </test:conclusionDocument>

Par convention, un tel pseudo-document est dit ressortir faux sous toute interprétation.

Test d'implication négatifs

Ces tests sont indiqués en utilisant une structure similaire à celle des tests d'implication positifs, avec l'élément <test:NegativeEntailmentTest> employé à la place de <test:PositiveEntailmentTest>. Le test échoue si la conclusion peut être établie à partir des prémisses en utilisant les règles d'implication RDF ou RDFS. Le test est considéré comme étant passé lorsqu'on peut démontrer de manière formelle (conclusively) que la conclusion ne peut être établie ainsi. En pratique, le test peut être considéré comme étant passé lorsqu'une tentative assidue de faire échouer le test est incapable d'obtenir l'échec.

<test:NegativeEntailmentTest rdf:about="http://w3.example.org/statement-entailment/test001">

   <test:status>PENDING</test:status>
   <test:approval rdf:resource="http://rdfcore.example.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0476.html" />
   <test:description>
     RDF Core WG RESOLVED that a reified statement was a stating, not a statement.
     The following entailment does not, therefore, hold.
   </test:description>

   <test:entailmentRules rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#" />
   <test:entailmentRules rdf:resource="http://www.w3.org/2000/01/rdf-schema#" />

   <test:premiseDocument>
      <test:NT-Document rdf:about="http://w3.example.org/statement-entailment/test001a.nt" />
   </test:premiseDocument>

   <test:conclusionDocument>
      <test:NT-Document rdf:about="http://w3.example.org/statement-entailment/test001b.nt" />
   </test:conclusionDocument>

</test:NegativeEntailmentTest>

Tests d'implication avec type de données (datatype-aware entailment tests)

Les jeux d'essais d'implication peuvent en outre nécessiter une gestion des types de données. Une telle exigence est indiquée dans le manifeste par la présence de l'élément <test:entailmentRules> ci-dessous, suivi de zéro ou plus entrées <test:datatypeSupport>.

   <test:entailmentRules rdf:resource="http://www.w3.org/2000/10/rdf-tests/rdfcore/datatypes#" />
   <test:datatypeSupport rdf:resource="http://www.w3.org/2001/XMLSchema#integer" />
   <test:datatypeSupport rdf:resource="http://dt.example.org/datatype#foo" />

Pour les besoins de la suite de tests, si un jeu d'essais impose la gestion des types de données pour un ensemble de types de données { T, U, V, ... }, alors les trois points suivants du mécanisme sont nécessaires :

• pour tout littéral typé de la forme "aaa"^^<T>, où T est un type de données reconnu, il doit être possible de déterminer si aaa est une forme lexicale valide pour ce type de données, et ;
• pour deux littéraux typés de la forme "aaa"^^<T> et "bbb"^^<U>, avec aaa et bbb respectivement des formes lexicales valides des types de données reconnus T et U, il doit être possible de déterminer si ces deux littéraux dénotent la même valeur. (Notez qu'il n'est pas explicitement exigé de déterminer quelle est cette valeur.) ;
• pour tout littéral typé de la forme "aaa"^^<T>, où T est un type de données reconnu, et pour un type de données reconnu U, il doit être possible de déterminer si la valeur dénotée par le littéral appartient ou non à l'espace de valeurs de U. (Cette dernière condition est nécessaire pour permettre la vérification des conflits d'images (range clashes))). Enfin, ;
• Pour deux types de données T et U, il doit être possible de déterminer (éventuellement par simple décret) si T, considéré comme une classe, est une sous-classe de U, considéré comme une classe.

Tests divers

Cette entrée de manifeste sert à décrire les jeux d'essais qui ne tombent pas dans les catégories précédentes. Plusieurs fichiers peuvent lui être associés, indiqués dans des éléments <test:document>.

<test:MiscellaneousTest rdf:about="http://w3.example.org/misc001">

   <test:status>PENDING</test:status>
   <test:description>
     A serializer asked to output the graph described in the test001
     document should raise an exception since it cannot be described using
     RDF/XML.
   </test:description>

   <test:document>
      <test:NT-Document rdf:about="http://w3.example.org/nonserializable/test001.nt" />
   </test:document>

</test:MiscellaneousTest>

En outre, chaque description de jeu d'essais peut comporter les attributs communs suivants :

• L'élément <test:issue> contient un pointeur vers le problème associé dans le document de suivi du groupe de travail RDF Core. Il peut apparaître zéro fois ou plus.

  <test:issue rdf:resource="http://www.w3.org/2000/03/rdf-tracking/#rdfs-no-cycles-in-subClassOf" />
  

• L'élément <test:status>, si présent, indique le statut du test conformément au processus du groupe de travail RDF Core. Seules les descriptions de test avec le contenu suivant devraient être considérés comme étant approuvés par le groupe de travail.

  <test:status>APPROVED</test:status>
  

• L'élément <test:approval>, si présent, contient une référence aux minutes de la réunion du groupe de traval RDF Core où le statut du jeu d'essais aura changé en dernier.

   <test:approval rdf:resource="http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0476.html" />
  

• L'élément <test:discussion>, si présent, contient un pointeur vers une autre délibération autour de ce jeu d'essais ou du problème associé. Cet élément peut apparaître plusieurs fois.

   <test:discussion rdf:resource="http://rdfcore.example.org/" />
  

• L'élément <test:description>, si présent, contient un résumé intelligible (human-readable) du jeu d'essais.

  <test:description>
      Text describing the test case goes here.
  </test:description>
  

• L'élément <test:warning>, si présent, indique que le test peut générer un avertissement même s'il devait réussir. Le contenu de l'élément fournit une description intelligible de l'avertissement.

  <test:warning> Text describing the warning goes here. </test:warning>
  

2.2. Jeux d'essais approuvés

Les jeux d'essais du tableau suivant ont été approuvés.

2.3. Jeux d'essais non approuvés

Le référentiel de jeux d'essais contient des jeux d'essais non approuvés. Ceux-ci ne sont pas énumérés dans ce document mais une liste en est disponible à http://www.w3.org/2000/10/rdf-tests/rdfcore/allTestCases.html.

2.4. Exécution des jeux d'essais

Le format des manifestes de jeux d'essais a été choisi volontairement pour être une description déclarative simple des jeux d'essais. Les tests d'analyseur peuvent être exécutés conjointement à des outils simples tels que ntc [NTC]. Un analyseur devrait passer tous les tests d'analyseur positifs et rejeter tous les tests d'analyseur négatifs. Des outils tels que Euler [EULER] ont été utilisés pour éxécuter les tests d'implication.

En raison des règles des tests d'implication, on peut utiliser un jeu d'essai d'implication positif ou négatif avec un document de conclusion vide pour illustrer les contraintes sémantiques associées aux ensembles de règles d'implication.

Les jeux d'essais ont été créés pour illustrer la résolution de problèmes particuliers de la liste de suivi des problèmes RDF. Par conséquent, les résultats de jeu d'essais devraient toujours s'interpréter conjointement à la résolution du problème associé et à la description (le cas échéant) jointe au jeu d'essais dans le manifeste.

3. N-Triples

N-Triples est un format en texte ordinaire par ligne (line-based, plain text format) pour coder un graphe RDF. Il a été conçu comme un sous-ensemble fixe de N3 [N3] [N3-Primer], et on peut donc utiliser des outils N3 tels que cwm [CWM], n-triples2kif [N-TRIPLES2KIF] et Euler [EULER] pour le lire et le traiter. cwm peut sortir ce format lorsqu'on l'évoque par "cwm -ntriples".

Il est recommandé, sans obligation, de stocker le contenu N-Triples dans des fichiers avec le suffixe « .nt » pour le distinguer de N3.

Le type de média Internet, ou type MIME