[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