- About XNAT
- News & Events
- XNAT Marketplace
- Contact Us
The proposed system (XNAT Desktop) will represent rich client software installed locally by users of one or more XNAT Enterprise deployments. XNAT Desktop is a file-centric architecture for managing local research files based on tagging system and interacting with XNAT Enterprise deployments. XNAT Desktop should efficiently deliver the following tasks:
XNAT Desktop (XND) will consist of two parts: XND Frontend and XNAT File Server.
XNAT File Server will provide core functionality for managing repository item records (this is performed by repository manager) and transferring items between different File Server entities (performed by file transfer manager). XND Frontend will provide GUI to
a) manage item tags in local or remote repository,
b) query for items with specific tags, both locally and remotely,
c) transfer items between local and remote repositories.
A warehouse containing all files/folders tracked by XNAT Lite.
A root folder for managed items. Repository can have an arbitrary (but presumably small) number of roots for managed items. Each repository root should have a unique alias understood by XNAT file server (i.e. binding exists between system-addressable URI pointing to actual location on a local file system, and root alias). All references to repository items are maintained using root alias instead of actual file URI alias. This helps reduce security risks by hiding local file system structure and also add flexibility to managing
Each folder maintained under repository root, is referred to as a repository container. An actual path maintained by Repository is relative to one of existing roots. For instance, if we have a root “C:\documents and settings\testuser\my documents\data” with alias “/mri_data”, its subfolders “/mpr”, “/recon” and “/seg” are maintained as “/mri_data/mpr”, “/mri_data/recon” and “/mri_data/seg”. Note that except for the repository root, none of the containers can be addressed by name different from the name on actual file system. Additionally, similarly to Amazon’s “digital bucket” concept, the relation between two different containers is not explicitly defined (although it can be inferred from the folder path).
File sitting in one of the folders addressable as repository containers. An expression “an item belongs to this container” implies that the actual file is residing in folder denoted by the container. An item that belongs to a container may or may not be managed by Repository database, and search queries to File server cannot identify an item in container unless it is managed.
Store / de-store item.
Add/remove item to/from Repository (start/stop managing item). Note that this operation does not involve file creation, copying or deletion in any way, but rather managing records in the database.
Basic item operations, file server operations.
Rename, delete, move, copy item. This functionality is performed by a file server which is conceptually separated from repository manager, due to architecture considerations, as discussed in “Architecture” section.
Item tag is a “name-value” pair. Tag name is uniquely represented by alphanumeric string without spaces, defined by the user or predefined in XNAT Lite. For each item, each specific tag is either defined or undefined, and if defined, tag value can be an arbitrary string.
To tag item.
To define specified tag for selected item(s) in Repository.
Following the tag rename or delete, correctly update tag definitions of all in repository.
Each function described henceforward, will be logically ascribed to either XNAT Desktop or XNAT File Server, so this will be implied in expressions like “exists in Desktop role”, “included in File Server role”.
Zero, one or more tags can be attached to each item in repository.
The user should be able to:
The user should be able to:
XND will provide simple item search by combination of any number of tags and partial item name.
XND should provide both client and server functionality for transferring repository items between XNAT File Server installations. For each upload session/item, minimal data the user will have to provide:
Advanced features may include:
Currently, the need also exists to provide a generic API for sharing items in Repository over the network. The proposed architecture is divided, for implementation purposes, into DB query module (Repository manager) and resource (i.e. mainly file) transfer module (i.e. core File Server manager)
The user interface should provide the following:
Related: XNAT File Server API