RE: [plcs-dex] Assigning X to Y or Y to X

["Nigel Shaw" <nigel.shaw@eurostep.com>]

Some observations:

1) Given the richness of the capability we are aiming to support, some
ambiguity is inevitable.

2) A major driver for the use of the assignment approach is that items have
different life-cycles. Therefore one rule is to consider which of the items
under consideration is changing fastest - and assign that one. I appreciate
that this will sometimes not be clear.

3) Some of the examples quoted by Sean would be better handled by assigning
to an assignment. In this case there is less ambiguity because we have no
"assignment_assignment" entities. (e.g. a task assigned to a part under a
particular contract, the contract should be assigned to the assignment of
task to part.)
(if task developed under a contract, assignment of contract is then correct
IMHO)

4)  Where specific semantics are provided (such as is the case with
resources versus assigning the task to an item in the role of resource), use
the detailed semantics. (There will always be ambiguity - does the
engine_service apply to the engine (task_assignment) or does it need an
engine to be performed (required_resource)? In this case if an engine is
necessary as a "spare part", both cases apply. Otherwise use the former.)

Specific to the question Sean and Leif debated:
My position is that all resource_item relationships should go via
required_resource to allow for the case where the same resource plays
multiple roles in the task and multiple different resources can play the
same role. The intent of required_resource is to capture the role.
Resource_item_assignment was introduced to allow for cases such as when a
part is designed to be specifically used with another (as a tool, for
example) - a relationship that is independent of tasks.

	Nigel



-----Original Message-----
From: Hendrix, Thomas E [mailto:thomas.e.hendrix@boeing.com] 
Sent: 21 November 2005 18:53
To: Barker, Sean (UK); plcs-dex@lists.oasis-open.org
Cc: stepmod-devel@lists.sourceforge.net
Subject: RE: [plcs-dex] Assigning X to Y or Y to X


Sean,

Interesting question.

I agree that from a modeling standpoint, the direction doesn't matter. I
would not be comfortable (so far) with a direction dependent semantic, for
the reasons you suggest.  So simplest approach is to allow only one
direction.  This can be done arbitrarily, for example, by alphabetical
order. Thus, allow 
X <-- Y, or X <-- X
but disallow 
Y <-- X.

If for some cases both directions are allowed, the  roles need to be
documented in pairs xy and yx (presumably in an owl table, or an
algorithm) such that:
X <-xy- Y == Y <-yx- X


Regards,

Tom

Thomas E. Hendrix
Phone: 206-544-5276
thomas.e.hendrix@boeing.com


>-----Original Message-----
>From: Barker, Sean (UK) [mailto:sean.barker@baesystems.com]
>Sent: Monday, November 21, 2005 8:21 AM
>To: plcs-dex@lists.oasis-open.org
>Cc: stepmod-devel@lists.sourceforge.net
>Subject: [plcs-dex] Assigning X to Y or Y to X
>
>
>
>In PLCS, the question has arisen several times on whether we
>should assign X to Y or Y to X. For example, assign a resource 
>to a task_element via a task_element_assignment or via a 
>resource_item_assignment. Or a contract to a task_method via a 
>task_method_assigment or a contract_assignment.
>
>This ability to do things either way round is not uncommon in
>PLCS. Currently we have no principled way of deciding which 
>way to do this (and Leif G and I are not perfectly in accord - 
>[disagree is too strong] on which way round for task_element 
>to resource).
>
>Looking at this from a configuration control viewpoint, and
>using the example of task_method, the boundary of 
>"task_method" (while beyond the scope of the standard) needs 
>to be determinate. That is, it must be possible to decide 
>whether a change to an association requires a new version of a 
>task_method. My preference would be to say "if the association 
>is part of the [configuration] definition of the item, then 
>use the association tied to the item,
 otherwise, use the 
>opposite sense.
 An alternative way of expressing this is to 
>say that the association is from the dependent to the
>free-standing item, with the role being defined relative to 
>the dependent item (the task_method "uses" the resource - the 
>resource may have several other uses).
>
>That is, where a task_method uses a resource_item, then
>changing the resource may require a reissue of the task_method 
>- in this instance use a task_method_association. Where a 
>resource defines, say, a preparation task (such as calibrate), 
>then changing the preparation method changes the definition of 
>the resource, and in which case use resource_item_association.
>
>Similarly, where a contract cites a task_method, then use a
>contract_assignment. A task_method_assignment to a contract 
>would only be used if the task_method actually created the contract.
>
>There are two possible problems with this approach. Firstly
>there may not be a two-way option. Secondly, the configuration 
>control scope may change from business to business. In the 
>first case, we must live with this - it simply means that the 
>configuration implications of the relationship will need 
>spelling out in any exchange agreement.
>
>In the second case we can make the assertion stronger in the
>negative. That is, using the item association is an assertion 
>that the item is not part of the configuration of the target. 
>In the case of a task using a resource, the use of 
>task_element_assignment is an assertion that a change to that 
>assignment does not affect the definition of the resource (but 
>it may well affect the definition of the task). 
>
>
>From the point of view of a data exchange purist, the choice
>makes no difference, since the file contains the relationship 
>either way. However, this issue is important from the 
>viewpoint of maintaining a distributed environment - this, 
>rather than exchanging data, is the business goal of those using PLCS.
>
>Comments please.
>
>Sean Barker
>0117 302 8184
>
>
>********************************************************************
>This email and any attachments are confidential to the
>intended recipient and may also be privileged. If you are not 
>the intended recipient please delete it from your system and 
>notify the sender. You should not copy it or use it for any 
>purpose nor disclose or distribute its contents to any other person.
>********************************************************************
>