Replies: 1 comment 1 reply
-
My preference is also the last model. I only see the costs and not the value in creating digests for objects that are not identifiable. We will occassionally show compacted representation of higher order classes (like Allele) that contain only the nested identifiable object(s) (SequenceLocation) as a digest. We would never do this for these other structures that are NOT identifiable. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In VRS 1.x, if an object was GA4GH-identifiable, the digest of that object is used in place as a reference to that object in nested structures, simplifying the input serialization for computed identifier calculation.
In VRS 2.x, this remains the same, but now we have other Value Objects with integrated descriptive attributes that are dropped for serialization. We also have a "special case" of SequenceReference, which is non-identifiable, but passes through a digest of a RefGet sequence object for digest serialization.
Here is what that looks like from a serialization perspective:
I would like to consider treating all value objects in VRS consistently, by always computing/retrieving and returning a digest for serialization. We can maintain the "passthrough" special case for SequenceReference to avoid computing a secondary digest, but this would provide consistency in implementation by always returning digests for any Value Object in VRS. All Value Objects already allow for digest to be stored, so "compute digest" may be implemented as a 1-time operation per value object. The revised process would look like this:
This has nice implications for other complex "for purpose" value objects like GenotypeMember, which could also be compacted into digest references.
A second option is to go the other way: instead non-GA4GH-identifiable objects are serialized but not digested for parent object serialization, and the digest keys for SequenceReference are limited to type and refgetAccession. It would look like this:
My preference is this last model, since there are no special cases under this model.
@reece @larrybabb @korikuzma @theferrit32 @tnavatar @toneillbroad @andreasprlic thoughts?
Beta Was this translation helpful? Give feedback.
All reactions