Using two issue tracking systems at once is unhelpful, I suggest the team pick one, and stick to it.
In Soprano, based on my very limited understanding, there is a class designed specifically for connecting Soprano to any SPARQL query engine over HTTP. It is called Soprano::Client::SparqlModel and is documented at http://soprano.sourceforge.net/apidox/stable/classSoprano_1_1Client_1_1SparqlModel.html
So... where is the actual issue here for wintermute? As currently stated in the Bug Description above, this issue sounds a bit like "we need our program to do what it is supposed to do".
OK... so... go ahead and code, so it does that :) Set up your SPARQL query backend of choice (Rasqual? Joseki? Openlink Virtuoso Open Source? Other?), and write a bit of glue code to point Soprano::Client::SparqlModel at it. Job done. I think?? Am I over-simplifying here? Possibly :)
What the specific problem is, that is preventing your team from coding something like that, to let your application execute SPARQL queries, is not mentioned at all in the description of this issue. Nor is what your team has already tried in this area, and why it didn't work out, and pointers to those earlier failed attempts...
More generally, doing apt-cache search sparql and investigating each package returned in depth could well lead to greater understanding of what parts of the task are already coded and available for wintermute to re-use, and what parts will need to be written by the wintermute team.
If your team has already done that kind of investigation, then please say so, and put a pointer to the results of that work here, so those reading the issue can easily see exactly what your team has already done as they work towards a solution.
For a few more SPARQL implementations, see http://www.w3.org/wiki/SparqlImplementations .