alexander boer [email protected] tom van engers saskia van de ven
DESCRIPTION
Alexander Boer [email protected] Tom van Engers Saskia van de Ven. The Agile Project (late 2008-2012) Traceability and change in legal requirements engineering Building bridges between three knowledge domains. Project partners. - PowerPoint PPT PresentationTRANSCRIPT
The Agile Project (late 2008-2012)
Traceability and change in legal requirements engineeringBuilding bridges between three knowledge domains
Alexander [email protected]
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
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/22/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
Sour
ce o
f law
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 by
1. 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
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
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 rulesDemonstration 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
ExampleOWL2 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 exampleOWL2 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)))
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