This is one of the possible Use Cases.
1. Abstract
Examining consistency between policy & preference pairs is becoming a common task for every kind of web transactions. Rules are useful for describing and exchanging complex policies and preferences.
2. Status
Proposed by MinsuJang
3. Links to Related Use Cases
4. Relationship to OWL/RDF Compatibility
- Simple preference and policies can be described in factual format a la RDF or OWL, while more complex ones are written in rules. In such cases, rules need to reference the policy or preference IDs, which makes OWL/RDF compatibility a necessary feature.
5. Examples of Rule Platforms Supporting this Use Case
Rule systems with OWL/RDF processing capabilities can implement this use-case. Some sample systems are Euler, Bossam, KAON2, and Hoolet.
6. Benefits of Interchange
Benefit 1: Policies and preferences that contain rules can be exchanged across any web service providers, user agents etc.
7. Requirements on the RIF
Requirement 1: The policies and preferences should be written in a compatible format as well as in semantically compatible vocabularies. Sometimes, the commitment checking mechanism itself might be implemented in rules, so it should be possible to mix all the three knowledge bases and to perform inferencing.
8. Breakdown
8.1. Actors and their Goals
Policy Writer writes up policies of specific purposes.
Policy Publisher provides a service for policy aggregation and publishing for public access, be it free or not.
Preference Writer writes up preferences of specific purposes.
Preference Publisher provides a service for preference aggregation and publishing for public access, be it free of not.
Service Provider hosts the data that is provided by Data Owners and controls the accesses to the data.
Data Owner is the owner of the data who wants to publish it in a controlled way.
Data User wants to access data of which the accesses to it is controlled.
8.2. Main Sequence
Data Owner writes up or obtains a preference profile from Preference Publisher, publishes its data along with the preference profile to Service Provider.
Data User writes up her own set of policies or obtains ready-made one from Policy Publisher.
Data User tries to access the data of her interest via Service Provider by sending data request messages along with her policies.
Service Provider calculates the commitment between the policies from Data User and the preferences from Data Owner, and provides the requested data if the commitment is positive.
9. Narratives
9.1. Accessing Location Information
Policy-Preference computing can occur in any controlled data access scenario. One representative setting is the scenario of serving location information as described as follows:
The actors are:
Inquirer 1 - wants to locate The Tracked
Inquirer 2 - wants to locate The Tracked
The Tracked - wants to control the way of revealing its location
Tracking Server - wants to provide the location of mobile users
And the narrative is:
The Tracked is registered at Tracking Server so that the server can provide the location information of The Tracked. The Tracked posts its preferences that specify to whom and when its location information is available.
The Tracked periodically reports its location to the Tracking Server.
Inquirer 1 sends to Tracking Server a request for the location of The Tracked with its privacy policy description.
Tracking Server examines if there's an agreement among the preferences of The Tracked, the identity of Inquirer 1, and its privacy policy.
Tracking Server finds that there's an agreement, so it provides the location of The Tracked to Inquirer 1.
Later, Inquirer 2 also requests the location of The Tracked, but its privacy policy does not meet the conditions described in the preferences of The Tracked, so the request is rejected.
10. Commentary
I find preferences and policies everywhere on the web, e.g. P3P, CC/PP, location based service frameworks etc. Interchangeable rules will become an essential tool for formally describing and processing policies and preferences.