On the call of 2018-12-14, we discussed (briefly) #20, #98, and #86. One realization that came out of the discussion was that we currently have two ways to refer to contexts - either by references as a single string (the URI of the context) or by value as a JSON object (the actual context). In order to have in-document metadata about the context, such as asserting fixity such as via the SRI specification, we would need to have a URI with additional metadata about it.

Questions that arise:

• How to distinguish between a context by value JSON object and a context by reference with metadata JSON object?
• As the version is in the context, and this functionality is only version 1.1, how would we signal the processing requirement - some sort of transclusion within a context that has the version?
• Are metadata properties extensible or fixed in the specification? If they're extensible, we would need some sort of meta-context wherein the mapping is asserted. If they're fixed, we would need to be very careful to accommodate the various use cases otherwise the tendency will be to simply add in new keys regardless and hope for the best.

For example:

{
  "@context": [
    "https://example.com/context-by-reference",
    {"id": "@id"},
    {"@version": 1.1, "@context": "https://example.com/context-with-metadata", "@sri": "sha256-abcd"}
  ]
}