ga4gh / va-spec

An information model for representing variant annotations.
Apache License 2.0
17 stars 4 forks source link

Define types of extensibility to support in the VA-Spec #54

Open mbrush opened 4 years ago

mbrush commented 4 years ago

There are several levels of extensibility our model may eventually need to support - e.g. ad hoc element extensions, class specializations, and complete custom models built from these simpler components. These roughly map to the three levels of extensibility and customization supported by the FHIR model. Initially we will adopt the FHIR naming conventions for these types of extensibility, and explore how we might learn from / adopt the mechanisms they define to support them.

  1. Element Extensions - features that support adding ad hoc attributes within existing/core classes.
    a. e.g. key-value based objects where implementers can define new/custom attributes (keys) as a proper part of the model. b. see FHIR ‘extension’ element

  2. Profiles - formal process to add custom constraints to existing core classes to finely control use of fields and data they will take. Specialization of core classes may also be covered here? a. lets implementers refine attribute cardinality or data type / value set bindings to reflect the unique semantics of the specialized type, and requirements of the implementing application. b. May also support custom specialization - e.g. defining a ‘Variant Pathogenicity Statement’ as a specialization of the core ‘Statement’ class.
    c. see FHIR Profiling

  3. Implementation Guides (IGs) - custom data models built from Profiles. a. e.g. a GA4GH Variant Pathogenicity IG built from Profiles of various core IM classes, including Statement (as above), but also Annotation, Method, Contribution, Evidence Line, etc. b. see FHIR Implementation Guides

The ticket here is for discussion/debate about the need for and utility of these types of extensibility, and documenting use cases and requirements. Proposals for specific mechanisms/models to support a given type of extensibility should be captured in a related ticket.

mbrush commented 4 years ago

For the v0 release, we may consider only Level 1 'Element Extensions' - bespoke attributes to capture content needed for specific applications.

The use case for this is clear, and simple, tested solutions exist that we can explore for inclusion in the v0 release. This will support real DP use cases, and offer an opportunity for testing and feedback - and we may even identify new elements that should be part of the core spec in this way (i.e. because many adopters create the same custom attributes)

Starting a new ticket to discuss proposals for implementing this specific type of extensibility (#55).