Re: Experiment Ontology

Hi Susie,

We certainly do need an "Experiment Ontology" - or Ontology of  
Biomedical Investigation (OBI).

I believe Matthias, Michael, and Kei have all made exactly the points  
I think are most important to consider:
	1) Matthias's comments
		Are you following "best practices" in creating the ontology.  I  
believe Matthias gives many instructive examples on how to adjust  
what is here to bring it much more in sync with the emerging "best  
practices" that are coming out of the community development  
surrounding a variety of OBO Foundry ontologies.  Matthias also makes  
the point that its important to seek to re-use (or directly  
contribute to) the emerging community ontologies to cover the  
required domains.  In the case of this particular Experiment  
Ontology, the ontologies to consider are Ontology of Biomedical  
Investigation (OBI), the OBO Relations Ontology, the Gene Ontology  
(specifically the Molecular Function and Cellular Component branches,  
the latter of which is designed to capture components down to the  
level of macromolecular complexes), the Sequence Ontology, Protein  
Ontology (nascent - but proceeding rapidly), the Cell Ontology - at a  
minimum.  As many on this list know - and I'm certain the talented  
folks at Lilly who invested time in assembling this ontology also  
learned - many of these are not fully ready for prime-time, and/or  
may not FULLY cover the breadth and depth of the domains a specific  
application requires.  However, if one doesn't seek to work with  
these community efforts, you cannot expect to achieve the ultimately  
goal, which is to make your data maximally "semantically sticky", so  
as to ensure the least amount of custom logic and human effort will  
be required to get the most value from your data.  Otherwise, you  
stand the chance of creating what may be a useful ontology that meets  
your specific requirements (as has been true of "investigation"- 
oriented ontologies that have come before such as the MAGE Ontology,  
ExperiBase, EXPO, myGRID KAVE, etc.), but don't help the community at- 
large to appropriately re-use your data.  In each case, these  
ontologies or KR frameworks have been extremely useful in the local  
application context for which they were constructed, but they cannot  
be effectively employed as the basis for semantically-driven  
integration across data sets that may not be able to accept the  
constraints (or lack thereof) of this application-oriented ontology.
		Would you know off-hand, Susie, whether the folks who worked on  
this ontology at Lilly have both reviewed the relevant community  
efforts cited above and/or have sought to interact with those groups  
to get some input on how best to meet the overall requirements that  
underlie this particular Experiment Ontology with the minimal  
required effort and in a manner that could help to ensure Lilly's  
sunk investment could be of benefit to us all.

	2) Michael's comments
		It's very helpful to know what the target is when it comes to  
exporting/exchanging the actual data.  As Michael points out, a great  
deal of work has gone into the production of FuGE (and MaGE before  
it) to come up with the appropriate division of labor between the  
semantically-opaque, syntactical requirements as represented in a  
data model such as MaGE or FuGE and the explicit semantics as  
captured in the ontology.  For those using FuGE, as Michael states,  
in the realm of syntax, the intention for FuGE is to provide a shared  
structure for universal elements such as biomaterials, experiment  
populations/pools/groups, protocol details, reagents details, etc..   
Built on that shared, generic foundation, any specific discipline -  
e.g., microarray expression, GC-MS, FISH, MRI, etc. - can sub-class  
FuGE components and add what additional detail required in their  
discipline.  In parallel with this effort on data structure, the OBI  
ontology cooperative seeks to provide that same foundation for the  
shared semantic domains, and a clear set of recommended practices for  
how to re-use entities from other OBO Foundry ontologies such as  
ChEBI, Sequence Ontology, Protein Ontology, OBO Cell, Organism  
Taxonomy (OWL versions of NCBI Tax), etc. to specify the critical  
biomedical entities and their complex relations.  As I say above,  
these are works in progress.  For those of us who must have something  
working now, the recommended practice is to actively participate in  
these projects with an eye toward following their practice - and  
replacing any "proxy" you create in the interim with the community  
ontology, when it is ready for use.  This is what we have done in the  
BIRN ontology BIRNLex.  We actually have an OWL module called  
"BIRNLex-OBI-Proxy.owl" which we fully intend to replace with OBI  
entities, when they are ready for use.  We also have "BIRNLex- 
Investigation.owl" that builds on this "proxy" to cover entities BIRN  
researchers must capture.  We expect to eventually see the contents  
of "BIRNLex-Investigation" in OBI in some form.  We intend to  
"contribute" those elements from this OWL file directly to OBI, when  
OBI is ready for them, and we have the time work through this  
migration process.

	3) Kei's comments
		Examples - examples - examples.  This is critical.  Working through  
the example Kei cites from the NIH Neuroscience Microarray Consortium  
is a wonderful way to determine whether:
			- there are existing community ontologies that can meet the KR and  
processing requirements
			- where the gaps are in those community ontologies
			- whether the ontology you are creating effectively fills those  
gaps (if it does, that makes it very clear how the community effort  
can make effective use of your ontology)
		In regards to Gene Lists, Kei is certainly correct.  If these are  
captured through algorithmic means, it's critical to capture the  
details on that algorithm - typically both the version of the  
algorithm as well as the version of the data repository you ran it  
against.
		Also - where gene entities are concerned - there is ongoing work  
between the GO groups, the Sequence Ontology, and the Protein  
Ontology that is particularly targeted toward capturing the specific  
relations between types of genomic sequence elements and types of  
biologically active protein-based molecules (e.g., macromolecular  
complexes composed of a collection of proteins in a variety of post- 
translationally modified states - e.g., GPC receptors, ion channels,  
transporters, pathway enzymes, etc. - i.e., Rx drug targets).  These  
are the details we'll all require in order to do round-trip  
pharmacogenetics - i.e.,effects of genetic constructs on target  
susceptibility to drugs - AND - the ways in which drugs ultimately  
alter macromolecular complexes by leading to changes in gene expression.

Just my $0.02 filtering on these helpful comments from Matthias,  
Michael, and Kei.

Cheers,
Bill

On Dec 3, 2007, at 1:00 PM, Kei Cheung wrote:

>
> This is great!
>
> I have a microarray experiment description (that has to do with  
> Alzheimer Disease) extracted from NINDS microarray consortium:
>
> http://arrayconsortium.tgen.org/np2/viewProject.do? 
> action=viewProject&projectId=433773
>
> I just wonder how this example would fit this experiment ontology  
> (as well as others such as OBI) As shown in this example, we record  
> information such as organ type, organ region, cell type (layer II  
> pyramidal neuron), etc. NINDS microarry consortium uses different  
> array platforms (e.g., agilent, Affymetrix, and cDNA)  for  
> different organisms so one may need to divide chips into groups  
> corresponding to different platform types. Each group can then be  
> further divided into subgroups corresponding to different organisms.
>
> We also would like to capture gene lists (not the raw gene lists  
> but the ones (much shorter) that indicate what genes are over/under  
> expressed under certain experimental conditions). Such gene lists  
> would usually be extracted from the literature. Also the analysis  
> package (including version) that was used to generate a gene list  
> should be identified. One possible use of these gene lists is to  
> compare them to identify genes are differentially expressed under  
> the same/similar experimental condition across different microarray  
> experiments. This would help identify true signals from noises.
>
> Hope it helps.
>
> Cheers,
>
> -Kei
>
>
>
> Matthias Samwald wrote:
>>
>> Hi Susie,
>>
>> Susie wrote:
>>> It would be great if you could take a look at it and provide  
>>> comments. The
>>> ontology is available at:
>>> http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/ 
>>> Experiment_Ontology
>>
>> * Some of the entities/properties are missing a rdfs:label or have  
>> an empty label (a string with lenght 0).
>> * Some of the entities could be taken from existing ontologies  
>> like OBI, RO or some of the OBO Foundry ontologies. This would  
>> save work and makes integration with other data sources and  
>> ontologies much easier. By the way, there seem to be several  
>> groups working on ontologies for mircoarray experiments, or are at  
>> least planning to do that. It would be great if these groups could  
>> work together.
>> * The class 'Chip type' should be removed and be replaced by  
>> subclasses of 'chip', e.g., 'chip (human)', 'chip (mouse)' etc.
>> * Some of the object properties appear like they are intended to  
>> be datatype properties (e.g., 'has proteome id').
>> * Many of the datatype properties could be replaced with object  
>> properties, possibly referring to third party ontologies -- of  
>> course this would require a richer ontology and more work spent on  
>> creating mappings. 'has molecular function' could refer to  
>> entities from the gene ontology, 'has associated organ' could  
>> refer to an ontology about anatomy and so on.
>> * Object properties and their ranges are quite redundant. Property  
>> 'has reagent' has range 'Reagent', property 'has treatment' has  
>> range'Treatment' and so on. Maybe the ontology could be designed  
>> in such a way that there are only some generic properties such as  
>> 'has part'. This would make the ontology much easier to maintain,  
>> query and understand in the long term.
>> * It is unclear how 'Gene list' is intended to be used.
>> * 'Hardware' and 'Software' should not be subclasses of 'Protocol'.
>>
>>
>> Many of the datatype properties in this ontology look very  
>> interesting and might provide requirements for other ontologies.  
>> It would be great if some of them could be described/commented in  
>> more detail so that we know more about the requirements that  
>> motivated the creation of these properties.
>>
>> I hope that was somewhat helpful.
>>
>> cheers,
>> Matthias Samwald
>>
>>
>>
>
>
>



William Bug, M.S., M.Phil.                                         		 
email: wbug@ncmir.ucsd.edu
Ontological Engineer (Programmer Analyst III)		work: (610) 457-0443
Biomedical Informatics Research Network (BIRN)
and
National Center for Microscopy & Imaging Research (NCMIR)
Dept. of Neuroscience, School of Medicine
University of California, San Diego
9500 Gilman Drive
La Jolla, CA 92093

Please note my email has recently changed