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

Manifest details.

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Fri, 16 Nov 2001 11:41:53 +0000 (GMT)
To: RDFCore Working Group <w3c-rdfcore-wg@w3.org>
Message-ID: <Pine.GSO.4.31.0111161050160.26038-300000@mail.ilrt.bris.ac.uk>
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.

Received on Friday, 16 November 2001 06:42:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC