• Currently we rely on defaulting so that our JSON-LD file can be small.
• The context doc is available by content negotiation from http://schema.org/ or directly ivia http://schema.org/docs/jsonldcontext.json
• Doing this means that there can be interactions with other JSON-LD vocabularies e.g. extensions, when multiple extensions are in play.
  • Example 1: "@context": [ "http://schema.org/", "http://foo.example.org/" ]
  • Example 2: "@context": [ "http://foo.example.org/", "http://schema.org/" ]

In the current situation where we list only @id-typed and datatyped (e.g. DateTime) properties, other terms such as literal-valued properties, types, enumerated values are not explicitly "claimed" by schema.org. In the case of e.g. 2 above, that is OK. In the case of e.g. 1 above, a declaration of @vocab within foo.example.org's JSON-LD context file will "claim" all the non-explicit schema.org terms, so that Person will expand to http://foo.example.org/Person instead of http://schema.org/Person etc.

By making schema.org's context list everything, we allow instance data and external context authors to choose how to mix and superimpose it with other vocabulary.

<- this is my understanding of the situation at least, but am open to corrections. --@danbri