Hey Justin,

I've cut a new release of Apollo.  It should have the ChadoXML rank
issues fixed, along with some other bug fixes and small new additions.
Let me know if you have any other problems.

-Ed

On Tue, 2008-06-10 at 16:24 +0700, Justin Reese wrote:
> Hey Ed,
> Thanks a lot. How much trouble would it be to cut a release for this?
> Or, if you send me a diff file I can compile a new version myself.
> 
> If we use the current Apollo, the next step in our annotation process will
> convert the ranks to 0, which I'd like to avoid - someone may have
> annotated some trans-spliced genes (or may want to in the future).
> -j
> 
> On Tue, Jun 10, 2008 at 4:40 AM, Ed Lee <[EMAIL PROTECTED]> wrote:
> > Hey Justin,
> >
> > I've updated the Chado XML writer to handle exon ranks in a more correct
> > manner.  Also fixed a "bug" where ranks generated were 1-based rather
> > than 0-based (look at the original Chado XML file you loaded into Chado
> > - the ranks are 1-based rather than 0-based).  Please keep in mind that
> > the adapter was written specifically for FlyBase and is by no means a
> > general purpose Chado XML adapter (which we should probably write at
> > some point down the line).  I'd imagine that this is not a show stopper
> > on your side, so you won't see the fix until the next release.  But if
> > this is urgent, let me know and I'll cut a release.
> >
> > To the Flybase folks:
> >
> > Hopefully these changes won't break anything on your side.  I've noticed
> > that the ranks in Chado XML were 1-based, which goes against the Chado
> > convention.  Was the rank of "0" used as some kind of place holder for
> > your programs to replace?  Let me know if the changes will break
> > anything on your side.
> >
> > -Ed
> >
> >
> > On Tue, 2008-06-10 at 01:27 +0700, Justin Reese wrote:
> >> Hi Mark,
> >> Yeah, I don't anticipate needing the feature relationship rank
> >> attribute for anything, I thought I should pursue it though because
> >> 1) Some other piece of software down the pike might care about
> >> rank
> >> 2) it's kind of curious that Apollo would write the rank out
> >> to Chado XML correctly but not read it from Chado correctly
> >> correctly
> >> 3) might help improve Apollo, if this turns out to be a bug
> >>
> >> -j
> >>
> >> On Tue, Jun 10, 2008 at 1:16 AM, mark gibson <[EMAIL PROTECTED]> wrote:
> >> > This doesnt surprise me - as you see i think the chado xml adapter doesnt
> >> > deal with rank. rank is something that apollo doesnt need and so its not
> >> > tracking. in fact i dont think theres anything in the apollo datamodel 
> >> > for
> >> > rank - and it would need to be added (either explicitly or through a
> >> > property).
> >> > Nomi wrote the chado xml adapter and she can probably elaborate further.
> >> > The question though is why do exons need to be ranked in chado? Isnt it
> >> > redundant with coordinates? Why does exon rank mean anyways?
> >> > cheers - Mark
> >> >
> >> > On Jun 9, 2008, at 1:34 PM, Ed Lee wrote:
> >> >
> >> >> Hi Justin,
> >> >>
> >> >> Yes, please provide me with some sample data and access to the database
> >> >> and I'll explore this issue further.
> >> >>
> >> >> -Ed
> >> >>
> >> >> On Tue, 2008-06-10 at 00:20 +0700, Justin Reese wrote:
> >> >>>
> >> >>> Hey Apollo-ers,
> >> >>> We are using Apollo, Chado and XORT to handle the bovine genome
> >> >>> annotation effort, and things are working pretty well.
> >> >>>
> >> >>> I am running some tests to make sure everything is working correctly,
> >> >>> and it seems Apollo is not pulling some rank attributes out of Chado
> >> >>> correctly.
> >> >>>
> >> >>> When I do a roundtrip test thusly:
> >> >>>
> >> >>> 1) Annotate gene using Apollo, save as Chado XML
> >> >>> 2) Load into Chado using XORT
> >> >>> 3) Pull annotation from Chado using Apollo
> >> >>> 4) Write to Chado XML ("after" XML file)
> >> >>>
> >> >>> and do a diff on the "before" Chado XML (step 1) and "after" Chado XML
> >> >>> (step 4), the rank attribute of feature_relationship's have changed.
> >> >>>
> >> >>> In the "before" Chado XML, the rank attribute of feature_relationship
> >> >>> between
> >> >>> exons and their mRNA in the before Chado XML is always equal to the 
> >> >>> order
> >> >>> of the exon: 1st exon has a rank of 1, second exon has a rank of 2 and 
> >> >>> so
> >> >>> on.
> >> >>> In the "after" Chado XML, the rank attribute is always 0.
> >> >>>
> >> >>> Example:
> >> >>>
> >> >>> Before -
> >> >>>          <feature_relationship>
> >> >>>            <rank>1</rank>
> >> >>>            <subject_id>
> >> >>>              <feature>
> >> >>>                <is_analysis>0</is_analysis>
> >> >>>                <name>Btgn:temp1:Chr6.29:650000-768000:1</name>
> >> >>>
> >> >>> After -
> >> >>>          <feature_relationship>
> >> >>>            <rank>0</rank>
> >> >>>            <subject_id>
> >> >>>              <feature>
> >> >>>                <is_analysis>0</is_analysis>
> >> >>>                <name>Btgn:temp1:Chr6.29:650000-768000-RA exon 1</name>
> >> >>>
> >> >>> XORT seems to have correctly loaded the ranks into Chado, so that's not
> >> >>> the
> >> >>> problem:
> >> >>>
> >> >>> SELECT feature.name, feature_relationship.rank FROM feature,
> >> >>> feature_relationship WHERE feature.feature_id =
> >> >>> feature_relationship.subject_id AND uniquename LIKE
> >> >>> 'Btgn:temp1:Chr6.29:650000-768000%'
> >> >>>
> >> >>>                name                 | rank
> >> >>> -------------------------------------+------
> >> >>>  Btgn:temp1:Chr6.29:650000-768000-PA |    0
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:16 |   16
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:15 |   15
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:14 |   14
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:13 |   13
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:12 |   12
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:11 |   11
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:10 |   10
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:9  |    9
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:8  |    8
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:7  |    7
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:6  |    6
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:5  |    5
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:4  |    4
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:3  |    3
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:2  |    2
> >> >>>  Btgn:temp1:Chr6.29:650000-768000:1  |    1
> >> >>>  Btgn:temp1:Chr6.29:650000-768000-RA |    0
> >> >>>
> >> >>> I did some Apollo code diving, and found this in ChadoXmlAdapter.java:
> >> >>>
> >> >>>  /** Get the rank from a featureprop record.
> >> >>>   *      <featureprop>
> >> >>>   *        <rank>0</rank>
> >> >>>   *        <type_id>
> >> >>>   *  Returns the rank as a short (default is 0 if it can't be parsed).
> >> >>>   * 12/2005: No longer used (not roundtripping featureprop ranks). */
> >> >>>
> >> >>> Looks like someone else was doing this same roundtrip and decided
> >> >>> that this diff was not a dealbreaker. I found several other places in 
> >> >>> the
> >> >>> Apollo code where rank is retrieved from Chado and assigned, but can't
> >> >>> seem to find the one that is relevant here (i.e. a place where I can
> >> >>> change
> >> >>> the rank manually to something unique like 99999 and have that rank
> >> >>> show up in the "after" XML).
> >> >>>
> >> >>> Any advice about why ranks aren't being pulled correctly here, and, 
> >> >>> more
> >> >>> importantly, whether this is harmful? Are incorrect 
> >> >>> feature_relationship
> >> >>> ranks going to hurt anything? Apollo happily loads these genes with
> >> >>> the wrong ranks, and they display correctly as far as I can tell.
> >> >>>
> >> >>> I'd be glad to provide a chado-adapter.xml or connection info if anyone
> >> >>> wants to connect to our chado and have a look first-hand.
> >> >>>
> >> >>> Thanks in advance,
> >> >>> Justin
> >> >>> _______________________________________________
> >> >>> apollo mailing list
> >> >>> [email protected]
> >> >>> http://mail.fruitfly.org/mailman/listinfo/apollo
> >> >>>
> >> >>
> >> >> _______________________________________________
> >> >> apollo mailing list
> >> >> [email protected]
> >> >> http://mail.fruitfly.org/mailman/listinfo/apollo
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> 
> 
> 

_______________________________________________
apollo mailing list
[email protected]
http://mail.fruitfly.org/mailman/listinfo/apollo

Reply via email to