Valid subjects for Relative and Absolute Copy Number statements

[ahwagner]

#277 discusses RelativeCopyNumber but focuses mostly on the way of expressing the relative copies, not the subject of the copies themselves.

RelativeCopyNumber: There is a systemic gain, loss, or neutral copies of a subject.

AbsoluteCopyNumber: There are Number/Range systemic copies of a subject.

I think that we currently represent locations as a sequence derived from a location (DerivedSequenceExpression). I propose that we remove the use of SequenceExpression as a subject in lieu of Location. This has a few advantages:

• parallels Allele structure / is Location based
• allows for objects with ChromosomeLocation subjects
• does not mix identifiable and non-identifiable types for subject

In addition, we should revisit the use of MolecularVariation here, which is designed to support Genotypes (#202) but we are still waiting on this.

[ahwagner]

@larrybabb and @mbaudis would like your thoughts here.

[mbaudis]

@ahwagner @larrybabb Absolute in favour. We do not need to have a "sequence we do not know the exact composition of" as intermediary. So the example I used w/ @ahwagner

"variation": {
	"type": "RelativeCopyNumber",
	"relativeCopyClass": "partial loss",
	"subject": {
		"type": "DerivedSequenceExpression",
		"location": {
			"interval": {
				"end": { "type": "Number", "value": 10099020 },
				"start": { "type": "Number", "value": 8938194 }
			},
			"sequenceId": "refseq:NC_000010.11",
			"type": "SequenceLocation"
		}
	}
}

... to:

"variation": {
	"type": "RelativeCopyNumber",
	"relativeCopyClass": "partial loss",
	"subject": {
		"interval": {
			"end": { "type": "Number", "value": 10099020 },
			"start": { "type": "Number", "value": 8938194 }
		},
		"sequenceId": "refseq:NC_000010.11",
		"type": "SequenceLocation"
	}    
}

???

If I understand correctly ...

[larrybabb]

I'm a fan... @ahwagner here's how it would look if we finally make that change to simplify sequencLocation that we've been discussing. Simplicity is the key. Now that we have added Range and removed the need for inner outer intervals the need for interval goes away and we can simply embed it as part of sequenceLocation (aka Region).

"variation": {
	"type": "RelativeCopyNumber",
	"relativeCopyClass": "partial loss",
	"subject": {
		"end": { "type": "Number", "value": 10099020 },
		"sequenceId": "refseq:NC_000010.11",
		"start": { "type": "Number", "value": 8938194 },
		"type": "SequenceLocation"
	}    
}

[larrybabb]

Why not be able to use a CanonicalLocation (or named region aka gene) as the subject, too?

[mbaudis]

@larrybabb +1

[mbaudis]

So this is an example call for the Progenetix Beacon, for 1x CNV and 1x SNV / Allele examples:

http://progenetix.org/beacon/variants/?variantIds=pgxvar-5c86664409d374f2dc4eeb93,pgxvar-5be1840772798347f0eda0d8

Some wrappers in the response; look for variation. Comments appreciated!

[larrybabb]

Looks great from my perspective. Very exciting to see the standard being applied in a real project. No major concerns at this point. FYI - Alex and I are discussing the idea of flattening SequenceInterval into SequenceLocation to simplify the structure. Still to be determined. But to be clear, this looks like it conforms to our CNV draft spec currently available.

[github-actions[bot]]

This issue was marked stale due to inactivity.

[larrybabb]

this was implemented as agreed to above in vrs 1.3