From TAMI

1 Introduction
2 Data
3 Section 3: AIR Language Features
- 3.1 Policy Modeling
- 3.2 Justification
4 Section 4: Policy Engine Features
5 AIR: an all purpose semantic web Rule Language
6 AIR: a complete policy language?
- 6.1 Some features that AIR doesn't support
  - 6.1.1 Policy encoding
  - 6.1.2 Policy priority

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, 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 viewed using the Tabulator, a firefox extension.

More examples and demos can be found here

For tutorial on AIR version 2.0, see here

Data

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

Tutorial Policy 1:

@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:pattern {
       :PERSON tamip:Lives_in_city :CITY.
       :CITY tamip:Has_state :NY.         
    };    
    air:assert {: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.

Tutorial Policy 2:

@forAll :PERSON, :CITY.
:ny_state_residency_policy a air:Policy;
      rdfs:label "NY State residency policy";
      air:rule [
        rdfs:label "state residency rule";
        air:pattern {
           :PERSON tamip:Lives_in_city :CITY.
           :CITY tamip:Has_state :NY.         
        };    
        air:assert {:PERSON air:compliant-with :ny_state_residency_policy.}
      ].

AIR Policy Tutorial

From TAMI

Contents

Introduction

Data

Section 3: AIR Language Features

Policy Modeling

Policy with Single Rule

Rule with empty pattern

Policy with Multiple Rules

Nested rules

Positively Nested, nested rule becomes active when the pattern gets matched (air:rule)

Negatively Nested, nested rule becomes active when the pattern doesn't match (air:alt)

Non-nested rules

Alternative Assertion (air:alt)

Variable Quantification and Scoping

Global Declaration

Existential Quantification in the pattern

Universal Quantification in the pattern

Multiple Policies

Multiple Policies in 1 Document

Policies in more than 1 file

Variable Scoping over multiple policy files

Some avoidable errors

Unsafe rules

Contradictory conclusions

Justification

Natural language explanation of the rule (air:description)

Hiding Justification (air:Hidden-rule)

Explicit Justification (air:assertion, air:statement, air:Justification, air:antecedent, air:rule-id)

Explanations for failed policy compliance (air:alt, air:non-compliant-with)

Section 4: Policy Engine Features

OWL Inferencing Support

Multiple Logs

Parameters can be passed to the engine

Reasoner's output

Display all conclusions for a predicate

AIR: an all purpose semantic web Rule Language

AIR: a complete policy language?

Some features that AIR doesn't support

Policy encoding

Policy priority

Views

Personal tools

Navigation

scenarios & tutorials

links

Search

Toolbox