Cvterms shared between multiple cvs (ontologies)

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

Cvterms shared between multiple cvs (ontologies)

Bob MacCallum
Hello all,

This follows on from a discussion more than a year ago:
First things first, in the below, when I say "load" I mean the following:
cat file.obo | go2fmt.pl -p obo_text -w xml - | go-apply-xslt oboxml_to_chadoxml > file.chado-xml
stag-storenode.pl -d "dbi:Pg:dbname=$CHADO_DB_NAME" --user $USER file.chado-xml


If I load GO the term "nuclear chromosome" ends up in the cvterm table belonging to the "cellular_component" cv - which is fine.

Then I load MIRO via the same process

And the row in cvterm is updated so that cv_id is now pointing to MIRO.

Here's the MIRO nuclear chromosome term for reference:
http://bioportal.bioontology.org/ontologies/MIRO?p=classes&conceptid=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FGO_0000228


This hasn't been a problem for us until now.  Now we want to write a script which "gets all terms from MIRO and ... [dumps them to Solr JSON FWIW]".  And because of the fragile nature of the cvterm.cv_id column (and its one-to-one-ness) we can't do this.

Has anyone else tackled this issue?

many thanks,
Bob.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Cvterms shared between multiple cvs (ontologies)

Chris Mungall-5

For now you would have to fix the ontology - the developers (cc'd) may
be able to do this. Or you could hack something ugly into your workflow.
But note this may indicative of worse problems to come. What happens if
the 'MIREOT'ed copy of a subset of GO merged into MIRO is out of date to
the extent that you have terms obsolete in one and live in the other?
You might want to invest some effort evaluating your set of required
ontologies, how they connect and if any pre-processing is required.

Pantelis you can contact me off list if you want help fixing the
workflow for MIRO

On 24 Feb 2015, at 9:01, Bob MacCallum wrote:

> Hello all,
>
> This follows on from a discussion more than a year ago:
>
> http://gmod.827538.n3.nabble.com/stag-storenode-pl-overwrites-existing-cvterms-in-vocabularies-different-from-the-one-being-loaded-td4031069.html
>
> First things first, in the below, when I say "load" I mean the
> following:
>
> cat file.obo | go2fmt.pl -p obo_text -w xml - | go-apply-xslt
> oboxml_to_chadoxml > file.chado-xml
> stag-storenode.pl -d "dbi:Pg:dbname=$CHADO_DB_NAME" --user $USER
> file.chado-xml
>
>
>
> If I load GO the term "nuclear chromosome" ends up in the cvterm table
> belonging to the "cellular_component" cv - which is fine.
>
> Then I load MIRO via the same process
>
> And the row in cvterm is updated so that cv_id is now pointing to
> MIRO.
>
> Here's the MIRO nuclear chromosome term for reference:
> http://bioportal.bioontology.org/ontologies/MIRO?p=classes&conceptid=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FGO_0000228
>
>
> This hasn't been a problem for us until now.  Now we want to write a
> script
> which "gets all terms from MIRO and ... [dumps them to Solr JSON
> FWIW]".
> And because of the fragile nature of the cvterm.cv_id column (and its
> one-to-one-ness) we can't do this.
>
> Has anyone else tackled this issue?
>
> many thanks,
> Bob.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> things parallel software development, from weekly thought leadership
> blogs to
> news, videos, case studies, tutorials and more. Take a look and join
> the
> conversation now.
> http://goparallel.sourceforge.net/_______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema