RE: ontology specs for self-publishing experiment

Trish,

> Comments inline.
> 
> >> 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.
> This is the idea behind FuGE and to some degree FuGO. The 
> development of FuGE is an effort to factor out the re-usable 
> bits of modelling an experiment that can be used to describe, 
> in particular any functional genomics experiment, but perhaps 
> some sections could be extended to other types of 
> experiments?. The concepts that AJ has included seem to be 
> fine with respect to having something to test the proof of 
> concept of the idea and technology for linking/searching the 
> data. One thing that may need to be added is something to 
> indicate the type of experiment so that searches can be 
> limited in some way. The ways to go about typing the kind of 
> experiment are many so if needed, that can be left for future 
> discussions. Depending on how fine grained this effort goes, 
> perhaps there is some benefit in joining this work to what 
> has been done, at least with functional genomics experiments, 
> to develop data standards and exchange formats as these 
> efforts represent the granularity needed by the community.

When I mean "factoring out", I mean by grouping terms under different
namespaces.  I just take a brief overlook on FuGO, just taking the first
look that "LC_instrument" is under the same namespace of "continuant"
already tells me there is no modulization whatsoever.  (Please correct me if
I am wrong).  If I were an anatomist, who will conduct experiment, but never
care about LC_instrument.  But if I want to use FuGO's continuant, I would
have to buy in the concepts of LC_instrument as well.  Now, what about some
physicist, electrical engineer, do each scientific community should they
ever want or forced to accept LC_experiment?

To factor it out, for example, you need to break it at least into two
ontologies. One top generic concepts and one lower domain specific ones.
So, at least, people can share the top one without forced to take the bottom
one.  But the right way in my suggested methodology would be at least be
three.  For the simple case, there needs to be at least three: two
LocalOntologies + one Profile (see my classification of ontologies and what
I mean by ontology normalization at
http://www.charlestoncore.org/ont/2005/08/o3.html). By this way, if a lower
level ontologies want to realign its relations to another high-level
ontology, a new profile can be created to associate them.  The rational for
the basis of  
ontology normalization is to separate ontologies' dependency so they can
gracefully evolve over time... I will stop here.  Otherwise, I would have to
put out my entire manuscript to make it clear.

FuGO, in its current form, would be unable to handle the evolutionary, let
alone the revolutionary change of its ontological terms.   

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

> The overlap with the self-descriptive experiment ontology is 
> actually with both FuGE and FuGO. FuGE provides a model to 
> capture common components of investigations and to provide a 
> framework to capture laboratory workflows. FuGO is being 
> designed to provide a source of descriptors for the 
> annotation of investigations. The scope of FuGO includes the 
> design of an investigation, the protocols and instrumentation 
> used, the data generated and the types of analysis performed 
> on the data. FuGO is not to model any of these particular 
> items, but to provide annotation terms as needed by the 
> collaborating communities. Of course terms/classes will be 
> needed in the ontology to properly fill out the is_a hierachy 
> and create needed relationships between classes. Therefore, 
> in the FuGE model there will be a reference to use an 
> ontology term from some source and in some cases this will be 
> FuGO that contains the term. In other cases where an existing 
> ontology has already been designed, e.g. Foundational Model 
> of Anatomy, a term from this ontology will be used. FuGE 
> provides a mechanism to state which ontology the term was 
> obtained from so this will be present.

Hiearchy is not modulization.  A tree is a tree, unless its braches can
exist independently.  Whether an ontology is structured or not, btw, which
ontology does not have a structure? has nothing to do with if the ontology
is monolithic or not.
 
Xiaoshu

Received on Friday, 7 July 2006 20:02:42 UTC