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