Re: relations between activites

My suggestion would be to put this as an issue to be considered with
all the issues arising from last call.

I think as a process, we should try to collect these issues and then
see what we do about each.

cheers
Paul

On Fri, Jul 6, 2012 at 5:04 PM, Timothy Lebo <lebot@rpi.edu> wrote:
> 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
>>
>>
>



-- 
--
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
Knowledge Representation & Reasoning Group
Artificial Intelligence Section
Department of Computer Science
VU University Amsterdam

Received on Friday, 6 July 2012 15:09:38 UTC