Re: PROV-ISSUE-203: Proposal to amend definition and usage of Plan in PROV-DM [prov-dm]

Oops.  This email feel through the cracks.

On Jan 11, 2012, at 6:34 AM, Luc Moreau wrote:

> Hi Stephan,
> 
> I am coming back to the following outstanding issue.
> There are cases when a plan is known but the agent is not
> (it doesn't mean that there is no agent, but simply the agent is not known).
> 
> Currently, in wasAssociatedWith(activity, agent, plan, attributes)
> a plan is optional.
> 
> I would like to suggest that agent may also be optional (obviously,
> one of them must be present in this relation).
> 
> What do you think?

Why would agent be optional in wasAssociatedWith?  Was not wasAssociatedWith supposed to describe the association of an agent with an involvement in an activity?

"An activity association is an assignment of responsibility to an agent for an activity, indicating that the agent had a role in the activity."

I do not think it makes sense for agent to be optional in an activity association, especially with the caveat that plan or agent must be present, but both are individually 'optional'.  That caveat may cause confusion and an activity association of an activity to just a plan does not make sense according to the definition of activity association.

So, I am against making agent optional in activity association.

If we take an open world view, then I there isn't an issue if we know that a specific plan was adopted by an otherwise unknown agent.  We can represent the agent,  we just won't have any characterizing information about the agent except that it was the agent that adopted this specific plan in this activity.

If that is not desirable, I suggest adding an Activity-Entity Relation to link Plans to Activities without information about which Agent(s) used the plan.

--Stephan

> 
> Luc
> 
> On 12/20/2011 10:50 AM, Luc Moreau wrote:
>> 
>> Hi Stephan, all,
>> 
>> I have implemented the changes, as follows.
>> - plan is an entity
>> - your definition of plan reused
>> - hadPlan relation dropped
>> - wasAssociatedWith extended with optional plan
>> 
>> Changes visible in 
>> http://dvcs.w3.org/hg/prov/rev/676811be7851
>> 
>> To me, there is an outstanding issue. I think it is over constraining to mandate the assertion of an agent
>> when a plan needs is to be asserted.  For flexibility, I would also make the agent optional (but obviously,
>> either agent or plan has to asserted).
>> 
>> Luc
>> 
>> On 12/19/2011 06:06 PM, Stephan Zednik wrote:
>>> 
>>> 
>>> On Dec 19, 2011, at 10:55 AM, Luc Moreau wrote:
>>> 
>>>> 
>>>> Hi Stephan,
>>>> 
>>>> On 19/12/11 17:49, Stephan Zednik wrote:
>>>>> 
>>>>> 
>>>>> On Dec 19, 2011, at 2:38 AM, Luc Moreau wrote:
>>>>> 
>>>>>> Hi Stephan,
>>>>>> 
>>>>>> It seems that your proposal can be captured by allowing a plan to be specified
>>>>>> in an activity association record.  If multiple plans need to be specified, fine,
>>>>>> we can assert multiple such records.
>>>>> 
>>>>> If I understand this proposal correctly, this alleviates the problem of restricting all plans to be agents?
>>>> 
>>>> Yes, plans would be entities (given agents are subclass of entities, plans can also be agents, if desirable).
>>> 
>>> Sounds great.
>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> Question: should we allow assertions for a plan but no agent?  
>>>>> 
>>>>> A good question, and one that I was unsure about when I raised the original proposal, but I believe it is worthwhile to require an agent for a plan because it allows us to determine who is "responsible" for following the plan.
>>>>> 
>>>>> If a plan is understood to be the description of a set of actions or steps intended by one or more agents to achieve some goal, than the activity-plan linkage which says that a plan was used in an activity (and plans are used by agents) should also reference the agent or agents that used the plan.
>>>>> 
>>>>> I think that in domains were recipe-link is used in OPM without a reference to the agent, the agent is implicit, and I am worried that that modeling would not work well in a general model.  it works in workflows because of the implicit agent, but it doesn't work well when you talk about say, cooking.
>>>> 
>>>> My concern is about workflows. If the agent is the enactment engine, is it necessary to mandate the agent.
>>>> In particular, if workflows are standardized/portable, an asserter may not know the agent actually executing it.
>>> 
>>> What about saying that the workflow enactment engine is the agent, without providing any additional details?
>>> 
>>> We have now made the implicit explicit, and not required the assert to say anything detailed about the acting agent (other than that one existed).
>>> 
>>> In the case of workflows, the asserter knows the plan was a workflow so it is reasonable they could describe the agent as a workflow enactment engine, even if they know no other information about it.
>>> 
>>> I think it is ok to say, "There was some agent that followed this plan in this activity, and that is all I know about that agent."
>>> 
>>> 
>>>>> 
>>>>>> 
>>>>>> Here is the proposed modification:
>>>>>> 
>>>>>> 
>>>>>> An activity association record, written wasAssociatedWith(id,a,ag2,pl,attrs) in PROV-ASN, has the following constituents:
>>>>>> 
>>>>>>  An activity association record, written wasAssociatedWith(id,a,ag2,pl,attrs) in PROV-ASN, has the following constituents:
>>>>>> 
>>>>>> id: an optional identifier id identifying the activity association record;
>>>>>> activity: an identifier a for an activity record;
>>>>>> agent: an identifier ag2 for an agent record, which represents the agent associated with the activity;
>>>>>> plan: an optional identifier pl for an entity record, which represents a plan adopted by the agent in the context of this activity;
>>>>>> attributes: an optional set of attribute-value pairs attrs that describe the modalities of association of this activity with this agent.
>>>>>> 
>>>>>> 
>>>>> I am happy with this based on my current understanding of its implications ;-)
>>>> 
>>>> Good, and I understand the caveat.
>>>> 
>>>> If you agree, I'll make the changes along the proposal, for you and the WG to review.
>>> 
>>> I agree.
>>> 
>>> --Stephan
>>> 
>>>> 
>>>> Regards,
>>>> Luc
>>>>> 
>>>>> --Stephan
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Cheers,
>>>>>> Luc
>>>>>> 
>>>>>> On 12/15/2011 07:52 PM, Provenance Working Group Issue Tracker wrote:
>>>>>>> 
>>>>>>> PROV-ISSUE-203: Proposal to amend definition and usage of Plan in PROV-DM [prov-dm]
>>>>>>> 
>>>>>>> http://www.w3.org/2011/prov/track/issues/203
>>>>>>> 
>>>>>>> Raised by: Stephan Zednik
>>>>>>> On product: prov-dm
>>>>>>> 
>>>>>>> Dear all,
>>>>>>> 
>>>>>>> I would like to suggest an amended definition and usage for plan in PROV-DM.
>>>>>>> 
>>>>>>> CONTEXT:
>>>>>>> 
>>>>>>> 1. The concept of plan is currently related to activity via a plan link, which is a specialization of an activity association record; as a consequence all plans are agents.
>>>>>>> 
>>>>>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-planLink
>>>>>>> 
>>>>>>> 2. This means that according to the definition of agent at http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#section-entity-activity-agent, plans 1) take an active role in an activity and 2) can be assigned some degree of responsibility for the activity taking place.
>>>>>>> 
>>>>>>> 3. The relation between agents and the plan that guides their actions is not explicit in PROV-DM.  We could infer that all agents involved in an activity act according to the activity's linked plan, but this prevents us from describing an activity were multiple agents act guided by different plans.
>>>>>>> 
>>>>>>> PROPOSAL 1: Amend the definition of plan in PROV-DM to:
>>>>>>> 
>>>>>>> "In the context of PROV-DM, a plan should be understood as the description of a set of actions or steps intended by one or more agents to achieve some goal."
>>>>>>> 
>>>>>>> PROPOSAL 2: Amend plan link record such that it is not a specialization of an activity association record.
>>>>>>> 
>>>>>>> Comment: I do not think we should define all plans as agents.  By our existing definition a plan is a "set of actions or steps ... to achieve some goal."  It is a description (usually in the form of a document) of the action or actions an agent should take to achieve a desired goal.
>>>>>>> 
>>>>>>> As a description of the actions an agent should take, it does not make sense for a plan to have responsibility.  The responsible party for a plan (e.g. owner, creator) could have some responsibility for the outcome of the activity, but the description of the "set of actions or steps intended to achieve some goal" would not.
>>>>>>> 
>>>>>>> A plan without an agent is (generally) inert.  Something must follow/execute the plan for there to be action.  A recipe is inert - bread is made by the baker.  Driving directions are inert, a driver must control the vehicle from the trip's point of origin to its destination.  If driving directions are incorrect, it would be the source of the driving directions (e.g. Google Maps) that would bear responsibility for the failure of the activity to result in the desired objective.
>>>>>>> 
>>>>>>> Software and especially workflows are a fuzzy area; you can reasonably define any software as a document of steps that a microprocessor is capable of executing.  
>>>>>>> 
>>>>>>> To allow users to record provenance in a way that is natural to them I suggest we not define plans and agents as disjoint, but I do not think we should define all plans as agents.
>>>>>>> 
>>>>>>> PROPOSAL 3: Amend plan link record such that it can express which agents in the activity are following the plan.
>>>>>>> 
>>>>>>> PROPOSAL 4: We should define a relation to describe the responsible party for a plan.
>>>>>>> 
>>>>>>> --Stephan
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>   
>>>>>> 
>>>>>> -- 
>>>>>> 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
>>>>>>     
>>>>> 
>>> 
>> 
>> -- 
>> 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
>>   
> 
> -- 
> 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, 5 March 2012 17:36:46 UTC