[ome-devel] questions about the well index

[josh.moore at gmx.de]

Bernhard Holländer writes:
 > Hi Josh!

Morning.

 > > Not necessarily. This is file format specific, so if you know that the
 > > format you're working with behaves this way then it's a fine
 > > assumption. Unfortunately, we can't guarantee it for all formats.
 > 
 > But what if I add the samples with the method above. Is it not
 > guarantied that the sample I get back from the end of the list of
 > samples is the one I just added (neglecting concurrency issues)? How
 > could I otherwise get the id of the new sample which I need to link it
 > to the screen acquisition?

Ah, sorry. I was thinking too far ahead. Since you (as a developer)
are in control of how things are being added, the code is completely
valid. For others who are reading data from some arbitrary HCS format,
care will need to be taken. Sorry for the confusion, but better safe
than sorry on the mailing list. :)

 > If you use the well_index to get the same well samples for an entire
 > plate, do you take care when there is a sample missing in a well. Say
 > well A1 has four samples but the acquisition in well A2 had problems
 > and only produced 2 samples, which are e.g the first and the last, the
 > second and third are missing.

It's possible to add nulls to the list if that is what you mean.

 > As far as I understand, if a plate is measured multiple times,
 > different screen acquisitions would be linked against different sets
 > of well samples. I assume well_index does not start again at 0 for the
 > other measurement. Eg:

Yes. It starts at 0 for each well. It's up to the client code to
create them in sync. Conceptually, Well.wellSamples is nothing other
than a List instance per well.
 
 > screen acquisition 1 -> ws 1 (well 1, well_index 0)
 >                                  -> ws 2 (well 1, well_index 1)
 > screen acquisition 2 -> ws 3 (well 1, well_index 2)  *)
 >                                  -> ws 4 (well 1, well_index {previous+1})
 > 
 > At *) I would prefer well_index 0 again, since this is the first field
 > of the second acquisition of well 1.
 
Right.

 > How about adding another container (WellSampleSet) that holds a
 > collection of well samples of one acquisition and this would have the
 > well index field. In addition this would make it easier for us to
 > store analysis results that are averaged over all samples in a well.
 > These could be saved as a WellSampleSet annotation.

Isn't that what ScreenAcquisition *-> ScreenAcquisitionWellSampleLink
<-* WellSample gets you? It doesn't have a defaultSample value field,
which we can discuss, but for the moment you could store that
information as an annotation on the ScreenAcquisition itself.

 > Thanks again! Bernhard

Cheers,
~Josh.