Mbirn: Workflow Updates

From NAMIC Wiki
Jump to: navigation, search
Home < Mbirn: Workflow Updates

UPDATES

11/07/2005: Outcomes from BIRN AHM, 2005 (J. Jovicich)


8/29/2005: Minutes from Workflow meeting Aug 4, 2005 (S. Murphy)

  • Next meeting: Thursday, 9/1, at 4:00 EDT
  • Present were:
    • Arthur Toga, Michael Pan, Jeff Grethe, Anthony Kolasny, Steve Piper, David Kennedy, Michael Mendis, Shawn Murphy
  • Discussion topics:
    • The UCLA group was interested in following up with the use of Freesurfer in a workflow, but did not have the source code to work with. Their contact person at the MGH was identified as Nick Schmansky (nicks@nmr.mgh.harvard.edu) who is working with Bruce Fischl to support the distribution of Freesurfer. The UCLA group was also interested in a specific application of Freesurfer that could be used for demonstration purposes. They wished to have a workflow that did not involve user interactions. David pointed out that there were no real-world workflows for Freesurfer that currently existed, that did not involve some kind of user interaction. It was not clear how this would be resolved, but using workflow fragments that did not involve user interaction for a demonstration was suggested.
    • The second topic concerned the development of agendas for the All Hands Meeting with regard to workflows. I suggested that having a Kepler User Document geared specifically for using Kepler "out of the box" with imaging applications and a kind of Tutorial to accompany it would be a good idea. The UCLA group could have one for the LONI pipeline, and Anders/Burak could have one for their workflow application. No specific follow-up action items were made at a group level as this identified site-specific action items that could be managed at the local sites.


05/17/2005 (S. Murphy)

  • S. Murphy & M. Mendis prepared a report (see below) that provides an understanding of the capabilities of currently defined Working Definition Languages (WDLs), which are the instructions that 'Workflow Engines' or 'Processing Pipelines' use. The report aims also at understanding the complexity of transformations that could take one WDL to another. In the context of mBIRN, if such transformations were possible, each site could run their own workflow engine, achieving interoperability by transforming one WDL into another.
  • The report has been distributed and the goal is to have a meeting in June or July to make the next set of decisions that can help us start building a common framework for the existing and rather different available pipelines.
  • Analysis Pipelines and Interoperability in mBIRN
    • The ability to send image data through a succession of software programs is critical for the successful analysis of complex imaging data. Applications that oversee this process are called “Workflow” engines, and their processing can be digested into machine-readable lists of instructions know as a “Workflow definition languages” (WDLs). Workflow engines of various kinds (Kepler, LONI, jBPM, TCL scripts) exist at the various mBIRN sites. Given the potential importance of workflow engines in performing image calculations, it would be of great interest to the mBIRN to adopt a common WDL language or WDL interconversion process that allows a workflow to be run at any of the mBIRN sites. The purpose of this report is to provide an understanding of the capabilities of the WDLs that are currently defined, and to understand the complexity of transformations that could take one WDL to another. In the context of mBIRN, if such transformations were possible, each site could run their own workflow engine, achieving interoperability by transforming one WDL into another. We found that the WDLs underlying the “scientific” workflow applications (MoML, XScufl, SWFL, possibly LONI pipeline) were similar in structure and are potentially interoperable, while the WDLs for business applications (BPEL4WS, WSFL, XPDL) are not. However, even the scientific WDLs could only be interconverted if there would exist a common repository of data type definitions and software modules such that they are available to perform the computations within the workflows.

Download "Analysis Pipelines and Interoperability in the Morphometry Biomedical Informatics Research Network" (with full appendixes) as a Microsoft Word document

Download "Analysis Pipelines and Interoperability in the Morphometry Biomedical Informatics Research Network" (with full appendixes) as a PDF file


04/01/2005 (J. Jovicich)

  • Pipeline Specifications: We will attempt to combine the various parts of the analysis pipelines that have been used to date, either at the level of specifications or code. At the level of specifications, the requirements for these are expressed as a pipeline definition language. Since analysis pipelines in science are roughly equivalent to workflow definitions in business, we are also looking to business for workflow specifications. In business, as in science, workflow definition languages are used to embody the requirements for the workflow applications. Current business workflow languages that appear to embody some of our requirements are the XML Process Definition Language (XPDL, sponsored by the Workflow Management Coalition) and the Business Process Execution Language for Web Services (BPELWS, sponsored by a coalition of BEA, IBM, Microsoft, SAP AG and Siebel Systems). Scientific analysis pipeline languages that appear to embody some of our requirements include XML Simple Conceptual Unified Flow (XScufl, sponsored by the myGrid project), Modeling Markup Language (MoML, sponsored by the Kepler project), and Laboratory of Neuro Imaging XML Workflow Representation (LONI-XML, sponsored by the Laboratory of Neuro Imaging).
  • Pipeline Architecture: The requirements of the pipeline will be defined to a great extent in the XML specification of the workflow. The agreement to work on this XML specification was made at the March 2005 mBIRN All Hands Meeting. The evolving architecture of the actual workflow application will be described (mBIRN Pipeline Arquitecture concept). However, the adoption of existing applications (such as the LONI pipeline) as a starting point to build the architecture is highly desirable. The architecture later described would then be layered upon the existing application and evolve in an mBIRN open source setting.
  • LONI: Ongoing developments on the data processing LONI pipeline have led to publications that validate its use as a processing and visualization environment that can facilitate neuroscience research (see Mbirn: Recent Publications). There has been significant work on a major new pipeline release [1].
  • Updates from Miami meeting (March 2-5, 2005)


2/03/2005 (Heidi Schmidt)

  • Collaboration/brainstorm initiated for design specs (H. Schmidt & M. Mendis)
  • Automated Freesurfer segmentation first focus (steps 1-3 of FreeSurfer process)
  • pipeline languages under review and contacting key stakeholders
  • Goal for March Miami meeting is to have an architecture mock up to solicit feedback and ideas from the overall BIRN team.

Associated details:

  • Meeting with Data Provenance to work in BIRN XML standards aka XML namespace work in progress Demonstration/Information_session_being_held_2/8/05_1:00_PM_at_BWH Contact Jonathan Sacks if interested in attending this meeting in person or remote.
  • Meeting with Ravi at MGH regarding Siemens special tags sections for DICOM headers (requires prep work with dcmdump to examine total headers for what is relevant to tracking)
  • Collaborating with Doug Greve to get feedback and align with fbirn efforts

--User:Bboop 09:56, 10 Mar 2005 (EST) Heidi Schmidt