Idea: non-logical restrictions for variable fillers

[balhoff]

This just came up in a Monarch all hands discussion; not sure how useful or required it may be. But someone may want to specify a 'slim' or some other annotation as a way to restrict available terms.

[dosumis]

Already possible with data_vars & data_list_vars.

…

On 27 Feb 2017 20:55, "Jim Balhoff" ***@***.***> wrote: This just came up in a Monarch all hands discussion; not sure how useful or required it may be. But someone may want to specify a 'slim' or some other annotation as a way to restrict available terms. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#25>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG4x2W7laBasA6UrCJ67F6rHeF2vRUVks5rgzhCgaJpZM4MNnWM> .

[balhoff]

I think we might be talking about different things, but please correct me if not. I mean that if someone has these variables in their pattern:

vars: 
  membrane: "'membrane'"
  cargo: "'chemical entity' or 'macromolecular complex' or 'transcript'"
  start: "'cellular_component'"
  end: "'cellular_component'"

Instead of saying that start needs to be a logical subclass of cellular_component, they may want to say that all fillers for start need to be in some slim (i.e. all allowable classes have a particular in_subset annotation value).

[dosumis]

OK. Got it now. Can't think of a clean way to do this within the vars dict given that the range is specified as a Manchester Syntax class expression. Also wouldn't want to clutter the core spec with something so specific. I guess we could add a new variable dictionary in the OBO extension - vars_by_subset ?

I'm not keen on this use-case though. The design pattern approach is meant be logic-based. Subsets can be added to anything, so it would be easy to end up with nonsensical outputs.

[balhoff]

I think you're right about possible problems with non-logical groupings. I'm going to close this.