Personal tools
  • We're Hiring!

You are here: Home Documentation Previous versions OME Server Developer XML Schemas Semantic Types New Semantic Types

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>
Document Actions