This document is also available in these non-normative format: pdf
This document is licensed under
Creative Commons 0 Public Domain Dedication
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 is a draft that could be altered, removed or replaced by other documents. It is not a recommendation approved by TO.
This section is non-normative.
The Core Public Rule Management Vocabulary (CPRMV) extends the Core Public Service Vocabulary Application ProPSV-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 ProPSV-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 ProPSV-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 ProPSV-AP) standard to conform to a proposed standard for Public Rule Mangement in which:
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 Git Issues page.
Besides this ReSpec documentation, the actual vocabulary is defined in the form of RDF(S)/OWL/SHACL designed to match how the Core Public Service Vocabulary Application ProPSV-AP) has also been specified in the same way. This specification of the CPRMV can be found here: CPRMV RDF(S)/OWL/SHACL specification
Also noteworthy is the development of a helper tool in the form of a so called CPRMV API: CPRMV API which can also be found in the Git repository: CPRMV API on Gitlab
Also note the CHANGELOG.md and ROADMAP.md relating both the CPRMV as well as the CPRMV API
This section is non-normative.
All concepts in relation to the Core Public Rule Management Vocabulary (CPRMV) are defined in the normative sections hereafter. This section gives a non normative overview of the concepts of the Core Public Rule Management Vocabulary (CPRMV).
The following overview shows the main Core Public Rule Management Vocabulary (CPRMV) concepts in relation to each other and how they relate to the Core Public Service Vocabulary Application ProPSV-AP) (version 3.2.0). Note that the overview does not include the entire Core Public Service Vocabulary Application ProPSV-AP), only a relevant part. The overview does include the entire [Core Public Rule Management Vocabulary (CPRMV).
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 ProPSV-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.
A set of Rule's. Which is produced as cv:Ouput within a cpsv:Publicservice. While not always being a eli:LegalResource, a eli:LegalResource is to be seen as a cprmv:RuleSet. Just like eli:Work, CPRMV defines RuleSet's as FRBR Work (frboo F1_work). eli:LegalResource's are eli:Work's too and more formalised versions thereof are to be seen as a derivation of those eli:Work's' too but separate Works. Also, being a cv:Ouput, a cprmv:RuleSet cprmv:is_part_of a dcat.Dataset
subclass of: http://data.europa.eu/m8g/Output
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|---|---|---|
| id | 1..1 | denotes a universal unique id with which to refer to what the cprmv object like RuleMethod's Explanation's, RuleSet's and Rule's represents. | |
| isBasedOn | Rule Set, Rule | 0..* | In the case of a RuleSet this property states the RuleSet to be derived from the RuleSet(s) in their entirety (all cprmv:Rules contained in the cprmv:RuleSet that is derived from, depending on whether they are defined with the same cprmv:hasMethod or not, can or must have matching ones in the cprmv:RuleSet that derives) possibly aggregated by analysis or formalisation (not codification). In the case of a cprmv:Rule it refers to the matching cprmv:Rule contained in a cprmv:RuleSet that is derived from by the RuleSet that contains the deriving cprmv:Rule (this must be the case). A cprmv:Rule in the cprmv:RuleSet that is derived from does not have to be referred by a cprmv:Rule contained in the deriving cprmv:RuleSet if both RuleSet's contain only cprmv:Rule's defined with the same cprmv:method, in which case this implies the cprmv:Rule implicitly becomes part of the deriving cprmv:RuleSet as is. Multiple cprmv:Rule's / cprmv:RuleSet's can be derived from within the same cprmv:Rule / cprmv:RuleSet |
| output of | 1..1 | denotes a cprmv:RuleSet to be produced as cv:Ouput of a cpsv:PublicService | |
| method | Rule Method | 1..* | denotes the cprmv:RuleMethod used to define the cprmv:RuleSet |
| validFrom | xsd:date | 1..1 | denotes the date from which day on the RuleSet is to be held valid. |
| validUntil | xsd:date | 0..1 | denotes the date until which day on the RuleSet is to be held valid. On the day of this date, the RuleSet is no longer valid. If no date value is set, this means the RuleSet is valid until further notice. |
| publishedOn | xsd:date | 0..1 | denotes the date at which day the RuleSet has been officially published. Note that the RuleSet may denote to be valid from a date before this date of publishing. |
| hasPart | Rule Set, Rule | 1..1 | denotes the ordered list of Rule's as the parts a Rule(Set) can have and together with the cprmv:definition and cprmv:postDefinition properties (in case of Rule's') define the Rule(Set) by concatenating the definition, the definitions of the cprmv:Rule's that are part of it (recursively in order) and their postDefinition's |
| comment | xsd:string | 0..1 | denotes information as comment for a cprmv:Rule, cprmv:RuleSet or cprmv:RuleMethod |
A Rule Set that has been produced by following a Analysis Method.
subclass of: RuleSet
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Rule Set that has been produced by following a Formalisation Method.
subclass of: RuleSet
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|---|---|---|
| hasAnalysis | Analysis | 0..* | denotes the Analysis a DecisionModel is based on. |
A Rule denotes a official expression of an agreement which can both be expressed in natural language like articles in laws as well as more formal business rules for automation of decisions
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|---|---|---|
| id | 1..1 | denotes a universal unique id with which to refer to what the cprmv object like RuleMethod's Explanation's, RuleSet's and Rule's represents. | |
| isBasedOn | Rule Set, Rule | 0..* | In the case of a RuleSet this property states the RuleSet to be derived from the RuleSet(s) in their entirety (all cprmv:Rules contained in the cprmv:RuleSet that is derived from, depending on whether they are defined with the same cprmv:hasMethod or not, can or must have matching ones in the cprmv:RuleSet that derives) possibly aggregated by analysis or formalisation (not codification). In the case of a cprmv:Rule it refers to the matching cprmv:Rule contained in a cprmv:RuleSet that is derived from by the RuleSet that contains the deriving cprmv:Rule (this must be the case). A cprmv:Rule in the cprmv:RuleSet that is derived from does not have to be referred by a cprmv:Rule contained in the deriving cprmv:RuleSet if both RuleSet's contain only cprmv:Rule's defined with the same cprmv:method, in which case this implies the cprmv:Rule implicitly becomes part of the deriving cprmv:RuleSet as is. Multiple cprmv:Rule's / cprmv:RuleSet's can be derived from within the same cprmv:Rule / cprmv:RuleSet |
| hasPart | Rule Set, Rule | 0..1 | denotes the ordered list of Rule's as the parts a Rule(Set) can have and together with the cprmv:definition and cprmv:postDefinition properties (in case of Rule's') define the Rule(Set) by concatenating the definition, the definitions of the cprmv:Rule's that are part of it (recursively in order) and their postDefinition's |
| definition | 0..1 | denotes the head part of the definition of a cprmv:Rule which is either a rdfs:text or any representation of knowledge in the form of rdf | |
| postDefinition | 0..1 | denotes the tail part of the definition of a cprmv:Rule which is either a rdfs:text or any representation of knowledge in the form of rdf. This property is only to be used when there are one or more cprmv:Rule's contained by the cprmv:Rule this property belongs to | |
| comment | xsd:string | 0..1 | denotes information as comment for a cprmv:Rule, cprmv:RuleSet or cprmv:RuleMethod |
| source quote | 0..1 | replicates (a part of) the definition of the cprmv:Rule that is being extended |
A Rule that forms a parameter. Normally these are specific small parts of a Rule Set that are changed more often than the rest of a Rule Set. They normally have a definition holding information that is of a simple type like a number, date etc.
subclass of: Rule
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Rule Method is a acknowledged known method for defining Rule's, either from scratch through deliberation and / or based on existing Rule's.
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|---|---|---|
| id | 1..1 | denotes a universal unique id with which to refer to what the cprmv object like RuleMethod's Explanation's, RuleSet's and Rule's represents. | |
| comment | xsd:string | 0..1 | denotes information as comment for a cprmv:Rule, cprmv:RuleSet or cprmv:RuleMethod |
A Rule Method with which an existing Rule is extended through analysis, which does not yet entirely formalises a Rule semantically but only defines what is to be seen as a separate Rule and adds metadata to it or normalises its form etcetera.
subclass of: RuleMethod
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Rule Method with which an existing Rule is extended through formalisation, which entirely formalises a Rule semantically as far as possible and makes it represented in a interoperable way to the point cprmv compatible systems can comsume them within processes for delivering Public Services.
subclass of: RuleMethod
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Rule Method with which an existing Rule is extended through codification, which entirely formalises a Rule semantically if necesary as well as codifies them into an executable form that can be utilised by specific systems within processes for delivering Public Services.
subclass of: RuleMethod
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Rule Method with which an existing Rule is executed in the context of delivering a Public Service.
subclass of: RuleMethod
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
An explanation method defines the method for producing Explanations in relation to cprmv:Rule(Set)'s'
subclass of: RuleMethod
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Rule Method with which Rule's are defined that describe test scenario's defined in cprmv:TestSet's containing cprmv:TestCase's, which are specialised cprmv:RuleSet's and cprmv:Rule's and that can be tested in the context of a cprmv:RuleSet's.
subclass of: RuleMethod
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Rule Method for publication of the definition of Rule(Set)'s apart from the Execution of them...
subclass of: RuleMethod
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Rule Method for the referencing of Rule(Set)'s apart from the Execution of them...
subclass of: RuleMethod
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A cprmv:Explanation is a cprmv:Rule defined with a cprmv:ExplanationMethod. This Rule contains a concise explanation of one or multiple Rule's or RuleSet's.
subclass of: Rule
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|---|---|---|
| explains | Rule Set, Rule | 1..1 | denotes the cprmv:Rule(Set) a cprmv:Eplanation holds explanatory content of for the use of explaining them in the systems that use them for delivering Public Services |
A TestCase is a cprmv:Case defined for and following a TestMethod
subclass of: Case
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A TestSet is a cprmv:RuleSet containing cprmv:TestCase's defined for following a TestMethod
subclass of: RuleSet
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Decision is a cprmv:Rule defined following a ExecutionMethod
subclass of: Rule
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
A Case is a cprmv:Rule containing a list of Decisions defined following a ExecutionMethod
subclass of: Rule
properties (excluding inherited):
| Property | Type/Range | Cardinality | Definition |
|---|
Referenced in:
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.