Search
Login not required to view content
User login
Follow us on
AIR Tutorial
Introduction
Accountability in RDF (AIR) is a policy language represented in Turtle + quoting. The vocabulary –classes and properties- used for declaring policies is defined in the AIR ontology (ttl, owl 1, owl 2, class taxonomy). AIR supports generation of explanations for policy decisions and provides efficient and expressive reasoning.
In AIR, policy is modeled as production-rule containers. Rules are encoded as pattern-action pairs. Conditions for a rule is represented in form of graph pattern. The actions- assertions, triggering of a new rule- can be declared to be executed either when pattern is matched or when no match is found. A matched subgraph can be referenced and reused to generate justifications. Every action is associated with a justification- rule-id and matched pattern- at the run-time. A natural language description of the rule can also be included. Rules are of 2 types- Belief-rules and Hidden-rules. When an explanation for policy decision is generated the justification for actions in Hidden rules are not included. Compliance and non-compliance with policies can be asserted using compliant-with and non-compliant-with predicates. Detailed AIR policy specifications are provided here.
The tutorial is structured as follows. Section 2 provides description of the data referred to in the examples in the tutorial. AIR language features are covered in section 3. The conclusions from the policy reasoning are based on the output of the cwm/n3 and TMS-based AIR policy engine implemented at DIG, CSAIL, MIT. Section 4 discusses some features specific to this policy engine. Output from the policy engine- conclusions with justifications- can be best viewed using the Justification UI of Tabulator.
More examples and demos can be found here
The latest release of the Tabulator extension for Firefox is available here.
Data
Figure 1. Data Log
Data used for examples in the tutorial: Demo Data ( in RDF )
Description of the Data:
- Alice lives in Troy
- Bob lives in Troy
- George lives in Boston
- Alice has NY state ID 307578001
- David has NY state ID 307578002
- Troy is in state of NY
- Boston is in state of MA
- NY is neighbor-state of MA
- neighbor-state is an owl:SymmetricProperty
The general flavor of policies is that people belonging to NY state- because of their place of residence and/ or if they hold a NY state id- are policy compliant.
Section 3: AIR Language Features
3.1: Policy Modeling
Policy contain one or more rules. The preconditions for the rule are described as graph patterns where variable may occur at any of the 3 positions- subject, object or predicate- and is declared using the air:pattern property. The global variables are declared at the beginning of the document. The assertions are made using air:assert (or air:assertion) property.
3.1.1: Policy with Single Rule
@forAll :PERSON, :CITY.
:ny_state_residency_policy a air:Policy;
rdfs:label "NY State residency policy";
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.}]].
Global variables :PERSON and :CITY are declared first (beginning of the document). :ny_state_residency is a policy that contains the rule :state-residency-rule.
:state-residency-rule states that for all person and city when a person lives in that city and the city is in NY state, person complies-with the :ny_state_residency_policy.
Execute (Output of the Policy Engine)
Conclusions: Bob and Alice are compliant with :ny_state_residency.
(Bob and Alice live in Troy, which is in NY state)
The same policy can be written without explicitly naming the rule. However, for justification justification of actions taken when this rule is applied the policy engine assigns a random identifier for the rule.
@forAll :PERSON, :CITY.
:ny_state_residency_policy a air:Policy;
rdfs:label "NY State residency policy";
air:then
[ air:rule
[
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.}]] ]].
Execute
3.1.1.1: Rule with empty pattern
A rule with an empty pattern can also be asserted as shown in the example below.
TODO
Tutorial Policy 21:
@forAll :PERSON, :CITY.
:rpi_location_based_policy a air:Policy;
air:rule :troy-rule;
air:rule :hartford-rule.
:troy-rule a air:Belief-rule;
rdfs:label "rpi in troy rule";
air:if { };
air:then [air:assert [air:statement {:rpi tamip:Located_In :troy.}]].
:hartford-rule a air:Belief-rule;
rdfs:label "rpi in hartford rule";
air:if { };
air:then [air:assert [air:statement {:rpi tamip:Located_In :hartford.}]].
:troy-rule adds a fact to the data-set that rpi is located in troy. Similarly :hartford-rule adds the fact rpi is located in hartford.
Conclusions: Alice is compliant with '':ny_state_residency_and_id_policy.
(Alice lives in Troy which is in NY state and has NY state id 307 578 001)
3.1.2.1.2: Negatively Nested, nested rule becomes active when the pattern doesn't match (air:alt)
@forAll :PERSON, :CITY, :STATE.
:ny_neighbor_state_residency_policy a air:Policy;
air:rule :non-ny-residency-rule.
:non-ny-residency-rule a air:Belief-rule;
rdfs:label "Non NY residency rule";
air:if {:PERSON tamip:Lives_in_city :CITY.};
air:then
[ air:rule [
air:if {:CITY tamip:Has_state :NY.};
air:else [air:rule :neighbor-state-rule]]].
:neighbor-state-rule a air:Belief-rule;
rdfs:label "neighbor state rule";
air:if { :CITY tamip:Has_state :STATE.
:NY tamip:Neighbor_state :STATE.};
air:then [air:assert [air:statement { :PERSON air:compliant-with :ny_neighbor_state_residency_policy. }]].
:ny_neighbor_state_residency_policy contains three rules: :non-ny-residency-rule, :neighbor-state-rule and an anonymous rule nested in :non-ny-residency-rule. The anonymous node is positively nested, i.e. this rule is triggered when there is a match for the pattern in :non-ny-residency-rule. In contrast, the :neighbor-state-rule is negatively nested in the anonymous rule. That is, the :neighbor-state-rule would be triggered when the pattern :CITY tamip:Has_state :NY has no match.
According to the :non-ny-residency-rule, if a person lives in a city and if 'the city in NY state' does not hold, apply the :neighbor-state-rule rule. When the :neighbour-state-rule is applied, if the city is in a state, and the state is a neighboring state of NY, the person is asserted to comply with :ny_neighbor_state_residency_policy.
Conclusion: George is compliant with :ny_neighbor_state_residency_policy.
(George lives in Boston, Boston is in MA (not NY), NY is a neighbor state of MA.)
3.1.2.2: Non-nested rules
@forAll :PERSON, :CITY, :NY_STATE_ID.
:ny_state_residency_or_id_policy a air:Policy;
air:rule :state-residency-rule;
air:rule :state-id-check.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_or_id_policy.}]].
:state-id-check a air:Belief-rule;
rdfs:label "state id check rule";
air:if { :PERSON tamip:Has_ny_state_id :NY_STATE_ID. };
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_or_id_policy.}]].
The :ny_state_residency_or_id_policy policy contains two rules: :state-residency-rule and :state-id-check, that are not nested and sort of independent of each other.
In this case, a person complies with the policy if he has a NY state id or if he stays in a city and that city is in NY. :state-id-check rule checks for ny state id, and :state-residency-rule independently checks if a person lives in a city in NY state.
Conclusions: Alice, Bob and David comply with the :ny_state_residency_or_id_policy.
(Bob live in Troy, which is in NY. David has NY state ID 307 578 002. Alice lives in Troy, in NY and has a NY state ID, 307 578 001, as well.)
3.1.3: Alternative Assertion (air:alt)
In Negatively Nested Rules air:alt had been used to activate a nested rule when the pattern in the nesting rule did not match. However, air:alt can also be used to make simply an alternate assertion.
@forAll :PERSON, :CITY.
:ny_state_residency_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
};
air:then [air:rule [
air:if {
:CITY tamip:Has_state :NY.
};
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.}]];
air:else [air:assert [air:statement {:PERSON air:non-compliant-with :ny_state_residency_policy.}]] ]
].
According the the :state-residency-rule: for all persons, person lives in a city and city in state of NY, the person is compliant with :ny_state_residency_policy. And for all persons, person lives in a city and 'city in state of NY' does not hold, the person is not compliant with :ny_state_residency_policy.
Conclusions: Alice and Bob comply with the :ny_state_residency_policy. George is not compliant with the :ny_state_residency_policy.
(Alice and Bob live in Troy which is in NY state. George lives in Boston, in MA, which is not in NY.)
3.1.4: Variable Quantification and Scoping
- Variables are declared in N3logic syntax and scoped to file in which they appear in.
- Variables can be
- declared globally (outside policies and rules) or
- declared in one of the two sides of a rule (pattern or assertion).
- Only globally declared variable can be used on both sides of any rule in that file and can be referred to in nested rules triggered from those rules in that file.
- If one of the rules in the file ultimately triggers a nested rule in a different file, then a previously matched global variable can be used in the latter rule as long as it is referred to with its entire URI (base URI of original file + name of variable).
- A (universal or existential) variable that is declared in the left hand side (pattern) or the right hand side (assertion) of a rule is only accessible in that side.
- Global declaration of existential variables is not supported in this version. Existentials can only be used in patterns.
- Variables declared in the right hand side (assertion) are simply anonymous nodes with the correct quantification, but that functionality is not supported in this version.
3.1.4.1: Global Declaration
All variables in the examples covered so far were declared globally.
3.1.4.2: Existential Quantification in the pattern
@forAll :PERSON.
:ny_state_residency_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
@forSome :CITY.
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.}]].
This policy is same as the Tutorial Policy 1 in 3.1, except that :CITY is locally declared within the pattern. Note that :CITY is existentially quantified and is not used in the right hand side (assertion). According to the state-residency-rule, for all persons, person lives in some city that is in NY state, the person is compliant with the :ny-state-residency-policy.
Conclusions: Bob and Alice comply with :ny_state_residency_policy.
Instead, if :CITY was universally qualified, the :state-residency-rule would become: for all persons, if person lives in :CITY and for all values that :CITY can take :CITY is in state NY, the person is compliant with :ny_state_residency_policy. Since all URIs in the data are possible values for :CITY, empty set is returned as conclusion. (Tutorial Policy 7, Execute)
Note that the existentially quantified variable :CITY can be replaced with a blank node.
@forAll :PERSON.
:ny_state_residency_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city [tamip:Has_state :NY].
};
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.}]].
Execute
3.1.4.3: Universal Quantification in the pattern
TBD
3.1.5: Multiple Policies
3.1.5.1: Multiple Policies in 1 Document
@forAll :PERSON, :CITY, :NY_STATE_ID. :ny_state_residency_policy a air:Policy; air:rule :state-residency-rule. :state-residency-rule a air:Belief-rule; rdfs:label "state residency rule"; air:if { :PERSON tamip:Lives_in_city :CITY. :CITY tamip:Has_state :NY. }; air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.}]]. :ny_state_id_policy a air:Policy; air:rule :state-id-check. :state-id-check a air:Belief-rule; rdfs:label "state id check rule"; air:if { :PERSON tamip:Has_ny_state_id :NY_STATE_ID. }; air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_id_policy.}]].
Here we see that we can define two different policies :ny_state_residency_policy and :ny_state_id_policy in the same document. Rules listed in a document are considered together, therefore an assertion made in :state-id-check can potentially impact the execution of :state-residency-rule and vice-versa. Therefore, carefully check for any side effects from rules contained in other policies, in the same document.
Conclusions: Alice and Bob comply with :ny_state_residency_policy. Alice and David comply with :ny_state_id_policy.
(Alice and Bob stay in Troy, which is in NY state. Alice and David have NY state ids "307 578 001" and "307 578 002")
3.1.5.2: Policies in more than 1 file
@forAll :PERSON, :CITY.
:ny_state_residency_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.}]].
Tutorial Policy 10:
@forAll :PERSON, :NY_STATE_ID.
:ny_state_id_policy a air:Policy;
air:rule :state-id-check.
:state-id-check a air:Belief-rule;
rdfs:label "state id check rule";
air:if { :PERSON tamip:Has_ny_state_id :NY_STATE_ID. };
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_id_policy.}]].
The two policies in Tutorial Policy 19_v2 in 3.1.5.1 are split over 2 files.
Conclusions: Alice and Bob comply with :ny_state_residency_policy. Alice and David comply with :ny_state_id_policy.
3.1.5.3: Variable Scoping over multiple policy files
@forAll :PERSON, :CITY.
:ny_state_residency_and_id_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:rule :state-id-check].
Tutorial Policy 18:
@forAll :PERSON, :NY_STATE_ID.
:state-id-check a air:Belief-rule;
rdfs:label "state id check rule";
air:if { :PERSON tamip:Has_ny_state_id :NY_STATE_ID. };
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_and_id_policy.}]].
The Tutorial Policy 3 in 3.1.2.1.1 is split over 2 files. The second file contains only a rule- state-id-check rule, which is a nested in rule state-residency-rule. Here we see that variable bindings are retained when rules are cross-referenced across files.
Conclusions: Alice is compliant with ':ny_state_residency_and_id_policy'.
3.1.6: Some avoidable errors
3.1.6.1: Unsafe rules
Variable bindings take place at the time of pattern matching. Unsafe rule refers to the condition when a statement is asserted by the rule when not all of its variables are bound. It may arise for at-least one of these two reasons.
1. PERSON1 variable doesn't occur in the pattern of the rule or that of it's parent or any ancestor rules.
@forAll :PERSON, :CITY, :PERSON1.
:ny_state_residency_and_id_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:assert [air:statement {:PERSON1 air:compliant-with :ny_state_residency_and_id_policy.}]].
2. Even though the variable occurs in the pattern, the assertion is made when the pattern doesn't match, i.e. when no variable binding is found.
@forAll :PERSON, :CITY.
:ny_state_residency_and_id_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:else [air:assert [air:statement {:PERSON air:non-compliant-with :ny_state_residency_and_id_policy.}]].
3.1.6.2: Contradictory conclusions
Though this can rarely be detected before policy reasoning is performed, but while performing reasoning it can be inferred explicitly using following policy:
@forAll :RES, :POL.
:contains_contradiction_policy a air:Policy;
air:rule [
rdfs:label "rule to detect contradiction";
air:if {
:RES air:compliant-with :POL.
:RES air:non-compliant-with :POL.
};
air:then [air:assert air:statement [{:RES air:compliant-with :contains_contradiction_policy.}]]
].
Justification
Every action is associated with justification(s) at the run time. By default the conjunction of matched graphs (antecedent) and the rule-id are given as justification for the actions. These justifications (i.e. antecedent & rule-id) can be explicitly modified or suppressed.
A natural language description of the rule can also be provided.
3.2.1: Natural language explanation of the rule (air:description)
@forAll :PERSON, :CITY.
:ny_state_residency_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then
[ air:description(:PERSON "lives in the NY state city -" :CITY);
air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.}]].
The policy is same as that in Tutorial Policy 1_v2 in 3.1.1. Here, we also provide a natural language description for the :state-residency-rule, using air:description. Description is given as a sequence of variables and strings.
, <:Alice> "lives in the NY state city -" <:Troy>.
3.2.2: Hiding Justification (air:Hidden-rule)
@forAll :PERSON, :CITY, :NY_STATE_ID.
:ny_state_residency_and_id_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:rule :state-id-check].
:state-id-check a air:Hidden-rule;
rdfs:label "state id check rule";
air:if { :PERSON tamip:Has_ny_state_id :NY_STATE_ID. };
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_and_id_policy.}]].
The policy is same as Tutorial Policy 3_v2 in 3.1.2.1.1. But we don't want the state id to show up in the justification. To hide it we declare :state-id-check to be a air:Hidden-rule.
:justification [
:antecedent-expr [
a :And-justification;
:sub-expr [
air:instanceOf <:state-id-check>;
:justification [
:antecedent-expr [
a :And-justification;
:sub-expr <:state-residency-rule>,
{<:Alice> <:Lives_in_city> <:Troy> . <:Troy> <:Has_state> <:NY> .} ];
:rule-name <:state-residency-rule> ] ],
{<:Alice> <:Has_ny_state_id> <:307_578_001> .
} ];
:rule-name <:state-id-check> ] .
Justification for Tutorial Policy 12:
TBD
:justification [
:antecedent-expr [
a :And-justification;
:sub-expr <:state-residency-rule>,
{<:Alice> <:Lives_in_city> <:Troy>. <:Troy> <:Has_state> <:NY>.} ];
:rule-name <:state-residency-rule> ].
3.2.3: Explicit Justification (air:assertion, air:statement, air:Justification, air:antecedent, air:rule-id)
@forAll :PERSON, :CITY, :NY_STATE_ID, :G1 .
:ny_state_residency_and_id_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:matched-graph :G1;
air:then [air:rule :state-id-check].
:state-id-check a air:Belief-rule;
rdfs:label "state id check rule";
air:if { :PERSON tamip:Has_ny_state_id :NY_STATE_ID. };
air:then
[ air:description ( :PERSON "is a new york state resident" );
air:assert
[ air:statement { :PERSON air:compliant-with :ny_state_residency_and_id_policy.};
air:justification
[ air:rule-id :state-residency-id-rule;
air:antecedent :G1 ]]].
This policy is the same as Tutorial Policy 3_v2 in 3.1.2.1.1 and Tutorial Policy 12_v2 in 3.2.2. Again, we do not want the state id to show up in the justification. But instead of suppressing the justification we explicitly define the justification for the :state-id-check rule. The default rule-id :state-id-check is replaced by a new rule-id :state-residency-id-rule. The default antecedent is replaced by the matched-graph of :state-residency-rule, which is referenced through the variable :G1. Note that :G1 is bound whenever the :state-id-check rule is active. air:statement serves similar purpose as air:assert, i.e. the triple :PERSON air:compliant-with :ny_state_residency_and_id_policy, where :PERSON1 is replaced by its binding value, is asserted.
Justification for Tutorial Policy 13:
:justification [
:antecedent-expr [
a :And-justification;
:sub-expr <:state-residency-rule>,
{<:Alice> <:Lives_in_city> <:Troy>. <:Troy> <:Has_state> <:NY>.} ];
:rule-name <:state-residency-rule> ].
3.2.4: Explanations for failed policy compliance (air:alt, air:non-compliant-with)
In section 3.1.3 we had seen how unmatched cases can be explicitly handled using air:alt, like in Tutorial Policy 16_v2. This explicit handling also provides explanations for failed (non-compliant) policy decisions.
Section 4: Policy Engine Features
4.1: OWL Inferencing Support
The policy engine supports reasoning for following owl (& rdfs) constructs:
- rdfs:subClassOf
- rdfs:subPropertyOf
- rdfs:domain
- rdfs:range
- owl:sameAs
- owl:TransitiveProperty
- owl:SymmetricProperty
The inference rules are encoded in AIR (base-rules).
@forAll :PERSON, :CITY, :STATE.
:ny_neighbor_state_residency_policy a air:Policy;
air:rule :non-ny-residency-rule.
:non-ny-residency-rule a air:Belief-rule;
rdfs:label "Non NY residency rule";
air:if {:PERSON tamip:Lives_in_city :CITY.};
air:then
[ air:rule
[ air:if {:CITY tamip:Has_state :NY.};
air:else [air:rule :neighbor-state-rule]]].
:neighbor-state-rule a air:Belief-rule;
rdfs:label "neighbor state rule";
air:if { :CITY tamip:Has_state :STATE.
:STATE tamip:Neighbor_state :NY.};
air:then [air:assert [air:statement { :PERSON air:compliant-with :ny_neighbor_state_residency_policy. }]].
The policy is same as Tutorial Policy 4_v2 in 3.1.2.1.2. However, the pattern of :neighbor-state-rule is changed- the triple :NY tamip:Neighbor_state :STATE is reversed. The data includes the triple :NY tamip:Neighbor_state :MA, only. But it also includes the triple tamip:Neighbor_state rdf:type owl:SymmetricProperty.
Conclusions: George is compliant with :ny_neighbor_state_residency_policy.
(George lives in Boston. Boston is in MA, not in NY. NY is neighbor state of MA, but since neighbor state is a symmetric property, MA is neighbor state of NY also holds.)
4.2: Multiple Logs
Consider a new data file AIR Demo Data1_v2 (RDF)- contains single triple :Bill tamip:lives_in_city :Troy.
The 2 data files, AIR Demo Data and AIR Demo Data1_v2, are checked against Tutorial Policy 1_v2.
Conclusions: Alice, Bob and Bill comply with :ny_state_residency policy.
(Alice & Bob live in Troy, which is in NY. Bill also lives in Troy. Troy is in NY is stated in other log.)
4.3: Parameters can be passed to the engine
For example, a list of concluded predicates to be displayed in the reasoner's output can be passed to the engine. This is discussed in detail in 4.4.1.
4.4: Reasoner's output
Policy engine employs a forward chaining reasoner. On finding the deductive closure (of conclusions) the reasoner filters some conclusions to be displayed in the results, along with their justification. Other characteristics of the reasoners output:
- The result shows only compliance or non-compliance conclusions and contains justifications for each of these conclusions.
- In the current version, only 1 justification for each of the (non)compliance assertions are included.
- The results recursively include justifications for triples in the antecedent of the justification of conclusions that have been included so far, unless the triples are part of the assumptions (i.e. the triples are part of the data at the beginning)
@forAll :PERSON, :CITY.
:ny_state_residency_policy a air:Policy;
air:rule :state-residency-rule.
:state-residency-rule a air:Belief-rule;
rdfs:label "state residency rule";
air:if {
:PERSON tamip:Lives_in_city :CITY.
:CITY tamip:Has_state :NY.
};
air:then [air:assert [air:statement {:PERSON air:compliant-with :ny_state_residency_policy.
:PERSON tamip:Lives_in_state :NY.}]].
It is similar to the Tutorial Policy 1. We make an additional assertion that the person lives in state NY. We know that whenever a person is concluded to be compliant-with the :ny_state_residency_policy, it is also asserted that s/he lives in NY state.
Conclusions: Bob and Alice are compliant with :ny_state_residency policy. However, the result does not include the triples- <:Bob> tamip:Lives_in_state <:NY> and <:Alice> tamip:Lives_in_state <:NY>- that we know have been asserted as well.
4.4.1: Display all conclusions for a predicate
By default the policy engine chooses to filter all the conclusions with the predicates air:compliant-with and air:non-compliant-with. We can pass a list of URIs of predicates to the argument named filterProperties, directing the policy engine to filter all the conclusions with these predicates (in addition to air:compliant-with and air:non-compliant-with predicates).
We will run data by Tutorial Policy 15, and pass tamip:Lives_in_state as argument to filterProperties.
Powered By 
- Semantically Enabled by Tetherless World