search

International-Data-Spaces-Association / ids-specification

The Dataspace Protocol is a set of specifications designed to facilitate interoperable data sharing between entities governed by usage control and based on Web technologies. These specifications define the schemas and protocols required for entities to publish data, negotiate Agreements, and access data in a data space
https://docs.internationaldataspaces.org/dataspace-protocol/
Apache License 2.0
30 stars 14 forks source link

Introduce best practices document #104

Closed juliapampus closed 10 months ago

juliapampus commented 1 year ago

Following ODRL best practices, we should add a document that briefly explains how the protocol could/should be used and how it could be extended, state machine- or vocabulary-wise (on an abstract level). This will help people to understand the intention and scope of these documents beyond the basic README.md.

Possible ToC:

jimmarino commented 1 year ago

There appear to be a few issues here:

  1. A primer covering the DSP protocol
  2. The process for writing binding specifications
  3. How to "extend" the DSP protocol

Point 1 could be done by the RAM or another set of documents and they should be explicitly non-normative. @PeterKoen-MSFT, what do you think?

Point 2 is important, but I don't think we should define it at this point because that process will depend on the standards body we submit the current specifications to.

IMO we should never define #3. Conformant implementations are not required to support extending the protocol with custom messages or types, and that touches too much on specific implementation details. It will also break interoperability. If people want to "extend" the protocol, they should create overlay or derivative protocols outside the requirements of the core specifications in a different working group.

Implementations should also not be required to support human workflows. The only capability they should be required to support is the asynchronous messaging specified by the protocol.

Note that this is different than saying people should avoid developing policy or catalog vocabularies. We don't need to do anything, as ODRL and DCAT already define ways of doing this.

PeterKoen-MSFT commented 1 year ago

Point 1 could be covered in the introductory chapters of the new RAM that we are planning and where work will kick off after the summer. It would be a great intro to position the possibility of implementing many different solution architectures and business models on top of the DSP. @ssteinbuss may I ask you to add this to the backlog for the Architecture WG.

On Point 3: I believe that a lot of people wish to extend the protocol because there isn't enough understanding of how their scenarios can be covered by adding vocabularies for policies, data plane selection, etc... This is definitely something where we should consider writing a document. @ssteinbuss is this something that you would like to see in the RAM as well? It could be both: part of the introduction, as well as a closing chapter giving outlook on how to extend the base model to custom solutions.

gbrost commented 1 year ago

I would really like to see good practices how to embed the protocol in real data space implementations. This should include

ssteinbuss commented 1 year ago