Linkr
Home Resources Tools Documentation Blog Demo
FR
  • What is Linkr?
  • Deployment modes
  • Quick start
  • Local install
  • With Docker
  • Manual install
  • Client-only
  • Your first project
  • Workspaces and projects
  • The data pipeline
  • Entities and sharing
  • Versioning and collaboration
  • Overview
  • Projects
  • Wiki
  • Plugins
  • Members and roles
  • Settings
  • Schemas
  • Databases
  • Derived sub-databases
  • Data quality
  • Data catalog
  • SQL script collections
  • ETL pipelines
  • Overview
  • Mapping projects
  • Global view
  • Target concepts
  • Mapping editor
  • Suggestions
  • Evaluation
  • Export
  • Overview
  • Concepts
  • Cohorts
  • Patient data
  • Pipeline
  • Datasets
  • IDE
  • Web apps
  • Versioning
  • Overview
  • Tabs and widgets
  • Built-in widgets
  • Analysis widgets
  • Control charts (SPC)
  • Surveys and eCRF
  • R and Python code
  • Filters, settings and export
  • Overview
  • Presentation mode
  • Exporting a report
  • Agents
  • Model providers
  • Skills
  • Authoring through MCP
  • Import and export
  • Git versioning
  • Community catalog
  • Publishing content
  • Production install
  • Configuration
  • Authentication and permissions
  • Files on the server
  • Backup and restore
  • Glossary
  • Keyboard shortcuts
  • Release notes
Documentation Sharing and catalog Community catalog

Community catalog

Browsing and installing projects, schemas, mappings and rule sets published by other research teams.

In short

The catalog is Linkr’s shared shelf: projects, schemas, concept mappings and quality rules published by research teams. It is a directory of git repositories — each entry points at one, and installing it amounts to cloning it. Browsing works everywhere, including in the browser; installing needs server mode.

Client Not available in client-only mode — this feature requires a backend. Backend Available with the FastAPI backend.

The badge refers to installing, which needs a server. Browsing the catalog works in both modes.

What it is for

A great deal of health-data work is redone identically from one institution to the next: describing a MIMIC database’s schema, mapping local codes onto a standard vocabulary, writing the quality checks for an OMOP warehouse. It takes time, and it is the same work everywhere.

The catalog answers that. One team publishes its schema, its rule set or its whole project to a git repository, declares that repository to the catalog, and the others install it in one click to start from there.

Two catalogs, not to be confused

The community catalog, described here, indexes Linkr entities to install. The data catalog documents a warehouse’s variables: what each field means, where it comes from. Neighbouring names, unrelated purposes.

Getting there

The catalog is a top-level sidebar entry, Catalog, next to Home and Workspaces. It belongs to no workspace: it is a resource of the whole installation.

On a first visit it does not load by itself. A Catalog not loaded screen invites you to click Load catalog, naming the server that will be contacted.

Why that explicit click

Loading the catalog contacts a server outside your institution. In a hospital setting an outbound request should never go out unless you decided it — hence the button rather than an automatic load.

Once loaded, the catalog is cached: it stays readable between sessions, with its update date. The Refresh button checks whether it has changed, and an Updates available banner summarises what is new, updated or removed.

What you find there

Nine entity types can be published.

Workspace

A complete set, with its projects and resources. This is how the demonstration data arrives.

Project

A whole study: cohorts, dashboards, scripts.

Concept mapping

A correspondence between local codes and a standard vocabulary.

Script collection

Reusable SQL queries, organised in folders.

ETL pipeline

A transformation from a source model to a target model, OMOP for instance.

Data catalog

The documentation of a warehouse’s variables.

Quality rules

A set of checks to run against data.

Schema preset

A source’s description: its tables, its columns, how to read them.

Database

A public database and its data — the MIMIC-IV demo, for example.

Reading an entry

Each entry shows its name, description, author and organization, licence, version and tags. An Open repository link leads to the original git repository, so you can inspect the content before installing.

Three states flag an entry to treat with care: Work in progress for unfinished work, Deprecated for a superseded entry, Unreachable when its repository no longer answers.

The size is announced when it matters

Most entities weigh a few kilobytes of JSON. A database carries its data files — the MIMIC-IV demo is 18 MB — and the entry then shows it, to avoid the surprise on a slow connection.

Searching

A search bar and four filters: Type, Tags, Author and Organization. Sorting is the same as in Linkr’s other lists, and your choice is remembered.

The Organization filter does a particular service: it answers “what has that hospital published?”, which is often the real question when you are looking for content you can trust.

Installing an entry

The Install button asks which workspace the entity should land in, then clones its repository.

If you already have it, Linkr says so — Installed — and offers to Update when a newer version exists. The entry then compares the installed version against the catalog one.

Installing again replaces or duplicates

On an entry you already have, the application warns: “Already installed in this workspace. Installing again replaces or duplicates it.” As with an import, the call is yours — see Import and export.

An installed entity stays linked to its original repository. You therefore pick up its later fixes without reinstalling from scratch.

Installing a workspace: "Installed, but some content is missing"

A published workspace is made of pointers to each of its items’ repositories. They are fetched one by one, and some may fail — the common case being a private repository, which the install presents no credentials to.

The message then tells you exactly which ones stayed empty. The workspace is installed; what it lacks is the content of those items, which you can fetch afterwards by providing an access token.

Installing needs server mode

Installing clones a git repository, which the browser alone cannot do. In browser mode the catalog stays readable — you see the entries and can open their repositories — but the install button is unavailable.

To get published content into a browser-only installation anyway, download an archive from the repository and import it as a ZIP.

From the import window

The catalog also appears as the third tab of the Import window, From the catalog, filtered to the type you are importing. Handy when you already know what you are after: a schema, from the schemas page.

Using an internal catalog

The default catalog is public and open. An institution may prefer its own — for content that must not leave, or for a catalog validated internally.

The settings carry a Community catalog section: “The Git repository Linkr reads the catalog from. Change it to use an internal catalog.” You give it a Catalog repository URL and a Branch, with a Reset to default button to return to the public catalog.

What that address expects

An https URL to a GitLab repository — the public instance, a community forge, or your institution’s own GitLab. The index repository’s format is that of the public catalog, which can therefore serve as a model.

When it does not work

The messages distinguish the causes, which saves you looking in the wrong place.

  • Could not reach the catalog — no network, or an outbound connection blocked by the institution’s firewall. This is the most frequent case in a hospital.
  • No catalog found at this address — the configured URL does not point at a catalog repository.
  • The catalog file is not readable — the repository answers, but its content cannot be used.
  • This catalog needs a newer version of Linkr — update the application.

Going further

  • Publishing content — putting your own work there.
  • Import and export — the two other ways to move an entity around.
  • Database schemas — what gets installed most often from the catalog.
  • Entities and sharing — what makes an entity installable.
PreviousGit versioningNextPublishing content

Product

  • Home
  • Demo

Resources

  • Documentation
  • Resources
  • Tools
  • Blog

Community

  • Framagit source code
  • Github source code

About

  • InterHop.org
  • Contact

2021–2026 InterHop — CC BY-NC-SA 4.0 (site) · GPLv3 (software)