Roadmap

This milestone is a container for tasks that need to be done soon (not wish list) but are not part of the current milestone.

For the implementation of the graph representation of glycans in GRITS the project is divided in three parts:

  • Object model to represent the graph in memory
  • Substructure based algorithm to represent a set of input structures in the object model
  • Interactive GUI to represent the tree in GRITS.

Object model

  • Nodes: Glycans are nodes in the graph
    • Glycan
    • (optional) Meta data => used for decorators
    • (optional) can have a level
  • Edges: Relationships between glycans are the edges in the graph
    • Relationships can be: substructure, enzymatic precursor
    • (optional) meta data => used for decorators
    • Hidden or deselected property.
  • Graph
    • Mass spec application: Directed, no multigraph, disconnected graph
    • Pathway application: Directed, no multigraph, disconnected graph, cyclic

Mass spec application: Substructure based graph generation

  • Input is a set of glycans (from several dozen to more than 1.000 glycans)
  • Calculate the substructure dependency between these glycans
  • Build the graph based on these dependencies
  • Reduce number of edges by hiding edges
    • This may include human specified rules
    • No links to grandparents and grandchildren
    • Arbitrary select one path

GUI representation in GRITS

  • Representation
    • Draw glycans as nodes
      • (not preferable) use images (png, jpg)
      • (preferable) import from SVG as intact objects
    • Draw not hidden edges as connections
      • (optional) with arrowhead for direction
    • Alignment
      • Nodes should be non-overlapping
      • If the level feature is used nodes of the same level have to be on the same horizontal/vertical line
      • (optional) Connections should cross as less as possible
  • Interaction
    • Export/print graph (e.g. pdf)
    • Hide, unhide, remove edges
    • Remove nodes => interaction with other plugins
    • (optional) Drag and drop rearrangement of the graph

For the implementation of the Heatmap representation of glycomics data in GRITS the project is divided in three parts:

  • Object model to represent the data in memory
  • Clustering algorithm
  • Interactive GUI in GRITS

Object model

  • List of data sets (columns) with each data set
    • ID
    • Meta data
    • List of Properties with each property
      • ID
      • Numerical value
      • Meta data
  • (optional) Meta data related to the clustering

GUI representation in GRITS

  • Each cell is represented as colored square
  • Data sets ID in the bottom of the data area
  • Property ID on the right of the data area
  • A legend below to explain color scale based on numerical value
  • Coloring can be done linear, ex or ln(x) based
  • It is possible to define a lower and upper threshold
  • Interaction
    • Export/print graph (e.g. pdf)
    • Mouse over cell shows numerical value

Clustering

  • It should be possible to cluster
    • By data set only
    • By property only
    • By data set and property
  • Clustering only changes the order of properties and data sets in the data model and provides the information for the dendrogram

Aim is the implementation of the plugin that is specific for the service lab and contains functions that are only necessary for them:

Generate a bill proposal based on what analysts have uploaded

  • Creation of a management module
    • allows to classify each protocol into known protocols and new protocols
    • For each protocol a display name can be specified
    • Associate a set of costs with each protocol
      • static costs = total number given
      • Dynamic costs = amount is multiplied with the value of a parameter of the protocol
  • Generate a bill proposal for a project
    • go over all samples and find all protocols
    • for each "chargeable" protocol give the name, the total amount and the samples
    • output as word file

Validation of data completeness

  • Management module
    • Allow associating a Task (preference) with a list of protocols (known protocols) and a min and max number of protocols that need to be executed for each task
    • Allow associating of Protocols with files
      • Number of files of a type that need to be provide
      • Main category of the file
      • Sub category of the file
  • Implement a check function
    • can be triggered manually or as part of the bill proposal
    • gives a summary of inconsistencies
      • check if for each task (* number of task) enough protocols are present
      • check for each leaf in the protocol graph if a task is present
      • check if for each protocol the required files are uploaded

Notification email for samples

  • Management module that allows to associate people (preference) with email addresses
  • Preference for email settings
  • Function that can be called per project or per sample and shows the list of people, after user selection an notification email is send to the selected people

Generation of a Service lab report

  • Use the text templates associated with the protocols to generated a report stub with the description of the performed experiment
    • Tree structure of the experiment design need to be considered
    • Place holder need to be replaced with actual parameter values

Update parameter with information from uploaded files

  • Have separate menu options to upload certain files (NMR, MS) to protocols
  • These files are parsed and information is extracted and used to update the parameters in the protocol
  • Files are added to the right archive or archive is created first
  • Candidates for data extraction
    • NMR files = instrument time
    • MS files = number of scans

Upload of the final bill

  • File is stored in the project archive
  • Associated amount is separately

Ongoing milestone holding all tasks related to improvement of the web page and the development portal. This may include:

  • Documentation in the developer portal (Trac)
  • New pages on the main web site (WordPress)
  • New tutorials (Trac)

All tickets that are neither invalid nor rejected, but simply not part of our current road map. Manly tickets for enhancements that depend on somebody with time to make them happen. In order not to lose them we collect them under this milestone.

Note: See TracRoadmap for help on using the roadmap.