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

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.

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Wednesday, 26 October 2011 16:11:54 UTC