 |
 |
 |
 |
 |
FCS 3.0 does an adequate, if cumbersome job, of providing a data interchange
format. However, most instrumentation manufacturers developed software that
would read FCS files that their instruments generated, and didn't put in much
effort to covering other cases (one manufacturer, in particular, actively made
it's software refuse to read FCS files from other sources, a stroke
of "marketing brilliance"). This was facilitated by the design of FCS - the
free form text header (keyword-values) contribute to the difficulty of
developing a general library to parse these values into usable form.
However, I don't believe that FCS per se is the cause of the difficulty Gunter
expresses for his second criteria - interfacing with databases for patient or
experiment management. A very important aspect has been consistently
overlooked by commercial software - a method for users to easily fill in the
necessary attributes for the FCS keywords. Much development has been spent on
generating flashy graphics whose axis are "intelligently" labeled FL1 and FL2 (or
P1 and P2). The combination of instrument configuration which would specify
measurement parameter color, (FITC, TexRed, etc.), parameter scaling (log,
lin), and other instrument conditions with sample attributes (source, cell
type, stains, etc.) could currently all be stored in FCS keywords and read into
various databases from them, satisfying mcuh of Gunter's second criteria. However
without the development of appropriate software for users to generate this
information, this won't happen. Moreover, I would think it appropriate for ISAC
to generate some standards on what these attribute values should be. It would
be very obnoxious to search your database for e.g. cd4 OR CD4 OR cd-4 OR CD-4
OR...
As a "proof of principle" let me summerize what we have done here. Since 1983
we have provided a klunky (compared to GUIs) "protocol editor" which allowed
users to generate a matrix of cell types and reagents. Our collection software
associated each element of this matrix with one or more collected samples. This
was combined, as indicated above, with instrument configuration parameters (from
our standardization program). Data collected during one FACS run is accessed
together as an "experiment" with an instrument, date, and user stamp. People
could browse an archive of old experiments and bring up data with graphs whose
axes were properly labeled and had reagent and cell type descriptions. Despite
its unfriendliness, most Facility users found that the benefits outweighed the
disadvantages and annotated their data. I think the lesson to be learned is that
if the capacity to annotate exists and is relatively easy to use, most of the
time it will be because the benefits are great.
-Marty Bigos
Stanford Shared FACS Facility
|
|
|
|
|
|
CD-ROM Vol 3 was produced by Monica M. Shively and other staff at the
Purdue University Cytometry Laboratories and distributed free of charge
as an educational service to the cytometry community.
If you have any comments please direct them to
Dr. J. Paul Robinson, Professor & Director,
PUCL, Purdue University, West Lafayette, IN 47907.
Phone: (765)-494-0757;
FAX(765) 494-0517;
Web