Move version field from ConsentCodeDataUse to BeaconDataset

[mcupak]

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.

[jrambla]

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]

+1

Tony

---

From: Miro Cupak [[email protected]]
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//issues/46

[mcupak]

+1 from Marc

[mcupak]

Prerequisite: #22

+1 for including in v.0.4.0.

[antbro]

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 [[email protected]]
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: #22#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//issues/46#issuecomment-225770814, or mute the threadhttps://github.com/notifications/unsubscribe/AI_EVDIFAnUJc0JjiB9tgyrndwsujAL7ks5qLiALgaJpZM4IWSN-.

[jrambla]

-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]

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]

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 [[email protected]]
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//issues/46#issuecomment-226114130, or mute the threadhttps://github.com/notifications/unsubscribe/AI_EVGHD9FsbZQZ-LejaUd8oQZQU_2Cnks5qL68pgaJpZM4IWSN-.

[jrambla]

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 [email protected] 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 [[email protected]]
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
#46 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHsiOkEc7ubCe9DGsVrfLDWxppx10q-dks5qL88mgaJpZM4IWSN-
.

[antbro]

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 [email protected] 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 [[email protected]]
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
#46 (comment),
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
#46 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AI_EVH4Y38qUWoXOF-0yLU2oUvtrnvnKks5qMB9JgaJpZM4IWSN-.

[sdelatorrep]

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]

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 Professor Anthony J Brookes Department of Genetics University of Leicester University Road Leicester, LE1 7RH, UK Tel: +44 (0)116 2523401 Mbl: +44 (0)777 0620396 Fax: +44 (0)116 2523378 mailto: [email protected]<mailto:[email protected]> -- ** Where is the wisdom we have lost in knowledge? ** Where is the knowledge we have lost in information? ** T.S. Eliot

…

________________________________ From: sdelatorrep [[email protected]] 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 (@mcupak<https://github.com/mcupak>) and two -1 (@antbro<https://github.com/antbro>, @jrambla<https://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 GitHub<#46 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AI_EVAPHiAKFM471yVAs5vyfaLfcoffjks5rxKzOgaJpZM4IWSN->.

[sdelatorrep]

Discarded.