RE: [plcs-dex] Scheme entry assignment or Activity method realization?

[Tim Turner <tjt@lsc.co.uk>]

Title: Message

Nigel,

 

thanks for your helpful comments. It's not pretty, though it helps to separate out the reasons for why the model is the way it is.

 

However, there are still some confusing aspects for me, which I have tried to drive out in the following.

 

I appreciate that the 1:1 link between Activity and Activity_method is inadequate. However, I don't think Activity_method_realization CAN address this specific issue as it does not relate an Activity to Activity_method.

 

It relates an Activity_method with one of the following;

TYPE activity_realization_select = SELECT
   (Scheme,
    Scheme_version,
    Task_element,
    Task_method,
    Task_method_version);

 

However, in C032 I note Activity_method is refered to as a "typical activity", so typical activities could be used in this [bent] fashion - (though it strikes me that maybe typical_activity is a missing subtype). Hence the activity_method (classified as a typical activity) can be related to another activity_method (this time a subtype such as scheme, scheme_version, task_method task_method_version or task_element). However, the relationship is again a 1:1, which requires a new relationship each time to represent the instructions, schedules, safety_procedure etc.. Presumably this would have been better as a list of 1:? to achieve the scenario discussed below.

 

But then the question is does this also work for a <planned> activity? Clearly, the select type above does not allow for this (I just double-checked that activity is not in the select type list from the latest corrected version of 239). The other possibility is to use the activity.chosen_method but this is again inadequate since only one of the tasks can be linked where we may have several (as you indicated).

 

There are thus, only two other ways to resolve this. 

i) that the <planned> activity references the <typical activity> activity_method through the activity.chosen_method, thereby linking the typical to the planned.

 

ii) to use an applied_activity_assignment on the <planned> activity - this provides a set of [1:?] activity_item & this select type subsumes those entities of the Activity_realization_select type of Activity_method_realization entity.

 

Taking each of these in turn;

Case i) then allows (the simplest case) for the typical activity, to be linked to the planning stage, without having to redefine all the relationships (of typical activity) when using a <planned> activity. Hence, activity can thus be defined as a planned occurrence of a typical activity. The approval of the activity would signify approval of all the typical tasks. Likewise for rejection / dis-approval.

 

Case ii) allows each of the relationships defined within the typical case to be repeated, but this time in a simpler fashion (a one to many relation), and each relationship could be assigned an approval independantly of the typical activity's approval. However, this could also be shown implicitly by only providing the relationships which are effective for the given approval of the <planned> activity. That is, the relations then show which are planned to be taken up. As the activity.chosen_method attribute, is mandatory it should then point to the typical activity refered to in i).

 

C032 only refers to approval at the activity level so I presume that in case i) we approve / reject the whole typical activity, or, if separate relationships have been provided from the <planned> activity to certain tasks identified within the typical activity, that only those are approved / rejected. Of course, the logic can work in either direction (i.e. are those that are not classified as dis-approved, approved?) Note, we will have to create a precedence table for these and other approvals at other levels.

 

Lastly, an activity_actual can be seen as a realized occurrence of a typical activity (rather than <planned>, as the .chosen_method cannot point to this) and can (like in case ii) be either just accepting the whole thing or just adding the relations to those undertaken. In addition, we can then add the activity relationship activity_happening between the <planned> and the actual_activity.

 

I see two things which come from this approach;

 

1. That should there be no typical activity defined for the tasks which a planned activity would normally identify (though the applied_activity_assignment), there will be no straight-forward solution to what the <planned> activity.chosen_method attribute points to. We will have to (in these cases) define activities on a 1:1 basis with respect to the tasks identified and drop the use of the applied_activity_assignment (which will be repeating the .chosen_method link & so is redundant). This also provides an opportunity to either reference a task, or to redefine/extend one if necessary.

 

2. Conversely, I also note that by using activity_method for the typical case, it means that a life cycle opportunity cannot be defined as described within C020 (it specifies that it has to be an activity). However, we could provide a dummy activity for this purpose, which then allows the rest of the work package to be defined.

 

 

On the second issue, I appreciate the difference between an activity and an occurrence of one as an entry in to a scheme of work. I presume that when you say "a scheme entry is a representation of an activity" that this does not infer that the scheme_entry replaces the need for an activity. Yes, the fact that a scheme_entry is a type of activity_method does make this model questionable (un-intuitive at least), but if it's a necessary evil....

 

Just to wrap this last aspect up then, the scheme_entry should thus, be related to the typical, <planned> or actual_activity via a scheme_entry_assignment, which covers all these and more. What is less certain, is whether each should have a separate scheme_entry for it, or a single one which is re-used by the 3 assignments. I would favour the latter to keep the 3 aspects together which would be useful where other un-related entries could collate their activities together.

 

On a related aspect, I also see no reason why the directed_activity for a work_order should not also be used  as the activity for the life cycle opportunity model. Indeed, having several opportunities for support, several activities may be relevant, but only one should be authorized for the activities identified. The directed_activity should be the one approved and should not need another activity assigned (through applied_activity_assignment and activity_method) to achieve this. 

 

There are many other aspects of the model which can serve to distract from the logical use, which are no doubt there to allow flexibility for compatibility and/or specific usages, but hopefully the above is not too far from a basis to work from.

 

I apolpogise for the length of this, and I hope it makes sense, but as no doubt you'd appreciate, it's a complex beast to understand and takes time to walk through...

 

Kind regards,

Tim

---

From: Nigel Shaw [mailto:nigel.shaw@eurostep.com]
Sent: 17 January 2006 03:57
To: ''Plcs-Dex teams (E-mail) ''
Subject: RE: [plcs-dex] Scheme entry assignment or Activity method realization?

Tim

 

The models allow for many possibilities as a reflection of real life. In real life, when someone undertakes a piece of work they are often following a set of instructions AND one or more schedules AND a set of safety procedures AND organizational rules. On top of this, they may be subject to instructions on how to provide feedback on the work - what records to keep, which stages to sign-off, etc.

 

This is a marked contrast with the basic core STEP model for Activity which refers to a single chosen method.

 

Consider also that the chosen method could change  while the Activity is being planned  (same intended job but different plan or different approach) and tracking that change also may be important.

 

Hence from PLCS perspective I saw the existing required 1:1 between Activity and Activity_method as woefully inadequate. Activity_method_realization was intended to deal with both of these in that - with a suitable place holder method as the "chosen_method", multiple methods can be associated with the Activity and efffectivity can be applied to the Activity_method_realization.

 

So that was the first problem.

 

The second problem was to deal with plans and schedules.

Here the first thing to realise is that although people "follow" plans and schedules, the things in them are not Activity's. Why? - because the same Activity can appear in many schedules. So a scheme entry is a representation of an activity (or other things, such as change in resource availability). This makes it questionable as to whether it really is an Activity_method - but to get the interpretation to work, it had to become one.

Regrettably (and not the case in early versions), making it an Activty_method makes it possible to use activity_method_realization with it. I would not recommend this usage.

 

     Nigel

 

-----Original Message-----
From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: 16 January 2006 07:45
To: ''Plcs-Dex teams (E-mail) ' (plcs-dex@lists.oasis-open.org)'
Subject: [plcs-dex] Scheme entry assignment or Activity method realization?

Dear All,

Prior to Christmas I sent out an email regarding the relationship between a Scheme_entry and Task_method_version, both of which are subtypes of Activity_method).

An Activity_method_realization can be used to relate a Scheme_entry to a Task_method_version, as detailed briefly in C032 - Representing_activity.

However, there is also the possibility of using Scheme_entry_assignment (a subtype of applied_activity_method_assignment - which would appear to be designed for this) and allows a greater set of items to be assigned than through Activity_method_realization.

Through various conversations I understood that it was expected that we use the former over the latter. However, I cannot fully appreciate the reasoning behind this, especially when one seems to be more tailored for the purpose (i.e. the latter). Either usage is valid in the EXPRESS (i.e. there are no rules which enforce one over the other as far as I'm aware)... The rules (only on Scheme_entry_assignment) just redefine the types or inhibit a recursive relationship.

The former is also just a binary relation (1:1), whereas the latter provides for a set [1:?] of items. Hence I can see more advantage in using the latter, were a number of tasks required to represent a scheme_entry.

I had begun to think that the Activity_method_realization was part of a lifecycle view, but this is hard to appreciate since the entities made available by the two select types overlap, but are different (the latter enables greater number). Hence there can be no 1:1 across such a view.

Scheme_entry_assignment is described within C062 - Representing Scheme and is pulled in to the capabilities EXPRESS usage area. However, Activity_method_realization is NOT pulled into the usage of C032 - Representing_activity, where it would naturally fit and is briefly described. This is perhaps an issue for C032.

I would appreciate modeller views on this asap so we can document a consistent approach.

Many thanks,
Tim

NB. WRT Activity_method_realization,  C032 - Representing_activity says "If the typical activity [activity_method] is described by a Task_method, or scheduled by a Scheme, then it is related to the Activity_method by an Activity_method_realization. This is described in the capabilities C015: representing_task and C062: representing_scheme". However, there is no further description of this, and the statement is ambiguous since there is no clarification whether any subtypes of activity_method can also play in the role of a "typical activity".

PS. It also seems odd that none of the versioning entities for this area of the model (e.g. scheme_version, task_method_version) have an .id - is it therefore, valid (consistent) to create ids as reference data for such entities, where no such attribute ever existed in ap239?

<<...OLE_Obj...>>

*************************************************************************
*
* Mr. Timothy J. Turner BSC(Hons) MSc, MBCS
* Executive Consultant, Enterprise Integration Technologies
* LSC Group, Lincoln House, Wellington Crescent, Fradley Park, LICHFIELD, Staffordshire WS13 8RZ, ENGLAND
* UK Switchboard: +44-1543 446800 Fax: +44-1543 446900
* Mobile (US) telephone: +1-843-4759179
* Mobile (UK) telephone: +44-7885-393225
* e-mail: tjt@lsc.co.uk <mailto:tjt@lsc.co.uk> Internet: <http://www.lsc.co.uk/>
*
*************************************************************************
<<Tim Turner (Tim Turner).vcf>>

DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED***   The information in this message is confidential and may be legally privileged. It is intended solely for the addressee.  Access to this message by anyone else is unauthorised.  If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful.  Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG

DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG