Decision Proposal on normative Relations between IDS-Specification and Information Model

[sebbader-sap]

We need a documented decision how the content of the protocol specification and other IDS resources, in particular the Information Model, play together. We need to agree which resource is dependent on which so that we do not cause any side-effects.

[sebbader-sap]

Let me start a list of "requirements" or "to become agreed statements":

1. The protocol specification from this repository is the leading normative one, therefore all other resources have to stay compliant to its restrictions. In particular: 1.1. identifiers of terms are not changed, 1.2. no new identifiers for already existing terms are introduced anywhere else, and 1.3. no additional restrictions are introduced.

2. IDS compliant data objects (policies, messages etc.) which pass the schemas of the protocol specification are "compliant". If a schema validation fails, the data object is not part of the normative content of IDS/DS.

[jimmarino]

Some more requirements:

1. The DSP specifications are the only normative content.
2. All concepts, including the information model, must be defined in the specification and based on normative statements.
3. No other IDS resource may introduce normative requirements or concepts to the protocol specifications.
4. Resources and content outside the specifications may not use the core DSP namespace or derivatives.
5. Compliance will be based on the normative schema definitions contained in the specifications.
6. Message and policy types may not be extended and considered compliant with the specifications.

[sebbader-sap]

4. Resources and content outside the specifications may not use the core DSP namespace or derivatives.

I slightly disagree, I think were is an option where external resources (I call them (RDF) documents but 'document' in the sense of a web resource, not a Word document) provide additional, informative attributes. For instance, adding a longer description or providing rdfs:comment in additional languages.

[sebbader-sap]

2. All concepts, including the information model, must be defined in the specification and based on normative statements.

I think it would help if we have different names for the different things. Proposal: IDS Information Model: Everything provided at https://github.com/International-Data-Spaces-Association/InformationModel Dataspace Vocabulary: Everything provided at https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/model/terminology.md (I don't like my proposed name either, let's find something more speaking)

[jimmarino]

4. Resources and content outside the specifications may not use the core DSP namespace or derivatives.

I slightly disagree, I think were is an option where external resources (I call them (RDF) documents but 'document' in the sense of a web resource, not a Word document) provide additional, informative attributes. For instance, adding a longer description or providing rdfs:comment in additional languages.

By "use" I mean not "refer to" but "include". For example, if create a specification that defines additional properties that are included in the DSP namespace.

[jimmarino]

2. All concepts, including the information model, must be defined in the specification and based on normative statements.

I think it would help if we have different names for the different things. Proposal: IDS Information Model: Everything provided at https://github.com/International-Data-Spaces-Association/InformationModel Dataspace Vocabulary: Everything provided at https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/model/terminology.md (I don't like this one either, let's find something more speaking)

I like the separation of "Dataspace Protocol Specification" vs. "IDS" but we should be clear that "DSP" has no reliance on "IDS" and the two are distinct things.

[sebbader-sap]

@hosseinzadeha @Brandstaedter please check the discussion above and add your point of view.

[hosseinzadeha]

The Usage Control concepts introduced in Eclipse Dataspace Components or DSP is different from what was initiated and proceeded in International Data Spaces. However, the common ground has been developed in the context of the International Data Spaces. So, stating that there is no reliance is probably not completely right. After all, if you are willing to rework some concepts as part of the specification protocol and not rely on the IDS information model, then our input would not be required anymore. IDS Usage Control document, ODRL profile for IDS, IDS policy templates and IDS PAP are available, though.

As we are occupied with other projects, please be aware that our response time may be delayed.

[sebbader-sap]

Summarizing from the call today: As the discussion in this issue has been stale for more than a month, we assume that there is no principal objection against the points above.

Proposal: Until no other formal decision has been made, we as a community accept the statements for the scope of the Dataspace Protocol. Previous IDS versions, and data spaces using them, are of course relying on, e.g., particular versions of the IDS Information Model. Accepting the above statements does with no means indicate that established data spaces must change/update. However, for the current specified Dataspace Protocol and its parallel activities, the DSP is the leading truth with the requirements written above.

@ssteinbuss: We want to wait for your opinion before doing anything with this ticket (e.g. closing it).

[juliapampus]

Addressed with #149