Add proper policy atomization

[woutslabbinck]

Integrate the policy atomizer https://github.com/SolidLabResearch/ODRL-atomizer in the ODRL Evaluator.
This would solve #3

[woutslabbinck]

I've tested out the ODRL atomize library and decided for now not to integrate it within the ODRL Evaluator yet.

The reason for this is that it creates new identifiers for all ODRL rules, with a reference with property http://example.org/ns/derivedFrom to the original rule.

This results in ODRL Compliance Rule Reports (report:RuleReport) referencing ODRL Rules that were not part of the input (using report:rule) ODRL Policy.

Furthermore, if it were the same rule identifier. We would get that the action can be performed an not performed at the same time. That is also not ideal (see example).

Original policy

@prefix ex: <http://example.org/>.
@prefix odrl: <http://www.w3.org/ns/odrl/2/> .

ex:usagePolicy1 a odrl:Agreement ;
  odrl:permission ex:permission1 .
ex:permission1 a odrl:Permission ;
  odrl:action odrl:modify, odrl:read ;
  odrl:target <http://localhost:3000/alice/other/resource.txt> ;
  odrl:assignee <https://both.pod.knows.idlab.ugent.be/profile/card#me> .

Atomized policy

<http://example.org/usagePolicy1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/odrl/2/Agreement> .
<http://example.org/usagePolicy1> <http://www.w3.org/ns/odrl/2/permission> _:n3-0 .
_:n3-0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/odrl/2/Permission> .
_:n3-0 <http://example.org/ns/derivedFrom> <http://example.org/permission1> .
_:n3-0 <http://www.w3.org/ns/odrl/2/target> <http://localhost:3000/alice/other/resource.txt> .
_:n3-0 <http://www.w3.org/ns/odrl/2/action> <http://www.w3.org/ns/odrl/2/modify> .
_:n3-0 <http://www.w3.org/ns/odrl/2/assignee> <https://both.pod.knows.idlab.ugent.be/profile/card#me> .
<http://example.org/usagePolicy1> <http://www.w3.org/ns/odrl/2/permission> _:n3-1 .
_:n3-1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/odrl/2/Permission> .
_:n3-1 <http://example.org/ns/derivedFrom> <http://example.org/permission1> .
_:n3-1 <http://www.w3.org/ns/odrl/2/target> <http://localhost:3000/alice/other/resource.txt> .
_:n3-1 <http://www.w3.org/ns/odrl/2/action> <http://www.w3.org/ns/odrl/2/read> .
_:n3-1 <http://www.w3.org/ns/odrl/2/assignee> <https://both.pod.knows.idlab.ugent.be/profile/card#me> .

This is what happens if I evaluate over the latter with following request

@prefix odrl: <http://www.w3.org/ns/odrl/2/> .

<urn:ucp:policy:2a797ad7-232a-4e1f-853f-81388969e4a1> a odrl:Request;
    odrl:permission <urn:ucp:rule:e3ba21f7-57b0-4a43-988a-3221aba858ef>.
<urn:ucp:rule:e3ba21f7-57b0-4a43-988a-3221aba858ef> a odrl:Permission;
    odrl:action odrl:read;
    odrl:target <http://localhost:3000/alice/other/resource.txt>;
    odrl:assignee <https://both.pod.knows.idlab.ugent.be/profile/card#me>.

Compliance Report

@prefix ex: <http://example.org/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix report: <https://w3id.org/force/compliance-report#> .

<urn:uuid:254aed05-8592-44de-90e2-c0bcda3dc22c> a report:PolicyReport ;
  dct:created "2024-02-12T11:20:10.999Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
  report:policy ex:usagePolicy1 ;
  report:policyRequest <urn:ucp:policy:2a797ad7-232a-4e1f-853f-81388969e4a1> ;
  report:ruleReport <urn:uuid:db86aa2d-0816-40b9-8ae6-d35ff1f2eb04>, <urn:uuid:d59850c2-9f3d-477a-b362-2a9ad0be28c4> .

<urn:uuid:db86aa2d-0816-40b9-8ae6-d35ff1f2eb04> a report:PermissionReport ;
  report:attemptState report:Attempted ;
  report:rule _:n3-0 ;
  report:ruleRequest <urn:ucp:rule:e3ba21f7-57b0-4a43-988a-3221aba858ef> ;
  report:premiseReport <urn:uuid:acffccae-bb4c-4779-8c18-11b59f4e467c>, <urn:uuid:34ddd799-811c-41ee-b68b-44a3a006e54e>, <urn:uuid:73354a26-8236-4ed9-ad81-eac81f34fb48> ;
  report:activationState report:Inactive .

<urn:uuid:d59850c2-9f3d-477a-b362-2a9ad0be28c4> a report:PermissionReport ;
  report:attemptState report:Attempted ;
  report:rule _:n3-1 ;
  report:ruleRequest <urn:ucp:rule:e3ba21f7-57b0-4a43-988a-3221aba858ef> ;
  report:premiseReport <urn:uuid:acffccae-bb4c-4779-8c18-11b59f4e467c>, <urn:uuid:34ddd799-811c-41ee-b68b-44a3a006e54e>, <urn:uuid:adecb3f6-46f0-4755-b5cf-f80a1d886105> ;
  report:activationState report:Active .

<urn:uuid:acffccae-bb4c-4779-8c18-11b59f4e467c> a report:TargetReport ;
  report:satisfactionState report:Satisfied .

<urn:uuid:34ddd799-811c-41ee-b68b-44a3a006e54e> a report:PartyReport ;
  report:satisfactionState report:Satisfied .

<urn:uuid:73354a26-8236-4ed9-ad81-eac81f34fb48> a report:ActionReport ;
  report:satisfactionState report:Unsatisfied .

<urn:uuid:adecb3f6-46f0-4755-b5cf-f80a1d886105> a report:ActionReport ;
  report:satisfactionState report:Satisfied .

[woutslabbinck]

After some further discussions, there is the following conclusion.

When we atomize and evaluate, if there is a rule report that is active, that means the following:
One of the atomic ODRL rules of the policy results in an active rule report.

Lets check three cases with each different deontic rules.

If we had atomic permission rules to begin with, the specific active rule report would entail the action could be performed.
Thus if that were to be made into a composite rule, the action could still be performed, thus active is what matters.

If we had atomic prohibition rules to begin with, the specific active rule report would entail the action could NOT be performed.
If we bring those atomic prohibitions into one composite rule, the action still may not be performed. The active rule report is again what matters.

If we had atomic deontic rules to begin with, the specific active rule would entail the action MUST be performed (at some point).
It would here however mean that all actions at some point must be performed here, though activation state is not calculated for Duty rules by using a request.

I guess you could say duties are always active? The performance state is what matters there

[woutslabbinck]

Proposed implementation for handling Rule Compositions:

reports = []

for all rules in policies:

1. atomize (using ODRL-atomizer)
2. evaluations <- evaluate all atomized policies individually
   2.a. if there is an active rule: report <- compliance report of active policy
   2.b if there is no active rule: report <- compliance report with most satifisfied premises
3. rename blank node identifiers in report with identifiers from the original policy
4. add report to reports

This should be then replace this evaluation line:

ODRL-Evaluator/src/evaluator/Evaluate.ts

Line 72 in 09aede5

const evaluation = await this.engine.evaluate([...instantiatedPolicies, ...request, ...state])

And these comment should then be placed appropriately:

ODRL-Evaluator/src/evaluator/Evaluate.ts

Lines 63 to 66 in 09aede5

	// policy decomposition must happen to reduce the rules in the policy to atomic rules
	// see ODRL § 2.7 Policy Rule Composition (https://www.w3.org/TR/odrl-model/#composition)
	// if there are compact policies -> they must be expanded (also reocmmended by ODRL § 2.7.1 Compact Policy)