AIR Policy Test Cases

From TAMI

Jump to: navigation, search

Contents

Template

Data Set

Demo 1-1


Demo1: Policies with Simple Rules

Data Set

Demo 1--1 (Policy with a simple assertion that contains blank node)

  • Policy file: Demo1_Policy9 (N3 source)
  • Description: Rule with no pattern
  • [-] RESULTS from Justification UI
  • Description: Triple is always asserted

Demo 1-0 (Policy with a simple rule)

  • Policy file: Demo1_Policy8 (N3 source)
  • Description: Rule with no pattern
  • [+] RESULTS from Justification UI
  • Description: Triple is always asserted

Demo 1-1 (Policy with a simple rule)

  • Policy file: Demo1_Policy1 (N3 source)
  • Description: Any person who is known to hold the 'has_father' relation with another person complies with the policy. In addition we assert that the 2 persons are related by 'has_parent' relation.
  • [+] RESULTS from Justification UI
  • Description: Since Alice is known to have father Bob, Alice satisfies the policy

Demo 1-2 (A pattern with variable at the predicate position)

  • Policy file: Demo1_Policy6 (N3 source)
  • Description: Relations by which Alice and Bob are related are compliant with the policy
  • [+] RESULTS from Justification UI
  • Description: Since Alice and Bob are related by Has_Father relationship, Has_Father satisfies the policy

Demo 1-3 (It is important to assert at-least 1 compliance or non-compliance relation between a resource and some Policy.)

  • Policy file: Demo1_Policy2 (N3 source)
  • Description: Policy with one rule, that only asserts has_Parent relationship
  • [-] RESULTS from Justification UI
  • Description: AIR Policy engine tries to compute compliance (or non-compliance) relationships. Since in the given policy no such</br>

assertions are made, the reasoner returns an empty set of assertions.

Demo 1-4 (Two policies in 1 file)

  • Policy file: Demo1_Policy3 (N3 source)
  • Description: # Any person who is known to hold the 'has_father' relation with another person complies with the first policy. In addition we assert that the 2 persons are related by 'has_parent' relation. # Any person who is known to hold the 'has_parent' relation with another person complies with the second policy. In addition we assert the 'has_ancestor' relation.
  • [+] RESULTS from Justification UI
  • Description: Since Alice has father Bob, he complies with 1st policy and it is added that Alice has parent Bob. Now when Alice is known to have Parent Therefore Alice also complies with the 2nd policy.

Demo 1-5 (Two policies in 1 file, and order is enforced through the use of air:compliant with in the pattern)

  • Policy file: Demo1_Policy4 (N3 source)
  • Description: Policies as similar to that in 1-4. # Any person who is known to hold the 'has_father' relation with another person complies with the first policy. # Any person who is compliant with 1st policy, is also compliant with second policy. In addition we assert that the 'has_ancestor relationship holds.
  • [+] RESULTS from Justification UI
  • Description: Since Alice has father Bob, he complies with 1st policy. Now when Alice is compliant with the 1st policy, she is also compliant with 2nd policy and it is added that Alice has Ancestor Bob.

Demo 1-6 (Two rules in 1 policy. At least one rule must trigger for compliance with the policy)

  • Policy file: Demo1_Policy5 (N3 source)
  • Description: # According to the first rule any person who is known to hold the 'has_mother' relation with another person complies with the policy. # Similarly according to the second rule any person who is known to hold the 'has_father' relation with another person complies with the policy. In addition we assert, in either case, that the 2 persons are related by 'has_parent' relation.
  • [+] RESULTS from Justification UI
  • Description: Since Alice is only known to have has father relationship, Alice is compliant with the policy and he also has a parent in Bob.

Demo 1-7 (A rule outside the policy - i.e. not related with any policy)

  • Policy file: Demo1_Policy7 (N3 source)
  • Description:
  • [-] RESULTS from Justification UI
  • Description: Since the second rule is not contained in any policy it is never activated.

Demo10: Multiple policy files

Demo (AIR 10-1): 2 policy files containing independent policies

Demo (AIR 10-2): 2 policy files. Policy in the 1st policy file references rule in other policy file.

Demo (AIR 10-3): 2 policy files. Policy in the 1st policy file references rule in other policy file.

Demo (AIR 10-4): 2 policy files. Two policy files.

Demo (AIR 10-5): 2 policy files. Two policy files. PERSON is not declared to be a variable in second file.

Demo9: Variables

Demo (AIR 9-1): :PERSON2 variable is universally quantified

Demo (AIR 9-2): :PERSON2 variable is existentially quantified in the pattern

Demo (AIR 9-3): :PERSON2 variable is universally quantified in the pattern that is asserted

Demo (AIR 9-4): :PERSON2 variable is existentially quantified in the pattern that is asserted

Demo8: Nesting of rules

Demo (AIR 8-1): simple nesting of rules

Demo (AIR 8-2): Nesting of rules, while the level 1 rule triggers a new rule, it also asserts a triple.

Demo (AIR 8-3): Nesting of rules, while the level 1 rule triggers a new rule and asserts a fact not in database. The new fact queries for the new fact added

Demo (AIR 8-4): same rule is once nested, and once not- this is to verify if the rule is triggered independently.

Demo (AIR 8-5): Nesting of rules, while the level 1 rule triggers a new rule and asserts a fact not in database. The new fact queries for the new fact added

Demo (AIR 8-6): One rule is not contained in any policy, and it is not applied.

Demo (AIR 8-7): Same rule is contained in more than 1 policy.

Demo (AIR 8-8): A rule contains only alt, and trying to see how fwd chaining and NAF go hand in hand.

Demo2: Transitive Inference

Demo (AIR 2-1): Has_Ancestor is not declared to be Transitive. We define a rule within the policy to model transitivity.

Demo (AIR 2-2): Has_Descendant is declared to be Transitive Property using owl:TransitiveProperty, and new assertions (& compliances) are inferred by the policy engine reasoner

Demo (AIR 2-3): Same as AIR 2-1 example. However, 2 of the 3 rules are clubbed under 1 policy

Demo3: If-then-else

Demo (AIR 3-1): "if-then-else" using air:alt. in this example we check if aunt rule is compliant. If it is not compliant we check if uncle rule is compliant

Demo (AIR 3-2): The policy is same as in previous example, with the difference that an identifier for the alternative rule is used.

Demo (AIR 3-3): The policy is same as in previous example, with the difference that an identifier for the alternative rule is used.

Demo (AIR 3-4): Rule with multiple alt properties

Demo (AIR 3-5): Writing a rule such that when something is not found you can go on to add it, so that there is a match next time.

Demo (AIR 3-6): Writing a rule such that when something is not found you can go on to add it, so that there is a match next time.

Demo (AIR 3-7): An alternative description.

Demo (AIR 3-8): If then else, such that the variable appearing in else pattern is reused

Demo (AIR 3-9): If then else, such that the variable appearing in else pattern is reused

Demo (AIR 3-10): to test air:alt implementation

Demo6: Hidden Rule

Demo (AIR 6-1): (AIR 6-1) An anonymous node is declared to be a hidden rule.

Demo (AIR 6-2): (AIR 6-2) A named rule is declared to be a hidden rule.

Demo 7: Explicit Justification

Demo2_Data

Demo (AIR 7-1): Use of assertion [:statement {...}] instead of assert{...}.

Demo (AIR 7-2): Rule-id to be used in justification is explicitly declared

Demo (AIR 7-3): Rule-id and set of antecedents for justification are defined explicitly

Demo (AIR 7-4): Same as AIR 7-3 with a slight modification. We use both assert and assertion in the rule.

Demo (AIR 7-5): justification as a property of Abstract-assertion. We see 2 things. One that there is no nested justification anymore- only the explicitly declared matched-graph and rule id appear as justifications. second rule description of the rule where the assertion is done also shows up.

Demo (AIR 7-6): inner-most nested rule has a justification property. it doesn't affect any justification generation. however engine reports no error.

Demo (AIR 7-7): non inner-most nested rule has a justification property. again it doesn't affect any justification generation. again, engine reports no error.

Demo (AIR 7-8): multiple antecedents for the same assertion. The effect is that antecedent expression is union of the multiple matched-graphs.

Demo (AIR 7-9): multiple rule-ids in justification. doesn't work.

Demo (AIR 7-10): abstract assertions with multiple statements.

Demo (AIR 7-11): justification without antecedent. In the justification produced the antecedent expression is empty.

Demo (AIR 7-12): justification without rule-id. Rule engine gives an error.

Demo (AIR 7-13): empty justification. Rule engine gives an error.

Demo (AIR 7-14): abstract assertion w/t justification. this doesn't work

Demo (AIR 7-15): explicit justification for alternative assertion

Demo (AIR 7-16): explicit justification, s.t. antecedent is defined as a new graph, not a new graph.

Demo (AIR 7-17): long nesting of rules with descriptions for each.

Demo (AIR 7-18)  : Sample Policy for seeing justification produced by the current implementation

Demo4: Multi-log

Demo(4-1): reasoning on two logs


Demo11: multiple assert and assertion

Demo(11-1): multiple assert statements


Demo(11-2): simultaneous assert and assertion statements


Demo(11-3): simultaneous assert and assertion statements


Demo12: Rules in the file trigger a nested rule in a different file

Demo (AIR 12-1): 2 policy files. PERSON is not declared to be a variable in second file.

Demo (AIR 12-2): checking how demo policy 11 performs individually

Demo (AIR 12-3): checking how demo policy 11 performs individually

Demo13: Testing operational semantics of AIR (especially air:else)

Demo (AIR 13-1)  :

  • Tests - does the level of negative nesting matter - Yes
    • Test 1 - if P then R else [if true then P], will R be inferred? - Yes;
    • Test 2 - if P else [ if P then R else S ] else [ if true then P], is R or S inferred? - only R
  • Data : AIR Demo Data
  • Policy : Demo13_Policy1
  • Results

Demo (AIR 13-2) :

Demo (AIR 13-3) :

  • Tests
    • Test 1 - if P else Q. if Q else R, is R inferred? - Yes;
    • Test 2 - if P else Q. if P else [ if Q then S else R ], is R or S inferred - S only!
  • Data : AIR Demo Data
  • Policy : Demo13_Policy3
  • Results

Demo (AIR 13-4) : Does order of rules matter.

Demo (AIR 13-5) : Does order of rules matter?

Demo (AIR 13-6) : Testing if order of 'air:else' actions make a difference.

Demo (AIR 13-7) : Testing if order of 'air:else' actions make a difference.

Demo (AIR 13-8) : Testing if order of 'air:else' actions make a difference.

  • Test- assert triples in one of the 'else' actions that satisfy the if condition. The ordering should influence whether rest of the 'else' actions are effected.
  • Data : AIR Demo Data
  • Policy : Demo13_Policy8
  • Results

Demo14: Testing the TMS maintenance

Demo (AIR 14-1) : Test 1 - if P else Q. if Q then R. Does the justification for Q show up? - Yes; Test 2 - if P then Q. if Q then R. Does the justification for Q show up? - Yes

Demo (AIR 14-2) : if P then Q , with the description. Does description show up - Yes

Retrieved from "http://tw.rpi.edu/proj/tami/AIR_Policy_Test_Cases"
Personal tools