feat: Remove Json-Ld requirement for version endpoint and add version schema

[jimmarino]

What this PR changes/adds

We can't version the version endoint. Therefore, we need to remove the Json-Ld requirement.

Linked Issue(s)

Closes #37

[mkollenstart]

In order for me to clearly understand this. Removal of the JSON-LD context for the version metadata is primarily in order to ensure stability of the version metadata, as this spans multiple versions in one go. Therefore it might introduce issues when the context changes over the versions?

If that is the case, should we then include the version of the JSON schema? This might introduce issues when we actually want to change the schema of the version metadata.

[jimmarino]

In order for me to clearly understand this. Removal of the JSON-LD context for the version metadata is primarily in order to ensure stability of the version metadata, as this spans multiple versions in one go. Therefore it might introduce issues when the context changes over the versions?

If that is the case, should we then include the version of the JSON schema? This might introduce issues when we actually want to change the schema of the version metadata.

Yes, exactly. Do you have a proposal for including the schema version? I can adapt the PR to include it.

[mkollenstart]

In order for me to clearly understand this. Removal of the JSON-LD context for the version metadata is primarily in order to ensure stability of the version metadata, as this spans multiple versions in one go. Therefore it might introduce issues when the context changes over the versions?
If that is the case, should we then include the version of the JSON schema? This might introduce issues when we actually want to change the schema of the version metadata.

Yes, exactly. Do you have a proposal for including the schema version? I can adapt the PR to include it.

What we might do is require the $schema field to be set on the version metadata. This way the provider of the metadata can indicate with which schema the document should be validated. To prevent the client to have to guess which schema to use.
Like:

{
  "$schema": "https://w3id.org/dspace/2024/1/common/version-schema.json",
  "protocolVersions": [
    {
      "version": "1.0",
      "path": "/some/path/v1"
    }
  ]
}

We still then have to take care of ensuring the schema is stable, perhaps by using deprecated (https://json-schema.org/draft/2019-09/json-schema-validation#rfc.section.9.3) to ensure the main properties are stable over multiple versions.

[jimmarino]

@mkollenstart Do you want to file a separate issue so that we can explore this in more detail? If you are OK with that approach, should we merge this?

[jimmarino]

@mkollenstart I'm going to merge this and we can file a separate issue.