Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Handover method for data access #114
As was discussed previously and with some assigned future spot on the Beacon roadmap, there is general consensus about the need to implement a specification for a handoff protocol. The arguments supporting this development can be summarized as:
As starting point for discussions on the merits of this concept and how to implement it, we have prototyped a very basic version of a handoff concept (without use of a proper authentication procedure):
As part of the Beacon specifications, it should probably be sufficient to define an attribute name/format for the access handle; authentication etc. would be for demonstrators, "discovery" product ... but probably out of scope for the Beacon protocol itself (?).
changed the title from
Proposal: Handover method for data access
Handover method for data access
Mar 7, 2018
Working assumptions for the structure of the Handover protocol extension now are that:
As reminder, a simplified implementation has been prototyped for the Beacon+ resource and is conceptually documented here, though the format of the Handover object is assumed to be an object instead of the
@mbaudis what if the object lives on a different server from the one that is generating the response?
Here, is the access key used to ID the object or does it comprise the authentication information required to fetch it, or both?
What about having a
Can you provide an example of how the authentication procedure would be provided? I agree that this would be very helpful to encode as a hint, just wondering how you'd approach it.
@mfiume I don't think that this would be part of Beacon, but the general idea would be that the "handoff" key would point to whatever action is then executed. It doesn't really matter which server the data resides on; this is resolved from
Sure, the handover object could be a
Authentication could be provided in OAuth etc., and the resolver would match credentials to access rights. This would allow the layered access of public beacon query + limited data retrieval.
Our testbed implementation
In our current implementation, the
Now data can be retrieved by creating different style queries from this.
... would deliver the document shown. This has its own:
If you now follow the original GA4GH schema, you can retrieve e.g. all biosample ids by querying:
... etc., and the get the biosample data; similar for all variants from the matching callsets etc.
But this requires a standardised data structure in the
It is all rather trivial, if keeping to the basic principles of a schema which had been developed over years, without enforcing some of the more esoteric "recapitulate VCF column format" ideas of it.
Updated scenario: Providing a url + label handover list for direct access to the identified resources;
We have now implemented this scenario, for "one click" actions, based on the variants/callsets/samples identified in the Beacon query.
Example (this is the excerpt from the Beacon response):
added a commit
Nov 6, 2018
@sdelatorrep I would suggest adding also a
Also, this would be an interesting scenarion in which we have to decide if we should implement the general