New Semantic Types
Defining New Semantic Types in OME-XML
Semantic types (STs) are defined in XML according to the Semantic Type definition schema.
The following excerpt from OME Core Types
Instrument.ome
defines the ST Light-Source
.
<SemanticType Name= "LightSource" AppliesTo = "G"> <Element Name= "Manufacturer" DBLocation = "LIGHT_SOURCES.MANUFACTURER" DataType = "string"/> <Element Name= "Model" DBLocation = "LIGHT_SOURCES.MODEL" DataType = "string"/> <Element Name= "SerialNumber" DBLocation = "LIGHT_SOURCES.SERIAL_NUMBER" DataType = "string"/> <Element Name= "Instrument" DBLocation = "LIGHT_SOURCES.INSTRUMENT" DataType = "reference" RefersTo = "Instrument"/> </SemanticType>
When a ST definition XML file is imported into OME, it is interpreted to produce the appropriate database tables and columns. The ST's attributes are stored as rows of the ST's table:
ome=# select * from light_sources; attribute_id | model | instrument | serial_number | module_execution_id | manufacturer --------------+-------------------+------------+---------------+---------------------+-------------- 93 | WMD Laser | 92 | 123skdjhf1234 | 14 | Olympus 95 | Realy Bright Lite | 92 | 123skdjhf1456 | 14 | Olympus (2 rows)
Pixels and Derived Semantic Types
Attributes of ST Pixels
, defined in
Image.ome,
are different than other STs. The actual pixels, which can easily be
in the GBs, are stored on the OME Image Server and the
database stored attributes simply describe the pixels
(Semantic Elements: SizeX, SizeY, SizeZ, SizeC, SizeT, PixelType, FileSHA1
) and
give a reference to how the pixels can be accessed from OMEIS
(Repository, ImageServerID
).
A lot of logic in the OME backend deals with Pixel
's special
status. Pixels
's
uniqueness is unfortunately unavoidable -- we just can't store the
pixels in the database. There are many other BLOB-like STs such as
large matrices or vectors that are not Pixels
(i.e. must
have a different semantic type for clear data-modeling) and also
should be stored in OMEIS rather than in the database.
We have developed a special, ad-hock, sort of inheritance based on the Parent
semantic element for the Pixels
derived ST. Consider the
ST definition for FrequencySpace
ST. The Parent
SE is set to ST PixelsSlice
. If you follow a similar naming
convention for your STs, they will be transparently saved to and loaded
from OMEIS by the Analysis Engine handlers.
<SemanticType Name="FrequencySpace" AppliesTo="I"> <Description> The frequency space (i.e. the Fourier Transform of Real space) is, in general, complex. We represent it by its magnitude and phase rather than its real and imaginary parts. Magnitude(F) = sqrt (real(F)^2 + imag(F)^2). Also Phase(F) = atan(imag(F)/real(F)). The magnitude is encoded as channel 0 and the phase is channel 1 of the output pixels set. </Description> <Element Name="Parent" DBLocation="FOURIER.MAG_AND_PHASE" DataType = "reference" RefersTo = "PixelsSlice"/> </SemanticType>