gusdev-gusdev — Topics concerning GUS development

[GUSDEV] GUS @ BOSC?

[Michael S. <msa...@pc...>]

Since there wasn't any interest in a GUS meetup at the Bioinformatics  
Hackathon, we'd thought we'd see if there was greater interest for a  
GUS meeting/hackathon/get together in conjunction with BOSC/ISMB:

http://open-bio.org/bosc2005/

Anyone out there interested in GUS User group meetings?

--Mike


On Apr 22, 2005, at 6:36 PM, Michael Saffitz wrote:

>
> There's been some talk on various Bioinformatic mailing lists of a  
> "hackathon" coinciding with Apple's WWDC this June (see below).
>
> Are any GUS users out there thinking about attending either the  
> hackathon or the WWDC, and if so, is there any interest in forming  
> a GUS contingent?
>
> Possible topics and areas of development could include plugin work,  
> support for integrating other databases (i.e. tools to load data  
> from chado databases), object layer development/improvements, ????  
> ideas ?
>
> --Mike
>
>
>>> From: Suzanna Lewis <su...@fr...>
>>> Date: April 20, 2005 6:42:29 PM EDT
>>> To: da...@bi..., bak...@bi...,
>>> bio...@bi..., "go-...@ge..."
>>> <go-...@ge...>, go-...@fr...,
>>> mge...@li...,
>>> gmo...@li..., bio...@op...,
>>> bio...@bi..., em...@em...
>>> Cc: George Hartzell <har...@ke...>, Cyrus Harmon
>>> <cy...@cy...>, Steve Chervitz
>>> <Ste...@af...>
>>> Subject: Hackathon 2005
>>>
>>> (sorry for multiple postings, but please do forward to
>>> anyone else who you think might be interested)
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> ----------
>>>
>>> Dear everyone,
>>>
>>> It has been a long time and we Bioinformatics devotees are  
>>> overdue for
>>> another total-immersion coding-fest (the last hackathon was held in
>>> Singapore February 2003, more than two years ago).  Apple has  
>>> offered
>>> to host us this year, and as an added bonus include free  
>>> admission to
>>> the World-Wide Developers Conference in San Francisco the prior  
>>> week.
>>> They are also looking for some people to present interesting new
>>> developments at the WWDC, so if you have something noteworthy please
>>> let us know. Apple is not attaching any strings, so our work need  
>>> not
>>> address Apple-specific software or hardware areas. Apple will  
>>> provide
>>> space and hardware (and access to their engineers if we'd like).
>>>
>>> Week 1 (June 6-10) would be spent at the WWDC. Week 2 (June 12-16)
>>> would be in Cupertino, at Apple's headquarters.  We're free to focus
>>> on what interests us, our tentative plans include:
>>>
>>>   1. Bio-ontologies software
>>>   2. High-performance computing (e.g. large scale computations,
>>> optimization)
>>>   3. Image analysis
>>>   4. Documentation
>>>   5. Anything else that may interest you
>>>
>>> Our plan is to organize this much as the Aspen Center for Physics
>>> computational biology workshops were organized (for those old enough
>>> to
>>> remember): A couple of presentations to start the day; collaboration
>>> and coding afterwards; time for a bit of fun (does anyone else
>>> cycle?), and discussions in the late afternoons and evenings.
>>>
>>> Would everyone who is interested in attending please send us a short
>>> description of what you would like to do, and perhaps other  
>>> people who
>>> you would like to work with. There is somewhat limited space, so we
>>> will try to prioritize groups that have a clear focus and a need to
>>> interact. We now this is very short notice, but we hope that there
>>> will be enough interest to make it possible.
>>>
>>> We are looking into additional funding support, to pay for travel
>>> expenses, but this is still to be decided.
>>>
>>> Looking forward to hearing from everyone.
>>> George, Cyrus, Steve, and Suzanna (the Bay Area locals)
>>>
>>>
>>> --
>>> This message is from the GOFriends moderated mailing list.  A  
>>> list of
>>> public
>>> announcements and discussion of the Gene Ontology (GO) project.
>>> Problems with the list?           E-mail:
>>> own...@ge...
>>> Subscribing   send   "subscribe"   to
>>> gof...@ge...
>>> Unsubscribing send   "unsubscribe"  to
>>> gof...@ge...
>>> Web:          http://www.geneontology.org/
>>>
>>
>

Re: [GUSDEV] GBParser error

[Thomas O. <ot...@fi...>]

Hi Fabricio,

did you try the insert with another seqeunce? Does the same errors occure?
Looks like, that your genbank entry is not well formated... maybe attach 
it, and I will try to insert it in our DB, without commit. Is it 
NA-Sequence?

Cheers,
Thomas
fab...@de... wrote:

>Hello all,
>
>we are trying to load a genbank file into GUS by GBParser. We downloaded a file
>from NCBI (sequences.gb) as a result search about "tripanosoma cruzi". When we
>executed the command to run the GBParser (ga GUS::Common::Plugin::GBParser
>--file=sequences.gb --gbRel=145.0 --db_rel_id=62 --commit) we got the following
>outputs  on the screen:
>
>...
>ERR     LINE=234512     unparsed line                       
>/locus_tag="SCO7809"
>ERR     LINE=234513     unparsed line                        /note="SC8E7.06,
>possible TetR-family transcriptional
>ERR     LINE=234514     unparsed line                        regulator, len:
>210
>aa. Similar to several other members
>ERR     LINE=234515     unparsed line                        of the TetR-family
>e.g. Streptomyces glaucescens
>ERR     LINE=234516     unparsed line                        SW:TCMR_STRGA
>(EMBL:M80674) tetracenomycin C
>ERR     LINE=234517     unparsed line                        transcriptional
>repressor, TcmR (226 aa), fasta scores
>ERR     LINE=234518     unparsed line                        opt: 187 z-score:
>235.6 E(): 1.2e-05 26.4% identity in 197
>ERR     LINE=234519     unparsed line                        aa overlap and
>Streptomyces coelicolor TR:CAB88457
>ERR     LINE=234520     unparsed line                        (EMBL:AL353815)
>putative TetR-family transcriptional
>...
>and finally this,
>ERR     LINE=235521     unparsed line        RBS            
>complement(8667068..8667073)
>VLD     CBIL::Bio::GenBank::Origin      1
>Tue May  3 15:28:12 2005        STATUS  N=1 ACC=NC_003888       
>TOTAL_OBJECTS=17
>Tue May  3 15:28:35 2005        Genbank entries inserted= 0;  updated= 0; total
>#(inserted::updated::deleted)=17::::
>Tue May  3 15:28:35 2005        FAILURES        Unable to process 2 entries.
>See
>gbparserFailures/
>Tue May  3 15:28:35 2005        RESULT  Genbank entries inserted= 0;  updated=
>0;  failed= 2
>
>In the gbparserFailures/errors file has only this two lines:
>
>------------------ entry number 1 -----------------
>Can't call method "getSingleFeature" on an undefined value at
>/usr/local/GUS/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 311, <GEN0>
>line 379982.
>------------------ entry number 2 -----------------
>Can't call method "getAccession" on an undefined value at
>/usr/local/GUS/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 223, <GEN0>
>line 379983.
>
>Does anyone know what the problem is?
>
>Thanks a lot.
>
>
>----------------------------------------------------------------
>This message was sent using IMP, the Internet Messaging Program.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: NEC IT Guy Games.
>Get your fingers limbered up and give it your best shot. 4 great events, 4
>opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
>win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>  
>

Re: [GUSDEV] GUS 3.5 Schema -- Final

[Sucheta T. <su...@vb...>]

Mike,

I will be happy to assist in plugin creation and testing. Please let me 
know which all plugins you are creating and which still needs be done.

Best

Sucheta

At 05:26 PM 5/3/2005 -0400, Michael Saffitz wrote:


>All,
>
>The final schema for GUS 3.5 is attached.  Any changes at this point
>should be entered in the GUS Tracker for inclusion in a future
>release of GUS.
>
>Work is now underway in readying plugins and the application
>framework for GUS 3.5, as well as documentation development.  Please
>let me know if you have any questions or would like to help out in
>any way.
>
>Thanks,
>
>Mike
>
>

Re: [GUSDEV] GUS 3.5 Schema -- Final

[Jian Lu <jl...@vb...>]

To help debug for plugins, I have log files for all plugin registration 
error messages. No error from GoPridict plugin.

Jian
VBI

Michael Saffitz wrote:

>
>
> All,
>
> The final schema for GUS 3.5 is attached.  Any changes at this point  
> should be entered in the GUS Tracker for inclusion in a future  
> release of GUS.
>
> Work is now underway in readying plugins and the application  
> framework for GUS 3.5, as well as documentation development.  Please  
> let me know if you have any questions or would like to help out in  
> any way.
>
> Thanks,
>
> Mike

[GUSDEV] GUS 3.5 Schema -- Final

[Michael S. <MSA...@pc...>]

All,

The final schema for GUS 3.5 is attached.  Any changes at this point  
should be entered in the GUS Tracker for inclusion in a future  
release of GUS.

Work is now underway in readying plugins and the application  
framework for GUS 3.5, as well as documentation development.  Please  
let me know if you have any questions or would like to help out in  
any way.

Thanks,

Mike

[GUSDEV] GBParser error

[<fab...@de...>]

Hello all,

we are trying to load a genbank file into GUS by GBParser. We downloaded =
a file
from NCBI (sequences.gb) as a result search about "tripanosoma cruzi". Wh=
en we
executed the command to run the GBParser (ga GUS::Common::Plugin::GBParse=
r
--file=3Dsequences.gb --gbRel=3D145.0 --db_rel_id=3D62 --commit) we got t=
he following
outputs  on the screen:

...
ERR     LINE=3D234512     unparsed line                      =20
/locus_tag=3D"SCO7809"
ERR     LINE=3D234513     unparsed line                        /note=3D"S=
C8E7.06,
possible TetR-family transcriptional
ERR     LINE=3D234514     unparsed line                        regulator,=
 len:
210
aa. Similar to several other members
ERR     LINE=3D234515     unparsed line                        of the Tet=
R-family
e.g. Streptomyces glaucescens
ERR     LINE=3D234516     unparsed line                        SW:TCMR_ST=
RGA
(EMBL:M80674) tetracenomycin C
ERR     LINE=3D234517     unparsed line                        transcript=
ional
repressor, TcmR (226 aa), fasta scores
ERR     LINE=3D234518     unparsed line                        opt: 187 z=
-score:
235.6 E(): 1.2e-05 26.4% identity in 197
ERR     LINE=3D234519     unparsed line                        aa overlap=
 and
Streptomyces coelicolor TR:CAB88457
ERR     LINE=3D234520     unparsed line                        (EMBL:AL35=
3815)
putative TetR-family transcriptional
...
and finally this,
ERR     LINE=3D235521     unparsed line        RBS           =20
complement(8667068..8667073)
VLD     CBIL::Bio::GenBank::Origin      1
Tue May  3 15:28:12 2005        STATUS  N=3D1 ACC=3DNC_003888      =20
TOTAL_OBJECTS=3D17
Tue May  3 15:28:35 2005        Genbank entries inserted=3D 0;  updated=3D=
 0; total
#(inserted::updated::deleted)=3D17::::
Tue May  3 15:28:35 2005        FAILURES        Unable to process 2 entri=
es.
See
gbparserFailures/
Tue May  3 15:28:35 2005        RESULT  Genbank entries inserted=3D 0;  u=
pdated=3D
0;  failed=3D 2

In the gbparserFailures/errors file has only this two lines:

------------------ entry number 1 -----------------
Can't call method "getSingleFeature" on an undefined value at
/usr/local/GUS/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 311, =
<GEN0>
line 379982.
------------------ entry number 2 -----------------
Can't call method "getAccession" on an undefined value at
/usr/local/GUS/gus_home/lib/perl/GUS/Common/Plugin/GBParser.pm line 223, =
<GEN0>
line 379983.

Does anyone know what the problem is?

Thanks a lot.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [GUSDEV] LoadBLATAlignment and gaptables

[Y. T. G. <yon...@pc...>]

Yes you should use the new version from now on, but if you have already 
loaded all your alignments then there is no reason for a redo.

The plugin reads the raw output files (.pls files) from the BLAT program 
that you ran prior to your calling this plugin, so if you do not delete 
those files, the original alignment results will be there. There are 
several rounds of filtering:
1) the BLAT program by default only reports DNA alignments of 
identity >= 90% and alignment score of >= 30 (i.e. roughly 30 nucleotides in length). 
Alignments inferior in quality will not be in you .pls files
2) the LoadBLATAlignments plugin by default (you can certainly adjust 
this) discards alignments that span less than 10% of the query. These 
alignments will stay in the raw output files but they won't be loaded into 
GUS. Whether an alignment is loaded is not affected in anyway by the 4 
categories: they are just there as an annotation.
3) the plugin also has a "keep_best" option. If it is set to 1, it keeps 
the best alignment for each query sequence while deleting others. If it is 
set to 2, it keeps top alignments (whoses alignment score is within 1% of 
the best score, defined as the square root of %identity times %query 
aligned, for that specific query sequence).

Hope this helps and let me know if you have more questions.

-Thomas

On Sun, 1 May 2005, Sucheta Tripathy wrote:

> Hi Thomas,
>
> Thanks for the reply. I am using the older version of the plugin, I will
> update it..
>
> In fact, now I forced the alignments to be loaded even without the
> gaptables, by assigning some return values in BLAT::Alignment file. I
> guess it is not the right way to do.
>
> Another question I have is, with the new plugin, is there a possibility
> that some of the alignments will be thrown out, if it does not belong to
> these 4 categories? In this particular instance I found atleast some of
> the alignments are thrown out, and also if the alignments that are not
> loaded, are they stored in some file for look up later.
>
> Many thanks
>
> Sucheta
>> Hi Sucheta:
>> What version of the plugin are you using? The latest version (1.35) has
>> gapTableSpace as a command line option, and it is optional.
>>
>> When we load BLAT alignments of cDNAs, we may take into consideration
>> alignments that span or fall on the edge of a gap in the genomic sequence.
>> We usually import the per chromosome gap tables from GoldenPath into a
>> temporary table space. The temp table space (e.g. ygan is my personal
>> schema) needs to be separate from GUS schemas as DDL operations to them
>> are restricted and the number and names of gap tables change from version
>> to version. The gap information is only used to classify alignments into
>> one of 4 categories: very good alignments, very good but contain/close to
>> genomic gaps, good, and others.
>>
>> That said, you may not care about gaps at all or can safely ignore
>> the impact of gaps in your case. As of a version later than the one you
>> have, you do not have to worry about gap tables any more - just do not
>> set the gapTableSpace option in the command line.
>>
>> -Thomas
>>
>> On Fri, 29 Apr 2005, Sucheta Tripathy wrote:
>>
>>> Dear group,
>>>
>>> I am trying to use the plugin LoadBLATAlignment, but can't figure out
>>> where
>>> to define my gaptable(as I see in line 452
>>>
>>> 452     my $gapTable = 'ygan.' . $ext_genome_ver . '_' . $target_id .
>>> '_gap'
>>>    ;)
>>>
>>> If I have to define a table for gap regions, can anyone please suggest
>>> what
>>> are the fields.
>>>
>>> Do I need to pre-load some data into them?
>>>
>>> Many thanks
>>>
>>> Sucheta
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: NEC IT Guy Games.
>>> Get your fingers limbered up and give it your best shot. 4 great events,
>>> 4
>>> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
>>> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>
>>
>
>
> -- 
> Sucheta Tripathy
> Virginia Bioinformatics Institute Phase-I
> Washington street.
> Virginia Tech.
> Blacksburg,VA 24061-0447
> phone:(540)231-8138
> Fax:  (540) 231-2606
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Re: [GUSDEV] LoadBLATAlignment and gaptables

[Sucheta T. <su...@vb...>]

Hi Thomas,

Thanks for the reply. I am using the older version of the plugin, I will
update it..

In fact, now I forced the alignments to be loaded even without the
gaptables, by assigning some return values in BLAT::Alignment file. I
guess it is not the right way to do.

Another question I have is, with the new plugin, is there a possibility
that some of the alignments will be thrown out, if it does not belong to
these 4 categories? In this particular instance I found atleast some of
the alignments are thrown out, and also if the alignments that are not
loaded, are they stored in some file for look up later.

Many thanks

Sucheta
> Hi Sucheta:
> What version of the plugin are you using? The latest version (1.35) has
> gapTableSpace as a command line option, and it is optional.
>
> When we load BLAT alignments of cDNAs, we may take into consideration
> alignments that span or fall on the edge of a gap in the genomic sequence.
> We usually import the per chromosome gap tables from GoldenPath into a
> temporary table space. The temp table space (e.g. ygan is my personal
> schema) needs to be separate from GUS schemas as DDL operations to them
> are restricted and the number and names of gap tables change from version
> to version. The gap information is only used to classify alignments into
> one of 4 categories: very good alignments, very good but contain/close to
> genomic gaps, good, and others.
>
> That said, you may not care about gaps at all or can safely ignore
> the impact of gaps in your case. As of a version later than the one you
> have, you do not have to worry about gap tables any more - just do not
> set the gapTableSpace option in the command line.
>
> -Thomas
>
> On Fri, 29 Apr 2005, Sucheta Tripathy wrote:
>
>> Dear group,
>>
>> I am trying to use the plugin LoadBLATAlignment, but can't figure out
>> where
>> to define my gaptable(as I see in line 452
>>
>> 452     my $gapTable = 'ygan.' . $ext_genome_ver . '_' . $target_id .
>> '_gap'
>>    ;)
>>
>> If I have to define a table for gap regions, can anyone please suggest
>> what
>> are the fields.
>>
>> Do I need to pre-load some data into them?
>>
>> Many thanks
>>
>> Sucheta
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: NEC IT Guy Games.
>> Get your fingers limbered up and give it your best shot. 4 great events,
>> 4
>> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
>> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>


-- 
Sucheta Tripathy
Virginia Bioinformatics Institute Phase-I
Washington street.
Virginia Tech.
Blacksburg,VA 24061-0447
phone:(540)231-8138
Fax:  (540) 231-2606

Re: [GUSDEV] LoadBLATAlignment and gaptables

[Y. T. G. <yon...@pc...>]

Hi Sucheta:
What version of the plugin are you using? The latest version (1.35) has 
gapTableSpace as a command line option, and it is optional.

When we load BLAT alignments of cDNAs, we may take into consideration 
alignments that span or fall on the edge of a gap in the genomic sequence. 
We usually import the per chromosome gap tables from GoldenPath into a 
temporary table space. The temp table space (e.g. ygan is my personal 
schema) needs to be separate from GUS schemas as DDL operations to them 
are restricted and the number and names of gap tables change from version 
to version. The gap information is only used to classify alignments into 
one of 4 categories: very good alignments, very good but contain/close to 
genomic gaps, good, and others.

That said, you may not care about gaps at all or can safely ignore 
the impact of gaps in your case. As of a version later than the one you 
have, you do not have to worry about gap tables any more - just do not 
set the gapTableSpace option in the command line.

-Thomas

On Fri, 29 Apr 2005, Sucheta Tripathy wrote:

> Dear group,
>
> I am trying to use the plugin LoadBLATAlignment, but can't figure out where 
> to define my gaptable(as I see in line 452
>
> 452     my $gapTable = 'ygan.' . $ext_genome_ver . '_' . $target_id . '_gap'
>    ;)
>
> If I have to define a table for gap regions, can anyone please suggest what 
> are the fields.
>
> Do I need to pre-load some data into them?
>
> Many thanks
>
> Sucheta
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

[GUSDEV] LoadBLATAlignment and gaptables

[Sucheta T. <su...@vb...>]

Dear group,

I am trying to use the plugin LoadBLATAlignment, but can't figure out where 
to define my gaptable(as I see in line 452

452     my $gapTable = 'ygan.' . $ext_genome_ver . '_' . $target_id . '_gap'
     ;)

If I have to define a table for gap regions, can anyone please suggest what 
are the fields.

Do I need to pre-load some data into them?

Many thanks

Sucheta

Re: [GUSDEV] Preliminary 3.5 Schema

[<ju...@cs...>]

What is the rationale behind DoTS.ExternalNASequence
and DoTS.ExternalAASequence having the column:

          NAME        STRING(255)

and this column being missing from DoTS.NASequence and
DoTS.AASequence?

As I have written before, I would find it useful for query
and display purposes, to be able to refer to a sequence by a shorter
handle then something that would go into the

         DESCRIPTION   STRING(2000)

column.  Perhaps there is an intended use for DoTS.ExternalNASequence.name
that is not clear to me?

Also, we at the Preuss Lab have a need to store base quality scores
associated with many of our local sequences, and I wonder if such an
extension as the following could be added:


  DoTS::NAFragment extends DoTS.NASequence
  ----------------------------------------------------

  scores                        clob(4000)
  primer                        varchar2(255)
  plate_number                  varchar2(255)
  well_number                   varchar2(255)
  chromatogram                  varchar2(255)
  library_id                    DoTS::Library
  orientation                   number(12)
  create_date                   date(7)

the most important column being "scores clob(4000)".


Thank you.


Josef



Josef Jurek, Ph.D.

Daphne Preuss Laboratory
Molecular Genetics and Cell Biology
The University of Chicago
ju...@cs...

voice: (773) 834-3985
fax:   (773) 702-6648

Re: [GUSDEV] Regarding comment tables in the DoTS

[Bindu G. <bi...@pc...>]

Jian -
i dont think Ed mentioned explicitly how dots.nafeaturecomment is used.
here, we store the GenBank data comments in the dots.nacomment table.

Bindu


On Apr 26, 2005, at 12:42 PM, Jian Lu wrote:

> As Ed mentioned, that dots.nafeaturecomment is also used for storing 
> GenBank data comment . If I insert a new comment to 
> dots.nafeaturecomment table with the same fk na_feature_id, how could 
> I tell which one is which by query? (assuming there has been GenBank 
> comment)
>
> Thanks,
> Jian
>
> Bindu Gajria wrote:
>
>> dots.nafeaturecomment table has the field na_feature_id, which is a 
>> foreign key. plasmodium gene features are stored in dots.genefeature, 
>> whose primary key is na_feature_id. so, one can identify the comment 
>> in the nafeaturecomment table to a particular gene.
>>
>> bindu
>>
>> On Apr 26, 2005, at 11:45 AM, Jian Lu wrote:
>>
>>> Thank you all.
>>>
>>> By using dots.nafeaturecomment table, how could you tell the 
>>> comments from GenBank file or curators or other results?
>>>
>>> Jian
>>>
>>> Bindu Gajria wrote:
>>>
>>>> hi Jian -
>>>> appending to Ed's reply:
>>>> to help in curation, we have set up a mechanism in PlasmoDB to 
>>>> allow for the user community to submit (and view) comments on 
>>>> genes. and for this, PlasmoDB uses dots.nafeaturecomment table. 
>>>> will be glad to provide specifics on how this table, or the others 
>>>> are used.
>>>>
>>>> Bindu
>>>>
>>>>
>>>> On Apr 26, 2005, at 10:09 AM, Ed Robinson wrote:
>>>>
>>>>> Curation is something we are still/constantly incorporating
>>>>> into GUS.  If you can give us more information about your
>>>>> specific curatorial needs, a number of people here can point
>>>>> you to the best places to locate that information.
>>>>>
>>>>> Generally, the comment fields you are talking about are not
>>>>> used for curatorial purposes, but are used for capturing
>>>>> annotations loaded from input files such as GenBank.  For
>>>>> instance,  a comment in the header of a GenBank file would
>>>>> likely go in the comment section, a commnet or note in a gene
>>>>> feature would go in an NAComment and a comment or note in a
>>>>> CDS feature would go in an AAComment.  Of course, the tables
>>>>> you mention AAFeatureImp and NAFeatureImp are not themselves
>>>>> tables you would use directly.  Rather, you would use specific
>>>>> feature views of these tables, such as GeneFeature, Transcript
>>>>> and TranslatedAAFeature.
>>>>>
>>>>> Of course, none of this should stop you from using these
>>>>> tables in the ways that seem best for your data.  If you want
>>>>> to add free-form notes to features, these tables are are
>>>>> likely one of the better places.
>>>>>
>>>>> In general, curatorial information is found in the SRes
>>>>> tables, so you should look at those closely also.
>>>>>
>>>>> Also, you should dig around in the documentation section of
>>>>> gusdb.org.  There are some papers that discuss the schema
>>>>> buried somewhere in there.
>>>>>
>>>>> -ed
>>>>>
>>>>>
>>>>>
>>>>> ---- Original message ----
>>>>>
>>>>>> Date: Mon, 25 Apr 2005 12:11:28 -0400
>>>>>> From: Jian Lu <jl...@vb...>
>>>>>> Subject: [GUSDEV] Regarding comment tables in the DoTS
>>>>>> To: gus...@li...
>>>>>>
>>>>>> Hi GUS folks,
>>>>>>
>>>>>> I am new in GUS schema. This might not be a new question, but I 
>>>>>> just
>>>>>> want to understand more about GUS. It would be great  if someone 
>>>>>> already
>>>>>> has had answers.
>>>>>>
>>>>>> I realize that there are different comment tables at DoTS:
>>>>>>
>>>>>> COMMENTS (COMMENTS_ID, COMMENT_STRING, REVIEW_STATUS_ID, ...)
>>>>>>
>>>>>> AACOMMENT (AA_COMMENT_ID, AA_SEQUENCE_ID, COMMENT_NAME_ID,
>>>>>> COMMENT_STRING, ...)
>>>>>>
>>>>>> NACOMMENT (NA_COMMENT_ID, NA_SEQUENCE_ID, COMMENT_STRING, ...)
>>>>>>
>>>>>> They have all common attributes (comment_id and comment_string), 
>>>>>> and AA
>>>>>> and NA groups have their associated sequence_ids. However, the
>>>>>> differences are obvious that REVIEW_STATUS_ID only at the COMMENTS
>>>>>> table, and COMMENT_NAME_ID only exists at the AACOMMENT table.
>>>>>>
>>>>>> Also, there is a NAFEATURECOMMENT table associated with 
>>>>>> NAFEATUREIMP
>>>>>> table. But there is no such table for AAFEATUREIMP.
>>>>>> If there would be comments on a feature, where should they go?
>>>>>>
>>>>>> The reason I brought this issue is we are considering to use 
>>>>>> comment
>>>>>> tables to store curation evidence and knowledge content, and we 
>>>>>> want to
>>>>>> make our development consistent.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jian Lu
>>>>>> VBI
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>> Read honest & candid reviews on hundreds of IT Products from
>>>>>
>>>>>
>>>>> real users.
>>>>>
>>>>>> Discover which products truly live up to the hype. Start
>>>>>
>>>>>
>>>>> reading now.
>>>>>
>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>> _______________________________________________
>>>>>> Gusdev-gusdev mailing list
>>>>>> Gus...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>
>>>>>
>>>>> -----------------
>>>>> Ed Robinson
>>>>> Center for Tropical and Emerging Global Diseases
>>>>> University of Georgia, Athens, GA 30602
>>>>> ero...@ug.../(706)542.1447/254.8883
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> SF email is sponsored by - The IT Product Guide
>>>>> Read honest & candid reviews on hundreds of IT Products from real 
>>>>> users.
>>>>> Discover which products truly live up to the hype. Start reading 
>>>>> now.
>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>> _______________________________________________
>>>>> Gusdev-gusdev mailing list
>>>>> Gus...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>
>>>>
>>>
>

Re: [GUSDEV] Preliminary 3.5 Schema

[Michael S. <msa...@pc...>]

All,

The latest proposed GUS 3.5 schema is attached.  This draft has numerous 
changes since the previous release, including the addition of a few dozen 
missing views, the changes outlined below, and other cleanup.

This draft has a small error in which the first subclass for a particular 
superclass appears twice.  I'm trying to track down and resolve that, but 
it appears to only affect this simple text reports, not the actual DDL. 
Schemas and tables are in alphabetical order, but capitalization is 
wreaking a little bit of havok on that.  I hope to fix that in a future 
draft as well.

There are some additional PROT changes that this draft does not include.  I 
will send another draft Wednesday with those changes.

Please submit comments/changes/etc. as soon as possible.  The 3.5 schema is 
scheduled to be frozen at the end of this week and all resources will turn 
at that time to preparing the application level code for release.

Thanks,

Mike

DoTS:

* Drop DoTS.PlasmoAPFeature view

* Drop DoTS.MassSpecSummary

* DoTS.GeneFeatureSeqOverlap.SIMILARITY_ID will have a foreign key 
constraint to DoTS.SIMILARITY

* DoTS.NASequenceImp.SOURCE_NA_SEQUENCE_ID will have a foreign key 
constraint to DoTS.NASequenceImp

* DoTS.SecondaryStructure.AA_SEQUENCE_ID will have a foreign key constraint 
to DoTS.AASequenceImp.  DoTS.SecondaryStructure.PRED_ALG_INVOCATION_ID will 
have a foreign key constraint to Core.AlgorithmInvocation.

* DoTS.SecondaryStructureCall.Secondary_Structure_ID will have a foreign 
key constraint to DoTS.SecondaryStructure

* DoTS.AASequenceEnzymeClass.AA_Sequence_ID will have a foreign key 
constraint to DoTS.AASequenceImp, and 
DoTS.AASequenceEnzymeClass.EC_ASSIGNMENT_CONTACT_ID will have a foreign key 
constraint to SRES.CONTACT

* DoTS.ConsistentAlignment.SIMILARITY_ID will have a foreign key constraint 
to DoTS.Similarity

* DoTS.RejectedMotif.External_Database_Id will have a foreign key 
constraint to SRes.ExternalDatabase. 
DoTS.RejectedMotif.External_Database_release_id will have a foreign key 
constraint to SRes.ExternalDatabaseRelease

* DoTS.Similarity.Subject_Table_ID and DoTS.Similarity.Query_Table_id will 
have foreign key constraints to core.tableinfo

* DoTS.PlasmoMap has been renamed to DoTS.MicroSatelliteMap

Prot:

* Prot.OntologyEntry has been removed

* Prot.StudyAssay has been added.

* Prot.StudyDesignAssay has been added

* Prot.StudyBioMaterial has been added

* Prot.AcquisitionChannel has been added

SRes:

* SRes.ExternalDatabaseKeyword has been moved to DoTS

RAD:

* RAD.ScanAlyzeElementResult.top,left,bot,right have had _coordinate 
appended to them

* The RAD.DataTransformationResult has been added as a view on 
RAD.AnalysisResultImp

* RAD.ReporterArray has been renamed to RAD.ArrayDesign.  This impacts the 
following changes:
  - RAD.ArrayAnnotation -> RAD.ArrayDesignAnnotation
  - RAD.ArrayGroup -> RAD.ArrayDesignGroup
  - RAD.ArrayGroupLink -> RAD.ArrayDesignGroupLink
  - and associated column changes

* RAD.CompositeElementGus has been dropped

* RAD.MageDocumentation and RAD.Mage_ML have been dropped.

* RAD.Channel has been removed

Study:

* Study.Ontology* tables have been dropped.  This includes ontology, 
ontologyannotation, ontologyrelationship, ontologyterm, ontologytype.  This 
DOES NOT include study.ontologyentry.

* Study.BioSample, Study.BioSource, and Study.LabeledExtract have been 
added as views on Study.BioMaterial

* Moved Study.BioMaterialMeasurement to Prot and a copy to RAD.

* Study.Parameter* tables have been moved to prot.  This includes 
parameter, parameterinstance, parameterizable, parameterizableinstance, and 
paramterizablelink

--On April 21, 2005 3:20:15 PM -0400 Michael Saffitz 
<msa...@pc...> wrote:

>
> Since releasing the preliminary 3.5 schema, the following changes have
> been proposed.  The list below only covers App, SRes, and Core-- other
> schema changes will come early next week.
>
> The scheduled freeze date for the 3.5 schema is 4/29.  If there are no
> objections to the items below, Core and App will be frozen for 3.5 on
> 4/25 (more SRes changes may be coming early next week).
>
> Consult the road map for full changes.  The list below are just new
> changes since sending this previous email.  They'll be added to the road
> map after feedback from the list is received.
>
> App:
>
> * The App schema has been deprecated.  The remaining few tables that were
> in app will be moved to non-GUS project specific schema (i.e. a Study
> Annotator schema).
>
> Core:
>
> * The workflow tables have been deprecated as they were never actually
> used.  This includes core.workflowstatus, core.workflowedge,
> core.workflowinit, core.workflowedgesql, core.workflow,
> core.workflowblackboard, and core.workflowstatus
>
> * core.generaldocumentation is tentatively deprecated, pending the lack
> of objections from this list.
>
> * core.userdatabase is tenetively deprecated, pending the lack of
> objections from this list.
>
> SRes (tentative, pending more review)
>
> * SRes.SequenceOntology.SO_ID will be a VARCHAR(12), not a NUMBER(10)
>
> * SRes.MGEDOntologyRelationship will be named SRes.OntologyRelationship
>
> * SRes.MGEDOntologyTerm will be named SRes.OntologyTerm
>
> * SRes.BibliographicReference.authors will be nullable, to support the
> alternative BibRefAuthor linking table.
> SRes.BibliographicReference.External_Database_Release_ID will gain the FK
> the ExternalDatabaseRelease table
>
> * SRes.BibRefAnnotation is tentatively deprecated, pending the lack of
> objections from this list.
>
> Thanks,
>
> Mike
>
>
> --On April 7, 2005 1:53:44 PM -0400 Michael Saffitz
> <msa...@pc...> wrote:
>
>>
>> All,
>>
>> Development work on the GUS 3.5 Schema is nearing completion, and we'd
>> like to take this opportunity to solicit community feedback and provide
>> the 3.5 schema for review.
>>
>> With the 3.5 Schema nearly finalized, we're now turning our attention to
>> ensuring compatibility in the object layer and with plugins for 3.5. Once
>> done, GUS 3.5 will be ready for release.  It's my hope that that will be
>> as soon as possible, but I'm hesitant to give a firm date.
>>
>> The attached file contains the 3.5 schema, in a simple text summary
>> format.  When reviewing the file, please keep the following in mind:
>>
>> * I've done a very preliminary analysis of the file--- there may be
>> glaring mistakes/omissions.
>>
>> * All tables and views in GUS 3.5 are versioned, and the version
>> tables/views are not displayed.
>>
>> * All tables and views in GUS 3.5 contain the standard housekeeping
>> columns, which are also not displayed.
>>
>> * Subclass tables (marked by "extends superclass" where superclass is the
>> name of the parent table) only have the columns added by the subclass
>> displayed.  For example, if the superclass has columns a, b, c, and d,
>> then the subclass will display the column e but have all five columns in
>> the database.
>>
>> * This is an object-centric display-- the method of subclassing (i.e. use
>> of imp tables) is not changing.  As a result, Imp tables are not
>> displayed, nor are super/sub classes flagged as views.
>>
>> * The Type of a column with a foreign key is the name of the foreign key
>> table.  For example, a table with a column NA_FEATURE_ID with a foreign
>> key to DoTS.NAFEATURE will have a type of DoTSS.NAFEATURE.  This is the
>> only way foreign keys are displayed in this view.
>>
>> * All tables first column serves as the Primary key.  There is no
>> denotation for the primary key (although it will also appear as an index
>> against the first column).  Some tables are missing primary keys in this
>> document-- it will be fixed soon.
>>
>> * All indexes for a table are displayed.
>>
>> Please let me know if you have any questions/concerns.
>>
>> Thanks,
>>
>> Mike
>
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] Regarding comment tables in the DoTS

[Jian Lu <jl...@vb...>]

What I could do is to use dots.nafeaturerelationship table to define the 
different comments. Sounds right?

Jian

Jian Lu wrote:

> As Ed mentioned, that dots.nafeaturecomment is also used for storing 
> GenBank data comment . If I insert a new comment to 
> dots.nafeaturecomment table with the same fk na_feature_id, how could 
> I tell which one is which by query? (assuming there has been GenBank 
> comment)
>
> Thanks,
> Jian
>
> Bindu Gajria wrote:
>
>> dots.nafeaturecomment table has the field na_feature_id, which is a 
>> foreign key. plasmodium gene features are stored in dots.genefeature, 
>> whose primary key is na_feature_id. so, one can identify the comment 
>> in the nafeaturecomment table to a particular gene.
>>
>> bindu
>>
>> On Apr 26, 2005, at 11:45 AM, Jian Lu wrote:
>>
>>> Thank you all.
>>>
>>> By using dots.nafeaturecomment table, how could you tell the 
>>> comments from GenBank file or curators or other results?
>>>
>>> Jian
>>>
>>> Bindu Gajria wrote:
>>>
>>>> hi Jian -
>>>> appending to Ed's reply:
>>>> to help in curation, we have set up a mechanism in PlasmoDB to 
>>>> allow for the user community to submit (and view) comments on 
>>>> genes. and for this, PlasmoDB uses dots.nafeaturecomment table. 
>>>> will be glad to provide specifics on how this table, or the others 
>>>> are used.
>>>>
>>>> Bindu
>>>>
>>>>
>>>> On Apr 26, 2005, at 10:09 AM, Ed Robinson wrote:
>>>>
>>>>> Curation is something we are still/constantly incorporating
>>>>> into GUS.  If you can give us more information about your
>>>>> specific curatorial needs, a number of people here can point
>>>>> you to the best places to locate that information.
>>>>>
>>>>> Generally, the comment fields you are talking about are not
>>>>> used for curatorial purposes, but are used for capturing
>>>>> annotations loaded from input files such as GenBank.  For
>>>>> instance,  a comment in the header of a GenBank file would
>>>>> likely go in the comment section, a commnet or note in a gene
>>>>> feature would go in an NAComment and a comment or note in a
>>>>> CDS feature would go in an AAComment.  Of course, the tables
>>>>> you mention AAFeatureImp and NAFeatureImp are not themselves
>>>>> tables you would use directly.  Rather, you would use specific
>>>>> feature views of these tables, such as GeneFeature, Transcript
>>>>> and TranslatedAAFeature.
>>>>>
>>>>> Of course, none of this should stop you from using these
>>>>> tables in the ways that seem best for your data.  If you want
>>>>> to add free-form notes to features, these tables are are
>>>>> likely one of the better places.
>>>>>
>>>>> In general, curatorial information is found in the SRes
>>>>> tables, so you should look at those closely also.
>>>>>
>>>>> Also, you should dig around in the documentation section of
>>>>> gusdb.org.  There are some papers that discuss the schema
>>>>> buried somewhere in there.
>>>>>
>>>>> -ed
>>>>>
>>>>>
>>>>>
>>>>> ---- Original message ----
>>>>>
>>>>>> Date: Mon, 25 Apr 2005 12:11:28 -0400
>>>>>> From: Jian Lu <jl...@vb...>
>>>>>> Subject: [GUSDEV] Regarding comment tables in the DoTS
>>>>>> To: gus...@li...
>>>>>>
>>>>>> Hi GUS folks,
>>>>>>
>>>>>> I am new in GUS schema. This might not be a new question, but I just
>>>>>> want to understand more about GUS. It would be great  if someone 
>>>>>> already
>>>>>> has had answers.
>>>>>>
>>>>>> I realize that there are different comment tables at DoTS:
>>>>>>
>>>>>> COMMENTS (COMMENTS_ID, COMMENT_STRING, REVIEW_STATUS_ID, ...)
>>>>>>
>>>>>> AACOMMENT (AA_COMMENT_ID, AA_SEQUENCE_ID, COMMENT_NAME_ID,
>>>>>> COMMENT_STRING, ...)
>>>>>>
>>>>>> NACOMMENT (NA_COMMENT_ID, NA_SEQUENCE_ID, COMMENT_STRING, ...)
>>>>>>
>>>>>> They have all common attributes (comment_id and comment_string), 
>>>>>> and AA
>>>>>> and NA groups have their associated sequence_ids. However, the
>>>>>> differences are obvious that REVIEW_STATUS_ID only at the COMMENTS
>>>>>> table, and COMMENT_NAME_ID only exists at the AACOMMENT table.
>>>>>>
>>>>>> Also, there is a NAFEATURECOMMENT table associated with NAFEATUREIMP
>>>>>> table. But there is no such table for AAFEATUREIMP.
>>>>>> If there would be comments on a feature, where should they go?
>>>>>>
>>>>>> The reason I brought this issue is we are considering to use comment
>>>>>> tables to store curation evidence and knowledge content, and we 
>>>>>> want to
>>>>>> make our development consistent.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jian Lu
>>>>>> VBI
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> SF email is sponsored by - The IT Product Guide
>>>>>> Read honest & candid reviews on hundreds of IT Products from
>>>>>
>>>>>
>>>>>
>>>>> real users.
>>>>>
>>>>>> Discover which products truly live up to the hype. Start
>>>>>
>>>>>
>>>>>
>>>>> reading now.
>>>>>
>>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>> _______________________________________________
>>>>>> Gusdev-gusdev mailing list
>>>>>> Gus...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>>
>>>>>
>>>>>
>>>>> -----------------
>>>>> Ed Robinson
>>>>> Center for Tropical and Emerging Global Diseases
>>>>> University of Georgia, Athens, GA 30602
>>>>> ero...@ug.../(706)542.1447/254.8883
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> SF email is sponsored by - The IT Product Guide
>>>>> Read honest & candid reviews on hundreds of IT Products from real 
>>>>> users.
>>>>> Discover which products truly live up to the hype. Start reading now.
>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>> _______________________________________________
>>>>> Gusdev-gusdev mailing list
>>>>> Gus...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>
>>>>
>>>>
>>>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] Regarding comment tables in the DoTS

[Jian Lu <jl...@vb...>]

As Ed mentioned, that dots.nafeaturecomment is also used for storing 
GenBank data comment . If I insert a new comment to 
dots.nafeaturecomment table with the same fk na_feature_id, how could I 
tell which one is which by query? (assuming there has been GenBank comment)

Thanks,
Jian

Bindu Gajria wrote:

> dots.nafeaturecomment table has the field na_feature_id, which is a 
> foreign key. plasmodium gene features are stored in dots.genefeature, 
> whose primary key is na_feature_id. so, one can identify the comment 
> in the nafeaturecomment table to a particular gene.
>
> bindu
>
> On Apr 26, 2005, at 11:45 AM, Jian Lu wrote:
>
>> Thank you all.
>>
>> By using dots.nafeaturecomment table, how could you tell the comments 
>> from GenBank file or curators or other results?
>>
>> Jian
>>
>> Bindu Gajria wrote:
>>
>>> hi Jian -
>>> appending to Ed's reply:
>>> to help in curation, we have set up a mechanism in PlasmoDB to allow 
>>> for the user community to submit (and view) comments on genes. and 
>>> for this, PlasmoDB uses dots.nafeaturecomment table. will be glad to 
>>> provide specifics on how this table, or the others are used.
>>>
>>> Bindu
>>>
>>>
>>> On Apr 26, 2005, at 10:09 AM, Ed Robinson wrote:
>>>
>>>> Curation is something we are still/constantly incorporating
>>>> into GUS.  If you can give us more information about your
>>>> specific curatorial needs, a number of people here can point
>>>> you to the best places to locate that information.
>>>>
>>>> Generally, the comment fields you are talking about are not
>>>> used for curatorial purposes, but are used for capturing
>>>> annotations loaded from input files such as GenBank.  For
>>>> instance,  a comment in the header of a GenBank file would
>>>> likely go in the comment section, a commnet or note in a gene
>>>> feature would go in an NAComment and a comment or note in a
>>>> CDS feature would go in an AAComment.  Of course, the tables
>>>> you mention AAFeatureImp and NAFeatureImp are not themselves
>>>> tables you would use directly.  Rather, you would use specific
>>>> feature views of these tables, such as GeneFeature, Transcript
>>>> and TranslatedAAFeature.
>>>>
>>>> Of course, none of this should stop you from using these
>>>> tables in the ways that seem best for your data.  If you want
>>>> to add free-form notes to features, these tables are are
>>>> likely one of the better places.
>>>>
>>>> In general, curatorial information is found in the SRes
>>>> tables, so you should look at those closely also.
>>>>
>>>> Also, you should dig around in the documentation section of
>>>> gusdb.org.  There are some papers that discuss the schema
>>>> buried somewhere in there.
>>>>
>>>> -ed
>>>>
>>>>
>>>>
>>>> ---- Original message ----
>>>>
>>>>> Date: Mon, 25 Apr 2005 12:11:28 -0400
>>>>> From: Jian Lu <jl...@vb...>
>>>>> Subject: [GUSDEV] Regarding comment tables in the DoTS
>>>>> To: gus...@li...
>>>>>
>>>>> Hi GUS folks,
>>>>>
>>>>> I am new in GUS schema. This might not be a new question, but I just
>>>>> want to understand more about GUS. It would be great  if someone 
>>>>> already
>>>>> has had answers.
>>>>>
>>>>> I realize that there are different comment tables at DoTS:
>>>>>
>>>>> COMMENTS (COMMENTS_ID, COMMENT_STRING, REVIEW_STATUS_ID, ...)
>>>>>
>>>>> AACOMMENT (AA_COMMENT_ID, AA_SEQUENCE_ID, COMMENT_NAME_ID,
>>>>> COMMENT_STRING, ...)
>>>>>
>>>>> NACOMMENT (NA_COMMENT_ID, NA_SEQUENCE_ID, COMMENT_STRING, ...)
>>>>>
>>>>> They have all common attributes (comment_id and comment_string), 
>>>>> and AA
>>>>> and NA groups have their associated sequence_ids. However, the
>>>>> differences are obvious that REVIEW_STATUS_ID only at the COMMENTS
>>>>> table, and COMMENT_NAME_ID only exists at the AACOMMENT table.
>>>>>
>>>>> Also, there is a NAFEATURECOMMENT table associated with NAFEATUREIMP
>>>>> table. But there is no such table for AAFEATUREIMP.
>>>>> If there would be comments on a feature, where should they go?
>>>>>
>>>>> The reason I brought this issue is we are considering to use comment
>>>>> tables to store curation evidence and knowledge content, and we 
>>>>> want to
>>>>> make our development consistent.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jian Lu
>>>>> VBI
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> SF email is sponsored by - The IT Product Guide
>>>>> Read honest & candid reviews on hundreds of IT Products from
>>>>
>>>>
>>>> real users.
>>>>
>>>>> Discover which products truly live up to the hype. Start
>>>>
>>>>
>>>> reading now.
>>>>
>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>> _______________________________________________
>>>>> Gusdev-gusdev mailing list
>>>>> Gus...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>>
>>>>
>>>> -----------------
>>>> Ed Robinson
>>>> Center for Tropical and Emerging Global Diseases
>>>> University of Georgia, Athens, GA 30602
>>>> ero...@ug.../(706)542.1447/254.8883
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real 
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Gusdev-gusdev mailing list
>>>> Gus...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>
>>>
>>

Re: [GUSDEV] Regarding comment tables in the DoTS

[Bindu G. <bi...@pc...>]

dots.nafeaturecomment table has the field na_feature_id, which is a 
foreign key. plasmodium gene features are stored in dots.genefeature, 
whose primary key is na_feature_id. so, one can identify the comment in 
the nafeaturecomment table to a particular gene.

bindu

On Apr 26, 2005, at 11:45 AM, Jian Lu wrote:

> Thank you all.
>
> By using dots.nafeaturecomment table, how could you tell the comments 
> from GenBank file or curators or other results?
>
> Jian
>
> Bindu Gajria wrote:
>
>> hi Jian -
>> appending to Ed's reply:
>> to help in curation, we have set up a mechanism in PlasmoDB to allow 
>> for the user community to submit (and view) comments on genes. and 
>> for this, PlasmoDB uses dots.nafeaturecomment table. will be glad to 
>> provide specifics on how this table, or the others are used.
>>
>> Bindu
>>
>>
>> On Apr 26, 2005, at 10:09 AM, Ed Robinson wrote:
>>
>>> Curation is something we are still/constantly incorporating
>>> into GUS.  If you can give us more information about your
>>> specific curatorial needs, a number of people here can point
>>> you to the best places to locate that information.
>>>
>>> Generally, the comment fields you are talking about are not
>>> used for curatorial purposes, but are used for capturing
>>> annotations loaded from input files such as GenBank.  For
>>> instance,  a comment in the header of a GenBank file would
>>> likely go in the comment section, a commnet or note in a gene
>>> feature would go in an NAComment and a comment or note in a
>>> CDS feature would go in an AAComment.  Of course, the tables
>>> you mention AAFeatureImp and NAFeatureImp are not themselves
>>> tables you would use directly.  Rather, you would use specific
>>> feature views of these tables, such as GeneFeature, Transcript
>>> and TranslatedAAFeature.
>>>
>>> Of course, none of this should stop you from using these
>>> tables in the ways that seem best for your data.  If you want
>>> to add free-form notes to features, these tables are are
>>> likely one of the better places.
>>>
>>> In general, curatorial information is found in the SRes
>>> tables, so you should look at those closely also.
>>>
>>> Also, you should dig around in the documentation section of
>>> gusdb.org.  There are some papers that discuss the schema
>>> buried somewhere in there.
>>>
>>> -ed
>>>
>>>
>>>
>>> ---- Original message ----
>>>
>>>> Date: Mon, 25 Apr 2005 12:11:28 -0400
>>>> From: Jian Lu <jl...@vb...>
>>>> Subject: [GUSDEV] Regarding comment tables in the DoTS
>>>> To: gus...@li...
>>>>
>>>> Hi GUS folks,
>>>>
>>>> I am new in GUS schema. This might not be a new question, but I just
>>>> want to understand more about GUS. It would be great  if someone 
>>>> already
>>>> has had answers.
>>>>
>>>> I realize that there are different comment tables at DoTS:
>>>>
>>>> COMMENTS (COMMENTS_ID, COMMENT_STRING, REVIEW_STATUS_ID, ...)
>>>>
>>>> AACOMMENT (AA_COMMENT_ID, AA_SEQUENCE_ID, COMMENT_NAME_ID,
>>>> COMMENT_STRING, ...)
>>>>
>>>> NACOMMENT (NA_COMMENT_ID, NA_SEQUENCE_ID, COMMENT_STRING, ...)
>>>>
>>>> They have all common attributes (comment_id and comment_string), 
>>>> and AA
>>>> and NA groups have their associated sequence_ids. However, the
>>>> differences are obvious that REVIEW_STATUS_ID only at the COMMENTS
>>>> table, and COMMENT_NAME_ID only exists at the AACOMMENT table.
>>>>
>>>> Also, there is a NAFEATURECOMMENT table associated with NAFEATUREIMP
>>>> table. But there is no such table for AAFEATUREIMP.
>>>> If there would be comments on a feature, where should they go?
>>>>
>>>> The reason I brought this issue is we are considering to use comment
>>>> tables to store curation evidence and knowledge content, and we 
>>>> want to
>>>> make our development consistent.
>>>>
>>>> Thanks,
>>>>
>>>> Jian Lu
>>>> VBI
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from
>>>
>>> real users.
>>>
>>>> Discover which products truly live up to the hype. Start
>>>
>>> reading now.
>>>
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Gusdev-gusdev mailing list
>>>> Gus...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>
>>> -----------------
>>> Ed Robinson
>>> Center for Tropical and Emerging Global Diseases
>>> University of Georgia, Athens, GA 30602
>>> ero...@ug.../(706)542.1447/254.8883
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real 
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>

Re: [GUSDEV] Regarding comment tables in the DoTS

[Jian Lu <jl...@vb...>]

Thank you all.

By using dots.nafeaturecomment table, how could you tell the comments 
from GenBank file or curators or other results?

Jian

Bindu Gajria wrote:

> hi Jian -
> appending to Ed's reply:
> to help in curation, we have set up a mechanism in PlasmoDB to allow 
> for the user community to submit (and view) comments on genes. and for 
> this, PlasmoDB uses dots.nafeaturecomment table. will be glad to 
> provide specifics on how this table, or the others are used.
>
> Bindu
>
>
> On Apr 26, 2005, at 10:09 AM, Ed Robinson wrote:
>
>> Curation is something we are still/constantly incorporating
>> into GUS.  If you can give us more information about your
>> specific curatorial needs, a number of people here can point
>> you to the best places to locate that information.
>>
>> Generally, the comment fields you are talking about are not
>> used for curatorial purposes, but are used for capturing
>> annotations loaded from input files such as GenBank.  For
>> instance,  a comment in the header of a GenBank file would
>> likely go in the comment section, a commnet or note in a gene
>> feature would go in an NAComment and a comment or note in a
>> CDS feature would go in an AAComment.  Of course, the tables
>> you mention AAFeatureImp and NAFeatureImp are not themselves
>> tables you would use directly.  Rather, you would use specific
>> feature views of these tables, such as GeneFeature, Transcript
>> and TranslatedAAFeature.
>>
>> Of course, none of this should stop you from using these
>> tables in the ways that seem best for your data.  If you want
>> to add free-form notes to features, these tables are are
>> likely one of the better places.
>>
>> In general, curatorial information is found in the SRes
>> tables, so you should look at those closely also.
>>
>> Also, you should dig around in the documentation section of
>> gusdb.org.  There are some papers that discuss the schema
>> buried somewhere in there.
>>
>> -ed
>>
>>
>>
>> ---- Original message ----
>>
>>> Date: Mon, 25 Apr 2005 12:11:28 -0400
>>> From: Jian Lu <jl...@vb...>
>>> Subject: [GUSDEV] Regarding comment tables in the DoTS
>>> To: gus...@li...
>>>
>>> Hi GUS folks,
>>>
>>> I am new in GUS schema. This might not be a new question, but I just
>>> want to understand more about GUS. It would be great  if someone 
>>> already
>>> has had answers.
>>>
>>> I realize that there are different comment tables at DoTS:
>>>
>>> COMMENTS (COMMENTS_ID, COMMENT_STRING, REVIEW_STATUS_ID, ...)
>>>
>>> AACOMMENT (AA_COMMENT_ID, AA_SEQUENCE_ID, COMMENT_NAME_ID,
>>> COMMENT_STRING, ...)
>>>
>>> NACOMMENT (NA_COMMENT_ID, NA_SEQUENCE_ID, COMMENT_STRING, ...)
>>>
>>> They have all common attributes (comment_id and comment_string), and AA
>>> and NA groups have their associated sequence_ids. However, the
>>> differences are obvious that REVIEW_STATUS_ID only at the COMMENTS
>>> table, and COMMENT_NAME_ID only exists at the AACOMMENT table.
>>>
>>> Also, there is a NAFEATURECOMMENT table associated with NAFEATUREIMP
>>> table. But there is no such table for AAFEATUREIMP.
>>> If there would be comments on a feature, where should they go?
>>>
>>> The reason I brought this issue is we are considering to use comment
>>> tables to store curation evidence and knowledge content, and we want to
>>> make our development consistent.
>>>
>>> Thanks,
>>>
>>> Jian Lu
>>> VBI
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from
>>
>> real users.
>>
>>> Discover which products truly live up to the hype. Start
>>
>> reading now.
>>
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>> -----------------
>> Ed Robinson
>> Center for Tropical and Emerging Global Diseases
>> University of Georgia, Athens, GA 30602
>> ero...@ug.../(706)542.1447/254.8883
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

Re: [GUSDEV] Regarding comment tables in the DoTS

[Bindu G. <bi...@pc...>]

hi Jian -
appending to Ed's reply:
to help in curation, we have set up a mechanism in PlasmoDB to allow 
for the user community to submit (and view) comments on genes. and for 
this, PlasmoDB uses dots.nafeaturecomment table. will be glad to 
provide specifics on how this table, or the others are used.

Bindu


On Apr 26, 2005, at 10:09 AM, Ed Robinson wrote:

> Curation is something we are still/constantly incorporating
> into GUS.  If you can give us more information about your
> specific curatorial needs, a number of people here can point
> you to the best places to locate that information.
>
> Generally, the comment fields you are talking about are not
> used for curatorial purposes, but are used for capturing
> annotations loaded from input files such as GenBank.  For
> instance,  a comment in the header of a GenBank file would
> likely go in the comment section, a commnet or note in a gene
> feature would go in an NAComment and a comment or note in a
> CDS feature would go in an AAComment.  Of course, the tables
> you mention AAFeatureImp and NAFeatureImp are not themselves
> tables you would use directly.  Rather, you would use specific
> feature views of these tables, such as GeneFeature, Transcript
> and TranslatedAAFeature.
>
> Of course, none of this should stop you from using these
> tables in the ways that seem best for your data.  If you want
> to add free-form notes to features, these tables are are
> likely one of the better places.
>
> In general, curatorial information is found in the SRes
> tables, so you should look at those closely also.
>
> Also, you should dig around in the documentation section of
> gusdb.org.  There are some papers that discuss the schema
> buried somewhere in there.
>
> -ed
>
>
>
> ---- Original message ----
>> Date: Mon, 25 Apr 2005 12:11:28 -0400
>> From: Jian Lu <jl...@vb...>
>> Subject: [GUSDEV] Regarding comment tables in the DoTS
>> To: gus...@li...
>>
>> Hi GUS folks,
>>
>> I am new in GUS schema. This might not be a new question, but I just
>> want to understand more about GUS. It would be great  if someone 
>> already
>> has had answers.
>>
>> I realize that there are different comment tables at DoTS:
>>
>> COMMENTS (COMMENTS_ID, COMMENT_STRING, REVIEW_STATUS_ID, ...)
>>
>> AACOMMENT (AA_COMMENT_ID, AA_SEQUENCE_ID, COMMENT_NAME_ID,
>> COMMENT_STRING, ...)
>>
>> NACOMMENT (NA_COMMENT_ID, NA_SEQUENCE_ID, COMMENT_STRING, ...)
>>
>> They have all common attributes (comment_id and comment_string), and 
>> AA
>> and NA groups have their associated sequence_ids. However, the
>> differences are obvious that REVIEW_STATUS_ID only at the COMMENTS
>> table, and COMMENT_NAME_ID only exists at the AACOMMENT table.
>>
>> Also, there is a NAFEATURECOMMENT table associated with NAFEATUREIMP
>> table. But there is no such table for AAFEATUREIMP.
>> If there would be comments on a feature, where should they go?
>>
>> The reason I brought this issue is we are considering to use comment
>> tables to store curation evidence and knowledge content, and we want 
>> to
>> make our development consistent.
>>
>> Thanks,
>>
>> Jian Lu
>> VBI
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from
> real users.
>> Discover which products truly live up to the hype. Start
> reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> -----------------
> Ed Robinson
> Center for Tropical and Emerging Global Diseases
> University of Georgia, Athens, GA 30602
> ero...@ug.../(706)542.1447/254.8883
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] Regarding comment tables in the DoTS

[Ed R. <ero...@ug...>]

Curation is something we are still/constantly incorporating
into GUS.  If you can give us more information about your
specific curatorial needs, a number of people here can point
you to the best places to locate that information.

Generally, the comment fields you are talking about are not
used for curatorial purposes, but are used for capturing
annotations loaded from input files such as GenBank.  For
instance,  a comment in the header of a GenBank file would
likely go in the comment section, a commnet or note in a gene
feature would go in an NAComment and a comment or note in a
CDS feature would go in an AAComment.  Of course, the tables
you mention AAFeatureImp and NAFeatureImp are not themselves
tables you would use directly.  Rather, you would use specific
feature views of these tables, such as GeneFeature, Transcript
and TranslatedAAFeature.  

Of course, none of this should stop you from using these
tables in the ways that seem best for your data.  If you want
to add free-form notes to features, these tables are are
likely one of the better places.

In general, curatorial information is found in the SRes
tables, so you should look at those closely also.

Also, you should dig around in the documentation section of
gusdb.org.  There are some papers that discuss the schema
buried somewhere in there.

-ed



---- Original message ----
>Date: Mon, 25 Apr 2005 12:11:28 -0400
>From: Jian Lu <jl...@vb...>  
>Subject: [GUSDEV] Regarding comment tables in the DoTS  
>To: gus...@li...
>
>Hi GUS folks,
>
>I am new in GUS schema. This might not be a new question, but
I just 
>want to understand more about GUS. It would be great  if
someone already 
>has had answers.
>
>I realize that there are different comment tables at DoTS:
>
>COMMENTS (COMMENTS_ID, COMMENT_STRING, REVIEW_STATUS_ID, ...)
>
>AACOMMENT (AA_COMMENT_ID, AA_SEQUENCE_ID, COMMENT_NAME_ID, 
>COMMENT_STRING, ...)
>
>NACOMMENT (NA_COMMENT_ID, NA_SEQUENCE_ID, COMMENT_STRING, ...)
>
>They have all common attributes (comment_id and
comment_string), and AA 
>and NA groups have their associated sequence_ids. However, the 
>differences are obvious that REVIEW_STATUS_ID only at the
COMMENTS 
>table, and COMMENT_NAME_ID only exists at the AACOMMENT table.
>
>Also, there is a NAFEATURECOMMENT table associated with
NAFEATUREIMP 
>table. But there is no such table for AAFEATUREIMP.
>If there would be comments on a feature, where should they go?
>
>The reason I brought this issue is we are considering to use
comment 
>tables to store curation evidence and knowledge content, and
we want to 
>make our development consistent.
>
>Thanks,
>
>Jian Lu
>VBI
>
>
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from
real users.
>Discover which products truly live up to the hype. Start
reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
-----------------
Ed Robinson
Center for Tropical and Emerging Global Diseases
University of Georgia, Athens, GA 30602
ero...@ug.../(706)542.1447/254.8883

[GUSDEV] Regarding comment tables in the DoTS

[Jian Lu <jl...@vb...>]

Hi GUS folks,

I am new in GUS schema. This might not be a new question, but I just 
want to understand more about GUS. It would be great  if someone already 
has had answers.

I realize that there are different comment tables at DoTS:

COMMENTS (COMMENTS_ID, COMMENT_STRING, REVIEW_STATUS_ID, ...)

AACOMMENT (AA_COMMENT_ID, AA_SEQUENCE_ID, COMMENT_NAME_ID, 
COMMENT_STRING, ...)

NACOMMENT (NA_COMMENT_ID, NA_SEQUENCE_ID, COMMENT_STRING, ...)

They have all common attributes (comment_id and comment_string), and AA 
and NA groups have their associated sequence_ids. However, the 
differences are obvious that REVIEW_STATUS_ID only at the COMMENTS 
table, and COMMENT_NAME_ID only exists at the AACOMMENT table.

Also, there is a NAFEATURECOMMENT table associated with NAFEATUREIMP 
table. But there is no such table for AAFEATUREIMP.
If there would be comments on a feature, where should they go?

The reason I brought this issue is we are considering to use comment 
tables to store curation evidence and knowledge content, and we want to 
make our development consistent.

Thanks,

Jian Lu
VBI

[GUSDEV] GUS @ Bioinformatics Hackathon?

[Michael S. <msa...@pc...>]

There's been some talk on various Bioinformatic mailing lists of a 
"hackathon" coinciding with Apple's WWDC this June (see below).

Are any GUS users out there thinking about attending either the hackathon 
or the WWDC, and if so, is there any interest in forming a GUS contingent?

Possible topics and areas of development could include plugin work, support 
for integrating other databases (i.e. tools to load data from chado 
databases), object layer development/improvements, ???? ideas ?

--Mike

>> From: Suzanna Lewis <su...@fr...>
>> Date: April 20, 2005 6:42:29 PM EDT
>> To: da...@bi..., bak...@bi...,
>> bio...@bi..., "go-...@ge..."
>> <go-...@ge...>, go-...@fr...,
>> mge...@li...,
>> gmo...@li..., bio...@op...,
>> bio...@bi..., em...@em...
>> Cc: George Hartzell <har...@ke...>, Cyrus Harmon
>> <cy...@cy...>, Steve Chervitz
>> <Ste...@af...>
>> Subject: Hackathon 2005
>>
>> (sorry for multiple postings, but please do forward to
>> anyone else who you think might be interested)
>>
>> ----------------------------------------------------------------------
>> ---
>> ----------
>>
>> Dear everyone,
>>
>> It has been a long time and we Bioinformatics devotees are overdue for
>> another total-immersion coding-fest (the last hackathon was held in
>> Singapore February 2003, more than two years ago).  Apple has offered
>> to host us this year, and as an added bonus include free admission to
>> the World-Wide Developers Conference in San Francisco the prior week.
>> They are also looking for some people to present interesting new
>> developments at the WWDC, so if you have something noteworthy please
>> let us know. Apple is not attaching any strings, so our work need not
>> address Apple-specific software or hardware areas. Apple will provide
>> space and hardware (and access to their engineers if we'd like).
>>
>> Week 1 (June 6-10) would be spent at the WWDC. Week 2 (June 12-16)
>> would be in Cupertino, at Apple's headquarters.  We're free to focus
>> on what interests us, our tentative plans include:
>>
>>   1. Bio-ontologies software
>>   2. High-performance computing (e.g. large scale computations,
>> optimization)
>>   3. Image analysis
>>   4. Documentation
>>   5. Anything else that may interest you
>>
>> Our plan is to organize this much as the Aspen Center for Physics
>> computational biology workshops were organized (for those old enough
>> to
>> remember): A couple of presentations to start the day; collaboration
>> and coding afterwards; time for a bit of fun (does anyone else
>> cycle?), and discussions in the late afternoons and evenings.
>>
>> Would everyone who is interested in attending please send us a short
>> description of what you would like to do, and perhaps other people who
>> you would like to work with. There is somewhat limited space, so we
>> will try to prioritize groups that have a clear focus and a need to
>> interact. We now this is very short notice, but we hope that there
>> will be enough interest to make it possible.
>>
>> We are looking into additional funding support, to pay for travel
>> expenses, but this is still to be decided.
>>
>> Looking forward to hearing from everyone.
>> George, Cyrus, Steve, and Suzanna (the Bay Area locals)
>>
>>
>> --
>> This message is from the GOFriends moderated mailing list.  A list of
>> public
>> announcements and discussion of the Gene Ontology (GO) project.
>> Problems with the list?           E-mail:
>> own...@ge...
>> Subscribing   send   "subscribe"   to
>> gof...@ge...
>> Unsubscribing send   "unsubscribe"  to
>> gof...@ge...
>> Web:          http://www.geneontology.org/
>

Re: [GUSDEV] Preliminary 3.5 Schema

[Michael S. <msa...@pc...>]

Since releasing the preliminary 3.5 schema, the following changes have been 
proposed.  The list below only covers App, SRes, and Core-- other schema 
changes will come early next week.

The scheduled freeze date for the 3.5 schema is 4/29.  If there are no 
objections to the items below, Core and App will be frozen for 3.5 on 4/25 
(more SRes changes may be coming early next week).

Consult the road map for full changes.  The list below are just new changes 
since sending this previous email.  They'll be added to the road map after 
feedback from the list is received.

App:

* The App schema has been deprecated.  The remaining few tables that were 
in app will be moved to non-GUS project specific schema (i.e. a Study 
Annotator schema).

Core:

* The workflow tables have been deprecated as they were never actually 
used.  This includes core.workflowstatus, core.workflowedge, 
core.workflowinit, core.workflowedgesql, core.workflow, 
core.workflowblackboard, and core.workflowstatus

* core.generaldocumentation is tentatively deprecated, pending the lack of 
objections from this list.

* core.userdatabase is tenetively deprecated, pending the lack of 
objections from this list.

SRes (tentative, pending more review)

* SRes.SequenceOntology.SO_ID will be a VARCHAR(12), not a NUMBER(10)

* SRes.MGEDOntologyRelationship will be named SRes.OntologyRelationship

* SRes.MGEDOntologyTerm will be named SRes.OntologyTerm

* SRes.BibliographicReference.authors will be nullable, to support the 
alternative BibRefAuthor linking table. 
SRes.BibliographicReference.External_Database_Release_ID will gain the FK 
the ExternalDatabaseRelease table

* SRes.BibRefAnnotation is tentatively deprecated, pending the lack of 
objections from this list.

Thanks,

Mike


--On April 7, 2005 1:53:44 PM -0400 Michael Saffitz 
<msa...@pc...> wrote:

>
> All,
>
> Development work on the GUS 3.5 Schema is nearing completion, and we'd
> like to take this opportunity to solicit community feedback and provide
> the 3.5 schema for review.
>
> With the 3.5 Schema nearly finalized, we're now turning our attention to
> ensuring compatibility in the object layer and with plugins for 3.5. Once
> done, GUS 3.5 will be ready for release.  It's my hope that that will be
> as soon as possible, but I'm hesitant to give a firm date.
>
> The attached file contains the 3.5 schema, in a simple text summary
> format.  When reviewing the file, please keep the following in mind:
>
> * I've done a very preliminary analysis of the file--- there may be
> glaring mistakes/omissions.
>
> * All tables and views in GUS 3.5 are versioned, and the version
> tables/views are not displayed.
>
> * All tables and views in GUS 3.5 contain the standard housekeeping
> columns, which are also not displayed.
>
> * Subclass tables (marked by "extends superclass" where superclass is the
> name of the parent table) only have the columns added by the subclass
> displayed.  For example, if the superclass has columns a, b, c, and d,
> then the subclass will display the column e but have all five columns in
> the database.
>
> * This is an object-centric display-- the method of subclassing (i.e. use
> of imp tables) is not changing.  As a result, Imp tables are not
> displayed, nor are super/sub classes flagged as views.
>
> * The Type of a column with a foreign key is the name of the foreign key
> table.  For example, a table with a column NA_FEATURE_ID with a foreign
> key to DoTS.NAFEATURE will have a type of DoTSS.NAFEATURE.  This is the
> only way foreign keys are displayed in this view.
>
> * All tables first column serves as the Primary key.  There is no
> denotation for the primary key (although it will also appear as an index
> against the first column).  Some tables are missing primary keys in this
> document-- it will be fixed soon.
>
> * All indexes for a table are displayed.
>
> Please let me know if you have any questions/concerns.
>
> Thanks,
>
> Mike

Re: [GUSDEV] problems loading data

[Amruta J. <am...@st...>]

> have a version that works for our data.  Can you tell me a bit
> more about your TIGR files.  Is it one big file or many small
> files for individual contigs?  Did it actually load any data?

It's not a TIGR file, it's an NCBI Entrez XML format file.
It is one single file.
No rows have been inserted in the expected tables.
LoadGeneFeatuteFromXML has a method parseFile having comment as parses TIGR
xml. That's why I was concerned whether LGFFXml could parse my NCBI Entrez
XML file.

Amruta



>
> ---- Original message ----
>>Date: Tue, 19 Apr 2005 17:09:50 -0700
>>From: "Amruta Joshi" <am...@st...>
>>Subject: [GUSDEV] problems loading data
>>To: <gus...@li...>
>>
>>   Hi,
>>
>>   I've successfully installed GUS and am trying to
>>   load data into it.
>>   I have downloaded Bordetella bronchiseptica ds-DNA
>>   sequence in XML format from:
>>
> (http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=Nucleotide&cmd=search&term=nc_002927)
>>
>>   I tried using LoadGeneFeatureFromXML
>>   (v1.878) plugin, but it prints the length of
>>   submitted sequence as 0.
>>   My guess is that the plugin is not able to parse my
>>   xml file.
>>   Is TIGR XML format different from the Genbank XML
>>   file format?
>>   Is there some other plugin that parses xml to load
>>   data?
>>
>>   I tried using GBParser on data downloaded from the
>>   same site in GenBank (.gb) format. That too failed
>>   with the error:
>>    ------------------ entry number 1 -----------------
>>   You have exceeded the maximum number of allowable
>>   objects in memory:
>>    ------------------ entry number 2 -----------------
>>   Can't call method "getAccession" on an undefined
>>   value
>>
>>   The complete command and errors are pasted below for
>>   reference.
>>
>>
>>   thanks,
>>   Amruta
>>

[GUSDEV] TIGR XML DTD

[Brian H. <bh...@ti...>]

Greetings.

I understand there was some confusion regarding the TIGR XML DTD.  There is only one XML 
format supported by TIGR and the DTD is located at:

ftp://ftp.tigr.org/pub/data/DTDs/tigrxml.dtd

All changes to the DTD are well documented, and all older XML files originally designed to 
this spec should be backwards compatible with the latest DTD.

There may be some confusion because certain groups were supplying .coords files for 
annotation in a long deprecated XML format which was originally designed for internal use 
only and never should have made it to the public arena.  I'll see to it that these are 
purged from our ftp site, and replaced with more suitably formatted files, as needed.


As an aside, the TIGR XML format is slowly being phased out, to be eventually replaced 
with GFF3.  I expect this will occur later this year, or early next year.

Please let me know if you have any questions.

Best regards,

-Brian

-- 
Brian J. Haas
Bioinformatics Engineer
The Institute for Genomic Research
(301) 795-7988
email: bh...@ti...
http://www.tigr.org/~bhaas

   ("`-''-/").___..--''"`-._
    '0_ 0' )   `-.  (     ).`-.__.`)
    (_Y_.)'  ._   )  `._ `. ``-..-'
  _..`--'_..-_/  /--'_.' ,'
(il).-''  (li).'  ((!.-'

Re: [GUSDEV] problems loading data

[Ed R. <ero...@ug...>]

WWVzLCBUSUdSIGlzIHNpZ25pZmljYW50bHkgZGlmZmVyZW50IGZyb20gR0VOQkFOSy4gIEFs
c28sIFRpZ3INCnJvdXRpbmVseSB1cGRhdGVzIHRoZWlyIHhtbCBmb3JtYXQgd2l0aG91dCB1
cGRhdGluZyB0aGVpciBEVEQuDQogSWYgTG9hZEdlbmVGZWF0dXJlRnJvbVhNTCBsb2FkZWQg
YW55dGhpbmcsIHlvdSBhcmUgbHVja3kuICANCldlIGhhdmUgYSBtb2RpZmllZCBMR0ZGWE1M
IGZvciBvdXIgVGNydXppIGRhdGEuICBPdXIgZGF0YSBoYXMNCmluZGl2aWR1YWwgZmlsZXMg
Zm9yIGVhY2ggY29udGlnLCB3aGljaCBpcyBkaWZmZXJlbnQgZnJvbSBtYW55DQpvdGhlciBk
YXRhIHNldHMsIHNvIHRoYXQgaXMgcGFydCBvZiB0aGUgcHJvYmxlbS4gIEV2ZW4gdGhlDQpC
aW9QZXJsIGFkYXB0ZXJzIGJsb3cgb3V0IG9uIHNvbWUgVElHUiBYTUwgZmlsZXMuICANCg0K
VGhlIEdCUGFyc2VyIGlzIG5vdCBtdWNoIGJldHRlci4gIFdvcnNlLCBpdCBwdXRzIGRhdGEg
aW4gdGhlDQp3cm9uZyBwbGFjZXMuICBXb3JzZSBzdGlsbCwgbmVpdGhlciB0aGUgVElHUiBY
TUwgUGx1Z2luIG5vcg0KdGhlIEdCUGFyc2VyIGhhdmUgYSBjb25zaXN0ZW50IHZpZXcgb2Yg
d2hhdCB0aGUgR1VTIFNjaGVtYSBpcywNCnNvLCBpZiB5b3UgZ2V0IGJvdGggcGx1Z2lucyBy
dW5uaW5nLCBhbmQgeW91IGxvYWQgZGlmZmVyZW50DQp2ZXJzaW9ucyBvZiB0aGUgc2FtZSBk
YXRhIHNldCBpbnRvIEdVUyB1c2luZyBUaWdyIGZvciBvbmUNCnZlcnNpb24gYW5kIEdCIGZv
ciB0aGUgb3RoZXIsIHlvdXIgZGF0YSB3aWxsIGJlIGluIGRpZmZlcmVudA0KcGxhY2VzLiAg
VGhpcyBpcyBqdXN0IGEgd2FybmluZyB0byBiZSBjb25zaXN0ZW50IG9uY2UgeW91DQpjaG9v
c2UgYSBwbHVnaW4gdG8gbG9hZCB5b3VyIGRhdGEuICBUaGUgcGx1Z2lucyB3ZXJlIHdyaXR0
ZW4NCmJ5IGRpZmZlcmVudCBncm91cHMgZm9yIGRpZmZlcmVudCBwcm9qZWN0cywgc28gdGhl
eSBhcmUgbm90DQpjb25zaXN0ZW50LiAgV2Ugd2lsbCByZWxlYXNlIGEgbmV3IHBsdWdpbiB0
aGF0IHdpbGwgaGFuZGxlIGFsbA0Kb2YgdGhlIGZvcm1hdHMgc29vbi4gIEluIHRoZSBtZWFu
dGltZSwgeW91IGhhdmUgdG8gcGljayBhbmQNCmNob29zZS4NCg0KUGVyc29uYWxseSwgSSBw
cmVmZXIgdGhlIExvYWRYTUwgcGx1Z2luIG92ZXIgdGhlIEdCUGFyc2VyLg0KQWxzbywgaXQg
c291bmRzIGxpa2UgaXQgaXMgY2xvc2UgdG8gbG9hZGluZyB5b3VyIGRhdGEuICBXZQ0KaGF2
ZSBhIHZlcnNpb24gdGhhdCB3b3JrcyBmb3Igb3VyIGRhdGEuICBDYW4geW91IHRlbGwgbWUg
YSBiaXQNCm1vcmUgYWJvdXQgeW91ciBUSUdSIGZpbGVzLiAgSXMgaXQgb25lIGJpZyBmaWxl
IG9yIG1hbnkgc21hbGwNCmZpbGVzIGZvciBpbmRpdmlkdWFsIGNvbnRpZ3M/ICBEaWQgaXQg
YWN0dWFsbHkgbG9hZCBhbnkgZGF0YT8NCg0KLUVkDQoNCg0KLS0tLSBPcmlnaW5hbCBtZXNz
YWdlIC0tLS0NCj5EYXRlOiBUdWUsIDE5IEFwciAyMDA1IDE3OjA5OjUwIC0wNzAwDQo+RnJv
bTogIkFtcnV0YSBKb3NoaSIgPGFtcnV0YWpAc3RhbmZvcmQuZWR1PiAgDQo+U3ViamVjdDog
W0dVU0RFVl0gcHJvYmxlbXMgbG9hZGluZyBkYXRhICANCj5UbzogPGd1c2Rldi1ndXNkZXZA
bGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KPg0KPiAgIEhpLA0KPiAgICANCj4gICBJJ3ZlIHN1
Y2Nlc3NmdWxseSBpbnN0YWxsZWQgR1VTIGFuZCBhbSB0cnlpbmcgdG8NCj4gICBsb2FkIGRh
dGEgaW50byBpdC4NCj4gICBJIGhhdmUgZG93bmxvYWRlZCBCb3JkZXRlbGxhIGJyb25jaGlz
ZXB0aWNhIGRzLUROQQ0KPiAgIHNlcXVlbmNlIGluIFhNTCBmb3JtYXQgZnJvbToNCj4gIA0K
KGh0dHA6Ly93d3cubmNiaS5ubG0ubmloLmdvdi9lbnRyZXovcXVlcnkuZmNnaT9kYj1OdWNs
ZW90aWRlJmNtZD1zZWFyY2gmdGVybT1uY18wMDI5MjcpDQo+ICAgIA0KPiAgIEkgdHJpZWQg
dXNpbmcgTG9hZEdlbmVGZWF0dXJlRnJvbVhNTA0KPiAgICh2MS44NzgpIHBsdWdpbiwgYnV0
IGl0IHByaW50cyB0aGUgbGVuZ3RoIG9mDQo+ICAgc3VibWl0dGVkIHNlcXVlbmNlIGFzIDAu
DQo+ICAgTXkgZ3Vlc3MgaXMgdGhhdCB0aGUgcGx1Z2luIGlzIG5vdCBhYmxlIHRvIHBhcnNl
IG15DQo+ICAgeG1sIGZpbGUuDQo+ICAgSXMgVElHUiBYTUwgZm9ybWF0IGRpZmZlcmVudCBm
cm9tIHRoZSBHZW5iYW5rIFhNTA0KPiAgIGZpbGUgZm9ybWF0Pw0KPiAgIElzIHRoZXJlIHNv
bWUgb3RoZXIgcGx1Z2luIHRoYXQgcGFyc2VzIHhtbCB0byBsb2FkDQo+ICAgZGF0YT8NCj4g
ICAgDQo+ICAgSSB0cmllZCB1c2luZyBHQlBhcnNlciBvbiBkYXRhIGRvd25sb2FkZWQgZnJv
bSB0aGUNCj4gICBzYW1lIHNpdGUgaW4gR2VuQmFuayAoLmdiKSBmb3JtYXQuIFRoYXQgdG9v
IGZhaWxlZA0KPiAgIHdpdGggdGhlIGVycm9yOg0KPiAgICAtLS0tLS0tLS0tLS0tLS0tLS0g
ZW50cnkgbnVtYmVyIDEgLS0tLS0tLS0tLS0tLS0tLS0NCj4gICBZb3UgaGF2ZSBleGNlZWRl
ZCB0aGUgbWF4aW11bSBudW1iZXIgb2YgYWxsb3dhYmxlDQo+ICAgb2JqZWN0cyBpbiBtZW1v
cnk6DQo+ICAgIC0tLS0tLS0tLS0tLS0tLS0tLSBlbnRyeSBudW1iZXIgMiAtLS0tLS0tLS0t
LS0tLS0tLQ0KPiAgIENhbid0IGNhbGwgbWV0aG9kICJnZXRBY2Nlc3Npb24iIG9uIGFuIHVu
ZGVmaW5lZA0KPiAgIHZhbHVlDQo+ICAgIA0KPiAgIFRoZSBjb21wbGV0ZSBjb21tYW5kIGFu
ZCBlcnJvcnMgYXJlIHBhc3RlZCBiZWxvdyBmb3INCj4gICByZWZlcmVuY2UuDQo+ICAgIA0K
PiAgICANCj4gICB0aGFua3MsDQo+ICAgQW1ydXRhDQo+ICAgIA0KPiAgICANCj4gICAgDQo+
ICAgIA0KPiAgICANCj4gICAgDQo+ICAgIA0KPiAgICANCj4gICAgDQo+ICAgTG9hZEdlbmVG
ZWF0dXJlRnJvbVhNTDogKFByb2JsZW0tU3VibWl0dGluZyBzZXF1ZW5jZQ0KPiAgIG9mIGxl
bmd0aCAwKQ0KPiAgIFthbXJ1dGFqQGFzaWFnbyBndXNdJCBnYQ0KPiAgIEdVUzo6Q29tbW9u
OjpQbHVnaW46OkxvYWRHZW5lRmVhdHVyZXNGcm9tWE1MDQo+ICAgLS1YbWxGaWxlPSJ+L2dl
bmJhbmtfZmlsZXMvbmNfMDAyOTI3LnhtbCIgXA0KPiAgID4gLS1UYXhvbj0iQm9yZGV0ZWxs
YSBicm9uY2hpc2VwdGljYSBSQjUwIg0KPiAgIC0tUHJvamVjdD0iQm9yZGV0ZWxsYSBicm9u
Y2hpc2VwdGljYSBSQjUwIg0KPiAgIC0tU2VxVHlwZUlEPTMgXA0KPiAgID4NCj4gICAtLUFs
Z29yaXRobT1HVVM6OkNvbW1vbjo6UGx1Z2luOjpMb2FkR2VuZUZlYXR1cmVzRnJvbVhNTA0K
PiAgIC0tZXh0RGJSZWxJZD01MDA0IOKAk2NvbW1pdA0KPiAgIFR1ZSBBcHIgMTkgMTA6MDM6
MTQgMjAwNSAgICAgICAgRmluZGluZyBBbGdvcml0aG0NCj4gICBUdWUgQXByIDE5IDEwOjAz
OjE0IDIwMDUgICAgICAgIEZpbmRpbmcgUHJvamVjdA0KPiAgIFR1ZSBBcHIgMTkgMTA6MDM6
MTQgMjAwNSAgICAgICAgRmluZGluZw0KPiAgIEV4dGVybmFsRGF0YWJhc2VSZWxlYXNlSWQN
Cj4gICBUdWUgQXByIDE5IDEwOjAzOjE0IDIwMDUgICAgICAgIEZpbmRpbmcNCj4gICBFeHRl
cm5hbERhdGFiYXNlSWQNCj4gICBUdWUgQXByIDE5IDEwOjAzOjE0IDIwMDUgICAgICAgIEZp
bmRpbmcgU2VxdWVuY2UNCj4gICBUeXBlIElkDQo+ICAgVHVlIEFwciAxOSAxMDowMzoxNCAy
MDA1ICAgICAgICBMb2FkaW5nIFhNTA0KPiAgIGZpbGUvaG9tZS9hbXJ1dGFqL2dlbmJhbmtf
ZmlsZXMvbmNfMDAyOTI3LnhtbA0KPiAgIExvYWRpbmcgWE1MIGZpbGU6DQo+ICAgL2hvbWUv
YW1ydXRhai9nZW5iYW5rX2ZpbGVzL25jXzAwMjkyNy54bWwNCj4gICBUdWUgQXByIDE5IDEw
OjA0OjUxIDIwMDUgICAgICAgIEZpbmRpbmcgVGF4b25JRA0KPiAgIFN1Ym1pdHRpbmcgc2Vx
dWVuY2Ugb2YgbGVuZ3RoIDANCj4gICBUdWUgQXByIDE5IDEwOjA1OjE5IDIwMDUgICAgICAg
IFJFU1VMVCAgMQ0KPiAgIFthbXJ1dGFqQGFzaWFnbyBndXNdJA0KPiAgICANCj4gICAgDQo+
ICAgR0JQYXJzZXI6DQo+ICAgIGdhIEdVUzo6Q29tbW9uOjpQbHVnaW46OkdCUGFyc2VyIFwN
Cj4gICAtLWZpbGU9fi9nZW5iYW5rX2ZpbGVzL25jXzAwMjkyNy5nYiAtLWRlYnVnIFwNCj4g
ICAtLWdiUmVsPTE0NiAtLWRiX3JlbF9pZD0yMiAtLWNvbW1pdA0KPiAgICANCj4gICAgLS0t
LS0tLS0tLS0tLS0tLS0tIGVudHJ5IG51bWJlciAxIC0tLS0tLS0tLS0tLS0tLS0tDQo+ICAg
WW91IGhhdmUgZXhjZWVkZWQgdGhlIG1heGltdW0gbnVtYmVyIG9mIGFsbG93YWJsZQ0KPiAg
IG9iamVjdHMgaW4gbWVtb3J5Og0KPiAgICAgWW91IG11c3QgdXNlIHRoZSBtZXRob2QgJ3Vu
ZGVmUG9pbnRlckNhY2hlKCknIGluDQo+ICAgZWFjaCBsb29wDQo+ICAgICAgIHRvIGNsZWFy
IHRoZSBjYWNoZSBhbmQgYWxsb3cgZ2FyYmFnZQ0KPiAgIGNvbGxlY3Rpb24hIQ0KPiAgICBJ
ZiB5b3UgbmVlZCA+IDUwMDAwIG9iamVjdHMgYXQgb25lIHRpbWUsDQo+ICAgICAgdGhlbiBp
bmNyZWFzZSB0aGUgZGVmYXVsdCBudW1iZXIgd2l0aCB0aGUgbWV0aG9kDQo+ICAgJ3NldE1h
eGltdW1OdW1iZXJPZk9iamVjdHMoPG51bWJlcj4pJyBhdA0KPiAgIC9vcHQvZ3VzL2d1c19o
b21lL2xpYi9wZXJsL0dVUy9PYmpSZWxQL0RiaURhdGFiYXNlLnBtDQo+ICAgbGluZSA1MTIN
Cj4gICAgICAgICAgDQo+ICANCkdVUzo6T2JqUmVsUDo6RGJpRGF0YWJhc2U6OmFkZFRvUG9p
bnRlckNhY2hlKCdHVVM6Ok9ialJlbFA6OkRiaURhdGFiYXNlPUhBU0goMHg4YzM3MWY4KScs
J0dVUzo6TW9kZWw6OkRvVFM6OkRiUmVmTkFTZXF1ZW5jZT1IQVNIKDB4MTI1MDlkNmMpJykN
Cj4gICBjYWxsZWQgYXQNCj4gICAvb3B0L2d1cy9ndXNfaG9tZS9saWIvcGVybC9HVVMvTW9k
ZWwvR3VzUm93LnBtIGxpbmUNCj4gICAyOA0KPiAgICAgICAgICANCj4gICBHVVM6Ok1vZGVs
OjpHdXNSb3c6Om5ldygnR1VTOjpNb2RlbDo6RG9UUzo6RGJSZWZOQVNlcXVlbmNlJykNCj4g
ICBjYWxsZWQgYXQNCj4gICAvb3B0L2d1cy9ndXNfaG9tZS9saWIvcGVybC9HVVMvQ29tbW9u
L1BsdWdpbi9HQlBhcnNlci5wbQ0KPiAgIGxpbmUgNzc5DQo+ICAgICAgICAgIA0KPiAgDQpH
VVM6OkNvbW1vbjo6UGx1Z2luOjpHQlBhcnNlcjo6YnVpbGREYlhSZWYoJ0NCSUw6OkJpbzo6
R2VuQmFuazo6UXVhbGlmaWVyPUhBU0goMHhiZmQ0MTQ0KScsJ0dVUzo6TW9kZWw6OkRvVFM6
OkV4dGVybmFsTkFTZXF1ZW5jZT1IQVNIKDB4ZGVlNzNiOCknKQ0KPiAgIGNhbGxlZCBhdA0K
PiAgIC9vcHQvZ3VzL2d1c19ob21lL2xpYi9wZXJsL0dVUy9Db21tb24vUGx1Z2luL0dCUGFy
c2VyLnBtDQo+ICAgbGluZSA1MDMNCj4gICAgICAgICAgDQo+ICANCkdVUzo6Q29tbW9uOjpQ
bHVnaW46OkdCUGFyc2VyOjpidWlsZEZlYXR1cmVzKCdHVVM6OkNvbW1vbjo6UGx1Z2luOjpH
QlBhcnNlcj1IQVNIKDB4ODVhMGI5MCknLCdDQklMOjpCaW86OkdlbkJhbms6OkVudHJ5PUhB
U0goMHhhMzc0Mzk0KScsJ0dVUzo6TW9kZWw6OkRvVFM6OkV4dGVybmFsTkFTZXF1ZW5jZT1I
QVNIKDB4ZGVlNzNiOCknKQ0KPiAgIGNhbGxlZCBhdA0KPiAgIC9vcHQvZ3VzL2d1c19ob21l
L2xpYi9wZXJsL0dVUy9Db21tb24vUGx1Z2luL0dCUGFyc2VyLnBtDQo+ICAgbGluZSAyNTEN
Cj4gICAgICAgICAgDQo+ICANCkdVUzo6Q29tbW9uOjpQbHVnaW46OkdCUGFyc2VyOjpwcm9j
ZXNzRW50cnkoJ0dVUzo6Q29tbW9uOjpQbHVnaW46OkdCUGFyc2VyPUhBU0goMHg4NWEwYjkw
KScsJ0NCSUw6OkJpbzo6R2VuQmFuazo6QXJyYXlTdHJlYW09SEFTSCgweGEzNzQzMjgpJykN
Cj4gICBjYWxsZWQgYXQNCj4gICAvb3B0L2d1cy9ndXNfaG9tZS9saWIvcGVybC9HVVMvQ29t
bW9uL1BsdWdpbi9HQlBhcnNlci5wbQ0KPiAgIGxpbmUgMTg1DQo+ICAgICAgICAgICBldmFs
IHsuLi59IGNhbGxlZCBhdA0KPiAgIC9vcHQvZ3VzL2d1c19ob21lL2xpYi9wZXJsL0dVUy9D
b21tb24vUGx1Z2luL0dCUGFyc2VyLnBtDQo+ICAgbGluZSAxODQNCj4gICAgICAgICAgDQo+
ICANCkdVUzo6Q29tbW9uOjpQbHVnaW46OkdCUGFyc2VyOjpydW4oJ0dVUzo6Q29tbW9uOjpQ
bHVnaW46OkdCUGFyc2VyPUhBU0goMHg4NWEwYjkwKScsJ0hBU0goMHg4ZTRjMTY4KScpDQo+
ICAgY2FsbGVkIGF0DQo+ICAgL29wdC9ndXMvZ3VzX2hvbWUvbGliL3BlcmwvR1VTL1BsdWdp
bk1nci9HdXNBcHBsaWNhdGlvbi5wbQ0KPiAgIGxpbmUgNDUzDQo+ICAgICAgICAgICBldmFs
IHsuLi59IGNhbGxlZCBhdA0KPiAgIC9vcHQvZ3VzL2d1c19ob21lL2xpYi9wZXJsL0dVUy9Q
bHVnaW5NZ3IvR3VzQXBwbGljYXRpb24ucG0NCj4gICBsaW5lIDQ1MA0KPiAgICAgICAgICAN
Cj4gIA0KR1VTOjpQbHVnaW5NZ3I6Okd1c0FwcGxpY2F0aW9uOjpkb01ham9yTW9kZV9SdW5P
clJlcG9ydCgnR1VTOjpQbHVnaW5NZ3I6Okd1c0FwcGxpY2F0aW9uPUhBU0goMHg4MDRjOGM0
KScsJ0dVUzo6Q29tbW9uOjpQbHVnaW46OkdCUGFyc2VyJywxKQ0KPiAgIGNhbGxlZCBhdA0K
PiAgIC9vcHQvZ3VzL2d1c19ob21lL2xpYi9wZXJsL0dVUy9QbHVnaW5NZ3IvR3VzQXBwbGlj
YXRpb24ucG0NCj4gICBsaW5lIDM4Mw0KPiAgICAgICAgICANCj4gIA0KR1VTOjpQbHVnaW5N
Z3I6Okd1c0FwcGxpY2F0aW9uOjpkb01ham9yTW9kZV9SdW4oJ0dVUzo6UGx1Z2luTWdyOjpH
dXNBcHBsaWNhdGlvbj1IQVNIKDB4ODA0YzhjNCknLCdHVVM6OkNvbW1vbjo6UGx1Z2luOjpH
QlBhcnNlcicpDQo+ICAgY2FsbGVkIGF0DQo+ICAgL29wdC9ndXMvZ3VzX2hvbWUvbGliL3Bl
cmwvR1VTL1BsdWdpbk1nci9HdXNBcHBsaWNhdGlvbi5wbQ0KPiAgIGxpbmUgMjg5DQo+ICAg
ICAgICAgIA0KPiAgDQpHVVM6OlBsdWdpbk1ncjo6R3VzQXBwbGljYXRpb246OmRvTWFqb3JN
b2RlKCdHVVM6OlBsdWdpbk1ncjo6R3VzQXBwbGljYXRpb249SEFTSCgweDgwNGM4YzQpJywn
R1VTOjpDb21tb246OlBsdWdpbjo6R0JQYXJzZXInKQ0KPiAgIGNhbGxlZCBhdA0KPiAgIC9v
cHQvZ3VzL2d1c19ob21lL2xpYi9wZXJsL0dVUy9QbHVnaW5NZ3IvR3VzQXBwbGljYXRpb24u
cG0NCj4gICBsaW5lIDE5OA0KPiAgICAgICAgICANCj4gIA0KR1VTOjpQbHVnaW5NZ3I6Okd1
c0FwcGxpY2F0aW9uOjpwYXJzZUFuZFJ1bignR1VTOjpQbHVnaW5NZ3I6Okd1c0FwcGxpY2F0
aW9uPUhBU0goMHg4MDRjOGM0KScsJ0FSUkFZKDB4ODA1ZmY2OCknKQ0KPiAgIGNhbGxlZCBh
dCAvb3B0L2d1cy9ndXNfaG9tZS9iaW4vZ2EgbGluZSAxMQ0KPiAgICANCj4gICAgLS0tLS0t
LS0tLS0tLS0tLS0tIGVudHJ5IG51bWJlciAyIC0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgQ2Fu
J3QgY2FsbCBtZXRob2QgImdldEFjY2Vzc2lvbiIgb24gYW4gdW5kZWZpbmVkDQo+ICAgdmFs
dWUgYXQNCj4gICAvb3B0L2d1cy9ndXNfaG9tZS9saWIvcGVybC9HVVMvQ29tbW9uL1BsdWdp
bi9HQlBhcnNlci5wbQ0KPiAgIGxpbmUgMjE4LCA8R0VOMD4gbGluZSAyMzAzNjUuDQo+ICAg
IA0KPiAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICANCj4gICAgDQo+
ICAgIA0KPiAgICANCi0tLS0tLS0tLS0tLS0tLS0tDQpFZCBSb2JpbnNvbg0KQ2VudGVyIGZv
ciBUcm9waWNhbCBhbmQgRW1lcmdpbmcgR2xvYmFsIERpc2Vhc2VzDQpVbml2ZXJzaXR5IG9m
IEdlb3JnaWEsIEF0aGVucywgR0EgMzA2MDINCmVyb2JpbnNvQHVnYS5lZHUvKDcwNik1NDIu
MTQ0Ny8yNTQuODg4Mw0K