fix(test): update copyChange to use MappableConcept

[korikuzma]

@larrybabb @ahwagner can you also confirm that ga4gh_serialize/ga4gh_digest/ga4gh_identify will remain the same?

[larrybabb]

@ahwagner I'm fine with this for now because I think that CopyNumberChange will ultimately be dropped from VRS and only included in Cat-VRS. As long as this stays as draft maturity you can do whatever you want with it. This. class will NOT be used by ClinGen as-is. I do think we need to have this discussion and determine if there are any folks that are interested in using this as-is.

[larrybabb]

Also, having structures like MappableConcept included in digest keys that impact identity is a generally bad idea IMO. MappableConcept does not inherently require any fields and is meant to be a useful construct for sharing entities that exist in the public domain that we do not want to take ownership of modeling ourselves.

[larrybabb]

Also, Any attributes involved in VRS digest generation that are not "codes" should be strict enumerations that are clearly specified, they should not be something that can be added to, modified or deleted from by external groups.

@ahwagner we probably should state this as a policy behind digest generation.

[korikuzma]

Also, having structures like MappableConcept included in digest keys that impact identity is a generally bad idea IMO. MappableConcept does not inherently require any fields and is meant to be a useful construct for sharing entities that exist in the public domain that we do not want to take ownership of modeling ourselves.

@larrybabb so it requires either label or primaryCode to be present, but ya it feels weird to have this included in digest keys if primaryCode can be null

[ahwagner]

@larrybabb agree that this should be tightly constrained for digests in VRS objects and we should make primaryCode the ga4gh.inherent attribute for MappableConcept. Also agree we should leave this in draft for the moment.