Key-value pairs
===============
Ongoing advancements in microscopic techniques, analysis
systems, and other areas for which OME attempts to provide
metadata exchange require a certain flexibility in the OME
model. There is a need to store instrument configuration,
script parameters, and similar for later use.
Basic text representations are too difficult to parse to be
of significant use. An XML format can be more easily parsed,
but a single format would have to be agreed upon by all
users. Therefore, it is useful to add particular extension
points to the model for which no consensus on a data format
has been reached, but where more structure than just text is
needed.
A `hash map` was the most likely candidate for this
data; however, rather than limit this to traditional
associative arrays, OME maps are defined as a
**"ordered list of key-value pairs"**. The benefit of
this representation is that configuration files which are
standard for Java ``java.util.Properties`` objects can be
represented fully in a single map. Duplicates are maintained
since there is no unique constraint on the list of pairs.
In most cases, the interpretation of the ordered list will
be such that the final value for a particular key "wins" as
if each value were placed into a hash map in order, with
duplicate values replacing previous ones.
OME-XML
-------
In the OME-XML model, these maps are represented in a compact
format. Any map field is defined by the MapPairs complex
type which consists of M elements of the form:
::
value
OMERO languages
---------------
In OMERO, a slightly more verbose representation of these
objects is used. Each map type consists of a list or vector
in the respective language, composed of NamedValue objects
and possibly nulls.
::
// OMERO.java
ImagingEnvironment environment = new ImagingEnvironmentI();
environment.setMap(new List());
environment.getMap().add(new NamedValue("altitude", "1000m"));
image.setImagingEnvironment(environment);
Fields
^^^^^^
The concrete fields which are present in the model are
currently:
* ExperimenterGroup.config
* GenericExcitationSource.map
* ImagingEnvironment.map
* ImportJob.versionInfo
More will be added as demand increases.
MapAnnotations
--------------
In addition to the fields above, there is also a
:doc:`structured annotation `
which contains a key-valued pair, the ``MapAnnotation``.
::
// OMERO.cpp
MapAnnotation ann = new MapAnnotationI();
ann->getMapValue().push_back(new NamedValueI("run", "5.0"));
ann->getMapValue().push_back(new NamedValueI("run", "4.9"));
ann->getMapValue().push_back(new NamedValueI("run", "5.1"));
This permits the flexible attachment of key-value pairs to
any of the OME types which are annotatable. Such annotations
attached to key UI elements like images and datasets will be
presented by the clients, and can be edited with the
appropriate permissions. See :help:`Managing Data
` on :help:`OMERO User Help<>`
for more information.
Storage and queries
-------------------
Each map-based field in the OMERO model is represented by an
extra table of the form `$className_$fieldName`. For example,
MapAnnotation.mapValue becomes `annotation.mapValue`, where
the loss of "map" from the class name is due to the subclassing
of `Annotation` by `MapAnnotation`.
In general, use of the specific tables is not necessary and
it suffices to write HQL queries based on the classes and
field names themselves.
Find the value for a key
^^^^^^^^^^^^^^^^^^^^^^^^
::
select nv.value from MapAnnotation ann
join ann.mapValue as nv
where nv.name = 'altitude'
Finding objects with a key
^^^^^^^^^^^^^^^^^^^^^^^^^^
::
select ann from MapAnnotation ann
join ann.mapValue as nv
where nv.name = 'altitude'
Finding objects **without** a key
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
::
select ann from MapAnnotation ann
where not exists(
from MapAnnotation m2
join m2.mapValue as nv2
where nv2.name like 'size%')
Finding objects with multiple values
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
::
select ann from MapAnnotation ann
join ann.mapValue as nv1
join ann.mapValue as nv2
where nv1.name = 'date'
and nv2.name = 'owner'