[ome-users] User Feedback

Jason Swedlow jason at lifesci.dundee.ac.uk
Wed Jul 22 20:07:16 BST 2009


Hi Jerome-

This is hugely useful feedback.

Responses in line.

On 22 Jul 2009, at 12:19, Jerome Avondo wrote:

>
> Hi,
>
> I had a long meeting with our users, here at the John Innes Centre,  
> about the OMERO platform and specifically the OMERO.insight and  
> OMERO.importer.
>
> This was to give them a good overview of the system, and try and  
> identify how it would fit with our use cases, with the ultimate goal  
> to get them to start using it.
>
> A couple points came up which I thought I would report back,
>
> Firstly, let me say overall impression is that it looks great, and  
> is something we want/will to adopt for the whole lab. :)

Ok, that is great.  Please keep all feedback coming-- we love it!

>
>
> Three main issues did however come up...
>
> 1) Project, Dataset...
>
> The Project, Dataset hierarchy was something people found quite  
> abstract, and did not really understand what this related to in  
> their day to day. And by this I mean they found it related to many  
> things, but just couldn't figure out what is, if any, the best way  
> to use this...
>
> Some cases were should Projects be the type of data it is, like  
> confocal, light microscopy, optical projection tomography or the  
> grant project or etc.. And then Datasets could be the type of the  
> experiment or species or probe imaged or etc...
>
> They found it very hard to relate these two entities to just single  
> real world scenarios... And people came up with many many different  
> ways this could be used...
>
> So maybe this is something the OMERO community can help us with.  
> What kind of things do you represent with the Project/Dataset  
> hierarchy, is there any "best practice" I can guide them with?
>

Yes, this can be confusing.  The fact is that there is no mandated way  
to use "PDI", and users are free to use it in any way that suits  
them.  For example, I use "Projects" to delineate high level classes  
of experiments, and Datasets to mean experiments.  One postdoc in my  
lab makes every experiment a diiferent Project, named by date, and  
individual experimental conditions (ctrl, siRNA, etc.) as Datasets.   
Both work, and are, as far as we know, just fine.

However, you can imagine that people writing analysis tools against an  
OMERO API would define some pattern of PDI for processing: process all  
images in a Dataset, or a Project, but not both.  My personal  
preference is that these applications should be mindful of the  
different approaches and support some flexibility (User chooses to  
process all images in a Dataset, or all images within defined Datasets  
in a Project).  As you know the OMERO API supports this.


> 2) Data sharing...
>
> In the lab we have a strong policy of data sharing, where the notion  
> of users does not really exist. For example we use a wiki to publish/ 
> report/talk about our finding, where everyone can see everything and  
> contribute to anything.

Sounds great.

>
>
> Likewise for our file store, this is a common network drive, where  
> no data is divided on a per user basis.
>

OK.

> This is mainly done for data longevity, in that when people leave,  
> we know where to find the ex-members data, as we all store our data  
> in the same way. As what we found was when someone left, if they had  
> their own personal way of storing data, then this would be very  
> difficult for anyone else to actually find it again. What makes  
> sense to you doesn't necessarily make sense to someone else, is the  
> motto here really...

Understood.

>
>
> So when looking at the OMERO.insight people where a bit worried how  
> each user can have their own data hierarchy, as this is something we  
> have tried to stay away from.
>
> What I thought we could do, was still manage the data on a per-user  
> level but also have a special single account for the whole lab, and  
> make sure all data is also kept in this common hierarchy, but there  
> might be better ways to address this.

OMERO supports this concept, and I suspect, you might like how this  
works.

>
> I also see that in OMERO.insight that Projects/Datasets/Images seem  
> to default as private. What implications does this exactly have? And  
> I can't seem to find any way to change this status to public.

You might remember OMERO-Beta3-- users within a group could see each  
other's data.  Some people loved this, some people really did not like  
it-- just not what they need.  So we needed to fix this.  For various  
technical reasons, we needed to switch all exisiting databases back to  
all private, and ensure that was all OK.  We did that in Beta4.0.   
That will enable us to allow users to set their own permissions in  
upcoming releases.

Once that is the case, you can set a separate account ("MyLab") and  
create new datasets by including images from other users within the  
group.  This just makes links, and doesn't create any copies of the  
images or associated data.

As you know, our priorities for 4.1 have been set on the DataIn/Out  
issues and DataDupe by the feedback from the Paris mtg.  We've been  
VERY focussed on all that.  We very much want to get the permissions  
available for users to start playing with, but need to make sure this  
is ready to go.  Once Josh and Jean-Marie are back from well-earned  
holidays, we'll talk about this and let you know where we stand.

>
>
> 3) Tags and importing...
>
> People understood the power of Tags, and really liked it.
>
> However there was some concern over how this happens after the  
> import, and that this was really a recipe for people just not  
> bothering to tag anything. People seemed to agree on at least a  
> minimum of what we called core tags, like what species it is, probe  
> used, etc.. This minimum is something that we found should be forced  
> on data import. To ensure all data has a minimum description. There  
> was also some concerns over how tags have to be added one by one,  
> and this can quickly become tedious so the idea of templates for  
> tags was something they liked.

You're not the first to mention this-- a number of others have brought  
this up as well, in many contexts.  Of course, there's the alternative  
view, that many have, summarised as "let me do what i want".

We very much want to look at this.  Maybe one way to start is to use  
OMERO.editor to define a set of tags that your lab will use.  It's  
templating functionality would be very good for that.  We have various  
ideas about extending the integration of editor and insight, and this  
might help drive that.  Of course, the BBSRC didn't fund our request  
for more funding for OMERO.editor, so we're trying to figure out what  
to do there.  Any feedback would be most welcome. If you think we  
should build an annotation workflow during import (for all the reasons  
you mentioned), let us know.

>
> That's really the main feedback I got at the meeting, the next  
> meeting we will be having is defining what tags we use. As this is  
> something we think we need to have a good stab at getting right from  
> the start.

Understood.

>
> Of course all I said here really only reflects how we would like to  
> use OMERO and I understand this does not reflect the whole community  
> as a whole. And the great thing is we can still implement our own  
> clients/importers to customize OMERO to our needs...

Exactly, that is what it fundamentally comes down to.  We never expect  
to be able to do everything.  Please let us know what we can do to help.

>
> But nonetheless I thought this would be useful to firstly give you  
> some feedback, and secondly check that we haven't misunderstood how  
> it should be used, so if anything I've said is something you  
> disagree with please do say so!

Nope, it's all great!

Thanks so much!  Gives us lots to discuss and mull over. Keep it  
coming.  Our best to all your users!

Cheers,

Jason

>
>
> J.
>
> _________________________________________________________________
> Celebrate a decade of Messenger with free winks, emoticons, display  
> pics, and more.
> http://clk.atdmt.com/UKM/go/157562755/direct/01/
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users



**************************
Wellcome Trust Centre for Gene Regulation & Expression
College of Life Sciences
MSI/WTB/JBC Complex
University of Dundee
Dow Street
Dundee  DD1 5EH
United Kingdom

phone (01382) 385819
Intl phone:  44 1382 385819
FAX   (01382) 388072
email: jason at lifesci.dundee.ac.uk

Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
Open Microscopy Environment: http://openmicroscopy.org
**************************

The University of Dundee is a Scottish Registered Charity, No. SC015096.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20090722/0c83cf26/attachment.html>


More information about the ome-users mailing list