Sorry for the last-thing-Friday post... It's for information only, thankfully.
For those still interested, this is a reasonable work-around:
1. using the GUI, inherit the "channel 1" sample's annotation (just click one
checkbox) for each hyb in your experiment. (Or hack the base1 migration
code.)
2. in your API code, use the following determine if your sample is "channel 1"
(or not) with respect to a given hyb
Hybridization hyb = ...;
Sample sample = ...;
boolean isChannel1 = false;
try {
ItemQuery<AnnotationSet> iasq =
hyb.getAnnotationSet().getInheritedAnnotationSets();
iasq.include(Include.SHARED);
ItemResultList<AnnotationSet> ias = iasq.list(dc);
if (ias.contains(sample.getAnnotationSet()))
isChannel1 = true;
} catch (Exception ex) {
// do nothing
}
So in our simplified gene expression API we can retrieve the samples in
channel order. Hurrah. (The try/catch is needed to ignore permissions
problems for a guest user when no annotationsets exist.)
Of course this doesn't work for 3 or more channel data. Are we really
likely to come across it?
cheers,
Bob.
Bob MacCallum writes:
>
> Sorry for the long delay in this thread.
>
> I guess one way around this for us is to have the rawbioassay inherit from
> the
> "channel 1" biosource as you recommend, and through the API go and get the
> annotations from both samples or biosources. One of the biosources will have
> the same annotation as the rawbioassay, this is therefore ch1, the other one
> by elimination is ch2.
>
> Nicklas Nordborg writes:
> > Bob MacCallum wrote:
> > >
> > > Nicklas Nordborg writes:
> > > > I really don't see how a 'channel' attribute could help answer that
> > > > question. Everything upstreams of the raw bioassay is generally
> speaking
> > > > not accessible in the analysis module. The only upstreams
> information
> > > > you can use are annotations that have been inherited to the raw
> > > > bioassays and specified as experimental factors of the experiment.
> For a
> > > > single raw bioassay this should be either 'male' or 'female'. The
> > >
> > > So even though the two samples/biosources each have an annotation (one
> "male"
> > > one "female"), you would recommend that the raw bioassay should inherit
> only
> > > from one.
> >
> > By default inheriting multiple annotations of the same type is reported
> > as an error by the experiment validator tool. This can of course be
> > changed to warning or ignore, but I suspect that downstream analysis
> > tools and plug-ins can get confused. The tools/plug-ins we have created
> > are works on the bioassay level as the smallest entity, ie. if you
> > create group things together the entire bioassay must belong to the same
> > group. It seems like your case wants ch1 to belong to the "male" group
> > and ch2 to belong to the "female" group (or the other way around).
> >
> >
> > > As discussed here:
> > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00907.html
> > > inheriting from more than one item leads to undefined behaviour.
> >
> > This is a bug that has been fixed in the 2.5 release.
> >
> >
> > > I'd like to suggest that one should be able to inherit annotations from
> > > multiple biosources in a defined order (e.g. ch1, ch2).
> > >
> > > Alternatively, some innate ordering of the labelled extracts with
> respect to
> > > hyb (again in channel order).
> >
> > None of the above seems possible with the current database design and
> > backwards compatibility issues. It would be a thing for BASE 3.
> >
> > Even if that information did exist in the database, there is no
> > guarantee that the data was imported in that way. That would require the
> > importer to be more intelligent than just copying values from a text
> > file column into the database. It would have to match the "dye" for the
> > column to a labeled extract's dye and then verify this against what
> > has been defined in the raw-data-types.xml file. But, everything can
> > still be re-linked to other items after the import so it could still not
> > be "trusted".
> >
> > /Nicklas
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > basedb-devel mailing list
> > basedb-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/basedb-devel
>
> --
> Bob MacCallum | VectorBase Developer | Kafatos/Christophides Groups |
> Division of Cell and Molecular Biology | Imperial College London |
> Phone +442075941945 | Email [EMAIL PROTECTED]
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> basedb-devel mailing list
> basedb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/basedb-devel
--
Bob MacCallum | VectorBase Developer | Kafatos/Christophides Groups |
Division of Cell and Molecular Biology | Imperial College London |
Phone +442075941945 | Email [EMAIL PROTECTED]
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
basedb-devel mailing list
basedb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/basedb-devel
