- From: Joshua Cornejo <josh@marketdata.md>
- Date: Thu, 04 Jul 2024 13:57:55 +0100
- To: "public-odrl@w3.org" <public-odrl@w3.org>
- Message-ID: <0878D12B-9511-4439-9E14-47D72C4881C8@marketdata.md>
Your statement:
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?
It reads as if you are establishing an “observable condition” (it does not read as permission nor an obligation as per the ODRL definitions) for the exchange.
As a way forward (if you want to bundle into an ODRL Agreement), you could create a new sub-class from odrl:Rule that is fit for your purpose:
Ontology like:
@prefix xin <https://your.url/>. xin:Contract rdfs:subClassOf odrl:Agreement ; # add a new relationship to xin:Indicator. xin:Indicator rdfs:subClassOf odrl:Rule ; # You can SHACL odrl:failure relationship (another xin:Indicator?) # And then define xin:amend (to a Duty associated when an Indicator fails?) # Finally define any other mandatory relationships and/or properties.
Example:
ex:ContinuousURI a odrl:Action;
terms:description "insert your KPI action and constraint"@en;
odrl:refinement ex:ContinuousURI. ex:ContinuousIndicator a xin:Indicator;
odrl:target ex:dataset; odrl:failure ex:someOtherIndicator; odrl:refinement ex:ContinuousURI.
ex:ServiceDescription a xin:Contract; odrl:permission ex:PermissionURI; odrl:obligation ex:PaymentURI, ex:IndicatorPenaltyURI;
xin:indicator ex:ContinuousIndicator.
“Indicator” due to lack of a better name, as in SLA most things are referred to as key performance indicators (KPI), and to keep consistency with being a noun.
You could then expand the Actions / LeftOperands / etc to make sense within your profile.
Regards,
___________________________________
Joshua Cornejo
marketdata
embed open standards
across your supply chain
From: Xin LI <xin-li1990@hotmail.com>
Date: Thursday 4 July 2024 at 12:56
To: "Beatriz Gonçalves Crisóstomo Esteves (UGent-imec)" <Beatriz.Esteves@ugent.be>
Cc: "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 11:56:09 +0000
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
On 4 Jul 2024, at 08:49, Beatriz Gonçalves Crisóstomo Esteves (UGent-imec) <Beatriz.Esteves@ugent.be> wrote:
Hi Xin,
Also consider that to model data governance-related concepts there’s 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. (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 (in particular and at this stage - Catalog and Data Service).
Regards,
___________________________________
Joshua Cornejo
marketdata
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.
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 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 | www.gaia-x.eu |
Avenue des Arts 6-9
1210 Bruxelles/Brussels
Belgium
<image001.png>
News & Press | Events | Media| Membership | 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
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:
Data use constraints
Technical quality
Service Level Agreement (SLA)
......
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.
GitHub - bitol-io/open-data-contract-standard: Home of the Open Data Contract Standard (ODCS).
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
Received on Thursday, 4 July 2024 12:58:02 UTC