Modelling Provenance

1
Modelling Provenance

• Discussions

2
Introduction

• Provenance to be viewed as a global entity (not
  restricted to any particular work package)
• Only easy to collect data has been collected so
  far
• Varied reactions from users
• Cool youve got lots of data
• I need some higher level data for my boss
• Not what I expected

3
Queries a user may want to ask

• Is it worth running this experiment again?
• Report what services my lab has used in the past
  6 months
• How much do I trust this result?
• Can he/she analyse/query my provenance trace?
• Why should someone else trust my provenance
  trace?
• What are the other experiments that are similar
  to this one?
• Provenance on workflow templates (workflow
  collections)
• What data has been used recently?
• etc, etc.
• DQP (if integrated properly within myGrid) could
  expose a whole lot of different types of data
  query plan, hosts where the query executed

4
Provenance Types

• Derivation collected automatically, for
  example this result came from this workflow at
  this time
• Annotation Why did I do this?
• Can these two be considered the same or do they
  differ? Seem to be the same

5
Sources of Provenance

• Classes for updating MIR
• Workflow enactment engine
• Any services invoked
• Registry (dynamic discovery)
• User
• DQP
• As above

6
Short term issues

• Do we need control over provenance collection or
  does the service/workflow produce everything they
  can produce?
• Should the provenance system be configured when
  the RUN button in clicked?

7
Possible Provenance Architecture
Provenance Repository (mIR???)
Query I/f
Record I/f
library
User Annotation
User I/f
ReExec
Java client
DQP
Workflow Enactor
8
Issues and recommendations

• Too late for 3rd party repository implementation?
• Need to use mIR
• Specify interface to map high level queries and
  refine the low level interface to support them
• Initial recording could be done by storing XML
  doc
• Schema for provenance required