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


Forgot your password?
New user?
 

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):
---------------------
  • META-INF/MANIFEST.MF
  • configs/
  • lib/
  • module-info/modules.txt
  • resources/
    • ?
  • runs/
    •    run1/
      • reportLayout
      • runMetadataMoml
      • workflowMoml
      • reportRoml
      • inputData/
      • outputData/
        • images
        • data
        • reportInstance
    • run2/
    • ...
  • src/
---------------------
 
Manifest
    •  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