sync agreements to Dataspaces practice

[VladimirAlexiev]

@jgeluk @rivettp
Perhaps you know, Dataspaces is a huge thing in Europe and is used in numerous industries for sharing of commercial/protected (not open) data.

https://github.com/EKGF/dprod/tree/main/examples/core-data-product-extensions talks of "adding an agreement to a data product" and mentions ODRL in passing.

Dataspaces use odrl:Offer and then a very simple "contract negotiation" protocol. Please add an example along these lines:
https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/contract-negotiation/contract.negotiation.protocol

[joshcornejo]

There is a step between ODRL and FIBO that I've raised from some work I did a couple of years ago.

I am unsure what "add an IDS example" means for DPROD?

IDS' state machine is defining commercial steps, whilst odrl has odrl:Offer (what a supplier brings to the market), odrl:Request (what a consumer would want) and odrl:Agreement (a successful engagement between supplier and consumer).

odrl:Request     -> REQUESTED
odrl:Offer       -> OFFERED
odrl:Agreement   -> ACCEPTED
                 -> AGREED
                 -> VERIFIED

Not explicitly covered:
- FINALIZED
- TERMINATED

Due to the nature of a lot of entitlements, those not explicitly covered should be 'programmatically' included in a policy (for example using dates (valid until "datetime lteq A:B:C") or events (ex:cancellation) to determine when the policy stops being active for evaluation).

PS. From what I've read (I am an observer at both Gaia-X and IDS), IDS "hacks" a bit of DCAT and ODRL (for example, only using JSON with the policy always as part of the payload of the asset and prescribing the definition of an asset inside the policy).

[VladimirAlexiev]

@joshcornejo

IDS' state machine is defining commercial steps

That's just the first section. Subsequent sections also define data models for offer, agreement, rejection...
I'm not saying DPROD should mess with overly DSP-specific classes like dspace:ContractAgreementVerificationMessage.
But DPROD should use ODRL, not just mention it.

And should mention and add links to relevant DSP sections.

IDS "hacks" a bit of DCAT and ODRL

I couldn't agree more. And if you look under the hood into things like Eclipse Dataspace Components, you get the feeling their devs haven't used sem tech much :-(

[joshcornejo]

@VladimirAlexiev I spent part of June looking at their implementation to start and then i walked backwards to the documentation ... it might be good for a PoC, but won't implement the full specifications for DCAT nor ODRL.

Do you mean something like this:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix md: <https://o.marketdata.md/ns/01/>.
@prefix odrl: <http://www.w3.org/ns/odrl/2/>.
@prefix terms: <http://purl.org/dc/terms/>.
@prefix time: <http://www.w3.org/2006/time#>.
@prefix xml: <http://www.w3.org/XML/1998/namespace>.
@prefix dcat: <http://www.w3.org/ns/dcat#>.
@prefix dprod: <https://ekgf.github.io/dprod/>.

md:URI_225b96258645_______13275A terms:created "2024-02-20T09:45:35.0000000Z"^^xsd:dateTime;
                                 terms:description "velit laboris ad irure excepteur veniam do tempor minim qui commodo do irure aliquip esse Lorem ad duis voluptate duis Lorem ullamco fugiat laborum proident anim nulla occaecat adipisicing anim occaecat deserunt veniam ex dolore duis occaecat qui deserunt cupidatat laborum non amet magna laborum aute elit aliqua consequat nostrud"@en;
                                 terms:valid md:URI_225b96258645_______13275I;
                                 a odrl:Asset,                                      # ODRL
                                   dprod:DataProduct;
                                 odrl:partOf md:URI_225b96258645_______13148A;      # ODRL
                                 odrl:hasPolicy md:policy_one;                     # ODRL Policy
                                 dprod:inputDataset md:output_dataset;
                                 dprod:inputPort md:input_dataservice;
                                 dprod:outputDataset md:input_dataset;
                                 dprod:outputPort md:output_dataservice;
                                 dprod:productionProcessDescription "some text about production process";
                                 md:category md:finance;
                                 md:publicName md:example_dprod.
md:URI_225b96258645_______13275I a time:ProperInterval;
                                 time:after "2024-02-20T10:34:55.0000000Z"^^xsd:dateTime;
                                 time:before "2024-02-20T10:40:55.0000000Z"^^xsd:dateTime.

[VladimirAlexiev]

@joshcornejo something alike...

But does the agreement apply to dprod:DataProduct, or to md:output_dataservice?

If you have another DataProduct with different inputs, that

• produces the same DataService
• or adds another chunk of data to the same DataService

then can someone consume one DataProduct but not the other?
Can you containerize the access to the DataService to consume only some of the DataProducts that may be present there?

[VladimirAlexiev]

@joepvgenuchten Does this relate to your concern in #76 ?

[joshcornejo]

If you look at ODRL, the references are via rules, policies are just "semantic bags".

ex:rule odrl:target md:URI_...13275A

I would expect that odrl:hasPolicy md:policy_one means that at least one rule in md:policy_one targets odrl:target md:URI_...13275A (md:policy_one is a test policy for many things, including md:URI_...13275A).

I would expect that (if required) md:output_dataservice has also an odrl:hasPolicy (could be the same policy, just different rules applied will have odrl:target md:output_dataservice depending on the service designer's requirements). md:output_dataservice will also have a odrl:hasPolicy md:policy_one (if it is the same policy or otherwise a different reference).