W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2012

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

From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Mon, 10 Sep 2012 11:48:17 +0100
Message-ID: <EMEW3|4cd9b9e2c3315ccb447e7d2e5b9800d3o89BmJ08l.moreau|ecs.soton.ac.uk|504DC571.1060809@ecs.soton.ac.uk>
To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
CC: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>, public-prov-wg@w3.org



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
Received on Monday, 10 September 2012 10:48:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 September 2012 10:48:53 GMT