the two contexts are not used in the ontology; ensure stable URL, updatability, content type

[VladimirAlexiev]

If you look at the uncefact and unlocode ontologies:

curl https://vocabulary.uncefact.org/ -H 'Accept: application/ld+json'
curl https://vocabulary.uncefact.org/unlocode# -H 'Accept: application/ld+json'

both use inline contexts (that define a few prefixes), and don't use the respective contexts, which are:

• unece-context.jsonld
• unlocode-vocab-context.jsonld

Then what is the purpose of these dedicated (network-available) contexts?
Are they to be used in instance data only?
How do you guarantee that the inline and network contexts are in sync (I think they are not)?

Pros for using network contexts:

• the contexts will grow in the future, to specify which prop is a URL (@id) and which is datatyped (eg xsd:boolean, xsd:float)
• while adding a hefty context to an ontology that's already much bigger is not a big deal, adding a few kB of context to every instance file is a big deal and should be avoided

Requirements for using network contexts so they can be used eg on the JSONLD Playground:

• they must be available at a stable network location (because the URL will be embedded in thousands of instance files)
• the location must be updated as soon as the source file is updated
• they must be served with appropriate Content-Type