Main website

This is the main website of the TRR379.

This website is not just a public-facing view on the consortium. It is specifically built to be the core component of the metadata concept of TRR379. It provides a collection of canonical definitions of entities essential for the function of TRR379. Such entities include

• projects of the TRR
• contributors to the TRR
• publication from the TRR membership
• site of the consortium
• …

Semantics

Any such entity has a dedicated page on the website, with a stable URL that serves as a URI for that entity. As such, these URLs can be used in any TRR379-related metadata to declare relationships to TRR379 entities, for example, the authorship of a publication, the origin project of a data release, etc.

The website is built with the static site generator Hugo. It capitalized on its taxonomy feature. Any page on the site is built from a metadata record. For Hugo, this metadata is presented in the form of a page’s front matter. However, these metadata may themselves be generated from the result of a database query.

Here is an example record for TRR379 spokesperson Ute Habel:

title: Ute Habel
projects:
- a02
- a04
- q01
- q04
sites:
- Aachen
- Juelich
roles:
- pi
- spokesperson
layout: contributor
params:
  orcid:  0000-0003-0703-7722
  name-title: Prof. Dr. rer. soc.
  affiliation: Department of Psychiatry, Psychotherapy and Psychosomatics, Faculty of Medicine, RWTH Aachen University
  sortkey: "Habel, Ute"

<additional content on the page's subject>

From this information, the page that identifies and describes Ute Habel as a spokesperson is generated. It also links and references her record on the respective pages for projects, sites, and roles she is associated with. Consequently, the URL https://www.trr379.de/contributors/ute-habel/ can serve as a URI for Ute Habel within the TRR379 metadata. Moreover, ute-habel is a unique identifier for her as a contributor to TRR379.

While other special-purpose identification systems exist (e.g., https://orcid.org for academics), this approach is automatically applicable to any concept and entity relevant to TRR379. Including roles, data acquisition methods, instruments, etc. The domain root trr379.de represents a unique namespace to define and reference any required entities. This enables a timely and unencumbered development of a metadata concept for TRR379, without hindering alignment with and mapping to more global efforts and initiatives.

Look

Structured metadata is rendered to an HTML website with Hugo using a template. This approach separates the information from its presentation.

The look of the website can be altered by adjusting the template, or switching to a different template entirely. This requires familiarity with Hugo and its templating mechanism.

At present, the congo template is used.

Collaboration platform

https://hub.trr379.de is the central (data) collaboration site of the consortium. It runs an enhanced variant of the Forgejo software that is designed for maximum interoperability with the RDM solution DataLad.

The main difference to the Gitlab solution – that is also employed by TRR379 for internal purposes – is the ability to also host arbitrarily large data on the same site. The integration with the git-annex software makes it ideal for the federated, multi-site nature of TRR379. The full software-stack is free and open source software, and can be deployed at any collaborating site with minimal effort. This aspect is essential for supporting the decentralized RDM approach of the TRR.

Any contributor can have an account on the central hub. Please contact Michael Hanke to get set up.

Calendars

TRR379 uses a dedicated CalDAV server at https://cal.trr379.de. This service can be used to host any number of online calendars. Individual calendars can be configured to be publicly accessible, or only for internal (authenticated) consumption.

Internal calendars

Any number of non-public calendars can be created and shared with specific audiences. This can be useful to coordinate data acquisition sessions, organize room bookings, or schedule slots for internal meetings and events.

Contact the management team to request a dedicated calendar.

Public calendars

All public calenders are available via CalDAV URL and can be included in any calendar solution, such as Google calendar.

The URLs follow the pattern https://cal.trr379.de/public/<name>, where <name> is the calendar name, as stated in the list below. For the events calendar this is https://cal.trr379.de/public/events.

For use with Google calendar, replace https:// with webcal://. For example, the events calendar can be added to Google calender with the URL webcal://cal.trr379.de/public/events.

Available public calendars:

• events: General TRR379 events [preview]

Data catalog

https://data.trr379.de hosts the data catalog of the TTR379. This site is currently work in progress, and will be published once the project has started to accumulate data.

A data catalog is a website that displays and organises information that you provide about your collected datasets. The purpose of a catalog is to make data more FAIR, specifcally more findable, even if they are access restricted. The catalog further encourages collaboration between partner sites. If all partners share a common data catalog which showcases their respective collected datasets, partners can more easily engage in potential collaborations with each other as they can see what data has already been collected at each site.

The data catalog only makes metadata (i.e. descriptive fields about your dataset) openly available, there is no need to make the actual data file content publicly accessible. In other words, you do not need to upload sensitive data (or publicly available data, for that matter) anywhere in order for the dataset to be part of the catalog, just metadata. Providing full access to a dataset, or merely to a limited description about a dataset is entirely within your control. If a partner wishes to pursue a collaboration regarding a certain dataset, that partner will still need to follow the existing institutional routes of requesting access to your dataset. You have FULL control over what information is displayed in the catalog, and if you want the data files to be publicly accessible or not.

Catalog sources follow a specific design and structure.

The main source of metadata for the data catalog is the DataLad dataset at ./data, also referred to as the catalog superdataset or the catalog homepage dataset.

The idea is that this superdataset acts as a container for the metadata of all new datasets that should be represented in the catalog.

In a typical catalog source repository, you will find the following structure:

./catalog - this is where the data catalog sources live - the live catalog site serves this directory

./code - this directory contains scripts that are used for catalog updates

./data - this is a DataLad subdataset of the current data-catalog dataset/repo - its origin is at: abcd-j/data - it functions as the superdataset for all datasets rendered in the catalog, i.e. it is the homepage of the catalog

./docs - documentation sources - contains documentation for catalog users and contributors

./inputs - input files used during catalog creation, updates, and testing

Knowledge pooling tool

The knowledge pooling tool is a system used for aggregating information on research progress and outputs across TRR379 partner sites and projects. It comprises a web UI for manually submitting, editing, and browsing information, and an API for programmatic submission and retrieval.

The current (generation v0) tool can be accessed at:

• UI: https://pool.v0.trr379.de/ui/
• API: https://pool.v0.trr379.de/api/docs

Cohort data discovery

https://nb-query.trr379.de hosts the central NeuroBagel query interface of the TRR379. With this solution, data availability can be queried dynamically, to faciliate data access requests.

NeuroBagel supports federated queries and is therefore ideally suited for the decentralized research data management approach of TRR379.

Data models

https://concepts.trr379.de hosts resources and documentation on the metadata models driving the research data management procedures of TRR379.

Documentation

https://docs.trr379.de (this site) is the main documentation source for the TRR379. It offers information on facilities and procedures.

Fulfill RTG requirements

All PhD students funded by the TRR379 participate in its Research Training Group.

This involves certain obligations, of which you can find an overview below:

Participation

official schedule

• internal meetings
  • attendance via Zoom (in library | Aachen only)
  • present own work twice (once | medical students only)
• lecture series
  • attendance via Zoom (on-site option for lecture location)
  • chair one session (optional | medical students only)
• workshops
  • attend obligatory + 3 (1 | medical students only) voluntary

Documentation via Gitlab

• upload CV (+ motivation letter | medical students only)
• submit thesis proposal (use template)
• sign supervision agreement
• register as member
• insert link to shared logbook (use template)
• plan + log event participation
• list thesis advisory committee meetings
• plan lab visits
• register for the annual RTG retreat
• list attended conferences

Get a Hub account

For working with the TRR379 collaboration platform an account is required.

In order to obtain an account, please email Michael Hanke with a request. Please email from an institutional email, and CC the respective TRR379 project lead. In the email, please mention any projects and/or organizations you require read or write access to.

Edit the website

The main TRR379 website is automatically rendered with Hugo. The website sources are hosted on the TRR379 collaboration hub in a repository under the Q04 project organization.

This repository is a DataLad dataset, the same technology that is used for research data management in the TRR379.

The repository README contains instruction on how to obtain a clone of the website for working on it, and testing it locally.

Alternatively, small edits can be done on the collaboration hub directly. The content of all pages can be browsed at https://hub.trr379.de/q04/www.trr379.de/src/branch/main/content.

Each page provides an “edit button” that enables editing content directly in the browser. The following screenshot show this button for the source file of the personal profile of Michael Hanke.

Once a change has been submitted, it is not reflected on the website immediately. All changes are reviewed and possibly adjusted by the website editor team of the Q04 project.

Submit annual DFG survey

Background

The Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) gathers information from its funded projects on an annual basis. Some information is collected from all members of a coordinated programme, such as a collaborative research centre.

The data are used to produce statistical reports and provide answers to statistical queries. In addition, the data serves as the basis for statistical evaluations, which the DFG uses to comply with its reporting obligations to financial backers, the federal government and the state governments.

Please refer to the information on data protection in relation to DFG research funding (see Research Funding point IV, under point 10), which can be accessed at https://www.dfg.de/privacy_policy.

If there are issues with the form, they can be submitted on the TRR379 collaboration hub at https://hub.trr379.de/q02/dfg-cp-survey-ui/issues (require an account).

TRR379 approach

The TRR379 collects the DFG survey data using the same infrastructure that is employed for research metadata collection and management, rather than the PDF-form based approach suggested by the DFG.

This offers the following advantages:

• members only have to enter their details in the first survey, and can efficiently resubmit updated records in subsequent years
• members can consent to having a subset of their information be used to create and update a profile page on their person on the TRR379 website with no additional effort
• members can consent to having basic information (e.g., name, ORCID) on them be made available in other TRR379 services, for example for reporting publications, or data annotation, to avoid repeated, manual information entry

Collected information is submitted to a TRR379-dedicated virtual server hosted at Forschunsgzentrum Jülich (operated by the Q02 project) via an encrypted connection. Individual person records are only accessible via a personalized link with an individual access token. Members receive this access information via email.

This service is opt-in. Members who do not wish to have their data submitted and kept in the described way can follow the standard DFG-procedure and send the PDF-form available at https://www.dfg.de/resource/blob/203580/questionnaire-sfb-grk-fip-2025-en.pdf to the TRR379 management team.

Submit data

The electronic survey form is provided at https://dfg-cp-survey.trr379.de

Members receive a personalized access link via email. Only with this link it is possible to see one’s personal record, and to submit information.

It is highly recommended to use this webform with a desktop browser. The form offers rich contextual information that are hard to access on mobile devices.

Create or edit a record

If no record on a person already exists, a new record must be created. This is done by clicking on the + button in the “Person” category.

Alternatively, if a previous record already exist, it can be loaded by clicking on the edit button.

Fill the form

Context help is provided for every form filed. This information is accessible by hovering the mouse pointer over the field title.

For some fields (e.g. prior workplace, area of study) one or more choices have to be selected. The selector offers type-ahead search of choices. The selection is constrained to choices matching the entered text in their label.

When no adequate choice exists, a new item can created by clicking the “New item” button.

Whenever a form (or sub-form) was completed, it must be saved by clicking the “Save” button.

Saving only stores the information in the local browser session! It does not submit the form to the server.

When the person record is complete and was saved, the record can be submitted to the server by clicking the submit button.

Submission is only possible with a valid access token. If the form was accessed via the personalized link, this token is already in place. If the form was accessed by other means, the token can be entered via the “key” button. The token is embedded in the access link received via email.

Deploy services

Work with raw MRI data

Magnetic resonance imaging is an essential data acquisition method for TRR379. Four sites acquire such data. Each site has (different) established routines and conventions. This documentation collects resources and best practices that can be adopted by TRR379 members.

• Archive DICOMs
• BIDS conversion

Identifier concept

Identifiers are an essential component of the TRR379 research data management (RDM) approach. This is reflected in the visible organization of information on the consortium website, but also in the schemas that define the structure of metadata on TRR379 outputs.

Many systems for identifying particular types of entities have been developed. A well-known example is DOI for digital objects, most commonly used for publications. However, many others exist, like ROR for research organizations, or Cognitive Atlas for concepts, tasks, and phenotypes related to human cognition.

RDM in the TRR379 aims to employ and align with existing systems as much as possible to maximize interoperability with other efforts and solutions. However, no particular identifier system is required or exclusively adopted by TRR379.

Instead, anything and everything that is relevant for TRR379 has an identifier in a TRR379-specific namespace.

Identifier persistence

TRR379 RDM heavily relies on persistent identifiers. More or less anything and everything has, and must have, a persistent identifier. This key constraint makes it possible for multiple actors to collaboratively, and simultaneously contribute metadata on arbitrary aspects – without having to wait and query for finished metadata records on associated entities.

TRR379 identifier namespace

TRR379 uses URIs as identifiers that map onto the structure of the main consortium website. For example, the full TRR379 identifier for the spokesperson Ute Habel is https://trr379.de/contributors/ute-habel. In this URI, https://trr379.de is the unique TRR379-specific namespace prefix, contributors/ute-habel is the TRR379-specific identifier for Ute Habel (where contributors is a sub-namespace for agents that in some way contribute to the consortium).

Even though Ute Habel can also identified by the ORCID 0000-0003-0703-7722, via the quasi-standard identifier system for researchers, this alternative identifier is considered an optional, alternative identifier rather than a requirement for TRR379 RDM.

The reasons for this approach are simplicity, and flexibility.

An identifier in TRR379 RDM is a simple text label, in a self-managed namespace. This self-managed namespace can cover any and all entity types that require identification with TRR379. In many cases, an identifier directly maps to a page on the main consortium website. This is a simple strategy to document the nature of any entity. It also establishes the main website as a central, straightforward instrument for communicating and deduplicating identifiers in a distributed research consortium.

Alignment with other identifiers

Even though any relevant entity can receive a TRR379-specific identifier with the approach described above, the utility of these identifier is limited to TRR379-specific procedures and activities. However, a TRR379 metadata record on a research site (e.g., https://trr379.de/sites/aachen ) can be annotated with any alternative identifier for the same entity (e.g., https://ror.org/04xfq0f34 ). Thereby it is possible to combine the benefits of a self-governed, project-specific identifier namespace with the superior discoverability and interoperability of established identification systems for particular entities.

Identifiers for particular entities

The additional documentation linked below provides more information on particular identifiers used by TRR379.

• Participants

RDM Infrastructure

[This is a draft under discussion]

The planned RDM infrastructure is a federation of interoperable site infrastructures. The key design principle is that no primary data are aggregated to a central infrastructure.

We aim to establish an infrastructure that is suitable for use within the TRR379, but not limited to this scope. Once deployed, the associated services are usable beyond the scope of TRR379.

The following schema sketches the planned infrastructure. Components that hold (primary) data are depicted in yellow. Components that hold (mostly or exclusively) metadata are shown in blue. The direction of information flow is indicated by arrows, exchange of data by solid arrows, and metadata-only exchange by dotted arrows. Infrastructures that are only accessible to authorized agents are labeled with a “lock” symbol. Further details on individual components are provided below.

graph TB;
    subgraph Central services
        C1[("Collaboration portal<br>hub.trr379.de<br> 🔐")]:::meta
        C2{{"Data search<br>query.trr379.de<br> 🔐"}}:::meta
        C3(Main website<br>www.trr379.de):::meta
        C4("Data catalog<br>data.trr379.de"):::meta
    end
    subgraph "Aachen 🔐"
        A1[(hub)]:::data
        A1a[(lab1)]:::data
        A1b[(lab2)]:::data
        A2{{query}}:::meta
    end
    subgraph "Frankfurt 🔐"
        F1[(hub)]:::data
        F2{{query}}:::meta
    end
    subgraph "Heidelberg 🔐"
        H1[(hub)]:::data
        H1a[(ZI-hub)]:::data
        H1b[(lab1)]:::data
        H2{{query}}:::meta
    end
    A1 -.-> C1
    A1a -.-> A1
    A1b <---> A1
    A1 -.-> A2
    A2 <-.-> C2
    F1 -.-> C1
    F2 <-.-> C2
    F1 -.-> F2
    C3 <-.-> C1
    C3 -.-> C2
    H1 -.-> C1
    H1a <-.-> C1
    H1a <-.-> H1
    H1b <---> H1
    H1 -.-> H2
    H2 <-.-> C2
    C1 -.-> C2
    C1 -.-> C4
    C3 -.-> C4
    H1b <---> A1a
    %% node links to actual services
    click C1 href "https://hub.trr379.de"
    click C3 href "https://www.trr379.de"
    %% classes to distinguish data and metadata nodes
    classDef data fill:#ffa200,color:#000
    classDef meta fill:#5C99C8,color:#000
    %% invisible link purely for manipulating the grouping
    C2 ~~~ A1b
    C4 ~~~ A1b
    C2 ~~~ F1
    C2 ~~~ H1b

Central services

All central services a metadata-focused. No primary data acquired at participating sites are aggregated into central databases/storage.

Collaboration portal (hub.trr379.de)

This is the main hub for collecting actionable links to all TRR379 resources and information. The software solution for this hub is Forgejo-ankesajo. It is a free and open-source software package, and the direct service counterpart of DataLad, the main tool proposed for implementing reproducible research workflows in TRR379 labs.

The hub will store DataLad datasets, referencing all TRR379 data resources without hosting any actual data. Instead the DataLad dataset point to the individual institutional data stores, or to community data repositories when and where data have been published.

The hub is also a place to deposit (shared) computational environments, and implementations of (shared) data processing pipelines, software publications, and source code repositories under a uniform TRR379 umbrella.

A test site is deployed at https://hub.trr379.de and is being evaluated.

Main website

See this page for a description of the main website. Importantly, the website renders essential metadata for the TRR379 (contributors, roles, publications, projects, research topics, etc.) It provides a unique URI for any such entity, to be used as identifiers in all TRR379 (meta)data resources.

The website is programmatically generated from a repository hosted on the TRR379 hub, to enable contributions by all TRR379 members.

Data catalog

The TRR379 data catalog is a website dedicated to providing a uniform (read-only) view on the TRR’s data resources. It is rendered programmatically by DataLad Catalog from metadata on TRR379 data resources hosts in the TRR379 hub.

This site is indexed by specialized search engines like Google’s dataset search and a key enabler for general findability of TRR379 resources.

Data search

This is a federated data discovery service that is tailored to the cohort dataset acquired by TRR379 as a whole. It will enable the discovery of individual data records matching a given set of criteria, regardless of the contributing TRR379 site.

The service is federated. Each sites runs their own instance, and has the sole authority on deciding what metadata are shared with other TRR379 sites. Only these metadata property will be accessible by TRR379 at large, while more detailed metadata records can be use for in-house queries.

The proposed solution for the query service is a version of NeuroBagel adapted to the data nature and needs of TRR379.

Site infrastructure

Sites are free to implement any RDM solutions, as long as that infrastructure provides

• (programmatically) queriable metadata of a previously agreed upon nature
• (programmatically) accessible data to any authorized members of TRR379

with the aim to enable reproducible research from primary data to published results within and across TRR379.

Q02 supports sites with software solution that facilitate interoperability within TRR379. This includes the local deployment of the software systems used to run the central services.

We aim at individual sites running their own data hubs (using the same software solution) as the central https://hub.trr379.de. In contrast to the central hub, these institutional sites can directly use the storage features of Forgejo-ankesajo, and host arbitrary amounts of data. TRR379 can communicate data availability using a federation protocol.

DFG

The German Research Foundation (Deutsche Forschungsgemeinschaft, DFG) is a German research funding organization.

SOP

A standard operating procedure, mostly referred to as SOP, is a set of step-by-step instructions compiled to help carry out routine operations.

TRR

A Transregio (TRR) is a variant of a DFG funded Collaborative Research Centre. Whereas traditional collaborative research centres are proposed and carried out by one university, a CRC is proposed and carried out jointly by two or three universities. It allows close cooperation between these institutions and the researchers based there, including the shared use of resources. The contributions of the partner applicants are essential to the joint research goal, complementary and synergistic.