An argument can be made to extend SampleMetadata with a new property called dbGapStudy since it looks like the planned dbGap node will only have one property associated with it. On the other hand, the dbGap study isn't going to be versioned and there's enough complexity with how SMdata is managed that it may not be worth introducing a new property for. Additionally, it would be ideal to not make a change to the schema that the downstream consumers are receiving since dbGap study isn't something of interest to them.
Data that we need to resolve or pull from other sources:
race Where can we pull this information from??
analyte type (can be resolved from SampleMetadata)
istumor (can use existing SampleMetadata isTumor field)
histological subtype Where is this from?? What does this look like??
platform (might be able to use existing mapping that Voyager uses // may also be able to resolve from request metadata)
instrument model (might be able to use existing mapping that Voyager uses // may also be able to resolve from request metadata)
NOTE: THESE FIELDS DO NOT NEED TO BE EDITED. Might be easiest to just resolve them in the dashboard on the fly.
Proposed changes:
dbGap properties:
An argument can be made to extend
SampleMetadatawith a new property calleddbGapStudysince it looks like the planneddbGapnode will only have one property associated with it. On the other hand, the dbGap study isn't going to be versioned and there's enough complexity with how SMdata is managed that it may not be worth introducing a new property for. Additionally, it would be ideal to not make a change to the schema that the downstream consumers are receiving since dbGap study isn't something of interest to them.Data that we need to resolve or pull from other sources:
isTumorfield)NOTE: THESE FIELDS DO NOT NEED TO BE EDITED. Might be easiest to just resolve them in the dashboard on the fly.