Policy derivation and Quality Assurance workshop
Download as PPTX, PDF0 likes266 views
The document outlines a grant agreement focused on enhancing the reuse of information throughout the content lifecycle, emphasizing digital preservation and quality assurance (QA) in policy management. It details the definitions, policy models, and methods for managing ecosystem policies while addressing the constant change and obsolescence in digital preservation. Additionally, it highlights the importance of understanding risks and impacts associated with policy changes and the need for automated compliance validation to support research outputs.
![GRANT AGREEMENT: 601138 | SCHEME FP7 ICT 2011.4.3
Promoting and Enhancing Reuse of Information throughout the Content Lifecycle taking account of Evolving
Semantics [Digital Preservation]
Fabio Corubolo - University of Liverpool
29 October, PERICLES Workshop
Belgian Institute for Space Aeronomy, Brussels](https://image.slidesharecdn.com/pericleswp2t2-151118103615-lva1-app6891/85/Policy-derivation-and-Quality-Assurance-workshop-1-320.jpg)
Policy derivation and Quality Assurance workshop
- 1. GRANT AGREEMENT: 601138 | SCHEME FP7 ICT 2011.4.3 Promoting and Enhancing Reuse of Information throughout the Content Lifecycle taking account of Evolving Semantics [Digital Preservation] Fabio Corubolo - University of Liverpool 29 October, PERICLES Workshop Belgian Institute for Space Aeronomy, Brussels
- 2. Motivation Overview Definitions (Policy, QA) Policy model Policy derivation QA of Policies Policies in the ecosystem model Examples
- 3. Managing and enforcing policy (one of the project objectives) in the overall infrastructure, is qualified, time consuming work Good management requires Quality Assurance Change an obsolescence is constant Digital preservation approaches for ecosystem management are useful NOW, and in the long term
- 4. QA used to manage change by: ◦ validating the correct application of policies in the ecosystem. ◦ detecting potential conflicts ◦ constraining the ecosystem evolution Policy derivation ◦ Adding dependencies to the ecosystem model by mapping polices to policies and other ecosystem entities High-level policies Intermediate-level policies Concrete implementations via processes and technical services
- 5. Change and model analysis Registration / Model update Validation Entity registry / Model repository Workflow engine Components Digital ecosystem User interface Model editor / Change explorer Preservation process User input Trigger s Entity, dependencies, metadata Change actions Process execution Content Compiled workflow Models and policies Workflow and results Validation results Model views Knowledge base User input Uses Uses ?
- 6. Quality Assurance (QA): a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met (Webster)
- 7. Used in very diverse meaning in English, and in IT. ◦ A policy is a plan that defines the desired state inside an ecosystem. A policy describes the 'what' (guidelines) and not the 'how' (implementation). (Pericles) ◦ A policy is a statement of intent, and is implemented as a procedure or protocol. (Wikipedia) ◦ A formal statement of direction or guidance as to how an organization will carry out its mandate, functions or activities, motivated by determined interests or programs (Interpares) ◦ … Many more specific uses: access control, security, load balancing, configuration … policies Our definition: “high and intermediate level natural language descriptions of an institution’s aims/goals, with what constraints.”
- 8. ID, Name Version Policy statement (formal or not formal) QA criteria (condition-action, rule, Unit test or other formal definition) Purpose (reason of creating) Dependencies Classification Owner Responsible for the application Level on compliance (must, should, …) …
- 9. How: Trace the highest level policies, through intermediate levels, down to concrete implementations such as rules (constraints) , procedures, WFs, services Why: High level => abstraction from detail (principle) => less change in the long term Rationalise the ecosystem structure by showing the dependencies between different level-policies, procedures/services and other ecosystem entities Enable policy based methods for QA and validation
- 10. High level abstract policy Independent from any model structure Level of abstraction Policy entities Intermediate level(s) policy Other Ecosystem entities (At different level of abstractions) Connects to abstract level entities Link to concrete implementation: workflow, procedure, services QA methods High level intent and constraints in natural language Detailed intent and constraints in natural language - Unit tests - Rule language constraints (PAL, SWRL) - Validation queries to ecosystem model (SPARQL) Services DOs Users Processes, rules, workflows Infrastructure, SW etc
- 11. DO 1 TS 1 DO 2 ON 1 TS 2 TS 3 TS 4 TS 5 Models: Process (BPMN) Dependency (LRM) Semantic dependency depends on depends on depends on semantically depends on semantically depends on process process PO 1 PO 2 depends on TS 6 TS 6 depends on depends on
- 12. Top-down: Know what processes depend on a specific policy, and be aware of consequences of change Bottom-up: Know what policy is motivating or depends a particular entity; so that any change related to that entity could trigger policy re- validation Notice when the practice starts to deviate from the policies, that will help update the policies or correct the practice depending on the case.
- 13. Notice when practice starts to deviate from policies http://arstechnica.com/tech-policy/2015/08/cops-decide-to-collect-less-license-plate-data-after-80gb- drive-got-full/
- 14. ● Unit tests on policy ● Rule/action language constraints (PAL, SWRL) ● Risk analysis on the ecosystem graph ● Validation queries to ecosystem model (SPARQL) ● Policy conflict detection and change management
- 15. Process PolicyDigital Object Technical Service Community User uses TS to get access to Processes and Digital Objects manage executes rulebase, constraints, validation procedure, rulebase, constraints, validation procedure, rulebase, constraints, validation rulebase, constraints,
- 18. Understand the risks and impact associated with a change of policy. Be aware of changes (external and internal) that may invalidate a policy implementation. Understand and control how the content of the archive may evolve over time. When a standard checklist of policies needs to be implemented to adhere to a standard, the policy derivation and mapping will help prove the correct implementation.
- 19. It can tie in existing systems and methods and does not mandate a specific model or complete buy in Does not impose organisation structure; or policy or process language, but can be integrated in existing ones QA methods can be implemented as well in any language or fashion
- 20. To support QA of research outputs Automated validation of compliance with policies and standards ◦ ease the pressure on scientists as far as policy compliance is concerned ◦ Integrate preservation practices at the moment of creation to support reuse; integrates in existing infrastructure ◦ Helps to keep track of the decisions made when implementing policies and their rationale
Editor's Notes
- #4: Managing digital ecosystems is currently repetitive and time consuming work, requiring specialised knowledge and continuous monitoring of the state to guarantee correct functioning with respect to the policies and guidelines, management principles and decisions. We want to validate the correct application of policies to the ecosystem.
- #7: QA: In this specific task, the focus of QA is that of monitoring and validating the different ecosystem entities to ensure that they maintain their functionality and usability in time, as change occurs. Policy: can range from “political agenda” to high level to technical to precise rules, from natural language to formal language. In our case we want to keep a generic approach that could fit most use cases, as opposed to an approach that would impose the use of a formal language or of a specific level.
- #8: Policy: can range from “political agenda” to high level to technical to precise rules, from natural language to formal language. In our case we want to keep a generic approach that could fit most use cases, as opposed to an approach that would impose the use of a formal language or of a specific level. Instead of operating on specific digital object related issues, such as validating format migration, this task works on integrating the QA approaches into the models. We consider this an important task: it will allow tracing the correct application of the higher-level policies (guidelines, principles, constraints) in the concrete ecosystem implementation.
- #9: Policy template Why no policy level? difficult to agree on a standard for policy level not so important in practice: we want to map from high to low level, whatever those are for you it’s very hard to impose a way of thinking in this kind of issues; better to have a flexible system
- #10: Policy derivation is developed in T3.5.2 and extended in T5.3
- #11: The model will provide ways to link to concrete implementations but not describe how to implement as it’s assumed that system architecture and methods will already exist.
- #13: top-down: Know what processes depend on a specific policy; in case of change in policy, this would allow to know what processes are influenced by the change - implemented as a simple query to the ecosystem model bottom-up: Know what policy (if any) is motivating or depends a particular ecosystem entity; so that any change related to that entity could trigger policy validation (again query) Knowing the policy - process model will also help notice when the practice starts to deviate from the policies, that will help update the policies or correct the practice depending on the case. See emergence and evolution connection to the ecosystem metaphor.
- #16: Digital Object: any item that is available digitally Process: A process is a description of linked steps on how to transform an input to a certain output. A process can invoke other systems or need human interaction. Technical Service: A technical service consists of hardware and software. The software typically governs the behaviour of a technical service. We use “service” to mean any operation that a technical service offers to the outside. It can be a user interface, a service that provides value to an organisation or a Technical Service used for automated machine to machine communication. Policy: A policy is a plan that defines the desired state inside a digital ecosystem. A policy describes the 'what' (guidelines) and not the 'how' (implementation). Community: A) stakeholders interested in the future usage of the digital objects, also system internal users like policy editor, administrator
- #17: if processes are linked to a policy, they get executed. If for example the policy level is “should” and if a processfortransformation exists, it will get executed. Ecosystem Policy Management - PART 1 Policy - Modelling Game example: Implemented Policy: Save checksum with submitted content Level Of Compliance: Must
- #18: Ecosystem Quality Assurance - Modelling Game example QA Criterion: Every DO at the repository has a saved checksum Process For Model Validation: Get all Digital Object entities which are part of the Repository, pass each DO to the ProEV Process For Entity Validation: Check if the DO has a saved checksum, if not pass DO to ProT Process For Transformation: Calculate checksum and save it with DO