Michael Baudis

Variant info

13

The VCF specifications express a number of (optional) variant parameters through use of the `INFO` field. This is e.g. necessary for the representation of any structural variant (`END`, `SVLEN`, `CIPOS`,...

In the first example the nesting of the `referenceRange` element is wrong; it should be an attribute of `quentity`.

The [Wiki](https://github.com/ga4gh-beacon/specification/wiki) contains old and potentially misleading documentation (e.g. links to pre-v1 tooling and information). Valid documentation should be consolidated on the website and the schema documentation page(s), and removed...

mentioning range matches for start + end

2

While we have shown range matches and wildcards in demonstrations, so far the `start` + `end` documentation only mentions structural changes. This has been extended.

Catalogue of query examples

1

Especially with the upcoming filters, but for CNV, wild card and range matches, we need to provide a catalogue of query examples supported through the current protocol version (and then...

Beacon queries should be extended for Boolean variant queries, to allow genomic context depending variant discovery. A typical example from cancer would be a query Find all variants in `biosamples`...

Move dataset_ids to separate message

2

the current BeaconAlleleResponse message embeds the optional specification of dataset ids. With a foreseeable move to multiple variant and metadata message query types, it seems logical to have the datasets...

Inconsistencies in `beaconMap` between entry types and paths (run, analysis)

7

The `beaconMap` schema has a number of inconsistencies in the `endpoints` definitions which preclude its use for determining path entry type relations. Starting here: https://github.com/ga4gh-beacon/beacon-v2/blob/afaf76ac3e4ce6c48fa5da571b7883046ccef020/models/src/beacon-v2-default-model/beaconMap.yaml#L19 ``` runs: returnedEntryType: run url:...

Informational field for filtering terms

7

IMO the best (and non-breaking) improvement for filtering terms would be to add a `modelPath` (naming suggestions welcome) _informational_ field which indicates against which field **in the beacon default model**...

In endpoints.yaml/.json for cohorts and datasets the /{id}/ request should be served by a `beaconCollectionsResponse` (or summary responses)

9

https://github.com/ga4gh-beacon/beacon-v2/blob/75850c3f19816ee05d4fd67d39811f9c5a6a8f29/models/src/beacon-v2-default-model/datasets/endpoints.yaml#L63 This picks up where some back-and-forth discussions in #116 started and rephrases this as the minimal issue. In short, since we use a separate `beaconCollectionsResponse` response schema for record-level...