Potential mismatch between DSP specification and current implementation in payloads/responses

[SebastianOpriel]

When having a look at the specification here or here (other places might also be affected) and comparing it to the implementation of the catalog request type / catalog context I doubt there might be a mismatch at least for

• @type: CatalogRequest vs. CatalogRequestMessage
• @context: https://w3id.org/dspace/v0.8/ or https://w3id.org/dspace/2024/1/context.json vs. https://w3id.org/dspace/v0.8/context.json

I cannot tell yet if only the docs are affected or the requests/responses itself area affected.

Credits for identifying this go to @VladimirAlexiev who analyzed it here based on EDC v0.2.1.

[jimmarino]

We are aware of these and a number of other mismatches with the DSP specification. There will continue to be mismatches as the specifications are a work-in-progress.

Alignment will be done in conjunction with the effort to pass the DSP TCK. This work will be undertaken by the committers to ensure backward compatibility with the current protocol support, if possible.

[VladimirAlexiev]

profiling (restricting) both DCAT and ODRL

It is already rather restricted

in favor of interoperability

You want to throw away the RDF representation, and you think you are doing a favor to interoperability? The temerity!

removing the requirement to process DSP messages as Json-Ld.

All DSP metadata is built on top of ontologies. Before I believe this, I'd like to see an official statement from IDSA that they are giving up on semantics

This approach is consistent with the one adopted by the VC Data Model 2.0 specification.

Yeah? But their payloads are valid JSON-LD, and yours are not.

moving target... working on TCK

Sorry, but these are poor excuses. You don't comply with the protocol , and I see no evidence that the protocol has evolved from allowing incorrect properties, namespaces and URLs to being more strict.

The lack of TCK is not a valid justification against specific bug reports. Either the reports are correct (and then fix the bugs) or they are wrong (but prove it so).

[VladimirAlexiev]

Your own spec:
https://github.com/eclipse-dataspace-dcp/decentralized-claims-protocol

The Json-Ld context is designed to produce message serializations using compaction that validate against the Json Schema for the given message type. This allows implementations to choose whether to process messages as plain Json or as Json-Ld and maintain interoperability between those approaches. 

I completely agree with this approach (but you may also need to use a Frame for mote precise layout)..

There are many communities that want to use JSON Schema to regulate their exchanges, yet put a context on top to also define the meaning of their terms in a global way, and to be able to use semantic technologies if they choose so (eg SPARQL is very useful for complex data like AAS).

But I disagree with throwing JSON-LD out: why do you want to do this?

[paullatzelsperger]

@VladimirAlexiev without going into specifics, please check your tone, this is completely unprofessional and uncalled for.
We are saying we are aware of the discrepancies, and we are working on it. You are free to raise as many issues as you like, so long as you base them on latest connector versions.

I will close this discussion down, as it has veered off into a fruitless direction.

[jimmarino]

profiling (restricting) both DCAT and ODRL

It is already rather restricted

in favor of interoperability

You want to throw away the RDF representation, and you think you are doing a favor to interoperability? The temerity!

The DSP specification will promote interoperability between DSP implementations. The message types will be defined using Json-Schema. Interoperability will be guaranteed by a TCK that is already underway. You may not like this approach, and you are free to argue your point with the Eclipse DSP project committers, who decided this direction. However, please avoid hyperbole as it does not advance the discussion here.

removing the requirement to process DSP messages as Json-Ld.

All DSP metadata is built on top of ontologies. Before I believe this, I'd like to see an official statement from IDSA that they are giving up on semantics

This is not the case with DSP, which is different than the old IDSA specification. Also, IDSA does not control the DSP specification. It is an Eclipse specification project governed by the DSP project committers and the Eclipse Foundation. Again, please avoid hyperbole as no one is "giving up on semantics." That is not a statement that is conducive to discussion. People are free to use whatever semantic technologies they want, but they will not be a required part of DSP.

This approach is consistent with the one adopted by the VC Data Model 2.0 specification.

Yeah? But their payloads are valid JSON-LD, and yours are not.

DSP payloads are valid Json-Ld. EDC's are as well (although there may be bugs). Please stick to facts.

moving target... working on TCK

Sorry, but these are poor excuses. You don't comply with the protocol , and I see no evidence that the protocol has evolved from allowing incorrect properties, namespaces and URLs to being more strict.

The lack of TCK is not a valid justification against specific bug reports. Either the reports are correct (and then fix the bugs) or they are wrong (but prove it so).

You are grossly misrepresenting what I said. I never argued that the EDC should ignore bug reports. Please go back and read my statement more carefully. More importantly, please adopt a professional and fact-based tone rather than heaping disparaging comments on the project committers.

[jimmarino]

Your own spec: https://github.com/eclipse-dataspace-dcp/decentralized-claims-protocol

The Json-Ld context is designed to produce message serializations using compaction that validate against the Json Schema for the given message type. This allows implementations to choose whether to process messages as plain Json or as Json-Ld and maintain interoperability between those approaches.

I completely agree with this approach (but you may also need to use a Frame for mote precise layout)..

There are many communities that want to use JSON Schema to regulate their exchanges, yet put a context on top to also define the meaning of their terms in a global way, and to be able to use semantic technologies if they choose so (eg SPARQL is very useful for complex data like AAS).

But I disagree with throwing JSON-LD out: why do you want to do this?

Again, no one is throwing out Json-Ld. Please take the time to properly understand what we are doing in DSP and DCP and ask questions rather than immediately jumping to disparaging and inaccurate comments.

[paullatzelsperger]

In addition to @jimmarino's comment I'm going to point out the obvious, which is that EDC 0.2.1 is more than a year old, and in a fast evolving environment such as this, is an eternity. I strongly urge you to upgrade to a more recent version for a myriad of reasons.

I'm sure you understand that we cannot consider any bugs reported on prior versions of EDC.

[SebastianOpriel]

I know, but I thought I liked the most recent DSP spec and code from main branch. If I am wrong here, please correct me.

[jimmarino]

The issue here is that EDC 0.2.1 is an ancient release and it makes it much more difficult for committers to sort through which are current bugs and which have already been addressed. Unfortunately, this seems to be an ongoing tendency, as a number of issues have been filed related to the 0.2.1 connector that have turned out to have been previously addressed.

Also, we highly recommend against running EDC 0.2.1 in any production (or other) environment. There have been numerous security and bug fixes, enhancements, and performance improvements that warrant upgrading.

[paullatzelsperger]

I know, but I thought I liked the most recent DSP spec and code from main branch. If I am wrong here, please correct me.

Not exactly sure what you mean. What I'm saying is that the committers won't look at any bug reports that target anything but the most recent version. If you're confident that a bug is still prevalent in the latest version, then please reproduce and file a bug report for it, but keep in mind @jimmarino's comment

[SebastianOpriel]

First 4 links of my initial message: #4624 (comment)
Just ignore the last link. But indeed maybe not worth further discussion about this topic, since in general for sure understood.

[wolf4ood]

Just as a note CatalogRequest is used in management API vs CatalogRequestMessage which is used in the DSP messagge

The EDC one is here

And the DSP one is here