gusdev-gusdev — Topics concerning GUS development

Re: [GUSDEV] you MUST check in your work

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

All,

A really effective way of doing this is to use the cvs release command.
When done a the top of a project, it will confirm that there are no pending
(uncommitted) changes, and then note in the history file that you've
released.

You then won't be able to commit changes from the checkout again.

--Mike



On 6/9/05 12:06 PM, "Steve Fischer" <sfi...@pc...> wrote:

> Folks-
> 
> You MUST check in your work on the GUS project by 6 am EST Friday 6/9
> (tomorrow)
> 
> otherwise your changes will be LOST.
> 
> as described in previous mail from Mike, we are switching from the
> Sanger CVS service to a Subversion service at CBIL.
> 
> steve
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

[GUSDEV] you MUST check in your work

[Steve F. <sfi...@pc...>]

Folks-

You MUST check in your work on the GUS project by 6 am EST Friday 6/9 
(tomorrow)

otherwise your changes will be LOST.

as described in previous mail from Mike, we are switching from the 
Sanger CVS service to a Subversion service at CBIL.

steve

[GUSDEV] ** IMPORTANT GUS CVS NEWS

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

All,

As previously proposed:

On Friday we'll moving the GUS cvs repository from Sanger to a SVN-based
repository at CBIL.  This will affect the GUS, WDK, WdkToySite, and install
projects (including the 3.5 branch!)

PLEASE CHECKIN ALL LOCAL MODIFICATIONS BY 6AM EST!!

Any local changes after that point will be un-commitable.  After the move,
you'll need to re-checkout local copies.

More information to follow.

Thanks,

Mike

[GUSDEV] GUS CVS Repository Proposal

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

All,

I'd like to propose to the GUS community the move from a CVS repository
hosted by Sanger to a Subversion repository hosted here at CBIL.  This
proposal follows several internal discussions here at CBIL about the best
way for the community to collectively work together on GUS, some
frustrations about the functionality provided by CVS, and complete technical
proof-of-concept testing.

First, a word about Subversion.  Subversion is an open source "version
control system that is a compelling replacement for CVS".  As a replacement,
subversion provides an almost identical user experience to CVS (except where
there was compelling reason to do otherwise).  For example, "cvs update" is
replaced by "svn update"; "cvs commit" replaced by "svn commit", and so on.

Subversion provides a lot of nice new functionality, such as support for
moving files and directories within a repository (and keeping history
details intact throughout the move), improved performance (costs are
generally in proportion to change size, not the data size), additional
offline actions, atomic commits, and proper versioning of directories,
renames, and file meta-data.

Subversion will also permit us to allow per-directory permissions,
increasing access and (hopefully) participation within the GUS project.

Before committing to making the change (which would most likely occur as
part of the 3.5 release process), we want to make sure that there are no
objections from the community, and that any concerns or questions are fully
addressed.

To be clear, the only change that developers will need to make is accessing
the repository via svn, instead of cvs.  This will require using a svn
client (although accessing the repository via the web will still be
supported for read-only access).  svn is supported on all modern operating
systems, and several also support graphical clients for those that do not
care for the command line.

More information is available at: http://subversion.tigris.org/

Thanks,

Mike

Re: [GUSDEV] plugins and CVs again

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

sounds good to me.

--Mike

On 6/6/05 4:58 PM, "Steve Fischer" <sfi...@pc...> wrote:

> ok.  yes, the format will be two columns, tab delimited.   how's that?
> 
> what we can do is rename my method from:
>  
> checkControlledVocab($file, $table, $column)
> 
> to:
> 
> my cvHash = getControlledVocab($file, $table, $column)
> 
> (it still dies if there is a problem.)
> 
> the key of the hash is the input value.  the value of the hash is a
> little hash with keys "term" and "primaryKey"
> 
> steve
> 
> Michael Saffitz wrote:
> 
>> Hi Steve,
>> 
>> Ok.  We'll have to standardize the format of the dinky CV mapping files,
>> right?
>> 
>> I think the following methods would be really helpful as well:
>> 
>> getInternalTermPrimaryKey( $external_term)
>> getInternalTerm( $external_term)
>> 
>> This way the individual plugins don't need to implement parsing the dinky
>> cvs file.  (method names are just quick suggestions, change at will :)
>> 
>> --Mike
>> 
>> 
>> 
>> On 6/6/05 4:11 PM, "Steve Fischer" <sfi...@pc...> wrote:
>> 
>>  
>> 
>>> ok, now i think i've cracked it.  and its simple simple simple.
>>> 
>>> any plugin that uses a dinky CV takes a mapping file from the input to
>>> the GUS CV.   the case where the input is identical to the GUS CV is not
>>> given special handling.
>>> 
>>> i will write a method in Plugin.pm:
>>> 
>>> checkControlledVocab($cvMappingFile, $table, $column);
>>> 
>>> it throws an exception (dies) unless every entry in the GUS column of
>>> the file is found in the db.
>>> 
>>> the message will include every entry not found.
>>> 
>>> then the user of the plugin has to update the table with the cv, or
>>> change the mapping file.
>>> 
>>> as far as consistency across applications within a site:  the user of
>>> the plugin will dump the table to see the allowed values.   that will
>>> serve as the authoritative version from which to make the mapping file.
>>> 
>>> steve
>>> 
>>> 
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
>>> shotput
>>> a projector? How fast can you ride your desk chair down the office luge
>>> track?
>>> If you want to score the big prize, get to know the little guy.
>>> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>>> _______________________________________________
>>> Gusdev-gusdev mailing list
>>> Gus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>>    
>>> 
>> 
>>  
>> 

Re: [GUSDEV] plugins and CVs again

[Steve F. <sfi...@pc...>]

ok.  yes, the format will be two columns, tab delimited.   how's that?

what we can do is rename my method from:
 
checkControlledVocab($file, $table, $column)

to:

my cvHash = getControlledVocab($file, $table, $column)

(it still dies if there is a problem.)

the key of the hash is the input value.  the value of the hash is a 
little hash with keys "term" and "primaryKey"

steve

Michael Saffitz wrote:

>Hi Steve,
>
>Ok.  We'll have to standardize the format of the dinky CV mapping files,
>right?
>
>I think the following methods would be really helpful as well:
>
>getInternalTermPrimaryKey( $external_term)
>getInternalTerm( $external_term)
>
>This way the individual plugins don't need to implement parsing the dinky
>cvs file.  (method names are just quick suggestions, change at will :)
>
>--Mike
>
>
>
>On 6/6/05 4:11 PM, "Steve Fischer" <sfi...@pc...> wrote:
>
>  
>
>>ok, now i think i've cracked it.  and its simple simple simple.
>>
>>any plugin that uses a dinky CV takes a mapping file from the input to
>>the GUS CV.   the case where the input is identical to the GUS CV is not
>>given special handling.
>>
>>i will write a method in Plugin.pm:
>>
>>checkControlledVocab($cvMappingFile, $table, $column);
>>
>>it throws an exception (dies) unless every entry in the GUS column of
>>the file is found in the db.
>>
>>the message will include every entry not found.
>>
>>then the user of the plugin has to update the table with the cv, or
>>change the mapping file.
>>
>>as far as consistency across applications within a site:  the user of
>>the plugin will dump the table to see the allowed values.   that will
>>serve as the authoritative version from which to make the mapping file.
>>
>>steve
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
>>a projector? How fast can you ride your desk chair down the office luge track?
>>If you want to score the big prize, get to know the little guy.
>>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>>_______________________________________________
>>Gusdev-gusdev mailing list
>>Gus...@li...
>>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>    
>>
>
>  
>

Re: [GUSDEV] plugins and CVs again

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

Hi Steve,

Ok.  We'll have to standardize the format of the dinky CV mapping files,
right?

I think the following methods would be really helpful as well:

getInternalTermPrimaryKey( $external_term)
getInternalTerm( $external_term)

This way the individual plugins don't need to implement parsing the dinky
cvs file.  (method names are just quick suggestions, change at will :)

--Mike



On 6/6/05 4:11 PM, "Steve Fischer" <sfi...@pc...> wrote:

> ok, now i think i've cracked it.  and its simple simple simple.
> 
> any plugin that uses a dinky CV takes a mapping file from the input to
> the GUS CV.   the case where the input is identical to the GUS CV is not
> given special handling.
> 
> i will write a method in Plugin.pm:
> 
> checkControlledVocab($cvMappingFile, $table, $column);
> 
> it throws an exception (dies) unless every entry in the GUS column of
> the file is found in the db.
> 
> the message will include every entry not found.
> 
> then the user of the plugin has to update the table with the cv, or
> change the mapping file.
> 
> as far as consistency across applications within a site:  the user of
> the plugin will dump the table to see the allowed values.   that will
> serve as the authoritative version from which to make the mapping file.
> 
> steve
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

[GUSDEV] plugins and CVs again

[Steve F. <sfi...@pc...>]

ok, now i think i've cracked it.  and its simple simple simple.

any plugin that uses a dinky CV takes a mapping file from the input to 
the GUS CV.   the case where the input is identical to the GUS CV is not 
given special handling.

i will write a method in Plugin.pm:

checkControlledVocab($cvMappingFile, $table, $column);

it throws an exception (dies) unless every entry in the GUS column of 
the file is found in the db.

the message will include every entry not found.

then the user of the plugin has to update the table with the cv, or 
change the mapping file.

as far as consistency across applications within a site:  the user of 
the plugin will dump the table to see the allowed values.   that will 
serve as the authoritative version from which to make the mapping file.

steve

[GUSDEV] Generic GUS data loader for tab delimited files

[Eric E. S. <es...@vb...>]

Dear GUSdev,

We have been having some trouble loading DNA annotation data via the 
gbparser plugin. We have been able to get around the problem in this 
instance by using addrow, which is quite general but impossibly slow. I 
cannot help but think there must be a generic tool for loading 
tab-delimited data files into GUS.

Assuming there isn't, I think it would be time well spent if someone 
wrote a plugin for GUS that would *efficiently* load data in 
tab-delimited format based on instructions described in a 
general-purpose data description file.  This file would identify the 
tables and fields corresponding to each column in the input file.  It 
would also need to define the rules for associating data from records 
stored in multiple tables and probably do other things as well.

Any takers?  I would be happy to spend whatever time is necessary to 
define the requirements for such a system.  If it doesn't already exist 
somewhere in the GUS community, I certainly think it would be useful.

I apologize in advance if this is a recent or frequent topic for this 
list.  I just subscribed and wasn't able to access sourceforge to check 
the archives.

Thanks!
eesnyder
-- 
Eric E. Snyder, Ph.D.
Virginia Bioinformatics Institute
Washington Street Phase 1 (0447)
Virginia Polytechnic Institute and State University
Blacksburg, VA 24061
USA

Office:	(540) 231-5428
Mobile:	(540) 230-5225
Fax:	(540) 231-2891
Email:	ees...@vb...
JDAM:	N 37 12'01.6", W 80 24'26.9"

[GUSDEV] Trunk merged into rel_3_5 branch

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

FYI:

The CVS trunk has been merged into the rel_3_5 branch.  If you have a copy
of rel_3_5 checked out, you should do a cvs update.

--Mike

[GUSDEV] New Plugin::Report

[Jonathan S. <js...@pc...>]

Folks:

Perhaps unbeknownst to most people it is now possible to make read- 
only plugins.  These plugins do not need to be registered to be run.   
The goal of such plugins is to make it easy to maintain plugins that  
access GUS, but do not need to write any data.  They can not submit  
objects so they have some write-protection, but you can still cheat  
and execute SQL that writes or deletes, but *do not do that*.  The ga  
program recognizes that a plugin is read-only when its package name  
matches the template  
<project>::<component>::Plugin::Report::<plugin>, e.g.,  
GUS::Common::Plugin::Report::PluginLister.  (I guess this should be  
renamed ListPlugins to follow the new guidelines.)  I've created a  
few utility read-only plugins and put them under GUS::Common.  Check  
them out.

Thoughts?

Jonathan



------------------------------------------------------------------------ 
---
Jonathan Schug            Center for Bioinformatics
js...@pc...     Computational Biology and Informatics Lab
(215) 573-3113 voice      University of Pennsylvania,
(215) 573-3111 fax        1413 Blockley Hall, Philadelphia, PA
                           19014-6021

Re: [GUSDEV] new GUS documentation effort

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

Steve,

GUS 3.5 will include documentation in several formats (pdf, html, etc.)
produced from docbook format which is included as a component in the GUS
source.  This will include a user's guide, install guide (pretty much
completed), and a developer's guide (using Ed's documentation as a base).

I see the wiki as supplementing the official documentation.  I don't think
the wiki is well suited to house the official documentation for a variety of
reasons-- poor offline support, too much of a "living" document, poor
support for multiple concurrent authors (compared to cvs), etc.

--Mike

On 6/5/05 7:21 AM, "Steve Fischer" <sfi...@pc...> wrote:

> folks-
> 
> i am putting some time into creating wiki docs for gus, modeled on the
> WDK docs.
> 
> you can see the work in progress on the wiki
> 
> i am folding in the idea's from Ed's documentation.
> 
> http://www.gusdb.org/wiki/
> 
> you will see that the documentation is organized by version number.
> when we release a new version we begin the documentation effort by
> copying the previous release to a new address that uses the new version
> number, and then edit it to reflect the changes in the new version.
> 
> suggestions encouraged.
> 
> steve
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

[GUSDEV] new GUS documentation effort

[Steve F. <sfi...@pc...>]

folks-

i am putting some time into creating wiki docs for gus, modeled on the 
WDK docs.

you can see the work in progress on the wiki

i am folding in the idea's from Ed's documentation.

http://www.gusdb.org/wiki/

you will see that the documentation is organized by version number.  
when we release a new version we begin the documentation effort by 
copying the previous release to a new address that uses the new version 
number, and then edit it to reflect the changes in the new version.

suggestions encouraged.

steve

[GUSDEV] Taxon_id in GBParser

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

Hello,

=20

We=92re having a problem with our GBParser again. We=92re trying to =
insert the
attached file to test GBParser, but we always receive the error showed
bellow:

=20

DBD::Pg::st execute failed: ERROR:  insert or update on table
"nasequenceimp" violates foreign key constraint "nasequenceimp_fk02" at
/usr/local/GUS/gus_home/lib/perl/GUS/ObjRelP/DbiDbHandle.pm line 147, =
<GEN0>
line 83.

=20

In gbparserFailures/errors we noticed that the taxon_id value is 0 and =
we
don=92t have this value in the database (Sres.Taxon table). How does =
GBParser
get taxon_id value? It=92s from genbank input file, isn=92t it? And why =
our
taxon_id is always 0? :-(

=20

Thanks a lot,

=20

Fabr=EDcio.

[GUSDEV] 6/3 GUS 3.5 Development Status

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

IMPORTANT PRE-3.5 STATUS REPORT NOTE:

GUS 3.5 is nearing completion.  Before releasing it, the 3.5 branch in CVS
will need to be merged back into the main trunk.  This will be easiest if
CVS access is restricted.  THUS:  Please be prepared to commit all changes
to CVS by the end of next week (regardless of which branch you're working
in).  It's very highly likely that CVS will be restricted early the
following week for the merge and anticipated release of GUS 3.5.  More
details to follow as we get closer.

GUS 3.5 Development Status

This is an updated 3.5 status report. As always, please let me know if you
have any questions or concerns.

Important!=A0 While components of GUS 3.5 are finalized and the overall syste=
m
is nearing release, it is NOT YET READY=A0for use and attempting to do so in =
a
production environment, or even in a test environment in which GUS 3.0
exists MAY RESULT IN DATA LOSS.=A0 You have been warned!=A0 Do NOT=A0use the GUS
3.5 cvs branches for any other purpose than GUS 3.5 development, and only
after having read and fully understanding the relevant documentation.

* Schema

Completed and frozen for release.

See the Administrative Functions for a few small notes that tangentially
affected the schema.

* Plugins

The plugins still represent the largest body of work remaining for 3.5.
We're moving closer, especially thanks to the hard work from Jennifer Domme=
r
and Debbie Pinney.  Most of the Plugin development team feels that remainin=
g
plugins will be completed by 6/10.

* Application Framework

There were a few small changes this week in the application framework,
mostly to address Java compile issues.  I believe the application framework
to now be stable and complete, pending any yet-to-be-discovered bugs.

* Administrative Functions & Installing

The configuration for the administrative framework has been updated so that
tables use NUMBER datatypes for housekeeping columns instead of CHARACTERS.

An oversight was addressed that prevented the CHARACTER datatype from havin=
g
any length greater than 1.

Many tables were renamed in the gus_schema.xml file to fix capitalization
issues.

The bootstrap data issue has been resolved by required plugins to bring wit=
h
themselves any trivial CVs.  See related emails from this past week.

I believe the administrative functions and installer to now be stable and
complete, pending any yet-to-be-discovered bugs.

* Documentation

The install guide is nearing completion-- I expect it to be done Monday.
The developers and users guides will be next, and hopefully completed by th=
e
end of next week.

* Upgrading

No changes.

[GUSDEV] 3.5 plugdev Database Reloaded

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

FYI:

CBIL's 3.5 Plugin Development Database, plugdev, has been reloaded to
reflect several bug fixes and other issues.  Specifically, these were:

https://www.cbil.upenn.edu/tracker/show_bug.cgi?id=29 :
dots.sequencetype.nucleotide_type  type

https://www.cbil.upenn.edu/tracker/show_bug.cgi?id=30 : the object layer
class name was not generated correctly

This has resulted in minor changes/fixes to the schema.

--Mike

P.S. CBIL folks-- toxobld has also been rebuilt.

Re: [GUSDEV] Error in Loading NCBI data

[Jinal J. <jjh...@vb...>]

It's a warning and not an error! GBParser doesn't understand/load locus_tag 
and that's why it complains("warns") about it.  

A good test would be to double check if all gbk entries were loaded in 
dots.nafeature


On Thursday 02 June 2005 03:12 pm, Kumar, Sanjeev (Contr) wrote:
> Hi I am getting following error while loading the NCBI gene data using
> GBParser:
>
> Wed Jun 1 14:53:41 2005 INVALID QUALIFIER GUS::Model::DoTS::GeneFeature ::
> locus_tag :: MT0570 Wed Jun 1 14:53:41 2005 INVALID QUALIFIER
> GUS::Model::DoTS::Transcript :: locus_tag :: MT0570 Wed Jun 1 14:53:41 2005
> INVALID QUALIFIER GUS::Model::DoTS::GeneFeature :: locus_tag :: MT0571 Wed
> Jun 1 14:53:41 2005 INVALID QUALIFIER GUS::Model::DoTS::Transcript ::
> locus_tag :: MT0571 I have seen in the archive that couple of members had
> reported this problem earlier , but I couldn't locate the solution to this
> problem. I am using following command to load the data:
> $ ga GUS::Common::Plugin::GBParser
> --file=/home/domana/Downloads/data/AE000516.gbk --gbRel=146 --db_rel_id=200
> --verbose > AE000516.gbk.out
>
> Can any one help in finding the solution for this.
> Thanks
> Sanjeev
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit
> http://developer.yahoo.net/?fr_____________________________________________
>__ Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

[GUSDEV] Error in Loading NCBI data

[Kumar, S. \(Contr\) <San...@ng...>]

Hi I am getting following error while loading the NCBI gene data using =
GBParser:

Wed Jun 1 14:53:41 2005 INVALID QUALIFIER GUS::Model::DoTS::GeneFeature =
:: locus_tag :: MT0570=20
Wed Jun 1 14:53:41 2005 INVALID QUALIFIER GUS::Model::DoTS::Transcript =
:: locus_tag :: MT0570=20
Wed Jun 1 14:53:41 2005 INVALID QUALIFIER GUS::Model::DoTS::GeneFeature =
:: locus_tag :: MT0571=20
Wed Jun 1 14:53:41 2005 INVALID QUALIFIER GUS::Model::DoTS::Transcript =
:: locus_tag :: MT0571
I have seen in the archive that couple of members had reported this =
problem earlier , but I couldn't locate the solution to this problem.
I am using following command to load the data:
$ ga GUS::Common::Plugin::GBParser =
--file=3D/home/domana/Downloads/data/AE000516.gbk --gbRel=3D146 =
--db_rel_id=3D200 --verbose > AE000516.gbk.out

Can any one help in finding the solution for this.
Thanks
Sanjeev

Re: [GUSDEV] plugin naming conventions

[Aaron J. M. <am...@pc...>]

On Jun 1, 2005, at 7:36 PM, Steve Fischer wrote:

> comments?

This is rock solid.  I'm so glad to see you back in action!

-Aaron

--
Aaron J. Mackey, Ph.D.
Project Manager, ApiDB Bioinformatics Resource Center
Penn Genomics Institute, University of Pennsylvania
email:  am...@pc...
office: 215-898-1205
fax:    215-746-6697
postal: Penn Genomics Institute
         Goddard Labs 212
         415 S. University Avenue
         Philadelphia, PA  19104-6017

[GUSDEV] Re: new plugin/CV policy

[Steve F. <sfi...@pc...>]

a clarification:
 
plugins that use CVs fall into two categories:
  1. those that hard code the CV. 
  2. those that do not hard code the CV, but, rather, get it from the input

in case 1, the plugin, obviously, hard codes the CV and does not offer 
the option of a file to change it.

in case 2, the plugin hard codes only a default.  if the user of the 
plugin determines that the input has an different CV, then the user must 
provide a file to the plugin specifying the CV.  (the plugin will fail 
if the input CV does not match the default, or the file if provided)

steve

Steve Fischer wrote:

> folks-
>
> there are a number of "dinky" controlled vocabularies in the GUS schema:
>
> DoTS.BlatAlignmentQuality
> DoTS.GOAssociationInstanceLOE
> DoTS.GeneCategory
> DoTS.GeneInstanceCategory
> DoTS.InteractionType
> DoTS.MotifRejectionReason
> DoTS.ProteinCategory
> DoTS.ProteinInstanceCategory
> DoTS.ProteinProteinCategory
> DoTS.ProteinPropertyType
> DoTS.RNACategory
> DoTS.RNAInstanceCategory
> DoTS.RNARNACategory
> DoTS.RepeatType
> SRes.BibRefType
> SRes.ReviewStatus
>
> These are application specific.
>
> Here is how i think we can manage these.
>
> 1. any foreign key to any of these tables must be nullable
>
> 2. any plugin that writes to or reads from one of these tables must  
> make sure that it contains at least the vocab that the plugin  expects 
> (but possibly a superset).  That is, it reads the table to  make 
> sure.   If the expected vocab is not found, the plugin updates  the 
> table.
>
> 3. the plugin hard-codes a default controlled vocabulary.  It  
> optionally takes a file that specifies the vocab.  This way a site  
> can maintain consistency of the vocab across  plugins and as the  
> vocab evolves.
>
> comments?
>
> steve
>

[GUSDEV] plugin naming conventions

[Steve F. <sfi...@pc...>]

folks-

as you might know, we at cbil are preparing for release 3.5.   part of 
that effort is to sort the plugins that exist into two categories:
  - supported
  - community

a supported plugin is one that is known to work, adheres to the plugin 
standard, and will be of use to at least two sites.  a community plugin 
is not reviewed by CBIL.  if it meets all three of those standards then 
it would be promoted to supported. 

we have designated a set of plugins that are supported (sent in previous 
mail i believe).

and, we are now bringing them up to the standard.

part of the standard is how to name a plugin.  we will be changing the 
names of any supported plugins that do not comply.

here is the standard:
  1. a plugin must start with one of four verbs:
         - insert:  insert only, no update or delete
         - delete: delete only, no update or insert
         - update: update only, no insert or delete
         - load: any two or more of insert, delete or update
  2. the name should be concise
  3. the name should be accurate.

The poster child of a plugin name that needs improvement is 
InsertNewExternalSequences.     it violates all three rules.  (in 
fairness, it was written long ago before there were "standards" or even 
users of GUS outside CBIL).  the plugin inserts and updates, so it 
should start with load.  it is not concise because "insert" and "new" is 
redundant.  and, it is not accurate because (1) it can load sequences 
that are already in the database (2) it can load sequences that are 
generated internally as well as externally (the only constraint is that 
it expects that the sequence be tagged with a source database) and (3) 
it doesn't inform the user that it the sequences must be in Fasta format.

The new name will be LoadFastaSequences

(now isn't that clearer)

comments?

steve

[GUSDEV] Re: dbest_name in DoTS::EST

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

Hi Fernan,


On 6/1/05 9:25 AM, "Fernan Aguero" <fe...@ii...> wrote:

> +----[ Michael Saffitz <msa...@pc...> (31.May.2005 15:52):
> |
> | Hi Fernan,
> | 
> | In general, the issue here is that the current (and soon to be released 3.5
> | schema) doesn't fully allow for representation of a particular domain.  As
> | discussed, one approach is to "massage" the data into the available schema,
> | but as noted, this is not ideal for numerous reasons including overall
> | compatibility, data model clarity, integration concerns, and so on.  The
> | only other approach then is to change the data model/schema to fully support
> | the domain.  You may do this locally, within your own GUS instance, or (and
> | much preferred) you may submit the changes to the GUS community for
> | inclusion with the GUS project.
> 
> I completely agree.
> 
> | This latter route is what I'd suggest in this case.  The
> | procedure for this is:
> | 
> | 1) Create a ticket in the tracker with the proposed
> | changes, being as specific as possible.  SQL DDL is much
> | appreciated.
> 
> Maybe a diff against gus_schema.xml? Seems to me easier to
> apply.

Yes, a diff against the gus_schema.xml is fine as well.  Eventually we'll
have another schema that defines changes (i.e:

<add>
    <column name="record_id" table="dots.nasequence">
</add

)

> 
> | 2) Send an email to the list requesting feedback and comments on the change.
> | This allows the community to evaluate the change and work as a whole to come
> | up with the best solution.  Sometimes this step is not required for smaller
> | changes, and sometimes this step and the first step are switched in order.
> | 
> | 3) Once the community has come to a consensus about the change, it will be
> | incorporated into GUS and included in the next release.  If you need the
> | change sooner, you may receive it by using a CVS release of GUS (assuming
> | GUS 3.5 here).
> | 
> | Hopefully this addresses the more larger issue and your questions as well.
> | 
> | Thanks,
> | 
> | Mike
> |
> +----]
> 
> Just a minor issue: is it possible to submit 'tickets' to
> CBIL's bugzilla by email? I know bugzilla has this
> functionality and it is much more convenient (at least for
> me) to submit things this way.
> 
> Fernan

I'll look into this functionality, but it's not setup at the moment.

--Mike

[GUSDEV] new plugin/CV policy

[Steve F. <sfi...@pc...>]

folks-

there are a number of "dinky" controlled vocabularies in the GUS schema:

DoTS.BlatAlignmentQuality
DoTS.GOAssociationInstanceLOE
DoTS.GeneCategory
DoTS.GeneInstanceCategory
DoTS.InteractionType
DoTS.MotifRejectionReason
DoTS.ProteinCategory
DoTS.ProteinInstanceCategory
DoTS.ProteinProteinCategory
DoTS.ProteinPropertyType
DoTS.RNACategory
DoTS.RNAInstanceCategory
DoTS.RNARNACategory
DoTS.RepeatType
SRes.BibRefType
SRes.ReviewStatus

These are application specific.

Here is how i think we can manage these.

1. any foreign key to any of these tables must be nullable

2. any plugin that writes to or reads from one of these tables must  
make sure that it contains at least the vocab that the plugin  expects 
(but possibly a superset).  That is, it reads the table to  make sure.   
If the expected vocab is not found, the plugin updates  the table.

3. the plugin hard-codes a default controlled vocabulary.  It  
optionally takes a file that specifies the vocab.  This way a site  can 
maintain consistency of the vocab across  plugins and as the  vocab 
evolves.

comments?

steve

[GUSDEV] Re: dbest_name in DoTS::EST

[Fernan A. <fe...@ii...>]

+----[ Michael Saffitz <msa...@pc...> (31.May.2005 15:52):
|
| Hi Fernan,
| 
| In general, the issue here is that the current (and soon to be released 3.5
| schema) doesn't fully allow for representation of a particular domain.  As
| discussed, one approach is to "massage" the data into the available schema,
| but as noted, this is not ideal for numerous reasons including overall
| compatibility, data model clarity, integration concerns, and so on.  The
| only other approach then is to change the data model/schema to fully support
| the domain.  You may do this locally, within your own GUS instance, or (and
| much preferred) you may submit the changes to the GUS community for
| inclusion with the GUS project.

I completely agree.

| This latter route is what I'd suggest in this case.  The
| procedure for this is:
| 
| 1) Create a ticket in the tracker with the proposed
| changes, being as specific as possible.  SQL DDL is much
| appreciated.

Maybe a diff against gus_schema.xml? Seems to me easier to
apply.

| 2) Send an email to the list requesting feedback and comments on the change.
| This allows the community to evaluate the change and work as a whole to come
| up with the best solution.  Sometimes this step is not required for smaller
| changes, and sometimes this step and the first step are switched in order.
| 
| 3) Once the community has come to a consensus about the change, it will be
| incorporated into GUS and included in the next release.  If you need the
| change sooner, you may receive it by using a CVS release of GUS (assuming
| GUS 3.5 here).
| 
| Hopefully this addresses the more larger issue and your questions as well.
| 
| Thanks,
| 
| Mike
|
+----]

Just a minor issue: is it possible to submit 'tickets' to
CBIL's bugzilla by email? I know bugzilla has this
functionality and it is much more convenient (at least for
me) to submit things this way. 

Fernan

[GUSDEV] Re: dbest_name in DoTS::EST

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

Hi Fernan,

I'm sending this to both the GUSDEV and ApiDB lists since I think the answer
is useful to both audiences.

In general, the issue here is that the current (and soon to be released 3.5
schema) doesn't fully allow for representation of a particular domain.  As
discussed, one approach is to "massage" the data into the available schema,
but as noted, this is not ideal for numerous reasons including overall
compatibility, data model clarity, integration concerns, and so on.  The
only other approach then is to change the data model/schema to fully support
the domain.  You may do this locally, within your own GUS instance, or (and
much preferred) you may submit the changes to the GUS community for
inclusion with the GUS project.  This latter route is what I'd suggest in
this case.  The procedure for this is:

1) Create a ticket in the tracker with the proposed changes, being as
specific as possible.  SQL DDL is much appreciated.

2) Send an email to the list requesting feedback and comments on the change.
This allows the community to evaluate the change and work as a whole to come
up with the best solution.  Sometimes this step is not required for smaller
changes, and sometimes this step and the first step are switched in order.

3) Once the community has come to a consensus about the change, it will be
incorporated into GUS and included in the next release.  If you need the
change sooner, you may receive it by using a CVS release of GUS (assuming
GUS 3.5 here).

Hopefully this addresses the more larger issue and your questions as well.

Thanks,

Mike


On 5/31/05 1:42 PM, "Fernan Aguero" <fe...@ii...> wrote:

> +----[ John Iodice <io...@pc...> (31.May.2005 14:29):
> |
> | Maybe we can have it both ways, by immediately changing the plugins to
> | populate dots.ExternalNaSequence.secondary_identifier, and planning to
> | make the schema change (adding est_uid to dots.Est) in a future revision
> | (since it didn't make 3.5).
> | 
> +----]
> 
> Hi John and Michael,
> 
> as I just wrote to Deborah, I guess that source_id and
> secondary_identifier are used for accession and gi (i just
> asked her to see what is in those fields for dbEST entries
> or NRDB entries).
> 
> IF secondary_identifier is not used we can use it for the
> time being.  But that would be a hack.
> 
> I agree this would have to be in a future revision. Should I
> add it as a PR in the tracker?
> 
> Fernan