Re: ontology specs for self-publishing experiment

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.

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

> 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.
The goal of FuGO is to identify where the overlap in term needs exists and 
not duplicate this in separate ontologies.

Trish

Received on Thursday, 6 July 2006 18:30:51 UTC