CSAIL logo MIT logo

AIR Web Rule Language

Previous Version : http://dig.csail.mit.edu/TAMI/2008/12/AIR

This Version : http://dig.csail.mit.edu/2009/AIR

The Semantic Web is a distributed model for publishing, utilizing and extending structured information usingWeb protocols. One of the main goals of this technology is to automate the retrieval and integration of data and to enable the inference of interesting results. This automation requires logics and rule languages that make inferences, choose courses of action, and answer questions. The openness of theWeb, however, leads to several issues including the handling of inconsistencies, integration of diverse information, and the determination of the trustworthiness of data. AIR is a Semantic Web-based rule language that provides this functionality while focusing on generating and tracking explanations for its inferences and actions and conforming to Linked Data principles. AIR supports Linked Rules, which can be combined and re-used in a manner similar to Linked Data. Additionally, AIR explanations themselves are Semantic Web data so they can be used for further reasoning.

AIR (AMORD In RDF) is a rule language that is represented in Turtle + quoting and supports AMORD-like constructs. The language describes several classes and properties that can be used to define policies.

Specifications

The following image illustrates the AIR classes and properties and their relationships.

AIR ontology

There are two super classes in AIR: Abstract-action and Abstract-container.

An AIR Policy is an subclass of Abstract-container. For example, an AIR ruleset, policy1, can be declared as 

@prefix air: <http://dig.csail.mit.edu/TAMI/2007/amord/air#> .
@prefix ex: <http://example.org/expolicy#> .

:policy1 a air:RuleSet.

air:Policy is a subclass of air:RuleSet so policy1 can also be defined as 

@prefix air: <http://dig.csail.mit.edu/TAMI/2007/amord/air#> .
@prefix ex: <http://example.org/expolicy#> .

:policy1 a air:Policy.

AIR uses N3Logic syntax to declare variables. It uses @forAll to declare universals and @forSome to declare existentials. Variables are scoped to file in which they appear in. Variables can be declared globally (outside rulesets and rules) or they can be declared in one of the two sides of a rule (pattern or assertion).

If a variable is declared globally then that 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 trigger 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 variable is an anonymous node named with a certain URI. If an un-nested rule refers to a variable that is not quantified in the file using the variable's URI, it will referring to an object at that URI and not a variable in a different file. A (universal or existential) variable that is declared in the hand side (pattern) or the right hand side (assertion) of a rule is only accessible in that side. 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. In order to use the same variable in both the left and right hand side of a rule, it must be declared globally. However, globally declaring existential variables is not supported in this version and existentials can only be used in patterns.

An Abstract-rule is a subclass of both Abstract-container and Abstract-action and its subclasses are Hidden-rule and Belief-rule. Most policies usually contain only Belief-rules. The deductions made by a rule declared to be a Hidden-rule will not appear in the resulting explanation. A rule is a property of all Abstract-containers and is used to attach rules to policies as shown in the example above.

A RuleSet usually consists of one or more rules specified via the air:rule property. A rule consists of a pattern, a matched-graph variable, a justification, a label, a description, and zero or more actions. The matched-graph variable, justification, description, and label are optional. Omitting the matched-graph variable means there's no direct reference for the matched graph, which often isn't needed. Omitting the justification means a default justification is used, also the usual case. The description is a list of strings, variables, and expressions that provides a natural language description of the rule. For example, the following belief rule declares a variable and has a label, and a pattern 

@forAll :U.
:rule3 a air:Belief-rule;
   rdfs:label "AIRRule 3";
   air:description ("The event " :U " uses prox card data ");
   air:pattern
      {
        :U a tami:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      }.

The action portion of a rule can either be a nested rule or an assertion. A nested rule is specified using air:rule property and an assertion via air:assert property. If a rule has as its action another rule, then when the pattern of the initial rule matches, the nested rule becomes active. In the following example, policy3 has a rule rule4. If the pattern of rule4 is matched, its action becomes active. In this case, the action is another rule so the rule becomes active. At this point of time, if the pattern of the nested rule matches, the action, which is an assertion, becomes active i.e. the statement is asserted. 

@forAll :U, :A.

:policy3 air:rule :rule4.

:rule4 a air:Belief-rule;
   rdfs:label "AIRRule 4";
   air:pattern
      {
        :U a tami:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      };
    air:rule 
       [
         rdfs:label "NestedAIRRule";   
         air:pattern 
            {
              :U :actor :A.
              :A a :Student. 
            };
         air:assert { :U a :StudentUseEvent }
        ].

There is another useful property in an Abstract-rule namely air:alt. It is used to specify alternate rules that become active or are triggered when the pattern of the parent rule does not match. In the example below, :rule5 only becomes active when the pattern associated with :rule4 does not match 

@forAll :U, :A.

:policy3 air:rule :rule4.

:rule4 a air:Belief-rule;
   rdfs:label "AIRRule 4";
   air:pattern
      {
        :U a tami:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      };
    air:alt 
       [
         rdfs:label "AlternateRule";   
         air:pattern 
            {
              :U a tami:UseEvent
            };
         air:assert { :U a mit:NotProxCardEvent }
        ].

The actions of rules can also be assertions. These assertions can either be beliefs in which case the asserted statement(s) can be matched against belief rules or goals in which case the asserted statement(s) can be matched against goal rules. Belief and Goal are subclasses of Abstract-assertion, which is a subclass of Abstract-action. An instance of an Abstract-assertion has one property namely statement. Depending on the type of subclass, a statement is either asserted as a goal or a belief. In the following example, a Belief assertion is associated with :rule5, so when the pattern matches, the statement is asserted as a belief 

@forAll :U.

:rule5 a air:Belief-rule;
   air:pattern
      {
        :U a tami:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
       }.
   air:assert { :U :patternMatches :rule5 }.

In order to modify the dependency structure and allow customized justifications, AIR provides a means to write explicit justifications. This is done by using the assertion property associated with rules. This property is composed of two components, statement, which is the set of triples being asserted, and justification, which is the explicit justification that needs to be associated with the statement. The value of the justification property has to be an instance of the Justification class. The Justification class consists of two properties rule-id and antecedent. The rule-id can be set to the name of the rule that the assertion is to be attributed to and the antecedent is a list of matched graphs that would act as the premises. It is possible to obtain the matched graphs of rules by using the matched-graph property of rules with a variable. Consider the example below. A rule, :DAP-1, has a nested rule, :DAP-2, inside it. The default justification for the assertion of :DAP-2 would be both the rules and their matched graphs. 

@forAll :REQ, :REQUESTER, :RESOURCE, :MEMBER, :MEMBERLIST.
:DAP-1 a air:BeliefRule;

   air:pattern {
      :REQ a air:Request;
      foaf:openid :REQUESTER;
      air:resource :RESOURCE.
      :DIG data:owns :RESOURCE.
   };
   air:rule :DAP-2.

:DAP-2 a air:BeliefRule;
   air:pattern {
      :DIG foaf:member :MEMBERLIST.
      :MEMBER list:in :MEMBERLIST.
      :MEMBER a foaf:Person;
      foaf:openid :REQUESTER.
   };
   air:assert{ :MEMBER permitted :RESOURCE }.

In order to change this justification structure and show that a completely different rule, :SomeOtherRule is used, the matched-graph, :G1, for the new rule is obtained. This matched-graph is used as the antecedent and the rule name, :SomeOtherRule, is used as the rule-id in the assertion of :DAP-2. This overwrites the original justification tree of assertion of ":MEMBER permitted :RESOURCE". 

:SomeOtherRule a air:BeliefRule;
   air:matched-graph :G1;
   air:pattern { A X C };
   air:assert { B A C}.

:DAP-2 a air:BeliefRule;
   air:pattern {
      :DIG foaf:member :MEMBERLIST.
      :MEMBER list:in :MEMBERLIST.
      :MEMBER a foaf:Person;
      foaf:openid :REQUESTER.
   };
   air:assertion [
      air:statement { :MEMBER permitted :RESOURCE };
      air:justification [
         air:rule-id :SomeOtherRule;
         air:antecedent :G1
      ]
   ].

The AIR ontology also includes properties for policy compliance namely compliant-with and non-compliant-with and they specify that the subject is or is not compliant with the object policy. For example, the following policy has a single rule, which when matched asserts that the event is compliant-with the policy 

@forAll :U, :P, :AP.
:policy7 a air:RuleSet;
   air:rule 
      [
        air:pattern
           {
             :U a tami:UseEvent;
               :refers-to [ a mit:ProxCardEvent ];
               :purpose P;
               tami:UseEvent :allowed-purposes :AP.
               :P is-member-of :AP                            
            };
        air:assert { :U air:compliant-with :policy7 }
      ].

AIR Reasoner

The AIR reasoner is developed in python and uses cwm libraries. It can be accessed online via a web service and or be downloaded and run locally.

The web service uses the following properties The output of the reasoner is a list of justifications (classes and properties defined in the justification ontology) for all triples that include the predicates defined in filterProperties (or air:compliant-with and air:non-compliant-with by default). To try the online version reasoner, please see AIR tutorial. The reasoner can also be downloaded [code] and run locally.

Justification User Interface

As justifications provided by the AIR reasoner are usually in the form of proof trees that may not be useful for end users, we have developed a user interface to interpret these results into a user-friendly layout. This user interface is part of Tabulator, a Semantic Web Browser. For more information, please see Justification UI.

References

maintained by Lalana Kagal
 $Revision: 32527 $
$Date: 2016-12-08 16:08:21 -0500 (Thu, 08 Dec 2016) $

*This work is sponsored by the National Science Foundation (Cybertrust award number CNS-0831442), the Intelligence Advanced Research Projects Activity (award number FA8750-07-2-0031), and the Air Force Office of Scientific Research (Young Investigator Program award number FA9550-09-1-0152).