Re: Leveraging ODRL to represent data contracts

Hi Xin,
Also consider that to model data governance-related concepts there’s DPV<https://w3id.org/dpv/>.
DPV has an extensive list of taxonomies for legal roles, purposes, legal basis, data categories, technical and organization measures, and risks that can be used to populate data contracts.
Best,
Beatriz Esteves

From: Joshua Cornejo <josh@marketdata.md>
Date: Thursday, 4 July 2024 at 09:29
To: public-odrl@w3.org <public-odrl@w3.org>
Subject: Re: Leveraging ODRL to represent data contracts
Hi,

I had a long draft in progress, but I will just put 3 key points (unless someone is interested and we should have a call).


  *   I read ODCS last night and it appears their meaning of ‘contract’ is perhaps close to the definition of ‘protocol’, for negotiation between end-points (SLA’s would be for ‘groups of end-points’)
  *   In my experience, service-level (not end-point) SLA semantics are different from Rights semantics (SLA’s are expressed in concepts such as ‘should’ / ‘must’, percentages, ranges and penalties/credits).
  *   If I use the definitions from Telecommunications (it has a very mature framework called eTOM): BSS (business dimension) is where ODRL (and Yassir’s contracts) operate; whilst OSS (operational dimension) is where SLA operate.

You can see there have been efforts to propose ontologies on SLA in the past<https://www.researchgate.net/publication/271516192_Ontology_of_Secure_Service_Level_Agreement>. (Fig 1 gives a good overview of the main concepts).

PS. The GaiaX’s ServiceOffering entities appear to be a subset, and going in the direction to be a remake of DCAT<https://www.w3.org/TR/vocab-dcat-3/> (in particular and at this stage - Catalog and Data Service).

Regards,
___________________________________
Joshua Cornejo
marketdata<https://www.marketdata.md/>
embed open standards
across your supply chain

From: Yassir Sellami <yassir.sellami@gaia-x.eu>
Date: Thursday 4 July 2024 at 07:09
To: "xin-li1990@hotmail.com" <xin-li1990@hotmail.com>, "public-odrl@w3.org" <public-odrl@w3.org>
Subject: Re: Leveraging ODRL to represent data contracts
Resent-From: <public-odrl@w3.org>
Resent-Date: Thu, 04 Jul 2024 06:09:09 +0000

Hello,

I am not familiar with the Open Data Contract Standard, thanks for sharing.
However, I do believe it is very close to what we are trying to do at Gaia-X you can find the ontology here<https://gaia-x.gitlab.io/technical-committee/service-characteristics-working-group/service-characteristics/ontology/gaia-x/ServiceOffering>.

In my honest opinion, it is sometimes necessary to traverse the graph, but it also depends on whether the policy needs to be technically enforced or just be a legally binding contract. Another possibility is to "flatten" the contract at the time of agreement/signature.

Another crucial point: signing the contract, this would make sure that it cannot be tampered with, and have a certain legal validity, for this we are using Verifiable Credentials which could also allow the Integrity of related resources<https://www.w3.org/TR/vc-data-model-2.0/#integrity-of-related-resources.> in that graph.

But I am also curious to know what the ODRL community think about this issue.

Please feel free to contact me if needed.

Regards,

Yassir Sellami | Software Developer
Gaia-X European Association for Data and Cloud AISBL

yassir.sellami@gaia-x.eu<mailto:yassir.sellami@gaia-x.eu>  | www.gaia-x.eu<http://www.gaia-x.eu/> |

Avenue des Arts 6-9
1210 Bruxelles/Brussels
Belgium

[Gaia-X Signature Generic.png]<https://gaia-x.eu/>

News & Press<https://gaia-x.eu/news-press/> | Events<https://gaia-x.eu/events/> | Media<https://gaia-x.eu/media/>| Membership<https://gaia-x.eu/membership/> | www.gaia-x.eu<http://www.gaia-x.eu/>

PRIVACY AND CONFIDENTIALITY NOTICE: For details about what personal information we collect and why, please see our Privacy Policy on our website at http://www.gaia-x.eu/privacy-policy.


This e-mail message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or legally privileged information. Any unauthorized use or disclosure, copying and/or distribution of the content of this e-mail message and attachments is prohibited. If you are not the intended recipient, please contact us by reply e-mail and destroy all copies of the original message and attachments immediately. Thank you.

Please consider the environment before printing this e-mail. Save about 200ml water, 2g CO2, 0.05kWh power, and 2g wood.

________________________________
From: Xin LI <xin-li1990@hotmail.com>
Sent: Wednesday, July 3, 2024 16:11
To: public-odrl@w3.org <public-odrl@w3.org>
Subject: Leveraging ODRL to represent data contracts

You don't often get email from xin-li1990@hotmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi, ODRL working group,

I am exploring the potential of leveraging ODRL to represent data contracts in a use case that my team is working on. The data contract I am dealing with is basically an agreement between data producer and data consumer that defines the following:


  1.  Data use constraints

  1.  Technical quality

  1.  Service Level Agreement (SLA)

  1.  ......

In fact, I am taking inspirations from the open data contract standard (https://github.com/bitol-io/open-data-contract-standard) and trying to leverage ODRL to encode these fundamentals defined in a data contract.
[Image removed by sender.]<https://github.com/bitol-io/open-data-contract-standard>
GitHub - bitol-io/open-data-contract-standard: Home of the Open Data Contract Standard (ODCS).<https://github.com/bitol-io/open-data-contract-standard>
Home of the Open Data Contract Standard (ODCS). Contribute to bitol-io/open-data-contract-standard development by creating an account on GitHub.
github.com

The target of an ODRL agreement is a dcat dataset in my use case. On the dcat side, a lot of metadata is captured such as data specifications, technical quality, and SLA. Our thought is when we create an agreement for a particular dataset, we can find its related technical quality, SLA from the dcat side.

For example, in our knowledge graph, we have a dataset instance, dataset1, shown below in turtle format.

example:dataset1 a dcat:Dataset ;
               dcterms:accrualPeriodicity <http://purl.org/cld/freq/continous> ;
                dcat:temporalResolution "PT1H"^^xsd:duration .

The data contract built for this dataset1:

example:contract1 a odrl:Agreement ;
            odrl:permission [  a odrl:Permission ;
                            odrl:target example:dataset1;
                            odrl:assigner example:provider1;
                            odrl:assignee example:consumer1
...........
]
                 
         
If we follow this approach, the agreement upon SLA and other fundamentals is seemingly inexplicit in this data contract as we have to further traverse the graph to find more metadata of the dataset1.

My question is what would be the best practice to utilize ODRL to document data contracts with requirements, including technical quality, SLA etc. Should we add additional constraints to the agreements to make the conditions more explicit, but somehow introduce data duplication?

     example:contract1 a odrl:Agreement ;
            odrl:permission [  a odrl:Permission ;
                            odrl:target example:dataset1;
                            odrl:assigner example:provider1;
                            odrl:assignee example:consumer1;
                            odrl:constraint [ a odrl:Constaint ;
                            odrl:leftOperand example:accrualPeriodicity ;
                            odrl:operator odrl:eq ;
                            odrl:rightOperand  <http://purl.org/cld/freq/continous>
]
...........
]


Please let me know if further information is needed.

Thanks,

Xin Li