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
