Re: PROV-ISSUE-447: subactivity relation [prov-dm]

Hi Stian,

I think you have drifted in your discussion.
This issue has been addressed in prov-constraints:
http://lists.w3.org/Archives/Public/public-prov-wg/2012Aug/0153.html
and voted before LC release.

generation-uniqueness is for a pair e,a.

However all generations for an entity should occur simultaneously.


Luc


On 09/06/2012 11:11 AM, Stian Soiland-Reyes wrote:
> It still raises the question about entities generated by both
> activities and the generation-uniqueness constraint.
>
> One way around it, as I've approached it for Taverna's workflow PROV,
> is to use prov:alternateOf between two entities, one per
> generation/invalidation. You can picture these entities as
> representing "The value as output gate X" and "The value at output
> gate Y" - almost like the old prov:EntityInRole. This is the same
> reasoning a washed car coming out of the last-stage
> activity(polishing) and thereby completing the activity(carWashing)
> can be seen as generated twice, once as "polishedCar" and once as
> "washedCar" - even though there is nothing happening between the two
> activities and the two entities are equivalent.
>
> If this is the recommended approach, then it would be good to have a
> property to clarify this is not just any odd alternate; say
> prov:alternateInSubActivity. (as a property on the prov:Entity or a
> subproperty of prov:alternateOf). Otherwise it gets tricky to query
> the provenance across, we don't want to follow every odd alternate up
> and down the trace. The strange thing here is that you don't*need*  to
> do the prov:alternateOf wrapping for usage or association. The
> question also then comes to which extend to the subactivities should
> always twin the entities or not.
>
> I don't particularly like that "work around" approach for
> subactivities, as it ends up making a verbose "twin world" with
> alternate identifiers (which you have to mint) - effectively making an
> inline bundle without clear boundaries.
>
>
>
> The second way, much simpler and my preference, is to allow multiple
> generation, but only as long as one activity is subactivity of the
> other. I guess we can't infer which one is the sub and which one is
> the super - so it would be a constraint rather than an inference, but
> this gets tricky with the open world assumption and the use of OR/NOT.
>
> (This can be solved by adding a prov:alternateActivityFor as a
> symmetric superproperty of prov:wasSubActivityOf, then we can instead
> of the constraint simply infer prov:alternateActivityFor on multiple
> generations. The semantics of prov:alternativeActivityFor would be
> particularly weak, similar to prov:alternativeOf.  )
>
>
> This is indeed the approach we have taken for Wf4Ever's 'simplified'
> workflow provenance model wfprov -
> http://wf4ever.github.com/ro/#wfprov
>
> Here wfprov:wasPartOfWorkflowRun is the workflow equivalent of
> wasSubActivityOf, and both are allowed to have the same artifact (ie.
> entity) as it's wfprov:wasOutputFrom. Because of this we currently we
> can't make wfprov:wasOutputFrom a subproperty of prov:wasGeneratedBy
> without violating PROV-Constraints. As we don't want to make a too
> verbose model, we are trying to avoid adding the equivalent of
> prov:alternateOf workaround I sketched above.

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm