1. MBAT Infrastructure Controversial remarks…

2. What is an atlas?  a set of 2D images or a 3D volume in a specified coordinate system with a set of spatially registered annotations.  Other tools: Spatial normalization tools Viewers Annotation tools Segmentation Analysis tools  What we need is more than an atlas Atlas as a gateway to distributed “large” databases of images, volumes, segmentations, other spatially- registered data

3. What should BIRN offer?  Two Visions: Stand alone application:  Based on Shiva How to get data and application: Java Webstart???  3D Atlas  Comparison tools Web-based system:  Available through portal  Based on interoperable tools that work on BIRN infrastructure Authentication and data grid API’s XML-based exchange of spatial information Create “portlets” for modules Neuroterrain and Smart Atlas  Interface for accessing and performing “meta-analysis” over distributed spatially registered data

4. What is a working infrastructure Something that has value beyond specific components, regardless of how good they are –Especially true about front-end components… Makes sure that components can be replaced, upgraded as needed, and multiple front-ends are supported In fact, different front-ends serve different purposes, tuned to different data. It is hard to design an omnivorous client Regardless of a front-end system, data services (retrieval and query) and catalogs (query) will still be re-usable

5. Interoperability desiderata Read data from other atlases/databases API for data retrieval and transformation Find relevant data in other atlases/ databases API for atlas catalogs View the region of interest in another atlas API for atlas state exchange

6. 1. API for data retrieval and transformation Settle on common BIRN-supported data formats: –2D raster formats, 2D vector formats (e.g. ArcIMS services) –3D formats –XML exchange standards Settle on a common spatial and ontological references –Stereotaxic, plus conversion routines –Ontologies is an ongoing effort Common web services API for data access (CCDB web services!)

7. 2. API for atlas catalogs Not much is done… Work on spatial registries: –Image registration pipeline Mediator Registry, CCDB Registry of web services

8. Image Registration Portlet Automatic generation of spatially-registered image services

9. Image Registration Portlet: Spatial Registry

10. API for state exchange First version available, and supported by three atlases (Shiva, SA, NT) –Agreed-upon protocol and ROI description, plus Java API; –Agreed-upon coordinate framework; –Synchronizing mouse positions Doesn’t really exist in the earth sciences, because of much higher level of standardization on the data API side, and lots of free data. OGC standards

11. ROI exchange API in action  Integration across atlas clients Specification of state of atlas client API for initializing exchange service and submitting and retrieving states Servlet Or Web Service Any Atlas Smart Atlas Init() New service id & URL Open SmartAtlas using returned URL Submit() Confirmation Retrieve() Result wrapped in XML End_service() Confirmation Retrieve() Result wrapped in XML Submit() Confirmation Service ended automatically when application is closed

12. Universal description of location and spatial relationships?? Across scales and coordinate systems Location description: –By geometries (in common coordinates) –By feature names (in shared ontology) –By relationships (in common mereotopology terms): need engines for description “packing” and “unpacking”

13. Sociology… People who develop atlases are the best Let’s not try to convince them that their favorite client interface is no good, and make them use something else Experience of other projects: people rarely change client interfaces they have used (and especially developed)… But it is possible to have them develop a new generation research infrastructure – …developers are eager to use stable external interfaces that provide access to useful data - isn’t it BIRN?