algorithm / (pseudo)code for comparing expected vs received resultset

I'm working to hook up my Rubyrdf code to the query test case machinery[1] 
being drafted here and in the IRC chat series. I'm at the stage where I
need to compare the expected results (using the format Andy's been 
working on) with the actual bindings I get back from the query system.

This amounts to a need to compare two tables, with columns corresponding
to the requested variables, and rows for each satisfying binding. We know
the column headings across the two tables because there is an assumed 
correspondence to variable names. But we don't have any principle for
ordering the resultset rows (at least for the squish-like languages
we're using for these initial testcases). The combination of this and the 
inability to compare bNode local IDs across expected vs actual results
means there is some subtlety involved in using these test cases.

So... I was wondering how others are dealing with this. I was thinking 
I'd go through the result rows, and for each bNode, annotate it with a 
description of it in terms of its relationship to concrete URIs and 
literals in the data structure. That (on a good day) allows the bnode 
bits of each table to be re-labelled consistently, which in turn 
allows the table rows to be compared like-against-like. 

This is a variant of the rdf graph comparison problem, but a bit more
constrained. I'm not sure to what extent it makes sense to try for a 
common approach to both. I guess it depends on the data; lots of 
bnodes makes things hairy...

ramblingly,

dan 


[1] http://www.w3.org/2003/03/rdfqr-tests/

Received on Thursday, 10 April 2003 08:57:25 UTC