Rules

The rules concepts are based on specific phrasing defined in Request for Comments Summary RFC Numbers 2100-2199 that allows a standardised and consistent interpretation of the rules and provides a way to detect and represent them in textual forms and documentation. The table below summarises this association.

Permission refers to the indicated context being allowed or approved to be carried out. Permissions are only a 'permissive signal' i.e. it is not necessary to carry out an activity just because it is permitted (see obligation for this). Permissions can be used to record what has been permitted, such as in use-cases for policies, agreements, consent records, and risk assessments. Permission is indicated/associated using the relation hasPermission, and is typically indicated in textual form through the [RFC2199] keyword MAY.

A Permission means an optional acceptability, where the default or expectation is that something is not occurring and it is permissible to let it occur. Thus, when evaluating permissions, the only possible outcomes are whether it has or has not been utilised (see the fulfilment statuses).

Recommendation refers to the indicated context being suggested to be carried out. Recommendations are only a 'suggestion' i.e. it is not necessary (see obligation) to carry out an activity, but as it is being recommended, not carrying it out should be accompanied with a justification (see dpv:Justification that explains why it was not carried out. Recommendations can be used to record what has identified as the 'default' to occur with the possibility that it may not be desirable or may not occur in some cases. Such uses are typical in policies and guidelines. Recommendation is indicated/associated using the relation hasRecommendation, and is typically indicated in textual form through the [RFC2199] keyword SHOULD.

A Recommendation means a desired acceptability, where the default or expectation is that it is permissible to let it occur and it should be occurring. Thus, when evaluating recommendations, the only possible outcomes are whether it has or has not been utilised (see the fulfilment statuses).

Obligation refers to the indicated context being necessary or mandatory to be carried out. Obligations are a 'requirement' i.e. it is necessary to carry out an activity, which implies it is permitted, and that not carrying it out will be a problem or issue or violation. Obligations can be used to issue requirements in use-cases for policies, agreements, consent records, and risk assessments. Obligation is indicated/associated using the relation hasObligation, and is typically indicated in textual form through the [RFC2199] keyword MUST.

An Obligation means a necessary acceptability, where the default or expectation is that something is not occurring and it is necessary to make it occur. Thus, when evaluating obligations, the only possible outcomes are whether it has been fulfilled (i.e. what was said has been carried out), unfulfilled (i.e. not carried out but there is scope to so), and violated (see the fulfilment statuses).

Prohibition refers to the indicated context being necessary or mandatory to NOT be carried out. Prohibitions are a 'requirement' i.e. it is necessary to NOT carry out an activity, which implies it is not permitted, and that carrying it out will be a problem or issue or violation. Prohibitions can be used to issue requirements that are different from obligations in that the implementer must ensure the prohibited part is not being carried out, whereas obligations require that part to be carried out. Prohibition is indicated/associated using the relation hasProhibition, and is typically indicated in textual form through the [RFC2199] keyword MUST NOT.

A Prohibition means a necessary unacceptability, where the default or expectation is that something is not occurring and it is prohibited to let it occur. Thus, when evaluating prohibitions, the only possible outcomes are whether it has been fulfilled (i.e. what was said has NOT been carried out) or violated (see the fulfilment statuses).

Deterrence refers to the indicated context being suggested to NOT be carried out. Deterrences are only a 'suggestion' i.e. it is not necessary (see prohibition) to prevent an activity, but as it is being deterred from being carrying out, it should be accompanied with a justification (see dpv:Justification that explains why it was carried out. Deterrences can be used to record what has been identified as the 'default' that should not be occurring with the possibility that it may be desirable or may occur in some cases. Such uses are typical in policies and guidelines. Deterrence is indicated/associated using the relation hasDeterrence, and is typically indicated in textual form through the [RFC2199] keyword SHOULD NOT.

A Deterrence means a desired unacceptability, where the default or expectation is that it is not permissible to let it occur and it should be not occurring. Thus, when evaluating recommendations, the only possible outcomes are whether it has or has not been utilised (see the fulfilment statuses).

Rules can be expressed in two forms: (1) by directly declaring them as an instance of a specific rule concept; and (2) by using the relation to declare an interpretation/application of a rule. The example below shows both in use, where the first method uses a relation to indicate whether a process is permitted or prohibited, and the second contains the process itself being declared as permitted or prohibited.

Both methods have their advantages or utility. For Method 1 where relations are used, this allows existing processes to be contextually declared as permitted in one use-case and prohibited in another. For Method 2 where instances are used, this allows annotating processes or use-cases as being permitted or prohibited in entirely -- e.g. in reports. A note of caution: though Method 1 uses relations, it can be inferred that the process is being permitted/prohibited when running a reasoner (which is correct in context).

The DPVCG is exploring representing the state of rule fulfilment through concepts, for example to represent a prohibition has been violated, or an obligation has been fulfilled, or a permission has been utilised. The currently provided concepts for these, represented by the concept RuleFulfilmentStatus and its taxonomy, which are associated using the relation hasFulfilmentStatus, indicate the intent and scope of this work.

The DPVCG is working with ongoing efforts regarding similar modelling of concepts for ODRL implementations, in particular to ensure the concepts in DPV are in sync and compatible with those developed for ODRL. The below issue shows the progress for this.

Though DPV provides concepts representing deontic logic, it does not specify what should be the 'default' interpretation in relation to rules, i.e. it does not provide an interpretation of whether some rules apply automatically unless otherwise declared. For example, in declaring an instance of Process, the assumption is that the activities are modelled for what is happening or what is intended/planned to happen. The explicit annotation using a Permission rule adds information about whether some activity is permitted (and its associated information). Instead, if the use-case is using DPV to only document activities that are permitted, there is no need to explicitly specify the permissions. Similarly, just because something is happening or planned to happen, it cannot be assumed to be permitted (e.g. pending evaluation of legal requirements).

This lack of default interpretation enables modularity in the use of DPV concepts. For example, an instance of dpv:Process which does not have a dpv:hasRule declared within it, can be made part of a rule to specify permissions, prohibitions, or obligations regarding the process. If instead the process had a default interpretation (e.g. permission), then it would require creating a separate instance with the same information - leading to duplicated efforts. While an apparent solution is to create a mechanism whereby the rule in the process is overridden with the intended 'outer' rule or context e.g. to specify the prohibition in one process overrules permission in another process, this prevents the combination of rules to describe situations such as a permission for a larger context within which specific parts are prohibited or obligated.

In representing Rules, DPV only provides the concept and does not express any inherent semantics on what those rules mean in relation to each other. For example, DPV does not express Permission to be non-compatible or disjoint from Prohibition. This is to separate the interpretation and application of rules based on the necessities of a use-case. For example, in a legal investigation it may be prudent to specify permission and prohibition can never occur together, but this may not be true if there are different legal requirements that allow a prohibition to be resolved or deferred, such as through another permission that overrides the prohibition.

Further, as described earlier in the section on default interpretations, it is possible to mix or nest rules such as through processes. For example, if ProcessA is a permitted process and contains ProcessB which is a prohibited process, DPV does not dictate what should be default interpretation for this arrangement. The role of DPV concepts regarding rules, as of now, is to provide a simplified indication of whether something is permitted, prohibited, or obligated. Further interpretations require creation of a formal specification that dictates how rules should function together. For example, depending on the use-case, several interpretations are possible for the example described here:

1. Prohibitive interpretation: Both ProcessA and ProcessB are prohibited because through ProcessA is permitted, ProcessB is within it and is prohibited - thereby prohibiting both processes. Such interpretations prevent modularity - everything is prohibited because something is prohibited, or it is permitted because there are no prohibitions.
2. Permissive interpretation: ProcessA and ProcessB are both permitted since ProcessA gives permission for the entire process and overrides the prohibition in ProcessB. Such interpretations also prevent modularity - everything is permitted because the higher/broader processes are permitted even though there are specific prohibitions at a granular level.
3. Contextually Prohibitive interpretation: ProcessB is prohibited as declared, and the rest of ProcessA without ProcessB is permitted. If there was a further ProcessC that is permitted, and is present within ProcessB, then ProcessC would still be prohibited as the broader prohibition from ProcessB overrides it. Such interpretations permit modularity with permission granted for parts as long as there is no prohibition overriding it from a broader context. In this, a prohibition within a permission still allows the permitted parts to be carried out, whereas a permission within a prohibition would still be prohibited.
4. Contextually Permissive interpretation: This is the same as the contextually prohibitive interpretation, except permissions occurring within prohibitions are not overridden. This means, ProcessA is allowed through its permission, with ProcessB within it being prohibited, except for ProcessC within ProcessB - which is permitted.

The above example interpretations only concerned permissions and prohibitions, and did not include obligations - or other concepts such as duties, dispensations, exceptions, and defeasibility. From this, it should be clear how the specification and interpretation of rules can be quite complex and has a large impact on the intended activities and information being documented.

DPV uses the following terms from [RDF] and [RDFS] with their defined meanings:

• rdf:type to denote a concept is an instance of another concept
• rdfs:Class to denote a concept is a Class or a category
• rdfs:subClassOf to specify the concept is a subclass (subtype, sub-category, subset) of another concept
• rdf:Property to denote a concept is a property or a relation

The following external concepts are re-used within DPV: