Open mfiume opened 4 years ago
@mfiume The currently working way would be to use a handover item (i.e. link object) to point to a data file/stream. You could stick with GA4GH specs by providing then the clinical ... etc. data as phenopackets (or FHIR .... etc.; anything with a GA4GH blessed standard).
IMO the next step for authenticated Beacons v2 is to provide phenopackets directly in a response; I'm not a fan of this (i.e. any direct response which goes beyond variant data), conceptually, but maybe.
Now, if there are other standards blessed by GA4GH, you can push them to an {S}[B] repo; and then they become "reusable", e.g. for Beacon responses (so v2 supports this kind of payload).
Michael answer is correct. I’ll strongly suggest start looking in the crystalizing Beacon v2 spec. We can help.
Best!
Jordi
From: Michael Baudis [mailto:notifications@github.com] Sent: Friday, 20 March, 2020 15:52 To: ga4gh-beacon/specification specification@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [ga4gh-beacon/specification] Consider using SchemaBlocks as payload (#298)
@mfiumehttps://github.com/mfiume The currently working way would be to use a handover item (i.e. link object) to point to a data file/stream. You could stick in the GA4GH specs by providing then the clinical ... etc. data as phenopackets (or FHIR .... etc.; anything with a defined standard).
IMO the next step for authenticated Beacons v2 is to provide phenopackets directly in a response; I'm not a fan of this (i.e. any direct response which goes beyond variant data), conceptually, but maybe.
Now, if there are other standards blessed by GA4GH, you can push them to an {S}[B] repo; and then they become "reusable", e.g. for Beacon responses (so v2 supports this kind of payload).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/ga4gh-beacon/specification/issues/298#issuecomment-601740577, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB5SEOT2ZKTOWNSZ6BXXHSLRIN7KLANCNFSM4LQNB3AQ.
@mfiume Also with regards to yesterday's call - Some of the issues (e.g. what data v2 is supposed to support in protocol, how you can already use {S}[B] for payload formatting…) are already being addressed; so it is just a question of exploring the documentation & if needed discuss specific needs, improvements, changes:
Biosample
(draft)GeoLocation
(e.g. for COVID19 Beacon...)Disease
specificationSo I think a bit of "proactive alignment" could drive things nicely - challenge & improve what is being developed at the default standard repos!
For clinical and other kinds of beacons (e.g. an infectious disease beacon we created), it is difficult to return structured data (e.g. patient records) as a flat list of string-only key-value pairs via the info property. Can we consider leveraging SchemaBlocks as a way to return custom or standardized data models in the Beacon payload?
@mbaudis @jfuerth @mcupak