Open fornaran opened 4 months ago
In the work I am doing, and as per the email I sent a few days ago:
evaluate ( did:odrlw:01913775-4e85-74a4-881a-5b1005415c12, ex:someActor, odrl:play, ex:someMovie )
Note 1: I like the order world -> actor -> action -> asset (i think it has a good grammatical flow compared to action -> actor -> asset).
Note 2: For practical reasons, variables can also be added to the world "manually" to the context, especially for "spatial" assessments (we only know the location of an actor or asset when the evaluation is executed. I have 3 functions: addToContext / replaceInContext / removeFromContext - the most important is "replace" (as it can 'fix' issues with any variable's state/value and do things like change location), probably irrelevant to formal definitions.
The representation of the state of the world implies having new elements in ODRL. I label this issue as "new feature".
So far the state of the world and a Policy have been separate entities as an implementation.
The "world" is linked to an "agreement" only for practical purposes, and as per my diagram above, when an agreement is created between an odrl:Assigner and an odrl:Assignee - the "world manager" extracts the variables from the agreement and categorises them (those that are "editable" - like a count and those that are "extraneous" - like dateTime).
I am unsure if the actual representation of the world has to be part of a "new feature" - unless the expectations are that you can "move" the agreements and states of worlds around in a distributed environment.
I would start with a logical representation and the rules to evaluate an outcome.
If we speak about "what is out there", as I mentioned during our call - authZen has a definition that was compatible with my evaluation:
{
"subject": {
"id": "Alice"
},
"resource": {
"type": "payment_initiation"
},
"action": {
"name": "transfer"
},
"context": {
"remittance": "Ref Number Merchant"
}
}
They also have a verbose way of describing relationships, those "evaluations" listed in that example, look as they can be actions in a list:
odrl:action ex:list_accounts, ex:read_balances, ex:read_transactions
I have a much more "compressed" (because the agreements give us much more information from the start) < subject, action, resource >
where each item is just a UUID with the addition of the world it looks something like: < worldId, < actor, action, asset > >
Finally, they have a "client" managed context (or "state of the world") ... I am partial to where the context lives, there are advantages and disadvantages of either side.
In order to proved a Formal Semantics for ODRL (https://w3c.github.io/odrl/formal-semantics/), it is necessary to specify the name of the properties that can be used to describe the executed Actions in the "state of the world". One initial proposal may be to represent them with at least: a type (the class of Actions to which the action belong), a performer (i.e. the agent that performs the action), an object (i.e. the object on which the action is performed), an atTime for describing the instant of time when the action is executed or when its execution has started.