On 18th-19th May, King’s College London hosted the third in a series of DReSNet workshops on policies in repositories. The workshop was attended by members of the FP7-funded project SHAMAN, colleagues from King’s and from the University of Amsterdam. The workshop focused on understanding the derivation of processes (implemented as software) from policies.
The SHAMAN derivation procedure was used as the starting point for the discussion. The procedure takes the hypothesis that each process must be able to find a home within a policy, that is each process must be uniquely associated with a policy statement. The procedure starts with a derivation of detailed policy statements from the policy document. Each statement in the document is studied and the steps necessary to achieve the statement are documented. The dependencies on other statements are also described, as are the assumptions made in defining the steps. The steps needed to achieve the policy statement are then transformed into high-level rules (we have selected the W3C standard Rule Interchange Format, RIF, as the high-level language). Again, any assumptions made in the transformation need to be documented. The high-level rules can then be translated into low-level, implementable rules (such as iRODS rules) or processes. For many, the distinction between the high-level rule and the detailed policy is blurred, as much of the work is carried out while making the policies themselves more detailed, so that they can serve as the basis for formalisation.
The high-level rule is just a formalised form of the policy statement. However, the fact that the choice of high-level rule format (currently the RIF) may change in the future suggests that it is prudent for the time-being to keep the two steps separate. But, the procedure has been modified to take account of the optional nature of the step (see Policy Refinement Process).
The workshop found that that the SHAMAN procedure missed out some important information. The fact that policies or sub-policies may exist within the organisation, or that workflows may exist within the organisation were not taken into account. The impact on the procedure was to introduce the issue of conflicting rules or workflows in which a rule derived from the derivation process may conflict with an existing rule. Possible reasons for the conflict could be that the existing rule corresponds to multiple policy statements, or covers a partial statement. In this case a procedure to resolve the conflict would need to be established. The procedure to resolve the conflict would necessarily be manual as this would involve understanding the nature of the conflict and the assumptions made in creating the rules. In some cases the conflict resolution may be made more difficult due to an ‘orphaned’ existing rule where an understanding of how the rule was derived does not exist. Although conflict resolution may be manual the identification of conflicts can be almost totally automated.
Conflicts at the policy level arise when new policies are created. An understanding of how they relate to existing policies and the impact on existing policies would need to be assessed. It can be argued the creation of the new policy would already involve an understanding of the impact on existing policies. The new policy may require changes to existing policies that would have a ‘trickle-down’ effect at all levels. The refined diagram is shown in Policy System Data Model.
An interesting point was raised during the workshop that all policies are inherited. That is all policies are really sub-policies as they are all derived from some existing policy (for example, we ultimately operate within the law and the law is a policy that describes how society interacts). This is a refinement of the original identification of external policies that influence an organisation’s policies.
The workshop then took a couple of example policy statements from a JISC-funded project (link??????) to test the derivation procedure. The tricky part of the procedure was in understanding what assumptions had been made during the derivation. It was helpful that members of the workshop were not experts on the project and were able to ask questions on why certain choices were made in the description of the workflow. In general the derivation of rules from policies may be the result of a small group of individuals from within the organisation which may make it difficult to distinguish common, current organisational practices from standard practices. Perhaps the best rule of thumb is to justify everything to ensure longer-term sustainability. The workshop also thought it useful to review the derivation process on a yearly basis to update the assumptions to ensure they are still understandable.
The next steps for the group are to continue to take more example policies and apply the procedure to generate processes in order to
further work-harden the procedure as well as to continue to understand the conflict identification and resolution procedure.



