Closed mcupak closed 7 years ago
jrambla
commented
8 years ago Keeping the version inside the ConsentCodeDataUse allows you to fully detach the ConsentCodeDataUse without impacting the BeaconDataset itself. This is parallel to any other concept that we like to plug into the Beacon elements. Also, you are not having the version of the ConsentCode, but the one an specific dataset is using, thus I guess this is fine. My 2 cents.
antbro
commented
8 years ago +1
Tony
From: Miro Cupak [notifications@github.com] Sent: 03 May 2016 15:39 To: ga4gh/beacon-team Subject: [ga4gh/beacon-team] Move version field from ConsentCodeDataUse to BeaconDataset (#46)
I think the version field from ConsentCodeDataUse should not be inside ConsentCodeDataUse. It's a version of the consent code specification the beacon uses, which might eventually be developed in a separate repository and released as a separate artifact. As such, the dataset should contain the version, which would refer to the version of the artifact. Similarly, different data use systems would have a version field there.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/ga4gh/beacon-team/issues/46
mcupak
commented
8 years ago +1 from Marc
mcupak
commented
8 years ago Prerequisite: https://github.com/ga4gh/beacon-team/issues/22
+1 for including in v.0.4.0.
antbro
commented
8 years ago I did previously +1 this, but now suspect I may have misunderstood the issue
Two objectives are in play:
1) within a data use condition (CC, ADAM, or whatever) the version of that spec used needs to be stated, so that the condition is modular and can be used in different places/ways
2) We might decide that Beacon needs to limit itself to only one version each of ADAM, CC, etc, in which case the version would need to be in BeaconDataset. [or we might not limit in this way?]
So the critical issue is whether we want to limit Beacon to one version each of ADAM, CC, etc. I'd rather not have such a limitation (unless we absolutely have to for some reason), and so would therefore only see #1 above as pertinent - in which case I would withdraw my +1 and leave the the version number in the data use module itself
Cheers Tony
From: Miro Cupak [notifications@github.com] Sent: 14 June 2016 04:29 To: ga4gh/beacon-team Cc: Brookes, Anthony J. (Prof.); Comment Subject: Re: [ga4gh/beacon-team] Move version field from ConsentCodeDataUse to BeaconDataset (#46)
Prerequisite: #22https://github.com/ga4gh/beacon-team/issues/22
+1 for including in v.0.4.0.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ga4gh/beacon-team/issues/46#issuecomment-225770814, or mute the threadhttps://github.com/notifications/unsubscribe/AI_EVDIFAnUJc0JjiB9tgyrndwsujAL7ks5qLiALgaJpZM4IWSN-.
jrambla
commented
8 years ago -1 in just having the DUC version at the Beacon level, because this is not "true" in cases like the EGA,where we are having different submitters, each own submitting at different points in time and not necessarily (hardly) updating the DUC Profiles when new versions of DUCs pop up. It will be like forcing a Beacon to just use one version of the Reference Genome...
jrambla
commented
8 years ago I have another aspect to consider... @antbro Should we consider versions of the Profiles? Are we expecting that data owners would evolve their profiles, thus we can face a situation where a user has done a request and get a DUC profile and a later request (some days later) on the same dataset could receive an "updated" profile? (I guess this is relevant for auditing and "liability" aspects)
antbro
commented
8 years ago Hi Jordi. Good point. It is imagined that profiles will sometimes be changed. In ADA-M v1.0 this is captured in a Header section, via two fields "Matrix profile creation date" and "Matrix profile updates" [these are distinct from the "Matrix version" field in the Header, which we have been discussing]. So basically we're capturing the profile version by creation date and update date list info, not a 'profile version' as such. So I guess the question is whether or not these two date fields, as well as the Matrix version field, might need to be replicated in the Beacon API body
From: jrambla [notifications@github.com] Sent: 15 June 2016 08:52 To: ga4gh/beacon-team Cc: Brookes, Anthony J. (Prof.); Mention Subject: Re: [ga4gh/beacon-team] Move version field from ConsentCodeDataUse to BeaconDataset (#46)
I have another aspect to consider... @antbrohttps://github.com/antbro Should we consider versions of the Profiles? Are we expecting that data owners would evolve their profiles, thus we can face a situation where a user has done a request and get a DUC profile and a later request (some days later) on the same dataset could receive an "updated" profile? (I guess this is relevant for auditing and "liability" aspects)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/ga4gh/beacon-team/issues/46#issuecomment-226114130, or mute the threadhttps://github.com/notifications/unsubscribe/AI_EVGHD9FsbZQZ-LejaUd8oQZQU_2Cnks5qL68pgaJpZM4IWSN-.
jrambla
commented
8 years ago In such case, we just need to be sure that these two fields find their way to the Beacon API ADA-M section.
On Wed, 15 Jun 2016 at 12:08 antbro notifications@github.com wrote:
Hi Jordi. Good point. It is imagined that profiles will sometimes be changed. In ADA-M v1.0 this is captured in a Header section, via two fields "Matrix profile creation date" and "Matrix profile updates" [these are distinct from the "Matrix version" field in the Header, which we have been discussing]. So basically we're capturing the profile version by creation date and update date list info, not a 'profile version' as such. So I guess the question is whether or not these two date fields, as well as the Matrix version field, might need to be replicated in the Beacon API body
From: jrambla [notifications@github.com] Sent: 15 June 2016 08:52 To: ga4gh/beacon-team Cc: Brookes, Anthony J. (Prof.); Mention Subject: Re: [ga4gh/beacon-team] Move version field from ConsentCodeDataUse to BeaconDataset (#46)
I have another aspect to consider... @antbrohttps://github.com/antbro Should we consider versions of the Profiles? Are we expecting that data owners would evolve their profiles, thus we can face a situation where a user has done a request and get a DUC profile and a later request (some days later) on the same dataset could receive an "updated" profile? (I guess this is relevant for auditing and "liability" aspects)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/ga4gh/beacon-team/issues/46#issuecomment-226114130>, or mute the thread< https://github.com/notifications/unsubscribe/AI_EVGHD9FsbZQZ-LejaUd8oQZQU_2Cnks5qL68pgaJpZM4IWSN-
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ga4gh/beacon-team/issues/46#issuecomment-226144638, or mute the thread https://github.com/notifications/unsubscribe/AHsiOkEc7ubCe9DGsVrfLDWxppx10q-dks5qL88mgaJpZM4IWSN- .
antbro
commented
8 years ago Same will be true for Consent Codes or any other 'data use conditions statement model' that might come along, assuming they have an internal way to record changes in their 'profile' equivalent
jrambla wrote:
In such case, we just need to be sure that these two fields find their way to the Beacon API ADA-M section.
On Wed, 15 Jun 2016 at 12:08 antbro notifications@github.com wrote:
Hi Jordi. Good point. It is imagined that profiles will sometimes be changed. In ADA-M v1.0 this is captured in a Header section, via two fields "Matrix profile creation date" and "Matrix profile updates" [these are distinct from the "Matrix version" field in the Header, which we have been discussing]. So basically we're capturing the profile version by creation date and update date list info, not a 'profile version' as such. So I guess the question is whether or not these two date fields, as well as the Matrix version field, might need to be replicated in the Beacon API body
From: jrambla [notifications@github.com] Sent: 15 June 2016 08:52 To: ga4gh/beacon-team Cc: Brookes, Anthony J. (Prof.); Mention Subject: Re: [ga4gh/beacon-team] Move version field from ConsentCodeDataUse to BeaconDataset (#46)
I have another aspect to consider... @antbrohttps://github.com/antbro Should we consider versions of the Profiles? Are we expecting that data owners would evolve their profiles, thus we can face a situation where a user has done a request and get a DUC profile and a later request (some days later) on the same dataset could receive an "updated" profile? (I guess this is relevant for auditing and "liability" aspects)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub< https://github.com/ga4gh/beacon-team/issues/46#issuecomment-226114130>, or mute the thread<
https://github.com/notifications/unsubscribe/AI_EVGHD9FsbZQZ-LejaUd8oQZQU_2Cnks5qL68pgaJpZM4IWSN-
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ga4gh/beacon-team/issues/46#issuecomment-226144638, or mute the thread
https://github.com/notifications/unsubscribe/AHsiOkEc7ubCe9DGsVrfLDWxppx10q-dks5qL88mgaJpZM4IWSN- .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ga4gh/beacon-team/issues/46#issuecomment-226231149, or mute the thread https://github.com/notifications/unsubscribe/AI_EVH4Y38qUWoXOF-0yLU2oUvtrnvnKks5qMB9JgaJpZM4IWSN-.
sdelatorrep
commented
7 years ago Can we recap this? We have one +1 (@mcupak) and two -1 (@antbro, @jrambla). I suggest keeping the version field inside the ConsentCodeDataUse and closing this issue (or restart the discussion but we should move forward).
antbro
commented
7 years ago Hi
Miro, along with Francis Jeanson and several others (some from my lab) were starting up an effort to define a data use conditions API, and that team would be best to advise on al this
Last thing I knew the group was awaiting some github space to get started. Francis was to drive this, so I cc him in to this email
Cheers
Tony
Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? ** T.S. Eliot
From: sdelatorrep [notifications@github.com] Sent: 18 April 2017 13:30 To: ga4gh/beacon-team Cc: Brookes, Anthony J. (Prof.); Mention Subject: Re: [ga4gh/beacon-team] Move version field from ConsentCodeDataUse to BeaconDataset (#46)
Can we recap this? We have one +1 (@mcupakhttps://github.com/mcupak) and two -1 (@antbrohttps://github.com/antbro, @jramblahttps://github.com/jrambla). I suggest keeping the version field inside the ConsentCodeDataUse and closing this issue (or restart the discussion but we should move forward).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/ga4gh/beacon-team/issues/46#issuecomment-294819964, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AI_EVAPHiAKFM471yVAs5vyfaLfcoffjks5rxKzOgaJpZM4IWSN-.
sdelatorrep
commented
7 years ago Discarded.
I think the version field from ConsentCodeDataUse should not be inside ConsentCodeDataUse. It's a version of the consent code specification the beacon uses, which might eventually be developed in a separate repository and released as a separate artifact. As such, the dataset should contain the version, which would refer to the version of the artifact. Similarly, different data use systems would have a version field there.