Using RDF to describe and run URI test cases

RDF test case descriptions have been used with some success by the W3C RDF and OWL working groups. This note is a summary of my attempts to do something similar for URI test cases.

For my own URI parser, written in Haskell, I have collected some 300 or so sets of test data from various sources, which result in the execution of 500 or so actual test cases. So my first challenge is: how to author all this as RDF? As part of my Swish project, I have created an option to read RDF from an annotated comma separated variable (CSV) file exported by Microsoft Excel; this allows RDF data that follows a regular pattern to be authored easily as a spreadsheet, exported to CSV and subsequently converted to Notation3 using Swish. This can then be converted to RDF/XML using CWM.

RDF data is entered into a spreadsheet using one row of data per subject, with each column corresponding to a different RDF property. Annotations indicate the RDF property and the type of RDF data (resource, plain literal or typed literal) associated with each colun. One of the columns can be designated as indicating a subject URI, and other annotations can be used to indicate namepace URIs and subject type information.

There are four kinds of test described here:

• Syntax checking: confirm that a given URI string conforms to an indicated kind of URI: absolute URI reference with optional fragment identifier; absolute URI reference without fragment identifier; relative URI reference with optional fragment identifier; or an invalid URI reference.
• URI decomposition tests (picking out the scheme, authority user, authority registered name, authority port number, path, query and fragment components).
• Relative URI tests. The important tests are relative-to-absolute evaluation with reference to a given base, but I also have code that evaluates a relative URI reference with respect to a given base, so there are three kinds of test: relative-to-absolute conversion, absolute-to-relative conversion, and absolute-to-relative-to-absolute round tripping.
• URI normalization tests, covering case normalization, escape normalization and path segment normalization.

For more information, refer to the Excel or CSV source files.

The following links refer to my URI test descriptions in their various forms, and related software:

• URI test data as an Excel spreadsheet: http://www.ninebynine.org/Software/HaskellUtils/Network/UriTest.xls.
• URI test data as CSV file: http://www.ninebynine.org/Software/HaskellUtils/Network/UriTest.csv.
• URI test data as RDF/N3 (Notation3) file: http://www.ninebynine.org/Software/HaskellUtils/Network/UriTest.n3.
• URI test data as CSV file: http://www.ninebynine.org/Software/HaskellUtils/Network/UriTest.csv.
• MS-Windows batch file to convert CSV data into RDF/N3 and RDF/XML, using Swish and CWM: http://www.ninebynine.org/Software/HaskellUtils/Network/MakeUriTest.bat. Some details are specific to my system installation, but it should serve as a kind of recipe to indicate what steps need to be performed.
• Current working version of Swish software (NOTE: release 0.21 of Swish does not contain the CSV parsing logic, and certain other enhancements needed to run the URI test cases): http://www.ninebynine.org/Software/HaskellRDF/, and supporting libraries http://www.ninebynine.org/Software/HaskellUtils/. The URI and URI test code is here: http://www.ninebynine.org/Software/HaskellUtils/Network/.

So much for describing the test cases. For my own URI software, which is written in Haskell, I have written a test runner program that uses my Swish code to read the test case descriptions, uses an RDF graph query capability to extract the test descriptions, and constructs the corresponding unit test cases and then executes them coutesy of Haskell's higher order functions.

At the time of writing, I have some bugs to fix in my code...