gusdev-gusdev — Topics concerning GUS development

Re: [Gusdev-gusdev] Loading similarity data

[Deborah F. P. <pi...@sn...>]

Hi,

startRunGenerateBlastSimilarity.pl is a perl script that orchestrates
blast runs on a cluster. In this case the query sequences are the
assemblies and the subject databases are sequences from prodom, nrdb, or
cdd. We are currenntly running the script via a controller that Steve
Fischer wrote. Here is an example of an old command line that might give
you some information:


startRunGenerateBlastSimilarity.pl --regex '(\S+)' --blastProgram blastp
--database prodom2001 --seqFile ~/BlastRuns/plas_v3.1VsProdom.cds
--setsize 500 --nodes '72, 73' --blastParams 'wordmask=seg+xnu W=3
T=1000'


And here is a sample output:

>40142473 (0 subjects)
>40142515 (0 subjects)
>40142529 (0 subjects)
>40142583 (0 subjects)
>40142613 (1 subjects)
  Sum: 8022685:114:1.2e-09:7:84:2:227:2:66:33:43:1:-1
   HSP1: 8022685:23:32:49:114:1.2e-09:36:84:2:148:1:-1
   HSP2: 8022685:10:11:17:44:1.2e-09:7:23:177:227:1:-3
>40142617 (0 subjects)
>97378349 (1 subjects)


We extract the assembly, prodom, and nrdb sequences from the Assembly view
of NASequenceImp and the MotifAASequence and ExternalAASequence views of
AASequenceImp. We do this using another perl script,
dumpSequencesFromTable.pl, so that they have GUS identifiers. CDD
sequences are handled using Rps Blast so that GUSidentifiers have to be
attached afterwards using substitutePrimKeysInSimilarity.pl.

Finally, the resulting similarity files are loaded into the
Similarity table (from which previous similarities for that taxon have
been deleted) using LoadBlastSimilaritiesPK.pm.


There are more details but I may have already told you more than you
want to know right now.

We are hard at work on a script that automates the entire DoTS build and
annotation process. It is in the development stage at the moment
although we are using it for a large part of the process.

I hope this helps.

                                               Deborah Pinney







On 25 Jul 2002, Keith James wrote:

>
> Hi,
>
> Sorry if you get this twice - the first time I posted nobody at Sanger
> seemed to get my message.
>
> In plugins I found LoadBlastSimilaritiesPK.pm which appears to use
> output from a script called generateBlastSimilarity.pl (which we do
> not have). What does generateBlastSimilarity.pl do and what file
> format does it produce, please?
>
> thanks,
>
> Keith
>
>

[Gusdev-gusdev] Loading similarity data

[Keith J. <kd...@sa...>]

Hi,

Sorry if you get this twice - the first time I posted nobody at Sanger
seemed to get my message.

In plugins I found LoadBlastSimilaritiesPK.pm which appears to use
output from a script called generateBlastSimilarity.pl (which we do
not have). What does generateBlastSimilarity.pl do and what file
format does it produce, please?

thanks,

Keith

-- 

- Keith James <kd...@sa...> bioinformatics programming support -
- Pathogen Sequencing Unit, The Wellcome Trust Sanger Institute, UK -

[Gusdev-gusdev] Re: [Fwd: Re: proposed modifications to GO Schema for GUS3.0]

[Matt B. <mb...@sa...>]

That should be sufficient.  In the GO database, there is only ever one 
comment per GO term.

cheers
Matt

Sharon Diskin wrote:

> Okay, thanks.   Does this mean that a single comment field added to 
> the GOTerm table is sufficient in your view?  
>
> Alternatively, we could use the DoTS.Comments table to store comments, 
> these can then be associated through the Evidence table to any row in 
> GUS.  So, another option would be to use the Comments table to store 
> the text, and link it to the GOTerm entry through the Evidence table. 
>  If this is not an appropriate use of the Evidence table, then we 
> could just create a GOTermComments linking table.  
>
> cheers,
> sharon
>
> Arnaud Kerhornou wrote:
>
>> Hi Sharon
>>
>> I forward you an example of a GO comment given by Matt.
>>
>> cheers
>> Arnaud
>>
>> -------- Original Message --------
>> Subject: Re: proposed modifications to GO Schema for GUS3.0
>> Date: Tue, 16 Jul 2002 13:19:51 +0100
>> From: Matt Berriman <mb...@sa...>
>> To: Arnaud Kerhornou <ax...@sa...>
>> References: 
>> <Pin...@sn...> 
>> <3D2...@sa...> <3D2...@pc...> 
>> <3D2...@sa...> <3D2...@pc...> 
>> <3D3...@sa...>
>>
>>
>>
>>Here's a complete entry from the GO database:
>>
>>term: C-terminal protein farnesylation
>>
>>goid: GO:0006503
>>
>>definition: The covalent or non-covalent attachment of a farnesyl moiety 
>>to the carboxy terminus of a protein. OBSOLETE.
>>
>>definition_reference: GO:jl
>>
>>comment: This term was made obsolete because the process is not exclusive to the carboxy terminus 
>>of a protein. Consider instead the biological process term 'protein amino acid farnesylation ; 
>>GO:0018347'.
>>
>>cheers
>>Matt
>>
>>
>>Arnaud Kerhornou wrote:
>>
>>> Sharon Diskin wrote:
>>>
>>>>
>>>>> Also re. the GOTerm table, would it be possible to add a comment 
>>>>> field ?
>>>>
>>>>
>>>>
>>>> I do not have a problem with this.  Does anyone else have an opinion 
>>>> on this?  What type of information would you put in the comment field?
>>>
>>>
>>> Matt,
>>>
>>> Do you have an 
>>exa
>>mple of comment you want to store ?
>>>
>>> I should mention than the GO database design allows to store several 
>>> comments (one to many relationship), one comment field might be enough 
>>> though and would keep the design simple.
>>>
>>> cheers
>>> Arnaud
>>>
>>>>
>>>> Cheers,
>>>> Sharon
>>>>
>>>> p.s.  I will be out of town until Monday July 22nd.
>>>>
>>>>>
>>>>> cheers
>>>>> Arnaud
>>>>>
>>>>> Sharon Diskin wrote:
>>>>>
>>>>>> Hi Arnaud,
>>>>>>
>>>>>> I've attached the new GO schema and documentation that Jonathan 
>>>>>> Schug and I have come up. We believe that this new schema addresses 
>>>>>> your concern about the association date and also provides a better 
>>>>>> way of tracking multiple instances/sources of the same association 
>>>>>
>>> (s
>>ee description of GOAssociationInstance table).
>>>>>>
>>>>>>
>>>>>> Regarding your other question concerning the 'DB:Ref' and 'from or 
>>>>>> with', we see these being tracked using the generic Evidence 
>>>>>> table.   The 'from or with' would be Evidence for the 
>>>>>> GOAssocInstEvidCode entry as it is connected to a specific evidence 
>>>>>> code that is assigned to the association.  The 'DB:Ref' (such as in 
>>>>>> the PubMed example you mentioned) would be Evidence for the 
>>>>>> GOAssociationInstance entry as it is _not_ connected to a specific 
>>>>>> evidence code, but rather the association as a whole.  More details 
>>>>>> can be found in the attached documentation.
>>>>>>
>>>>>>
>>>>>> Any feedback is welcome.  Also, if any of this is unclear, just let 
>>>>>&g
>>t; us know.
>>
>>>>>>
>>>>>> Cheers,
>>>>>> Sharon
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>-- 
>>
>>  Dr Matthew Berriman 
>>  Senior Computer Biologist - Pathogen Sequencing Unit - 
>>  The Wellcome Trust Sanger Institute
>>  Tel +44 (0)1223 494817 -  Fax +44 (0)1223 494919 
>>  http://www.sanger.ac.uk
>>-- 
>>Arnaud Kerhornou
>>
>>The Wellcome Trust Sanger Institute
>>The Pathogen Sequencing Unit
>>Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SA, UK
>>Work: +44 (0) 1223 494955
>>Fax:  +44 (0) 1223 494919
>>
>>
>>
>>
>>
>

-- 

  Dr Matthew Berriman 
  Senior Computer Biologist - Pathogen Sequencing Unit - 
  The Wellcome Trust Sanger Institute
  Tel +44 (0)1223 494817 -  Fax +44 (0)1223 494919 
  http://www.sanger.ac.uk

[Gusdev-gusdev] Re: [Fwd: Re: proposed modifications to GO Schema for GUS3.0]

[Sharon D. <di...@SN...>]

Okay, thanks.   Does this mean that a single comment field added to the 
GOTerm table is sufficient in your view?  

Alternatively, we could use the DoTS.Comments table to store comments, 
these can then be associated through the Evidence table to any row in 
GUS.  So, another option would be to use the Comments table to store the 
text, and link it to the GOTerm entry through the Evidence table.  If 
this is not an appropriate use of the Evidence table, then we could just 
create a GOTermComments linking table.  

cheers,
sharon

Arnaud Kerhornou wrote:

> Hi Sharon
>
> I forward you an example of a GO comment given by Matt.
>
> cheers
> Arnaud
>
> -------- Original Message --------
> Subject: Re: proposed modifications to GO Schema for GUS3.0
> Date: Tue, 16 Jul 2002 13:19:51 +0100
> From: Matt Berriman <mb...@sa...>
> To: Arnaud Kerhornou <ax...@sa...>
> References: 
> <Pin...@sn...> 
> <3D2...@sa...> <3D2...@pc...> 
> <3D2...@sa...> <3D2...@pc...> 
> <3D3...@sa...>
>
>
>
>Here's a complete entry from the GO database:
>
>term: C-terminal protein farnesylation
>
>goid: GO:0006503
>
>definition: The covalent or non-covalent attachment of a farnesyl moiety 
>to the carboxy terminus of a protein. OBSOLETE.
>
>definition_reference: GO:jl
>
>comment: This term was made obsolete because the process is not exclusive to the carboxy terminus 
>of a protein. Consider instead the biological process term 'protein amino acid farnesylation ; 
>GO:0018347'.
>
>cheers
>Matt
>
>
>Arnaud Kerhornou wrote:
>
>> Sharon Diskin wrote:
>>
>>>
>>>> Also re. the GOTerm table, would it be possible to add a comment 
>>>> field ?
>>>
>>>
>>>
>>> I do not have a problem with this.  Does anyone else have an opinion 
>>> on this?  What type of information would you put in the comment field?
>>
>>
>> Matt,
>>
>> Do you have an exa
>mple of comment you want to store ?
>>
>> I should mention than the GO database design allows to store several 
>> comments (one to many relationship), one comment field might be enough 
>> though and would keep the design simple.
>>
>> cheers
>> Arnaud
>>
>>>
>>> Cheers,
>>> Sharon
>>>
>>> p.s.  I will be out of town until Monday July 22nd.
>>>
>>>>
>>>> cheers
>>>> Arnaud
>>>>
>>>> Sharon Diskin wrote:
>>>>
>>>>> Hi Arnaud,
>>>>>
>>>>> I've attached the new GO schema and documentation that Jonathan 
>>>>> Schug and I have come up. We believe that this new schema addresses 
>>>>> your concern about the association date and also provides a better 
>>>>> way of tracking multiple instances/sources of the same association 
>>>>> (s
>ee description of GOAssociationInstance table).
>>>>>
>>>>>
>>>>> Regarding your other question concerning the 'DB:Ref' and 'from or 
>>>>> with', we see these being tracked using the generic Evidence 
>>>>> table.   The 'from or with' would be Evidence for the 
>>>>> GOAssocInstEvidCode entry as it is connected to a specific evidence 
>>>>> code that is assigned to the association.  The 'DB:Ref' (such as in 
>>>>> the PubMed example you mentioned) would be Evidence for the 
>>>>> GOAssociationInstance entry as it is _not_ connected to a specific 
>>>>> evidence code, but rather the association as a whole.  More details 
>>>>> can be found in the attached documentation.
>>>>>
>>>>>
>>>>> Any feedback is welcome.  Also, if any of this is unclear, just let 
>>>>> us know.
>
>>>>>
>>>>> Cheers,
>>>>> Sharon
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
>-- 
>
>  Dr Matthew Berriman 
>  Senior Computer Biologist - Pathogen Sequencing Unit - 
>  The Wellcome Trust Sanger Institute
>  Tel +44 (0)1223 494817 -  Fax +44 (0)1223 494919 
>  http://www.sanger.ac.uk
>-- 
>Arnaud Kerhornou
>
>The Wellcome Trust Sanger Institute
>The Pathogen Sequencing Unit
>Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SA, UK
>Work: +44 (0) 1223 494955
>Fax:  +44 (0) 1223 494919
>
>
>
>
>

[Gusdev-gusdev] CBIL Annotator Interface Req Spec

[Sharon D. <di...@SN...>]

Hi Folks,

I've attached our latest requirements spec for the annotator interface. 
 Notably missing from this document are the details regarding the GUI 
and some specifics for how we envision external tools being run from 
within the interface (such as Blast for example).    We are in the 
process of working out some details in these areas and we would be happy 
to share our thoughts with you if this is something you are interested 
in.   What you will find in this document is a complete list of the 
annotation tasks we plan to include as well as some high level 
requirements that support the annotation tasks.   As Joan mentioned in 
the teleconference, we will likely focus on those tasks termed "surface 
level" as a first pass/version of a new tool.

Cheers,
Sharon 

[Gusdev-gusdev] SRes.Contact

[Angel P. <an...@sn...>]

Could we add a 'contact_type' column to SRes.Contact so that we can
differnetiate between organizations and people? This is basically either
a bit column or enumeration ('person'|'organization') but it makes export
to MAGE (and other object models that differentiate between the two) much
easier.

Angel

[Gusdev-gusdev] sequences

[Angel P. <an...@sn...>]

I added the sequences for Core, SRes and DoTS into the sourceforge.net
CVS.
Basically just relpaced the empty files that were there already. Also
welcome debbie pinney to the sourceforge developer team!

Angel

[Gusdev-gusdev] GUSdev

[Pjm <pj...@sa...>]

Hi Jonathan,

I have attached the PL/SQL scripts to dump everything in the correct order. I 
include what our DBA said on how to run it. Please email me or Martin the DBA 
(md...@sa...) if you have any questions.

Since we need to get started on importing data into GUS we need to use GUSdev. 
The schema we have is not in sync with the website code (remember, we had errors 
because tables did not exist in the GUS import). Could we get a copy of the DB 
and the website code (plus perl layer). I hope this is not asking too much - you 
could test the PL/SQL to see if it works!

thanks,
Paul.


----------------

Its a PL/SQL package that can be installed on any database that it is needed on.

It can be called by a simple script such as :-

--run_cps.sql
--
set serveroutput on size 100000
spool cre_eric.sql
execute schema_copy.cp_schema('ENTMAN','USERS','INDX','ERIC','RED','GUS',128)
spool off

The above eg duplicates the "entman" schema into user "eric" identified by 
"red", using tablespaces "users" and "indx" and defaulting all objects to "128k" 
intitial and next.
The script can be changed to run for multiple users, spool the  various outputs 
and probably kick it off at the end.

----

As a side issue, if you have a fragmented database this code will calculate the 
size of the extents

Re: [Gusdev-gusdev] GUS30 or GUSdev?

[Chris S. <sto...@sn...>]

Paul,
Will try to meet on this Monday and have an answer for our conference
call (I'm out of town today). For mid-September my guess is GUS3.0 but
that's a guess.
Cheers,
Chris

On Thu, 18 Jul 2002, pjm wrote:

> Hi all,
>
> we would like to use GUS30 schema to load data into it and, in a couple
> of weeks time, use the code for the AllGenes website to query that
> data. We are not sure how far along you are porting over the perl
> code, in particular the dbiperl_utils modules and the GA plugins -
> here are the main ones of interest;
>
>     UpdateGUSFromXML.pm (will need XML too for taxon table)
>     LoadGoOntology.pm
>     Swall & EMBL plugins
>     SO - can we use the same plugin as GO or do we need a new one?
>
> We would like to be able to show basic querying by mid-September (for
> the Woods Hole meeting) - the results can just be links to gene pages
> in www.genedb.org for now - but obviously we need to make a start very
> soon.
>
> Should we go with GUSdev or GUS30?
>
> Also the Oracle sequences are not present in Sourceforge, please could you add
> them. Our Oracle DBA has finished the PL/SQL script for exporting everything in
> the correct order, I hope to give you more details tomorrow.
>
> Paul.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>

-- 
Chris Stoeckert, Ph.D.
Research Associate Professor, Dept. of Genetics
Center for Bioinformatics, University of Pennsylvania
418 Guardian Dr., Philadelphia, PA 19104
Ph: 215-573-4409   FAX:215-573-3111

[Gusdev-gusdev] GUS30 or GUSdev?

[pjm <pj...@sa...>]

Hi all,

we would like to use GUS30 schema to load data into it and, in a couple 
of weeks time, use the code for the AllGenes website to query that 
data. We are not sure how far along you are porting over the perl
code, in particular the dbiperl_utils modules and the GA plugins -
here are the main ones of interest;

    UpdateGUSFromXML.pm (will need XML too for taxon table)
    LoadGoOntology.pm
    Swall & EMBL plugins
    SO - can we use the same plugin as GO or do we need a new one?

We would like to be able to show basic querying by mid-September (for 
the Woods Hole meeting) - the results can just be links to gene pages 
in www.genedb.org for now - but obviously we need to make a start very 
soon.

Should we go with GUSdev or GUS30?

Also the Oracle sequences are not present in Sourceforge, please could you add
them. Our Oracle DBA has finished the PL/SQL script for exporting everything in
the correct order, I hope to give you more details tomorrow.

Paul.

[Gusdev-gusdev] [Fwd: Re: proposed modifications to GO Schema for GUS3.0]

[Arnaud K. <ax...@sa...>]

  Hi Sharon

I forward you an example of a GO comment given by Matt.

cheers
Arnaud

-------- Original Message --------
Subject: Re: proposed modifications to GO Schema for GUS3.0
Date: Tue, 16 Jul 2002 13:19:51 +0100
From: Matt Berriman <mb...@sa...>
To: Arnaud Kerhornou <ax...@sa...>
References: 
<Pin...@sn...> 
<3D2...@sa...> <3D2...@pc...> 
<3D2...@sa...> <3D2...@pc...> 
<3D3...@sa...>



Here's a complete entry from the GO database:

term: C-terminal protein farnesylation

goid: GO:0006503

definition: The covalent or non-covalent attachment of a farnesyl moiety 
to the carboxy terminus of a protein. OBSOLETE.

definition_reference: GO:jl

comment: This term was made obsolete because the process is not exclusive to the carboxy terminus 
of a protein. Consider instead the biological process term 'protein amino acid farnesylation ; 
GO:0018347'.

cheers
Matt


Arnaud Kerhornou wrote:

> Sharon Diskin wrote:
>
>>
>>> Also re. the GOTerm table, would it be possible to add a comment 
>>> field ?
>>
>>
>>
>> I do not have a problem with this.  Does anyone else have an opinion 
>> on this?  What type of information would you put in the comment field?
>
>
> Matt,
>
> Do you have an example of comment you want to store ?
>
> I should mention than the GO database design allows to store several 
> comments (one to many relationship), one comment field might be enough 
> though and would keep the design simple.
>
> cheers
> Arnaud
>
>>
>> Cheers,
>> Sharon
>>
>> p.s.  I will be out of town until Monday July 22nd.
>>
>>>
>>> cheers
>>> Arnaud
>>>
>>> Sharon Diskin wrote:
>>>
>>>> Hi Arnaud,
>>>>
>>>> I've attached the new GO schema and documentation that Jonathan 
>>>> Schug and I have come up. We believe that this new schema addresses 
>>>> your concern about the association date and also provides a better 
>>>> way of tracking multiple instances/sources of the same association 
>>>> (see description of GOAssociationInstance table).
>>>>
>>>>
>>>> Regarding your other question concerning the 'DB:Ref' and 'from or 
>>>> with', we see these being tracked using the generic Evidence 
>>>> table.   The 'from or with' would be Evidence for the 
>>>> GOAssocInstEvidCode entry as it is connected to a specific evidence 
>>>> code that is assigned to the association.  The 'DB:Ref' (such as in 
>>>> the PubMed example you mentioned) would be Evidence for the 
>>>> GOAssociationInstance entry as it is _not_ connected to a specific 
>>>> evidence code, but rather the association as a whole.  More details 
>>>> can be found in the attached documentation.
>>>>
>>>>
>>>> Any feedback is welcome.  Also, if any of this is unclear, just let 
>>>> us know.
>>>>
>>>> Cheers,
>>>> Sharon
>>>>
>>>>
>>>
>>
>
>
>

-- 

  Dr Matthew Berriman 
  Senior Computer Biologist - Pathogen Sequencing Unit - 
  The Wellcome Trust Sanger Institute
  Tel +44 (0)1223 494817 -  Fax +44 (0)1223 494919 
  http://www.sanger.ac.uk
-- 
Arnaud Kerhornou

The Wellcome Trust Sanger Institute
The Pathogen Sequencing Unit
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SA, UK
Work: +44 (0) 1223 494955
Fax:  +44 (0) 1223 494919

[Gusdev-gusdev] Re: proposed modifications to GO Schema for GUS3.0

[Arnaud K. <ax...@sa...>]

Sharon Diskin wrote:

>
>> Also re. the GOTerm table, would it be possible to add a comment field ?
>
>
> I do not have a problem with this.  Does anyone else have an opinion 
> on this?  What type of information would you put in the comment field?

Matt,

Do you have an example of comment you want to store ?

I should mention than the GO database design allows to store several 
comments (one to many relationship), one comment field might be enough 
though and would keep the design simple.

cheers
Arnaud

>
> Cheers,
> Sharon
>
> p.s.  I will be out of town until Monday July 22nd.
>
>>
>> cheers
>> Arnaud
>>
>> Sharon Diskin wrote:
>>
>>> Hi Arnaud,
>>>
>>> I've attached the new GO schema and documentation that Jonathan 
>>> Schug and I have come up. We believe that this new schema addresses 
>>> your concern about the association date and also provides a better 
>>> way of tracking multiple instances/sources of the same association 
>>> (see description of GOAssociationInstance table).
>>>
>>>
>>> Regarding your other question concerning the 'DB:Ref' and 'from or 
>>> with', we see these being tracked using the generic Evidence 
>>> table.   The 'from or with' would be Evidence for the 
>>> GOAssocInstEvidCode entry as it is connected to a specific evidence 
>>> code that is assigned to the association.  The 'DB:Ref' (such as in 
>>> the PubMed example you mentioned) would be Evidence for the 
>>> GOAssociationInstance entry as it is _not_ connected to a specific 
>>> evidence code, but rather the association as a whole.  More details 
>>> can be found in the attached documentation.
>>>
>>>
>>> Any feedback is welcome.  Also, if any of this is unclear, just let 
>>> us know.
>>>
>>> Cheers,
>>> Sharon
>>>
>>>
>>
>

[Gusdev-gusdev] Re: proposed modifications to GO Schema for GUS3.0

[Sharon D. <di...@SN...>]

Hi Arnaud,

Thanks for the quick review.  

Arnaud Kerhornou wrote:

> Hi Sharon
>
> I had a discussion with Matt and from our point of view, the design 
> you're proposing sounds sensible.
>
> Just two clarifications about evidences:
>
>    (1) for an evidence attached to a GOAssociationInstance, it can be:
>        *  Similarity data,
>        * a AAMotifGORule,
>        * a DB Reference, stored in an ExternalDBEntry if it's external,
>        * if it's a pubmed_id, we may want to store the whole reference 
> into a reference entry. But I guess it can be done with the schema 
> you're proposing, is that right ?


That is correct.  Since we're using the generic Evidence table, the 
"fact_table" could be any table in GUS.  There are no constraints that 
force you to have all the DB refereneces stored in an ExternalDBEntry.

>
>    (2) for an evidence attached to a GOAssocInstEvidenceCode as it may 
> be an "internal DB link", e.g. a protein_id for example, the DB name 
> prefix will be GeneDB in our case, or if it's a GO_id, it will be GO 
> as a prefix. Will it be generated on the fly ?


I would view this as something generated on the fly.  I suppose for 
external databases (such as GO), we could add an attribute to the 
ExternalDatabase table that represents the "abbreviated name".  This 
abbreviated name could then be used to prefix identifiers.

>
> Also re. the GOTerm table, would it be possible to add a comment field ?

I do not have a problem with this.  Does anyone else have an opinion on 
this?  What type of information would you put in the comment field?

Cheers,
Sharon

p.s.  I will be out of town until Monday July 22nd.



>
> cheers
> Arnaud
>
> Sharon Diskin wrote:
>
>> Hi Arnaud,
>>
>> I've attached the new GO schema and documentation that Jonathan Schug 
>> and I have come up. We believe that this new schema addresses your 
>> concern about the association date and also provides a better way of 
>> tracking multiple instances/sources of the same association (see 
>> description of GOAssociationInstance table).
>>
>>
>> Regarding your other question concerning the 'DB:Ref' and 'from or 
>> with', we see these being tracked using the generic Evidence table.   
>> The 'from or with' would be Evidence for the GOAssocInstEvidCode 
>> entry as it is connected to a specific evidence code that is assigned 
>> to the association.  The 'DB:Ref' (such as in the PubMed example you 
>> mentioned) would be Evidence for the GOAssociationInstance entry as 
>> it is _not_ connected to a specific evidence code, but rather the 
>> association as a whole.  More details can be found in the attached 
>> documentation.
>>
>>
>> Any feedback is welcome.  Also, if any of this is unclear, just let 
>> us know.
>>
>> Cheers,
>> Sharon
>>
>>
>
>
>

[Gusdev-gusdev] Re: proposed modifications to GO Schema for GUS3.0

[Arnaud K. <ax...@sa...>]

Hi Sharon

I had a discussion with Matt and from our point of view, the design 
you're proposing sounds sensible.

Just two clarifications about evidences:

    (1) for an evidence attached to a GOAssociationInstance, it can be:
        *  Similarity data,
        * a AAMotifGORule,
        * a DB Reference, stored in an ExternalDBEntry if it's external,
        * if it's a pubmed_id, we may want to store the whole reference 
into a reference entry. But I guess it can be done with the schema 
you're proposing, is that right ?

    (2) for an evidence attached to a GOAssocInstEvidenceCode as it may 
be an "internal DB link", e.g. a protein_id for example, the DB name 
prefix will be GeneDB in our case, or if it's a GO_id, it will be GO as 
a prefix. Will it be generated on the fly ?

Also re. the GOTerm table, would it be possible to add a comment field ?

cheers
Arnaud

Sharon Diskin wrote:

> Hi Arnaud,
>
> I've attached the new GO schema and documentation that Jonathan Schug 
> and I have come up. We believe that this new schema addresses your 
> concern about the association date and also provides a better way of 
> tracking multiple instances/sources of the same association (see 
> description of GOAssociationInstance table).
>
>
> Regarding your other question concerning the 'DB:Ref' and 'from or 
> with', we see these being tracked using the generic Evidence table.   
> The 'from or with' would be Evidence for the GOAssocInstEvidCode entry 
> as it is connected to a specific evidence code that is assigned to the 
> association.  The 'DB:Ref' (such as in the PubMed example you 
> mentioned) would be Evidence for the GOAssociationInstance entry as it 
> is _not_ connected to a specific evidence code, but rather the 
> association as a whole.  More details can be found in the attached 
> documentation.
>
>
> Any feedback is welcome.  Also, if any of this is unclear, just let us 
> know.
>
> Cheers,
> Sharon
>
>

[Gusdev-gusdev] Protein properties and protein features in GUS

[Arnaud K. <ax...@sa...>]

  Hi everyone

I would like to report a new table, ProteinProperty and new views on the 
top of AAFeatureImp table for protein features such as domains.

* Protein properties :

There are 4 protein properties :
   * Isoelectric point (1),
   * Molecular mass (2),
   * Charge (3),
   * Average residue mass (4).

The 3 first ones may have several values as they can be characterized 
experimentally.

 From a design point of view, we can have a unique ProteinProperty table 
or a view foreach proterty (a ProteinPropertyImp table and three views: 
IsoElectricPointProperty, MolecularMassProperty and ChargeProperty).
The number of properties may not changed in the future so I may be 
simpler to create a unique ProteinProperty table.

Specification => A property would behave like a feature, ie :
   * it is attached to a sequence modulo the fact it doesn't have a 
location within it,
   * it can be supported by evidences such as an experiment, published 
or from a personal communication.
   * have external db refs.

ProteinProperty table:
   * protein_property_id : number
   * property_name : varchar2(50)
   * property_value : number (5)
   * & stuff common to any GUS table: modification_date ...

The 4th property, average residue mass, could be an extra attribute in 
the proteinSequence or TranslatedAASequence view.

******************
* Protein Features :

Features attached to a protein sequence.

The new features objects are:
    (1) Signal Peptide Feature :
It's already a view in GUS, but we will store curated data, such as 
targetting information.

    (2) Domains:
It can be:
    * a Leucine Zipper domain,
    * a coiled-coil domain,
    * a Pfam, Smart or Prosite domain.

DomainFeature view:
    * aa_feature_id : number (10),
    * aa_sequence_id : number (10),
    * name : varchar2 (50),
    * description : varchar2 (100),
    * score : number (4)
    * e_value : number (10),
+ external database link entries and a location object.

    (3) Transmenbrane domain feature:
Question : PlasmoDB web site shows hydrophobicity graphics, where is it 
stored in GUS ?

    (4) Post-translational modification feature:
    * type : varchar2 (50) (e.g. glycosylation, phosphorylation ...)
    * modified_by : use of the Interaction table ?
    * Coordinates of the phosphorylation site in a AALocation object.
 
    (5) Repeat Features, should be the same design that at the DNA level :
        * RepeatRegionFeature as a set of RepeatUnitFeatures,
        * RepeatUnitFeature, with the consensus sequence, name and size
        * RepeatType table

Another question : What about 2D structures (beta-sheet and 
alpha-helice) in GUS ?

Let me know if you have any comments. I'll send another email for extra 
features at the DNA/RNA level.

Cheers
Arnaud

Re: [Gusdev-gusdev] schemas

[Arnaud K. <ax...@sa...>]

Hi Chris

Sounds good. See below for some comments.

Chris Stoeckert wrote:

> Hi All,
> Here are the phenotype tables I mentioned during the conference call. 
> I still need to look at the rest of the schema to see how best to link 
> it to gene sequences but welcome suggestions.


We would use it to annotate alleles. I guess a new table is needed with 
the allele name, the degree of dominance, mutation data, complementation 
data ...

>
> Also, Angel has posted a picture of a proposed schema for capturing 
> mass spec data at:  
> http://www.cbil.upenn.edu/downloads/Proteomics/schema/
> Next steps are to have people look it over and try to fit available 
> data into it.
>
> Finally, I will write up my notes of our conference call and send to 
> Marie-Adele to edit and pass around (if she agrees ;-) ).
>
> Cheers,
> Chris
>
> Phenotype: A linking table in the spirit of GOBO or PATO constructing 
> phenotypic descriptions from orthogonal ontologies using nounal phrases.
> phenotype_id
> pato_attribute_id
> anatomy_id
> cell_type_id        can point to the Anatomy table
> dev_stage_id
> description    varchar 255    text description of what the terms 
> represent in aggregate


At the moment, as pombe, Trypanosoma and Leish are unicellular, the 
orthologous ontologies we would use are GO process and GO component, as 
well as the Parasite life cycle ontology being developed here by Mat. 
Berriman.

>
> PATOAttribute: A
> pato_attribute_id
> term_name    varchar255
> term_synonym    varchar 255
> version        varchar 50
> parent_pato_attribute_id       term_type    varchar 20    "attribute", 
> "attribute value"

So to summarize a phenotype is made from a set of ontology terms, there 
is a many to many relationship between each of these orthogonal 
ontologies and the Phenotype table. It also has a set of attributes, and 
each attribute is associated to a set of attribute values.

cheers
Arnaud


Note this is based on Michael Ashburner's draft.
----------
On the representation of phenotypic data in genome databases - 
pato.ontology.

A discussion paper.

Version 2.0 22 February 2002.

Michael Ashburner, FlyBase.

pato: phenotype & trait ontology.

This paper assumes some knowledge of the work of the Gene Ontology
Consortium - see www.geneontology.org.

A major conceptual and practical problem that faces all genomic 
databases is
how to describe mutant phenotypes (I include in this term epigenetic 
phenotype
due to RNAi, for example, and the more general class of traits, in the 
sense
this word is used by plant and animal breeders).  Some databases are, I 
know,
struggling to find a solution to this problem, these include FlyBase, 
Gramene,
the Mouse Genome Database, and others.  Traditionally, phenotypes have been
described as free text, for example in some FlyBase tables and in the Mouse
Locus Catalog.  This is great, but is obviously a poor solution if the 
data are
to be efficiently analysed (e.g. by a search engine) computationally.  I 
am not
wholly convinced that we can ever get away from free text, at the very 
least as
a "gloss" on a more systematic representation of these data. 
Nevertheless, the
effort to represent these data systematically is very much worth while, 
and is
again - I maintain - an effort that it is far better we do collaboratively,
arriving at common standards, that independently.  If this works it also
has the consequence that rigorous queries across databases could be made
(as now with GO).

The core of my proposal is that phenotypic data can be represented as
qualifications of descriptive nouns or nounal phrases.  A typical 
descriptive
noun would be "eye" or "leaf" or "wing development".  For each class of 
such
nouns there will be a finite (I hope) set of relevant attributes. For these
examples attributes could include: shape, color, size; for "leaf" they 
could
include: thickness, pilosity, for "wing development" they could include
"abnormal". For each attribute there will be a finite (I hope) set of 
values.
For the attribute color, for example, values would include: black, 
white, green.
For each value there will be a finite (I hope) set of qualifiers, for green
these may include dark, light.

Using these three semantic classes we have, I think, the basis for the
systematic  description of phenotypes.  The only extra need is to be 
able to
describe the assay by means of which the phenotypes (i.e. values) were
determined  and the conditions, both environmental and genetic, under 
which the
assay was  performed.  I will not consider assays and their conditions 
in this
paper, since these are very much a concern of the MGED group and we 
should share their work (see www.mged.org).

I see pato as being used to annotate (a) alleles and (b) "strains" or 
"lines"
of an organism (e.g. for crop plants or posssibly mouse strains).

I should say that I do not regard pato as the place for what (albeit 
loosely)
we normally consider as attributes of alleles: e.g recessive, dominant,
cold-sensitive, although pato should be designed to store phenotypic 
data that
is conditional on an environmental condition (or background genotype).

I am also aware that keeping pato in a flat file may be a challenge and 
that a
more sophistical mechanism (?DAML+oil) may be needed.

The purpose of sending this out at this preliminary stage is to get
feedback, both at the conceptual and detailed levels.

I thank John Walshaw, Suzi Lewis, Pankaj Jaiswal, Judy Blake and my 
Cambridge
FlyBase curators (Rachel Drysdale, Gillian Milburn, Chihiro Yamada and 
Aubrey
de Grey) for input & ideas. I have made _no_ attempt to make 
pato.ontology v.1.0
anything like complete - especially with respect to attribute values.

We are experimenting now with re-casting some FlyBase annotation using
pato.ontology, and will report. Please feel free to redistribute this to 
anyone
who might give feedback. Distribution list at end of this file. If you 
never
want to be bothered my me again, send me an email to that effect.

Michael.



The nouns/nounal phrases.
-------------------------

These will be terms from an orthogonal ontology, for example the GO
biological_process ontology, the GO cellular_component ontology or a 
species
specific anatomy ontology (see go/anatomy for the Drosophila and 
Arabidopsis
anatomy ontologies; mouse, worm and Monocot anatomies are on their way).

The attributes.
---------------

The hardest job will be to make a classification of attributes.  A very 
first
step is given below.  We will then need a syntax for declaring for which
nouns/nounal phrases a particular attribute (and its child attributes) 
can be
used.  For exampe attributes of size are of obviously relevant to 
anatomical
structures, but not to a process such as "flight behavior".

Their values.
-------------

The second task is to determine the list of values any attribute may 
have.  I
have shown a few of these in pato.ontology.

Their qualifiers.
-----------------

Finally, we would need to determine the qualifiers that are relevant 
(allowed)
for any particular attribute.  Thus the qualifie fully would be relevant 
to a
fertility attribute, but not to an attribute of size.

I present first a "schema" of the relationships between these concepts:

                                            !antonym             !antonym
                                                |                    |
                                            {mayhave}              {has}
                                                |                    |
concept <-{usedfor}--%attribute ---{has}---> <value ---{has}---> .qualifier
                                           |       |
                                  {determinedby} | {mayhave}
                                         |          |
                                         |          units
                                         |
                                        assay ---{constrainedby}---> 
conditions ---{oftype}---> [MGED]environmental&|genetic


attribute|value|qualifier ---{have}---> synonyms.

concept is a concept (term) from another (orthogonal) ontology.

In the draft pato.ontology: % is for attributes, < is for values of 
attributes

[Gusdev-gusdev] schemas

[Chris S. <sto...@SN...>]

Hi All,
Here are the phenotype tables I mentioned during the conference call. I=20=

still need to look at the rest of the schema to see how best to link it=20=

to gene sequences but welcome suggestions.

Also, Angel has posted a picture of a proposed schema for capturing mass=20=

spec data at:  http://www.cbil.upenn.edu/downloads/Proteomics/schema/
Next steps are to have people look it over and try to fit available data=20=

into it.

Finally, I will write up my notes of our conference call and send to=20
Marie-Adele to edit and pass around (if she agrees ;-) ).

Cheers,
Chris

Phenotype: A linking table in the spirit of GOBO or PATO constructing=20
phenotypic descriptions from orthogonal ontologies using nounal phrases.
phenotype_id
pato_attribute_id
anatomy_id
cell_type_id		can point to the Anatomy table
dev_stage_id
description	varchar 255	text description of what the terms =
represent=20
in aggregate

PATOAttribute: A
pato_attribute_id
term_name	varchar255
term_synonym	varchar 255
version		varchar 50
parent_pato_attribute_id	=09
term_type	varchar 20	"attribute", "attribute value"

Note this is based on Michael Ashburner's draft.
----------
On the representation of phenotypic data in genome databases -=20
pato.ontology.

A discussion paper.

Version 2.0 22 February 2002.

Michael Ashburner, FlyBase.

pato: phenotype & trait ontology.

This paper assumes some knowledge of the work of the Gene Ontology
Consortium - see www.geneontology.org.

A major conceptual and practical problem that faces all genomic=20
databases is
how to describe mutant phenotypes (I include in this term epigenetic=20
phenotype
due to RNAi, for example, and the more general class of traits, in the=20=

sense
this word is used by plant and animal breeders).  Some databases are, I=20=

know,
struggling to find a solution to this problem, these include FlyBase,=20
Gramene,
the Mouse Genome Database, and others.  Traditionally, phenotypes have=20=

been
described as free text, for example in some FlyBase tables and in the=20
Mouse
Locus Catalog.  This is great, but is obviously a poor solution if the=20=

data are
to be efficiently analysed (e.g. by a search engine) computationally.  I=20=

am not
wholly convinced that we can ever get away from free text, at the very=20=

least as
a "gloss" on a more systematic representation of these data.=20
Nevertheless, the
effort to represent these data systematically is very much worth while,=20=

and is
again - I maintain - an effort that it is far better we do=20
collaboratively,
arriving at common standards, that independently.  If this works it also
has the consequence that rigorous queries across databases could be made
(as now with GO).

The core of my proposal is that phenotypic data can be represented as
qualifications of descriptive nouns or nounal phrases.  A typical=20
descriptive
noun would be "eye" or "leaf" or "wing development".  For each class of=20=

such
nouns there will be a finite (I hope) set of relevant attributes. For=20
these
examples attributes could include: shape, color, size; for "leaf" they=20=

could
include: thickness, pilosity, for "wing development" they could include
"abnormal". For each attribute there will be a finite (I hope) set of=20
values.
For the attribute color, for example, values would include: black,=20
white, green.
For each value there will be a finite (I hope) set of qualifiers, for=20
green
these may include dark, light.

Using these three semantic classes we have, I think, the basis for the
systematic  description of phenotypes.  The only extra need is to be=20
able to
describe the assay by means of which the phenotypes (i.e. values) were
determined  and the conditions, both environmental and genetic, under=20
which the
assay was  performed.  I will not consider assays and their conditions=20=

in this
paper, since these are very much a concern of the MGED group and we=20
should share their work (see www.mged.org).

I see pato as being used to annotate (a) alleles and (b) "strains" or=20
"lines"
of an organism (e.g. for crop plants or posssibly mouse strains).

I should say that I do not regard pato as the place for what (albeit=20
loosely)
we normally consider as attributes of alleles: e.g recessive, dominant,
cold-sensitive, although pato should be designed to store phenotypic=20
data that
is conditional on an environmental condition (or background genotype).

I am also aware that keeping pato in a flat file may be a challenge and=20=

that a
more sophistical mechanism (?DAML+oil) may be needed.

The purpose of sending this out at this preliminary stage is to get
feedback, both at the conceptual and detailed levels.

I thank John Walshaw, Suzi Lewis, Pankaj Jaiswal, Judy Blake and my=20
Cambridge
FlyBase curators (Rachel Drysdale, Gillian Milburn, Chihiro Yamada and=20=

Aubrey
de Grey) for input & ideas. I have made _no_ attempt to make=20
pato.ontology v.1.0
anything like complete - especially with respect to attribute values.

We are experimenting now with re-casting some FlyBase annotation using
pato.ontology, and will report. Please feel free to redistribute this to=20=

anyone
who might give feedback. Distribution list at end of this file. If you=20=

never
want to be bothered my me again, send me an email to that effect.

Michael.



The nouns/nounal phrases.
-------------------------

These will be terms from an orthogonal ontology, for example the GO
biological_process ontology, the GO cellular_component ontology or a=20
species
specific anatomy ontology (see go/anatomy for the Drosophila and=20
Arabidopsis
anatomy ontologies; mouse, worm and Monocot anatomies are on their way).

The attributes.
---------------

The hardest job will be to make a classification of attributes.  A very=20=

first
step is given below.  We will then need a syntax for declaring for which
nouns/nounal phrases a particular attribute (and its child attributes)=20=

can be
used.  For exampe attributes of size are of obviously relevant to=20
anatomical
structures, but not to a process such as "flight behavior".

Their values.
-------------

The second task is to determine the list of values any attribute may=20
have.  I
have shown a few of these in pato.ontology.

Their qualifiers.
-----------------

Finally, we would need to determine the qualifiers that are relevant=20
(allowed)
for any particular attribute.  Thus the qualifie fully would be relevant=20=

to a
fertility attribute, but not to an attribute of size.

I present first a "schema" of the relationships between these concepts:

                                             !antonym             =
!antonym
                                                 |                    |
                                             {mayhave}              =
{has}
                                                 |                    |
concept <-{usedfor}--%attribute ---{has}---> <value ---{has}--->=20
.qualifier
                           		         |       |
                                   {determinedby} | {mayhave}
                                          |          |
                                          |          units
                                          |
                                         assay ---{constrainedby}--->=20
conditions ---{oftype}---> [MGED]environmental&|genetic


attribute|value|qualifier ---{have}---> synonyms.

concept is a concept (term) from another (orthogonal) ontology.

In the draft pato.ontology: % is for attributes, < is for values of=20
attributes

##

FlyBase: Bill Gelbart <ge...@mo...>
FlyBase: Suzanna Lewis <su...@fr...>
FlyBase: Chris Mungal <cj...@bd...>
Mouse GI: Judy Blake <jb...@in...>
Mouse: Jonathan Bard <J....@ed...>
German Mouse ENU project: Martin Hrab=C8 de Angelis <hr...@gs...>
MRC ENU project: Steve Brown <br...@ha...>
Baylor ENU: Monica Justise <mju...@bc...>
SGD: Mike Cherry <ch...@ge...>
Arabidopsis: Sue Rhee <rh...@ac...>
WormDB: Erich Schwarz <em...@it...>
Andrzej Kilian <a.k...@ca...>
Everything: Lincoln Stein <ls...@cs...>
S. pombe: John Walshaw <jo...@bi...>
Gramene: Susan McCouch <sr...@co...>
Gramene: Pankaj Jaiswal <pj...@co...>
Rice: Richard Bruskiewich <R.B...@CG...>
MaizeDB: Vincent Leszek <Le...@mi...>
RatBase: Simon Twigger <si...@mc...>
London Dysmorphology DB: R.M. Winter <rw...@ic...>
Zebra: Pat Edwards <ed...@uo...>
Zebra: Mont Westerfield <mo...@uo...>
MGED: Chris Stoeckert <sto...@SN...>
MGED: Helen Parkinson <par...@eb...>
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: pato.ontology
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 170

!date:                 Fri Feb 22 2002
!version: $Revision: 1.0 $
$pato_attribute_ontology
  %quantitative_attribute
  %qualitative_attribute
   <normal
   <abnormal ; synonym:defective
   %specific_qualitative_attribute
    %sensitivity_attribute
     <sensitive
     <insensitive ; synonym:resistant
     <tolerant
     <intolerant
     <responsive
     <unresponsive
     %photosensitivity_attribute
      <photosensitive
      <photoinsensitive ; synonym:photoresistant
     %thermosensitivity_attribute
      <thermosensitive
      <thermoinsensitive ; synonym:thermoresistant
     %chemical_sensitivity_attribute
      %drug sensitivity_attribute
       <drug sensitive
       <drug insensitive ; synonym:drug resistant
    %odor_attribute
    %flavor_attribute
    %color_attribute
     %color_hue_attribute
      <white ; synonym:#FFFFFF
      <black ; synonym:#000000
      <red ; synonym:#FF0000
      <green ; synonym:#00FF00
      <blue ; synonym:#0000FF
      <yellow ; synonym:#FFFF00
      <cyan ; synonym:#00FFFF
      <magenta ; synonym:#FF00FF
     %color_intensity_attribute
      <bright
      <dim
     %color_saturation_attribute
      <pale
      <dark
     %other_color_attribute
       <spotted
       <variegated ; synonym:mottled (sensu Drosophila)
       <blotchy
       <irregular
       <discolored
       <pigmented
       <unpigmented
    %aspect_of_mass_attribute
     %size_attribute
      %absolute_size_attribute
      %relative_size_attribute
       <large ; synonym:enlarged ; synonym:big ; synonym:great
       <small ; synonym:tiny
       <vestigial
      %mass_attribute
       %absolute_mass_attribute
       %relative_mass_attribute
        <large
        <small
       %weight_attribute
        <heavy
        <light
      %height_attribute
      %thickness_attribute
       <thick
       <thin
      %width_attribute
       <wide
       <narrow
      %volume_attribute
    %texture_attribute
     <smooth
     <rough
    %pilosity_attribute
     <hairy
     <glabrous
     <pubescent
    %activity_attribute
     <hypoactive
     <hyperactive
     <impaired
     <coordinated
     <uncoordinated
     <paralysed
     <bang sensitive
     %speed_attribute
      <fast
      <slow
    %spatial_attribute
     %placement_attribute ; synonym:positional_attribute
      <misplaced
      <localised
      <unlocalised
      <exserted
      <inserted
     %closure_attribute
      <open
      <closed ; synonym:blocked
     %angle_attribute
      <acute
      <obtuse
    %morphological_attribute
     %shape_attribute
      <round
      <square
      <oblate
      <pinnate
      <branched
      <unbranched
      <cleft
    %temperature_attribute
     %absolute_temperature_attribute
     %relative_temperature_attribute
      <hot
      <cold
    %temporal_attribute ; synonym:event_attribute
     %absolute_temporal_attribute
     %relative_temporal_attribute
      <early ; synonym:premature
      <late ; synonym:retarded
      <arrested
      <continuous
      <discontinuous
    %yield_attribute
     <low yield
     <high yield
    %compositional_attribute
     %metabolite_compositional_attribute
     %electrolyte_compositional_attribute
     %macromolecular_compositional_attribute
      %enzyme_compositional_attribute
    %nutritional_attribute
     <auxotroph
     <prototroph
    %life_span__attribute
    %viability_attribute
     <viable
     <lethal
    %fertility_attribute
     %male_fertility_attribute
      <male fertile
      <male infertile ; synonym:male sterile
     %female_fertility_attribute
      <female fertile
      <female infertile ; synonym:female sterile
     %hybrid_fertility_attribute
      %F1_fertility_attribute
       <F1 fertile
       <F1 infertile ; synonym:F1 sterile
      %F2_fertility_attribute
       <F2 fertile
       <F2 infertile ; synonym:F2 sterile
      %backcross_fertility_attribute
       <backcross fertile
       <backcross infertile ; synonym:backcross sterile
      %intercross_fertility_attribute
       <intercross fertile
       <intercross infertile ; synonym:intercross sterile
      %cytoplasmic_infertility_attribute
      %germ_line_dependent_fertility_attribute
      %soma_dependent_fertility_attribute
    %compatability_attribute
     <compatible
     <incompatible
      %gametophytic_compatability_attribute
      %sporphytic_compatability_attribute

Re: [Gusdev-gusdev] CVS

[Pjm <pj...@sa...>]

Steve,

I have just talked to James Cuff (ja...@sa...).
Because the ssh accounts will be very restrictive (you can't cd out of your home 
dir) you will not be able to change files in the repository.

The Ensembl people who share this system also can not get to the repository. All 
requests have to go through James and his team: ss...@sa.... As long as 
the requests don't come thick and fast he is quite happy to make changes for us. 
Is this a deal breaker?

As for service levels, the policy for all Sanger systems is "best efforts" - no 
SLA's exist here. Now I have said that, the service from all sys admins here is 
excellent and they are quite prepared to fix things at 1am on a Saturday morning 
if things go wrong (they have good financial incentives plus time of work to do 
this :)

I can understand any misgivings you may have over what I have described so 
please discuss with your team and let me know what your thoughts are.

Paul.

Steve Fischer wrote:
> jonathan crabtree      cra...@pc..., 215 573-3115
> steve fischer             sfi...@pc..., 215 573-2280
> deborah pinney      pi...@pc... 215 573-3116
> chris stoeckert       sto...@pc...  215 573-4409
> jonathan schug       js...@pc...  215-573-3113
> angel pizarro           an...@pc...  215 573-3114
> 
> 
> 
> Pjm wrote:
> 
>>
>> The following users have been created in the external repos.
>>
>> > pjm
>> > kmr
>> > axk
>> > art
>> > adh
>> > ejz
>>
>> I did request the following but the sys admins would like names and 
>> contact info before creating them. Please send this info to me. If you 
>> would like to change users name let me know. Also anyone not on this 
>> list please let me know your user name, name and contact details. I 
>> will tell you know your passwords via the conference call tomorrow.
>>
>> > crabtree
>> > fischer
>> > pinney
>> > stoeckrt
>> > schug
>>
>> Paul.
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Gusdev-gusdev mailing list
>> Gus...@li...
>> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>>
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
> 

Re: [Gusdev-gusdev] dependencies

[Chris S. <sto...@SN...>]

> Hi,
>
> am I right in thinking the only dependencies are from DOTS to CORE, 
> SRES to CORE
> etc, so they are one way? I ask because we would like scripts to 
> recreate the
> schema in a new instance but this depends on no inter dependencies.

Hi Paul,
Yes, I believe. Core should be created first, then SRes, then RAD and 
DoTS (I don't see any dependencies between DoTS and RAD in the current 
GUS3.0).

Chris

Re: [Gusdev-gusdev] CVS

[Steve F. <st...@SN...>]

jonathan crabtree      cra...@pc..., 215 573-3115
steve fischer             sfi...@pc..., 215 573-2280
deborah pinney      pi...@pc... 215 573-3116
chris stoeckert       sto...@pc...  215 573-4409
jonathan schug       js...@pc...  215-573-3113
angel pizarro           an...@pc...  215 573-3114
 


Pjm wrote:

>
> The following users have been created in the external repos.
>
> > pjm
> > kmr
> > axk
> > art
> > adh
> > ejz
>
> I did request the following but the sys admins would like names and 
> contact info before creating them. Please send this info to me. If you 
> would like to change users name let me know. Also anyone not on this 
> list please let me know your user name, name and contact details. I 
> will tell you know your passwords via the conference call tomorrow.
>
> > crabtree
> > fischer
> > pinney
> > stoeckrt
> > schug
>
> Paul.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>
>

[Gusdev-gusdev] CVS

[Pjm <pj...@sa...>]

The following users have been created in the external repos.

 > pjm
 > kmr
 > axk
 > art
 > adh
 > ejz

I did request the following but the sys admins would like names and contact info 
before creating them. Please send this info to me. If you would like to change 
users name let me know. Also anyone not on this list please let me know your 
user name, name and contact details. I will tell you know your passwords via the 
conference call tomorrow.

 > crabtree
 > fischer
 > pinney
 > stoeckrt
 > schug

Paul.

[Gusdev-gusdev] dependencies

[Pjm <pj...@sa...>]

Hi,

am I right in thinking the only dependencies are from DOTS to CORE, SRES to CORE 
etc, so they are one way? I ask because we would like scripts to recreate the 
schema in a new instance but this depends on no inter dependencies.

Our DB is confident he can have a script(s) to recreate the schemas because he 
has code that already does this for other DBs (Oracle 9 does something like this 
he thinks as standard). Thinking further down the line this would be nice for 
running unit tests over night, starting with a fresh DB for each test or set of 
tests. I have done this sort of thing in a previous life and it's very useful.

The current files in cvs need to be updated though but we shall discuss in the 
conference call tomorrow.

Paul.

[Gusdev-gusdev] Database stuff again

[pjm <pj...@sa...>]

Morning, 

I have done 2 inserts into DATABASEINFO, with primary keys of 5 and 6. Not sure
why 2 DBs referenced from the core.TableInfo records. These are needed in the
core-tableinfo file.

Also the order in the core-tableinfo records: The tables have to be inserted
first, then the views. As an example 'AAFeature' is defined before
'AAFeatureImp' but the TABLEINFO record for it says it is a view on
'AAFeatureImp' (thus failing constraint CORE.TABLEINFO_FK02). Maybe I should
have loaded the bootstrap stuff before loading the constraints but I just ran it
twice and excepted the error messages.

Paul.

[Gusdev-gusdev] constraints

[pjm <pj...@sa...>]

Not sure if I sent this earlier, apologies if I have....

the constraints given in the CVS files are listed in alabetical order which
means I keep rerunning the file till it works - it tries to create foreign keys
to not yet existing primary keys. For Oracle 8 you can dump;

	primary keys
	unique contraints
	foreign keys

in that order. In Oracle 9 we think a fancy feature exists that works out the
correct order for you or just does the above.

Re: [Gusdev-gusdev] instance v's schemas

[<cra...@SN...>]

Paul-

> we have always had a serate instance for testing and development in production
> software - quite handy when some dodgy SQL brings the server to its knees. The
> only thing in the code that changes is the connection to the DB itself, nothing
> else. Does Oracle run on just the one machine?

Right, so we could certainly solve the naming problem by requiring that people
who want a second copy of the database set up a different Oracle instance for
it.  And if it doesn't pose an immediate problem for you I'd propose that we
just not worry about the naming question for the time being.

We also have two Oracle instances, one for production and one for development,
running on two separate machines.  However, I was thinking that we might at some
point want to have two copies of GUS 3.0 on the development machine (and perhaps
this is simply not the case.)  We only run one Oracle instance on the development
machine because there's not much point in having two; we have few enough physical
disks that any dodgy SQL on the one instance would most likely affect the other
one too.  I also wanted to keep things as simple as possible in terms of
administration.

> We have scripts to dump data (all or a subset) from the live DB into the test
> one so we have working real data.
> 
> As for getting the schema into our instance, I am attempting to write a script
> that will run as each user to create the nessacery tables and log what happened.
> I have also come accross 2 buglets;

Sounds great!

> the *-indexes.sql just contain line returns or white space, not actual code.

OK, I'm sure Debbie is already looking into this.

> I added this line to core-tableinfo.sql;
>         alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';
> Oracle 8 & 9 have a default date field of 'DD--MON-RR' I believe.

That's my fault, sorry.  We use a nonstandard default date format because I found 
the Oracle default too annoying when we were switching from Sybase to Oracle 8i.

Jonathan

-- 
Jonathan Crabtree
Center for Bioinformatics, University of Pennsylvania
1406 Blockley Hall, 423 Guardian Drive Philadelphia, PA 19104-6021
215-573-3115