VRS 2.0.0 Trial Use Ballot

[ahwagner]

The first ballot release for the VRS specification, this ballot covers models under consideration for advancement to trial use in v2.0.0, including:

• Expression
• Allele
• CisPhasedBlock
• CopyNumberCount
• CopyNumberChange
• SequenceLocation
• SequenceReference
• ReferenceLengthExpression
• LengthExpression
• LiteralSequenceExpression
• Range
• Residue
• SequenceString
• Adjacency
• Terminal
• DerivativeMolecule
• TraversalBlock

---

This discussion was created from the release VRS 2.0.0 Trial Use Ballot.

[rrfreimuth]

Thanks to everyone for putting so much effort into this release! Great job!

Comments and questions:

• Please add a figure showing the class hierarchy to illustrate inheritance. This would be especially helpful for an abstract class like Location, which is listed as a datatype for several attributes but is not included in the documentation so it is difficult to know which child classes are valid for a given attribute.
• Please include links to examples from within concept/model pages, so it is easier to see instance examples of each class
• Sequence Reference appears to support only refget accession numbers. How would other types of accession numbers be represented? (as a CURIE in .id?) Is it possible to specify more than one accession number?
• Why is SequenceLocation.sequence not of type LiteralSequenceExpression?
• SequenceLocation should require either sequenceReference or sequence to be populated
• The links to type IRI (referencing https://vrs.ga4gh.org/ga4gh/schema/gks-common/1.x/data-types/json/IRI) are broken
• The relationship between Allele and Derivative Molecule should be defined. They both represent contiguous sequences and it may be possible to represent at least some Derivative Molecules as Alleles. A normalization algorithm may be needed.
• Are all members of a CisPhasedBlock defined to be in the forward orientation?
• Adjacency: Please add an example that illustrates "increasing position" adjacent to "increasing position"
• Derivative Molecules: Is it required that sequential elements form a contiguous path? For example, if a DerMol contains 2 adjacencies (between two Terminii), should there be structural consistency (sequence, location, orientation) between the first adjoinedSequence of the second Adjacency and the second adjoinedSequence of the first Adjacency?
• How is Terminus different from Location?
• I am not sure Terminus should be a type of Molecular Variation (it seems more like a utility datatype)
• The expressions attribute is inherited by several classes but its use in those classes is not apparent (e.g., DerivativeMolecule, CopyNumberChange)
• Why is the alternativeLabels attribute needed, rather than simply expanding the cardinality of the label attribute to 0..m?

[ahwagner]

Derivative Molecules: Is it required that sequential elements form a contiguous path? For example, if a DerMol contains 2 adjacencies (between two Terminii), should there be structural consistency (sequence, location, orientation) between the first adjoinedSequence of the second Adjacency and the second adjoinedSequence of the first Adjacency?

Yes, this is the intent of that class.

[ahwagner]

How is Terminus different from Location?

A terminus is the explicit end of a physical molecule at a Location. The Location defines the coordinate where this occurs. The SV SIG recommended use of Adjacency for this, but the semantics were fuzzy so we created a new class, Terminus.

[ahwagner]

I am not sure Terminus should be a type of Molecular Variation (it seems more like a utility datatype)

@rrfreimuth I would like to hear your rationale for this; please open a Discussion with additional detail to help motivate why a change is needed here. We believe that both Adjacency and Terminus objects share an abstract (undefined) parent concept, and so either both should be Mol Var or both something else.

[ahwagner]

The expressions attribute is inherited by several classes but its use in those classes is not apparent (e.g., DerivativeMolecule, CopyNumberChange)

If or when community nomenclatures for these concepts exist, expression is useful for representing those nomenclatures as descriptive metadata. For example, one can envision use of ISCN representations for some DerivativeMolecules.

[ahwagner]

Why is the alternativeLabels attribute needed, rather than simply expanding the cardinality of the label attribute to 0..m?

The label under the label attribute is the primary label for display.

[Mrinal-Thomas-Epic]

I didn't notice it until today's discussion, but why are Mappings no longer supported on VRS variation? If an implementation is using the id field for their own identifier, how would they attach ClinGen Allele Registry CA IDs or dbSNP rs IDs (or even a VRS 1.3 ID) to an Allele without a mappings concept?

[larrybabb]

We(Matt and I) made a change to only include mappings on DomainEntity. Alex had originally created a special class called MappableEntity which existed in the ValueObject hierarchy. We thought it would be fine to have the VRS Variation and Location classes use DomainEntity as it's parent, but Alex pointed out later this was not logical (see Alex for logic). In the end the mappings got dropped/lost from ValueObjects.

The question is whether FHIR identifiers can be handled by Mappings and if so, should we simply add this as an optional field at the Entity level? I think Mappings were mainly introduced to handle xrefs since they provide the relation feature.

In the end, we may need to have an identifiers attribute that is more of an "exact" mapping and useful for listing identifiers (not just the concept id within the message). identifiers would presumably always be exact mappings and follow the FHIR definition for the concept.

CodeableConcept would then be the "thing" that is replaced by Mappings I suppose.

Lots to discuss.

[larrybabb]

Update on this discussion. @ahwagner @mbrush and I are working out a draft/trial use plan for Mappings and DomainEntities as I write. We will be picking a path forward with the intent of allowing developers to establish the first steps. We will reserve the right to refactor this DomainEntity area of the model in a future minor or major release of the specification.
For now, we have agreed that DomainEntities belong only up in the VA-spec to relate to profiles that may need them.