Target package organization

[rrfreimuth]

In order to keep organized as things scale, we need to structure the packages a little differently.

Each online resource should have an interface class:

• NCBI Variation Services: This is a wrapper class for the NCBI API. The current api_class.py has a few methods that could form the basis of this class (e.g., spdi_to_hgvs, hgvs_to_spdi).
• VICC: This is a wrapper class for the VICC API. The current api_class.py has a few methods that could form the basis of this class (variation_to_vrs).

Each format should have a class:

• VRS: DONE? - the VRS packages already define a VRS object and many methods for translation/validation. Any time we have a VRS object, this class should be used to manipulate it.
  • I believe this package already has to_hgvs and to_spdi methods
• HGVS: DONE? - the biocommons hgvs packages already define a HGVS object and many methods for translation/validation. If we get an HGVS string, it should be parsed with this class. Any time we have an HGVS object, this class should be used to manipulate it.
  • If the hgvs package does not have a "to_spdi" method, we can extend it by adding a method that uses the NCBI Var Services class.
  • to_vrs: if this doesn't already exist, we could add it as a pass-through call to one of the VRS methods
• SPDI: Currently there is no SPDI class defined (that I am aware of). We should write this. It will be a simple class with 4 required input params (SPDI) that uses the NCBI Var Services class for validation. Methods include:
  • init: create an object from scratch using required params
  • to_hgvs( format ): returns an HGVS object or string, as determined by the value of "format". This method can use the NCBI Var Services class to do the heavy lifting.
  • to_vrs: if this doesn't already exist, we could add it as a pass-through call to one of the VRS methods
• Gen Std Core: this is the primary class we're working on now, to serve as the common data structure. The class needs to have the following methods.
  • init: create an object from scratch using required params
  • var_obj_to_core: takes as input a VRS, HGVS, or SPDI object, extracts values for required params, calls init()
  • to_spdi( format ): returns a SPDI object, string, or dict ( { sequence, position, deletion, insertion } ) as determined by the value of "format"
  • to_hgvs( format ): returns an HGVS object or string, as determined by the value of "format". This method can use the NCBI Var Services class to do the heavy lifting, or the hgvs package if we want to try to assemble it from scratch (probably harder)
  • to_vrs( format ): returns a VRS object or JSON structure, as determined by the value of "format". This method can use the VICC class to do the heavy lifting.

Additional classes (future):

• Core db interface
• FHIR R5+
• FHIR R4?

[rrfreimuth]

@SalemBajjali Scan through the issues I just created so you get an idea of what is there. Address the issues as they pertain to the classes in the order given below.

Work from the top-down in the list above. Begin with the 2 interface classes since they should just need a bit of cut/paste from what you already have. Then check the VRS packages to see if they have everything we need as per above.

Let me know when you start on the HGVS package because I want to make sure we're on the same page regarding implementation (subclass/extension/wrapping).

The SPDI class should be straightforward.

Once those are done (hopefully it won't take very long) we can hit the gen std core class again. The guts of it shouldn't change much (see existing code and the associated issues I created tonight), and the methods for to_spdi/hgvs/vrs should be mostly pass throughs. The ingest method might take a bit of work but if we're using the pre-built objects it might be easier than taking strings.

While you're doing this I'll work with Jeff on the db schema, so it should be up and running by the time you start thinking about the core db interface class. You can take what you already have for that and update it as needed, then test it against the db he creates.

At that point we'll be ready to load some data and do some testing.

We'll do the FHIR classes last, of course.