Context architecture - patterns and antipatterns, or convenience packages?

[rob-metalinkage]

Struggling to understand why context documents seem to be ad-hoc mixtures of common terms from various vocabularies without some overarching rationale for this pattern.

I would expect and hope (and publish!) contexts that match the governance domains of the underlying vocabularies - hence a context for DCTerms, one for SKOS, etc.

This doesnt preclude creating minimal bundles of bits of these such as the recommended context for RDFA, - to express specific profiles of the underlying vocabularies for use in a given appkication domain, but cannot this be made explicit? And what can we do to have canonical, normative contexts for the same ontology building blocks we use for data models?

[pchampin]

Doing some cleanup in my huge backlog, this issue popped back in my radar! Thanks @rob-metalinkage for raising it.

In my view, there are many different use-cases for contexts. The kind of contexts you would expect (vocabulary driven or profile driven) cover some use-cases – mostly for people starting with linked data. The other kind of contexts ("ad-hoc mixtures of common terms from various vocabularies") are still useful to "lift" legacy JSON formats into linked data.

I believe both kinds are valid. But I agree that a more explicit "typology" of contexts, and a set of good and bad practices for each kind, would be helpful.