I tried testing the RDF to Triples stylesheet by hand, looking at the test cases and my own output. There are 540 triples produced by the test cases and whenever I tweaked my stylesheet to satisfy one set of output, I would break the stylesheet for another set. It felt like the "hitting the moles with a hammer" game. After a discussion with Dan Brickley I decided to bite the bullet and build a proper test harness, with SQL Server as a back end triple store, so that I can run intersection queries against the test case triples and my own. This involves some recursive processing with some scrappy C# classes and some SQL server development work - at least one area where I feel happy.

It's been a gruelling trek through the RDF XML syntax and test cases documentation but I feel near the end of the tunnel. The greatest problem I have faced is distinguishing between rdf:ID attributes on subjects, objects and predicates - on subjects and objects the ID relates to the resource, whereas on the predicate element the ID refers to a statement (arc) that is reified. Unfortunately you can't tell from within the context of an element whether it is a predicate or not, and because I was being clever in reusing templates I was processing the same element in as both a subject, object and predicate. This is the case where, for example, the predicate points to a blank resource which has only string literal properties. Tricky. It has made me realise that a simpler RDF syntax, with no abbreviations or deviance from a pure striping model, would certainly be easier to process. It takes RDF XML syntax away from looking like "regular" XML, though.