1. Using Semantic Web Data: Proof
Lalana Kagal
Decentralized Information Group
MIT CSAIL
Eric Prud'hommeaux
Engineer
World Wide Web Consortium

2. Importance of Proofs
Proofs for policy decisions allow users to understand how the results were obtained
Increase trust in the policy reasoning and enforcement process
Used by policy administrators to confirm the correctness of the policy and to check that the result is as expected
In the case of failed queries, they can be used to figure out what additional information is required for success

3. Problem with Proofs
Proofs or explanations generated by reasoning engines are usually in the form of proof-trees
Proofs or explanations generated by reasoning engines are usually in the form of proof-trees
Image courtesy

4. Explanations Proof trees not easy to understand by end users
Too much information in proof trees
Need to extract relevant information from proof trees and present to end users in easy to understand manner
Require explanations

5. AIR Policy Language
rule-based policy language for usage and access control
integrated explanations for policy decisions through dependency tracking
more efficient and expressive reasoning through the use of goal direction
mainly forward chaining
backward chaining is used to limit search space
grounded in Semantic Web technologies for greater interoperability, reusability, and extensibility

6. AIR Tools
AIR Reasoner accepts data + policy and produces reasoning result of running policy over data
Justification UI accepts reasoning result, extracts explanation, and displays it

7. Installing AIR Tools Explanation/Justification User Interface
Download Firefox extension from
Install into Firefox browser
Restart Firefox

8. Executing AIR Tools Install Tabulator extension with justification UI
Remote
Call reasoner on web server with remote log and policy
Invoke reasoner and view justification

9. Testing AIR Justification UI
Start Firefox
Open

10. If installed correctly
Tabulator loads the representation of the policy as

11. Testing AIR Justification UI
Open bin/server_cgi.py?logFile= .n3&rulesFile=
This calls the AIR reasoner on mr-burns.w3.org and returns the reasoning result

12. Testing AIR Justification UI

13. Testing AIR Justification UI
To see the result in the AIR Justification UI
Press in the Tabulator to turn the RDF view OFF
Press in the Tabulator to turn the Justification view ON

14. Testing AIR Justification UI

15. AIR specifications Each AIR policy consists of one or more rules
policy = { rule }
A rule is made up of a pattern that when matched caused the associated action to be fired
rule = { pattern, action }
An action can either be an assertion, which is a fact that is added to the knowledge base or a nested rule
action = { assertion | rule }
:MyFirstPolicy a air:Policy;
air:rule [
air:pattern { ... };
air:assertion { ... };
air:rule [ ... ]

16. AIR specifications An AIR policy or rule also contains . air:variable
used to declare variables that can be used inside patterns
the scope of variable is the container in which it is declared. If the variable is bound before a rule is invoked, it is passed as a constant
air:description: list of variables and strings that are put together to provide the NL description
:MySecondPolicy a air:Policy;
air:variable :VAR1;
air:rule [
air:variable :VAR2;
air:pattern { ... };
air:assertion { ... };
air:description (:VAR1, “ is a variable that is declared in :MySecondPolicy and ”, :VAR2, “ is a variable that is declared in this rule”);
air:rule [ ... ] .

17. Scenario: Decentralized Access Control
The DIG group has several online resources including pictures, papers, presentations, and proposals that are only accessible to members of the group and to people that members trust. The group has a webpage that lists its members using N3. The page identifies members by their Friend Of A Friend (FOAF) pages. Authentication in this scenario is via OpenID. DIG members provide their OpenID URI (usually the same as their work homepages) in their FOAF pages.
Open for this data about the DIG group
Policy: Only group members are allowed to access group resources or people who are trusted by group members
For simplicity, the data that we check our demo policies against also include a test request for a DIG resource

18. Scenario: Decentralized Access Control
For simplicity, the data that we check our demo policies against also include a test request for a DIG resource
:Req1 a air:Request;
foaf:openid <
air:resource <

19. Developing First Policy
POLICY: If a request is for a DIG resource, it is compatible with the DIG Policy
:DIGPolicy a air:Policy;
air:variable :REQ, :RESOURCE.
rdfs:label "DIG Policy";
air:rule :DAP_1.
:DAP_1 a air:BeliefRule;
rdfs:label "DIG Rule #1";
air:pattern {
:REQ a air:Request;
air:resource :RESOURCE.
:DIG data:owns :RESOURCE. };
air:description (:REQ " is a request made by a requester with openid, " :REQUESTER ", for DIG resource " :RESOURCE);
air:assert { :REQ air:compliant-with :DIGPolicy }.

20. Visualising First Policy
Open policy at

21. Executing First Policy
To execute AIR policy:
<air-reasoner>=
Executing First policy bin/server_cgi.py?logFile= eplk/code/data.n3&rulesFile= eplk/code/first.n3

22. Executing First Policy

23. Executing First Policy
Press to browse through the explanation
The yellow bar provides the NL description of the rule
The blue bar provides the actual premises that were used to come up with the conclusion
Premises are rule patterns with variables substituted

24. Developing Second Policy
Modify first policy to check other attributes of the Request
Check if the openid URI of the requester has been provided

25. Executing Second Policy
Execute this policy and see if it works
bin/server_cgi.py?logFile= eplk/code/data.n3&rulesFile= eplk/code/second.n3

26. Developing Third Policy
Open the data file and see if there are any other attributes passed along with the Request and check those in the policy as well
Open

27. Developing Third Policy
There are no other attributes in Request, so there is no need of a third policy

28. Developing Fourth Policy
Add another rule to the policy; check if the requester is a member of the DIG group
:DAP_2 a air:BeliefRule;
rdfs:label "DIG Rule #2";
air:pattern {
:DIG foaf:member :MEMBERLIST.
:MEMBER air:in :MEMBERLIST.
:MEMBER a foaf:Person;
foaf:openid :REQUESTER. };
air:description ("The requester with openid, " :REQUESTER ", is a DIG member");
air:assert { :REQ air:compliant-with :DIGPolicy }.

29. Visualising Fourth Policy
Open fourth policy eplk/code/fourth.n3

30. Executing Fourth Policy
Open bin/server_cgi.py?logFile= eplk/code/data.n3&rulesFile= eplk/code/fourth.n3
Explore the explanation using WHY and START OVER buttons

31. More AIR Specifications
So far, we've used
air:Policy, air:variable, air:BeliefRule, air:pattern, air:description, air:assert
More air tags
air:alt An alternative is a rule that becomes active if the pattern of the containing rule fails. This alt property is used to assert closure over some set of facts. Consider the following example. If the pattern of :RuleB matches, then the assertion fires, otherwise the alternative, :RuleC becomes active.
:RuleB a air:Belief-rule;
air:variable :MEMBER;
air:pattern {
:MEMBER air:in :MEMBERLIST. };
air:assert { :MEMBER foaf:member :DIG };
air:alt [ air:rule :RuleC ].
:RuleC a air:Belief-rule;
...

32. Using alt tag Add a new rule to the policy to create fifth.n3
The rule is fired if the requester is not a DIG group member
The rule checks if the requester is known to any of the DIG members
This rule should be an alternative to rule, DAP_2
fifth.n3:

33. Executing the fifth policy
In order to test this we need a new request from someone who is known to a DIG member
Yosi, with openid < is not a DIG member but is known by one
:Req2 a air:Request;
foaf:openid <
air:resource <
Open
Why does this Request satisfy the new policy ?

34. Executing the fifth policy
Open bin/server_cgi.py?logFile= eplk/code/data2.n3&rulesFile= eplk/code/fifth.n3
Explore the explanation using WHY and START OVER buttons

35. Executing the fifth policy

36. How are explanations generated ?
specific set of premises from which any conclusion/policy decision was derived is an effective explanation for the conclusion
these premises are called the set of dependencies and dependency tracking is the process of maintaining dependency sets for derived conclusions

37. Dependency Tracking
We use Truth Maintenance System (TMS) for tracking dependencies of conclusions
keeps track of the logical structure of a derivation
has ability to assume and retract hypothetical premises
Explanations are automatically generated by extracting and presenting relevant information from dependencies

38. Overriding Automatic Justification
Using dependency tracking, we are able to generate explanations for every conclusion reached by the reasoner
However, sometimes we need to override these explanations
When the explanation is too lengthy, we might want to reduce the number of steps
When the explanation exposes too much information about the policy, we might want to protect our policy

39. AIR tags for explanation
We use the following tags to modify the dependency structure and provide customized explanations
air:assertion property of rules
This property is composed of two components, air:statement, which is the set of triples being asserted, and air:justification, which is the explicit justification that needs to be associated with the statement.
The Justification class consists of two properties air:rule-id and air: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.

40. Sixth policy
Modify fourth policy to provide a different explanation for DAP_2
:SomeOtherRule a air:BeliefRule;
air:variable :REQ, :G1;
air:matched-graph :G1;
air:pattern { :REQ a air:Request; };
air:rule :DAP-1.
:DAP-2 a air:BeliefRule;
rdfs:label "DIG Rule #2";
air:pattern { };
air:description ("The request is valid");
air:assertion [
air:statement { :REQ air:compliant-with :DIGPolicy };
air:justification [
air:rule-id :SomeOtherRule;
air:antecedent :G1 ] ].

41. Sixth policy

42. Execute sixth policy
Open bin/server_cgi.py?logFile= eplk/code/data.n3&rulesFile= eplk/code/sixth.n3
Explore the explanation using WHY and START OVER buttons

43. Execute sixth policy

44. Lawyer View
We also have a different view of our justification UI, a lawyer view
This presents the explanation in a non graphical format, in a style more suited for lawyers
To activate this, execute any policy, and press th e button

45. Lawyer View of Fourth Policy
Open bin/server_cgi.py?logFile= eplk/code/data.n3&rulesFile= eplk/code/fourth.n3 To activate lawyer view, and press the button

46. Lawyer View of Fourth Policy

47. How AIR fits into our accountability framework
Accountability allows violators of applicable privacy policies to be identified and held accountable
Privacy usage restrictions and resource access control policies are specified in AIR
user's actions within the framework are captured and annotated transaction logs are maintained
Policy compliance over transaction logs can be checked using the AIR reasoner

48. AIR Contributions automated explanations for policy decisions
customizable explanations, if required
more efficient and expressive reasoning
extraction of relevant explanation for policy decision
presenting explanations in Justification UI

49. More Information
Air specifications:
Paper on AIR, Integrated Policy Explanations via Dependency Tracking, overview.pdf
TAMI/E2ESA:
How to use the Justification UI :