- From: Renato Iannella <r@iannel.la>
- Date: Wed, 10 Jul 2024 11:31:12 +1000
- To: "public-odrl@w3.org" <public-odrl@w3.org>
- Message-Id: <4CFB844B-B99D-4678-9716-76910A10C630@iannel.la>
Yes, good pick up and suggestion Joshua !
R
> On 9 Jul 2024, at 22:08, Joshua Cornejo <josh@marketdata.md> wrote:
>
> Reading the standard, shouldn’t it have the line in yellow?
>
> An ODRL Policy of subclass Agreement:
>
> · MUST have one assigner property value (of type Party) to indicate the functional role in the same Rules.
>
> · MUST have one assignee property value (of type Party) to indicate the functional role in the same Rules.
>
>
> {
> "@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": [{
> "assigner": "http://example.com/big-data-org",
> "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" }
> }]
> }]
> }]
> }
>
> There are also “other” roles that could be useful:
>
> https://www.w3.org/TR/odrl-vocab/#partyRolesCommon
>
> odrl:informingParty / odrl:informedParty could also serve as useful functions in a ‘dialogue’ during this SLA scenario?
>
> "obligation": [{
> "assigner": "http://example.com/big-data-org",
> "assignee": "http://example.com/big-data-org",
> "informingParty": "http://example.com/big-data-org",
> "informedParty": " http://example.com/user1",
> "action": [{
> "rdf:value": { "@id": "ex:update" },
> "refinement": [{
> "leftOperand": "ex:frequency",
> "operator": "eq",
> "rightOperand": { "@value": "PD", "@type": "xsd:duration" }
> }]
> }]
> }]
>
>
> ___________________________________
> Joshua Cornejo
> marketdata <https://www.marketdata.md/>
> embed open standards
> across your supply chain
>
> From: Renato Iannella <r@iannel.la <mailto:r@iannel.la>>
> Date: Tuesday 9 July 2024 at 04:14
> To: "public-odrl@w3.org <mailto:public-odrl@w3.org>" <public-odrl@w3.org <mailto:public-odrl@w3.org>>
> Subject: Re: Leveraging ODRL to represent data contracts
> Resent-From: <public-odrl@w3.org <mailto: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": [{
> "assigner": "http://example.com/big-data-org",
> "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
Received on Wednesday, 10 July 2024 01:31:40 UTC