released-schema.2003-IR3.AnalysisModule.xsd Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of specification Show documentation
Show all versions of specification Show documentation
The OME Data Model specification
States module requirements.
Formal Inputs are optional because input requirements may be specified by guaranteed image attributes. For example, OME_Image_XYZ_stats requires a path to the OME repository file, and Dimensions.
These are given by <RawImageFilePath>, <sizeX>, <sizeY>, <sizeZ>, <sizeT>, and <sizeW>.
Specifies an input requirement for a module. Image dimensions and image file locations (repository or other format) should not be specified with this. Image dimensions are intrisic to an image. They do not represent a special requirement. Image file locations and contents are specified by other elements. Specifically, RawImageFile, RawImageFilePath, XYPlaneFile, and XYPlaneFilePath.
Tied to DB. Table FORMAL_INPUTS Column NAME
OME interprets this as a recommendation rather than a requirement.
Tied to DB. Table FORMAL_INPUTS Column USER_DEFINED
Tied to DB. Table FORMAL_INPUTS Column DESCRIPTION
References a SemanticType
Represented in DB as FORMAL_INPUT.ATTRIBUTE_ID
Specifies an output element of a module.
Tied to DB. Table FORMAL_OUTPUTS Column NAME
Tied to DB. Table FORMAL_OUTPUTS Column DESCRIPTION
Concerning MakeNewFeature attribute of ExecutionInstructions, if a new feature type is made, then there are two possible places a formal output attribute can be stored: It can be stored as an attribute of the FeatureIterator, or it can be stored as an attribute of the new Feature.
This tag is supposed to specify which. Can be left blank if module does not make new iterator.
Tied to DB. FORMAL_OUTPUTS.FEATURE_TAG
Processed before storage to DB
References a SemanticType
Represented in DB as FORMAL_OUTPUT.ATTRIBUTE_ID
Declares a table in the DB.
Maps to table DATATYPES during module import.
This specifies if this table is an attribute of Dataset, Image, or Feature.
Tied to DB. DATA_TABLES.ATTRIBUTE_TYPE
Tied to DB. DATA_TABLES.TABLE_NAME
Tied to DB. DATA_TABLES.DESCRIPTION
Describes valid values for an input. Think enumerations, (a list of valid values).
Tied to DB. LOOKUP_TABLES.NAME
Tied to DB. LOOKUP_TABLES.DESCRIPTION
Tied to DB. LOOKUP_TABLE_ENTRIES.VALUE
Tied to DB. LOOKUP_TABLE_ENTRIES.LABEL
An analysis module is defined by two things:
1) A program
2) An interface
A single program may have multiple interfaces. Why do you need multiple interfaces?
Pretend you have a program that calculates simple statistics on the pixels of an image. You can specify which statistics you want via parameters.
Typing
./stats -mean -sigma image1
will ouput
Image | mean | sigma
image1 12.4 1
Typing
./stats -geomean -mean image1
will output
Image | geomean | mean
image1 12.2 12.4
The outputs are completely different. You need to specify an interface for each of these behaviors.
Or pretend you have a powerful program that can do 10 unrelated tasks, each of which outputs an image. While the outputs are the same type and format, they represent 10 completely different things. In this case, it might make sense to define 10 corrosponding AnalysisModule to represent the 10 logical functions.
In any case, use AnalysisModule to define an interface and Program to store installation software for a program.
Describes an interface to use with a program.
PROGRAM_NAME in the database is a misnomer. It really should be changed to NAME.
Tied to DB. Table PROGRAMS Column PROGRAM_NAME
Specifies what category this program belongs to.
Tied to DB. Table PROGRAMS Column CATEGORY
Tied to DB. Table PROGRAMS Column DESCRIPTION
This is a stub for future development. The database location doesn't even exist yet.
If the output of the analysis will be the same when pixel positions are scrambled, the analysis is a stream algorithm.
Examples of stream algorithms are:
A statistics module that produces mean, geometric mean, standard deviation, etc. for pixel intensities.
A module to cross correlate pixel intensities across wavelengths.
Example of an algorithms that is not a stream algorithm is:
FindSpots. (It's a module to find blobs in an image.)
If a module is a stream algorithm, it can function across the x, y, z, and time dimensions.
Tied to DB. Table PROGRAMS Column IS_STREAM_ALGORITHM
As more handlers, are added, this part of the schema needs to be changed
Tied to DB. Table PROGRAMS Column MODULE_TYPE
Used to reference a Program Element. It should corrospond to a ProgramID specified in a Program Element.
Referential integrity is not enforced by this schema. That is, verification against the schema will not detect an error here if you make a typo.
If the module iterates over a feature, specify the iterator here. It will reference a feature via the TAG column of the FEATURES table.
An example of a module that does not iterate over a feature is Find Cells. It examines one image at a time, hence it iterates over an image, not a feature. It produces zero or more features (Çell) per image. These Cell features belong to an image.
This module would not get a FeatureIterator attribute.
An example of a module that iterates over a feature is Find Golgi. It examines one CELL at a time. A cell is a feature, hence the module iterates over features, not images or datasets. It produces zero or more Golgi features per Cell feature. These Golgi features belong to a Cell feature.
This module would get a FeatureIterator attribute of "CELL".
Tied to DB. Table PROGRAMS Column DEFAULT_ITERATOR
If this module makes new features, then the new Feature's name needs to be specified here.
If the module does not make new features, do not specify a value for this attribute.
Tied to DB. PROGRAMS.NEW_FEATURE_TAG
Stores an installation package and installation script for a program.
Referenced by AnalysisModule elements. Accordingly, each FormalOutput needs to be unique. Schema verification does not check for this. Verification against the schema will not detect an error here if you make a typo.
Program name.
Unclear how this would be used. DB location PROGRAMS.PROGRAM_NAME is populated by XML attribute AnalysisModule.Name.
Currently unused
Describes a binary file.
Describes a file location.
file location
Only necessary if file is compressed.
The script should interface with the OME API to find all information it needs. (i.e. installation path) It also needs to set the location of the program after the program is installed. The location should be set through the API, but it will propogate to the LOCATION column of the PROGRAMS table.
Contains a packaged or zipped installation files (binaries or source code).
This is a stub for future development. Don't bother with it unless you know more about it.
Specifies the packaging and/or compression format of the Installation file.
Specifies a column Name in the database.
Tied to database. DATA_COLUMNS.COLUMN_NAME
When it is necessary to generate a table and/or column in the Database, the importer needs to tell the database a datatype.
Not all SQL datatypes are supported currently.
Tied to DB. DATA_COLUMNS.DESCRIPTION
Defines a semantic type.
Restrictions:
Every SemanticElement must be in the same table.
Notes:
Granularity is infered from granularity of table.
Tied to DB. ATTRIBUTE_TYPE.NAME
Tied to DB. ATTRIBUTE_TYPE.DESCRIPTION
Tied to DB. ATTRIBUTE_COLUMNS.NAME
Tied to DB. ATTRIBUTE_COLUMNS.DESCRIPTION
References a Table
References a Column.
This, along with TableName, uniquely identifies a db location for this element.
Represented in DB as ATTRIBUTE_COLUMNS.DATA_COLUMN_ID