Thanks Ed!
-j
On Thu, Jun 12, 2008 at 10:57 PM, Ed Lee <[EMAIL PROTECTED]> wrote:
> 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
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
--
________________
http://five.sentenc.es/
_______________________________________________
apollo mailing list
[email protected]
http://mail.fruitfly.org/mailman/listinfo/apollo
