Re: vocabulary simplification: two proposals to vote on [deadline, Oct 26 midnight, GMT]

Hi Stian,

Your comments about oven/cooking do not seem to be specific to activity, 
they apply
to process execution too. In fact, they are symptomatic of the weak 
definition of control,
but this is another issue.

Luc

On 26/10/2011 17:10, Stian Soiland-Reyes wrote:
> On Sat, Oct 22, 2011 at 18:29, Luc Moreau<L.Moreau@ecs.soton.ac.uk>  wrote:
>
> (Not sure which midnight is implied, 00:00 or 24:00 - I assume the latter :) )
>
>    
>> PROPOSED: in section 2.1 [1], to define an entity as an identifiable
>> characterized thing.
>>      
> +1
>
>
>    
>> PROPOSED: to rename 'process execution' by 'activity'
>>      
> -1
>
> Same argument as raised by Khalid and Graham - harder to differentiate
> the instance from the class.
>
> I am worried because "an activity" can be something very general, like
> "cooking". It is difficult to assert when "cooking" started, probably
> 250,000 years ago.
>
>
> In PROV we generally want to talk about particular instances of
> activities/processes, and the terminology should reflect this.
>
>
> "Process" conveys that there's something going on, like in a machine
> or factory. Perhaps something was used by the process, perhaps
> something was produced (generated). From our current conceptual model
> such pipeline terminology seems to fit well.
>
>
> The "Execution" bit conveys that it is a particular instance of a
> process, not the general "Making something" process, but a particular
> execution of that. There might or might not be someone who controls or
> performs the execution (the agent) - but the Process itself might have
> been decided in another way (the recipe).
>
> Would we need to rename "recipe" as well? Perhaps "plan" suits better
> to an Activity.
>
>
> An activity don't focus on the pipeline aspect, and is more general as
> such. An activity is something that someone or something starts doing,
> (the agent is active) and then stops doing it. If we have
> free-standing activities without agents that just use and generate
> entities it might sound a bit odd - who is performing that activity?
> Perhaps this is a good way to enforce implicit agents gets asserted.
>
>
> We probably want to capture activity patterns in PROV. "Oven started
> the WarmingUp activity" but there is no use or generation; unless you
> introduce the entities :coldOven and :warmOven - but that's process
> thinking. Activities are more up to changing things, so the :coldOven
> changed state to a :warmOven. We don't really talk about state
> transitions in our current approach.
>
>
> I can see the need for such an approach - but worry that the rest of
> the model is very process centric and might not fit well with
> "activity". For instance, does it make sense for an agent like the
> :oven to be "controlling" the warming up activity when actually he is
> *performing* it? He is the one that does the activity. If it is
> controlled by anything, it's by the thermostat or the cook.
>
>
> To summarise, this is not a very strong -1. If we find a good way to
> avoid the Activity-class-problem (like "ActivityPerformance" or
> "Action"), and it does not sound too weird with the rest of our
> terminology and model I'm OK, as I see the need for the more general
> interpretation and avoid scaring people with process executions when
> that's not their mindset.
>
> I just don't want to jump too fast to the +1 because it sounds like a
> change with many ramifications.
>
>

Received on Wednesday, 26 October 2011 16:27:23 UTC