example of nwb viz library API

nwbviz_example.py

from nwbviz import view, option


@view(requirements='DfOverF')
def rastermap(nwbfile):
    """ Generates a sorted raster map of calcium data
    
    https://github.com/MouseLand/rastermap
    
    Parameters:
    -------
    nwbfile : pynwb NwbFile instance
    
    Returns:
    -------
    ax : matplotlib axes
    """
    
    <...>
    
    return ax


@option('Lower bound',keyword='lower',default=0.0,help="Lower bound of window")
@option('Upper bound',keyword='upper',default=0.5,help="Upper bound of window")
@view(requirements=["DfOverF", "ImageSeries"])
def image_evoked_calcium_response(nwbfile,lower,upper):
    """ Calculates mean calcium response to each stimulus image.
    
    Parameters:
    -------
    nwbfile : pynwb NwbFile instance
    lower : lower bound of window
    upper : upper bound of window
    
    Returns:
    -------
    hv : Holoviews object
    """
    
    <...>
    
    return hv

@neuromusic @tarelli @bendichter

How about something like:

from pynwb.ophys import DfOverF

@view(requirements=DfOverF)
def rastermap(nwbfile):
    """ Generates a sorted raster map of calcium data"""

This takes the ambiguity out of the string, and might reduce a layer of parsing and maintainence on NWB Explorere

Yeah, this assumes that another part of the package handles the inspection into the nwbfile object to evaluate whether the requirements are satisfied. I'm not sure how @tarelli et al are doing that... I recall seeing a string like processing.<processing_module>.DfOverF in the presentation. If the DfOverF object class is sufficient to do that lookup, then I agree that @nicain's proposal makes sense. OTOH, if the "requirements" use case is more complex, we might need to maintain our own nwb query language (:nauseated_face:)

@neuromusic @afonsobspinto @nicain @bendichter Looks good, so you are proposing to remove the JSON file and use Python annotations instead? Regarding using direct references to packages for the requirements that might work for simple scenarios but as Justin points out it's likely we might have to have something more complex to specify these requirements (e.g. preference for the value of a given attribute) at which point that will break while in the other case we can make up some simple syntax or reuse some preexisting notation.

@tarelli yes, I suppose my proposal is twofold...

1. factor out the plotting functions themselves to a separate plotting library
2. replace the JSON with python decorators