Skip to content

[TO BE DEPRECATED] A plugin developer’s guide to categories on the napari hub

Jump to bottom
Draga Doncila Pop edited this page Sep 19, 2023 · 1 revision

Note categories in config.yml are being deprecated in favour of the categories in the npe2 manifest. This guide is here for legacy purposes only.

The napari hub lets users explore napari plugins based on the Imaging Modalities they are relevant to, the Workflow Steps they implement, and the Data Dimensions they support. We do this by offering filters on search listings and based on the plugin developer’s own annotations of their plugin selected from terms in the EDAM Bioimaging ontology.

This guide orients plugin developers to the information architecture we implement and how to label their plugin so that it can be viewed using categories.

preview of categories filters

Information architecture design principles

A few key principles guided the design and development of the information architecture of feature:

  • Categories with very few or too many plugins aren’t very useful for napari users
  • The plugin ecosystem is growing quickly and today’s ideal partitioning may not be ideal six months from now
  • Plugin developers should need label their plugin infrequently... Ideally, no more than once unless they add functionality
  • Most napari plugins today are designed for bioimaging, but we hope and anticipate that the ecosystem will grow beyond

To support these principles

  1. Plugin developers can tag their plugin with terms from the EDAM Bioimaging ontology at whatever level of detail is relevant to their plugin
  2. On plugin pages, we will display everything that the plugin developer specified
  3. We will provide filters on the search page which represent pruned branches of the EDAM Bioimaging ontology, which will filter for all children of the corresponding EDAM term
  4. As the plugin ecosystem grows, we will revise the prunings as necessary to ensure that categories are relevant to napari users
  5. As the plugin ecosystem expands beyond bioimaging, we will explore supporting other areas of imaging with domain-relevant ontologies

Labeling your plugin

On the napari hub search page, we present filters for Imaging Modality, Workflow Step, and Supported Data that map onto corresponding terms in the EDAM Bioimaging ontology.

To label your plugin, you must specify in your .napari/config.yml file the relevant EDAM labels at whatever depth of the taxonomy is most appropriate for your plugin. You are able to specify any number of EDAM labels for their plugin... there is no limit.

For each of these filters, we will present categories to users of the napari hub based on the plugin developer’s own annotations of their plugin, selected from portions of the EDAM Bioimaging ontology. While a plugin developer can (and should) label their plugin at whatever depth is most relevant, we will “prune” the branches of the ontology and filter all plugins which are children of the selected category.

Example

For example, imagine a plugin which implements a pre-trained deep learning model for 3D segmentation of cells from fluorescent imaging data.

The plugin developer would label their plugin by adding the following to their .napari/config.yml file:

labels:
  ontology: EDAM-BIOIMAGING:alpha06
  terms:
  - 3D Image # Data Shape
  - Cell segmentation # Processing step
  - Model-based segmentation # Processing step
  - Fluorescence Microscopy # Imaging Modality

Then, on the napari hub if a user filtered by “Image Segmentation” under “Workflow Step”, all plugins including any type of segmentation in their EDAM terms would be displayed, including the above example (because both “Cell segmentation” and “Model-based segmentation” are children of “Image segmentation”)

Future directions

We recognize that this information architecture is incomplete and will need to be improved, extended, and iterated upon.

Improving the ontology

We currently support the alpha06 version of EDAM Bioimaging only. We hope to work with the EDAM Bioimaging team to improve the ontology to ensure that it works well for napari hub users and napari plugin developers. As new versions of EDAM are released, we will hope to extend support to newer versions.

Categorizing based on plugin type, filetype support, and more

Imaging Modality, Workflow Step, and Supported Data simply aren’t relevant to many plugins, such as those that provide additional utilities or generic file reading and writing support. We currently are planning to add support for Plugin Type and File Type Support, leveraging the new npe2 specification and will continue to explore ways to organize utilities and visualization tools whose functionality isn’t well captured by EDAM Bioimaging or the npe2 specification. If you’d like to see this or have thought on how the napari hub would best support categorizing plugins of these types, please reach out on our Discussion forum.

Extending support for domains beyond bioimaging

We recognize that napari is useful far beyond bioimaging and we’re eager to improve support for other scientific domains. Ideally, we will be able to do this by adding support for additional ontologies that are relevant to other imaging domains. If you’d like the napari hub to support your domain, please reach out on our Discussion forum.

Clone this wiki locally