A user of provenance replay may only care about analysis downstream of some specified result(s) (e.g. I want this whole analysis after the FeatureTable). Similarly, a user might only care about an analysis upstream of some specified result(s).
The ideal future use case basically looks like this:
user dumps a bunch of artifacts into the parser, generating a ProvDAG that looks like this:
B -- C
I -- A< > G -- H
D -- E
\-- F
user visualizes the ProvDAG graph in a fancy future GUI, and says "I want to replay provenance from this FeatureTable(A) through these Vizualizations (F & G) disregarding the rest.
The interface captures UUIDs for those nodes and passes them off to Replay
The core idea here is that a user might want to replay only (F | G) - A. We can probably use graphviews to handle this, writing predicates flexibly based on what a user wants to include and exclude. Computationally, this could be a little spendy, as we're probably actually composing_all of the unioned UUIDs and their ancestors, before truncating A and all of its ancestors.
A user of provenance replay may only care about analysis downstream of some specified result(s) (e.g. I want this whole analysis after the
FeatureTable). Similarly, a user might only care about an analysis upstream of some specified result(s).The ideal future use case basically looks like this:
A) through these Vizualizations (F&G) disregarding the rest.The core idea here is that a user might want to replay only
(F | G) - A. We can probably use graphviews to handle this, writing predicates flexibly based on what a user wants to include and exclude. Computationally, this could be a little spendy, as we're probably actuallycomposing_allof the unioned UUIDs and their ancestors, before truncatingAand all of its ancestors.