Version 5 (modified by sigadmin, 13 years ago) (diff)


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)

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 a distributed XQuery 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. Currently, there is no centralized server or library that does dxquery, but instead each component can use its own dxquery engine (unfortunately each engine has its own syntax). In this case, MindSeer is integrated using AngloSaxon and the other components are integrated using a degenerate form of dxquery (just shipping the query and getting a document).

Use Cases

The following use cases summarize how this system works.

  1. The XBrain User clicks on the 3D button and posts the XQuery to MsXBrain.
  2. The XQuery is encoded and placed in the MindSeer launching file (JNLP file) as a URL
  3. The JNLP file is returned to the XBrain User.

  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 executes the query on the XCSM and TransformationServer
  5. The resuls 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.