Michael Baudis

@blankdots @teemukataja As said, I think the concept of returning the different matched alleles looks good to me, but needs some work/discussion about the implementation: * There is a difference...

@blankdots Btw., those (list vs. object) are not equivalent since only a list allows repeated keys (making it harder to parse, but better as a wrapper).

I have written up a page about proposed [range matches and wildcards](https://beacon-project.io/roadmap/wildcard-range-matches.html), which also demonstrates a handover [[H->O]](/roadmap/handover.html) variant object, which in turn can be analysed for its variant flavours....

@sdelatorrep +1 There will be support for non-human data in the future (even plant data is on the roadmap). We'll soon launch a better documentation of the expected features.

@mcupak I would prefer to use "biosample_count", which would go along with the GA4GH (and general) "biosample" concept. This corresponds to the most relevant question (does this biological sample -...

@juhtornr So my use of "_count" would be incorrect, when using the counts observations concept, in which: * count => all records (biosamples, variants, callsets ...) * observations => matches...

While in personal use I'm all for "tags", a better way (when having the power to develop in a forward looking way) is to do this in a proper object...

@sdelatorrep Probably best to do this with concrete implementation. Also, evaluate then use of ontology terms (e.g. EFO) instead of arbitrary tags / typed values.

@jordi @dglemos The root cause here is the treatment of variants with the strange VCF concept where you are able to capture haplotypes for observations but each VCFvar (_i.e._ line)...

And a wish from my side: I'd rather love to have an explicit statement about entry type path element somewhere, e.g. in the form of ``` genomicVariant: entryType: genomicVariant pathElement:...