Summary
A workspace groups projects that share a context: the same databases, the same conventions, the same people. Everything expensive to produce — describing a source, mapping concepts, writing quality rules — lives there once and serves every project. Its Summary is the landing page someone discovering it will see.
What a workspace groups
The question to ask when creating one: what do these projects have in common? An intensive-care unit, a hospital, a multi-centre research network — the scale matters less than the sharing.
Because sharing is what justifies this level. Describing a data source, mapping local codes to a standard vocabulary, writing quality rules: this work is long, and redoing it in every project would be absurd.
The data warehouse
The connected databases and everything used to exploit them: schemas, mappings, quality rules, ETL pipelines, SQL scripts, catalog. See Data warehouse.
The projects
Each study, each monitoring programme. They draw on the workspace’s resources without duplicating them. See Projects.
The wiki
Team documentation: conventions, protocols, meeting notes. See Wiki.
The plugins
Reusable analyses, available in every project. See Plugins.
The Summary
This is the first page you see when opening a workspace, and the one a newcomer discovers. It brings together three things.
- Overview — what the workspace holds, group by group, with direct links.
- Readme — the introduction you write: what this workspace is for, who uses it, which conventions apply.
- Licence — on what terms this work can be reused, if you share it.
The readme is what travels
When a workspace is exported or published, its readme goes with it. It is often the only thing someone discovering it elsewhere will read — it deserves a few minutes.
How many workspaces?
One is often enough. You create a second when the context genuinely changes: different people, different data, or a requirement to keep things apart.
A common split
A hospital keeps a private workspace — ongoing research, identifying data, an internal git repository — and a public one where it publishes methods and results, connected to an open repository. The two share neither members nor rules.
In browser mode, no members
You can create as many workspaces as you like in the browser. What needs server mode is attaching people to them: accounts, roles and access rights only exist with a backend. Working alone on your own machine, the question does not arise — see Deployment modes.
Going further
- Workspaces and projects — why Linkr is organised on two levels.
- Members and roles — who has access to what.
- Settings — configuring the workspace.