W3C

GRDDL Test Cases

Editor's Draft March 13 2007

This version:
...
Latest version:
...
Editor:
Chimezie Ogbuji, Cleveland Clinic Foundation, <ogbujic@ccf.org>
Authors:
see Acknowledgments

Copyright © 2006-2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document describes and includes test cases for software agents that extract RDF from XML source documents by following the set of mechanisms outlined in the Gleaning Resource Description from Dialects of Language (GRDDL) specification. They demonstrate the expected behavior of a GRDDL-aware agent by specifying one (or more) RDF graph serializations which are the GRDDL results associated with a single source document.

Table of Contents

Introduction

The tests are meant to satisfy the requirement for test cases covering all GRDDL features and library transformations as outlined in the GRDDL Working Group charter.  They should be used for testing the conformance of GRDDL-aware agents. The normative tests cover the required behavior expected of a GRDDL-aware agent.  The informative tests demonstrate expected behavior with respect to the issues resolved by the Working Group as well as other tests of robustness for software agents which consume source documents within a Semantic Web and generate GRDDL results. This document itself has (as a GRDDL result) a manifest document describing the test cases in RDF.

Deliverables

The deliverables included as part of the test case collection are:

Test Manifest Format

This test collection uses an RDF vocabulary for manifests developed for the RDF Test Cases Recommendation. A GRDDL-aware agent can extract the test collection and automatically test compliance by attempting to reproduce the expected GRDDL result(s) associated with each test case.

Using the Test Driver

We provide testft.py, a test driver, based on rdflib 2.3.3 and 4suite, specifically 4Suite-XML-1.0.tar.gz. Run it a la:

$ python testft.py --run your_grddl_impl testlist1.rdf >earl_out.rdf All tests were passed!

@@ NOTE: testft.py currently only depends on rdflib 2.3.3

It has options for --debug and such; invoke it with no arguments (or with --help) for details:

Options:
  -r, --run              path to a GRDDL implementation to use to process the 
                         source document (checking results)
  -u, --update           path to a GRDDL Implementation to use to process the 
                         source document
      --tester           The URI of an agent associated with the EARL test assertions.
                         A BNode is used if none is given                          
      --project          The URI of the EARL 'subject' (the implementation being tested).
                         A BNode is used if none is given

EARL Reporting

In addition to writing various diagnostic messages to STDERR, the test harness writes additional RDF data to STDOUT: an EARL assertion about each test it runs.

To tell it about the person running the tests and the software project being tested, point it to a tester (a URI in a FOAF RDF graph) and a test subject (a URI in a DOAP RDF graph).

Protocol Tracing

We find TCPWatch useful for debugging HTTP protocol interactions. If you start TCPWatch like so:

$ python tcpwatch.py -p 6543 &

then you can use it as a proxy:

$ http_proxy=http://127.0.0.1:6543 python testft.py --run your_grddl_impl testharness.rdf

Local Policies, Faithful Rendition, and Conformance

The GRDDL specification states that any transformation identified by an author of a GRDDL source document will provide a Faithful Rendition of the information expressed in the source document. The specification also grants a GRDDL-aware agent the license to makes a determination of whether or not to apply a particular transformation guided by user interaction, a local security policy, or the agent's capabilities. However, for the purpose of running these tests in order to determine compliance, a GRDDL-aware agent with a security policy which does not prevent it from applying transformations identified by each test will produce the GRDDL result associated with each test.

Tests with Multiple GRDDL Results

Certain tests have multiple GRDDL results as a direct consequence of Faithful Infoset considerations, information resources with multiple representations, and seperate GRDDL mechanisms which produce distinct GRDDL results. For such tests, A GRDDL-aware agent should output at least one of the GRDDL results associated with the test case.

@TODO: The manifest needs a vocabulary to describe test alternatives beyond what the RDF Test vocabulary provides.

Normative Tests

These tests address the functional requirements of the various ways in which GRDDL mandates the extraction of a GRDDL result.

Localized Tests

For the sake of convenience, these first set of normative tests cover scenarios where neither namespace documents nor absolute URIs are used. Such tests can run offline rather easily.

Namespace Documents and Absolute Locations

These tests include the use of namespace documents and absolute URIs and are much more difficult to run offline.

Ambiguos Infosets and Representations

These tests help check for robustness of implementations in the face of various odd cases.

Informative Tests

These tests cover features not mandated explicitely by the GRDDL specification, but demonstrate behavior expected of a GRDDL-aware agent in the context of Web Architecture best practices (@@Appropriate [WEBARCH] link?). They also cover behavior suggested by the Working Group as a result of resolving certain issues.

@@TODO: How to reconcile current (approved but informative) status of the Atom / Turtle test? - There was appreciable consensus on mentioning RDF graphs not RDF/XML documents

References

@@Need references

Normative

Informative

Acknowledgements

@@Need comprehensive list of acknowledgements