Re: Leveraging ODRL to represent data contracts

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