Json-ld compacting - dspace namespace versions

[IgorBalog-Eng]

Hello EDC team,

We are using latest Samples (edc v0.10.0) to test connector interoperability.
Known impediment we have is related with json-ld compaction. We are expecting that some elements in the catalog are as arrays, and we managed to “solve” this by passing json-ld received from EDC through json-ld parser, and outcome is acceptable and we can deserialize string to java object.

Following changes are necessary: we must set output context to be like:

{
  "@context" : https://w3id.org/dspace/2024/1/context.json
}

While EDC Samples sends

{
"@context": {
               "@vocab": https://w3id.org/edc/v0.0.1/ns/,
               "edc": https://w3id.org/edc/v0.0.1/ns/,
               "dcat": [http://www.w3.org/ns/dcat#](http://www.w3.org/ns/dcat),
               "dct": http://purl.org/dc/terms/,
               "odrl": http://www.w3.org/ns/odrl/2/,
               "dspace": https://w3id.org/dspace/v0.8/
}
}

From inspecting EDC connector code, we noticed that in latest version (tag 0.10.0) and main branch you have dspace name for
"dspace": "https://w3id.org/dspace/2024/1/",
But for some reason we still keep getting v0.8.
Samples project, libs.versions.toml - edc = "0.10.0"

Another problem is that EDC cannot process following message:

{
               "@context": https://w3id.org/dspace/2024/1/context.json,
               "@type": "dspace:ContractAgreementMessage",
               "dspace:agreement": {
                              "@id": "urn:uuid:63e3154e-4244-44e4-ba65-5e239b9d34af",
                              "dspace:timestamp": "2024-11-04T12:38:19.3579303+01:00",
                              "odrl:assignee": "TRUEConnector v2",
….

With following error printed in terminal:
←[0;34mDEBUG 2024-11-04T12:38:53.701707 DSP: Incoming ContractAgreementMessage for class org.eclipse.edc.connector.controlplane.contract.spi.types.negotiation.ContractNegotiation process: 09b9c450-f978-43df-a5b5-6e292e8a9041←[0m
←[0;34mDEBUG 2024-11-04T12:38:53.7027082 DSP: Validation failed: [@type was expected to be https://w3id.org/dspace/v0.8/ContractAgreementMessage but it was not]←[0m

When we tried to use “older” context (for testing purposes) we have such error message in EDC console:
←[0;33mJsonLdError[code=There was a problem encountered loading a remote context [code=LOADING_REMOTE_CONTEXT_FAILED]., message=There was a problem encountered loading a remote context [https://w3id.org/dspace/v0.8/context.json]]
….
Caused by: JsonLdError[code=The document could not be loaded or parsed [code=LOADING_DOCUMENT_FAILED]., message=URL scheme [https] is not supported.]
at com.apicatalog.jsonld.loader.SchemeRouter.loadDocument(SchemeRouter.java:59)

Once expanded, context https://w3id.org/dspace/2024/1/context.json should be the same like EDC v0.10.0 uses (from looking at code) but for some reason Samples returns dspace v0.8 value.

https://github.com/eclipse-edc/Connector/blob/v0.10.0/extensions/common/json-ld/src/main/resources/document/dspace.jsonld#L11
https://github.com/eclipse-edc/Connector/blob/v0.10.0/extensions/common/json-ld/src/main/java/org/eclipse/edc/jsonld/JsonLdExtension.java#L99

Can you provide me with hints/instructions how to proceed with this situation? Is this something that EDC team knows about?
If you need any additional information, I will provide it in comments.

Kind regards
Igor

[jimmarino]

This is just a higher-level comment. If you are attempting to work on DSP interoperability, I would not do this directly against EDC, as it won't guarantee correct behavior. Right now, EDC is in the process of conforming to the DSP specifications, which are themselves still evolving. This means the EDC DSP behavior will change over the next months.

Instead, I would focus on conformance to the DSP specifications. There is a TCK that is being built for exactly this purpose. The TCK itself is incomplete and not yet released, so is available on a self-help basis (i.e. no support). However, it may be worth looking at to get an idea of how DSP will handle the question of interop. Note that there are also a number of things in the TCK that need to be updated, including the namespace issue.

[IgorBalog-Eng]

Thanks Jim for the update.
We will keep then with following protocol, and once TCK or EDC are close to the DSP protocol, we will check interoperability. Doing anything different than that, will be chasing the moving target.
If time and resources allow, we will check TCK.