w3c / market-data-odrl-profile

Rights Automation for Market Data W3C Community Group
Other
4 stars 6 forks source link

Notification, Request, and Consent Duties #6

Closed benedictws closed 3 years ago

benedictws commented 4 years ago

Many licenses require the Assignee to notify the Assigner when they start to use a product.

This can easily be modeled by a Duty. Effectively the permission(s) to use the product only become valid once the notification duty is fulfilled. Notification only needs be done once to fulfill the duty.

In summary (and from the DBAG non-display license):

db:O4-1 a                   odrl:Duty ;
        nl:creditor         <https://permid.org/1-4298007872> ; # DBAG
        odrl:action         [   a                  md:Notify ;
                                md:actionScope     md:Usage ;
                                odrl:count         "1"^^xsd:int
                            ] .
markabird commented 4 years ago

Could Notification Duties be used to enforce prior approval before distributing to a third party, or would that be a different duty?

benedictws commented 4 years ago

Good point, @markabird. Enough to change the title of this issue!

One could create a single duty (on the assignee) to obtain consent. The action would be something like obtainConsent. But that doesn't really model the interaction between the assignee and the assigner that delivers consent.

The interaction involves the assignee requesting a desired state, and the assigner consenting to it. Here we have two duties: one on the assignee (to request) and one on the assigner (to consent).

benedictws commented 4 years ago

Take the example of obtaining consent for the use of a Service Facilitator in the DBAG license.

The first duty, the request, differs from the example at the top both in its action and in its actionScope. We're not notifying the exchange that we've started using their product, but that we want to use a Service Facilitator.

It's also not a "one-off" duty, but one that is conditional on achieving a desired state: that of giving a Service Facilitator access to the data. We can capture that in a constraint: we want the property recipient (i.e. additional parties with access to the data though no rights over it) to be satisfied by an external party with the role of Service Facilitator.

So:

db::D3     a                   odrl:Duty ;
        nl:creditor         <https://permid.org/1-4298007872> ; # DBAG
        odrl:action         [   a                       md:Request ;
                                md:actionScope          md:ServiceFacilitator ;
                                odrl:count              "1"^^xsd:int
                            ] ;
        md:recipient        [   a                       md:External ;
                    md:role                 md:ServiceFacilitator
                            ] .

But this takes us only halfway to consent.

benedictws commented 4 years ago

We now need the assigner (in this example, DBAG) to give consent. This is another duty, but DBAG is now the debtor - it needs to consent, or not:

db:O3   a                   odrl:Duty ;
        nl:debtor           <https://permid.org/1-4298007872> ; # DBAG
        odrl:action         [   a                       md:Consent ;
                                md:actionScope          md:ServiceFacilitator ;
                                odrl:count              "1"^^xsd:int
                            ] ;
        odrl:duty           db:D3 . 

Note how this duty is only activated when the notification duty db:D3 is fulfilled. It's analogous to issue 8 when the payment duty only becomes active on fulfillment of the invoicing duty.

benedictws commented 4 years ago

The notification duty at the top of these comments, db:O4-1, provides no criteria that specify under what conditions it becomes activated. In a sense, it's simple: notify DBAG when you start using their data. But how do we capture this with a property? What is the property?