1. 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

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

3. 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

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

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

6. 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

7. Layered Provenance

11. 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

12. 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

13. VisTrails Demo

14. 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

15. Mediator Architecture Mapping from global schema to data source specific schema

16. Mediated Provenance Mapping from general model to engine- specific model

17. 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

18. 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

19. Provenance Model

20. 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)

21. Provenance API Example getExecutedModules(wf_exec) VisTrails (XPath) def getExecutedModules(self, wf_exec): newdataitems = [] q = '//exec[@id="' + wf_exec.pid.key + '"]/@moduleId' 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)

22. 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:http://relation.org/softmean --> vt3:0 myg1:urn:www.mygrid.org.uk/process#reslice1 --> pas2:http://relation.org/softmean myg1:urn:www.mygrid.org.uk/process#reslice2 --> pas2:http://relation.org/softmean myg1:urn:www.mygrid.org.uk/process#reslice3 --> pas2:http://relation.org/softmean myg1:urn:www.mygrid.org.uk/process#reslice4 --> pas2:http://relation.org/softmean myg1:urn:www.mygrid.org.uk/process#align_warp1 --> myg1:urn:www.mygrid.org.uk/process#reslice1 myg1:urn:www.mygrid.org.uk/process#align_warp2 --> myg1:urn:www.mygrid.org.uk/process#reslice2 myg1:urn:www.mygrid.org.uk/process#align_warp3 --> myg1:urn:www.mygrid.org.uk/process#reslice3 myg1:urn:www.mygrid.org.uk/process#align_warp4 --> myg1:urn:www.mygrid.org.uk/process#reslice4

23. 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

24. 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

25. 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!

26. Questions?

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

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