w3c / odrl

ODRL Community Group Repository
https://www.w3.org/community/odrl/
Other
18 stars 10 forks source link

How to represent in the "state of the world" the executed Actions #61

Open fornaran opened 4 months ago

fornaran commented 4 months ago

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.

  1. Are these basic properties OK?
  2. Is the list of action types specified in "ODRL Vocabulary & Expression 2.2/Actions for Rules" (https://www.w3.org/TR/odrl-vocab/#actionsCommon)?
  3. Is the list of other properties that can be used to describe an action that has been performed specified in "ODRL Vocabulary & Expression 2.2/Constraint Left Operands" (https://www.w3.org/TR/odrl-vocab/#constraintLeftOperandCommon)?
joshcornejo commented 3 months ago

In the work I am doing, and as per the email I sent a few days ago:

image001

  1. Once an agreement is created, a world IRI is generated (ie. because in practice a world can have 1:n agreements for the same actor(s));
  2. The agreement is added to a world, the extraction of variables takes place and they are added to the 'state of the world';
  3. The variables have a type, a name and values (e.g. <xsd:boolean, State, [false]> / <iso:iso639, languages, [esp, eng]>);
  4. Evaluation takes place via a function evaluate <world IRI , actor IRI, action IRI, asset IRI>

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.

vroddon commented 1 month ago

The representation of the state of the world implies having new elements in ODRL. I label this issue as "new feature".

joshcornejo commented 1 month ago

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.