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

Hi Daniel,


On 09/11/2012 04:24 AM, Daniel Garijo wrote:
> 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.

you mean "as a suggestion" rather than "as a recommendation", I suppose.

It's not clear which document this could actually go in.  I think the 
best option is to maintain a FAQ page on
our wiki. It would then be reasonable to have an example using 
dcterms:hasPart.

Luc


>
> Thanks,
> Daniel
>
> 2012/9/10 Luc Moreau <l.moreau@ecs.soton.ac.uk 
> <mailto: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  <tel:%2B44%2023%208059%204487>
>     University of Southampton fax: +44 23 8059 2865
>     <tel:%2B44%2023%208059%202865> Southampton SO17 1BJ email:
>     l.moreau@ecs.soton.ac.uk <mailto:l.moreau@ecs.soton.ac.uk> United
>     Kingdom http://www.ecs.soton.ac.uk/~lavm
>     <http://www.ecs.soton.ac.uk/%7Elavm>
>
>

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