Ms. XBrain


Ms. XBrain can be deployed by packaging it as a war file and handing it to a servlet container (like Tomcat).

The current deployment is at and when called, the Launch.jsp page should be the target.


An XQuery on the CSM database, it could be quickly extended to take a distributed XQuery. The results of the query are expected to follow these rule:

  1. A descendent of the root must be named "Patient"
  2. All sites must be in labels called "Site", "Stimsite" or "Stimsite1"
  3. All sites must descend from a Patient
  4. All sites must have children named "right_coord" "sup_coord" and "ant_coord"
  5. Any individual site cannot appear more than once (if they do they will be discarded by MindSeer)
  6. A list of file directives (<File>file:/path/to/file</File>). For more information, see MsXBrain_File

Client/Server? or Standalone

MindSeer has 2 modes that have advantages and disadvantages. Standalone is best when the data is local or the amount of data to download is small (or very reusable). Client/Server? works best when the data is in a large central repository that you don't wish to download. For visualizing on the average brain, we only need to download the data once. This makes it ideal for standalone as the server won't have any load from running the MindSeer server and the client has better performance. However this does not work for all individual subjects because the download would be too big. Because of this, the intermediate page launches either standalone or client/server depending on the patient selected.


The Bursa Version

Test Box

For internal testing, you can use the Test Page. Simply type in a CSM query.


Unlike other XBrain plugins, this one has some special issues to overcome:

  1. The immediately returned document is not the data.
  2. Because of #1, I have to encode the results or the query into a URL (I opted for the query using Base64 and GZip).

To accommodate this, it takes the query as the post and then uses DXQP to get the results and process them when they are requested by MindSeer.

How it fits in

While this diagram captures the XBrain System fairly accurately (with some simplification and completely leaving off the 2D image view), it fails to show how things are connected. Conceptually, you can imagine distributed XQuery (dxquery) binding the system together. DXQuery is not being done by DXQP using AngloSaxon. As you can see in the image below, DXQuery (via DXQP) is what binds the whole system together on the backend and the XBrain portal is just the opening page.

Use Cases

The following use cases summarize how this system works. This image is slightly out of date

  1. The XBrain User clicks on the 3D button and posts the XQuery to MsXBrain.
  2. An intermediate page allows the user to select a patient.
  3. The patient id, whether to use client/server and XQuery is encoded and placed in the MindSeer launching file (JNLP file) as a URL
  4. The JNLP file is returned to the XBrain User. This image is slightly out of date

  1. MindSeer uses the URL to request a map file (Results.bmx?...)
  2. Tomcat sends the file to the MindSeer File servlet.
  3. MindSeer File requests the data using the encoded query.
  4. AngloSaxon and DXQP execute the query on the XCSM and TransformationServer
  5. The results are returned to MindSeer to display to the user.

Distributed XQuery

Almost all of the real work for generating the map file is done in a single XQuery with Java just providing a cache and the front end.

The current query that this uses can be found here: CVS Copy

The one as of this writing is below:

(: Import anglo as the web service processor :)
declare namespace anglo="java:edu.washington.biostr.sig.anglo.WebServiceWrapper";
declare namespace dxqp="edu.washington.biostr.sig.dxq.DXQProcessor";
(: Create a spot for the xQuery that will be passed here :)
declare variable $query as xs:string external; 
declare variable $priv as xs:integer external; 

(: Run the XQuery using dxqp :)
let $processor := dxqp:new()

let $xq := dxqp:list_ExecuteQuery($processor, $query, $priv)

(: Process the results :)
let $descrip := $xq/Description
let $coord :=
<TransformServerParam coord="Label" source="0" target=""/>
<Data type="XML Map" name="{
if (exists($descrip))
then $descrip
else "Results"
(:Parse this into the form for the transform server:)
for $site in $xq//stimsite | $xq//site | $xq//stimsite1
let $patient := $site/ancestor::patient
let $pnum := concat("P", data($patient/pnum))
let $x := data($site//right_coord)
let $y := data($site//ant_coord)
let $z := data($site//sup_coord)
		<Label text="{concat($pnum, "-", data($site/site_label))}"			
			<Info tag="Original Coordinate" value="({$x}, {$y}, {$z})"/>
				(: Add any meta data that we have :)
				for $info in $site/*[not(ends-with(string(node-name(.)), "coord"))]
				<Info tag="{node-name($info)}" value="{data($info)}"/>				
			<Info tag="patient" value="{$pnum}"/>
				for $info in $patient/*[not(ends-with(string(node-name(.)), "site"))]
				<Info tag="{node-name($info)}" value="{data($info)}"/>				

(: Dispatch the above to the transformation web service's filter :)
let $ncoord := anglo:xquery("",
	"TransformationWS", "transformXML", $coord)
(: Return the results as a collection of data, later we may take other forms of data like fMRI :)
for $result in $ncoord//Data
return $result

As you skim the query you will notice a number of things:

  • It takes a query and calls DXQP from within the query.
  • The results are returned as Saxon objects so there is no performance hit.
  • We pull out all of the additional information for each site as meta-data.
  • The document is shipped to another Web Service to have the sites normalized.
Last modified 12 years ago Last modified on 01/18/07 11:48:03