3 · The five words people confuse
There's a lot of jargon surrounding Zarr, and it makes it hard to understand. This page serves to break down that jargon. In particular, we think that if you can understand 5 specific pieces of jargon (spec, implementation, store, data, and convention), you'll find it a lot easier to work with Zarr and the surrounding ecosystem.
The five words are spec, implementation, store, data, and convention.
The five words
| Word | What it is | What it is not |
|---|---|---|
| Spec | The written specification of the data model and how it maps to keys. | A library, or a file. |
| Implementation | A library that reads and writes data following the spec (for example, zarr-python). | The spec itself. |
| Store | The backend where the keys actually live: a local directory, memory, a ZIP, a cloud bucket. | The data model. |
| Data | The actual array and its metadata, encoded as key → bytes entries. | The store that holds it. |
| Convention | A community agreement layered on top of the spec for a particular domain (for example, GeoZarr). | Part of the core spec. |
Read that table twice. The pairs in the right-hand column are exactly the confusions you'll hear in the wild. For example, someone saying "a Zarr file" when they mean "the keys in some store."
One sentence to keep close
If you remember nothing else from this chapter, remember this:
The spec defines the data model (arrays, groups, codecs) and how it maps to keys. An implementation gives you an API over that model. A store is where the keys live.
Every chapter that follows is really an expansion of one clause of that sentence. Part I walks the data model and the keys. Part II walks the spec, its versions, and the conventions layered on top. Part III walks who maintains it all and the implementations built around it. When a later chapter starts to feel abstract, come back here — the sentence is the thread that ties it all together.