Let the users to give a selection of location labels to target

[filimarc]

For some cases it could be usefull to select a group of different locations instead of just one. For the example if for a devices i would like to target both soma and dendrites it is not possible at the moment.
For this reason i suggest to change the LabelTargetting from using an all to an any, for label check:

class LabelTargetting(LocationTargetting, classmap_entry="label"):
    labels = config.list(required=True)

    def get_locations(self, cell):
        locs = [
            loc
            for loc in cell.locations.values()
            if any(l_ in loc.section.labels for l_ in self.labels)
        ]
        return locs

[Helveg]

this was a breaking change 🥲 we should've added a flag, because now selecting only the dendrites+apical_dendrites isn't possible anymore

[drodarie]

Sorry that is on me. I did notice the change of behavior but thought the expected behavior was the new one, hence a fix. Should have double checked with you

[Helveg]

There's an equally big "should have documented this" on me ;p Is there any guide/docs on the targetting? We could document the intended behaviour there.

We can now also decide how we deal with fundamentally boolean label operations (here we're basically discussing whether we want to implicitly treat nodes as (L1 OR L2 OR L3) or (L1 AND L2 AND L3)). Labels appear IIRC on the level of cells and morphologies. We can for example see if there's readily available boolean parsers that could process strings such as (basal_dendrites OR apical_dendrites) AND not_tip; Arbor for example has a whole morphology DSL, which I think users can already leverage to create pretty darn powerful labels when they use the arbor morphology parser.

Since we allow so many ways of creating labels, including the option of arbitrarily labeling via Python components, I think a much simpler set of just grouping (with ()) and combining (with AND or OR) would suffice, since technically the user can already express everything by creating an new label that encompasses their desired combination.

What I mean is that we actually shouldn't even support multiple label targetting, because we could demand of the user that they create a label that includes their multiple labels, and then just target that single label 🤷 e.g.:

• User makes label A
• User makes label B
• With multi label targetting:
  • User specifies label A and B (with currently ambiguous boolean logic)
• Without multi label targetting:
  • User wants A + B so user chooses to create label C as either A AND B or A OR B
    • Either as part of a morphology pipeline for morphology labels, or as a post-placement hook for cell labels.
  • User uses label C unambiguously

I think the essential trade off is one of user experience versus burden of maintenance, and I think if a stock standard boolean string parser is available that it can be much more comfortable than to have to write a label-combining component for simple things.

[Helveg]

PS: Sorry for the long post, I guess the solution at interim is to either revert this, or a quick flag to choose between AND/OR if this has an urgent use case

[filimarc]

Hi,
I understand the necessity of resolving the ambiguities. The documentation currently does not cover Location Targeting, so the expected behavior is not clearly defined and i apologise for that.

To address the issue, my humble opinion is:

• It is not that urgent, so it's okay to revert the change for now. I will come back to implement a better-defined solution, probably next month.

• I’m not in favor of requiring users to create a specific label for every case — the boolean parsing approach seems better