The Agile Project (late 2008-2012)

Traceability and change in legal requirements engineeringBuilding bridges between three knowledge domains

Alexander Boeraboer@uva.nl

Tom van EngersSaskia van de Ven

Project partners

Academic input: Leibniz Center for Law (University of Amsterdam) and Technical University Delft

Technology input and product development: BeInformed and O&I

User input and validating pilot studies: Immigration & Naturalization Service (IND) and Dutch Tax and Customs Administration (Belastingdienst)

About the project

Agile: Advanced Governance of Information services through Legal Engineering

Goal: Increase the agility of organizations that deliver law-governed services in a network environment

Products: 1. two PhD theses (Saskia & Yiwei)2. design methodology & prototype specification

language3. prototype distributed service-oriented

architecture & supporting tools

Two PhD theses

Leibniz Center: accounting for how law is implemented in the organization (Saskia van der Ven)

Delft University: accounting for how rational agents use the law, and the way it is implemented (Yiwei Gong) Effectiveness and efficiency Evasive behaviour of clients (taxpayers,

immigrants) Intentions of other network partners

(employers, family members, etc.)

Domains for examples and pilots

Sales transactions (private law) Legislating (reusability) Knowledge worker permits (IND)

Involves income criterium, potential for interaction with client, Belastingdienst and employer in application process

Income and wages (Belastingdienst) One person business (ZZP) wages tax

support pilot

Agility and Traceability

Two aspects of agility

Quick adaptation of the organization Processes, services, knowledge resources

are robustly designed Decoupling: Separation of concerns in

specification and implementation

Quick impact analysis Which processes, services, knowledge

resources, etc are affected by a change?

Legal impact analysis

Is a service, process, or resource redesign legally speaking effective and is it compliant? Sources of law: legislation, case law,

organizational guidelines

What problems and opportunities are created by a change in the sources of law for existing services, processes, and resources? Compliance, efficiency, enforceability, changing

patterns of service delivery (chain partners) and consumption (taxpayers, immigrants)

Abilities to develop in Agile1. monitoring and managing the sources of law relevant to the

organization, distinguishing versions of these sources of law, and determining the applicability of rules originating from these sources of law in time and to categories of cases;

2. maintaining traceability from sources of law to implementation knowledge resources without ending up with Gordian provenance link knots;

3. efficiently and quickly justifying existing business processes, data in databases, etc, justified by old law, in new law if possible;

4. anticipating the effects of changes in law not directly addressing the organization itself to service delivery and consumption by network partners and clients;

5. developing an organizational structure, IT infrastructure, other resources, and – importantly - network arrangements that are robust in the face of changes to the law; and

6. delivering timely, constructive, and accurate feedback to the legislator.

Traceability and Impact Analysis I

The main knowledge resource of legal impact analysis: Provenance links from implementation knowledge resources to sources of law Provenance = origin, history Tends to either be very incomplete or to

degenerate into a Gordian knot Domain-specific obligations are more likely

to be explicitly linked than ability-creating rules, even though the latter are more likely to cause big changes if they are changed!

04/20/23blad 12

2.1 uitzondering VVR BEP, aantoonbaar geen document kunnen krijgenDe vreemdeling kan worden vrijgesteld van de voorwaarde dat hij/zij een geldig GD moet hebben om een VVR BEP te kunnen krijgen.

Dit geldt als de SvJ oordeelt dat er:- valide pogingen zijn gedaan om een geldig GD te krijgen, en;- is aangetoond dat de vreemdeling geen geldig GD van de regering van het land waarvan hij onderdaan is, kan krijgen.

Dit laatste geldt in ieder geval voor Somaliërs.

Regelgeving Art. 3.72 Vb

J urisprudentie 200700890/1

Begrippen 1.12

2.4

Gen. normen GRD

Sourc

e o

f la

w

Implementation knowledge model

Intermediate representation

At the IND

Traceability and Impact Analysis II

Decoupling approach: simple inert concept-centered requirements model intermediating between sources of law and implementation resources New staff uses it to acquire domain

knowledge However, it plays no role in impact analysis

and implementation Determination of applicability of rules is hard

Approach: rule applicability reasoning & services simulation using an improved requirements model

Approach on the conceptual level

Improving agility of organizations by1. Ontological stratification and supervenience:

rigid identity criteria distinguish the legal institutional domain from its implementation in the organization

2. Versioning (and identification) of sources of law (MetaLex) and of implementation resources

3. Create a mediating Agile knowledge resource that distinguishes three knowledge domains

4. Traceability based on rules bridging knowledge domains and on concepts describing the knowledge domains

Three knowledge domains supervenient on eachother

Legal theory input

(Re)presentation: Some medium (re)presents a proposition or rule

Constitutiveness: Some (brute) thing counts as a legal thing according to some rule Normativity: action counts as a violation Abstraction: Every legal thing must be

constituted by some thing to exist

Applicability: Some rule applies to a thing

Evidence: something is evidence for a proposition

Isolating changes in three knowledge domains

Isolating changes in three knowledge domains

Isolating changes in three knowledge domains

Isolating changes in three knowledge domains

Isolating changes in three knowledge domains

Interface to other knowledge resources

Specifications, logical models, knowledge base rules, schemas, etc, used in the organization are not in the bottom layer, but share (contextualized interpretations of) concepts, rules, individuals, etc with the bottom layer.1. To share is to use the same IRIs for reference, or to

be able to resolve the IRI in one model to the corresponding one in the other.

2. Agile resources minimally interfere with technology choices in the organization

3. Import/export functionality is however very desirable, in particular for knowledge bases

4. In usage, knowledge is contextualized to problem setting (assumptions etc.) and restricted to tool/language-specific expressive fragment and semantics (datalog, epistemic interpretation, negation as failure)

“Brute reality”

business processes: when, why, and how to react when citizens want to interact with the organization?

citizen life event modeling: when and why do citizens want/have to interact with the organization?

services: Description of transaction script from perspective of client role focusing on the changes (on the service target) valuable to the client, as advertized by a provider capable of bringing about those changes

Service and business process patterns

legal services: the service target is the legal position of the client: the value provided is an improvement of the client's position, and intended by the client

Legal position analysis of transaction scripts based on Hohfeldian relations: bundles of duties/rights and powers/liabilities Service notion adds provider/client roles

Reuse business ontologies?

Example rules

Demonstration of how rules define the interface between domains and exist within domains

Example

Rules: t1 The publication of a text presenting a

rule counts as the creation of that rule. t2 Rule t1 applies to text published by a

rule maker.

t1 represents legal rule r1 and t2 represents legal rule r2

logical rules a1 and a2 (in OWL2) represent their meaning to agents that have to apply them

Rules in Agile

Legal rules are distinguished from (presenting) text and from (representing) logical axioms Exist in institutional reality, Exist in time, and Are Traceable

to expressions of sources of law (MetaLex) representation and applicability

to their use in implementation resources contextualization of the meaning of rules

Logical rules are about three layers of reality and the interfaces between them

Example

OWL2 rule a1: “The publication of a text presenting a rule counts as the creation of that rule.”

if Publication that(resultsIn some

(Text that (represents some Rule)))

then(constitutes some Creation that

(resultsIn some Rule) and (applicable value r1)))

Other example

OWL2 rule a2: Rule t1 applies to text published by a rule maker.

if Rule that (representedBy some (metalex:Expression that(metalex:realizes value t1)))

then(appliesTo all (Creation that

(actor some RuleMaker) and (applicable value r2)))

FRBR bibliographic layers in CEN MetaLex

Applicability rules

If t1 changes (a new expression of the work)

A new legal rule presented by the new expression is created

And rule r2 automatically applies to it because it applies to all rules presented in expressions of t1

Applicability and defeasibility

Two kinds of applicability Actual: if the rule produces a legal effect it

is/was applicable Potential: If it will produce a legal effect if

applied it is applicable

Defeasibility and whole OWL2 axioms no special conditional but belief base

revision presents a challenge in accounting for its

semantics Purpose is to find problems rather than

solve them

To do in the next years

Versioning methodology for all resources MetaLex for sources of law

Making the modeling simple using patterns “Model sentences” in the law Reusable service, transaction, process,

information carriers patterns (and agents)

Easy to use model editor Develop agent simulation architecture for

Impact analysis Simulating alternative implementations