[ome-users] Questions about OME-XML and Java OME-XML library

[Curtis Rueden]

Hi Aaron,

Good to hear from you. Regarding what Andrew said about Image
requiring Pixels which requires either TiffData or BinData, that's
true, but you can always leave out the TiffData/BinData element to
have a metadata-only file. It won't valid with the current
specification, but something similar will be supported in the future,
as LOCI and others strongly want to adopt a similar approach in some
circumstances (e.g., storing an OME-XML metadata "companion file" to
augment information in a third-party file from a proprietary
acquisition system).

> ( 2 ) Are they supported in your Java OME-XML library?

The "levels" have been a subject of much debate at our OME meetings,
but we actually have very little decided as far as what the levels are
going to be, and how exactly they should work (numerical vs
categorical, etc.). The only level that we all agree on is "level
zero" or the base required information, which Andrew specified in his
email. Beyond that, you are free to include or exclude whatever
metadata you see fit, as defined within the specification. As such,
the Java OME-XML library does not have explicit support for the
levels. It actually does very little in the way of cross-checking and
verification to ensure your XML in its entirety will validate.

> ( 3 ) Can you store "arbitrary fields" (meaning without sticking to a
> specific OME-XML level) into a valid OME-XML file using your Java OME-XML
> library?

Yes, you can store whatever you want. You can also, as Andrew
mentioned, put things into the CustomAttributes, but the library does
not have any special logic to help you define the corresponding
SemanticType definitions necessary for your custom semantic types to
be properly recognized by OME. We plan to address this deficiency in
the future, at the same time we add a true OME-XML validation check to
the library (since just validating against the schema is, as Andrew
mentioned, insufficient to check the CustomAttributes blocks
properly).

> Assuming that all fields are defined in the XML schema, can you just add
> them, without sticking to a specific set of entries (e.g. a defined level)?

Essentially, the Java OME-XML library is just a big collection of node
wrappers around an XML DOM in memory. Each node contains getters and
setters corresponding to the attributes at that element. The library
does take care of OME-style ID references, so that for example you can
more easily jump from an Image to the Detectors it references, which
would require an explicit search through the DOM if you were not using
the node wrappers. These nodes are created "on demand," rather than
maintained in a mirror structure to the DOM, so they are pretty
disposable.

As Andrew mentioned, the library uses XSLT internally to transform
from "regular" OME-XML into the "CA-style" OME-XML defined in CA.xsd.
This version is a stripped down specification that stuffs nearly
everything into the CustomAttributes section, flattening the DOM and
easing machine processing, but is has some odd ramifications if you
scrutinize the node types intently (e.g., "ChannelInfo" becomes
"LogicalChannel" and other seemingly mysterious renames). In the
latest forthcoming version of the specification at which Andrew
hinted, much of this incongruity has been corrected.

The other thing to understand about OME-XML is that all of the
metadata fields are defined as OME semantic types using the OME
SemanticType definitions, for use with the OME (perl) database. This
fact is actually the real reason the XSLT stylesheets exist for
transforming between the regular and CA-style OME-XMLs: the database
(just like the Java library) uses the CA-style internally and
transforms everything to CA-style implicitly using the stylesheets.
The postgres database is actually a nearly direct mapping from
CA-style OME-XML to database tables. OMERO works a little differently,
but the OMERO guys are currently thinking about ways to accommodate
this model within the OMERO server.

Anyway, the reason I am going into all this detail is to point out one
last fact about the Java OME-XML library, which is that most of it is
actually autogenerated from the aforementioned metadata fields'
semantic type definitions. The good thing about that is that once we
have the XSLT stylesheets updated to reflect the new version of the
schema, it will be a simple matter to rerun the OME-XML Java library
autogenerator to produce a corresponding new version of the Java code.

The fact that we use XSLT in this way is a good indicator that your
plan of using XSLT to map between your tailor-made XML and OME-XML
should work well.

-Curtis

On 6/28/07, Ponti, Aaron <aaron.ponti at fmi.ch> wrote:
>
>
>
>
> Dear all
>
>
>
> This was initially a direct mail to Curtis and Jason, and Jason suggested
> posting it on the ome-users list.
>
>
>
> (…)
>
>
>
> In house we handle our data and associated metadata with a commercial
> package, and we are now interested in storing the metadata (only) in the
> OME-XML format. Each of our experiments has a quite large set of metadata
> associated to it, but the core information that we would like (at least
> initially) to store in XML is the following:
>
>
>
> Project = { Project name, Start date, Owner, Description, User }
>
> Experiment = { Experiment name, Start date, Organism, User, Experiment ID }
>
> Image = { x, y, z, Filename, AQ Date, Microscope, Objective, NA, Image File
> Name, Image file size, Image file date, User }
>
>
>
> This list is simply to give you an idea on what kind of information is
> relevant to us. Some basic information on the dataset structure (level 0?),
> plus some more on the experiment and project to which the dataset belongs.
> We have much more stuff stored in the database, but this does not need to
> end up in the XML file, at least in an initial stage.
>
>
>
> Now a couple of questions for you:
>
>
>
> ( 1 ) How far/completely have the different levels of the OME-XML
> specifications been defined?
>
> ( 2 ) Are they supported in your Java OME-XML library?
>
> ( 3 ) Can you store "arbitrary fields" (meaning without sticking to a
> specific OME-XML level) into a valid OME-XML file using your Java OME-XML
> library?
>
> Assuming that all fields are defined in the XML schema, can you just add
> them, without sticking to a specific set of entries (e.g. a defined level)?
>
> ( 4 ) Can you use custom-made XSLT stylesheets to map some XML scheme to
> OME-XML? (Our software already exports all entries from the database into a
> tailor-made XML file, and we would like to map it into OME-XML via XSLT).
> Can you also do the opposite (OME-XML -> some other XML)?
>
>
>
> The idea is of course to be able to create valid and portable OME-XML files.
>
>
>
> Thank you for any info you can give me.
>
> Aaron Ponti
>
>
>
> ----------------------------------------------------------------------
>
> | Dr. Aaron C. Ponti
>
> | Friedrich Miescher Institute
>
> | Facility for Advanced Microscopy and Imaging
>
> | Software development
>
> | Maulbeerstrasse 66 CH-4058, Basel
>
> | WRO-1066.2.32
>
> | Tel: +41 61 697 3012
>
> | Fax: +41 61 697 3976
>
> | http://www.fmi.ch/faim
>
> ----------------------------------------------------------------------
>
>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>
>