[ome-devel] OMERO.features API development

[Lee Kamentsky]

Just another short note - I tried downloading the pipeline file (data file
1) which looked OK and the reproduce.zip file which was definitely not. All
I got was an empty file (0KB download size).


On Tue, Nov 12, 2013 at 7:51 AM, Lee Kamentsky <leek at broadinstitute.org>wrote:

> Hi Vebjorn,
> Simon is trying to download the AZ dataset from JBS and found it to be
> corrupted. I'd rather not start a 700gb download just to test. Did you
> check to see if the files are accessible?
>
> Simon, if you need the data, the most straightforward approach may be for
> me to burn a CD and mail it. I think it would be a good dataset to test
> what you do at scale.
>
> --Lee
>
>
> On Mon, Nov 11, 2013 at 12:51 PM, Simon Li <s.p.li at dundee.ac.uk> wrote:
>
>>  Thanks Lee.
>>
>>  The features set you calculated for that screen sounds like a good test
>> of our infrastructure. However I'm having trouble downloading the
>> supplementary data from:
>> http://jbx.sagepub.com/content/early/2013/09/09/1087057113503553/suppl/DC2
>>
>>  Data_S3_reproduce.zip is empty
>> Data_S2_database.zip seems to be corrupt
>>
>>  Does it look correct from your end?
>>
>>  Thanks
>>
>>  Simon
>>
>>
>>
>>  On 7 Nov 2013, at 20:55, Lee Kamentsky <leek at broadinstitute.org> wrote:
>>
>>  I promised to roughly describe the CellProfiler use case - we recently
>> published a paper whose data should be available on-line, so I based it on
>> that. Enclosed is what I wrote up as well as the paper and the supplement.
>> The supplement is actually more important because it has more details about
>> the analysis (and the features).
>>
>>
>>   Ljosa_JBiomolScreen_2013.pdf<https://docs.google.com/a/broadinstitute.org/file/d/0Bzg4PoGEku2FTFFBS0ZsZTFoSXc/edit?usp=drive_web>
>>
>>   Ljosa_JBiomolScreen_2013_supplement.pdf<https://docs.google.com/a/broadinstitute.org/file/d/0Bzg4PoGEku2FLVZkTEZqUDJ5X1k/edit?usp=drive_web>
>>
>>
>>
>> On Thu, Nov 7, 2013 at 9:20 AM, Simon Li <s.p.li at dundee.ac.uk> wrote:
>>
>>> Some notes from our meeting yesterday:
>>>
>>> http://www.openmicroscopy.org/site/community/minutes/minigroup/omero-features-meetings/2013-11-06-omero-features-google-hangout
>>>
>>> Summary:
>>> We're thinking of representing features as a 2D array, with metadata
>>> stored as key-value maps attached to the array, or individual columns or
>>> rows. These keys could describe things such as the feature name (column),
>>> sample metadata (row), algorithm parameters, calculation pipelines, etc.
>>>
>>> This should work as an OMERO API- in order to retrieve features you'd
>>> pass in a set of key-value pairs, for instance to specify which features
>>> you want and which images/ROIs etc, and OMERO would handle the logic and
>>> return the feature table(s) matching those parameters. Since everyone has
>>> different requirements the keys could be anything, however we're trying to
>>> define a small set of standard keys- any suggestions are very welcome.
>>>
>>> Outside of OMERO we still need a format for transporting features, so
>>> we're thinking some form of HDF5.
>>>
>>> Simon
>>>
>>>
>>> The University of Dundee is a registered Scottish Charity, No: SC015096
>>> _______________________________________________
>>> ome-devel mailing list
>>> ome-devel at lists.openmicroscopy.org.uk
>>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>>>
>>
>>  <AZ_use_case.docx>
>>
>>
>>
>> The University of Dundee is a registered Scottish Charity, No: SC015096
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20131112/2fe95b67/attachment.html>