Default Interpretation

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.

Mixing/Nesting Rules

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.

Classes

Properties

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:

External