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

Sooner or later, I think you'll probably want to compare RDF graphs, so it 
would seem reasonable to me to bite the bullet.

I've just done coding and testing a version of Jeremy's graph compare logic 
in Haskell, and I think the same logic could be recoded relatively easily 
in other languages with dynamic structure allocation.  The core algorithm 
is quite compact, though there's a welter of detail that is needed to 
support it.  I've gone for a very general solution ... I suspect that the 
amount of detail may be reduced if some generalizations were assumed away.

#g
--

At 08:57 10/04/2003 -0400, Dan Brickley wrote:

>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/

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Thursday, 10 April 2003 12:10:23 UTC