What should the best practices be about?

[arnoweiss]

The best-practises document should give those implementing/profiling the DSP a starting point on how to do so. The DSP itself doesn't solve any particular business problem - that only becomes viable by extension with other protocol.

Things that I'd like to see in the DSP Best Practices:

1. How to specify side-effects: State transitions may trigger actions in a ParticipantAgent that transcend the scope of the DSP. This document should give examples on how that can happen.
2. Profiling DSP messages: A dataspace will usually have conventions on restricting a certain property that the DSP uses. For example the dspace:participantId, consumerId, providerId may have to follow a certain regex.
3. Extending ODRL: odrl:Constraints carry the semantics that define the legal terms of data exchange. This should be made clear and be advertised as an essential adaption point.
4. Defining extension points: As the spec does not handle transfer of business data, Dataspaces should be assisted with what they have to agree on to make that happen. Likely, this requires defining for instance dct:format for push- and pull-transfers

Please feel free to comment on the points above. If generally accepted, I'll create separate Issues for them. New ideas are obviously welcome as well.

[lgblaumeiser]

Concerning 2: Having a clear format definition, that could lead to a RegExp or similar validation means makes sense. The question is, that I would see a best practice after our exercise, whether a best practise for DSP is, that if combined with DCP, a did is a best practice to be used as identifier. Coming from a layered structure, that would perhaps be a best practice for the DCP application.

Concerning 3: Best practices on the whole profiling for a data space including ODRL makes sense. The value comes with the legal clarifications behind the ODRL profile. That could be a bit hard to provide on that technical level.

[juliapampus]

I would like to link to the "old" best practices discussion: International-Data-Spaces-Association/ids-specification#104

I'm fine with 1 and 4.

2. We agreed in the past that DSP messages must not be profiled. Thus, defining the syntax of a property may be a recommendation by a specific dataspace but nothing that is part of the DSP or requested by the DSP as best practice.

3. This should be nothing more than referring to the ODRL documentation. It is not our job to explain how to profile another spec. We must preassume a fundamental knowledge of ODRL.

[lgblaumeiser]

Concerning 2, a best paractice is a best practice, it describes experience in the usage. It is not binding and a prescription for the usage. If we want to foster interoperability between different data spaces, the DSP is not enough, so some recommendations on the main stream application imho makes sense.

Concerning 3, my understanding of this point is, that it should point out the what and why of semantically defining the constraints possible for a data space. The documentation is then the how, or do I miss something here?

[juliapampus]

so some recommendations on the main stream application imho makes sense

It should not be a recommendation to profile the dspace messages. If they are missing major information, they have to be changed. If a dataspace needs more information for basic communication flows, apart from additional properties, I would question the modelling, and clearly state that modifications are a risk for inter-dataspace interoperability. (When talking about messages, I don't mean the catalog or policy entities but the messages.)

it should point out the what and why of semantically defining the constraints possible for a data space

My thoughts on this: ODRL has nothing to do with dataspaces. This may be new information for some readers of the spec... The described data usage conditions have to also be enforced outside of a dataspace. Thus, in fact, every extension of ODRL is allowed - as long as agreed upon. Talking not only about LeftOperands and RightsOperands... From a technical perspective, there are no "typical constraints for data spaces". The semantic definition of rules like proving membership or identities should be part of a dataspace rulebook not communication spec like the DSP. I know this is a really simplified view, intentionally. I am totally fine with including a section highlighting the extensibility of ODRL, but it shouldn't be more than that. This would be more than a technical recommendation of the usage of the protocol.

[arnoweiss]

This is executed on as an initial contribution and will be iterated upon.