Importing features should be able to (optionally) include metadata about apollo

[selewis]

I think the approach should be (largely) no meta-data left behind. Might be
a few cases where it's inappropriate, but largely it should be held onto.

On Thu, Oct 23, 2014 at 7:07 PM, Nathan Dunn [email protected]
wrote:

Question/Issue 1:

I noticed that when creating transcripts from evidence, that all meta data
(like ‘description, dbxref) are lost. This is a bit of a problem, since my
workflow/rationale looks like this:

• create annotation with maker
• functionally annotate maker annotation
• load as track into WebApollo
• Manual verify transcript structures/meta data and add to
  user-curated track (changing the models significantly would of course
  require the curator to remove the meta data)
• Save curated annotations to Chado DB
• Load curated annotations to Jbrowse portal from Chado

So I hadn’t intended to ever take the annotations out of the database
again - but if the meta data is always lost in this processing chain, I
would basically have to dump out the WebApollo annotation, functionally
annotate it and then load it into JBrowse as a flat file. Which to me
defeats the purpose a little bit of being able to store WebApollo
transcript models to chado and so on (in my use case anyway).

—
Reply to this email directly or view it on GitHub
#52.

[nathandunn]

I agree. It should be identical.

Nathan

On Oct 28, 2014, at 9:08 AM, selewis [email protected] wrote:

I think the approach should be (largely) no meta-data left behind. Might be
a few cases where it's inappropriate, but largely it should be held onto.

On Thu, Oct 23, 2014 at 7:07 PM, Nathan Dunn [email protected]
wrote:

Question/Issue 1:

I noticed that when creating transcripts from evidence, that all meta data
(like ‘description, dbxref) are lost. This is a bit of a problem, since my
workflow/rationale looks like this:

• create annotation with maker
• functionally annotate maker annotation
• load as track into WebApollo
• Manual verify transcript structures/meta data and add to
  user-curated track (changing the models significantly would of course
  require the curator to remove the meta data)
• Save curated annotations to Chado DB
• Load curated annotations to Jbrowse portal from Chado

So I hadn’t intended to ever take the annotations out of the database
again - but if the meta data is always lost in this processing chain, I
would basically have to dump out the WebApollo annotation, functionally
annotate it and then load it into JBrowse as a flat file. Which to me
defeats the purpose a little bit of being able to store WebApollo
transcript models to chado and so on (in my use case anyway).

—
Reply to this email directly or view it on GitHub
#52.

—
Reply to this email directly or view it on GitHub #52 (comment).

[cmdcolin]

I think what Marc is referring to is that the metadata is not kept when importing the annotations, not when exporting them.

Note that he says he adds functional annotations before importing to webapollo, and he is concerned that these are lost.

So I think the relevant cards are

https://trello.com/c/4oDnoPKd/195-preserve-metadata-when-dragging-a-new-feature-into-the-user-created-annotations-area
https://trello.com/c/wKqdgGKq/209-support-preserving-metadata-from-evidence-tracks-when-dragging-a-new-annotation-for-curation

[nathandunn]

My plan for this was to add an integration test that did a round-trip export / import. Doing the reverse makes sense, as well.

[nathandunn]

Somewhat related to #1146 in that that will be pulling up gene fixes.

[nathandunn]

@satta and FYI @deepakunni3

The server-side never sees the additional annotations. The methods to be fixed (specifically to support Chado / JBrowse) are these sets of methods in DraggableHTMLFeatures:

https://github.com/GMOD/Apollo/blob/master/client/apollo/js/View/Track/DraggableHTMLFeatures.js#L1156-L1253

For gene / mRNA we have createAnnotations and for other transcripts we have createGenericAnnotations.

Not sure why they don't share the same code-base, but that is neither here nor there. It looks like the incoming code uses a NCList instead of JSON.

This is the code that moves from NCList to JSON and seems to have all of the upstream attributes. The JSON created there should correspond to this on the other end (which should be similar to the features I already gave you). This is the code that actually converts the JSON to the Feature, but it should take in generic properties if in the correct JSON format.

It would probably be good to confirm that REST JSON tracks use this mechanism (the NCList), but I'm pretty sure that is the way it works, since it is also using HTMLFeatures.

[nathandunn]

Importing is already fixed by @deepakunni3 as part of the fix for #1297