Review of the ISAC Draft Requirements for a Cytometry/Analytical Cytology Data File Standard

1
Review of the ISAC Draft Requirements for a
Cytometry/Analytical Cytology Data File Standard
2
(No Transcript)
3

• Encode the required information to interpret a
  cytometry experiment
• Facilitate the reproduction of a cytometry
  experiment
• Efficiently store cytometry list mode data
• (Not relevant to image-based HCS)
• Transparently store text-based data
• Facilitate support for other analytical cytology
  data

4

• Each type of information shall be uniquely
  identifiable
• Use of Global Identifiers need to add our own
  ontology for image-based, plate-based HCS
• It shall be possible to resolve data files over
  the internet
• Each type of information shall only be stored in
  one file format
• As the core information in HCS is almost always
  image file data, does this mandate the use of a
  single image file format? Is this even workable
  for us?

5

• Support for future instruments
• Can we envision a future-proof way of storing
  image data?
• Provide semantic meaning to all
  required/standardized information
• My interpretation just means that everything in
  the standard is defined in a detailed fashion
• Extensible by third parties
• Could this possibly dilute the standard nature
  of the standard?

6

• Extensions shall be separated and removable from
  normative parts
• Ensure that metadata can always be located
• Implies either a packaging mechanism with
  internal links, or some kind of global metadata
  ID schema
• Support for use cases where new metadata are
  being added subsequently
• Is analysis just a form of metadata?

7

• Several instances of mutable information may
  share immutable information
• You can perform store multiple analyses or
  multiple interpretations of the same data
• Some information may be encoded by a referenced
  semantic model or an existing standard
• Use previously existing standards if applicable
• Does this imply acceptance of any sufficiently
  standard image file format?
• It shall be possible to refer to multiple
  semantic models or standards

8

1. Use a manufacturer-independent format
2. Use a programming-language independent format
3. Use a file/operating system-independent format
4. Use a simple format oriented on data
   interoperability
5. Describe the standard unambiguously

9

• There shall be an open-review period before
  adopting the standard
• There shall be a mechanism to formally validate
  the standard
• The standard shall be public
• An implementation of the standard shall be
  possible without charge
• The implementation of the standard shall be
  non-restrictive
• No licensing restrictions any known or hidden
  IP traps here?

10

• Reuse existing standards
• Cited examples CEN, DICOM, HL7, W3C, etc.
• Redundant?
• Conformance to standards shall be (easily)
  testable
• The file format shall be as self-explanatory as
  possible

11

• To obtain a copy of this document
• Ryan Brinkman (brinkman_at_bccrc.ca)
• Kurt Scudder (kscudder_at_accelrys.com)
• DIA SIG Website
• http//www.ravkin.net/SBS/DIA_SIG.htm
• Your comments are welcome! Please email to Ryan
  and/or Kurt