Personal tools
You are here: Home Developer Infrastructure Teams Architecture Proposed changes to KAR

Proposed changes to KAR

Proposed changes to KAR

REAP needs a "publication ready archive". SANParks needs an archive that contains a workflow and reporting files. I propose we augment the KAR structure to be as similar as possible to the structure of a Kepler module (the specification for which can be found here <TBD add link to module structure specification>), but in addition contain any items needed by the two usecases above. Please add or comment on this as you see fit.


This is what a KAR file should be able to represent/contain:

    • one workflow
    • collection of workflows
    • one actor
    • collection of actors
    • one run
    • collection of runs
    • system extension module
Here's an example of an exploded KAR (it would be nice if this were made to be a fairly exhaustive example of everything a KAR could contain):
  • configs/
  • lib/
  • module-info/modules.txt
  • resources/
    • ?
  • runs/
    •    run1/
      • reportLayout
      • runMetadataMoml
      • workflowMoml
      • reportRoml
      • inputData/
      • outputData/
        • images
        • data
        • reportInstance
    • run2/
    • ...
  • src/
    •  List of contained objects and their KeplerLSIDs
RunMetadata (extended MoML)
    • points at KARFile KeplerLSID
    • points at ActorMetadata KeplerLSID
    • points at output data KeplerLSID(s)
ActorMetadata (extended MoML)
    • points at KARFile KeplerLSID

KARs, Runs and Workflows will all get unique KeplerLSIDs.
Discussion points: 
- If workflows are allowed to contain module-specific things (e.g. provenance recorder), the kar might be responsible for explaining and/or solving those dependencies (e.g. when someone tries to open the kar when not running the provenance module).
Document Actions