Modules

Status options?

Planned	Scheduled to start work
W.I.P.	Currently under development
Prototype	One or more first implementations exists for review
Draft	Working towards final version, working demo
Finished	Module is done, but can undergo fixes or small changes

List of modules

Name	Description	Applications	Status	Screenshot
StudyBook	Shows an overview of elements in a study, for example InvestigationElements?, Data and Files.	XGAP, Pheno, NGS	Prototype
MatrixViewer	Browse matrix data, allows twodimensional filtering, sorting and searching.	xQTL, AnimalDB	Prototype
Auth	Allows..	All ?	Draft
ExcelWizard	Import any MOLGENIS data into your database using Excel files	All ?	Draft
JobManager	Monitor and manage computational jobs	xQTL, NGS	Prototype
Heatmap	View matrix data as an adjustable heatmap	xQTL	Draft

Status: this is under development for MOLGENIS 4.0 Don't expect this if you use MOLGENIS 3.x!

Architectural overview

MOLGENIS is organized as a set of modules which we call plugins. Each plugin adds a combination of

• MolgenisModels? - models that use the domain specific language to define functionality compactly
• MolgenisGenerators? - templates that expand the models into working software
• MolgenisComponents -

and/or handwritten code. Other plugins may extend other plugins to yet add more functionality. The first plugin where all others build upon is the MOLGENIS database core. The last plugin is typically a fully functional application that assembles other plugins

TODO core architectural picture.

TODO directory structure

TODO concept of extension points

Extension mechanism

Each building block may add framework code, model extensions, generators and/or models. In this last case the module may regeneration against the last versions before it can be used (which we can do automatically?). After that we could use a osgi drop in mechanism to add the produce funtionality into a running system.

Design 0: simply link to projects In this procedure the model files are puth on classpath and can be simply imported. The code has to be generated by the imported projects themselves. This is ideal for development (as long as re-generation is a one push on a button event and checks if generators are changed (hash or something)).

Design 1: linking in code We imagine a procedure where when a user runs the generator (ant script, nothing else)

• downloads the core molgenis and starts the model parser/generator
• when <import="db" .../> is in your local model dependencies are automatically checked out from svn to /generated/java (incl libs!)
• each of these dependencies is regenerated in dependency order
• tests run to verify that the modules are sanitized (no compile errors, test cases work)
• and then produced as osgi modules that are simply loaded by the current project during the rest of development

And have a 'clean' action to redo the procedure.

Design 2: downloading maven/osgi modules. We imagine a procedure where when a user runs the generator from maven (maven pom + molgenis core as plugin, nothing else)

• downloads all depedencies using maven model (all MOLGENIS settings should be in this model as well to keep it simple?)
• add generate tasks to maven to get all stuff done

Complicating factor here is that the maven repos should be rebuild now and then.

We could allow both design 1 and 2 in order to speed up development?

i.e. organize maven compatible but still allow ant.xml type of interactions to do this low-tech. Or use maven in the back and don't necessarily bother the user with it.

Core modules

These are the foundational building blocks that can be reused between all MOLGENIS applications. Package org.molgenis.*

Core:

• core? - core platform of model (parsers), generators and util packages
• db? - database interface framework on top of MySQL, PostgreSQL and HypersonicSQL (extends core)
• exchange? - file import/export mechanisms from and to csv, tab, excel, (xml), etc (extends db)
• api? - application programming interfaces to Java, R, REST, SOAP, RDF, etc on top of Db (extends exchange)
• ui? - web user interface framework with forms, menus and plugins (extends api)
• compute? - compute interface framework for short, long and parallel running computations (extends ui?)

Discussion: ui could be moved to depend on core only, and then have other packages extend on that to add particular UI components for db, compute, etc. Or have separate ui extensions like ui.db, ui.compute, etc.

Components

These are the semi-finished building blocks that can be shared between different applications to reuse common work. These components typically provide data model (modules) that need to be generated before a plugin is ready to use. Hence, there is a need to regenerate on the first installation of the plugin. package org.molgenis.*

Cross cutting:

• auth? - secure authentication and sharing framework (extends ui)
• versionable? - mechanism to have versioned data elements by simply extending an interface

Discussion: need ability to weave this in later, like a special decorator that is applied everywhere? Or should we just make these core features and move it into db package?

Generic:

• molgenisdata.onto? - for using ontologies including tree based browser, search box (extends ui)
• molgenisdata.matrix? - for working with matrix like data having 'dimensionelements' and 'dataelements'
• molgenisdata.protocol? - for track and tracing of materials/data, protocols, protocolapplications (compatible with MAGE-TAB SDRF)
• tool? - for integrating R scripts onto the application (extends protocol, compute)
• tool? - for integrating R scripts onto the application (extends protocol)

Domain:

• locus? - tools for managing and browsing genomic sequence annotations
• pheno? - for representing deep phenotypic data collected in clinics and the field (extends onto, tracker, matrix)
• muta? - for working with mutating data conforming to HGVS nomenclature (extends pheno)

More ideas: pedigree, comments

Applications

Systems are ready to use and download. Ideally end users would be able to choose from these online.

• PhenoTracker? - for storing phenotypics annotations on individuals and panels
• GwasPlatform? - for GWAS studies like in EU-GEN2PHN, LifeLines and BBMRI-NL
• QtlPlatform? - for QTL studies in model organisms like EU-Panacea
• MutationTracker? - for locus specific annotations (extends pheno, muta)
• SequenceArchive? - for storing, QC-ing and releasing short read data from NGS

Ideas for more enhancements

Core

• ui.theme? - catalog of UI web themes for MOLGENIS applications the use can choose from (extends ui)
• ui.iphone? - iphone user interface (extends ui)
• db.versionable? - to allow versionable data entry
• api.observer? - mechanism to observe and log activity for tracking and tracing
• api.feed? - atom feeds + command in UI to observe data, queries and/or transactions (extends api, ui) ui
• ui.gwt? - rich client application generator based on GWT