org.molgenis file format reference

This is documentation on the data exchange format for the 'org.molgenis' system.

To ease data exchange this system comes with a simple 'tab separated values' file format. In such text files the data is formatted in tables with the columns separated using tabs, colons, or semi-colons. Advantage is that these files can be easily created and parsed using common spreadsheet tools like Excel. An example of such tab delimited file is shown below: 

name	description	date
Experiment1	This is my first experiment	2010-01-19
Experiment2	This is my second experiment	2010-01-20
This document describes what file types and columns are defined for the 'org.molgenis' system. Data in this format can be uploaded to the database via the user interface using the 'File' menu). Alternatively, a whole directory of such files can be loaded in batch using the CsvImport program. The following files are currently recognized by this program (grouped by topic):

Below, the columns for each of these file types are detailed as well as example data shown (if available).

org.molgenis.compute.core file types

org.molgenis.compute.runtime file types

File: computetask.txt

Contents:
A protocolApplication that reports the application of running a ComputeProtocol.

Structure:
column name type required? auto/default description
name string YES   Unique name.
computerun_name
 xref YES   The run this task is part of. This xref uses {computerun_name} to find related elements in file computeRun.txt based on unique column {name}.
computescript text YES   The actual command to be sent to the cluster, is a filled in version of the one define in the ComputeProtocol.
outputenvironment text     Environment vars created by this step.
runinfo text     Summary of the task execution.
runlog text     Log of the task execution.
failedlog text     Failed log of the task execution.
interpreter enum YES   the interpreter used to run this command. For example 'shellTemplate'.
prevsteps_name
 mref     To keep track of calculation dependencies. This mref uses {prevsteps_name} to find related elements in file computeTask.txt based on unique column {name}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.
statuscode enum   generated Last known status of this task. See compute history for details. NB 'ready' means ready for running (cf. 'done').
submittedid string     ID received from the scheduler after submission; used only in clusters.
Contraint: values in the combined columns (name, computerun) should be unique.

File: computetaskhistory.txt

Contents:
Keep track of the compute history of a task, including resubmissions.

Structure:
column name type required? auto/default description
computetask_name
 xref YES   the task for which the history was collected. This xref uses {computetask_name} to find related elements in file computeTask.txt based on unique column {name}.
statustime datetime   today time of state change.
runlog text     field to show the content of the error file (only applicable on fail/done of a task).
statuscode enum     current status of this task.
newstatuscode enum YES   current status of this task.

File: computevm.txt

Structure:
column name type required? auto/default description
serverid text    
hostname text     host of VMs name.
floatingipextern text     IP open to internet.
floatingiptarget text     IP open to target environment.
finishedcomputetask_name
 mref     tasks, which are completed on this VM. This mref uses {finishedcomputetask_name} to find related elements in file computeTask.txt based on unique column {name}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.
failedcomputetask_name
 mref     tasks, which are failed on this VM. This mref uses {failedcomputetask_name} to find related elements in file computeTask.txt based on unique column {name}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.
starttime datetime     time, when VM is started.
endtime datetime     time, when VM is down.
isinuse bool   false indicate if compute tasks are currently executed on VM.
computerun_name
 xref YES   This VM is used for this run. This xref uses {computerun_name} to find related elements in file computeRun.txt based on unique column {name}.

File: computeparametervalue.txt

Contents:
Related to ComputeTask values .

Structure:
column name type required? auto/default description
name string YES   Unique name.
computetask_name
 xref YES   ComputeTask, to which the value belongs. This xref uses {computetask_name} to find related elements in file computeTask.txt based on unique column {name}.
value text YES   the value of the parameter.

File: computerun.txt

Contents:
A set of computetasks to run.

Structure:
column name type required? auto/default description
name string YES   Unique name.
creationtime datetime   today time of creation.
showindashboard bool   true Show this run in the dashboard.
computebackend_name
 xref YES   Backend where run will be executed. This xref uses {computebackend_name} to find related elements in file computeBackend.txt based on unique column {name}.
userenvironment text     Environment vars provided by the user.
submitscript text     The generated submit.sh to use only in the cluster scheduler environment.
polldelay long     Delay between two database ComputeTask polls.
isactive bool   false
issubmittingpilots bool   false
isdone bool   false
iscancelled bool   false
interpreter enum     the interpreter used to run this command. For example 'shellTemplate'.
hasfailedjobs bool   false
owner_username
 xref YES   This xref uses {owner_username} to find related elements in file molgenisUser.txt based on unique column {username}.
pilotssubmitted int   0
pilotsstarted int   0
Constraint: values in column name should unique.

File: pilot.txt

Structure:
column name type required? auto/default description
value text YES  
owner_username
 xref YES   This xref uses {owner_username} to find related elements in file molgenisUser.txt based on unique column {username}.
backend_name
 xref YES   This xref uses {backend_name} to find related elements in file computeBackend.txt based on unique column {name}.
computerun_name
 xref YES   This xref uses {computerun_name} to find related elements in file computeRun.txt based on unique column {name}.
computetask_name
 xref     This xref uses {computetask_name} to find related elements in file computeTask.txt based on unique column {name}.
creationtime datetime   today time when pilot was submitted.
lifeterm int   120 term after which pilot id expires in minutes.
status enum YES  

File: computebackend.txt

Structure:
column name type required? auto/default description
name string YES   Unique name.
backendurl string YES   Backend host.
hosttype enum YES   type of the host.
command string     Command to be executed.
scheduler string     scheduler, that is used in backend.
rootdir string     root directory for all analyses.
Constraint: values in column name should unique.

org.molgenis.omx.core file types

File: molgenisentity.txt

Contents:
Referenceable catalog of entity names, menus, forms and plugins.

Structure:
column name type required? auto/default description
name string YES   Name of the entity.
type_ string YES   Type of the entity.
classname string YES   Full name of the entity.
Constraint: values in column classname should unique.
Contraint: values in the combined columns (name, type_) should be unique.

File: runtimeproperty.txt

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
value text YES  
Constraint: values in column identifier should unique.
Constraint: values in column name should unique.

File: freemarkertemplate.txt

Structure:
column name type required? auto/default description
name string YES   Name of the entity.
value script YES  
Constraint: values in column name should unique.

org.molgenis.omx.observ file types

Observ-OM is a model to uniformly describe any phenotypic, genotypic or molecular observation. The four core concepts are:

File: characteristic.txt

Contents:
Characteristics are yes-no statements about things in the world. These can be used as part of an observation, as parameter of ObservableFeature ('measuredCharacteristic'). For example: 'What is allele of [Marker]', here the [Marker] is a characteristic. Also, Characteristics can be used as target of observation. Typical examples are 'Individual' or 'Panel'. But also 'Marker' can be an Target when asked the question 'QTL p-value for [phenotype]': here both target and feature are characteristic, for example 'leave count' (phenotype characteristic) and 'PVV4' (marker characteristic).

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
Constraint: values in column identifier should unique.

File: observationtarget.txt

Contents:
ObservationTarget defines subjects of observation, such as Individual, Panel, Sample, etc. For instance: 'target 1' IS A 'Individual'.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
Constraint: values in column identifier should unique.

File: observablefeature.txt

Contents:
ObservableFeature defines anything that can be observed.

In other words, ObservableFeature are the questions asked, e.g. 'What is Height?', 'What is Systolic blood pressure?', or 'Has blue eyes?'.

Some questions may be repeated for multiple characteristics. For example 'What is [MarkerAllele] observed?' can be applied to all elements of a MarkerSet, and 'What is [medicin codes] uses' can be applied to a set of Medicine codes. This can be specified using the measuredCharacteristic field.

The identifier of ObservableFeature is globally unique. It is recommended that each ObservableFeature is named according to a well-defined ontology term or database accession.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
unit_Identifier
 xref     (Optional) Reference to the well-defined measurement unit used to observe this feature (if feature is that concrete). E.g. mmHg. This xref uses {unit_identifier} to find related elements in file ontologyTerm.txt based on unique column {identifier}.
definitions_Identifier
 mref     The concept that is being measured in a specific way.. This mref uses {definitions_identifier} to find related elements in file ontologyTerm.txt based on unique column {identifier}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.
datatype enum   string (Optional) Reference to the technical data type. E.g. 'int'.
temporal bool   false Whether this feature is time dependent and can have different values when measured on different times (e.g. weight, temporal=true) or generally only measured once (e.g. birth date, temporal=false).
minrange long     for numeric values this is used to set the 'min' value of the slider user interface.
maxrange long     for numeric values this is used to set the 'max' value of the slider user interface.
Constraint: values in column identifier should unique.

File: category.txt

Contents:
Category is partOf ObservableFeature to define categories for an ObservableFeature, such as the categorical answer codes that are often used in Questionaires. For example the ObservableFeature 'sex' has {code_string = 1, label=male} and {code_string = 2, label=female}. Category can be linked to well-defined ontology terms via the ontologyReference. Category extends ObservationElement such that it can be referenced by ObservedValue.value. The Category class maps to METABASE::Category .

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
observablefeature_Identifier
 xref YES   The Measurement these permitted values are part of.. This xref uses {observablefeature_identifier} to find related elements in file observableFeature.txt based on unique column {identifier}.
valuecode string     The value used to store this category in ObservedValue. For example '1', '2'.
definition_Identifier
 xref     The category that is being measured in a specific way.. This xref uses {definition_identifier} to find related elements in file ontologyTerm.txt based on unique column {identifier}.
ismissing bool   false whether this value should be treated as missing value.
Constraint: values in column identifier should unique.

File: protocol.txt

Contents:
The Protocol class defines parameterizable descriptions of (analysis)methods. Examples of protocols are: Questionaires, SOPs, Assay platforms, Statistical analyses, etc. Each protocol has a unique identifier. Protocol has an association to OntologyTerm to represent the type of protocol.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
protocoltype_Identifier
 xref     classification of protocol. This xref uses {protocoltype_identifier} to find related elements in file ontologyTerm.txt based on unique column {identifier}.
subprotocols_Identifier
 mref     Subprotocols of this protocol. This mref uses {subprotocols_identifier} to find related elements in file protocol.txt based on unique column {identifier}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.
features_Identifier
 mref     parameters (in/out) that are used or produced by this protocol.. This mref uses {features_identifier} to find related elements in file observableFeature.txt based on unique column {identifier}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.
requiredfeatures_Identifier
 mref     ........... This mref uses {requiredfeatures_identifier} to find related elements in file observableFeature.txt based on unique column {identifier}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.
root bool   false Indicator whether this protocol defines a workflow (e.g is the first protocol of a workflow).
active bool   true whether this protocol is considered active/inactive.
Constraint: values in column identifier should unique.

File: dataset.txt

Contents:
Container for one or more observations that are measured using the same protocol and by the same performer(s). The data set may be a file (having the same identifier) but in most cases it is a data table consisting of rows (Observation). This entity replaces ProtocolApplication.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
protocolused_Identifier
 xref YES   Reference to the protocol that is being used (if available). This xref uses {protocolused_identifier} to find related elements in file protocol.txt based on unique column {identifier}.
starttime datetime   today time when the protocol started.
endtime datetime   today (Optional) time when the protocol ended.
Constraint: values in column identifier should unique.

File: observationset.txt

Contents:
In practice: Observation is one row within a DataSet.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
partofdataset_Identifier
 xref YES   DataSet this ValueSet is part of.. This xref uses {partofdataset_identifier} to find related elements in file dataSet.txt based on unique column {identifier}.
time datetime     Time of this observationSet.
Constraint: values in column identifier should unique.
Contraint: values in the combined columns (partofdataset, time) should be unique.

File: observedvalue.txt

Contents:
Generic storage of values as part of one observation event. Values are atomatic observations, e.g., length (feature) of individual 1 (valueset.target) = 179cm (value). Values can also be qualified by some characteristic, e.g., QTL p-value (feature) between phenotype 'leaf count' (characteristic) and marker 'PVV4' (valueset.target) = 0.1^10+3 (value).

Structure:
column name type required? auto/default description
observationset_Identifier
 xref YES   Reference to the observation. For example a particular patient visit or the application of a microarray or the calculation of a QTL model. This xref uses {observationset_identifier} to find related elements in file observationSet.txt based on unique column {identifier}.
feature_Identifier
 xref YES   References the ObservableFeature that this observation was made on. For example 'probe123'.. This xref uses {feature_identifier} to find related elements in file observableFeature.txt based on unique column {identifier}.
value_id
 xref     The value observed. This xref uses {value_id} to find related elements in file value.txt based on unique column {id}.

org.molgenis.omx.observ.target file types

File: species.txt

Contents:
Ontology terms for species. E.g. Arabidopsis thaliana. DISCUSSION: should we avoid subclasses of OntologyTerm and instead make a 'tag' filter on terms so we can make pulldowns context dependent (e.g. to only show particular subqueries of ontologies).

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
ontology_Identifier
 xref     (Optional) The source ontology or controlled vocabulary list that ontology terms have been obtained from.. This xref uses {ontology_identifier} to find related elements in file ontology.txt based on unique column {identifier}.
termaccession string     (Optional) The accession number assigned to the ontology term in its source ontology. If empty it is assumed to be a locally defined term.
definition string     (Optional) The definition of the term.
Constraint: values in column identifier should unique.
Contraint: values in the combined columns (ontology, termaccession) should be unique.

File: individual.txt

Contents:
The Individuals class defines the subjects that are used as observation target. The Individual class maps to XGAP:Individual and PaGE:Individual. Groups of individuals can be defined via Panel.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
mother_Identifier
 xref     Refers to the mother of the individual.. This xref uses {mother_identifier} to find related elements in file individual.txt based on unique column {identifier}.
father_Identifier
 xref     Refers to the father of the individual.. This xref uses {father_identifier} to find related elements in file individual.txt based on unique column {identifier}.
Constraint: values in column identifier should unique.

File: panel.txt

Contents:
The Panel class defines groups of individuals based on cohort design, case/controls, families, etc. For instance: 'LifeLines cohort', 'middle aged man', 'recombinant mouse inbred Line dba x b6' or 'Smith family'. A Panel can act as a single ObservationTarget. For example: average height (Measurement) in the LifeLines cohort (Panel) is 174cm (ObservedValue). The Panel class maps to XGAP:Strain and PaGE:Panel classes. In METABASE this is assumed there is one panel per study.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
paneltype_Identifier
 xref     Indicate the type of Panel (example: Sample panel, AssayedPanel, Natural=wild type, Parental=parents of a cross, F1=First generation of cross, RCC=Recombinant congenic, CSS=chromosome substitution). This xref uses {paneltype_identifier} to find related elements in file ontologyTerm.txt based on unique column {identifier}.
numberofindividuals int YES  
species_Identifier
 xref     The species this panel is an instance of/part of/extracted from.. This xref uses {species_identifier} to find related elements in file species.txt based on unique column {identifier}.
individuals_Identifier
 mref     The list of individuals in this panel. This mref uses {individuals_identifier} to find related elements in file individual.txt based on unique column {identifier}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.
Constraint: values in column identifier should unique.

File: panelsource.txt

Contents:
PanelSources is partOf Panel to define how panels are related panels, founder panels, such as overlap, selection criteria, getting assayed panel from a sample panel, etc.

Structure:
column name type required? auto/default description
currentpanel_Identifier
 xref YES   Panel for which these sources are defined.. This xref uses {currentpanel_identifier} to find related elements in file panel.txt based on unique column {identifier}.
sourcepanel_Identifier
 xref YES   Source that contributed individuals to current panel. This xref uses {sourcepanel_identifier} to find related elements in file panel.txt based on unique column {identifier}.
numberofindividuals int     Number of individuals lifted over from this source.
selectioncriteria text YES   Inclusion/exclusion criteria used to select these individuals from source into current panel.

File: ontology.txt

Contents:
Ontology defines a reference to an ontology or controlled vocabulary from which well-defined and stable (ontology) terms can be obtained. Each Ontology should have a unique identifer, for instance: Gene Ontology, Mammalian Phenotype, Human Phenotype Ontology, Unified Medical Language System, Medical Subject Headings, etc. Also a abbreviation is required, for instance: GO, MP, HPO, UMLS, MeSH, etc. Use of existing ontologies/vocabularies is recommended to harmonize phenotypic feature and value descriptions. But one can also create a 'local' Ontology. The Ontology class maps to FuGE::Ontology, MAGE-TAB::TermSourceREF.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
ontologyaccession string     A accession that uniquely identifies the ontology (typically an acronym). E.g. GO, MeSH, HPO.
ontologyuri hyperlink     (Optional) A URI that references the location of the ontology.
Constraint: values in column identifier should unique.

File: ontologyterm.txt

Contents:
OntologyTerm defines a single entry (term) from an ontology or a controlled vocabulary (defined by Ontology). The identifier is the ontology term is unique. E.g. 'NCI:Antigen Gene'. Other data entities can reference to this OntologyTerm to harmonize naming of concepts. If no suitable ontology term exists then one can define new terms locally (in which case there is no formal accession for the term limiting its use for cross-Investigation queries).

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
ontology_Identifier
 xref     (Optional) The source ontology or controlled vocabulary list that ontology terms have been obtained from.. This xref uses {ontology_identifier} to find related elements in file ontology.txt based on unique column {identifier}.
termaccession string     (Optional) The accession number assigned to the ontology term in its source ontology. If empty it is assumed to be a locally defined term.
definition string     (Optional) The definition of the term.
Constraint: values in column identifier should unique.
Contraint: values in the combined columns (ontology, termaccession) should be unique.

File: accession.txt

Contents:
An external identifier for an annotation. For example: name='R13H8.1', ontology='ensembl' or name='WBgene00000912', ontology='wormbase'.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
ontology_Identifier
 xref     (Optional) The source ontology or controlled vocabulary list that ontology terms have been obtained from.. This xref uses {ontology_identifier} to find related elements in file ontology.txt based on unique column {identifier}.
termaccession string     (Optional) The accession number assigned to the ontology term in its source ontology. If empty it is assumed to be a locally defined term.
definition string     (Optional) The definition of the term.
Constraint: values in column identifier should unique.
Contraint: values in the combined columns (ontology, termaccession) should be unique.

org.molgenis.omx.auth file types

File: institute.txt

Contents:
A contact is either a person or an organization. Copied from FuGE::Contact.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES  
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
address text     The address of the Contact.
phone string     The telephone number of the Contact including the suitable area codes.
email string     The email address of the Contact.
fax string     The fax number of the Contact.
tollfreephone string     A toll free phone number for the Contact, including suitable area codes.
city string     Added from the old definition of MolgenisUser. City of this contact.
country string     Added from the old definition of MolgenisUser. Country of this contact.
Constraint: values in column identifier should unique.
Constraint: values in column name should unique.

File: person.txt

Contents:
Person represents one or more people involved with an Investigation. This may include authors on a paper, lab personnel or PIs. Person has last name, firstname, mid initial, address, contact and email. A Person role is included to represent how a Person is involved with an investigation. For submission to repository purposes an allowed value is 'submitter' and the term is present in the MGED Ontology, an alternative use could represent job title. An Example from ArrayExpress is E-MTAB-506 ftp://ftp.ebi.ac.uk/pub/databases/microarray/data/experiment/TABM/E-TABM-506/E-TABM-506.idf.txt. .
The FUGE equivalent to Person is FuGE::Person.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
address text     The address of the Contact.
phone string     The telephone number of the Contact including the suitable area codes.
email string     The email address of the Contact.
fax string     The fax number of the Contact.
tollfreephone string     A toll free phone number for the Contact, including suitable area codes.
city string     Added from the old definition of MolgenisUser. City of this contact.
country string     Added from the old definition of MolgenisUser. Country of this contact.
firstname string    
midinitials string    
lastname string    
title string     An academic title, e.g. Prof.dr, PhD.
affiliation_Name
 xref     This xref uses {affiliation_name} to find related elements in file institute.txt based on unique column {name}.
department string     Added from the old definition of MolgenisUser. Department of this contact.
roles_Identifier
 xref     Indicate role of the contact, e.g. lab worker or PI. Changed from mref to xref in oct 2011.. This xref uses {roles_identifier} to find related elements in file personRole.txt based on unique column {identifier}.
Constraint: values in column identifier should unique.
Constraint: values in column email should unique.

File: personrole.txt

Contents:
Seperate type of ontologyTerm to administrate roles.

Structure:
column name type required? auto/default description
identifier string YES   user supplied or automatically assigned (using a decorator) unique and short identifier, e.g. MA1234.
name string YES   human readible name, not necessary unique.
description text     (Optional) Rudimentary meta data about the observable feature. Use of ontology terms references to establish unambigious descriptions is recommended.
ontology_Identifier
 xref     (Optional) The source ontology or controlled vocabulary list that ontology terms have been obtained from.. This xref uses {ontology_identifier} to find related elements in file ontology.txt based on unique column {identifier}.
termaccession string     (Optional) The accession number assigned to the ontology term in its source ontology. If empty it is assumed to be a locally defined term.
definition string     (Optional) The definition of the term.
Constraint: values in column identifier should unique.
Contraint: values in the combined columns (ontology, termaccession) should be unique.

org.molgenis.omx.observ.value file types

File: value.txt

Structure:
column name type required? auto/default description

File: boolvalue.txt

Structure:
column name type required? auto/default description
value bool YES  

File: categoricalvalue.txt

Structure:
column name type required? auto/default description
value_Identifier
 xref YES   This xref uses {value_identifier} to find related elements in file category.txt based on unique column {identifier}.

File: datevalue.txt

Structure:
column name type required? auto/default description
value date YES  

File: datetimevalue.txt

Structure:
column name type required? auto/default description
value datetime YES  

File: decimalvalue.txt

Structure:
column name type required? auto/default description
value decimal YES  

File: emailvalue.txt

Structure:
column name type required? auto/default description
value email YES  

File: htmlvalue.txt

Structure:
column name type required? auto/default description
value text YES  

File: hyperlinkvalue.txt

Structure:
column name type required? auto/default description
value hyperlink YES  

File: intvalue.txt

Structure:
column name type required? auto/default description
value int YES  

File: longvalue.txt

Structure:
column name type required? auto/default description
value long YES  

File: mrefvalue.txt

Structure:
column name type required? auto/default description
value_Identifier
 mref YES   This mref uses {value_identifier} to find related elements in file characteristic.txt based on unique column {identifier}. . More than one reference can be added separated by '|', for example: ref1|ref2|ref3.

File: stringvalue.txt

Structure:
column name type required? auto/default description
value string YES  

File: textvalue.txt

Structure:
column name type required? auto/default description
value text YES  

File: xrefvalue.txt

Structure:
column name type required? auto/default description
value_Identifier
 xref YES   This xref uses {value_identifier} to find related elements in file characteristic.txt based on unique column {identifier}.

org.molgenis.omx.auth file types

File: molgenisuser.txt

Contents:
Anyone who can login.

Structure:
column name type required? auto/default description
username string YES  
password_ string YES   big fixme: password type.
activationcode string     Used as alternative authentication mechanism to verify user email and/or if user has lost password.
active bool   false Boolean to indicate if this account can be used to login.
superuser bool   false
firstname string    
middlenames string    
lastname string    
title string     An academic title, e.g. Prof.dr, PhD.
affiliation string    
department string     Added from the old definition of MolgenisUser. Department of this contact.
role string     Indicate role of the contact, e.g. lab worker or PI.
address text     The address of the Contact.
phone string     The telephone number of the Contact including the suitable area codes.
email email YES   The email address of the Contact.
fax string     The fax number of the Contact.
tollfreephone string     A toll free phone number for the Contact, including suitable area codes.
city string     Added from the old definition of MolgenisUser. City of this contact.
country string     Added from the old definition of MolgenisUser. Country of this contact.
changepassword bool   false If true the user must first change his password before he can proceed.
Constraint: values in column username should unique.
Constraint: values in column email should unique.

File: molgenisgroup.txt

Structure:
column name type required? auto/default description
name string YES  
active bool   true Boolean to indicate whether this group is in use.

File: molgenisgroupmember.txt

Structure:
column name type required? auto/default description
molgenisuser_username
 xref YES   This xref uses {molgenisuser_username} to find related elements in file molgenisUser.txt based on unique column {username}.
molgenisgroup_id
 xref YES   This xref uses {molgenisgroup_id} to find related elements in file molgenisGroup.txt based on unique column {id}.

File: userauthority.txt

Structure:
column name type required? auto/default description
role string YES  
molgenisuser_username
 xref YES   This xref uses {molgenisuser_username} to find related elements in file molgenisUser.txt based on unique column {username}.

File: groupauthority.txt

Structure:
column name type required? auto/default description
role string YES  
molgenisgroup_id
 xref YES   This xref uses {molgenisgroup_id} to find related elements in file molgenisGroup.txt based on unique column {id}.

Appendix: documentation of the mref tables

org.molgenis file types

File: computetask_prevsteps.txt

Contents:
Link table for many-to-many relationship 'ComputeTask.prevSteps'.

Structure:
column name type required? auto/default description
prevsteps_name
 xref YES   This xref uses {prevsteps_name} to find related elements in file computeTask.txt based on unique column {name}.
computetask_name
 xref YES   This xref uses {computetask_name} to find related elements in file computeTask.txt based on unique column {name}.
Contraint: values in the combined columns (prevsteps, computetask) should be unique.

File: computevm_finishedcomputetask.txt

Contents:
Link table for many-to-many relationship 'ComputeVM.finishedComputeTask'.

Structure:
column name type required? auto/default description
finishedcomputetask_name
 xref YES   This xref uses {finishedcomputetask_name} to find related elements in file computeTask.txt based on unique column {name}.
computevm_id
 xref YES   This xref uses {computevm_id} to find related elements in file computeVM.txt based on unique column {id}.
Contraint: values in the combined columns (finishedcomputetask, computevm) should be unique.

File: computevm_failedcomputetask.txt

Contents:
Link table for many-to-many relationship 'ComputeVM.failedComputeTask'.

Structure:
column name type required? auto/default description
failedcomputetask_name
 xref YES   This xref uses {failedcomputetask_name} to find related elements in file computeTask.txt based on unique column {name}.
computevm_id
 xref YES   This xref uses {computevm_id} to find related elements in file computeVM.txt based on unique column {id}.
Contraint: values in the combined columns (failedcomputetask, computevm) should be unique.