Allow URLs other than iana.org for media types

[apdavison]

The relatedMediaType property of ContentType expects an "official" IRI. The instruction is "Enter the internationalized resource identifier (IRI) to the official registered media type (e.g., provided on IANA.org) matching this content type."

Since there are so few officially-registered media types, I propose to relax this instruction, by also allowing links to non-official-but-widely-used media types on other servers, e.g., https://mimetype.io

(See discussion in #272)

[lzehl]

@apdavison thanks for raising the issue. could we also discuss here what we expect here to enter?
I think originally "relatedMediaType" should only be filled if our content type actually is the same as the official media type. Later I think this was not really followed but loosen to be able to link to parent official media types.

Question should we be more specific here?

• delete "relatedMediaType"
• add "sameAs" (external resource link, IANA or mimetype.io)
• add "isBasedOn" (other CT, IANA or mimetype.io)

[apdavison]

it does indeed seem that in some cases "relatedMediaType" is being used to refer to parent media types (e.g. many JSON-based formats link to the "application/json" IANA page). I agree about adding a new property called "isBasedOn" (or "isSpecializationOf", to be more specific about the relationship). However, this property should have "_linkedType": "ContentType".

We can then clean up "relatedMediaType" to only point to external definitions of the content-/media-type, expanding the allowed destinations to include mimetype.io as well as iana.org. I'm ok with renaming this to "sameAs", although this would be more work for migration.

[lzehl]

let's definitely keep this for v5.0

[lzehl]

• rename relatedMediaType to authoritativeSource and make it an array of IRIs; this is only to be used when external (official) source(s) define/describe the same content type.
• add property isBasedOn and make it an array of linked ContentType

@apdavison @Raphael-Gazzotti would you agree?

[Raphael-Gazzotti]

I agree with this approach, it preserves also the option to use sameAs for our internal versioning if needed.

[lzehl]

@Raphael-Gazzotti I can do the PR for schema update. I can let you know if I need help with the instance update (regarding property renaming not value cleanup; the latter we can tackle after the v5.0 release)

[lzehl]

Note: maybe authorativeSource is not fitting since mimetype.io is not an authoritative registry. I used now definingSource.