Re: [Obo-discuss] Request namespaces for INO (Interaction Network Ontology) and HINO (Human INO)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Thanks for all the comments and suggestions.

Some clarification: I don't wish to generate an ontology term for each item from a database (e.g. Reactome) (note: currently INO has many terms like this, but I think I should remove them all). Since hundreds of interaction and pathway databases exist and they often have redundancy and are difficult to communicate, my principle idea is to generate a non-redundant ontology to represent the same knowledge. Such an ontology is aligned with BFO so it can be integrated with and use over 100 other existing ontologies, like GO and ChEBI. This way we can achieve better data integration.

More detail can be found in my article: http://arxiv.org/ftp/arxiv/papers/1311/1311.3355.pdf

So by doing this, I don't aim to translate one database to an ontology. I aim to do data integration by integrating probably hundreds of interaction/pathway databases to one ontology system. It will for sure be a huge task and an ambitious aim. However, what we can do now is to give some small demonstration with some good use case(s). I think such a new idea is worth a try. The above quoted article is a first step towards a good demo. For now it only uses Reactome. Next we will need to demonstrate how to expand the same ontology to represent knowledge from other databases in a non-redundant way. As Chris commented, further experimentation such as what we are doing will better answer if there is a clear win in doing this.

I prefer to have it in the OBO space since it follows the OBO Foundry principles, aligns and integrates with other OBO Foundry ontologies, and addresses an important domain of biology. However, I also agree that this can be a big burden to OBO administration. I like Chris' suggestion and would like to test:
-----
>     If you really want to have these translations be in the OBO space, why
>     don't we set up one generic ID space and put everything under that,
>     relaxing the URI guidelines? For example, let's say you wanted to grab
>     an ID space "OMICS". You could then use this to prefix the URIs of
>     database-sourced entities retaining the original ID. E.g.
>     purl….obo/OMICS/REACTOME_12345. This way we don't end up with a
>     proliferation of "ontologies", and you have the freedom to keep adding
>     new entities (as you most likely will).
-----
      Eventually, I don't want to generate one ID like REACTOME_12345. I would like to generate some ID like HINO_12345 to represent the same human interaction/pathway knowledge seen in probably REACTOME_12345, KEGG_12345, and IDs from other databases. The HINO_12345 will represent non-redundant information about the same human interaction/pathway. This ID will also be associated with logic axioms that represent detailed input entity, output entity, enzymes, ... as you would commonly see in a typical reaction and pathway.
      However, for each species, we may need one extension, like for human, we need Human INO (HINO); for mouse, we need Mouse IDO (MIDO). In the end, we will have too many extension namespaces. To solve this issue, we can try Chris' suggestion (if I understand correctly):
      - Set up one generic ID space, like "IN" (representing "Interaction Network")
      - Then I could use this to prefix the URIs of core and species-specific IDs, e.g., purl...obo/IN/HINO_12345, purl...obo/IN/MIDO_12345.

Thanks!

Oliver

________________________________
From: Erick Antezana [eri...@gm...]
Sent: Wednesday, March 05, 2014 3:57 AM
To: n.l...@gm...; obo...@li...
Subject: Re: [Obo-discuss] Request namespaces for INO (Interaction Network Ontology) and HINO (Human INO)

indeed, even better.

On 5 March 2014 09:49, Nicolas Le Novere <n.l...@gm...<mailto:n.l...@gm...>> wrote:
On 05/03/14 08:05, Erick Antezana wrote:
> Hi,
>
> I agree with Chris: the proliferation of namespaces should be to some extent controlled...
>
> My take on this issue would be:
>
> - continue keeping namespaces in the OBO foundry which *only* correspond to domain ontologies
> - maintain a separate resource, something such as http://www.geneontology.org/cgi-bin/xrefs.cgi, for application ontologies.

Something like

http://identifiers.org?

> cheers,
> Erick
>
>
> On 5 March 2014 02:37, Chris Mungall <cjm...@lb...<mailto:cjm...@lb...> <mailto:cjm...@lb...<mailto:cjm...@lb...>>> wrote:
>
>     Hi Oliver,
>
>     I have a general concern, maybe I'm not getting something.
>
>     There are a very large number of databases out there. Many of these can
>     be translated to an ontology.
>
>     It's not clear that there's always a clear win in doing this (but that's
>     a question that may be best answered by doing further experimentation
>     such as what you're doing).
>
>     But in doing this we should not be creating an administrative burden by
>     registering new OBO namespaces for every database X species combination
>     out there. And we definitely should not be contributing to the ID
>     mapping curse by minting yet another set of numeric IDs.
>
>     Do you really need this to be an OBO library ontology? I know we have
>     something of a precedent here with things like the NCBITaxonomy, but
>     perhaps not every translated resource needs to have the magic OBO purl.
>
>     If you really want to have these translations be in the OBO space, why
>     don't we set up one generic ID space and put everything under that,
>     relaxing the URI guidelines? For example, let's say you wanted to grab
>     an ID space "OMICS". You could then use this to prefix the URIs of
>     database-sourced entities retaining the original ID. E.g.
>     purl….obo/OMICS/REACTOME_12345. This way we don't end up with a
>     proliferation of "ontologies", and you have the freedom to keep adding
>     new entities (as you most likely will).
>
>
>
>
>
>     On 4 Mar 2014, at 12:18, He, Yongqun wrote:
>
>      > Additional information:
>      >
>      > INO/HINO website:
>      > http://www.ino-ontology.org/
>      >
>      > INO in Ontobee: http://www.ontobee.org/browser/index.php?o=INO
>      > HINO in Ontobee: http://www.ontobee.org/browser/index.php?o=HINO
>      >
>      > Best,
>      > Oliver
>      >
>      >
>      > From: He, Yongqun
>      > Sent: Tuesday, March 04, 2014 3:16 PM
>      > To: obo...@li...<mailto:obo...@li...> <mailto:obo...@li...<mailto:obo...@li...>>
>      > Cc: He, Yongqun
>      > Subject: Request namespaces for INO (Interaction Network Ontology) and
>      > HINO (Human INO)
>      >
>      > Dear OBO-discuss:
>      >
>      > Here I would like to request two related namespaces for inclusion in
>      > the OBO Foundry ontology library:
>      > (1) INO: Interaction Network Ontology
>      > (2) HINO: Human Interaction Network Ontology, which is an extension of
>      > INO.
>      >
>      > INO is aligned with BFO. INO was initially developed to classify and
>      > represent different levels of interaction keywords used for literature
>      > mining of genetic interaction networks. The literature mining strategy
>      > and the INO name were described in our ontology-based literature
>      > mining paper in 2011:
>      >       Ozgur A, Xiang Z, Radev D, He Y. Mining of vaccine-associated
>      > IFN-γ gene interaction networks using the Vaccine Ontology. Journal
>      > of Biomedical Semantics. 2011, 2(Suppl 2):S8. PMID: 21624163.
>      > http://www.ncbi.nlm.nih.gov/pubmed/21624163
>      >
>      > HINO is an extension of INO. HINO targets for ontologically
>      > representing human interactions and networks. The rationale for HINO
>      > development is as follows:
>      >      Many resources, such as Reactome and KEGG, store manually curated
>      > interactions and pathways. However, there is no BFO-aligned
>      > interaction pathway ontology that specifies the information stored in
>      > Reactome and other databases. The curated data are commonly
>      > represented in BioPAX, an OWL-based biological pathway data exchange
>      > format. BioPAX represents these interactions and pathways as
>      > instances. BioPAX is successful in facilitating data exchange.
>      > However, individual entities, interactions, and pathways represented
>      > in BioPAX are all temporary instance IDs and cannot be exchanged among
>      > different resources. Given appropriate conditions, these interactions
>      > and pathways in Reactome and KEGG always occur. Therefore, they are
>      > more appropriately represented as ontology classes instead of
>      > instances. The HINO is aimed to provide non-redundant representations
>      > of human molecular interactions, pathways, and  networks. HINO was
>      > presented in ICBO-2013 as a poster:
>      > http://ceur-ws.org/Vol-1060/icbo2013_submission_70.pdf
>      >     More detail about HINO was recently published in a preprint in
>      > arXiv:
>      >
>      > -          Abstract: http://arxiv.org/abs/1311.3355
>      >
>      > -          PDF full text:
>      > http://arxiv.org/ftp/arxiv/papers/1311/1311.3355.pdf
>      >
>      > Currently HINO only represents human molecular interactions and
>      > networks knowledge stored in Reactome. We are working to add more
>      > results from other interaction and pathway databases. Cross-references
>      > to the original database sources will be provided.
>      >
>      > Suggestions, comments, and collaborations are welcome and appreciated.
>      >
>      > Thanks for your consideration,
>      >
>      > Oliver
>      >
>      > Yongqun "Oliver" He, DVM, PhD
>      > Associate Professor
>      > Unit for Laboratory Animal Medicine
>      > Department of Microbiology and Immunology
>      > Center for Computational Medicine and Bioinformatics
>      > and Comprehensive Cancer Center
>      > University of Michigan Medical School
>      > Mail: 018 ARF, 1150 W. Medical Center Dr.
>      > Ann Arbor, MI 48109
>      > Email: yon...@me...<mailto:yon...@me...> <mailto:yon...@me...<mailto:yon...@me...>><mailto:yon...@me...<mailto:yon...@me...> <mailto:yon...@me...<mailto:yon...@me...>>>
>      > Tel: 734-615-8231 (O)
>      > http://www.hegroup.org/
>      >
>      > **********************************************************
>      > Electronic Mail is not secure, may not be read every day, and should
>      > not be used for urgent or sensitive issues
>      > ------------------------------------------------------------------------------
>      > Subversion Kills Productivity. Get off Subversion & Make the Move to
>      > Perforce.
>      > With Perforce, you get hassle-free workflows. Merge that actually
>      > works.
>      > Faster operations. Version large binaries.  Built-in WAN optimization
>      > and the
>      > freedom to use Git, Perforce or both. Make the move to Perforce.
>      > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk_______________________________________________
>      > Obo-discuss mailing list
>      > Obo...@li...<mailto:Obo...@li...> <mailto:Obo...@li...<mailto:Obo...@li...>>
>      > https://lists.sourceforge.net/lists/listinfo/obo-discuss
>
>     ------------------------------------------------------------------------------
>     Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>     With Perforce, you get hassle-free workflows. Merge that actually works.
>     Faster operations. Version large binaries.  Built-in WAN optimization and the
>     freedom to use Git, Perforce or both. Make the move to Perforce.
>     http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Obo-discuss mailing list
>     Obo...@li...<mailto:Obo...@li...> <mailto:Obo...@li...<mailto:Obo...@li...>>
>     https://lists.sourceforge.net/lists/listinfo/obo-discuss
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Obo-discuss mailing list
> Obo...@li...<mailto:Obo...@li...>
> https://lists.sourceforge.net/lists/listinfo/obo-discuss
>

--
Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
Tel: +441223496433<tel:%2B441223496433>   Mob:+447833147074<tel:%2B447833147074>   n.l...@gm...<mailto:n.l...@gm...>
orcid.org//0000-0002-6309-7327<http://orcid.org//0000-0002-6309-7327>  http://lenoverelab.org/perso/lenov/
Skype:n.lenovere  twitter:@lenovere  http://nlenov.wordpress.com/

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Obo-discuss mailing list
Obo...@li...<mailto:Obo...@li...>
https://lists.sourceforge.net/lists/listinfo/obo-discuss

**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues 