search

ireceptor-plus / specifications

Central repository for all iReceptor+ specifications
0 stars 0 forks source link

Add a productive filter parameter #7

Closed bcorrie closed 4 years ago

bcorrie commented 4 years ago

Closes #3

bcorrie commented 4 years ago

@schristley @bzimonja @jeromejaglale is this a horrible way to do this? (See https://github.com/ireceptor-plus/specifications/pull/7/commits/521ef42412e8aff8b395e2968f69b9b25ccc8d12)

Essentially each entry point performs stats of a different type (e.g. gene_usage). For each type of stat (e.g. gene_usage) there is a specific type of stat the user is interested (e.g. v_call). In addition to the normal stats like v_call, the user can also ask for an important and commonly used stat, such as v_call_productive.

All stats at this level are a controlled vocabulary (so they are fixed) but because it is a controlled vocabulary, we can add new "stats" of a specific type by simply adding a new controlled vocabulary term. I think this is better than having to extend the spec with a "productive":true flag.

Thoughts?

bzimonja commented 4 years ago

I like it because it somewhat simplifies the data structure for stats, at a cost of adding more data to it. I right now use the format

This way I can remove total_productive and simplify the data model, or keep it there for performance/space saving reasons and have service keep track of which return value is needed.
bcorrie commented 4 years ago

@schristley are you OK with this as the approach for the alpha release? We can try this for the M24 milestone, and then change afterwards if we think it is problematic...