29.2.7. Experimental platforms and item subtypes

This section gives an overview of experimental platforms and how they are used to enable data storage in files instead of in the database. In some senses item subtypes are related to platforms so they are also included here.

See also

Figure 29.8. Experimental platforms and item subtypes

Experimental platforms and item subtypes

Platforms

The PlatformData holds information about a platform. A platform can have one or more PlatformVariant:s. Both the platform and variant are identified by an external ID that is fixed and can't be changed. Affymetrix is an example of a platform. If the fileOnly flag is set data for the platform can only be stored in files and not imported into the database. If the flag is not set data can be imported into the database. In the latter case, the rawDataType property can be used to lock the platform to a specific raw data type. If the value is null the platform can use any raw data type.

Each platform and it's variant can be connected to one or more DataFileTypeData items. This item describes the kind of files that are used to hold data for the platform and/or variant. The file types are re-usable between different platforms and variants. Note that a file type may be attached to either only a platform or to a platform with a variant. File types attached to platforms are inherited by the variants. The variants can only define additional file types, not remove or redefine file types that has been attached to the platform.

The file type is also identified by a fixed, non-changable external ID. The itemType property tells us what type of item the file holds data for (ie. array design or raw bioassay). It also links to a ItemSubtype which is the generic type of data in the file. This allows us to query the database for, as an example, files with the generic type FileType.RAW_DATA. If we are in an Affymetrix experiment we will get the CEL file, for another platform we will get another file.

The required flag in PlatformFileTypeData is used to signal that the file is a required file. This is not enforced by the core. It is intended to be used by client applications for creating a better GUI and for validation of an experiment.

The allowMultiple flag in PlatformFileTypeData controls if it should be possible to store more than one file of the given type in file type. Again, this is not enforced by the core, but only a recommendation to client applications. The setting is also used for validation of an experiment.

Item subtypes

The ItemSubtypeData class describes a subtype for a main itemType. In the simplest form the subtype is a kind of annotation that is used mainly for creating a better user experience. If the main item type is also implementing the FileStoreEnabledData interface, it is possible to register associations to the file types that can be used together with a given item subtype. The required and allowMultiple have are used in the same way as in the PlatformFileTypeData class.

A subtype can be related to other subtypes. This is used to "chain" together groups of item subtypes. For example, Hybridization is a subtype for PHYSICALBIOASSAY, which is related to the Labeled extract (EXTRACT) subtype which is related to the Label (TAG) subtype. In addition, there are also several protocol and hardware subetypes mixed into this. The relationship between subtypes makes it possible for client applications to filter out unrelated stuff, and to validate experiments.

FileStoreEnabled items and data files

An item must implement the FileStoreEnabledData interface to be able to store data in files instead of in the database. The interface creates a link to a FileSetData object, which can hold several FileSetMemberData items. Each member points to specific FileData item.