W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > July 2006

Re: ontology specs for self-publishing experiment

From: William Bug <William.Bug@DrexelMed.edu>
Date: Thu, 6 Jul 2006 12:55:50 -0400
Message-Id: <F5F10C40-4C24-4F7F-9838-AA442B4B05F1@DrexelMed.edu>
Cc: w3c semweb hcls <public-semweb-lifesci@w3.org>, Tim Clark <twclark@nmr.mgh.harvard.edu>
To: "Xiaoshu Wang" <wangxiao@musc.edu>
Hi Xiaoshu,

I believe the issue you raise is a critical one - one, as Sean - I  
believe - pointed out in the call - that there heated debates  
continue regarding whether whether it's appropriate to ever "merge"  
ontologies, and - if so, how explicit and detailed must the contract be.

Please see below for further comments.

Cheers,
Bill

On Jul 6, 2006, at 12:14 PM, Xiaoshu Wang wrote:

>
>> Based on that work, I'd like to follow Eric N's penchant for
>> "strawmen" and propose the following amendments to the
>> Proposed Classes to give focus to the discussion:
>>
>> Project
>> Study
>> Hypothesis
>> ...
>
> I honestly think before making the list, we should think about how  
> ontology
> should be modulized and how to develop ontologies on various  
> granualities.

We - in the W3C SW HCLSIG - don't need to do this, since it is  
already being done within the bio-ontology curation community - now  
under the auspices of the Nat. Center for Bio-Ontology.  At worst, we  
may want to learn more about the detailed foundation on which the OBO  
Foundry Principles derive ([http://obofoundry.org/]), and then, if we  
still find large issues being ignored, join the debate.

> I would suggest to start with an ontology that has a very coarse  
> granuality.
> And developing more detailed ontologies one step at a time.

In the context of the comment above, this is being addressed by  
trying to establish a foundational ontology for biomedical reality  
and an ontology of relations ([]).  I realize we went through this  
debate of the foundational ontology a few weeks back, but a fairly  
specific path is already being followed by the folks working on the  
OBO Foundry

>
> Using ontology implies that if you want to use one assertion of an  
> ontology,
> you must agree to all assertions made in the ontology. A detailed  
> monolithic
> ontology is what we should avoid.

Exactly right!  This was the basis for the foundation of the OBO site  
by the GO Consoritum, which - if I'm not mistaken - pre-dates work on  
the OBO Foundry Principles by a year or two at least.

> I have thought of this problem for quite a
> while.  The BOSS ontology (http://www.charlestoncore.org/ontology/ 
> boss) that
> I created only has a three classes (Study, Protocol and Data) and  
> three
> pairs of inverse properties.  (Please trust me, I am not trying to  
> promote
> the BOSS ontology here.) What I have really hoped is that we should  
> think
> how the ontologies will be shared before start building the ontology.

It sounds to me like what you have done with BOSS should be a part of  
the discussion/sharing of ideas Tim Clark suggested between SWAN &  
FuGE, which I believe should also include FuGO, PaTO, and EXPO.

>
> The same issue also goes to the overlap between FUGO with the proposed
> self-descriptive experiement ontology. In fact, I think all biological
> related ontology will perhaps touche on the topic of experiment in  
> one way
> or the other.  Hence, if each ontology's designers don't factor out  
> their
> ontology design, the eventual result will be a bunch of overlapping
> monolithic ontologies.

This is EXACTLY the mess the PaTO + FuGO formalism is designed to  
avoid.  I'd suggest looking folks interested in learning more about  
how they are looking to address this issue check out the following  
article AND what the PaTO web site ([http://obo.sourceforge.net/cgi- 
bin/detail.cgi?attribute_and_value]) and the PaTO mailing list ([obo- 
phenotype@lists.sourceforge.net]).  I believe there will be a PaTO  
meeting scheduled for sometime later in the year.

Most recent PaTO citations (even these are little out of date, since  
it's evolving quite rapidly):

CRAVE: a database, middleware and visualization system for phenotype  
ontologies.
Gkoutos GV, Green EC, Greenaway S, Blake A, Mallon AM, Hancock JM.
Bioinformatics. 2005 Apr 1;21(7):1257-62. Epub 2004 Nov 18.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi? 
db=pubmed&cmd=Retrieve&dopt=Abstract&list_uids=15550481&query_hl=1&itool 
=pubmed_docsum

Using ontologies to describe mouse phenotypes.
Gkoutos GV, Green EC, Mallon AM, Hancock JM, Davidson D.
Genome Biol. 2005;6(1):R8. Epub 2004 Dec 20.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi? 
db=pubmed&cmd=Retrieve&dopt=Abstract&list_uids=15642100&query_hl=1&itool 
=pubmed_docsum

If I understand the organizational structure of the PaTO project  
correctly, the people to contact directly would be either Giorgios  
GKoutos or Chris Mungall - but it's easiest to just use the obo- 
phenotype list email given above.

>
> Creating a big monolithic ontology is just the same as creating a
> conventional data standard, like XML schema or ER model because  
> sharing
> ontology must consider ontology merging as opposed to schema  
> integration.
> It transforms the problem but not solve it.

I agree 100%!

>
> Cheers
>
> Xiaoshu
>
>
> .
>
>

Bill Bug
Senior Analyst/Ontological Engineer

Laboratory for Bioimaging  & Anatomical Informatics
www.neuroterrain.org
Department of Neurobiology & Anatomy
Drexel University College of Medicine
2900 Queen Lane
Philadelphia, PA    19129
215 991 8430 (ph)
610 457 0443 (mobile)
215 843 9367 (fax)


Please Note: I now have a new email - William.Bug@DrexelMed.edu







This email and any accompanying attachments are confidential. 
This information is intended solely for the use of the individual 
to whom it is addressed. Any review, disclosure, copying, 
distribution, or use of this email communication by others is strictly 
prohibited. If you are not the intended recipient please notify us 
immediately by returning this message to the sender and delete 
all copies. Thank you for your cooperation.
Received on Thursday, 6 July 2006 16:56:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:44 GMT