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. A header card gives its name, its description and the organization behind it; three tabs follow.
ICU — University Hospital
The ICU team's shared warehouse: databases, mappings and ongoing studies.
Rennes University Hospital
HospitalReadme
ICU workspace
This workspace gathers the team's work. Before you start, read the “Conventions” wiki page.
- Main database: the unit's OMOP warehouse
- Demo data: MIMIC-IV
Recent projects
6Wiki
14Plugins
1Schemas
1Databases
2Recent mapping projects
1Script Collections
0None yet
Data Quality
1Data Catalog
1ETL Pipelines
16
Projects
2
Databases
1
Mapping projects
14
Wiki pages
- Overview — a preview of the readme, and for each of the ten kinds of item — projects, wiki, plugins, schemas, databases, mappings, scripts, quality, catalogs, ETL pipelines — the most recent ones, with a View all link.
- Readme — the introduction you write: what this workspace is for, who uses it, which conventions apply. Attachments — an image, a diagram — can illustrate it.
- License — on what terms this work can be reused, if you share it. See Publishing content.
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.