W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

Re: Manifest details.

From: <jos.deroo.jd@belgium.agfa.com>
Date: Mon, 19 Nov 2001 09:53:08 +0100
To: Jan.Grant@bristol.ac.uk
Cc: w3c-rdfcore-wg@w3.org
Message-Id: <OFE7887DF5.1ABACE19-ONC1256B09.002EB4D7@bayer-ag.com>

Hi Jan,

You've done a great job here!
What about using the namespace http://www.w3.org/2000/10/rdf-tests# ?
For Positive/NegativeEntailmentTest is it that we may assume by
default any W3C recommended set of rules (e.g. RDFS entailment rules)?


Jan Grant <Jan.Grant@bristol.ac.uk>@w3.org on 2001-11-16 12:41:53 PM

Sent by:  w3c-rdfcore-wg-request@w3.org

To:   RDFCore Working Group <w3c-rdfcore-wg@w3.org>
Subject:  Manifest details.

Sorry this took so long; it's pretty simple.

We're looking for a manifest file format to describe the RDFCore test
cases. This should let us -

- machine process the test case descriptions
- point to current copies of the test case input files on the web
- permit just the running (say) of parser tests
- permit the association of tests with particular issues
  (so we could just run the container tests, for instance)
- be in a simple-enough format that processing the manifest itself
  is not something that requires debugging
- be readily extensible to other types of test case as they arrive.

In addition, it was reckoned to be desirable that the whole test-case
directory structure plus manifest could be zipped up and shipped as an
item. Due to the handling of rdf:id attributes, this means we
potentially have to point to local copies of the test case files while
preserving information about their original base URIs.

1. A small taxonomy for test cases.

There are positive test cases (which should run to success) and negative
ones; a negative test case might illustrate where a parser might throw
an exception, or an entailment should _not_ be made.

(Required: the namespace "test" needs to live somewhere)

Currently test cases appear to be divided up into parser tests (which
generally take rdf/xml as input and compare the resulting graph with a
canonical version in ntriples) and entailment tests (where a number of
input files are processed and a check is performed to ensure that they
do, indeed, have as an entailment something specified in some other

So we wind up with the following base classes -


and subclass those pairwise to produce

     (which has one or more test:inputRDFXML properties,
     and one test:parserResult property)

     (which has one or more test:inputRDFXML properties,
     and no outputs (a failure is expected))

     (which has one or more test:input properties,
     and one test:entailment property)

     (which has one or more test:input properties.
     and one test:entailment property - the entailment
     should _not_ hold)

2. Representing input files.

It's easier to draw a picture of this:

       <test:primaryInstantiation rdf:resource="http://www.w3.org/..." />
       <test:localInstantiation rdf:resource="relative/address/of/tcfile" />

generally, something running a test case could go to the web to find its
input; or, optionally, process the local copy of that resource (treating
its base URI as that given by the primaryInstantiation property). We
hang both of these properties off a bNode since we might conceivably
wish to represent multiple renderings (with associated mime types) at
the same URL (ie, the test:RDFXML node in future might get a mimeType

(Note that here, the resources denoting the input files are labeled with
the URIs that can be dereferenced to get the content of those files,
which seems to be a common convention - it's worth pointing out though).

3. Putting everything together

Finally, there are some other properties that might be attached to a
test case (eg, relatedIssue, comment) plus the usual slew of DC bits and
pieces if required. These should be ignored by test-case processing

Schema attached (needs a namespace in W3C land) and a sample document.

I'd suggest the format for the manifest follow the example closely
(although rendering it in ntriples instead is an option).


jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Just because I have nothing to hide doesn't mean I have nothing to fear.

(See attached file: manifest-schema.rdf)
(See attached file: manifest.rdf)

Received on Monday, 19 November 2001 03:57:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:53 UTC