Details
-
Type:
Task
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 3.0
-
Component/s: data retrieval services, Datamodel, Dev and Dep, Scriptable API
-
Labels:None
-
Epic Link:
Description
There are a variety of different mechanisms for importing data from streams, identifying and parsing them and transferring information (if the data was parseable) to a sequence, collection of sequences or alignment. The basic method signature needs to be unified and an API for annotators created that allows easy extension, to support the implementation of handlers for new sources of annotation.
Process: take a look all cases where the JPredFile, FeaturesFile, TCoffeeFile, and AnnotationFile classes are used.
-> infer the basic cases :
Some examples here:
1. test if the data passed to parser can be parsed. give a reason if possible, and gracefully fail for partially broken sources.
2. test if the data is compatible with the context in which it was provided:
this has multiple levels:
i. data completely incompatible: T-Coffee data matches alignment it is it was loaded on to, IDs for sequence annotation cannot be resolved to sequences
ii. data mismatches but not incompatible - checksums for sequence annotation do not match checksums for sequence in alignment,
3. transfer as much annotation as possible and indicate if annotation was transferred or not.
4. summary report indicating annotation source/etc for provenance.
The objective of the api is to allow the core jalview logic to iterate through annotation handlers for a particular source of data, and if required, report any issues to the user, otherwise silently fail or succeed in the process.
Design criteria: scripting/api methods employing the parsers might allow one, some or all parsers to be explicitly specified, or allow the user to discover which parsers might work for the given data.
Process: take a look all cases where the JPredFile, FeaturesFile, TCoffeeFile, and AnnotationFile classes are used.
-> infer the basic cases :
Some examples here:
1. test if the data passed to parser can be parsed. give a reason if possible, and gracefully fail for partially broken sources.
2. test if the data is compatible with the context in which it was provided:
this has multiple levels:
i. data completely incompatible: T-Coffee data matches alignment it is it was loaded on to, IDs for sequence annotation cannot be resolved to sequences
ii. data mismatches but not incompatible - checksums for sequence annotation do not match checksums for sequence in alignment,
3. transfer as much annotation as possible and indicate if annotation was transferred or not.
4. summary report indicating annotation source/etc for provenance.
The objective of the api is to allow the core jalview logic to iterate through annotation handlers for a particular source of data, and if required, report any issues to the user, otherwise silently fail or succeed in the process.
Design criteria: scripting/api methods employing the parsers might allow one, some or all parsers to be explicitly specified, or allow the user to discover which parsers might work for the given data.