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

["Hendrix, Thomas E" <thomas.e.hendrix@boeing.com>]

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.
>********************************************************************
>