Analysis of Disease Outbreak Scenario

From XG Provenance Wiki
Jump to: navigation, search

Detailed analysis of the Disease Outbreak Scenario, which is scenario 2 of our group's requirements report.

Goals/Scope: Provenance Issues Highlighted in the Disease Outbreak Scenario


In this scenario, there are several distinctive uses of provenance:

  • repeatability: using provenance to rerun prior analyses with new data

User Requirements Specific to the Disease Outbreak Scenario

This section enumerates specific (provenance-related) user requirements from the scenario as described here, and gives reference to the relevant general user requirements listed in the requirements list.

  • Content
    • C-Attr-UR 1: Determine who contributed to a document (disambiguation).
    • C-Attr-UR 2: Record which content was created by which person (versions).
      • Eg: Who created the first version of the patient classification dataset?
    • C-Proc-UR 1: Relate agents to the (sub)process involved.
    • C-Proc-UR 2: It should be possible to reason on the outcome of a given process, assuming changes in their preconditions -- for example to consider hypothetical what-if scenarios.
      • Eg: What would be the result of the experiment if we change 2 different and compatible datasets?
    • C-Proc-UR 3: A process should be reproducible from its provenance graph.
    • C-Proc-UR 5: It should be possible to analyze the provenance of a process at different levels of granularity -- for example to drill down on justification for a result
      • Eg: Why have we obtained this outcome? Where does it come from?
    • C-Vers-UR 1: Determine how content changes (i.e. its version) across the web and who is responsible for those changes -- if a data source changes and is posted as a new version, you would need to update the integrated data and see what effects it has on the system.
      • Eg: Who is the author of the version 5.0 of the patient classification dataset?
      • Eg: How was the patient classification dataset changed from v3 to produce v5?
    • C-JUST-UR1: The end results of engineering processes or scientific studies need to be justified by linking to source and intermediate data.
    • C-JUST-UR1.1: The justification should distinguish between source and derived data, and show how intermediate results were obtained (Cf. C-PROC-UR-1, C-ENTAIL-UR-1, U-UNDER-UR-1, U-UNDER-UR-2)
      • Eg: Which datasets have been used for Alice's patient classification?
      • Eg: Is Gene K related to Bob's research?
      • Eg: Is patient classification dataset modified by Bob's research?
    • C-JUST-UR1.2: Links need to relate both public and confidential materials stored both online and offline (cf. C-ENTAIL-UR-6, M-DISS-UR-2)
    • C-JUST-UR2.1: Non-experts should be able to make basic judgments about the validity of the end results based on the supporting information, possibly using automatically constructed "executive summaries". (Cf. C-PROC-UR-3, C-PROC-UR-5, C-ENTAIL-UR-3, M-ACC-UR-2, M-ACC-UR-3, U-UNDER-UR4, U-IMPER-2)
    • C-JUST-UR2: The justification should facilitate informed discussion and decisions about the results.
    • C-JUST-UR2.2: Experts should be able to test the robustness of the conclusions by considering alternative steps or modeling choices, or identifying likely "points of failure" (Cf. M-DISS-UR-1, U-UNDER-UR-3, U-DEBUG-UR-1)
    • C-JUST-UR2.3: Automatic tools (by both experts and non-experts) should be able to perform basic checks of the authenticity, integrity and validity of the justification, to verify that a study or engineering process followed regulations, or to decide among different supported conclusions making competing claims (M-DISS-UR-1, U-INTER-TR1.3, U-ACCT-UR-1, U-COMP-UR1)
      • Eg: Why have I obtained that A is a human patogen responsible for owl flu in the experiment152?
      • Eg: Why step three took patient classification dataset v3 instead of owl dataset v5 in Bob's study?
    • C-JUST-UR3: The justification should be preserved so that the actual long-term behavior of a product, or effects of a policy can be compared with predictions.
      • Eg: Have the predictions for Bob's study come true when combining his data with Alice's experiment? Why?
    • C-JUST-UR4: As much as possible of the above processes should be automated, to reduce effort and ensure compliance with regulations.
    • C-Entail-UR 1 : Decide the trustworthiness of a reasoning process or a materialized view.
    • C-Entail-UR 7: Identify the transformation pattern used to derive conclusions.
      • Eg: How was patient classification obtained?
      • Eg: Which decisions has Bob taken to obtain the results his diagnosis?
    • C-Entail-UR 8: Identify the date and time of the derivation
    • C-Entail-UR 9: Identify any input information directly and indirectly used to derive conclusions
  • Management
    • M-Acc-UR 2: Given a set of provenance information, the user must be able to determine the source and authority of the provenance author
    • M-Acc-UR 4: Provide a way for stable provenance information to survive deidentification processes without endangering privacy.
    • M-Diss-UR 1: Verify that data, disseminated to some entity for processing, was processed for a purpose which was valid under some generally applied rules of validity, or as stated by the entity upon requesting the data.
    • M-Diss-UR 4: Check which uses of some data are affected by a change in that data, including those of remote, independent users who copied the data long before the change.
      • Eg: Would a change in Alice's dataset affect the result obtained in Bob's diagnosis?
  • Use
    • U-Under-UR 3: Be able to provide Subject Matter Experts (SMEs) with explanations of the rationale behind a certain outcome (domain)
    • U-Under-UR4: Enable users to approach the provenance graph at different levels of detail, e.g. enabling understanding for users of different levels of expertise, ranging from novice to expert (granularity).
      • Eg: For a novice user, Bob's study might show 3 different steps. For an expert user, the experiment could decompose one of those steps in another 4 specific and detailed steps.
    • U-Inter-UR 1 Enable users/systems to merge metadata about a same "entity" according to its attribution/provenance
    • U-Inter-UR2: (Chained provenance) Enable users/systems to trace back the origin of an "entity" whose ancestors have been produced/generated by different systems.
    • U-Inter-UR 5: Facilitate data sharing through interoperability of the associated provenance information.
      • Eg:Did the epidemiological study include data from the northern regions after May?
    • U-Comp-UR 1: Enable users to determine the similarities and differences between past processes or events
    • U-Tru-UR 1: Enable users to assess the trustworthiness of Web data.
    • U-Imper-UR 1: Allow users to access provenance information even if it cannot be directly observed.

Technical Requirements for Disease Outbreak Scenario

List the general technical requirements (a subset of those in the list gathered here) which are required to fulfill the user requirements listed above specifically for the Disease Outbreak Scenario.

  • Content
    • C-Attr-TR 1.1: The notion of contributor ID should be fixed to have data provider identity disambiguated.
      • Eg. Distinguish between authors 1 and 2, which have contributed to the creation of 2 different datasets.
    • C-Attr-TR 2.1: There should be a notion of "creator of data" (in which cases user can be considered a creator of a piece of data and in which cases only collaborator).
    • C-Attr-TR 2.2: There should be a schema which will lead user to fulfill requirements for correct management of provenance metadata (proper insertion/modifications of data creators and collaborators).
    • C-Proc-TR1.1: The provenance metamodel used should be expressive enough to support reasoning capabilities about agents and subprocesses.
      • Eg: Which agents were involved in the patient classification to obtain Alice's final dataset?
      • Eg: Which processes and subprocesses have been executed in Bob's diagnosis?
    • C-Proc-TR3.1: The provenance metamodel should be rich enough in terms of process description to identify the key features of a process.
      • Eg: When did Bob start his diagnosis?
      • Eg: Which databases did Bob use for his diagnosis?
    • C-Proc-TR3.2: It should be possible to revert provenance graphs into enactable process models.
    • C-Proc-TR 5.1: Libraries of domain-independent overlays could be (re)used that describe processes at different levels of detail so that provenance graphs can be matched against them.
    • C-Proc-TR 5.2: It should be possible to group the entities present on a provenance graph according to different criteria like proximity, sequence of subprocess, etc.
      • Eg: Which processes took place before step 3 in Bob's research?
      • Eg: Which processes have compatible inputs or outputs?
    • C-Vers-TR 1.1: A system should keep track of the different versions of a published document, or piece of information.
    • C-Vers-TR 1.2: A system should keep track of what entity makes changes to the document
    • C-JUST-TR3.2: Changes to the source data or justification over time need to be recorded to keep the records consistent (C-VERS-*, M-DISS-UR4)
    • C-JUST-TR4.1: The "correct" behavior of unsupervised justification behavior (for individual or networked systems) need to be specified and agreed with regulatory agencies
      • Need to know which specification is used as “correct” to determine the experiment. Are there many “correct” specifications?
    • C-JUST-TR4.4: Standards for exchanging justified, or provenance-carrying data should support collaboration among many users or systems (CF U-INTER-UR-2, U-INTER-UR-4, U-INTER-UR-5)
    • C-Entail-TR1.1 record the provenance of data at a coarse and fine granularity levels. In the context of RDF, recording the provenance at a fine granularity level amounts to recording the provenance of a single triple, whereas recording the provenance at a coarse granularity level accounts to recording the provenance of a collection of RDF triples.
    • C-Entail-TR 1.2 provenance model for the SPARQL language: determine the provenance of the result of a SPARQL query.
    • C-Entail-TR 7.1: For conclusion that is data, the algorithm, heuristic used
    • C-Entail-TR 8.1: Annotate the date and time of the derivation
    • C-Entail-TR 9.1: Identify Parameters directly and indirectly used to derive conclusions
    • C-Entail-TR 9.2: Identify Assumptions directly and indirectly used to derive conclusions
    • C-Entail-TR 9.3: Identify Hypotheses directly and indirectly used to derive conclusions
    • C-Entail-TR 9.4: Identify Other conclusions directly and indirectly used to derive conclusions
  • Management
    • M-Acc-TR 1.1: Applications should be able to use provenance to identify the authors and sources of data.
    • M-Diss-TR 1.1: Provenance should make it possible to determine whether experimental or survey results are suitable for a given kind of reprocessing or repurposing.
    • M-Diss-TR 4.1: Provenance should link data and physical artifacts (e.g. experimental samples) to the data from which they are derived.
  • Use
    • U-Under-TR 3.1: It should be possible to match a provenance graph against pre-existing high-level, domain-independent representations of candidate reasoning types.
    • U-Under-TR3.2: Such templates, or overlays, should be rich enough and abundant enough to cover the majority of the possible reasoning behaviours for a given domain and task.
    • U-Under-TR4.1: The reasoning structures used to provide the explanations mentioned in UR 3 should be represented at different levels of granularity
    • U-Under-TR4.2: It should be possible to transit between the different levels of granularity of the overlays, being such transitions semantically described.
      • Eg: Which steps would Bob's research display have if I’m a novice user? What if I demand a more detailed explanation of each step?
    • U-Inter-TR 1.1: Provide the means to query provenance of an "entity" (in the rdf context, "entity" to be understood as resource or statement!)
      • U-Inter-TR 1.1.1: query should be able to identify specific "aspects" of provenance, such as attribution, source characteristics, etc), hence some form of "filtering" required.
        • Eg: Which are the processes derived from Alice's patient classification that took place before date January 31th?
      • U-Inter-TR 1.1.2: query should be able to scope provenance (how far back to we go into the history). Note this was not specific in the use case but was discussed in Miles' requirements paper (
        • Eg: Which are the processes derived from Alice's patient classification that took place before date January 31th and belong to this experiment?
    • U-Inter-TR 1.2: Given a document, image, file, etc, provide the means to obtain its provenance
      • U-Inter-TR 1.2.1: Find an authoritative provenance service to retrieve its provenance
    • U-Inter-TR 1.3: Given a resource and some provenance, provide the means to verify that the provenance is the one of that resource.
      • Eg: Is Alice's patient classification dataset compatible with the input for Bob's research?
      • Eg: Does conclusion321 belong to Bob's research?
    • U-Inter-TR 2.1: Provide a common representation of provenance offering a technology-independent description of how an entity was derived
      • U-Inter-TR 2.1.1: Provide a computer parseable notation for provenance
      • U-Inter-TR 2.1.2: Provide a user-oriented notation for provenance.e.g. graphical notation
    • U-Inter-TR 2.2: Provide a mechanism to integrate part of a history in system x and part of history in system y.
    • U-Inter-TR 2.2.1: Provide the means to automatically propagate provenance information as data is exchanged between systems
    • U-Inter-TR 5.1: Provenance models to ensure conceptual clarity of provenance terms
    • U-Inter-TR 5.2: Ensure consistent use of provenance terms to reduce terminological heterogeneity (for example, naming conflict and data unit conflicts)
    • U-Inter-TR 5.3: Allow representation of domain-specific provenance details while ensuring provenance interoperability
    • U-Comp-TR 1.1: Allow records of past processes to be represented in such a way as to be able to compare their parts
    • U-Comp-TR 1.2: Provide a means for two processes or parts of processes to be treated as comparable (about the same thing), either by manual assertion or automatic deduction
    • U-Comp-TR 1.3: Provide a mechanism to take two comparable processes and produce a helpful explanation of their similarities and differences
    • U-Tru-TR 1.1: Allow applications to associate source information with aggregated data.
    • U-Tru-TR 1.2: Applications should be able to use source information to compute trust associated with data.
    • U-Tru-TR 1.3: Allow versions of trust to reflect different versions of source information (used to compute trust).
    • U-Tru-TR 1.4: Applications should be able to deal with missing provenance information
  • U-Imper-TR 1.1: Allow applications to assert provenance with a degree of uncertainty
    • U-Imper-TR 1.2: Allow applications to infer dependence/causation with a degree of uncertainty.
      • Eg: Patient classification depends on and NeISS resources. The system infers that it may depend too on resources (60% sure)
    • U-Imper-TR 1.3: Require asserter to be identified, and the nature of assertion to be specified (guess, inference, ...)


This is where we identify components/aspects of a provenance solution to the scenario, and how technical requirements for the scenario are illustrated in three diagrams.


Disease Outbreak 'Content' Block Diagram
Disease Outbreak 'Management' Block Diagram
Disease Outbreak 'Use' Diagram

Relevant State of the Art


Here is a summary of related work across scenarios.

Existing Solutions Used Today for Disease Outbreak Scenario





Current Provenance Research Relevant to the Scenario


















Publication, Access, and Dissemination




















  • Bleiholder J, Naumann F. Data fusion. ACM Computing Surveys. 2008;41(1):1-41.
  • Cheney J, Ahmed A, Acar UA. Provenance as dependency analysis. In: Arenas M, Schwartzbach M Proceedings of the 11th International Symposium on Database Programming Languages (DBPL 2007). Springer-Verlag; 2007:138-152.
  • Gomez-Rodriguez M, Leskovec J, Krause A. Inferring Networks of Diffusion and Influence. In: Proceedings of the 16th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. 2010:1019-1028.
  • Green TJ, Karvounarakis G, Tannen V, Ives ZG. Update Exchange with Mappings and Provenance. In: VLDB. 2007.
  • P. Missier, S.M. Embury, R.M. Greenwood, A.D. Preece, and B. Jin, "Managing information quality in e-science: the Qurator workbench," SIGMOD '07: Proceedings of the 2007 ACM SIGMOD international conference on Management of data, New York, NY, USA: ACM, 2007, pp. 1150-1152.
  • Pinheiro Da Silva P, McGuinness DL, Del Rio N, Ding L. Inference Web in Action: Lightweight Use of the Proof Markup Language. In: International Semantic Web Conference.; 2008.
  • Pinheiro Da Silva P, McGuinness DL, Fikes R. A Proof Markup Language for Semantic Web Services. Information Systems. 2006;31(4-5):381-395.
  • D. Stead, N. Paton, P. Missier, S. Embury, C. Hedeler, B. Jin, A. Brown, and A. Preece, "Information Quality in Proteomics," Briefings in Bioinformatics, vol. 9, 2008, pp. 174-188.
  • Zhang J, Jagadish HV. Lost source provenance. In: ACM International Conference Proceeding Series; Vol. 426.; 2010:311-322.

Gap Analysis


In the workflow provenance (e.g. Taverna, Pegasus, ZOOM etc.) and Semantic Web systems (Inferece Web) area, provenance techniques are closer to maturity, in part because the technical problems are less daunting because the information is coarser-grained, typpically describing larger computation steps rather than individual data items, and focusing on computations from immutable raw data rather than versioning and data evolution. There is already some consensus on graph-based data models for exchanging provenance information, and this technology gap can probably be addressed by a focused standardization effort.


Although there are many proposed approaches and technology solutions that are relevant, there are several major technology gaps to realizing the Disease Outbreak scenario. Organized by our major provenance dimensions, they are:

  • With respect to content:
    • No guidance on publishing provenance updates
  • With respect to management:
    • No well-defined standard for linking provenance between sites
  • With respect to use:
    • No general solutions to understand provenance published on the Web
    • No standard representations that support integration of provenance across different sources
    • No standard representations that support comparison across scientific analysis results
    • No broadly applicable approaches for dealing with imperfections in provenance,