Requirements of a Provenance Model
In order to provide a generic provenance structure for all kinds of data objects, the provenance model must meet the following requirements:
Unified Framework: The model must be able to represent metadata provided by the various provenance systems. Although a number of system-call based provenance architectures (Frew, Metzger, & Slaughter, 2008) (Muniswamy-Reddy, Holland, Braun, & Seltzer, 2006) have been proposed to capture file provenance, there is no well defined model to represent and organize such low level metadata. One important goal for any comprehensive provenance model is to bridge this gap and provide a unified model able to represent provenance for any kind of data at any abstraction layer. To this end, it is crucial to identify a comprehensive set of features that can characterize the existing provenance systems and systemize provenance management.
Provenance Granularity: Provenance may be fine-grained, e.g. provenance of data tuples in a database (Woodruff & Stonebraker, 1997), or coarse-grained, such as for a file in a provenance-aware file system (Muniswamy-Reddy, Holland, Braun, & Seltzer, 2006) or for collections of files generated by an ensemble experiment run (Plale, Gannon, Reed, Droegemeier, Wilhelmson, & Ramamurthy, 2005). The usefulness of provenance in a certain domain is highly related to the granularity at which it is recorded (Simmhan, Plale, & Gannon, 2005). Thus, the provenance model should be flexible enough to encapsulate various subjects and details of provenance based on user specifications.
Security: The model must support provenance security. Access control and privacy protection are primary issues in provenance security (Groth, et al., 2006). The problem of access control for provenance is complicated by the fact that different access control policies, possibly from different sources, may have to be enforced. Moreover, the data originators may specify personal preferences on the disclosure of particular provenance information. To meet these requirements, the provenance model must support the specification of privacy-aware fine grained access control policies and user preferences.
Interoperability: A data object can be modified by and shared among multiple computing systems and so is the provenance. To support provenance exchange, the model must support interoperability among provenance models and integration of provenance across different systems. Thus the model must conform to the Open Provenance Model (OPM), which provides a high level representation of provenance focusing on interoperability.
Provenance Queries and Views: The model should support various types of provenance queries. Historical dependencies as well as subsequent usages of a data object should be tracked easily.
If a data is processed in multiple system domains, an administrator might want to see a high level machine, system or domain view of the provenance graph. In addition, to find relevant information from large provenance graphs, one should be able to filter, group or summarize all/portions of provenance graphs and to generate tailored provenance views. Thus, the model should be able to distinguish the provenance generated from different systems and facilitate queries for constructing specialized views of provenance graphs.