<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi Matthew
<div>You are very wise.</div>
<div>Ed</div>
<br>
<br>
<div>-------- Original message --------</div>
<div>From: Matthieu Muffato <muffato@ebi.ac.uk></div>
<div>Date:06/02/2014 7:09 AM (GMT-05:00) </div>
<div>To: Ensembl Dev <dev@ensembl.org></div>
<div>Subject: Re: [ensembl-dev] Members, GeneMembers and SeqMembers in Ensembl 76
</div>
<div><br>
</div>
<div class="BodyFragment">
<div class="PlainText">Hi Ed<br>
<br>
get_all_Members() is not deprecated and won't be removed. There <br>
shouldn't be any warnings to change it. It does actually return <br>
SeqMembers, but changing its name was too invasive, I think. There is an <br>
additional get_all_GeneMembers() to return their genes.<br>
<br>
The perc_*() methods are (were) only available on the proteins / <br>
transcripts that are aligned, and used in our resources. Currently, they <br>
only return non-undef on the homology members, but we can probably <br>
define them to gene-tree leaves and family members as well. Not sure <br>
that can be done in time for e76, but I'll let you know.<br>
<br>
As perc_*() were never available on genes, there is no old code that <br>
would do that, and that we should support.<br>
Currently, it is not possible to define the perc_*() methods on genes <br>
generally, because we cannot know the homology to which species the use <br>
would refer to. But if a user does get_all_GeneMembers(), it is <br>
difficult to link the genes back to their sequences. There should indeed <br>
be a way of getting the perc_* values directly. Thank you for reporting <br>
that.<br>
<br>
Also on the list of changes to make in the API: We can leave methods <br>
that have been renamed (like get_canonical_Member() ) a bit longer to <br>
facilitate the transition.<br>
<br>
The e76 API only works with the e76 database, so I'm afraid testing it <br>
won't be possible until the public release of e76, then.<br>
<br>
Matthieu<br>
<br>
On 02/06/14 02:05, Ed Gray wrote:<br>
> I think you understand.<br>
><br>
> I guess what I am suggesting is that the GeneMembers allow for the<br>
> perc_id() (and similar methods). Sure they could return undef, but a<br>
> better solution might be for them to return the<br>
> get_canonical_SeqMember->perc_id(). Thta way all the old code that is<br>
> on the internet will continue to work, and work generally as expected<br>
> since many working with phylogenetics want the canonical cDNA sequence<br>
> for coding and gDNA for non-coding genes.<br>
><br>
> With the warnings in place, many will replace the get_all_Members with<br>
> get_all_GeneMembers not get_all_SeqMembers.<br>
><br>
> Regarding testing, we don't clone the database, we use the API, so if<br>
> you are interested in having someone run the api prior to its release,<br>
> we'd be happy to accomodate you.<br>
><br>
>> Date: Sun, 1 Jun 2014 22:36:17 +0100<br>
>> From: muffato@ebi.ac.uk<br>
>> To: dev@ensembl.org<br>
>> Subject: Re: [ensembl-dev] Members, GeneMembers and SeqMembers in Ensembl 76<br>
>><br>
>> Hi Ed,<br>
>><br>
>> I'm not sure I'm following you.<br>
>> There already is a get_canonical_SeqMember() method. It was introduced<br>
>> in e71 to replace the three previous methods<br>
>> get_canonical_peptide_Member() get_canonical_Member() and<br>
>> get_canonical_transcript_Member(), which were all doing the same thing<br>
>> in the end, It returns the SeqMember that is used in the gene-trees.<br>
>> Are you suggesting to keep get_canonical_Member() longer than scheduled<br>
>> to still allow old code to work ?<br>
>><br>
>> Methods such as perc_id(), perc_pos(), etc, are most useful for<br>
>> homologies. The homology object will still return SeqMembers when you<br>
>> call get_all_Members(), and they will still have those methods defined.<br>
>> Those 3 methods are actually also available for gene-tree and family<br>
>> members, but I think they return undef (they've probably always had)<br>
>><br>
>> There is no e76 database available yet, but it is still possible to<br>
>> create your own 76-like database by patching the e75 one. All the SQL<br>
>> patches should be on git ("master" branch)<br>
>><br>
>> Best,<br>
>> Matthieu<br>
>><br>
>> On 23/05/14 18:39, Ed Gray wrote:<br>
>> > Thanks Matthieu, that was a very helpful response. No need to feel<br>
>> > defensive, I understand the reasons behind separating Gene and Seq<br>
>> > Members and I support the change.<br>
>> ><br>
>> > I guess the only suggestion I might have is to implement some amount of<br>
>> > backwards compatibility by using the GeneMember's<br>
>> > get_canonical_SeqMember to give values for SeqMember methods that are<br>
>> > not implemented in GeneMember. At least that way, old code works,<br>
>> > albeit using the default canonical seqmember. I'd think that would<br>
>> > suffice in most cases, and providing a perc_id, perc_pos, perc_cov, etc.<br>
>> > etc. for GeneMembers.<br>
>> ><br>
>> > Frankly, I believe most folks just want the default canonical sequence<br>
>> > rather than having to leaf through transcripts and try to figure out<br>
>> > which is the best (e.g. all exons covered and ordered, with the<br>
>> > 'longest' sequence length yet not 'too long'). That is always a pain to<br>
>> > leaf through in code and the decisions we make based on the data in one<br>
>> > species often do not hold in another species. I think most of us<br>
>> > comparative genomics types would prefer to accept EMBLs call on what is<br>
>> > the best representation of the canonical sequence (amino acids for<br>
>> > proteiin coding or mRNA for ncRNA genes) for a specific gene in a<br>
>> > specific species.<br>
>> ><br>
>> > Is that a good idea to both provide aome backward compatibility while<br>
>> > providing the use base with a real feature whereby default transcript<br>
>> > sequences can be obtained?<br>
>> ><br>
>> >> Date: Wed, 21 May 2014 18:55:31 +0100<br>
>> >> From: muffato@ebi.ac.uk<br>
>> >> To: dev@ensembl.org<br>
>> >> Subject: Re: [ensembl-dev] Members, GeneMembers and SeqMembers in Ensembl 76<br>
>> >><br>
>> >> Dear Ed,<br>
>> >><br>
>> >> Yes, we are changing the compara API to use two specialized versions of<br>
>> >> Member (GeneMember and SeqMember) depending on the context (genes or<br>
>> >> gene products, i.e. ncRNAs and proteins). The Member adaptor is<br>
>> >> deprecated, as the preferred way will now be GeneMember and SeqMember<br>
>> >> adaptors. The Member object will still there as a base class of<br>
>> >> GeneMember and SeqMember, and some methods that can work with both kinds<br>
>> >> of members will still be around, and have the unspecialized word Member<br>
>> >> in their name (like get_all_Members, fetch_all_by_Member, etc)<br>
>> >><br>
>> >> The tutorials should be already using the right adaptors. However, some<br>
>> >> variables are still named $member, and it's probably clearer to use<br>
>> >> $seq_member or $gene_member instead. We still have to update the<br>
>> >> documentation of some methods to clearly state what kind of member<br>
>> >> they're dealing with.<br>
>> >><br>
>> >> You can write your code using v75 API / documentation. Only the methods<br>
>> >> that print a deprecation warning may be removed in e76. If they don't<br>
>> >> complain, it means that they'll still be available in e76.<br>
>> >><br>
>> >> The change is declared in a very concise manner in our declaration of<br>
>> >> intentions: "Split member into seq_member and gene_member + members<br>
>> >> depend on dnafrags" <a href="http://admin.ensembl.org/Changelog/Summary">http://admin.ensembl.org/Changelog/Summary</a><br>
>> >> We want to split the table that holds the members into two tables<br>
>> >> (seq_member and gene_member). We've first changed the object model in<br>
>> >> e71 (Apr 2013) and set up all the deprecation warnings for a final<br>
>> >> removal in e76. We're also using this opportunity to link the two member<br>
>> >> tables to the dnafrag table, which is used for genomic alignments. The<br>
>> >> goal is to provide smoother links within the compara resources. We'll<br>
>> >> also add more fields in the gene_member table / object to give a summary<br>
>> >> of the number of orthologues, paralogues, etc<br>
>> >><br>
>> >> I've had a look at the differences between the e75 and e76 API, and I<br>
>> >> cannot see further changes than the methods that are already deprecated.<br>
>> >> Data-wise, the only consequence is that the Family object will not<br>
>> >> directly hold genes any more. Up to e75, $family->get_all_Members() used<br>
>> >> to return both genes and proteins. From e76 onwards, it will only return<br>
>> >> the proteins, and $family->get_all_GeneMembers() will return the genes.<br>
>> >><br>
>> >> Hope this helps,<br>
>> >> Matthieu<br>
>> >><br>
>> >> On 20/05/14 23:46, Ed Gray wrote:<br>
>> >> > Hi All,<br>
>> >> ><br>
>> >> > I am writing some code right now that uses Members, GeneMembers and<br>
>> >> > SeqMembers. Is it true that the Member is being deprecated in the<br>
>> >> > upcoming Ensembl 76 release?<br>
>> >> ><br>
>> >> > If so,<br>
>> >> ><br>
>> >> > 1) Almost all of the relevant examples use what may soon be deprecated<br>
>> >> > code. FOr instance<br>
>> >> > <a href="http://useast.ensembl.org/info/docs/api/compara/compara_tutorial.html">
http://useast.ensembl.org/info/docs/api/compara/compara_tutorial.html</a> has the stanza<br>
>> >> > of code below just after a stanza example that has GeneMember objects.<br>
>> >> > my $homology = $homologies->[0]; # take one of the homologies and look<br>
>> >> > into it<br>
>> >> > foreach my $member (@{$homology->get_all_Members}) {<br>
>> >> > # each AlignedMember contains both the information on the SeqMember and in<br>
>> >> > # relation to the homology<br>
>> >> > print (join " ", map { $member->$_ } qw(stable_id taxon_id))."\n";<br>
>> >> > print (join " ", map { $member->$_ } qw(perc_id perc_pos perc_cov))."\n";<br>
>> >> > }<br>
>> >> ><br>
>> >> > 2) Will get_all_Members still be available after r75?<br>
>> >> ><br>
>> >> > 3) Is there any plan on adjusting the tutorials etc. for GeneMembers and<br>
>> >> > SeqMembers?<br>
>> >> ><br>
>> >> > 4) How different will the Compara API be in r76? Again, I am currently<br>
>> >> > writing code to try to take advantage of what I understand to be more<br>
>> >> > Compara data in r76 but I am concerned the API will be different and I<br>
>> >> > will have to re-write.<br>
>> >> ><br>
>> >> > So many questions, I know, but is there some guidance you could give on<br>
>> >> > the topic of Compara API changes and deprecations coming in ensembl 76?<br>
>> >> ><br>
>> >> > Many, many thanks,<br>
>> >> > Ed<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > Dev mailing list Dev@ensembl.org<br>
>> >> > Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev">
http://lists.ensembl.org/mailman/listinfo/dev</a><br>
>> >> > Ensembl Blog: <a href="http://www.ensembl.info/">http://www.ensembl.info/</a><br>
>> >> ><br>
>> >><br>
>> >> --<br>
>> >> Matthieu Muffato, Ph.D.<br>
>> >> Ensembl Developer and Ensembl Compara Manager<br>
>> >> European Bioinformatics Institute (EMBL-EBI)<br>
>> >> European Molecular Biology Laboratory<br>
>> >> Wellcome Trust Genome Campus, Hinxton<br>
>> >> Cambridge, CB10 1SD, United Kingdom<br>
>> >> Room A3-145<br>
>> >> Phone + 44 (0) 1223 49 4631<br>
>> >> Fax + 44 (0) 1223 49 4468<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Dev mailing list Dev@ensembl.org<br>
>> >> Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev">
http://lists.ensembl.org/mailman/listinfo/dev</a><br>
>> >> Ensembl Blog: <a href="http://www.ensembl.info/">http://www.ensembl.info/</a><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Dev mailing list Dev@ensembl.org<br>
>> > Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev">
http://lists.ensembl.org/mailman/listinfo/dev</a><br>
>> > Ensembl Blog: <a href="http://www.ensembl.info/">http://www.ensembl.info/</a><br>
>> ><br>
>><br>
>> --<br>
>> Matthieu Muffato, Ph.D.<br>
>> Ensembl Developer and Ensembl Compara Manager<br>
>> European Bioinformatics Institute (EMBL-EBI)<br>
>> European Molecular Biology Laboratory<br>
>> Wellcome Trust Genome Campus, Hinxton<br>
>> Cambridge, CB10 1SD, United Kingdom<br>
>> Room A3-145<br>
>> Phone + 44 (0) 1223 49 4631<br>
>> Fax + 44 (0) 1223 49 4468<br>
>><br>
>> _______________________________________________<br>
>> Dev mailing list Dev@ensembl.org<br>
>> Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev">
http://lists.ensembl.org/mailman/listinfo/dev</a><br>
>> Ensembl Blog: <a href="http://www.ensembl.info/">http://www.ensembl.info/</a><br>
><br>
><br>
> _______________________________________________<br>
> Dev mailing list Dev@ensembl.org<br>
> Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev">
http://lists.ensembl.org/mailman/listinfo/dev</a><br>
> Ensembl Blog: <a href="http://www.ensembl.info/">http://www.ensembl.info/</a><br>
><br>
<br>
-- <br>
Matthieu Muffato, Ph.D.<br>
Ensembl Developer and Ensembl Compara Manager<br>
European Bioinformatics Institute (EMBL-EBI)<br>
European Molecular Biology Laboratory<br>
Wellcome Trust Genome Campus, Hinxton<br>
Cambridge, CB10 1SD, United Kingdom<br>
Room A3-145<br>
Phone + 44 (0) 1223 49 4631<br>
Fax + 44 (0) 1223 49 4468<br>
<br>
_______________________________________________<br>
Dev mailing list Dev@ensembl.org<br>
Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev">
http://lists.ensembl.org/mailman/listinfo/dev</a><br>
Ensembl Blog: <a href="http://www.ensembl.info/">http://www.ensembl.info/</a><br>
</div>
</div>
</body>
</html>