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
Note: I am not sure whether we already talked about this behavior. And it may also be obsolete by providing the schemas as proposed by #50.
Describe the Bug
For alle JSON snippets (in examples and protocol/binding documents), we set the dspace prefix not only in the key but also for the value. For example:
"dspace:eventType" : "dspace:FINALIZED"
This (1) causes JSON-LD processors to wrongly expand/compact messages and (2) does not align with the JSON-LD specification. As stated in the JSON-LD specification (Value Objects, Value Compaction, Value Expansion):
While expanding, values of non reserved keys won't be checked for terms which therefore won't be mapped to it's corresponding IRI.
While compacting, the "@value" of a JSON-LD value object must be a string, number, boolean or null. So if it includes terms or IRIs this is just handled as string.
Type: normative (as no only included in example messages, but also the binding specs)
Expected Behavior
No room for interpretation on how values are handled; not by recommending an interpretation for implementations but by using the JSON-LD specification correctly.
Observed Behavior
Implementations that follow the JSON-LD specification won't process the value durig expansion/compaction while other implementations could interpret the DSP differently. At the moment, implementations would need to cover both cases to enable interoperability.
Detailed Description
A minimal example from an JSON-LD online tool visualizes the handling of the value as a string following the JSON-LD specs (see above):
Bug Report
Note: I am not sure whether we already talked about this behavior. And it may also be obsolete by providing the schemas as proposed by #50.
Describe the Bug
For alle JSON snippets (in examples and protocol/binding documents), we set the
dspace
prefix not only in the key but also for the value. For example:This (1) causes JSON-LD processors to wrongly expand/compact messages and (2) does not align with the JSON-LD specification. As stated in the JSON-LD specification (Value Objects, Value Compaction, Value Expansion):
Type:
normative
(as no only included in example messages, but also the binding specs)Expected Behavior
No room for interpretation on how values are handled; not by recommending an interpretation for implementations but by using the JSON-LD specification correctly.
Observed Behavior
Implementations that follow the JSON-LD specification won't process the value durig expansion/compaction while other implementations could interpret the DSP differently. At the moment, implementations would need to cover both cases to enable interoperability.
Detailed Description
A minimal example from an JSON-LD online tool visualizes the handling of the value as a string following the JSON-LD specs (see above):
Possible Implementation
Remove the
dspace
prefix from the values, e.g.: