CPRMV 0.4.0

The Core Public Rule Management Vocabulary (CPRMV) extends the Core Public Service Vocabulary Application Profile (CPSV-AP) standard to conform to a proposed standard for public rule management.

Whereas in general, public organisations in some way utilize business rules to operationalize government services, this is almost only done within the organisation. Often they are based on agreements, like policies that also are not publicly shared and often: rules fill gaps in the details in the interpretation of all agreements (laws, policies, standards, architecture, decisions and so on) into an operationalized service themselves.

It is necessary to understand that rules, whether formal or non formal, are agreements also, just like the rules denoted in the form of natural language in laws and decisions and that they need to be openly shared with end users of the services that operate on them to support these end users properly.

Moreover, rules often formalize on agreements published by other organisations too. When rules are only made within the scope of a single organisation, this prohibits effective reuse of rules. A single formalisation of a rule might get reinvented for thousands of times adding to the risc the formalisations interprets agreements differently where this should not be the case and can not be attributed to a difference in context. By not openly sharing rules such that they can be easily found in relation to serice descriptions, transparency lacks and effective reuse and feedback processes are prohibited.

The Core Public Service Vocabulary Application Profile (CPSV-AP) defines a standard for describing services, optionally up until the concept of a "Rule" in relation to the agreements it formalizes. But the Core Public Service Vocabulary Application Profile (CPSV-AP) leaves much of this undefined as it is more focused on specifying a single set of rules that describe the requirements for end users to be eligible to use a service, whereas services and rules can be more complicated than that as rules often have many sources of agreements across many organisations that when effectively managed for reuse should include other rules also.

To overcome all this the Core Public Rule Management Vocabulary (CPRMV) extends the Core Public Service Vocabulary Application Profile (CPSV-AP) standard to conform to a proposed standard for Public Rule Mangement in which:

• all bundled agreements are formalized as a set of similarily bundled rules
• all bundled rules are published in public as agreements
• like other published agreements, bundled rules are identifiable and therefor referrable through some acknowledged method of reference like European Legislation Identifier (ELI)
• like other published agreements such as laws, rules can refer to other bundled agreements both being a reference to some part of a bundled rules source and therefor automaticly the sources it formalizes.
• a CPSV-AP PublicService follows the set of rules in a single most specific bundled rules source
• a separate CPSV-AP PublicService is defined in which bundled rules conforming to the Core Public Rule Management Vocabulary (CPRMV) are being defined and supported and have a bundled set of rules as its output
• CPRMV does not enforce specific methods for analysis, formalization, testing, codification, execuction, publication or referencing of rules but allows for identifying these methods

A standard for Public Rule Management can than elaborate on how to operationalize services based on rules that include not only the development and execution of a specific set of rules but also services to correct errors, change the rules as well as continuously improve them in interaction with all stakeholders, including the people and companies that have to make use of the services.

This specification defines the Core Public Rule Management Vocabulary (CPRMV). The Core Public Rule Management Vocabulary (CPRMV) is the basis for a standard for public rule management for which the regels.overheid.nl is the (Dutch) portal for all related knowledge and tooling for now.

This specification is in development in the context of the (Dutch) regels.overheid.nl project. Comments, problems, wishes etcetera can be left through issues using the Github Issues page.

Where the CPSV-AP associates a service with zero to many Rules (the Rule concept in the CPSV-AP), stating the service "follows" these Rules, and such a Rule "implements" a Legal Resource (European Legislation Identifier (ELI)) which can be related to many other Legal Resources, the CPRMV denotes a Legal Resource to be formalised by a single RuleSet, that are sets of Rules (the Rule concept in the CPRMV) that together "implement" (formalises) the related Legal Resource to a certain extent. In CPRMV we do not call this a "implements" relation but a "isBasedOn" relation which is equivalent to eli:based_on.

Where two Legal Resources relate, also the RuleSets that implement these Legal Resources will relate in the same way to each other. Rules may however refer to specific concepts within other Rules in the same or related RuleSets. Moreover, a RuleSet is to be seen and published as a Legal Resource too which can be formalised even further through a single other RuleSet.

When using the CPRMV, a Public Service (CPSV-AP) can implicitly follow the Rules from a single RuleSet, and therefor all the Rules a service follows refer to the same legal resource that is the most specific legally binding agreement that defines the service. Such legal resources currently are often not defined and if they are often not published as such. CPRMV denotes all RuleSet's as referenceable LegalResources and as output of a Public Service (though note Government to Government services included). Output produced with regard to contract management proces of the Public Service and therefor by the organization delivering this service.

The CPRMV allows for specifying the method with which Rules in a RuleSet are defined. There are four general types of such RuleMethods for formalising agreements: Analysis Methods, Formalisation Methods, Codification Methods and Test Methods. Also there are some more abstract RuleMethods that come into play as being able to find all information about how rules are formalized all the way up until case's with the decisions being made by following rules within service operations is essential, both for people working in governments as citizens and companies. These other types of RuleMethods are: Publication-, Execution-, Test- and Reference Methods.

Analysis Methods do not yet entirely formalize knowledge in a legal resource such that you get rules that can be seen as deterministic enough for use in the operationalisation of services that then need to be able to follow these rules. Typically these methods involve annotating legal resources, structured as a set of rules with expert knowledge towards full formalisation. Adding metadata, sometimes also done within a method for publication is also a form of a Analysis.

Formalisation Methods are methods for interpretation of knowledge, describing them as rules in a way that make them suitable and interoperable enough for operationalisation by systems that conform to the [CPRMV] within the processes with which a Public Service is delivered..

Codification Methods are methods for transforming formalised rules into a code language that can be executed by specific systems within the processes with which a Public Service is delivered. Normally these are quite technical, can be defined in a very sound way and less important just like programmers do not usually should have to look at te level of machine language.

Note that services may be defined in which these methods are applied by multidisciplinary expert teams who are guided by these services. These teams will consist of representatives from different disciplines of the competent authority organisations that also specify the legal agreements and publish them as resource that impact the services that follow the rules in the rulesets that are based on these legal resources. These services do operationalize on rules as goal artifacts and probably can consume them for that goal. In such services, a RuleSet is the Ouput of the service in terms of the Core Public Service Vocabulary Application Profile (CPSV-AP). This makes all Rules, even those only containing the extra knowledge through applying Analysis Methods machine consumable, not to be mistaken for machine executable.

Typically, RuleMethods also allow for testing Rules using test datasets which contain testcases (sometimes also called test scenario's). Just like the Rule concept in the Core Public Rule Management Vocabulary (CPRMV), a test case only add extra very specific rules to rules to see, whether all the rules together including the extra ones of the test case still hold or not. Therefor a dataset with test cases, a TestSet, is a RuleSet that has one or more TestCase's which are Rule's themselves. TestCases are developed and evaluated through Test Methods.

The standard for Public Rule Management the CPRMV is part of also includes a governed list of acknowledged Rule Methods. RuleMethods may include many things, including a prescribed way of utilizing the RuleMethod, or using prescribed tooling etcetera. Besides the obvious well known RuleMethods related to established Business Rule Management methods with related standards and tooling such as SBVR, DMN, some localised adoption of RuleSpeak, OpenFisca, Law Analysis (Wetsanalyse), Calculemus/FLINT and so on, also standards for describing architecture such as Archimate could actually be seen as a RuleMethod, or in the future maybe even methods utilising Universal Meaning Representations with some new type of AI that then probably will have to need to include symbolic AI reasoners to become reliable enough. Even this very document, the CPRMV vocabulary can be formalized as a RuleSet conforming to itself and becoming a potential standard as a legal resource that other Rules in other RuleSets can refer to.

Allowing all these kinds of RuleMethods mixed together does not fully solve interoperability on its own, but it allows for getting all information already put into practice yet kept hidden, published openly from which point it is more easy to get to see how things correlate and to collaborate on traceability, explainability and interoperability resulting in more transparency, trust and efficiency. This is an important first step. All Rules express knowledge that needs to be known and explainable. Rules expressing the same knowledge with different RuleMethods that formalize to a comparable extent, should actually not differ that much semantically, and it should be fairly possible to work on rule interchange once the benefits of public rule management become clear. The more RuleMethods are in use, the more systems will need to be able to support them all. To enforce a single RuleMethod at current times is unrealistic however and probably not favorable in the future too, as none single RuleMethod will suffice for all in all cases. It will however become evident where stacking different interpretation steps using different methods on top of each other will only increase riscs and work if not part of a methodological approach.

New is the concept DecisionModel, which is a Rule Set linked to a Formalisation Method, and the concept Analysis which is a Rule Set linked to a Analysis Method. A Decision Model typically is based on an Analysis (indicated with a new hasAnalysis property which implies a isBasedOn property). Also new is the concept of a Parameter, which is a Rule that definessmall parts of information typically with simple types that often changes, like numbers and dates.

All Rules must cite and/or refer to their specific sources they form an analyis/formalization of. This can be done through a AnalysisMethod that just chunks a legal resource in identifiable Rules and subparts, citing the legal resources that often are crafted in natural language and published as such.

Rules refer to explanations where possible, for any specific stakeholder group requiring specific explanation of the Rule on its own (context independent), given a certain natural language and level of language that matches the group of stakeholders as intended audience. Note that these explanations may also have parts of explanations in a way such that context dependent (personalized) explanations can be made by services that operationalize on rules. It depends on the type of an Explanation object what content to expect. The CPRMV does not prescribe anything for this yet.

The idea not to rely on services utilizing machines to generate explanations on formalized rules (without explanatory content) in its entirety is to have more unification and deliberation on how rules are to be explained to (and therefor interpreted by) any stakeholder. Automation of explanatory content based on Rules is possible but resembles the possibility of automation of formalisation of Rules from legal resources in natural language both of which will always need human oversight before and during services that operationalize on them. Also, automation requires all agreements to be available in a machine consumable form which currenlty seems not to be the case for details in the interpretation of agreements that are published and for example policies for edge cases solved only locally in an ad hoc way.

These Explanations are also to be defined at the level of a whole RuleSet (which can specify a public service). Again, these may be automaticly generated through the explanations of the rules in the ruleset, but not entirely and not without proper human oversight.

The CPRMV is part of a standard for public rule management that will guide organisations to publish their RuleSet's (bundled sets of Rules) as legal resources in relation to the legal resources they implement.

Note that it might be persuasive to extend this vocabulary with metadata on the operationalisation of sercices that follow the rules. Where this metadata has its origin in some specific Rule or legal resource it cites or refers to this might be plausible but then it might be best to introduce a RuleMethod for formalising the metadata at that level. Where the metadata is not dependent on Rules or Legal Resources (not affecting the outcome of a service), or form explanations, it is better not to include this in RuleSets. This kind of metadata might however be bundled with RuleSets and the explanatory content in relation to the same legal resources too to keep all relevant things together in relation to services.