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

[fornaran]

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]

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

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]

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

[joshcornejo]

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.

[woutslabbinck]

To describe executed actions in the state of the world, we (@besteves4 and me) are proposing the compliance report model presented for the ODRL CG at 2 October (slides).

The policy report allows to describe the action, party and target resource by linking to the relevant odrl policy and rule and it has a property to denote the time.

Futhermore, the model can also be used to denote an odrl evaluation.

The repository contains examples of the report for the three type of rules: Permission, Prohibition and Duty.

If this model seems interesting, we would gladly further discuss it in a future ODRL (formal semantics) CG
meeting.

[joshcornejo]

When you say "describe executed actions in the state of the world", are you proposing some sort of "historical ledger"?

There seems to miss the outcome of the entire policy (a world can have many policies, let's assume with one actor, many actions, and many targets, and some can be inactive as the target is not part of that policy). It could have all the Attempted and Activation states.

Your diagram shows only Permissions, although it shows the report classes for all the rule types. A Permission can be "active/attempted", and during that same evaluation, you can have a Prohibition "active/violated" - the outcome of the Policy is therefore "active/violated". For example: "actor has permission to use asset" / "actor is prohibited to use it from home" (and yes, you can model this as a single rule - but you can also model it as multiple rules, so you have to allocate both possible paths, and hence why Policy is the "ultimate" outcome).

I'm not fond of reporting on "not attempted" - useful for development/debugging, but it could end up having lengthy reports with inconsequential entries.

Finally, during our call in October, it was raised a few times the complexities of Duty fulfilment processes. An example following yours:

ALICE must DELETE resource X

In practice, resource X is in Alice's shared drive, which has a local backup for her office that remains there for 12 months, and also goes to an organisational archive for 7 years.

At what point is the duty considered fulfilled and that report can be generated?

[fornaran]

Thank you for the fruitful discussion on this issue related to the ‘state of the world’.
If I have understood correctly, different visions have emerged as to what should be represented in the 'state of the world'.
Therefore, before discussing how to represent information in the state of the world (see the questions at the beginning of the issue), I think it is best to reach an agreement on what to represent.

I try to summarize the results of the discussion.
The following information has to be represented in the state of the world:

1. the current time of the state of the world; (proposed in [1] and [2]);
2. the list of performed actions (proposed in [1] and [2]);
3. every performed action has at least: a type, a performer, an object, an instant of time or an interval of time when it is performed; (proposed in [1])
4. a set of agents belonging to the odrl:Party class; (proposed in [1])
5. a set of objects belonging to odrl:Asset class;
6. a set of collections belonging to the odrl:AssetCollection class; (proposed in [2])
7. a set of collections belonging to the odrl:PartyCollection class; (proposed in [2])

• Is there any other information that you think is important to represent in the state of the world? Please also explain why.
• Is it ok to keep the set of objects that belong to the odrl:Agreement or odrl:Policy class separated from the "state of the world" (proposed in [3])?

References:
[1] Introduction of ODRL Formal Semantics web page https://w3c.github.io/odrl/formal-semantics/#intro
[2] Beatriz and Wout in slide 21 https://docs.google.com/presentation/d/1U0Rrvi8rhEIcS5DLrdmJ2kabQBurghQutS_mDMJW410/edit#slide=id.g307a5efff81_0_142
[3] propose by Joshua in this discussion

[vroddon]

Proposed resolution: the context is unlimited, infinite. Every new specified element should be backed by an example in the test bed. If there is no example in the test bed, we should not speak about it.

Therefore, the action is to add examples (jsonld or turtle files) in the github repo, folder "Formal Semantics" folder.