[ome-users] OME: Putting it all together (take 1)

[Ilya Goldberg]

On Jul 19, 2005, at 11:34 AM, Graham Klyne wrote:

> Now that I'm getting an inkling of how OME ticks, this message  
> outlines my emerging plan for configuring OME to serve our  
> requirements for image collection and annotation.
>
> 3. Proposed organization
>
> All datasets to be organized under a single project.
>
> Each experimenter to have a separate OME login, so that experimenter  
> information can be captured automatically by OME.  (Are there any  
> pitfalls here if experimenters want to search across other's  
> datasets?)

OME's access control is implemented very similarly to how its done in  
UNIX.  The rules are listed here:
http://cvs.openmicroscopy.org.uk/tiki/tiki-index.php? 
page=Simple+DBObject-level+access+control
Briefly, if you want a group of people to access each other's data, you  
put them into the same group.  People can belong to more than one  
group, but anything they create is (by default) assigned to their  
'primary' group.  Ownership can be edited using 'ome admin data chown'.
In subsequent releases, all objects are owned by the person who  
executed the MEX that created them (this is slightly different in  
2.4.0).

> Each dataset to contain images from a single slide.  Thus, the dataset  
> description can contain information about the slide identifier.  (It  
> might also be handy to include the gene name/identifier that is common  
> to all images from a slide, but categories don't seem to apply to  
> datasets, so that may not be an option).  The choice of one dataset  
> per slide seems to be operationally convenient.  (There may be  
> requirements to add further images from a given slide at a later date;  
> does OME prevent this? I vaguely remember reading something that  
> suggested it might).

I would recommend assigning image-pertinent information directly to  
images rather than to the group(s) they belong to.  A gene for example,  
is more a property of a given image than it is a property of a group of  
images only.  The gene that you visualized in the image doesn't change  
depending on which group you're looking at.

>
> Each image to be annotated with:
> - gene identifier (if this can't be "inherited" from the dataset in  
> some way).

It can be copied from the dataset certainly - especially in order to  
set a default in the UI.

> - strain identifiers (as categories would be neat, but the mutual  
> exclusion is a problem.  I might be able to use a category for the  
> "main" strain, and annotations for additional strains.

We're having the same problem with genes and strains.  Genes and  
strains have a many-to-many mapping (genes can be associated with more  
than a single strain, and strains can be associated with more than a  
single gene).  This is also somewhat true of probes, though usually a  
probe is chosen such that it associates with only a single gene.  The  
idea is to declare genes, strains and probes as STs, and also declare  
two associations.  The gene-probe association and the gene-strain  
association.  The associations can be populated in-bulk by slurping up  
parts of an external DB.  The strain/probe is annotated at import, and  
later on, once you have the associations, a display of a given image  
can include hyperlinks to the external datasources that describe the  
genes/strains/probes that its associated with.  The other reason for  
the ST is that you probably want OME to maintain how to construct the  
linkage to the other datasources.  We haven't done a lot of exploration  
what would work best here, but there are several options from including  
the URL in the gene/probe/strain data type to constructing the URL from  
the gene/probe/strain using a custom HTML template.

> - objective and optivar magnification details to be entered as  
> instrument details if possible, or as a separate custom annotation  
> using a new semantic type.

Reusing STs is the name of the game to achieve interoperability easily.  
  If you don't re-use STs, then interop only happens if you also provide  
a translator.

> - developmental stages showing expression to be drawn from a fixed  
> vocabulary (based on GO).  Each possible stage to be a CategoryGroup,  
> each with Categories corresponding to Yes/No.  Thus any combination of  
> development stages can be captured and used as basis for grouping.

A given image would not be associated with more than one development  
stage, would it?
If you have a CategoryGroup called "Development Stage", and within it  
are Categories one-per-possible stage, then you have a datamodel that  
would seem to fit better.  Maybe I don't understand what you mean here.
Technically, the limitation is really that the sum of the confidences  
that a given image is classified with into various categories of a  
given category group does not exceed 1.0.  Currently, manual  
classification presumes a confidence of 1 for each classification,  
which makes it mutually exclusive.  However, that's not necessarily so.  
  So if you think that an image is actually at a stage between two  
defined development stages, that can be represented as well.  All that  
needs is a different UI.

>
> This approach seems to require making several separate classification  
> annotations, which might be a bit inconvenient.  An alternative would  
> be to create a new semantic type and a new data entry template to  
> gather all the required information on a single screen per image.

a customized annotation template with a single screen per image is  
exactly what we're trying to accomplish.


>
> ...
>
> Does this outline proposal expose any fundamental oversights I may  
> have concerning the way OME works?  Thanks again for any insights.
>
> #g
>
>
> ---
> Graham Klyne
> Image Bioinformatics Research Group (http://www.bioimage.org/)
> Department of Zoology, University of Oxford
> South Parks Road, Oxford OX1 3PS, UK
> E-mail: <Graham.Klyne at zoo.ox.ac.uk>
> Direct phone: +44-(0)1865-281991
> Departmental fax: +44-(0)1865-310447
>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>