You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking over the specifications, it appears that the data model does have support for any sort of structural variant. If this is intentionally out of scope then this should be made explicit in the introduction with an explaination as to why. There is a CNV type listed in the future plans, but currently, the fundamental data model is inappropriate and unable to fully represent SVs.
More generally, should feedback be raised on github, or through the public consultation that is currently open?
The text was updated successfully, but these errors were encountered:
Thanks @d-cameron. Non-CNV structural variations are definitely in-scope for our roadmap (alongside CNVs), though we are still discussing how to best represent them and therefore did not include them in our v1.0 release candidate.
Currently our future plans include the Translocation class of Variation, which is intended to represent our plans to capture other SV types. Given your expertise in this area, your feedback and participation in developing this portion of the specification for a future release would be most welcome. The current avenue for feedback and suggestions on SVs and fusions is at #28.
Looking over the specifications, it appears that the data model does have support for any sort of structural variant. If this is intentionally out of scope then this should be made explicit in the introduction with an explaination as to why. There is a CNV type listed in the future plans, but currently, the fundamental data model is inappropriate and unable to fully represent SVs.
More generally, should feedback be raised on github, or through the public consultation that is currently open?
The text was updated successfully, but these errors were encountered: