-
Notifications
You must be signed in to change notification settings - Fork 5
API Outline
As far as users are concerned features will appear to be stored as 2D tables in which each cell contains a fixed-length array, and rows and columns each have a map of key-value pairs storing the metadata.
+---------------+-------------------+-------------------+---+
| | [FeatureSetMap-1] | [FeatureSetMap-2] | |
+---------------+-------------------+-------------------+---+
| [SampleMap-1] | [0,1,2,3,4,5,...] | | |
+---------------+-------------------+-------------------+---+
| | | | |
+---------------+-------------------+-------------------+---+
\[FeatureSetMap-1]:
{
FeatureSet: OME-FeatureSet ABC
FeatureSetParent: OME-FeatureSet
Version: 1.0
Parameter-a: 0.2
Parameter-b: 'abgh'
...
}
\[SampleMap-1\]:
{
ImageID-1: 123
ImageID-2: 456
...
}
Features will be retrieved by providing maps of column and row key-value pairs which will be matched against the stored features.
Storing features will require passing two maps, one to describe the sample and one to describe the FeatureSet, along with the actual feature values. To make querying easier some "well-known" keys will need to be defined, which either must be provided when storing features, or should only be used for a well-defined purpose.
The actual implementation of this API in OMERO is still being investigated. The main issue is that the storing and querying of metadata has very different requirements to the storage and retrieval of feature arrays. Posts on the ome-development email list suggest this is a common problem which remains unsolved, with many users deciding to use two separate storage mechanisms, effectively requiring a join between two databases. See for example:
See also:
- OMERO Metadata Storage for ideas on implementing this in OMERO.
- OMERO Tables Implementation for a possible implementation using OMERO.tables.