DSP agreement timestamp is a string instead of an object

[matgnt]

EDC uses a string timestamp instead of an object.
I opened the discussion here:

International-Data-Spaces-Association/ids-specification#132

Just a head-up. In case this is jsonld related, I also expect this to be profiled as with the other topics here:
International-Data-Spaces-Association/ids-specification#125

meaning, it will be required to be an object like:

"dspace:timestamp": {
      "@value": "2023-01-01T01:00:00Z",
      "@type": "xsd:dateTime"
    }

as it is right now in the DSP spec text and examples.

--
Matthias Binzer

[jimmarino]

I don't think the @type value is required since Json-Ld does not mandate explicitly typing nodes (which would also include strings). During expansion, the @type may be added to the result, see Type Coercion

[matgnt]

@jimmarino I think we should have this discussion in the DSP spec issue:
International-Data-Spaces-Association/ids-specification#132

The issue here is meant more as a heads-up, that there is potential that this might change. As mentioned, all examples in DSP spec look different to what EDC delivers right now. And this is probably again an jsonld topic.

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.