[Neurodebian-upstream] [Nipy-devel] Standard dataset
Matthew Brett
matthew.brett at gmail.com
Fri Sep 24 00:01:41 UTC 2010
Hi,
> I understand ;-) but it would be good to keep alternatives for a
> "transport layer" in mind and not exclusively focus on system that are
> permanently connected to the web and get everything via HTTP GET.
Yes, I agree. This might be important for large datasets in particular.
> Right, we might want to aim for an abstraction layer of such data
> package registration system. Something like:
>
> $ whereisdata colin27
> /usr/share/data/mni-colin27
>
> $ showdatacontent colin27
> colin27_t1_tal_lin_headmask.nii.gz
> colin27_t1_tal_lin_mask.nii.gz
> colin27_t1_tal_lin.nii.gz
>
> plus some meta data magic like
>
> $ showdatacontent colin27 T1
> colin27_t1_tal_lin.nii.gz
>
> $ showmealldata T1
> /usr/share/data/mni-colin27/colin27_t1_tal_lin.nii.gz
> /usr/share/data/spm8/canonical/avg305T1.nii
Are these querying filenames with regular expressions? Or are we
imagining some sort of labels attached to each of the bits of data,
with a central database by which these can be queried?
> (or similar stuff in Python, Perl, C, Haskell,....)
I suppose that can be an application like apt, that could be written
in any language.
> That would conveniently split the underlying system into:
>
> 1. A facility to get the data onto a system
>
> Several readily usable solution are available.
By system - you mean some sort of central repository? Solutions being
scp and so on?
>> Maybe we should start a conversation with the okfn people (datapkg)
>> for their thoughts?
>
> +1
OK - I'll try and investigate datapkg a bit more, and then try and
think of something sensible to ask ;)
See you,
Matthew
More information about the Neurodebian-upstream
mailing list