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

Re: ontology specs for self-publishing experiment

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Thu, 6 Jul 2006 12:14:17 -0400
To: <public-semweb-lifesci@w3.org>
Message-ID: <001501c6a117$3b3e0d80$14241780@bioxiao>

> 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. I
would suggest to start with an ontology that has a very coarse granuality.
And developing more detailed ontologies one step at a time.  

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. 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. 

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.

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.



Received on Thursday, 6 July 2006 16:19:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:17 UTC