[ome-users] Data modeling for integration into OME

[josh.moore at gmx.de]

Gerald Fontenay writes:
 > Hi,

Hi Gerald.

 > We have been looking at OMERO, and we are excited about the prospects of
 > using it.

Great! Let's see what we can do to help...

 > We already have some modeling in several relevant domains and we seek
 > advice on what the best course of action might be in transforming these
 > models for integration into OME.

Is this related to the BioSig software? Specifically
http://vision.lbl.gov/Resources/UML/ (blame Google) I was trying to
get an idea of what the models look like that you would like to work
with.

 > We are familiar with the "older" semantic types. Over the next year or
 > so, will the use of semantic types for getting types into the system
 > persist, or will POJO modeling replace it?  In case it may matter, the
 > domains have to do with experimental design, imaging parameters, and
 > feature analysis results.

The semantic types as you know them will not be ported to use in
OMERO. Instead, the OMERO server design has focused to date on
providing a fast and accessible data management solution across
multiple programming languages (Java, C++, Python; to come: Ruby,
.Net, PHP).  To do that, the flexibility of the Perl semantic types
was omitted, but with the intent that analysis capabilities, more
complex types, and links to external data and ontologies (GO, et al.)
would be layered on top of this foundation.

At the European OME Users meeting in March, there was much discussion
on just how the analytical results could and should be
represented. We're now getting to that phase of the project and so it
would be good to have your input, but a quick summary amounts to that,
often, storing blobs in the system -- which is currently possible --
will provide many analysis tools with a strong starting point. Over
time, as the structures become more widely used, they can become a
module within the OMERO system.

And this happens via the "POJO modelling" that you mention, only that
in OMERO it occurs via an abstract description (currently XML) which
is the input to a good deal of code generation. The disconnect with
the semantic types system is that this cannot happen on the fly. Not
only must the server be restarted, but all clients must have the
changes propagated to them (think a new libOMERO.so for
example). Depending on your infrastructure (BioSig apparently uses
Struts) this may be feasible, but it's not currently "supported". And
in some ways, such changes make multiple OMERO installations less
compatible.

If you'd like to take that route for your own needs, it's currently
possible and I can walk you through it. But it'd be good to have an
idea of your particular use case before making a suggestion.

 > Thanks in advance,
 > Gerald Fontenay
 > gvfontenay at lbl.gov

More than welcome. Looking forward to talking to you.
~Josh