From: Scott C. <ca...@cs...> - 2004-10-20 21:33:36
|
On Wed, 2004-10-20 at 17:11, Chris Mungall wrote: > On Wed, 20 Oct 2004, Scott Cain wrote: > > > (I put gmod-devel back on the cc list, since the chado-seq-ad list is > > quite small, and I believe there are people of the main dev list that > > will be interested.) > > If you're sure - although wouldn't gmod-schema be more appropriate? Allen choose devel, so I figured I'd go back to that. > > > I think this is what I had in mind, even though it wasn't a fully formed > > thought. > > Now I am really confused - you were originally proposing an SQL API, but > now you're saying that Guanming's idea for a java OO API is actually what > you had in mind...? > > If this was what you had in mind all along, fair enough, although I think > you were onto something with the idea of an SQL API, and Aaron seems to > agree. > > > You could imagine putting many useful functions in chado to > > get, set and delete all kinds of things. Now, getting a single feature > > is perhaps not so hard that you would need a function for it, but say, > > getting all the children of a feature is sufficiently complicated that > > it makes sense to offer a function do that rather than have all > > applications (perl and java) implement it. This function could be as > > simple as to just return a list of feature_ids, and then it is the > > object layer's job to convert feature_ids to objects. > > I can see the appeal, but this is a dangerous path to head down without > thinking things through very clearly. > > Think of all the possible constraints, qualifiers and options such an API > would have to offer just for querying. > > Would the queries be simply feature-by-name and feature-by-range? Would > there be feature-by-GO, other constraints, boolean combination of > constraints? > > How deep a feature object should be constructed? would it also contain, > say, genetic data and GO data? Would there be an option to get a 'slim' > version of a feature without all this? Would you allow fetching of both > direct children and all descendants? Across all relationship types or a > subset? Parents and ancestors too? > > If we don't think about this API very carefully from the start then the > final API may well be far more complex to use (and less flexible) than SQL > > Also, you seem to imply that this API would be usable from perl or java - > if this is an OO API I'm not sure how this would work, without some wacky > inter-language bridge or some kind of CORBA or SOAP layer. I'd caution > against this. Agreed (with all of the paragraphs above); it is definitely important to do it right, and to do the right thing in the right place. I don't think we would want any sort of OO API actually "residing" in chado as SQL functions, in fact, I don't know how that would work. What I would like to see are a set of functions that make hard things in chado much easier, using just plpgsql. They would just take and return simple scalar data, like you would get from writing SQL directly. Then there would need to be another layer for java and perl to convert that simple data to and from objects. > > > This is even more useful when you consider delete options--should the > > feature be deleted, with all children and related data, or should just > > the featurelocs be deleted or should just the relationship between the > > child and the parent be deleted? If we could wrap that in such a way as > > to make application writing easier, I think it is a big win. Another > > application that would potentially use this and a java object layer > > would be a java DAS2 client (which of course doesn't exist yet, but it > > could). Also, writing perl object layers would become significantly > > easier as well. > > OK, I admit this is hard with chado. So DAS2 allows writeback doesn't it? > So this is our second application that curates gene models in apollo so it > looks like we have the beginnings of a justification for some kind of API. Yes, and the gbrowse chado adaptor could use some of these things in a read only way that would no doubt make it cleaner and easier to use. I think the important thing is, yes, plan carefully, and keep the SQL function part simple, so that adding to it isn't too hard. > > > Scott > > > > > > On Wed, 2004-10-20 at 16:28, Chris Mungall wrote: > > > [cutting down on recipients since this was resulting in my messages being > > > held up] > > > > > > OK, I see. So you're proposing both an API and object model, with the > > > object model presumably derived directly from the chado schema. > > > > > > This seems reasonable. Although I am wondering - would apollo use this > > > API? Who else would use it? (ie how many other java applications will > > > there be that are for curating gene models) > > > > > > On Wed, 20 Oct 2004, Guanming Wu wrote: > > > > > > > What I talked is about another layer that is implemented in Java, wraps > > > > SQL functions to be implemented by Scott (if so), and can be used by > > > > Apollo JDBC or other Java applications. > > > > > > > > Thanks, > > > > > > > > Guanming > > > > > > > > Chris Mungall wrote: > > > > > > > > >Hi Guanming > > > > > > > > > >I'm not sure I follow. What you have below looks like a traditional OO > > > > >API. What Scott was proposing was a DBMS API implemented using database > > > > >procedures/functions. A DBMS API would not be able to accept objects > > > > >(well, you could use pljava but I think this would be a very bad idea!). > > > > > > > > > >A DBMS API would have to have fairly atomic calls; eg > > > > > > > > > > add_transcript(name,uniquename,nbeg,nend,strand,srcfeature_id) > > > > > > > > > >Cheers > > > > >Chris > > > > > > > > > >On Wed, 20 Oct 2004, Guanming Wu wrote: > > > > > > > > > > > > > > > > > > > >>Hi Scott, > > > > >> > > > > >>Are you going to go ahead to implement it actually? If you will, I guess > > > > >>Apollo JDBC can just use your API and will be much, much, much simpler. > > > > >>Probably Mark and I can wrap your SQL functions in Java as Java API, and > > > > >>use this Java API in Apollo. Also, we can create a standard-alone Java > > > > >>package (as Jar file) for chado, so that other users can directly use > > > > >>this Jar file for their own purposes. Here is an example how to use: > > > > >> > > > > >>Chado chado = ChadoFactory.init(dbName, dbPort, dbUser, dbPwd); > > > > >>Feature tran = chado.getFeature(uniquename); > > > > >>Feature newExon = new Feature(exonName); > > > > >>// Specify other info for newExon > > > > >>chado.insertExon(tran, newExon); > > > > >> > > > > >>It is blessing if chado can have something like the above. Actually, > > > > >>acedb has a very good API in perl, java, or c. > > > > >> > > > > >>Thanks, > > > > >> > > > > >>Guanming > > > > >> > > > > >> > > > > >>Scott Cain wrote: > > > > >> > > > > >> > > > > >> > > > > >>>Right, the reason I suggest SQL is that is the lowest common > > > > >>>denominator--writing wrappers in Perl or Java would be trivial, and > > > > >>>would give us a single place to fix things (I almost wrote a "single > > > > >>>point of failure", but I didn't want to sound to pessimistic :-) > > > > >>> > > > > >>> > > > > >>>On Wed, 2004-10-20 at 13:15, Guanming Wu wrote: > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>>>It will be great if such API exists. It can be in SQL, Perl, Java, C/C++. > > > > >>>> > > > > >>>>Guanming > > > > >>>> > > > > >>>>Scott Cain wrote: > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>>I've spent about a day mulling this over. I completely sympathize with > > > > >>>>>Chris' and Dave's concerns over implementing a 'non-shared' exon > > > > >>>>>schema. Certainly, the schema was built to support it, so why shouldn't > > > > >>>>>we? > > > > >>>>> > > > > >>>>>On thinking about it, what it really seems like we need is an API, or > > > > >>>>>something like it. At a GMOD developers meeting last year, a group of > > > > >>>>>eight or ten of us sat in a room trying to hammer out a developer's > > > > >>>>>guide. During that meeting, we decided that the point of common > > > > >>>>>interaction between applications would be the schema, so any API like > > > > >>>>>thing needs to exist inside the schema, via triggers, functions and > > > > >>>>>possibly rules. So what if there were functions like 'delete_gene' and > > > > >>>>>'add_exon_to_gene' that could be executed via SQL commands. Would this > > > > >>>>>help? It certainly seems like it would facilitate the creation of a > > > > >>>>>Apollo JDBC adaptor, as well as facilitate the creation of a DAS2 layer. > > > > >>>>> > > > > >>>>>Comments? > > > > >>>>> > > > > >>>>>Scott > > > > >>>>> > > > > >>>>>On Tue, 2004-10-19 at 11:45, David Emmert wrote: > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>>Hi, > > > > >>>>>> > > > > >>>>>>I completely disagree with any proposal to institute "unshared" exons in > > > > >>>>>>chado, whether as an interim step or as standard practice. The proposal > > > > >>>>>>to have "unshared" exons in the database is both bad biology and bad > > > > >>>>>>database practice. > > > > >>>>>> > > > > >>>>>>As Chris pointed out, the identity of an exon is defined by its genomic > > > > >>>>>>position. Implementing multiple identical exons based on transcript > > > > >>>>>>context effectively denormalizes the database. > > > > >>>>>> > > > > >>>>>>It may be convenient for Apollo not to worry about normalizing data in > > > > >>>>>>its internal model, but that certainly doesn't mean that for the sake of > > > > >>>>>>Apollo's convenience, we should just forget about having a normal > > > > >>>>>>back-end database altogether. > > > > >>>>>> > > > > >>>>>>Chris is right that this makes the apollo fine-grained transaction > > > > >>>>>>adaptor approach gnarlier, but it was clear from the beginning that > > > > >>>>>>taking this approach was going to lead to some tough data issues which > > > > >>>>>>would have to be addressed. It would be a terrible mistake to try to > > > > >>>>>>avoid dealing with a difficult, though completely solveable, apollo > > > > >>>>>>issue by compromising both SO and chado. > > > > >>>>>> > > > > >>>>>>-Dave > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>On 10/19/04 at 14:32 Scott Cain wrote: > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>>I think we are talking about a database/book keeping point of view, > > > > >>>>>>>versus the biologist point of view. From a programming perspective > > > > >>>>>>>(at > > > > >>>>>>>least mine), it makes life much easier if I can refer to an exon that > > > > >>>>>>>is > > > > >>>>>>>shared among splice variants as separate entities, at least most of > > > > >>>>>>>the > > > > >>>>>>>time. From a biologist's perspective, this is ridiculous, but I don't > > > > >>>>>>>see any reason why the biologist-user should ever see the data > > > > >>>>>>>presented > > > > >>>>>>>that way in an application, even if I do store them as separate > > > > >>>>>>>entities. > > > > >>>>>>> > > > > >>>>>>>For example, if I wanted to count the number of exons in a genome or > > > > >>>>>>>the > > > > >>>>>>>average number of exons per gene, it requires remembering to do a > > > > >>>>>>>GROUP > > > > >>>>>>>BY when the type is exon and the genomic coordinates are equal (which > > > > >>>>>>>could be done via a view and/or functions to do the common work). > > > > >>>>>>>What > > > > >>>>>>>I am trying to say is that I think it should be easier to "collapse" > > > > >>>>>>>to > > > > >>>>>>>shared exons when you want to that to force the database and > > > > >>>>>>>applications that talk to it to require the sharing of exons. > > > > >>>>>>> > > > > >>>>>>>Scott > > > > >>>>>>> > > > > >>>>>>>On Tue, 2004-10-19 at 01:43, Shengqiang Shu wrote: > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>are we really talking about practicality or sematics here? > > > > >>>>>>>> > > > > >>>>>>>>either way to store exons in db has its own implication on > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>application > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>software. > > > > >>>>>>>> > > > > >>>>>>>>are exons component parts of a transcript (analog: arms are parts of > > > > >>>>>>>>human body)? if so, can an integral part of a thing be shared with > > > > >>>>>>>>another thing of the same kind? > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>>Shu > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>>Sima Misra wrote: > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>>>I'm with Chris, here, Mark and Scott. > > > > >>>>>>>>> > > > > >>>>>>>>>An exon with the same genomic coordinates shared by multiple > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>transcripts > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>should be considered one exon. > > > > >>>>>>>>> > > > > >>>>>>>>>-sima > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>>>Sorry Scott, I'm afraid I completely disagree > > > > >>>>>>>>>> > > > > >>>>>>>>>>Chado cares a lot about the definition of exon. If there is no > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>defined > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>concept of exon then we lose interoperability. There's plenty of > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>software > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>beyond gbrowse that uses chado, including things such as in-house > > > > >>>>>>>>>>reporting script that gives things such as exon counts and exon > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>context > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>counts. > > > > >>>>>>>>>> > > > > >>>>>>>>>>Chado should use the SO definition of exon. Currently there is no > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>explicit > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>account of identity in the SO definition, but it is strongly > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>hinted at. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>The identity of an exon is defined by it's 5' and 3' edges on the > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>genome > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>-- not transcript. The SO definition essentially says this, but we > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>could > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>make it more clear that different transcript contexts do not make > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>for > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>different exons if the genomic coordinates are identical. I > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>believe that > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>all biologists would agree on this definition, and it isn't up for > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>debate. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>Apollo can model exons internally however it likes. However, once > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>it > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>exports to a SO-compliant model such as chado it has to conform to > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>SO. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>I think it would be very a bad idea to release a version of the > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>adapter > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>which exported to a non-SO compliant chado database, and an > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>absolutely > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>terrible idea to to release an exporter than exported chado that > > > > >>>>>>>>>>conflicted with SO. > > > > >>>>>>>>>> > > > > >>>>>>>>>>Databases being what they are, the initial release would quickly > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>ossify to > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>become the de-facto standard, and we would lose interoperability. > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>If you > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>must do this, then use a different feature type such as > > > > >>>>>>>>>>'exon_transcript_context'. Even though this is not in SO (and > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>never should > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>be) it is at least not inconsistent with SO. > > > > >>>>>>>>>> > > > > >>>>>>>>>>Sorry if this makes things a bit gnarlier as far as fine-grained > > > > >>>>>>>>>>transactions go - but we have known about this issue from the > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>beginning: > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>http://sourceforge.net/mailarchive/message.php?msg_id=9580964 > > > > >>>>>>>>>> > > > > >>>>>>>>>>Perhaps to make things easier you could make the first release > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>simply blow > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>away all old exons and insert them as new. This is how the current > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>course > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>grained transaction framework in place at FlyBase works. Of > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>course, you > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>would lose exon tracking, I'm not sure how big a deal that is for > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>people. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>Cheers > > > > >>>>>>>>>>Chris > > > > >>>>>>>>>> > > > > >>>>>>>>>>On Mon, 18 Oct 2004, Scott Cain wrote: > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>>>I sent this out to the wider list, since the cc list was getting > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>long > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>anyway... > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>I don't have a problem mandating non-shared exons, because it > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>makes life > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>so much easier. Hopefully the flybase people would agree, even > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>if > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>that's not what they've got now. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>At the moment, I don't think chado cares whether exons are shared > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>or > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>not. Certainly, the GFF3 loader handles multiple Parent > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>annotations for > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>a single feature. Also, the GBrowse adaptor shouldn't care > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>either, > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>though I can't say off hand if that is really true. If it isn't, > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>it is > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>a bug I'll need to fix. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>As to Doreen's question about supporting flybase, I believe, > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>(Mark or > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>Suzi, correct me if I am wrong) that the chado connectivity that > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>is > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>being developed is essentially "from scratch" and flybase won't > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>be using > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>it in the short term no matter what, so doing the easy thing > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>first > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>(non-shared exons) is the smart thing to do. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>Scott > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>On Mon, 2004-10-18 at 14:25, Guanming Wu wrote: > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>>Hi Scott, > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>>Non-shared exon will make implementation in Apollo much easier > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>indeed. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>However, how about the chado database in general? Mark and I are > > > > >>>>>>>>>>>>worrying about locking ourselfves (or Apollo) to a specific case > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>in the > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>rice if Chado is still using shared exons. > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>>Another question is that changing from sharing (I guess default > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>in > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>chado) to non-sharing will effect the downstream applications > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>(e.g. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>GBrowse)? > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>>Thanks, > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>>Guanming > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>>Ware, Doreen wrote: > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>>>Hi Scott, > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>We will be giving them Fgenesh models. I do know if Fgenesh > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>has shared > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>exons? (steve). From the data we observed the students may > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>want to send > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>back shared exons based upon the experimental evidence. Steve > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>will > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>comment also. > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>If Fly requires shared exons, and there is no extra burden, is > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>there a > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>problem with including this? > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>Doreen > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>-----Original Message----- > > > > >>>>>>>>>>>>>From: Scott Cain [mailto:ca...@cs...] > > > > >>>>>>>>>>>>>Sent: Monday, October 18, 2004 2:02 PM > > > > >>>>>>>>>>>>>To: Guanming Wu > > > > >>>>>>>>>>>>>Cc: Mark Gibson; Doreen Ware > > > > >>>>>>>>>>>>>Subject: Re: shared or non-shared exon in the rice database > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>Hi Guanming, > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>I think this depends on what we have as starting material. If > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>we only > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>have similarity data to start with and will be creating gene > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>models from > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>scratch, we could use nonshared exons, since it makes > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>development MUCH > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>easier, unless there is a good reason not to (Doreen?). > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>Scott > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>On Mon, 2004-10-18 at 13:47, Guanming Wu wrote: > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>Hi Scott, > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>I wonder if exons in the rice database will be shared or > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>non-shared. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>The > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>decision somewhat effects our implementation of chado > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>transaction xml. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>>>>>Thanks, > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>Guanming > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>------------------------------------------------------- > > > > >>>>>>>>>>This SF.net email is sponsored by: IT Product Guide on > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>ITManagersJournal > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>Use IT products in your business? Tell us what you think of them. > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>Give us > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>out more > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>>http://productguide.itmanagersjournal.com/guidepromo.tmpl > > > > >>>>>>>>>>_______________________________________________ > > > > >>>>>>>>>>Gmod-chado-seq-ad mailing list > > > > >>>>>>>>>>Gmo...@li... > > > > >>>>>>>>>>https://lists.sourceforge.net/lists/listinfo/gmod-chado-seq-ad > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>------------------------------------------------------- > > > > >>>>>>>>>This SF.net email is sponsored by: IT Product Guide on > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>ITManagersJournal > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>Use IT products in your business? Tell us what you think of them. > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>Give us > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>out more > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>>>http://productguide.itmanagersjournal.com/guidepromo.tmpl > > > > >>>>>>>>>_______________________________________________ > > > > >>>>>>>>>Gmod-chado-seq-ad mailing list > > > > >>>>>>>>>Gmo...@li... > > > > >>>>>>>>>https://lists.sourceforge.net/lists/listinfo/gmod-chado-seq-ad > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>-- > > > > >>>>>>>------------------------------------------------------------------------ > > > > >>>>>>>Scott Cain, Ph. D. > > > > >>>>>>>ca...@cs... > > > > >>>>>>>GMOD Coordinator (http://www.gmod.org/) > > > > >>>>>>>216-392-3087 > > > > >>>>>>>Cold Spring Harbor Laboratory > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>------------------------------------------------------- > > > > >>>>>>>This SF.net email is sponsored by: IT Product Guide on > > > > >>>>>>>ITManagersJournal > > > > >>>>>>>Use IT products in your business? Tell us what you think of them. Give > > > > >>>>>>>us > > > > >>>>>>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > > > > >>>>>>>more > > > > >>>>>>>http://productguide.itmanagersjournal.com/guidepromo.tmpl > > > > >>>>>>>_______________________________________________ > > > > >>>>>>>Gmod-chado-seq-ad mailing list > > > > >>>>>>>Gmo...@li... > > > > >>>>>>>https://lists.sourceforge.net/lists/listinfo/gmod-chado-seq-ad > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > > > Use IT products in your business? Tell us what you think of them. Give us > > > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > > > http://productguide.itmanagersjournal.com/guidepromo.tmpl > > > _______________________________________________ > > > Gmod-chado-seq-ad mailing list > > > Gmo...@li... > > > https://lists.sourceforge.net/lists/listinfo/gmod-chado-seq-ad > > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. ca...@cs... GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory |