Talk:PubMan Func Spec History of affiliations
from the definition it seems as if the type of change can readily be inferred from the actual untyped successor/predecessor relations - so it seems redundant.--Robert 10:06, 27 March 2009 (UTC)
Do you really think that can be inferred? That would be great! There seem to be the following types of predecessor: replacement, fusion, spin-off, splitting. Frank 09:17, 31 March 2009 (UTC)
- it sure sounds like it:
* An OU(1) has one direct successor OU(2) and not exists anymore in reality (i.e. is closed). The OU(1) is set in status closed (replacement). * An OU is founded as fusion from two or more other OUs (fusion). The new OU has multiple predecessors. * A part of an OU(1) is created as spin-off. The OU(1) exists (i.e. is not closed) beside the new OU(2) (spin-off). * An OU(1) is split-up into multiple new OUs (OU(3), OU(4), …) and has therefore multiple successors. OU(1) not exist in reality any longer and is therefore set to status ‘closed’. (splitting)
of course the state to infer the type of change from would have to be timestamped, and either e.g. the closing for a replacement would have to happen at the same time or before creating the replacement. but i still think inference would be better than risking data getting out-of-sync because the user inserts a type of change not matching the actual state.--Robert 09:23, 31 March 2009 (UTC)
i would even say that if the type of change cannot be inferred automatically, it should simply be a freetext note or something like that to avoid home-made inconsistency problems.--Robert 09:27, 31 March 2009 (UTC)
--Steffen 11:27, 31 March 2009 (UTC) Let me try to finsish the defined rule set: 1.Replacement Only one predecessor has to be related. The predecessor has to be in status close. 2.Fusion Two or more predecessors has to be related. Each predecessor has to be in status close. 3.Spin-off One or more predecessors has to be related. Each predecessor has to be in status open. 4.Splitting: Only one predecessors has to be related. The predecessor has to be in status closed. 5.Affiliated One predecessor has to be related. The predecessor has to be in status closed.
If the include the reverse direction into the infer method, than is it possible to derive the type of predecessor from the realtion. But this requieres a fixed workflow where the predecessor OU is in the right status before the successors is set. If a relation could be set “at any time” than is it possible to create predecessor relations with the potential to be wrong interpret. For example is OU(2) set as successor of OU(1) but OU(1) is not closed yet. Until OU(1) is close is OU(2) a spin-off, but with the close of OU(1) is OU(2) a replacement (for requirement definition see http://colab.mpdl.mpg.de/mediawiki/PubMan_Func_Spec_Organizational_Unit_Management#Future_Development). And it seems impossible to infer situations where OUs are created through a combination of multiple of these defined scenarios.
If inconsistency is defined though User/Solution, than wouldn't free text help to prevent inconsistencies.
- In my understanding we have agreed to have in next release:
a) typed relations
to avoid incosistencies, and in future development i.e. when relation objects are created
b) dates and some comments that would better explain the change
We can not expect that users would actually be able to set-up the right status at right time, therefore it was agreed to have the possibility to set these relations at any time after opening of an OU. --Natasa 08:00, 1 April 2009 (UTC)