Thank you Michael and Jennifer again!
On Tue, 06 Dec 2016, Elam, Jennifer wrote:
> To add to what Mike Harms just wrote, it still sounds like you are
> thinking of the packages as data bundles for groups of subjects.
yes -- indeed -- it was probably the main reason for a bit of disconnect in our
dialog since I have misused the term of a "package" which is indeed provided
per each subject separately and "bundle" would have been a proper term.
I will try to use correct terms (package vs bundle) appropriately from now on
;)
On Tue, 06 Dec 2016, Elam, Jennifer wrote:
> Subjects
> don't "belong" to a package because the packages don't contain groups of
> subjects. Instead, the packages are separate and specific to a particular
> subject ID, modality, processing level, and smoothing level (for fMRI).
On Tue, 06 Dec 2016, Harms, Michael wrote:
> To reiterate something Mike Hodge mentioned, any given package only
> contains files for one subject. When interacting with ConnectomDB, the
> subjects to download, and the particular packages to download, are two
> separate and distinct choices.
choices (as in the interface) are indeed distinct but not entirely
independent.
With my cleared up understanding of the terminology, question remains -- is
there a list of files per each package (per each subject) which you use to
generate packages from individual files? or that is the information contained
within XNAT schema used underneath (so it could may be queried instead)?
> I think the confusion is that individual subject packages can be queued
> for download in groups in ConnectomeDB. We could provide you with lists of
> subjects for each searchable group in ConnectomeDB, (e.g. U100, 7T data
> available, MEG data available) with which some users may have queued all
> subjects in a group for download of specific data packages for their
> analysis.
yes. That would be great.
> Another slight complication is that there is a little bit of overlap in
> the data in the packages themselves so that there is more than one package
> associated with some of the files. This was done so that users would have
> everything they need to do a certain analysis from a particular
> package. For example, the FIX and FIX-extended packages include a few of
> the same output files, although the FIX-extended package has a lot more of
> the FIX intermediate files to allow users to evaluate how FIX worked for a
> particular subject.
yeap. that is why having lists of those files per each package could be of
benefit. Could as well be located e.g. under packages/ "subfolder"
within each subject folder on S3 bucket, e.g. for
./100307/analysis_s12/100307_3T_tfMRI_EMOTION_analysis_s12.zip
there could be files like
./100307/packages/3T_tfMRI_EMOTION_analysis_s12.list
containing
100307/.xdlm/100307_3T_tfMRI_EMOTION_analysis_s12.json
100307/MNINonLinear/Results/tfMRI_EMOTION/tfMRI_EMOTION_hp200_s12_level2.feat/100307_tfMRI_EMOTION_level2_hp200_s12.dscalar.nii
100307/MNINonLinear/Results/tfMRI_EMOTION/tfMRI_EMOTION_hp200_s12_level2.feat/Contrasts.txt
100307/MNINonLinear/Results/tfMRI_EMOTION/tfMRI_EMOTION_hp200_s12_level2.feat/GrayordinatesStats/cope1.feat/cope1.dtseries.nii
100307/MNINonLinear/Results/tfMRI_EMOTION/tfMRI_EMOTION_hp200_s12_level2.feat/GrayordinatesStats/cope1.feat/logfile
100307/MNINonLinear/Results/tfMRI_EMOTION/tfMRI_EMOTION_hp200_s12_level2.feat/GrayordinatesStats/cope1.feat/mask.dtseries.nii
...
... (excluded folders since they provide no additional information) ...
do you see it feasible?
Thank you in advance for your informative replies!
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
_______________________________________________
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users
