[Gmod-phendiver] Anyone had any luck loading GAZ->Chado cv tables?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[Gmod-phendiver] Anyone had any luck loading GAZ->Chado cv tables?

Bob MacCallum
As you are probably all aware, GAZ is a big ontology.

As far as we are aware, this is the only source for it:
http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo

It contains a lot of formatting errors, which we once corrected
manually then converted to Chado XML and loaded via stag-storenode.pl
- that loading process took more than 5 days.

Recently I've tried fixing as many errors as possible with Perl
one-liners and making a few mods to Bio/OntologyIO/obo.pm
so that it handles quoted commas better and skips dodgy xrefs - so
that I can load it with gmod_load_cvterms.pl
(which I believe is preferable to stag-storenode if we want to
regularly re-load/update the ontology).

Trouble is, once all the terms are loaded (several hours), the
relationships are taking many many days (still not finished), while it
outputs this kind of thing:

Retrieved accession: 00307773
Looking at relationship in file: 00307773-00022850
Looking at relationship in file: 00307773-00022845
Retrieved accession: 00284751
Looking at relationship in file: 00284751-00283672
Retrieved accession: 00255061
Looking at relationship in file: 00255061-00007146

Before we go looking at optimising the code or other tricks, I
wondered if anyone else had solved this problem?

Then, of course, it would be nice to have cvtermpath populated but we
noticed circular references when we half-heartedly tried this last.

As far as I can tell, Gramene seems to be the only site with GAZ on
board.  I'll make contact with them but I don't think they have Chado
under the hood.

many thanks,
Bob.

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] Anyone had any luck loading GAZ->Chado cv tables?

Bob MacCallum
Hi,

Just a bit of an update on this.

The GAZ maintainers have fixed the syntax errors and circular
references, and the "ontology" is now on bioportal (minus full tree
browsing).

I forgot to mention that two hacks are needed to load the ontology into Chado

1. table cvterm constraint cvterm_c1: either remove constraint on name
or add an extra one on dbxref_id (we have gone for the latter, thanks
to Dave Emmert's suggestion).  This because there are several terms
with the same name, e.g. London.  So far we have not identified any
downstream problems, but other sites should test before this goes into
the trunk.

2. table dbxref column accession: extend to varchar(1024) to handle
some crazy long URLs purporting to be accessions.

Although it takes a while, conversion to Chado XML (4.2 days) and
loading with stag-storenode.pl (3.5h) seems to be working for us.  The
latter can handle updates also.


I guess we should try cvtermpath at some point - I imagine this will
take a while...

cheers,
Bob.


On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
<[hidden email]> wrote:

> As you are probably all aware, GAZ is a big ontology.
>
> As far as we are aware, this is the only source for it:
> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>
> It contains a lot of formatting errors, which we once corrected
> manually then converted to Chado XML and loaded via stag-storenode.pl
> - that loading process took more than 5 days.
>
> Recently I've tried fixing as many errors as possible with Perl
> one-liners and making a few mods to Bio/OntologyIO/obo.pm
> so that it handles quoted commas better and skips dodgy xrefs - so
> that I can load it with gmod_load_cvterms.pl
> (which I believe is preferable to stag-storenode if we want to
> regularly re-load/update the ontology).
>
> Trouble is, once all the terms are loaded (several hours), the
> relationships are taking many many days (still not finished), while it
> outputs this kind of thing:
>
> Retrieved accession: 00307773
> Looking at relationship in file: 00307773-00022850
> Looking at relationship in file: 00307773-00022845
> Retrieved accession: 00284751
> Looking at relationship in file: 00284751-00283672
> Retrieved accession: 00255061
> Looking at relationship in file: 00255061-00007146
>
> Before we go looking at optimising the code or other tricks, I
> wondered if anyone else had solved this problem?
>
> Then, of course, it would be nice to have cvtermpath populated but we
> noticed circular references when we half-heartedly tried this last.
>
> As far as I can tell, Gramene seems to be the only site with GAZ on
> board.  I'll make contact with them but I don't think they have Chado
> under the hood.
>
> many thanks,
> Bob.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] Anyone had any luck loading GAZ->Chado cv tables?

Naama Menda
hi Bob,

let me know when you try cvtermpath. 
We've been using it at SGN to make recursive querying much faster. I added a loading scripts to the gmod SVN (http://gmod.svn.sourceforge.net/viewvc/gmod/schema/trunk/chado/bin/gmod_make_cvtermpath.pl?view=log)

I'd like to see how other databases use the cvtermpath, since we occasionally encounter issues with the way we use it.

also let me know if you get errors with gmod_load_cvterms.pl, or if it fails due to errors in the obo file. Maybe such  can be checked before it starts to load the relationships

thanks!
-Naama

 
Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA

(607) 254 3569
Sol Genomics Network
http://solgenomics.net/
[hidden email]


On Wed, Mar 28, 2012 at 9:21 AM, Bob MacCallum <[hidden email]> wrote:
Hi,

Just a bit of an update on this.

The GAZ maintainers have fixed the syntax errors and circular
references, and the "ontology" is now on bioportal (minus full tree
browsing).

I forgot to mention that two hacks are needed to load the ontology into Chado

1. table cvterm constraint cvterm_c1: either remove constraint on name
or add an extra one on dbxref_id (we have gone for the latter, thanks
to Dave Emmert's suggestion).  This because there are several terms
with the same name, e.g. London.  So far we have not identified any
downstream problems, but other sites should test before this goes into
the trunk.

2. table dbxref column accession: extend to varchar(1024) to handle
some crazy long URLs purporting to be accessions.

Although it takes a while, conversion to Chado XML (4.2 days) and
loading with stag-storenode.pl (3.5h) seems to be working for us.  The
latter can handle updates also.


I guess we should try cvtermpath at some point - I imagine this will
take a while...

cheers,
Bob.


On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
<[hidden email]> wrote:
> As you are probably all aware, GAZ is a big ontology.
>
> As far as we are aware, this is the only source for it:
> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>
> It contains a lot of formatting errors, which we once corrected
> manually then converted to Chado XML and loaded via stag-storenode.pl
> - that loading process took more than 5 days.
>
> Recently I've tried fixing as many errors as possible with Perl
> one-liners and making a few mods to Bio/OntologyIO/obo.pm
> so that it handles quoted commas better and skips dodgy xrefs - so
> that I can load it with gmod_load_cvterms.pl
> (which I believe is preferable to stag-storenode if we want to
> regularly re-load/update the ontology).
>
> Trouble is, once all the terms are loaded (several hours), the
> relationships are taking many many days (still not finished), while it
> outputs this kind of thing:
>
> Retrieved accession: 00307773
> Looking at relationship in file: 00307773-00022850
> Looking at relationship in file: 00307773-00022845
> Retrieved accession: 00284751
> Looking at relationship in file: 00284751-00283672
> Retrieved accession: 00255061
> Looking at relationship in file: 00255061-00007146
>
> Before we go looking at optimising the code or other tricks, I
> wondered if anyone else had solved this problem?
>
> Then, of course, it would be nice to have cvtermpath populated but we
> noticed circular references when we half-heartedly tried this last.
>
> As far as I can tell, Gramene seems to be the only site with GAZ on
> board.  I'll make contact with them but I don't think they have Chado
> under the hood.
>
> many thanks,
> Bob.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] Anyone had any luck loading GAZ->Chado cv tables?

Scott Cain
In reply to this post by Bob MacCallum
Hi Bob,

So to get GAZ to load, you extended the name constraint so that it is
on a combination of name and dbxref_id?  This and extending the size
of dbxref.accession are not unreasonable changes to Chado (every time
I think we make something like accession big enough, somebody always
comes along to prove me wrong :-)

Given how long it takes to convert GAZ to chado-xml, it might be nice
to make that available somewhere for other people to use (ooh, maybe
the obo folks could be convinced to provide chado-xml for
download--that would be awesome! Yes Chris I'm looking at you :-)

Thanks,
Scott


On Wed, Mar 28, 2012 at 9:21 AM, Bob MacCallum
<[hidden email]> wrote:

> Hi,
>
> Just a bit of an update on this.
>
> The GAZ maintainers have fixed the syntax errors and circular
> references, and the "ontology" is now on bioportal (minus full tree
> browsing).
>
> I forgot to mention that two hacks are needed to load the ontology into Chado
>
> 1. table cvterm constraint cvterm_c1: either remove constraint on name
> or add an extra one on dbxref_id (we have gone for the latter, thanks
> to Dave Emmert's suggestion).  This because there are several terms
> with the same name, e.g. London.  So far we have not identified any
> downstream problems, but other sites should test before this goes into
> the trunk.
>
> 2. table dbxref column accession: extend to varchar(1024) to handle
> some crazy long URLs purporting to be accessions.
>
> Although it takes a while, conversion to Chado XML (4.2 days) and
> loading with stag-storenode.pl (3.5h) seems to be working for us.  The
> latter can handle updates also.
>
>
> I guess we should try cvtermpath at some point - I imagine this will
> take a while...
>
> cheers,
> Bob.
>
>
> On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
> <[hidden email]> wrote:
>> As you are probably all aware, GAZ is a big ontology.
>>
>> As far as we are aware, this is the only source for it:
>> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>>
>> It contains a lot of formatting errors, which we once corrected
>> manually then converted to Chado XML and loaded via stag-storenode.pl
>> - that loading process took more than 5 days.
>>
>> Recently I've tried fixing as many errors as possible with Perl
>> one-liners and making a few mods to Bio/OntologyIO/obo.pm
>> so that it handles quoted commas better and skips dodgy xrefs - so
>> that I can load it with gmod_load_cvterms.pl
>> (which I believe is preferable to stag-storenode if we want to
>> regularly re-load/update the ontology).
>>
>> Trouble is, once all the terms are loaded (several hours), the
>> relationships are taking many many days (still not finished), while it
>> outputs this kind of thing:
>>
>> Retrieved accession: 00307773
>> Looking at relationship in file: 00307773-00022850
>> Looking at relationship in file: 00307773-00022845
>> Retrieved accession: 00284751
>> Looking at relationship in file: 00284751-00283672
>> Retrieved accession: 00255061
>> Looking at relationship in file: 00255061-00007146
>>
>> Before we go looking at optimising the code or other tricks, I
>> wondered if anyone else had solved this problem?
>>
>> Then, of course, it would be nice to have cvtermpath populated but we
>> noticed circular references when we half-heartedly tried this last.
>>
>> As far as I can tell, Gramene seems to be the only site with GAZ on
>> board.  I'll make contact with them but I don't think they have Chado
>> under the hood.
>>
>> many thanks,
>> Bob.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Gmod-phendiver mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver



--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Anyone had any luck loading GAZ->Chado cv tables?

Chris Mungall
In reply to this post by Bob MacCallum

On Mar 28, 2012, at 6:21 AM, Bob MacCallum wrote:

> Hi,
>
> Just a bit of an update on this.
>
> The GAZ maintainers have fixed the syntax errors and circular
> references, and the "ontology" is now on bioportal (minus full tree
> browsing).
>
> I forgot to mention that two hacks are needed to load the ontology into Chado
>
> 1. table cvterm constraint cvterm_c1: either remove constraint on name
> or add an extra one on dbxref_id (we have gone for the latter, thanks
> to Dave Emmert's suggestion).  This because there are several terms
> with the same name, e.g. London.  So far we have not identified any
> downstream problems, but other sites should test before this goes into
> the trunk.
>
> 2. table dbxref column accession: extend to varchar(1024) to handle
> some crazy long URLs purporting to be accessions.

I think Michael is fixing these

> Although it takes a while, conversion to Chado XML (4.2 days) and
> loading with stag-storenode.pl (3.5h) seems to be working for us.  The
> latter can handle updates also.
>
>
> I guess we should try cvtermpath at some point - I imagine this will
> take a while...

I previously mentioned on the gmod-schema list a method for populating cvtermpath using owltools to build the closure. There's some docs on command line usage of owltools here:

        http://code.google.com/p/owltools/wiki/CommandLineExamples

For GAZ you would build the table like this:

        owltools gaz.obo --save-closure-for-chado gaz.inf

takes about 15 mins, the resulting file has ~4.5m lines, which could trivially be loaded at 4.5 rows into cvtermpath (I don't have code to do this, but it should be easy)

Note that building the cvetrmpath table in this way will give you the correct relationship between the two terms. The results may be surprising in some cases. For example, in GAZ there is a chain of tributary relationships:

                     GAZ:00063055 ! Oder
  tributary_of GAZ:00480012 ! Barycz
   tributary_of GAZ:00480017 ! Orla
    tributary_of GAZ:00469207 ! Maslowka
     tributary_of GAZ:00469209 ! Grobelka

However, there is no relationship between Grobelka and Oder in the table. This is because the tributary_of relation is not declared transitive in GAZ. If you do want them to be linked in the table, then we need to ask Michael either to make tributary_of transitive, or, preferably, create a new relation such as "connected_to" and add a rule to the ontology that a chain of 1 or more tributary_of relationships will yield a "connected_to" relationship. The method described above will make use of this rule.



> cheers,
> Bob.
>
>
> On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
> <[hidden email]> wrote:
>> As you are probably all aware, GAZ is a big ontology.
>>
>> As far as we are aware, this is the only source for it:
>> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>>
>> It contains a lot of formatting errors, which we once corrected
>> manually then converted to Chado XML and loaded via stag-storenode.pl
>> - that loading process took more than 5 days.
>>
>> Recently I've tried fixing as many errors as possible with Perl
>> one-liners and making a few mods to Bio/OntologyIO/obo.pm
>> so that it handles quoted commas better and skips dodgy xrefs - so
>> that I can load it with gmod_load_cvterms.pl
>> (which I believe is preferable to stag-storenode if we want to
>> regularly re-load/update the ontology).
>>
>> Trouble is, once all the terms are loaded (several hours), the
>> relationships are taking many many days (still not finished), while it
>> outputs this kind of thing:
>>
>> Retrieved accession: 00307773
>> Looking at relationship in file: 00307773-00022850
>> Looking at relationship in file: 00307773-00022845
>> Retrieved accession: 00284751
>> Looking at relationship in file: 00284751-00283672
>> Retrieved accession: 00255061
>> Looking at relationship in file: 00255061-00007146
>>
>> Before we go looking at optimising the code or other tricks, I
>> wondered if anyone else had solved this problem?
>>
>> Then, of course, it would be nice to have cvtermpath populated but we
>> noticed circular references when we half-heartedly tried this last.
>>
>> As far as I can tell, Gramene seems to be the only site with GAZ on
>> board.  I'll make contact with them but I don't think they have Chado
>> under the hood.
>>
>> many thanks,
>> Bob.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Anyone had any luck loading GAZ->Chado cv tables?

Chris Mungall
In reply to this post by Naama Menda

Naama,

It looks like your method builds the transitive closure of the entire graph ignoring relationship types. Not only does this mean that you will miss the relationship type information in cvtermpath, your method is not guaranteed to terminate. Perhaps this code could be modified such that it takes the output of owltools?

On Mar 28, 2012, at 12:48 PM, Naama Menda wrote:

hi Bob,

let me know when you try cvtermpath. 
We've been using it at SGN to make recursive querying much faster. I added a loading scripts to the gmod SVN (http://gmod.svn.sourceforge.net/viewvc/gmod/schema/trunk/chado/bin/gmod_make_cvtermpath.pl?view=log)

I'd like to see how other databases use the cvtermpath, since we occasionally encounter issues with the way we use it.

also let me know if you get errors with gmod_load_cvterms.pl, or if it fails due to errors in the obo file. Maybe such  can be checked before it starts to load the relationships

thanks!
-Naama

 
Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA

(607) 254 3569
Sol Genomics Network
http://solgenomics.net/
[hidden email]


On Wed, Mar 28, 2012 at 9:21 AM, Bob MacCallum <[hidden email]> wrote:
Hi,

Just a bit of an update on this.

The GAZ maintainers have fixed the syntax errors and circular
references, and the "ontology" is now on bioportal (minus full tree
browsing).

I forgot to mention that two hacks are needed to load the ontology into Chado

1. table cvterm constraint cvterm_c1: either remove constraint on name
or add an extra one on dbxref_id (we have gone for the latter, thanks
to Dave Emmert's suggestion).  This because there are several terms
with the same name, e.g. London.  So far we have not identified any
downstream problems, but other sites should test before this goes into
the trunk.

2. table dbxref column accession: extend to varchar(1024) to handle
some crazy long URLs purporting to be accessions.

Although it takes a while, conversion to Chado XML (4.2 days) and
loading with stag-storenode.pl (3.5h) seems to be working for us.  The
latter can handle updates also.


I guess we should try cvtermpath at some point - I imagine this will
take a while...

cheers,
Bob.


On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
<[hidden email]> wrote:
> As you are probably all aware, GAZ is a big ontology.
>
> As far as we are aware, this is the only source for it:
> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>
> It contains a lot of formatting errors, which we once corrected
> manually then converted to Chado XML and loaded via stag-storenode.pl
> - that loading process took more than 5 days.
>
> Recently I've tried fixing as many errors as possible with Perl
> one-liners and making a few mods to Bio/OntologyIO/obo.pm
> so that it handles quoted commas better and skips dodgy xrefs - so
> that I can load it with gmod_load_cvterms.pl
> (which I believe is preferable to stag-storenode if we want to
> regularly re-load/update the ontology).
>
> Trouble is, once all the terms are loaded (several hours), the
> relationships are taking many many days (still not finished), while it
> outputs this kind of thing:
>
> Retrieved accession: 00307773
> Looking at relationship in file: 00307773-00022850
> Looking at relationship in file: 00307773-00022845
> Retrieved accession: 00284751
> Looking at relationship in file: 00284751-00283672
> Retrieved accession: 00255061
> Looking at relationship in file: 00255061-00007146
>
> Before we go looking at optimising the code or other tricks, I
> wondered if anyone else had solved this problem?
>
> Then, of course, it would be nice to have cvtermpath populated but we
> noticed circular references when we half-heartedly tried this last.
>
> As far as I can tell, Gramene seems to be the only site with GAZ on
> board.  I'll make contact with them but I don't think they have Chado
> under the hood.
>
> many thanks,
> Bob.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] Anyone had any luck loading GAZ->Chado cv tables?

Chris Mungall
In reply to this post by Scott Cain

On Mar 28, 2012, at 1:05 PM, Scott Cain wrote:

> Hi Bob,
>
> So to get GAZ to load, you extended the name constraint so that it is
> on a combination of name and dbxref_id?  This and extending the size
> of dbxref.accession are not unreasonable changes to Chado (every time
> I think we make something like accession big enough, somebody always
> comes along to prove me wrong :-)
>
> Given how long it takes to convert GAZ to chado-xml, it might be nice
> to make that available somewhere for other people to use (ooh, maybe
> the obo folks could be convinced to provide chado-xml for
> download--that would be awesome! Yes Chris I'm looking at you :-)

We used to have chado-xml for all the ontologies available here:
http://www.berkeleybop.org/ontologies/

But this was switched off as not many people used it, and the xlstproc to chadoxml for some ontologies was taking too long.

I would recommend someone write a chadoxml dump in java as part of the owltools framework. This will be much faster, and will also allow you to translate the chado-subset of any OWL ontology without having to convert beforehand. I can't commit to doing this, but I can put some stub code in place and grant svn access if anyone wants to volunteer.

>
> Thanks,
> Scott
>
>
> On Wed, Mar 28, 2012 at 9:21 AM, Bob MacCallum
> <[hidden email]> wrote:
>> Hi,
>>
>> Just a bit of an update on this.
>>
>> The GAZ maintainers have fixed the syntax errors and circular
>> references, and the "ontology" is now on bioportal (minus full tree
>> browsing).
>>
>> I forgot to mention that two hacks are needed to load the ontology into Chado
>>
>> 1. table cvterm constraint cvterm_c1: either remove constraint on name
>> or add an extra one on dbxref_id (we have gone for the latter, thanks
>> to Dave Emmert's suggestion).  This because there are several terms
>> with the same name, e.g. London.  So far we have not identified any
>> downstream problems, but other sites should test before this goes into
>> the trunk.
>>
>> 2. table dbxref column accession: extend to varchar(1024) to handle
>> some crazy long URLs purporting to be accessions.
>>
>> Although it takes a while, conversion to Chado XML (4.2 days) and
>> loading with stag-storenode.pl (3.5h) seems to be working for us.  The
>> latter can handle updates also.
>>
>>
>> I guess we should try cvtermpath at some point - I imagine this will
>> take a while...
>>
>> cheers,
>> Bob.
>>
>>
>> On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
>> <[hidden email]> wrote:
>>> As you are probably all aware, GAZ is a big ontology.
>>>
>>> As far as we are aware, this is the only source for it:
>>> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>>>
>>> It contains a lot of formatting errors, which we once corrected
>>> manually then converted to Chado XML and loaded via stag-storenode.pl
>>> - that loading process took more than 5 days.
>>>
>>> Recently I've tried fixing as many errors as possible with Perl
>>> one-liners and making a few mods to Bio/OntologyIO/obo.pm
>>> so that it handles quoted commas better and skips dodgy xrefs - so
>>> that I can load it with gmod_load_cvterms.pl
>>> (which I believe is preferable to stag-storenode if we want to
>>> regularly re-load/update the ontology).
>>>
>>> Trouble is, once all the terms are loaded (several hours), the
>>> relationships are taking many many days (still not finished), while it
>>> outputs this kind of thing:
>>>
>>> Retrieved accession: 00307773
>>> Looking at relationship in file: 00307773-00022850
>>> Looking at relationship in file: 00307773-00022845
>>> Retrieved accession: 00284751
>>> Looking at relationship in file: 00284751-00283672
>>> Retrieved accession: 00255061
>>> Looking at relationship in file: 00255061-00007146
>>>
>>> Before we go looking at optimising the code or other tricks, I
>>> wondered if anyone else had solved this problem?
>>>
>>> Then, of course, it would be nice to have cvtermpath populated but we
>>> noticed circular references when we half-heartedly tried this last.
>>>
>>> As far as I can tell, Gramene seems to be the only site with GAZ on
>>> board.  I'll make contact with them but I don't think they have Chado
>>> under the hood.
>>>
>>> many thanks,
>>> Bob.
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Gmod-phendiver mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>
>
>
> --
> ------------------------------------------------------------------------
> Scott Cain, Ph. D.                                   scott at scottcain dot net
> GMOD Coordinator (http://gmod.org/)                     216-392-3087
> Ontario Institute for Cancer Research


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] Anyone had any luck loading GAZ->Chado cv tables?

Bob MacCallum
In reply to this post by Scott Cain
Lots to answer here, I'll start with Scott:

On Wed, Mar 28, 2012 at 9:05 PM, Scott Cain <[hidden email]> wrote:
> Hi Bob,
>
> So to get GAZ to load, you extended the name constraint so that it is
> on a combination of name and dbxref_id?  This and extending the size
> of dbxref.accession are not unreasonable changes to Chado (every time
> I think we make something like accession big enough, somebody always
> comes along to prove me wrong :-)

Yes that's right.  However, I would probably not force the
dbxref.accession change
on the wider community - these long accessions are not the norm.

Here are our working copy diffs.

% svn diff cv general
Index: cv/cv.sql
===================================================================
--- cv/cv.sql (revision 25255)
+++ cv/cv.sql (working copy)
@@ -45,7 +45,7 @@
     foreign key (dbxref_id) references dbxref (dbxref_id) on delete
set null INITIALLY DEFERRED,
     is_obsolete int not null default 0,
     is_relationshiptype int not null default 0,
-    constraint cvterm_c1 unique (name,cv_id,is_obsolete),
+    constraint cvterm_c1 unique (name,cv_id,is_obsolete,dbxref_id),
     constraint cvterm_c2 unique (dbxref_id)
 );
 create index cvterm_idx1 on cvterm (cv_id);
Index: general/general.sql
===================================================================
--- general/general.sql (revision 25255)
+++ general/general.sql (working copy)
@@ -54,7 +54,7 @@
     primary key (dbxref_id),
     db_id int not null,
     foreign key (db_id) references db (db_id) on delete cascade
INITIALLY DEFERRED,
-    accession varchar(255) not null,
+    accession varchar(1024) not null,
     version varchar(255) not null default '',
     description text,
     constraint dbxref_c1 unique (db_id,accession,version)


> Given how long it takes to convert GAZ to chado-xml, it might be nice
> to make that available somewhere for other people to use (ooh, maybe
> the obo folks could be convinced to provide chado-xml for
> download--that would be awesome! Yes Chris I'm looking at you :-)

we can put it on our FTP if you like...

ftp://ftp.vectorbase.org/public_data/organism_data/ontology/GAZ/


> Thanks,
> Scott
>
>
> On Wed, Mar 28, 2012 at 9:21 AM, Bob MacCallum
> <[hidden email]> wrote:
>> Hi,
>>
>> Just a bit of an update on this.
>>
>> The GAZ maintainers have fixed the syntax errors and circular
>> references, and the "ontology" is now on bioportal (minus full tree
>> browsing).
>>
>> I forgot to mention that two hacks are needed to load the ontology into Chado
>>
>> 1. table cvterm constraint cvterm_c1: either remove constraint on name
>> or add an extra one on dbxref_id (we have gone for the latter, thanks
>> to Dave Emmert's suggestion).  This because there are several terms
>> with the same name, e.g. London.  So far we have not identified any
>> downstream problems, but other sites should test before this goes into
>> the trunk.
>>
>> 2. table dbxref column accession: extend to varchar(1024) to handle
>> some crazy long URLs purporting to be accessions.
>>
>> Although it takes a while, conversion to Chado XML (4.2 days) and
>> loading with stag-storenode.pl (3.5h) seems to be working for us.  The
>> latter can handle updates also.
>>
>>
>> I guess we should try cvtermpath at some point - I imagine this will
>> take a while...
>>
>> cheers,
>> Bob.
>>
>>
>> On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
>> <[hidden email]> wrote:
>>> As you are probably all aware, GAZ is a big ontology.
>>>
>>> As far as we are aware, this is the only source for it:
>>> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>>>
>>> It contains a lot of formatting errors, which we once corrected
>>> manually then converted to Chado XML and loaded via stag-storenode.pl
>>> - that loading process took more than 5 days.
>>>
>>> Recently I've tried fixing as many errors as possible with Perl
>>> one-liners and making a few mods to Bio/OntologyIO/obo.pm
>>> so that it handles quoted commas better and skips dodgy xrefs - so
>>> that I can load it with gmod_load_cvterms.pl
>>> (which I believe is preferable to stag-storenode if we want to
>>> regularly re-load/update the ontology).
>>>
>>> Trouble is, once all the terms are loaded (several hours), the
>>> relationships are taking many many days (still not finished), while it
>>> outputs this kind of thing:
>>>
>>> Retrieved accession: 00307773
>>> Looking at relationship in file: 00307773-00022850
>>> Looking at relationship in file: 00307773-00022845
>>> Retrieved accession: 00284751
>>> Looking at relationship in file: 00284751-00283672
>>> Retrieved accession: 00255061
>>> Looking at relationship in file: 00255061-00007146
>>>
>>> Before we go looking at optimising the code or other tricks, I
>>> wondered if anyone else had solved this problem?
>>>
>>> Then, of course, it would be nice to have cvtermpath populated but we
>>> noticed circular references when we half-heartedly tried this last.
>>>
>>> As far as I can tell, Gramene seems to be the only site with GAZ on
>>> board.  I'll make contact with them but I don't think they have Chado
>>> under the hood.
>>>
>>> many thanks,
>>> Bob.
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Gmod-phendiver mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>
>
>
> --
> ------------------------------------------------------------------------
> Scott Cain, Ph. D.                                   scott at scottcain dot net
> GMOD Coordinator (http://gmod.org/)                     216-392-3087
> Ontario Institute for Cancer Research

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] Anyone had any luck loading GAZ->Chado cv tables?

Scott Cain
In reply to this post by Chris Mungall
It's unfortunate that it got dump it because it wasn't being used--had
I known it was there, I would have switch the default loading
mechanism for Chado to make use of it, and they would have been used
then :-/  So it goes, as the time to convert is an issue for everybody
(as Bob has attested :)

Having a Java based chadoxml dumper would be great, but I don't have
the time (or the necessary skill set) to do it either.

Scott


On Wed, Mar 28, 2012 at 5:04 PM, Chris Mungall <[hidden email]> wrote:

>
> We used to have chado-xml for all the ontologies available here:
> http://www.berkeleybop.org/ontologies/
>
> But this was switched off as not many people used it, and the xlstproc to chadoxml for some ontologies was taking too long.
>
> I would recommend someone write a chadoxml dump in java as part of the owltools framework. This will be much faster, and will also allow you to translate the chado-subset of any OWL ontology without having to convert beforehand. I can't commit to doing this, but I can put some stub code in place and grant svn access if anyone wants to volunteer.
>
>>
>> Thanks,
>> Scott
>>
>>
>> On Wed, Mar 28, 2012 at 9:21 AM, Bob MacCallum
>> <[hidden email]> wrote:
>>> Hi,
>>>
>>> Just a bit of an update on this.
>>>
>>> The GAZ maintainers have fixed the syntax errors and circular
>>> references, and the "ontology" is now on bioportal (minus full tree
>>> browsing).
>>>
>>> I forgot to mention that two hacks are needed to load the ontology into Chado
>>>
>>> 1. table cvterm constraint cvterm_c1: either remove constraint on name
>>> or add an extra one on dbxref_id (we have gone for the latter, thanks
>>> to Dave Emmert's suggestion).  This because there are several terms
>>> with the same name, e.g. London.  So far we have not identified any
>>> downstream problems, but other sites should test before this goes into
>>> the trunk.
>>>
>>> 2. table dbxref column accession: extend to varchar(1024) to handle
>>> some crazy long URLs purporting to be accessions.
>>>
>>> Although it takes a while, conversion to Chado XML (4.2 days) and
>>> loading with stag-storenode.pl (3.5h) seems to be working for us.  The
>>> latter can handle updates also.
>>>
>>>
>>> I guess we should try cvtermpath at some point - I imagine this will
>>> take a while...
>>>
>>> cheers,
>>> Bob.
>>>
>>>
>>> On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
>>> <[hidden email]> wrote:
>>>> As you are probably all aware, GAZ is a big ontology.
>>>>
>>>> As far as we are aware, this is the only source for it:
>>>> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>>>>
>>>> It contains a lot of formatting errors, which we once corrected
>>>> manually then converted to Chado XML and loaded via stag-storenode.pl
>>>> - that loading process took more than 5 days.
>>>>
>>>> Recently I've tried fixing as many errors as possible with Perl
>>>> one-liners and making a few mods to Bio/OntologyIO/obo.pm
>>>> so that it handles quoted commas better and skips dodgy xrefs - so
>>>> that I can load it with gmod_load_cvterms.pl
>>>> (which I believe is preferable to stag-storenode if we want to
>>>> regularly re-load/update the ontology).
>>>>
>>>> Trouble is, once all the terms are loaded (several hours), the
>>>> relationships are taking many many days (still not finished), while it
>>>> outputs this kind of thing:
>>>>
>>>> Retrieved accession: 00307773
>>>> Looking at relationship in file: 00307773-00022850
>>>> Looking at relationship in file: 00307773-00022845
>>>> Retrieved accession: 00284751
>>>> Looking at relationship in file: 00284751-00283672
>>>> Retrieved accession: 00255061
>>>> Looking at relationship in file: 00255061-00007146
>>>>
>>>> Before we go looking at optimising the code or other tricks, I
>>>> wondered if anyone else had solved this problem?
>>>>
>>>> Then, of course, it would be nice to have cvtermpath populated but we
>>>> noticed circular references when we half-heartedly tried this last.
>>>>
>>>> As far as I can tell, Gramene seems to be the only site with GAZ on
>>>> board.  I'll make contact with them but I don't think they have Chado
>>>> under the hood.
>>>>
>>>> many thanks,
>>>> Bob.
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
>>> Gmod-phendiver mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>
>>
>>
>> --
>> ------------------------------------------------------------------------
>> Scott Cain, Ph. D.                                   scott at scottcain dot net
>> GMOD Coordinator (http://gmod.org/)                     216-392-3087
>> Ontario Institute for Cancer Research
>



--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Anyone had any luck loading GAZ->Chado cv tables?

Naama Menda
In reply to this post by Chris Mungall
hi Chris,

it should do both - the entire graph and the relationship type graphs. Currently I only use the full graph, 
but  I'd like to test if the relationship type paths also work. I'll look at owltools output when I get to this. 


thanks
-Naama



On Wed, Mar 28, 2012 at 4:57 PM, Chris Mungall <[hidden email]> wrote:

Naama,

It looks like your method builds the transitive closure of the entire graph ignoring relationship types. Not only does this mean that you will miss the relationship type information in cvtermpath, your method is not guaranteed to terminate. Perhaps this code could be modified such that it takes the output of owltools?

On Mar 28, 2012, at 12:48 PM, Naama Menda wrote:

hi Bob,

let me know when you try cvtermpath. 
We've been using it at SGN to make recursive querying much faster. I added a loading scripts to the gmod SVN (http://gmod.svn.sourceforge.net/viewvc/gmod/schema/trunk/chado/bin/gmod_make_cvtermpath.pl?view=log)

I'd like to see how other databases use the cvtermpath, since we occasionally encounter issues with the way we use it.

also let me know if you get errors with gmod_load_cvterms.pl, or if it fails due to errors in the obo file. Maybe such  can be checked before it starts to load the relationships

thanks!
-Naama

 
Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA

<a href="tel:%28607%29%20254%203569" value="+16072543569" target="_blank">(607) 254 3569
Sol Genomics Network
http://solgenomics.net/
[hidden email]


On Wed, Mar 28, 2012 at 9:21 AM, Bob MacCallum <[hidden email]> wrote:
Hi,

Just a bit of an update on this.

The GAZ maintainers have fixed the syntax errors and circular
references, and the "ontology" is now on bioportal (minus full tree
browsing).

I forgot to mention that two hacks are needed to load the ontology into Chado

1. table cvterm constraint cvterm_c1: either remove constraint on name
or add an extra one on dbxref_id (we have gone for the latter, thanks
to Dave Emmert's suggestion).  This because there are several terms
with the same name, e.g. London.  So far we have not identified any
downstream problems, but other sites should test before this goes into
the trunk.

2. table dbxref column accession: extend to varchar(1024) to handle
some crazy long URLs purporting to be accessions.

Although it takes a while, conversion to Chado XML (4.2 days) and
loading with stag-storenode.pl (3.5h) seems to be working for us.  The
latter can handle updates also.


I guess we should try cvtermpath at some point - I imagine this will
take a while...

cheers,
Bob.


On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
<[hidden email]> wrote:
> As you are probably all aware, GAZ is a big ontology.
>
> As far as we are aware, this is the only source for it:
> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>
> It contains a lot of formatting errors, which we once corrected
> manually then converted to Chado XML and loaded via stag-storenode.pl
> - that loading process took more than 5 days.
>
> Recently I've tried fixing as many errors as possible with Perl
> one-liners and making a few mods to Bio/OntologyIO/obo.pm
> so that it handles quoted commas better and skips dodgy xrefs - so
> that I can load it with gmod_load_cvterms.pl
> (which I believe is preferable to stag-storenode if we want to
> regularly re-load/update the ontology).
>
> Trouble is, once all the terms are loaded (several hours), the
> relationships are taking many many days (still not finished), while it
> outputs this kind of thing:
>
> Retrieved accession: 00307773
> Looking at relationship in file: 00307773-00022850
> Looking at relationship in file: 00307773-00022845
> Retrieved accession: 00284751
> Looking at relationship in file: 00284751-00283672
> Retrieved accession: 00255061
> Looking at relationship in file: 00255061-00007146
>
> Before we go looking at optimising the code or other tricks, I
> wondered if anyone else had solved this problem?
>
> Then, of course, it would be nice to have cvtermpath populated but we
> noticed circular references when we half-heartedly tried this last.
>
> As far as I can tell, Gramene seems to be the only site with GAZ on
> board.  I'll make contact with them but I don't think they have Chado
> under the hood.
>
> many thanks,
> Bob.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________



------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Anyone had any luck loading GAZ->Chado cv tables?

Chris Mungall

OK, sorry, I didn't look at the code closely enough to see this

On Mar 29, 2012, at 8:25 AM, Naama Menda wrote:

hi Chris,

it should do both - the entire graph and the relationship type graphs. Currently I only use the full graph, 
but  I'd like to test if the relationship type paths also work. I'll look at owltools output when I get to this. 


thanks
-Naama



On Wed, Mar 28, 2012 at 4:57 PM, Chris Mungall <[hidden email]> wrote:

Naama,

It looks like your method builds the transitive closure of the entire graph ignoring relationship types. Not only does this mean that you will miss the relationship type information in cvtermpath, your method is not guaranteed to terminate. Perhaps this code could be modified such that it takes the output of owltools?

On Mar 28, 2012, at 12:48 PM, Naama Menda wrote:

hi Bob,

let me know when you try cvtermpath. 
We've been using it at SGN to make recursive querying much faster. I added a loading scripts to the gmod SVN (http://gmod.svn.sourceforge.net/viewvc/gmod/schema/trunk/chado/bin/gmod_make_cvtermpath.pl?view=log)

I'd like to see how other databases use the cvtermpath, since we occasionally encounter issues with the way we use it.

also let me know if you get errors with gmod_load_cvterms.pl, or if it fails due to errors in the obo file. Maybe such  can be checked before it starts to load the relationships

thanks!
-Naama

 
Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA

<a href="tel:%28607%29%20254%203569" value="+16072543569" target="_blank">(607) 254 3569
Sol Genomics Network
http://solgenomics.net/
[hidden email]


On Wed, Mar 28, 2012 at 9:21 AM, Bob MacCallum <[hidden email]> wrote:
Hi,

Just a bit of an update on this.

The GAZ maintainers have fixed the syntax errors and circular
references, and the "ontology" is now on bioportal (minus full tree
browsing).

I forgot to mention that two hacks are needed to load the ontology into Chado

1. table cvterm constraint cvterm_c1: either remove constraint on name
or add an extra one on dbxref_id (we have gone for the latter, thanks
to Dave Emmert's suggestion).  This because there are several terms
with the same name, e.g. London.  So far we have not identified any
downstream problems, but other sites should test before this goes into
the trunk.

2. table dbxref column accession: extend to varchar(1024) to handle
some crazy long URLs purporting to be accessions.

Although it takes a while, conversion to Chado XML (4.2 days) and
loading with stag-storenode.pl (3.5h) seems to be working for us.  The
latter can handle updates also.


I guess we should try cvtermpath at some point - I imagine this will
take a while...

cheers,
Bob.


On Thu, Dec 1, 2011 at 11:11 AM, Bob MacCallum
<[hidden email]> wrote:
> As you are probably all aware, GAZ is a big ontology.
>
> As far as we are aware, this is the only source for it:
> http://obo.cvs.sourceforge.net/viewvc/obo/obo/ontology/environmental/gaz.obo
>
> It contains a lot of formatting errors, which we once corrected
> manually then converted to Chado XML and loaded via stag-storenode.pl
> - that loading process took more than 5 days.
>
> Recently I've tried fixing as many errors as possible with Perl
> one-liners and making a few mods to Bio/OntologyIO/obo.pm
> so that it handles quoted commas better and skips dodgy xrefs - so
> that I can load it with gmod_load_cvterms.pl
> (which I believe is preferable to stag-storenode if we want to
> regularly re-load/update the ontology).
>
> Trouble is, once all the terms are loaded (several hours), the
> relationships are taking many many days (still not finished), while it
> outputs this kind of thing:
>
> Retrieved accession: 00307773
> Looking at relationship in file: 00307773-00022850
> Looking at relationship in file: 00307773-00022845
> Retrieved accession: 00284751
> Looking at relationship in file: 00284751-00283672
> Retrieved accession: 00255061
> Looking at relationship in file: 00255061-00007146
>
> Before we go looking at optimising the code or other tricks, I
> wondered if anyone else had solved this problem?
>
> Then, of course, it would be nice to have cvtermpath populated but we
> noticed circular references when we half-heartedly tried this last.
>
> As far as I can tell, Gramene seems to be the only site with GAZ on
> board.  I'll make contact with them but I don't think they have Chado
> under the hood.
>
> many thanks,
> Bob.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure_______________________________________________




------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver