@context registration / versioning for RDF persistence

Hi list,

Related to a general json-ld issue
<https://github.com/json-ld/json-ld.org/issues/540> with multiple embedded
@context processing in deserialization to RDF, I have considered a rough
idea that may work as an alternative than the current technique where every
time the processor reads an @context IRI, it must dereference it.[1]

The idea is to instantiate a node(s) in the document that persists in toRDF
deserialization that contains an @context ETag value, a domain (or package)
API name, and a commit/SHA-1/MD5 hash (if available).  Centralized context
repositories could be administered by API providers so that document models
that may require multiple or embedded remote contexts could also nest them
as single managed resources, that would need be served *only once* to a
processor, that could validate the document context properties to the
remotely served context repository resource, and only retrieve it if
necessary.

@context IRI as a document dependency is somewhat problematic.
1. it can not be round tripped toRDF and back to JSON-LD
2. there is no "built in" versioning mechanism
3. it breaks the encapsulation of a service API by necessitating that the
client has foreknowledge of its resource identities and locations.
4. if a document contains many remote contexts, deserialization is
inefficient (unless the client maintains a local cache).

In a way, I see this as a kind of Maven Central/NPM only for JSON-LD
@context.  This functionality would be supplemental to existing processor
deserialization methods, and could be triggered with an option.  I am not
yet convinced that it is worth the complexity, but it would definitely
ensure that @contexts are served consistently (and legitimately) and
processed efficiently.

Christopher Johnson
Scientific Associate
Universitätsbibliothek Leipzig

[1]
https://json-ld.org/spec/latest/json-ld-api/#context-processing-algorithms