Re: relations between activites

Stian,

(cc'ing our working group list instead of the comments list)

On Jul 6, 2012, at 10:09 AM, Stian Soiland-Reyes wrote:

> I would at least be very interested in defining activity composition
> as part of PROV.
> 
> I think as Tim points out there are many existing ways to model
> composition, but I don't think that means that PROV should ignore
> composition of activities and entities - it would be important to
> understand that for the outcome of the ex:Project there were many
> ex:MRIScannings - if we leave these to custom attributes, then those
> are separate islands in PROV.

As Paul mentions, heading down the path of composition leads to an abundance of details that would need to be considered, and is beyond the scope of our charter.
For example, I imagine we'd want temporal constraints imposing that the start of a child must not precede the start of the parent, etc.
That's a whole new area of the material that we have not addressed as a WG during its lifetime, and deserves more time than we can give it as things are finishing up.

Regarding your "islands" comment, that is the nature of defining any model with any coherent scope.
We've had the "island" argument for Dictionaries, and they ended up in a Note (with only Collection and hadMember surviving as a Rec).
So, perhaps we respond to Satra's comment with a bare-bones activity composition?
I'd like to point out that specialization already provides an orthogonal dimension similar to activity composition, but specialization is only among entities.
Also, is there adequate prior art on activity composition and granularity management? From what I've seen, the community has only stabbed at different parts of the elephant.

> 
> We did get rid of wasStartedByActivity for simplicity. Perhaps for
> wasInformedBy we can suggest some subtypes like prov:WasPartOf ?

Although wasPartOf may be a subtype of wasInformedBy from a workflow perspective, I think communication and part hood are orthogonal in general.
So tucking it under there doesn't seem appropriate.

Regards,
Tim


> 
> 
> 
> On Fri, Jul 6, 2012 at 2:14 PM, Paul Groth <p.t.groth@vu.nl> wrote:
>> Hi Satra,
>> 
>> Thanks for the question. We actually have had several people ask a
>> similar question. So I'm also curious what the group will answer :-)
>> 
>> For wasFollowedBy, we actually have the relation wasInformedBy which
>> you can use for activity ordering.
>> 
>> I think we were reticent to start defining the composition of
>> activities because that could lead down the path of defining an entire
>> workflow or programming language, which is not in our charter or
>> something we would want to do. I guess the answer was that we were
>> worried about feature creep. Do we stop at just composition or would
>> other constructs be necessary?
>> 
>> thanks
>> Paul
>> 
>> On Fri, Jul 6, 2012 at 2:45 PM, Satrajit Ghosh <satra@mit.edu> wrote:
>>> hello,
>>> 
>>> i was discussing this with luc and based on his feedback thought it might be
>>> useful to bring this up on the list.
>>> 
>>> ----
>>> question:
>>> how do you encode that a certain activity "emailing a letter" happened
>>> during another activity "a meeting"?
>>> 
>>> for example we conduct research studies/projects.
>>> 
>>> activity(p1, [prov:type='ex:Project'])
>>> activity(p2, [prov:type='ex:MRIScanning', ex:session=1])
>>> activity(p3, [prov:type='ex:MRIScanning', ex:session=2])
>>> 
>>> how would i encode that this activity p2 and p3 were conducted during p1?
>>> how would i encode p3 followed p2?
>>> 
>>> 
>>> luc's response:
>>> Regarding your question, there may be a few options:
>>> you could add time information to your activities. This will help you
>>> understand their ordering.
>>> 
>>> Alternatively, if you want an explicit dependency in your graph, then p2 may
>>> generate something
>>> that starts p3, and/or is consumed by p3
>>> 
>>> Finally, prov doesn't have relations between activities, to express their
>>> nesting, etc. It's important
>>> but we felt this is not specific to provenance, but to process executions.
>>> ----
>>> 
>>> it's the last point on this response that i was not completely sure about.
>>> why "relations between activities" is "not specific to provenance, but to
>>> process executions."
>>> 
>>> in the above example, one could say:
>>> 
>>> wasSubtaskOf(p2, p1)
>>> wasSubtaskOf(p3, p1)
>>> wasFollowedBy(p2, p3)
>>> 
>>> any clarification as to why such relations would be outside the realm of
>>> provenance would be much appreciated.
>>> 
>>> cheers,
>>> 
>>> satra
>> 
> 
> 
> 
> -- 
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> 
>

Received on Friday, 6 July 2012 15:05:25 UTC