Slicer3:UIDesign:WorkingProblems:SlicerInformatics:Draft1
Contents
Discussion at the NA-MIC 2009 AHM in Salt Lake City
Planning XNAT and Slicer integration next steps
Rough timeline for the next several months
Discussion points and action items
Deleting:
- resources (Use http delete),
- tags on resources, and
- tags from whole repository
Kevin will email wendy the API for the last two of these.
QA: detecting whether uploaded data is valid. WUSTL is thinking about QA; right now no provision. Future, maybe look at checksum on server side... Maybe there's a short-term soln: API provision for client to query for remote file size, and check this against local file size, the request file be deleted on remote host if no match...
Question: is there a way to validate a server as XND? We want to expose capability to 'add a new server', and a way to query the resulting servername for its identity, like 'http://xnd.slicer.org:8000/identify'. Kevin will look into this.
Security: no security yet. A first pass will come soon, probably http basic.
Tag/value length limits: There are no intentional limits on tag/value lengths. Long names and values may slow search time.
Special character restrictions: excaping all characters as for xml/html should be sufficient.
Note: WUSTL implemented a file browser metaphor for looking at hierarchy of resources, found that intuitive for users.
Note: XND current version is challenged by enormous datasets (like large collections of DICOM). Fix to this coming in version 0.8, with "collection support".
Note: Current XND version 0.7 is compatible with Slicer's existing implementation. Slicer will have to be modified to take advantage of Version 0.8's collection support: collections may not be supported by XND FileServer until a month or two after XND 0.8 is released.
Format tag: In the event that URIs don't contain an explicit extension (like those for XNAT-E, which also encode ticket info) we need some kind of tag on the dataset that Slicer can use to know how to open/load it. Current Slicer implementation automatically generates a "SlicerDataType" tag that it uses for that purpose. Better if we change that logic to use a "Format" tag that Slicer- and non-Slicer-people use. But we need to encourage the value assignments to be somewhat consistent. Can we create an XND default tag with a pre-populated set of values that takes a good stab at this? If so, Slicer can be modified to use "Format" instead of (or in addition to) "SlicerDataType".
Annotations, Thumbnails, and other derived data: We discussed the best way to accommodate annotations, and other data (thumbnails) associated with a particular dataset or collection of datasets. We would want to be able to:
- create these 'documents or datasets',
- upload them and associate them with a resource,
- query for them, and
- download them separately or bundled with data.
