Difference between revisions of "2011 Winter Project Week:FetchMIAPI"

From NAMIC Wiki
Jump to: navigation, search
Line 48: Line 48:
 
</div>
 
</div>
  
<!--<div style="width: 97%; float: left;">
+
 
  
 
==NOTES==
 
==NOTES==
Line 64: Line 64:
  
 
==References==
 
==References==
 
</div>
 
-->
 

Revision as of 17:44, 12 January 2011

Home < 2011 Winter Project Week:FetchMIAPI

Key Investigators

  • Wash U: Dan Marcus, Misha Milchenko

Objective

Recode the FetchMI interface to work with the XNAT 1.5 REST API

Approach, Plan

FetchMI was originally coded to work with the XNAT Desktop API which is now being updated to look like the XNAT 1.5 API. So updating FetchMI will allow Slicer to exchange data with both Desktop and Enterprise systems.

Short term plan: Implement for workflow for Slicer3.6 like this:

  • The user will go to the XNAT web interface to navigate to the data they want.
  • They will download these data (probably DICOM) locally and load into Slicer.
  • In Slicer, the user will construct a scene file and then upload that scene file to the XNAT through the FetchMI upload interface.
  • Only scenes will be downloadable from XNATE into Slicer via FetchMI.
  • Once a scene has been uploaded to XNAT, it will be accessible, along with all of the required data files, from FetchMI’s download interface.
  • The scene files will be posted to the project-level resources and will need to have some basic slicer metadata added to the format and/or content tags to allow the (for short term) implicit filtering for .mrml files through the query interface.
  • FetchMI's existing query interface will display *only* project tags for search to user initially (this eliminates the need to modify GUI to do hierarchical queries for short term) and will only look for files with format=MRML. So all Scenes will be uploaded at the project level, and will be searched at the project level.
  • There may be a need to add additional tags as well.

Long term plan:

  • All refined work will go into Slicer 4.
  • And extensions to query, parsing, tagging, upload and download LOGIC to accommodate moving individual (non-mrml) datasets to the XNE repository.
  • This will include substantial GUI revisions.

Progress

The FetchMI code has been reviewed and relevant replacement code has been identified.

Classes to be added:

  • vtkFetchMIWebServicesClientXNE <-- vtkFetchMIWebServicesClient (generates queries, performs queries, UL, DL, etc. via curl.) (is an existing vtkFetchMIWebServicesClientXND)
  • vtkFetchMIParserXNE <-- vtkFetchMIParser (parsers server responses) (is an existing vtkFetchMIParserXND)
  • vtkFetchMIWriterXNE <-- vtkFetchMIWriter (writes required XML for upload) (is an existing vtkFetchMIWriterXND)
  • vtkMRMLXNEHandler <-- vtkMRMLHTTPHandler (both in RemoteIO Lib) (is an existing vtkMRMLXNDHandler)

Places in code to be touched:

  • vtkMRMLFetchMINode
  • vtkFetchMILogic


NOTES

upload scene.

  • create a unique catalog resource name (name should be identical to scene base name)
  • verify that this resource name is unique on the project
  • configure the format tag on resource and any other metadata we might want.
  • the create on XNE
  • next, upload all scene files under this resource (have a pre-determined uri based on project and resource and resource name.)
  • move those uris into mrml scene file
  • configure the format tag on scene file and any other metadata we might want.
  • then upload scene file to the project with scene name = resourcename.mrml


References