API Outline V1

The full OMERO.features API should support storing and managing all the metadata that users require. In practice this is likely to take a while to define, so to begin with it would make more sense to start with a simplified API.

Initial design:

• Client-side Python library. Later this could be implemented server side with an Ice interface definition.
• Use OMERO.tables. This has some limitations, alternative storage methods will be explored later.
• Permissions: One table per user per group. The features client library will treat tables as read-only to everyone other than the owner irrespective of the actual group permissions. Full group permissions will be explored later.
• Columns: [Image id, ROI id, Features1, Features2, ....] The only metadata stored will be an Image ID and/or a ROI ID, and the names of features. This should support links to the most common data sources for feature calculations, and the ROI id should handle C/Z/T selections, albeit inefficiently. This will be improved later.
• Basic filtering/querying of rows. In practice this will initially be limited to a subset of whatever OMERO.tables supports.

Methods:

• create (featureset-name, [feature-names]) : Create a new feature store (corresponding to an OMERO.table)
• store (featureset-name, image-id, roi-id, values) : Store a row of features identified by Image ID and/or ROI ID, links the table to the image/ROI with a FileAnnotation
• fetch_by_image (featureset-name, image-id) -> values : Retrieve a single row of features by Image ID
• fetch_by_roi (featureset-name, roi-id) -> values : Retrieve a single row of features by ROI ID
• fetch_all (featureset-name, image-id) -> [values] : Retrieve all rows of features by Image ID (i.e. corresponding to multiple ROIs)
• filter (featureset-name, conditions) -> [(image-id, roi-id)] : Retrieve all row indicies (or maybe the contents of each row) where the features fulfill the criteria in conditions.