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

Hi all,

sorry for jumping a bit late in the thread. It seems like the need for
activity composition
is clear but everybody is agreeing in that we should not create a new
relation for modeling it.

If that is the case, where should we address the subactivity composition?
In a best practice
document? I like the dcterms:hasPart idea, but I would like to see it
written down as a recommendation
or best practice somewhere.

Thanks,
Daniel

2012/9/10 Luc Moreau <l.moreau@ecs.soton.ac.uk>

>
>
>
> 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
>
>