Re: Leveraging ODRL to represent data contracts

Hi,

 

By the way, this was an extremely useful message (and distracting from the complexities of evaluation)!

 
I realised my DSL needed the concept of “self” for the users that are editors (which allowed me to test extensibility).
 

obligation ObligationName { 

            [ issue "2024-02-20T08:15:18.000Z" , expiry "2030-03-02T15:14:09.000Z" ];

            description "test auto";

            assignee Self; // ß parties need to reference themselves

        }            

 
How to map it to RDF/ JSON
 

md:URI_225b96258645_______21446I a time:ProperInterval;

                                 time:after "2024-02-20T08:15:18.000Z"^^xsd:dateTime;

                                 time:before "2030-03-02T15:14:09.000Z"^^xsd:dateTime.

md:URI_225b96258645_______21446A terms:created "2024-02-20T08:15:18.000Z"^^xsd:dateTime;
                                 terms:creator "user@editor.example"^^xsd:anyURI;
                                 terms:description "test auto"@en;
                                 terms:valid md:URI_225b96258645_______21446I;
                                 a odrl:Duty;
                                 odrl:assignee md:URI_225b96258645_______15372A; # ß this is the URI of self when generated
                                 odrl:assigner md:URI_225b96258645_______15372A. # ß same as the assigner

 

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain

 

From: Renato Iannella <r@iannel.la>
Date: Tuesday 9 July 2024 at 04:14
To: "public-odrl@w3.org" <public-odrl@w3.org>
Subject: Re: Leveraging ODRL to represent data contracts
Resent-From: <public-odrl@w3.org>
Resent-Date: Tue, 09 Jul 2024 03:14:04 +0000

 

Every rule can use explicit assigners/assignees, such as:

 

    "@type": "odrl:Agreement",

    "uid": "http://example.com/policy:88",

    "profile": "http://example.com/odrl:profile:09",

    "target": "http://example.com/dataset-001",

    "permission": [{

        "assigner": "http://example.com/big-data-org",

        "assignee": "http://example.com/user1",

        "action": "odrl:read"

    }]

    "obligation": [{

        "assignee": "http://example.com/big-data-org",

        "action": [{

                "rdf:value": { "@id": "ex:update" },

                "refinement": [{

                   "leftOperand": "ex:frequency",

                   "operator": "eq",

                   "rightOperand": { "@value": "PD", "@type": "xsd:duration" }

                }]

        }]

    }]

}  

 

 

Cheers -  R

 



On 8 Jul 2024, at 20:32, Xin LI <xin-li1990@hotmail.com> wrote:

 

Thanks Renato. 

 

I find the Service profile is quite close to my use case. So I can probably use the Duty rule to encapsulate requirements promised by producer as suggested, the only concern is in the existing examples provided in ODRL specifications, duty is always created for assignee and passed from assigner to assignee, can I only populate assigner property within a Duty rule to “implicitly” indicate that the duty is intended for assigner and assigner should fulfill the requirements in the duty? （I am trying to reuse the core ODRL model with minimum extensions)

 

{

“obligation”: [{

“assigner”: producer value,

“action”:[{

“rdf:value”:{

“@id”:”odrlprofile:update”

},

“refinement”: [

{

“leftOperand”: “frequency”

 

………………

 

 




On 6 Jul 2024, at 12:39, Renato Iannella <r@iannel.la> wrote:

 A long time ago, the ODRL group started work on a “Services Profile”: https://www.w3.org/2012/09/odrl/archive/odrl.net/Profiles/Services/WD-20080402.html 

that included “Requirements” (now called Duties) such as performance, reliability etc (see Fig 2 in the link above)

 

There is no reason why an ODRL Policy could not include an obligation (duty) on the provider (assigner) of a dataset (asset) to ensure it is updated on a daily basis (with appropriate new terms)

 

Cheers - Renato

 



On 4 Jul 2024, at 21:55, Xin LI <xin-li1990@hotmail.com> wrote:

 

Thanks Yassir, Joshua, and Beatriz for your invaluable feedback and suggestions.  

 

My use case is to leverage ODRL for documenting agreements between producer and consumer. This is a reverse engineered process as the data exchange already happened and we are now just trying to document the record.  Going forward, the right way should be similar to the Gaia-x approach which has a correct workflow for contract negotiations, including offering creation, data requests creation, negotiation, and agreement creation. 

 

The target in my use case is a dcat dataset, we have captured a lot of metadata for dataset, such as its quality, its SLA, and extended DCAT with properties to represent those metadata at dataset level. 

 

My question is when we reverse engineer to create an agreement to record the data exchange, should we use the constraint component to express requirements/conditions that are agreed by both parties? For example, both producer and consumer agree that the dataset must be updated on a daily basis, the leftOperand becomes frequency, operator becomes eq, and rightOperand becomes daily?

 

Though we can find frequency property value as daily from the dataset node, but to keep the specific requirement agreed by both parties at the Constraint component still makes sense?

 

Please let me know if you need further information.

 

Thanks,

 

Xin Li