RDF Test Cases

W3C Working Draft 10 October 2003

This Version:

http://www.w3.org/TR/2003/WD-rdf-testcases-20031010/

Latest Version:

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

Previous Version:

http://www.w3.org/TR/2003/WD-rdf-testcases-20030905/

Editors:

Jan Grant, (ILRT, University of Bristol)

Dave Beckett, (ILRT, University of Bristol)

Series editor:

Brian McBride (Hewlett Packard Labs)

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

---

Abstract

This document describes the RDF Test Cases deliverable for the RDF Core Working Group as defined in the Working Group's Charter.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a W3C Last Call Working Draft of the RDF Core Working Group and has been produced as part of the W3C Semantic Web Activity (Activity Statement).

Detailed changes from the previous 05 September 2003 working draft and the 23 January 2003 last call working draft are described in the Changes section.

This document is in the Last Call review period, which ends on 07 November 2003. This Last Call publication consolidates changes and editorial improvements undertaken in response to feedback received during the previous Last Call publication of the RDFCore specifications which began on 23 January 2003. A list of the Last Call issues addressed by the Working Group is also available. This document has been endorsed by the RDF Core Working Group.

This document is being released for review by W3C Members and other interested parties to encourage feedback and comments, especially with regard to how the changes made affect existing implementations and content.

In conformance with W3C policy requirements, known patent and IPR constraints associated with this Working Draft are detailed on the RDF Core Working Group Patent Disclosure page.

Comments on this document are invited and should be sent to the public mailing list www-rdf-comments@w3.org. An archive of comments is available at http://lists.w3.org/Archives/Public/www-rdf-comments/.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

Table of Contents

1. Introduction

One of the deliverables specified in Charter of the RDF Core Working Group is: a set of machine-processable test cases corresponding to technical issues addressed by the Working Group. This document describes the test cases that fulfill that deliverable but it does not contain the test cases themselves. The test cases are available at http://www.w3.org/2000/10/rdf-tests/rdfcore/.

The RDF Interest Group and other members of the RDF community have identified issues/ambiguities in the [RDFMS] Specification and the [RDF-SCHEMA] Candidate Recommendation. These issues have been collected and categorized in the RDF Core Working Group Issue Tracking document. The RDF Core Working Group uses this issue list to guide its work. The issues list is a working document; it is updated as new issues are identified. It is updated as the Working Group makes decisions as documented in the Attention Developers section of the document.

The complete specification of RDF consists of a number of documents:

• RDF Primer [RDF-PRIMER]
• RDF Concepts and Abstract Syntax [RDF-CONCEPTS]
• RDF Semantics [RDF-SEMANTICS]
• RDF/XML Syntax [RDF-SYNTAX]
• RDF Vocabulary Description Language 1.0: RDF Schema [RDF-VOCABULARY]
• RDF Test Cases (this document)

1.1. Scope

A comprehensive and complete test suite for RDF should cover all of the rules in the Formal Grammar for RDF. The Working Group, however, is not chartered to deliver such a test suite but rather to create test cases for the issues the Working Group addresses (when applicable). Although the Working Group will not create test cases for some grammar rules (e.g. rule [6.1]), if such test cases are donated to the W3C the Consortium may add such test cases to this set of test cases.

1.2. RDF Errata

The RDF Errata documents known errors in [RDFMS]. Since errata are considered normative changes to a W3C Specification and Working Group decisions are not normative until a specification is a W3C Recommendation, none of the decisions made by the RDF Core Working Group have (to date) been reflected in the errata.

2. Test Cases

The Test Case Repository [REPOSITORY] contains subdirectories, each containing test cases devoted to a single issue. Each directory contains a manifest file describing the tests in that directory. Where an issue originated with the RDF Issue Tracking process [ISSUES], the manifest will indicate this fact.

The Test Case Repository contains ZIP files of all Approved test cases [APPROVED] as well as a ZIP archive of all Approved and Not Approved test cases [FULLTESTS]

The Manifest file [MANIFEST] contains a machine-readable manifest of the test cases. The format of this file is described below.

2.1. Organization

The manifest file [MANIFEST] contains a machine-readable description of the test cases in RDF/XML. Care has been taken to ensure that this file follows a simple format to assist in machine-processing the test cases.

The file consists of a simple header [MANIFEST-HEAD], individual descriptions of the test cases, and a closing footer [MANIFEST-TAIL].

The test cases are divided into the following categories:

Positive Parser Tests

These tests consist of one (or more) input documents in RDF/XML as is revised in [RDF-SYNTAX]. The expected result is defined using the N-Triples syntax (Section 3). A parser is considered to pass the test if it produces a graph equivalent to the graph described by the N-triples output document, according to the definition of graph equivalence given in [RDF-CONCEPTS]. Where the input document(s) are legal RDF/XML, but a warning may be generated, this is indicated in the test manifest.

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

Negative Parser Tests

These tests consist of one input document. The document is not legal RDF/XML. A parser is considered to pass the test if it correctly holds the input document to be in error.

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

Positive Entailment Tests

These tests are specified by one or more premise documents (in RDF/XML or N-Triples) together with a single conclusion document. In addition, the rules used for determining entailment are specified by test:entailmentRules elements. If the following is present

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

then the test succeeds if the entailment holds according to the rules of RDF-entailment as specified in [RDF-SEMANTICS]. If the following two elements are present

<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#" />
     

then the test succeeds if the entailment holds according to the rules of RDFS-entailment as specified in [RDF-SEMANTICS].

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

According to [RDF-SEMANTICS], a premise document that contains a semantic error with respect to any constraints imposed by the entailment rules selected will be false in any interpretation (and hence entail anything).

Support for such situations is provided by the manifest format by declaring an premise or conclusion pseudo-document as follows:

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

By convention, such a pseudo-document is said to come out false under any interpretation.

Negative Entailment Tests

These tests are specified using a similar structure to the Positive Entailment Tests, with the <test:NegativeEntailmentTest> element used instead of the <test:PositiveEntailmentTest>. The test is failed if the conclusion can be drawn from the premises using the rules of RDF- or RDFS-entailment. The test is considered to be passed when it can be conclusively demonstrated that the conclusion cannot be so drawn. In practice, the test may be considered to be passed when a thorough attempt to fail the test is unable to achieve failure.

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

Datatype-aware entailment tests

Entailment test cases may, in addition, require datatype support. Such a requirement is indicated in the manifest by the presence of the following test:entailmentRules element, followed by zero or more test:datatypeSupport entries.

   <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" />

For the purposes of the test suite, if a test case requires datatype support for a set of datatypes, { T, U, V, ... } then the following three pieces of machinery are required:

• for any datatyped literal of the form "aaa"^^<T> where T is a supported datatype, it must be possible to determine if aaa is a valid lexical form for that datatype; and
• for any two datatyped literals of the form "aaa"^^<T> and "bbb"^^<U> with aaa and bbb valid lexical forms of the supported datatypes T and U respectively, it must be possible to determine if those two literals denote the same value. (Note that determining what that value is is not explicitly required.)
• for any datatyped literal of the form "aaa"^^<T> where T is a supported datatype, and for some supported datatype U, it must be possible to determine if the value denoted by the literal is or is not a member of the value space of U. (This last condition is required to support the checking of range clashes.) Finally,
• For two supported datatypes T and U, it must be possible to determine (possibly by simple fiat) if T, considered as a class, is a subclass of U, considered as a class.

Miscellaneous Tests

This manifest entry is used to describe test cases that do not fall into one of the earlier categories. It may have several associated files, indicated in <test:document> elements.

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

In addition, each test case description may have the following common attributes:

• The test:issue element contains a pointer to the associated issue on the RDF Core Working Group Tracking document. It may appear zero or more times.

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

• The test:status element, if present, indicates the status of the test according to RDF Core Working Group process. Only test descriptions containing the following should be considered to be approved by Working Group.

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

• The test:approval element, if present, contains a reference to the minutes of the RDF Core Working Group meeting where the test case status was last changed.

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

• The test:discussion element, if present, contains a pointer to other discussion surrounding this test case or the associated issue. This element may appear multiple times.

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

• The test:description element, if present, contains a human-readable summary of the test case.

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

• The test:warning element, if present, indicates that while the test should pass, it may generate a warning. The contents of the element provide a human-readable description of the warning.

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

2.2. Approved Test Cases

The test cases in the following table have been approved.

2.3. Test Cases Not Approved

The test case repository contains test cases that have not been approved. Such test cases are not enumerated in this document but a list of them is available at http://www.w3.org/2000/10/rdf-tests/rdfcore/allTestCases.html.

2.4. Running the Test Cases

The test case manifest format was deliberately chosen to be a simple, declarative description of the test cases. Parser tests can be run in conjunction with simple tools such as ntc[NTC]. A parser should pass all the positive parser tests, and reject all the negative parser tests. Tools like Euler [EULER] have been used to run the entailment tests.

Due to the rules of entailment tests, a positive or negative entailment test case with an empty conclusion document can be used to illustrate semantic constraints associated with sets of entailment rules.

The test cases have been created to illustrate the resolution of particular issues on the RDF Issue Tracking list. Consequently, test case results should always be interpreted in conjunction with the resolution of the associated issue and the description (if any) attached to the test case in the manifest.

3. N-Triples

N-Triples is a line-based, plain text format for encoding an RDF graph. It was designed to be a fixed subset of N3[N3] [N3-Primer] and hence N3 tools such as cwm [CWM], n-triples2kif [N-TRIPLES2KIF], and Euler [EULER] can be used to read and process it. cwm can output this format when invoked as "cwm -ntriples".

It is recommended, but not required, that N-Triples content is stored in files with an '.nt' suffix to distinguish them from N3.

The Internet media type / MIME type of N-Triples is text/plain and the character encoding is 7-bit US-ASCII.

NOTE: N-Triples is an RDF syntax for expressing RDF test cases and defining the correspondence between RDF/XML and the RDF abstract syntax. RDF/XML [RDF-SYNTAX] is the recommended syntax for applications to exchange RDF information.

3.1. Extended Backus-Naur Form (EBNF) Grammar

An N-Triples document is a sequence of US-ASCII characters and is defined by the ntripleDoc grammar term below. Parsing it results in a sequence of RDF triples formed from the subject, predicate and object productions.

This EBNF is