RE: how to deal with different requirements for experiment self-publishing

Hi All,
 
"On one end, some researchers want a quick and easy way to share an
experiment, e.g. simply decompose an experiment to hypothesis, data,
results, procedure, protocols used, who did it, what project it belongs
to, etc."
 
Even stronger, at a high level this is what a researcher wants to see
and can comprehend rapidly.  This is why in FuGE, this is what is
pre-eminent, and the tools in this domain typically allow visualization
of this level of detail.  The other thing to note is that an Experiment
is a series of events and products that will only occur once, that is,
the production of a sample from a cell line is unique, the hybridization
of a sample to a chip will be unique, the scan, they are all single
instances that will never occur again.
 
"On the other end of the spectrum, some researchers want to describe it
with domain-specific terms as detailed as possible, e.g using FuGO or
BioPAX terms.  In the middle of the spectrum,  one may want to describe
an experiment in general terms but with great details, e.g. using the
terms Bill Bug provided from BIRN."
 
But then as AJ says, the question becomes what is this experiment like,
who used similar tissue, what other experiment found a set of genes that
jumped out like in this experiment.  Different labs have a varying
number of resources to go further into this.  This is why in FuGE there
is no preconception of what annotation and how much will be used,
because, as AJ points out, there are varying views and abilities to do
the annotation.  If the annotation is available, it can be exported into
a FuGE document at what ever level is available.
 
We early on in MAGEv1 found ourselves trying to decide what
attributes/associations should a BioMaterial like a Cell Line have in
the UML model.  We quickly listed 50+, cut it back to 20, argued over
the ones left out, the ones left in, then punted by creating an
association to OntologyEntry called Characteristics.  In other words we
decided it would be better to let groups like this work out what and how
Characteristics could be annotated so that MAGE and now FuGE could
concentrate on allowing the sharing of experiments.
 
One of my interests in this list is to track annotation tools and
ontologies.  As they mature, if our users are interested, we will use
these tools and ontologies to enhance our product so that our users can
easily annotate their data.  This will then be reflected in our export
and available for others to import.  Then, I envision that semantic web
tools will be able to take this annotation (which I see separate and
independent of the semantic web tools but available to) and search for
interesting correlations.
 
my further 2c,
Michael

	-----Original Message-----
	From: public-semweb-lifesci-request@w3.org
[mailto:public-semweb-lifesci-request@w3.org] On Behalf Of AJ Chen
	Sent: Friday, July 07, 2006 12:43 AM
	To: public-semweb-lifesci@w3.org
	Subject: how to deal with different requirements for experiment
self-publishing
	
	
	All,
	>From the discussions so far, I see a whole spectrum of needs
for publishing experiment information.  On one end, some researchers
want a quick and easy way to share an experiment, e.g. simply decompose
an experiment to hypothesis, data, results, procedure, protocols used,
who did it, what project it belongs to, etc. On the other end of the
spectrum, some researchers want to describe it with domain-specific
terms as detailed as possible, e.g using FuGO or BioPAX terms.  In the
middle of the spectrum,  one may want to describe an experiment in
general terms but with great details, e.g. using the terms Bill Bug
provided from BIRN.
	
	Because of this diversity of requirements, I think it is not
realistic to expect one huge ontology will fit all. I would suggest we
think of this task in terms of multiple phases so that incremental
progress can be made within short time frame. In the first phase
(current phase), we focus on a small ontology that can be used to
develop quick and easy tools for self-publishing.  In the next phase, we
can add more granularity to it. In the third phase, we may figure out
how to bridge this general-purpose ontology to domain-specific
ontologies that are developed by other groups.  An alternative approach
is to have separate tasks to meet different requirements at the same
time.  
	
	What do you think? If we take the multi-phase approach, I would
suggest further discussions to be focused on the objective of the
current phase, i.e. a small and simple ontology.  If anyone likes the
multi-task approach, please consider to propose a new task. 
	
	
	AJ