PROPUB: towards a declarative approach for publishing customized, policy-aware provenance

  • Authors:

  • Saumen C. Dey;Daniel Zinn;Bertram Ludäscher

  • Affiliations:

  • Dept. of Computer Science, University of California, Davis;Genome Center, University of California, Davis;Dept. of Computer Science, University of California, Davis and Genome Center, University of California, Davis

  • Venue:
  • SSDBM'11 Proceedings of the 23rd international conference on Scientific and statistical database management
  • Year:
  • 2011

Quantified Score

Hi-index 0.00

Visualization

Abstract

Data provenance, i.e., the lineage and processing history of data, is becoming increasingly important in scientific applications. Provenance information can be used, e.g., to explain, debug, and reproduce the results of computational experiments, or to determine the validity and quality of data products. In collaborative science settings, it may be infeasible or undesirable to publish the complete provenance of a data product. We develop a framework that allows data publishers to "customize" provenance data prior to exporting it. For example, users can specify which parts of the provenance graph are to be included in the result and which parts should be hidden, anonymized, or abstracted. However, such user-defined provenance customization needs to be carefully counterbalanced with the need to faithfully report all relevant data and process dependencies. To this end, we propose PROPUB (Provenance Publisher), a framework and system which allows the user (i) to state provenance publication and customization requests, (ii) to specify provenance policies that should be obeyed, (iii) to check whether the policies are satisfied, and (iv) to repair policy violations and reconcile conflicts between user requests and provenance policies should they occur. In the PROPUB approach, policies as well as customization requests are expressed as logic rules. By using a declarative, logic-based framework, PROPUB can first check and then enforce integrity constraints (ICs), e.g., by rejecting inconsistent user requests, or by repairing violated ICs according to a given conflict resolution strategy.