-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BDG-FORMATS-29] Re-organize the Feature schema #30
Conversation
8794ee9
to
cee80b7
Compare
This PR reflects a fix for Issue #29 |
|
||
Key is database name and value is the accession. | ||
*/ | ||
map<string> dbxrefs = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last time, you mentioned the possibility of multiple accessions in a single database. Does this reflect your resolution of this potential issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup! This is meant to be an ID->DB map, but I haven't done any downstream testing yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it ever possible that an object can have one accession in multiple databases? I don't know if we're talking about a 7-sigma issue here, but is it worth going back to your original proposal of having an array of Dbxref objects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, and ID->DB (as opposed to DB->ID) mapping would handle "multiple acc's in one DB," right? I'm agnostic either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I mean, what if the same accession is used in multiple databases? Does
this ever happen?
On Sep 15, 2014 12:39 PM, "Timothy Danford" notifications@github.com
wrote:
In src/main/resources/avro/bdg.avdl:
- union { null, double } signalValue = null;
- union { null, double } pValue = null;
- union { null, double } qValue = null;
- union { null, long } peak = null;
- /**
- The value associated with this feature (if double)
- */
- union { null, double } value = null;
- /**
- Cross-references into other databases.
- Key is database name and value is the accession.
- */
- map dbxrefs = null;
Well, and ID->DB (as opposed to DB->ID) mapping would handle "multiple
acc's in one DB," right? I'm agnostic either way.—
Reply to this email directly or view it on GitHub
https://github.com/bigdatagenomics/bdg-formats/pull/30/files#r17563834.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh. Um. Yeah, maybe. "7-sigma," like you said, but we should probably plan for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we go back to your initial suggestion then? Of an array of Dbxref objects?
+1 overall |
c39a1c2
to
9020236
Compare
9020236
to
c766065
Compare
@tdanford would you like to get this in before I cut a new bdg-formats release? |
I don't think it's necessary, no. |
OK, thanks. I'll cut the release now. |
c766065
to
60c2748
Compare
Test PASSed. |
Should this be rebased down before merging? ANSWER: YES. Let me do that, real quick. |
Yes, please squash. |
This is attempting to re-organize the Feature schema, along the discussions that we (Timothy, Uri, Matt, Frank) have had in email and on the phone. The main requirements are: * less file-format dependence in the field choice ('qValue'-like fields could be relegated to the 'attributes' field) * fewer fields to improve the memory footprint
23fdcf2
to
886e273
Compare
Test PASSed. |
[BDG-FORMATS-29] Re-organize the Feature schema
Merged! Thanks @tdanford! |
This is attempting to re-organize the Feature schema, along the
discussions that we (Timothy, Uri, Matt, Frank) have had in email and on
the phone. The main requirements are:
could be relegated to the 'attributes' field)