ga4gh-beacon
Extend the ELIXIR Beacon Network UI to support multiple Beacon
Progenetix Beacon+ was added to the aggregator that https://beacon-ui-beacon.rahtiapp.fi/#!/view queries
Great! Example:
- https://beacon.progenetix.org/beaconplus-server/beaconresponse.cgi?datasetIds=&referenceName=17&assemblyId=GRCh38&start=7577121&referenceBases=G&alternateBases=A
... works, but some errors in the response, info have to be ironed out.
Great! Example:
- https://beacon.progenetix.org/beaconplus-server/beaconresponse.cgi?datasetIds=&referenceName=17&assemblyId=GRCh38&start=7577121&referenceBases=G&alternateBases=A
... works, but some errors in the response, info have to be ironed out.
Here is how it looks at our UI
Why isn't the alleleRequest being interpolated? Is returned by the server:
{
"beaconId": "progenetix-beacon",
"alleleRequest": {
"start": "7577121",
"referenceName": "17",
"referenceBases": "G",
"alternateBases": "A"
},
"exists": true,
"datasetAlleleResponses": [
.....
}
Because the table displays response data, not request data. The table was devised from a need for wildcard differentiation, for example:
However, we will take your feedback into account, and make a fallback method to show bases from the request. It'll be added in the next update.
Related issue: https://github.com/ga4gh-beacon/specification/issues/223 Related PR: https://github.com/ga4gh-beacon/specification/pull/227
O.k.
However, the problem w/ directly delivering the variants in the response is that it easily gets out of hand, especially for wildcard range matches. While this may be partially an engineering problem, it will lead to rather unstable Beacon conditions; our small-dataset example query over the EIF4A1 gene already delivers 61 distinct variants and makes Cloudflare unhappy ... No such problem w/ retrieving the variants in a 2nd pass & processing them w/ a different tool.
So my strong recommendation is to de-couple the Beacon response & the delivery of additional info, through a handover mechanism. One easily can achieve the functionality w/ some asynchronous call I guess (Implementing a direct variant response is in principle trivial - see below - but it substantiated my dislike ...).
"variantResponses": [
{
"alternateBases": "A",
"count": 21,
"referenceName": "17",
"referenceBases": "G",
"start": 7577121
},
{
"alternateBases": "A",
"start": 7574003,
"count": 7,
"referenceBases": "G",
"referenceName": "17"
},
{
"alternateBases": "A",
"start": 7577539,
"count": 4,
"referenceBases": "G",
"referenceName": "17"
},
...
@teemukataja @juhtornr ... so if you want to build an interface which demonstrates/provides the functionality you have shown (and which is certainly nice for different use cases), I suggest that you
- either add your specific response to the
infoattribute & retrieve it from there, or - (better) find a way to do this using handover (i.e. your front end can do a 2nd call to fetch the variants when receiving a corresponding value in the handover part of the message)
There are many use cases where a search would lead to a humongous amount of variants; so deparsing them as default cannot be a good idea (if I query our datasets for all MYC duplications ...).
@mbaudis thanks for the suggestions - currently we are not using info key to add specific keys as the beacon specification does not set additionalProperties: false so in practice additional keys are ok - this is as you mentioned for demonstration purposes.
I do like the idea of using handover, however I might be missing the use of ontologies in the handover( i have read the https://github.com/ga4gh-beacon/specification/issues/114 and corresponding PR) - is their use to annotate (provide the vocabulary) of a specific handover type (or "further action"); in RDF terms the datasetAlleleResponse is the Subject, handover the predicate and the handover Type the Object ?
@blankdots Regarding ontologies: See my last notes on https://github.com/ga4gh-beacon/specification/pull/230. The example in the PR is a bit misleading so far, since it doesn't demonstrate a "technical/data" ontology (like the "id" : "http://www.ebi.ac.uk/efo/EFO_0004157", "label" : "BAM format" in my comment). So, this is the way to go; also adhering to SchemaBlocks structure.
Still: The use of an OntologyTerm object is a bit forward looking; and I'm all in for documenting the helpful abuse of the structure with "id" : "CUSTOM" or such for making your own ideas work (but don't tell to The Internet).
This issue should be in the repo where the UI code is. Can you @teemukataja take a look if this issue could be moved?
This issue should be in the repo where the UI code is. Can you @teemukataja take a look if this issue could be moved?
@juhtornr one has to be admin on both repositories to move issues. You are admin at https://github.com/CSCfi/beacon-openshift so you can do it.