w3c
Description of the state of the world and the evaluation request in the specification text
Add two sections in the Formal Semantics document: one to propose a description of the representation of the world and one for the evaluation request of the ODRL Evaluator to make an evaluation. Text can depart from the State of the World for ODRL [link]
Here is a proposal for an Evaluation Request only using the ODRL existing Ontology, here included an OWL, and SHACL for the minimum attributes, "assigneOf" links back to the policy (it's optional), but might be useful when the same Asset is present in multiple policies (Example of having a policy to buy a lifetime license and another policy with subscription for the same product)
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix ex: <http://example.org/odrl-fs#> .
ex:EvaluationRequest a owl:Class ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty odrl:action ;
owl:someValuesFrom odrl:Action
] ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty odrl:assignee ;
owl:someValuesFrom odrl:Party
] ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty odrl:target ;
owl:someValuesFrom odrl:Asset
] .
odrl:assigneeOf a owl:ObjectProperty ;
rdfs:domain odrl:Party ;
rdfs:range odrl:Policy .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix ex: <http://example.org/odrl-fs#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
ex:EvaluationRequestShape a sh:NodeShape ;
sh:targetClass ex:EvaluationRequest ;
sh:property [
sh:path odrl:action ;
sh:minCount 1 ;
sh:maxCount 1 ;
sh:class odrl:Action ;
] ;
sh:property [
sh:path odrl:assignee ;
sh:minCount 1 ;
sh:maxCount 1 ;
sh:class odrl:Party ;
] ;
sh:property [
sh:path odrl:target ;
sh:minCount 1 ;
sh:maxCount 1 ;
sh:class odrl:Asset ;
] .
ex:AssigneeShape a sh:NodeShape ;
sh:targetObjectsOf odrl:assignee ;
sh:property [
sh:path odrl:assigneeOf ;
sh:maxCount 1 ;
sh:class odrl:Policy ;
] .
Of course, this should be extensible to add any required attributes depending on the use case of the evaluator.
Conceptually, the shape of the response would need to align with the shape of the request (e.g. 1:1, N:N request:response)?.
Also I would restrict the properties by sh:maxCount 1 ; as that class above can send a request that allows for calls like "can these actions be performed over these assets by these parties", creating a three-dimensional response (action x party x asset), perhaps theoretically allowed in an "open" world, but there is no longer coherent serialisation (e.g. first print -> then bound -> then sell).
Conceptually, the shape of the response would need to align with the shape of the request (e.g. 1:1, N:N request:response)?.
Also I would restrict the properties by
sh:maxCount 1 ;as that class above can send a request that allows for calls like "can these actions be performed over these assets by these parties", creating a three-dimensional response (action x party x asset), perhaps theoretically allowed in an "open" world, but there is no longer coherent serialisation (e.g. firstbound-> thensell).
I agree with the maxCount, I edited the comment above to add it. However I do not agree that the request needs to align with the response, in "closed-box" or User Centric Access Control, a simple boolean could be enough, but for Usage Control with possible consequences there need to be more details. The response can then refer to the request for traceability.
If you have Subject x Action x Resource matrix - a simple "yes/no" only tells you if all conditions were met for the request, but for sequences sent in the same request, you will never move to a "yes" state.
Please provide examples for Usage Control.
I think @YassirSellami is right, we may have different types of evaluation requests and the output of an evaluation should be a report that may have (for some types) just a yes/no, or more complex answers for other types of evaluation requests (like for usage control)
@AndreaCimminoArriaga - Examples are the best way to reinforce requirements.
For the Example 21 in here: https://www.w3.org/TR/odrl-model/#duty-policy or any kind of case where you would pay a fine or face any consequences. A detailed output from the evaluator is required to define what is the applied action(s) and obligations after evaluation of the request and state of the world. This can also be useful as an evaluation of Personal Data Regulations infrigements.
In the sake of transparency, the detailed outputs can also serve as trustworthy auditable trail.
Sorry @YassirSellami - I am confused, in your last message ("consequences", "after evaluation") you are talking about outputs, and your original message above was inputs (EvaluationRequest)?
I also don't think any example in the current 2.2 version describes "many 2 many 2 many", there is no trail that would justify that (and 21 has the assignee and assigner are instances, not collections), hence why supporting examples should be thought through.
For the Example 21 in here: https://www.w3.org/TR/odrl-model/#duty-policy or any kind of case where you would pay a fine or face any consequences. A detailed output from the evaluator is required to define what is the applied action(s) and obligations after evaluation of the request and state of the world. This can also be useful as an evaluation of Personal Data Regulations infrigements.
In the sake of transparency, the detailed outputs can also serve as trustworthy auditable trail.
exactly! and this not only applies to duties but also to any other types of requirements that can be modelled as constraints, e.g., the purpose or recipients of a certain action.
Sorry @YassirSellami - I am confused, in your last message ("consequences", "after evaluation") you are talking about outputs, and your original message above was inputs (
EvaluationRequest)?I also don't think any example in the current 2.2 version describes "many 2 many 2 many", there is no trail that would justify that (and 21 has the assignee and assigner are instances, not collections), hence why supporting examples should be thought through.
This was only to provide examples for your comment on Output and Usage Control/Monitoring which is mentioned in the Formal Semantics document.
I think to be efficient let's not discuss the output further and focus on the input for this issue.
For the "Many 2 Many", we can discuss it here: https://github.com/w3c/odrl/issues/119, or should that be a seperate discussion for the attributes of the policy. In my humble opinion, it could better to start by considering one Policy containing one target for one assignee, then try to move further.
More confusion - #119 talks about many policies, not many requests?
I also don't understand what is the need for many requests unless there are many policies, that's why it can be related.
@YassirSellami , you raised the many requests with your 1:unbound.
And anyway, policies are "data", e.g.
rule 1, condition1, etc etc
rule 2, condition2, etc etc
A request would be the equivalent of running ONE SINGLE SPARQL query over that data, and therefore, having (NxMxO inputs) is my issue.
Solved, Yassir will created a pull request to change the Semantics of ODRL web page.
