Specifying details to help fulfill a duty or obligation

[csarven]

For example, can additional details about the payment, such as available payment locations and payment methods be expressed in order to meet an obligation towards fulfilling a duty or obligation? Is this currently possible via the constraint and/or refinement properties or in other ways?

[joshcornejo]

I've implemented interactions with duties "in other ways".

a) I've created an extra property on the definition of duties (and the result) that allows for feedback (e.g. the client receives a pair of < type, content >, for example < "javascript", "url" > for a specific duty. This doesn't need standardisation (for now?).

So that javascript could be anything (like a map to available payment locations), but could be a JSON or any object of type "type".

b) sync - this will require an extension ( ... for consistency ... ) to ODRL to specify if a duty will "hold" on returning a result until it is fulfilled for a trigger. It could also have a 'time-out', so requests don't remain hanging (in my case status will return 0 = no sync, any number is an epoch representation of 'when a timeout will occur'). No result to the action request will be sent until the fulfilment of all duties.

So you can imagine that you "click" on a link to execute an action ... (a)happens and with (b) you can "wait" any further request until the corresponding duties have been fulfilled as specified on the interactions at (a).

[csarven]

Some related work that I'm trying to see what can be bridged:

https://www.w3.org/TR/payment-request/

w3ctag/design-reviews#1015

[joshcornejo]

They would be on my (a) side to start, and "compatible" with what I already provide on the envelope:

At this stage "asset" is just an ID, which could be equivalent to their json id:

"id": "super-store-order-123-12312",

... and once payment has happened, through back channels (b) could finalise as it has fulfilled the duty and return the result of the actions.

The architecture I envisioned looks like this:

[joshcornejo]

After a parallel chat, the use of spatial (and virtualLocation) could create a logical constraint that specifies "pay" AND "location" that could be bundled.

ex:uri_payment  a odrl:Constraint;
                odrl:leftOperand odrl:payAmount;
                odrl:operator odrl:eq;
                odrl:rightOperand "10"^^xsd:int;             # simple reference to amount
                odrl:unit ex:EURO.                           # reference to unit
ex:uri_location a odrl:Constraint;
                odrl:leftOperand odrl:spatial;               # indicates a location 
                odrl:operator odrl:eq;
                odrl:rightOperandReference ex:uri_payment_location.  # reference to URI that specifies that location
ex:logical_cons a odrl:LogicalConstraint;
                odrl:and ex:uri_payment,
                         ex:uri_location.

Comments:

• this approach would require the client to have a "duty" parser (the processing of the constraint takes place in 2 places: the evaluator to assess it, and the client to figure out actions)
• it will need different LeftOperands: odrl:spatial addresses physical / odrl:virtualLocation addresses digital
• it is possible for ex:uri_payment_location to contain all the information that answers the rest of the question (like 'payment methods'), so there is some separation between the fulfilment ("paying") process and the constraining ("odrl") process.
• it "smells" like coupling business responsibilities belonging to a different process (payment streams) to rights management.

[joshcornejo]

As it turned out it is quite easy to add this requirement on the reply too:

    "duties": [
      {
        "id": "uri of the duty",
        "timeStamp": 1234567890,         // epoch_number_for_event_signature
        "agreement": "uri of the agreement",
        "actor": "uuid of the actor",
        "triggerId": "uri of the 'triggerer' of the duty",
        "action": "action uuid",
        "asset": "uri for the asset",
        "relationship": "relationship uuid",
        "responsibilities": [ 
          {
            "action": [
              "compensate"               // a list of actions within the duty
            ],
            "operand": null,             // operand for logical constraint (if)
            "conditions": [              // the list of constraints constraint
              {
                "leftOperand": "payAmount", 
                "operator": "eq",                     
                "rightOperand": "uri_right_operand"
              }
            ]
          }
        ],
// a non-tripled alternative to fulfil the duties
        "toDo": {
          "type": "javascript",
          "content": "https://www.some-example.com/js/some-script.min.js"
        },
// status
        "fullfilled": false
      }