VisTrails Second Provenance Challenge Tommy Ellkvist David Koop Juliana Freire Joint work with: Erik Andersen, Steven P. Callahan, Emanuele Santos, Carlos E. Scheidegger, Cláudio Silva, and Huy T. Vo

Outline VisTrails Introduction VisTrails Demo Provenance Model and API Challenge Results Issues and Future Work

VisTrails Comprehensive provenance infrastructure for computational tasks Support for exploratory tasks such as visualization and data mining Workflows are iteratively refined as users generate and test hypotheses New change-based provenance model Uniformly captures data and workflow provenance

Change-based Provenance Provenance is stored as a tree of actions add module add connection

Provenance: Storing Actions Each change writes new actions to the tree

Change-based Provenance Data provenance: where does a specific data product come from? Workflow evolution: how has workflow structure changed over time? Treat workflow versions as data–store provenance of workflows

Layered Provenance

VisTrails Provenance Normalized information–no redundancy! Each layer provides more specific information but refers to parent layers Workflow Evolution  Workflow  Execution Extensible storage options Support for both relational and XML Flexible annotation framework–users can specify application-specific provenance information

Provenance for Reproducibility and Beyond Infrastructure for querying and reusing provenance Query workflows by example Create workflows by analogy Collaborative exploration Scalable derivation of data products

VisTrails Demo

Supporting Different Provenance Backends VisTrails has powerful tools to query and reuse provenance information There are many powerful workflow systems that produce such information Problem: How to integrate different provenance backends? Our approach: A mediation-based approach to provenance interoperability

Mediator Architecture Mapping from global schema to data source specific schema

Mediated Provenance Mapping from general model to engine- specific model

Combining Provenance Establish model Produce an API for this model Wrap provenance access for each system so that queries become native over their provenance data

Provenance Model Follows the layered architecture Versions map to a workflows Workflows are modeled as graphs Parameters capture module state User-defined annotations are available at each layer of the model Module Definition stores information about the computational pieces

Provenance Model

Provenance API Implements common access queries and operations over the provenance model Examples: getParent(module) getChildren(module) getUpstream(module) getDownstream(module) getAnnotations(module | workflow | …) getDataItems(module_exec) getParameters(module) getVersion(time) getExecutedModules(workflow) getConnection(data_item) getPorts(connection) findModulesByParameter(search_params) findModulesByAnnotation(search_params) findExecutionsByAnnotation(search_params) findVersionsByModules(search_params)

Provenance API Example getExecutedModules(wf_exec) VisTrails (XPath) def getExecutedModules(self, wf_exec): newdataitems = [] q = + wf_exec.pid.key + dataitems = self.logcontext.xpathEval(q) Pasoa (XPath) def getExecutedModules(self, wf_exec): q = "//ps:relationshipPAssertion[ps:localPAssertionId='" + wf_exec.pid.key + "']/ps:relation" dataitems = self.context.xpathEval(q) Taverna (SPARQL) def getExecutedModules(self, wf_exec): " " q = ''' SELECT ?mi FROM WHERE { ?mi } ''' return self.processQueryAsList(q, pModuleInstance)

Provenance API Results Implemented queries for each system and a combination of all three Annotation issues for a couple queries Example: Query 1 Results vt3:4 --> vt3:7 vt3:1 --> vt3:4 vt3:0 --> vt3:1 pas2: --> vt3:0 myg1:urn: --> pas2: myg1:urn: --> pas2: myg1:urn: --> pas2: myg1:urn: --> pas2: myg1:urn: --> myg1:urn: myg1:urn: --> myg1:urn: myg1:urn: --> myg1:urn: myg1:urn: --> myg1:urn:

Provenance API Integration Developed VisTrails Provenance Query Language for first challenge Plan to integrate API with query language Plan to integrate query language with VisTrails interfaces

Interoperability Issues Uniquely identifying intermediate results Intermediate file names were not specified and varied Tracing ids is difficult for users–this should be transparent A common query language should use concepts familiar to users Mediator vs. Warehousing approach

Performance Issues Redundant information can make queries inefficient What is the best storage backend? RDBMS vs. XML database? What is the best data model? XML vs. Relational vs. RDF? Need good benchmarks–large data!

Questions?

Mediated Provenance User queries General Provenance Model wrapper Taverna Mapping from generic provenance model into the models of different systems Pasoa… Prov API

Mediator Architecture User SQL/ODBC queries Mediator Global Schema wrapper Data Source Mapping from global schema into source schemas Data Source Data Source