DataLad を使用してマルチモーダルな動物研究データセットを確立および維持する方法

Jul 08, 2023

Scientific Data volume 10、記事番号: 357 (2023) この記事を引用

1 オルトメトリック

メトリクスの詳細

データ、処理ツール、ワークフローの共有には、オープンデータホスティングサービスと管理ツールが必要です。 FAIR ガイドラインや資金提供機関や出版社からの需要の増加にも関わらず、すべての実験データと処理ツールを共有している動物研究はほんのわずかです。大規模なマルチモーダルデータセットのバージョン管理とリモートコラボレーションを実行するための段階的なプロトコルを紹介します。均一なファイルとフォルダーの構造に加えて、データのセキュリティを確保するために、データ管理計画が導入されました。データへの変更は DataLad を使用して自動的に追跡され、すべてのデータは研究データプラットフォーム GIN で共有されました。このシンプルでコスト効率の高いワークフローは、生データと処理済みデータを利用可能にし、データ処理ステップを独立して再現するための技術インフラストラクチャを提供することで、FAIR データロジスティックスと処理ワークフローの導入を促進します。これにより、コミュニティは、特定のカテゴリのデータに限定されず、異種混合で取得および保存されたデータセットを収集できるようになり、他のサイトでのデータ処理を改善し、他の研究分野に拡張する豊かな可能性を備えた技術インフラストラクチャの青写真として機能します。

データの管理と共有には、人間の MRI に最近導入されたようなベストプラクティスが必要です 1,2。私たちの経験では、ほとんどの研究室は、ユーザー管理やバックアップ容量が不十分なローカルハードドライブまたはネットワークドライブ上の非標準データストレージに依存しています。小動物を使用している MRI 研究は少数であるという事実にもかかわらず、広く使用されている神経画像データ共有プラットフォーム 3 である OpenNeuro では、マウスまたはラットのデータが含まれているデータセットはわずか 3% であることは憂慮すべきことです。同様に、神経画像処理に特化していない別の人気のあるデータ共有プラットフォームである Zenodo4 では、MRI データセットの約 30% のみがマウスまたはラットのものです。さらに、これらの神経画像データセットの大部分で画像データのみが提供されている場合、それは驚くべきことであり、FAIR 原則 5 に反します。これには、in vivo 相互検証に使用される顕微鏡ファイルなどの付随データの大部分が除外されます。また、処理されたデータを再現するために必要なステップバイステップのガイドや自動化されたルーチンが明らかに不足していることも判明しました。これらの例は、小動物のデータ共有が一般的とは程遠く、データの取得、保管、共有に関して標準化が存在しないことを示す以前の報告6を強調しています。 93% の生物医学オープンアクセス出版物 7 の場合のように、データが共有されず再利用できない場合、これは動物実験の数を最小限に抑える 8 という 3 R 原則とも大きく対照的です。したがって、異なる研究室間の研究を比較することは依然として非常に困難であり、それが再現性の危機の一因となっており9、小動物（神経画像）研究も例外ではありません10。

私たちは、動物研究の信頼性と認知度を向上させるために、優れた科学的実践の条件と FAIR の原則 (検索可能、アクセス可能、相互運用可能、再利用可能 5、オープンサイエンス 2) に向けた変化を構想しています。私たちの目標は、生のデータと処理されたデータ、メソッド、結果、およびそれらの出所へのアクセスを提供するマルチモーダルデータセットを設定するための、簡単に適用できるアプローチを作成することでした。適切な研究データ管理 (RDM) は、資金提供機関や出版社からの要求もますます高まっており、これらの基準を満たすための鍵となります 2,11,12。

ここでは、リレーショナルデータベース 13、データプラットフォーム GIN (G-Node インフラストラクチャサービス、https://gin.g-node.org) という 3 つの確立されたツールを使用した、データ編成、メタデータ収集、およびデータ/分析追跡の戦略について説明します。、研究データ管理ソフトウェア DataLad14 です。このデータベースは、MRI、組織学、電気生理学、行動などの長期的および複合的な動物実験の完全なタイムラインに関するすべての実験メタデータを収集するために使用されます。 GIN と DataLad はどちらも、一般的なバージョン管理システムである Git と、特に大きなファイルの管理に関して Git の機能を拡張する git-annex に基づいています。 GIN は、組み込みのバージョニング、安全なアクセス、公開用永続データ識別子 (DOI)、自動インデックス付け、データ検証など、共同的なデータ処理のためのさまざまな機能を備えたオープンソースの Web ベースのデータ管理サービスです。 DataLad は、デジタルオブジェクトの開発のさまざまな段階をサポートするように設計されたデータ管理ソフトウェアです。重要なのは、DataLad は既存のデータ構造とサービス上のオーバーレイとして見ることができます。ファイルを追跡しても、ファイル自体やデータ処理ツールで取得できる場所は変更されません。

過去 5 年間にわたり、私たちは 1) プロジェクト計画、2) 文書化、3) データの取得と保管、4) データ共有に関する戦略を確立してきました (図 1)。プロジェクト計画と実験の詳細は、社内のクラウドベースのリレーショナルデータベースに記録されます13。データベースとデータストレージの両方にとって重要な要素は、データを見つけやすくするために標準化されたファイル名構造で使用される識別子、つまり各動物の研究 ID です。生データのディレクトリ構造は動物実験の実施許可に従っています。特定のプロジェクトのデータは、YODA 原則 (https://handbook.datalad.org/en/latest/basics/101-127-yoda.html) に従って編成されており、BIDS 構造などの既存の標準と互換性があります15 (図2A)。自動増分バックアップルーチンがインストールされ、メイン分析ワークステーションにリンクされた外部ディスクステーションから集中管理されたネットワークドライブにデータが転送されます。出版の準備とデータの再現性を促進するために、実験の生データと処理済みデータが GIN で公開され、後処理の詳細とパイプラインが出版物または GitHub ページ (https://github.com) で指定されます。 /aswentlab/Project_C3a_peri-infarct)。

緑の矢印: プロジェクト計画、データ取得、処理、保存のワークフロー。灰色の矢印: ローカルおよびネットワークストレージ上のバックアップ計画。オレンジ色の矢印: バージョン管理のための DataLad の統合。青い矢印: オンラインホスティングサービスとして GIN を使用する公開プロセス。 Biorender.com で作成された図。

(A) YODA ディレクトリ構造と DataLad の統合。オペレーティングシステム (OS) のルートディレクトリ、プロジェクトのリスト、およびプロジェクト関連のコンテンツ (フォルダー + ファイルタイプ)。破線と「//」で区切られた接続は、追加のレベル (測定時間など) が存在する可能性があることを示します。 Project1 フォルダーを DataLad データセットに変換する際、残りのデータには影響を与えることなく、対応する DataLad ファイル (灰色のボックス) が追加情報としてフォルダー内に作成されます。「raw_data」フォルダーと「code」内のすべてのフォルダーは、「code」が GIN ではなく Github に配置されているネストと分散化の確立のコンテキストにおいて、独立したサブデータセットです。 (B) DataLad データセットを作成するためのステップバイステップガイドは、4 つの必須の後続ステージで構成され、初期準備フェーズとオプションのサードパーティ使用シナリオによって構成されます (赤い丸は繰り返しのステージを強調表示します)。 (C) DataLad を使用せずに動物実験を行う許可に基づくフォルダー構造 (TVA = Tierversuchsantrag (ドイツ語: 動物プロトコル)。これは、YODA 構造が実装される前の古い構造であり、すべての処理もこの構造内でパイプラインを使用して行われました。元の生データは生データのアーカイブとしてこの構造内に保持されますが、残りは廃止されます。

DataLad は、中央データ管理ツール (図 1) として、またバージョン管理のために使用されます。DataLad は、どのファイルがいつ、誰によって変更されたかを追跡し、以前の状態を復元する機能を提供します。この目的のために、DataLad はデータ型に依存せず、コードファイルとデータファイル (通常はそれぞれ Git と git-annex によって処理される) を管理するための統合インターフェイスを提供します。

DataLad データセット内では、他の DataLad データセットを (無制限に) ネストすることができ、各サブデータセットは独自の履歴と兄弟を持つスタンドアロンコンポーネントのままになります。この構造を実現するには、確立されたデータセット内で次のステージ 1 ～ 4 を独立して実行できます。このようにして、ユーザーは、出版物、データタイプ、保存場所などによってプロジェクトを細分化できます。これを明確にするために、トップレベルのデータセットをサブデータセットと一緒にオンラインリポジトリサービスに配置することができます。ここでは、データセットによって直接追跡されたデータは通常どおり保存されますが、サブデータセットは独自のリポジトリへのリンクとしてのみ利用可能であり、同じオンラインリポジトリプロバイダーによってホストすることもできますが、そうする必要はありません。私たちの場合、すべてのプロジェクトコードは GitHub リポジトリ (https://github.com) に保存および維持され、GIN 上のメインのトップレベルデータセット Project1 内に複数のサブデータセットとしてインストールされます (図 2A)。 Yoda 原則によって導入された構造により、プロジェクト全体が自己完結型になります。入力から結果を取得するために、プロジェクトの外部にそれ以上の要素は必要ありません。対照的に、図 2C の構造では自己封じ込めは不可能です。

情報: コーディングスクリプトのみを含むフォルダーにデータセットまたはサブデータセットを実装する場合は、ステージ 1 ～ 4 をわずかに最適化する必要があります。簡単に言うと、git はコードを含むスクリプトのバージョン管理に非常に適しています。ステップ 1.2 を実行すると、デフォルトですべてが git-annex によって処理されます。代わりに、datalad create --force -c text2git を使用することもできます。追加の構成により、git がデータセットの内容を管理します。

このユースケースの説明は、ワークフロー開発 (図 1) に基づいて、複雑でマルチモーダルなファイル、つまり生データと処理済みデータ、およびコードと出力ファイル。

ハードウェアおよびソフトウェアの要件とインストール手順については、「方法」セクションと補足資料を参照してください。ワークフローは 4 つの必須ステージで構成されます (図 2B): 1. DataLad データセットの初期化、2. バージョン管理、3. リモート (オンライン) リポジトリの初期化、4. リモートリポジトリへのアップロード。また、サードパーティによる使用、つまり、同じデータセットで他の研究者と共同作業を行う場合や、データセットを公開する場合のオプションのユースケースシナリオについても説明します。

データ構造を作成するには、メインのプロジェクトフォルダーから始めて、関連する入力フォルダー内の生データを並べ替えます (図 2A)。

プロジェクトフォルダーを DataLad データセットに変換すると、ファイルや構造を変更せずに、対応する DataLad ファイルが自動的に作成されます。 DataLad ファイルには、プロジェクトフォルダー内のすべてのファイルのバージョンと履歴が含まれています。 Project1 は、関連付けられた raw_data フォルダーと proc_data フォルダーを備えたスーパーデータセットとして機能し、それぞれリポジトリサービス GIN および GitHub 上に独自のリポジトリを持つサブデータセットとして機能します。この構造を使用すると、DataLad はコード内の特定のパイプラインからの raw_data の処理などのアクションを登録し、パイプラインの出力を proc_data に保存できます。これらのアクションは、スーパーデータセット Project1 の履歴情報に保存されます。

私たちの場合、複数の動物プロトコルフォルダーのデータがプロジェクトフォルダーにコピーされ、元の生データ (アーカイブ内) はそのまま残ります。 Datalad がすべてのストレージに対してすでに有効になっている場合、このプロセスを追跡できます。他のデータ構造の場合、たとえば PACS サーバーを使用する場合、メインのプロジェクトフォルダーへのデータの転送は同様になります。アイデアは、プロジェクトに関連するすべてのデータを分析に利用し、後で共有できるようにすることです。入力の各サブフォルダーには方法論 (MRI、行動、組織学など) に従って名前が付けられ、さまざまなファイルタイプを含めることができます (表 2)。他のフォルダーには、コード、結果、ドキュメントが含まれます。この例では、コードには、自動品質管理、マルチモーダル MRI16 の処理、および Allen Mouse Brain Atlas17 への登録のための、アトラスベースの画像データ分析ツール AIDAqc および AIDAmri16 が含まれています。 docs フォルダーには、MRI データセットを再現するために必要なすべての (メタデータ) 情報とドキュメントが含まれています (たとえば、どのスタディ ID がどの実験グループに属するか、時点、MRI スキャンタイプなど)。

次のステージは、Project1 フォルダーの DataLad データセットへの変換を開始するために実行されます (図 2B)。ビデオガイドが利用可能です (https://gin.g-node.org/Aswendt_Lab/Example_Dataset_Kalantari_Paper/src/master/doc)。

1.1 まず、ターミナルを開き、ディレクトリをターゲットフォルダーに変更します。この例では、Project1 です。

»cdプロジェクト1

1.2 ターゲットフォルダーに移動したら、次のコマンドを実行して、DataLad データセット固有のフォルダーとファイルを Project1 フォルダーに作成します (図 2A)。

» データラド作成 – 強制

情報: DataLad には多数のコマンドが用意されており、各コマンドには異なるオプションがあります。 datalad createfolder_name を実行すると、空の DataLad データセットフォルダーを作成できます。ここで、ステップ 2 では、create コマンドを使用して現在の作業ディレクトリ内の DataLad データセットを初期化し、--force オプションを使用して、既にデータが含まれているフォルダーにデータセットを作成できるようにしました。他のオプションの詳細については、--help を使用してください。

2.1 初期化ステージ 1 の後、次のステップに進みます。ハードウェアによっては、この手順に時間がかかる場合があることに注意してください1。

(1 内部または外部に接続されたストレージドライブ、ネットワークドライブ、ハードディスクドライブ (HDD) やソリッドステートドライブ (SSD) などのストレージタイプなどの機能を指します)。

» datalad ステータス »datalad save -m "ユーザーメッセージ"

データセットが作成されると、datalad save コマンドを実行して、その内容を変更するステップが記録されます。ステージ 2 では、DataLad データセットの最初の実際的な使用法、つまり変更の記録を示します。私たちの場合、raw_data フォルダーには、たとえば MRI の生データが含まれています。 AIDAmri16 を使用して処理した後、結果は proc_data フォルダーに保存されます (図 2A)。

情報: datalad status コマンドは、DataLad によって追跡されているかどうか、削除されているか変更されているかなど、各ファイルの現在のステータスを出力する検査ツールと考えることができます。ステップ 2.1 で初期化した後、すべてのステータスの出力に「未追跡」と表示されます。新しく追加されたファイルは、datalad save が明示的に実行されるまで追跡されません。ファイルを保存し、その後内容を変更すると、ステータスの表示が異なります。一般に、datalad ステータスは情報提供のみを目的として使用され、最近の (未保存の) 変更を識別するのに役立つ場合があります。

一方、datalad save コマンドは、.git フォルダーに新しい変更を記録します。 save コマンドにはいくつかのオプションもあります。-m は、保存を変更の目的を説明できるユーザーメッセージに関連付けます。これらのメッセージは、ユーザーが特定のバージョンを見つけたり、データセットの変更をより簡単に思い出したりするのに役立ちます。コマンドのその他のオプションに興味がある場合は、--help オプションを使用してください。たとえば、datalad save --help は、コマンド save で使用できるすべてのオプションを表示します。

2.2 (オプション) 変更がプログラムで行われる場合 (カスタムスクリプトの実行など)、これは次のようなコマンドで行うことができます。

» datalad run -m "ユーザーメッセージ" --input … python < code.py >

runコマンドは、実行したコード（ここではPythonスクリプト）の入出力データの情報をデータセットの履歴情報に登録します。 datalad save コマンドは、datalad run の使用時に自動的に実行されますが、ユーザー指定のメッセージに加えて、来歴を取得するために再実行可能な実行レコードも保存されます。

ステージ 2 は反復的なステージ (図 2B) であること、つまり、連続的な変化または新しい状態を記録するために繰り返すことができることを強調することが重要です。このプロセスでは、時間の経過とともに、ユーザーがプロジェクトに対して実行したすべてのアクションが記録されるログブックが作成されます。このログブックにアクセスして使用する方法については、次の手順で説明します。

2.3 記録された変更に関するすべての登録情報には、次の方法でアクセスできます。

» git ログ

これにより、バージョン管理の開始以降に加えられたすべての変更が表示されます。必要に応じて、次のように入力します。

» git ログ -2

最後の 2 つの変更またはコミットのみが出力されます (図 3)。

作成者、日付、変更内容、および「sha」とも呼ばれる対応するコミット識別子に関する情報を示すデータセットの git ログ出力のサンプル。

情報: コミットはプロジェクトの現在の状態のスナップショットです。 1 つの datalad データセット内の 2 つのコミット間の違いは、プロジェクトの 2 つの状態の間で発生した変更を意味します。一部のデータは、生成、変更、移動、または削除される可能性があります。履歴にアクセスするには、tig (https://jonas.github.io/tig/) や、gitgui、gitk などの独自のグラフィカルユーザーインターフェイス (GUI) を使用する方法 (https://git-scm) などの他の方法もあります。 .com/downloads/guis)。

このシナリオでは、データプラットフォーム GIN を使用しています (他のオプションも利用可能です。表 1 を参照)。次の手順の前提条件は、関連付けられた SSH キーペア (http://handbook.datalad.org/en/latest/basics) を持つ運用可能な GIN アカウント (https://gin.g-node.org/user/sign_up) であることです。 /101-139-gin.html) を GIN アカウントとローカルコンピューター上のアカウントの間で接続します。注: ネットワーク速度によっては、この手順に時間がかかる場合があります。

GIN アカウントの下にプロジェクト固有のデータセット名を持つリポジトリを作成し、GIN によって生成されたプロジェクト固有の SSH リンクをコピーします。

Project1 フォルダーで独自の資格情報を使用して次のコマンドを実行します。

datalad 兄弟 add–dataset.–name gin–url [email protected]:/username/dataset-name.git

情報: datalad 兄弟は、データセットの他のコピーに影響を与えるすべてのアクションに使用されます。ここでは、追加オプションを使用して、兄弟またはデータセットのコピーが移動する新しい場所にデータセットをリンクします。次に、 --dataset は、構成されているデータセットのパスを定義します。ここでは、現在のフォルダーの場所を意味する「.」で定義されています。 --name は、ユーザーが定義できる兄弟の名前です。ただし、使いやすく、混乱を避けるために、オンラインリポジトリサービスに従って名前を付けるのが合理的です。ここではジンを使います。 --url オプションは、ステップ 3.1 で取得したプロジェクトページで利用可能なリンク用であり、そこで作成されたプロジェクトに対して明示的に生成されます。 GIN などの一部のリポジトリでは、リモート兄弟の作成と登録を 1 ステップで自動化する専用コマンドが提供されています。 GIN の場合、このコマンドは create-sibling-gin です。

リモートリポジトリがセットアップされ、両者間の接続が確立されたら、プロジェクトを GIN にアップロード (プッシュ) できます。

4.1. まず、ターミナルに次のコマンドを入力します。

datalad プッシュ --to gin

ステージ 2 と同様に、このステップも繰り返すことができます (図 2B)。データセットとその履歴情報が進行するにつれて、新しいコミットが追加され、更新をリモートリポジトリにプッシュできます。これは効率的に行われ、変更されたファイルのみが転送されます。バージョン管理により、アップロードされたデータセットの状態が固有になります。さらに、GIN は git および git-annex と完全な互換性があり、その Web インターフェイスでは、たとえば、変更履歴や関連するコミットメッセージを表示できます。

プロジェクトのサイズとインターネット接続の品質によっては、この手順の実行に時間がかかる場合があります。したがって、すべてのデータを 1 つのバッチでプッシュしようとしない、つまり、データを分割して複数のバッチでプッシュプロセスを実行することが賢明かもしれません。これは、プロジェクトの指定された小さな部分のパスをコマンドに追加することで可能になります。

4.2 (オプション) datalad Push --to gin

プロジェクトに興味のある人は誰でも、データだけでなく、いわゆる「クローン作成」を通じて、時間の経過とともに進化したプロジェクトの履歴にもアクセスしてダウンロードできるようになりました。サードパーティの観点から見ると、最初のステップは、GIN Web サイト上のそれぞれのリポジトリにアクセスすることです。データセットを変更するかダウンロードのみするかに応じて、SSH リンクまたは HTTPS リンクがそれぞれ見つかります。

情報: GIN アカウントのプロジェクトページには、リポジトリにアクセスするための 3 つのリンク (SSH、HTTPS、および GIN) があります。簡単に言うと、SSH と HTTPS は、ユーザーのオペレーティングシステムとオンラインリポジトリサービスの間で通信するための異なる方法です。このユースケースの主な違いは、データをリモートリポジトリにアップロードまたは「プッシュ」する場合は SSH 接続が必要であることです。データのダウンロードまたは「クローン作成」には、HTTPS 接続で十分です。ステージ 3 で簡単に説明したように、SSH リンクの設定には追加の手順が必要ですが、HTTPS リンクは特に心配することなく使用できます。

GIN プロジェクト Web ページから SSH/HTTPS リンクをコピーします。

ターミナルを開き、プロジェクトコンテンツを配置するフォルダーに移動し、サンプル URL をコピーしたリンクに置き換えて次のコマンドを実行します。

SSH リンクの場合:

データセットクローン [email protected] :/ユーザー名/データセット名.git

HTTPS リンクの場合:

データセットクローン https://gin.g-node.org/username/dataset-name

HTTPS リンクを選択した場合、リンクには .git 拡張子がつかないことに注意してください。

情報: datalad clone コマンドの便利な機能は、データセット全体を一度にダウンロードしないことです。ダウンロードするのは、フォルダー構造、小さなファイル、および大きなファイル、つまり git-annex で扱われるファイルのファイル名のみです。 datalad get コマンドを使用して、大きなファイルのコンテンツを選択的にダウンロードし、コンテンツ全体をローカルで利用できるようにすることができます。これは 2 つの観点から役立ちます。1 つは、データセット全体が非常に大きく、一部の部分のみが関心のある場合、それらの部分のみを選択的にダウンロードできることです。次に、プロジェクトの構造とファイル名のみが重要な場合、この場合、datalad get はまったく呼び出されません。

プロジェクト全体をダウンロードする場合は、最後の手順の後に作成された DataLad データセットフォルダーで次のコマンドを実行します。

次のように入力します。

コンピューター化されたヤギ

コマンドを特定のパス (ディレクトリまたはファイル) に制限して、内容を選択的に取得できます。

前のセクションで紹介したように、データセットのネストはサードパーティの観点から非常に役立ちます。この例では、トップレベルのデータセット Project1 には、「raw_data」フォルダーとさまざまなコードパイプラインの複数のデータセットが含まれています (図 2A)。このセットアップの目的は、第 1 に、すべての周辺プロジェクト構造をダウンロードすることなく、生のデータとコードをサードパーティが個別に利用できるようにすることであり、第 2 に、コードフォルダー内のさまざまなパイプラインの更新可能性を維持することでした。パイプラインは時間の経過とともに更新され、トップレベルのデータセットのクローンを作成すると、最新のパイプラインが自動的に関連付けられます。

データセットは公開と再利用を目的としているため、関連情報を注釈として付けることが重要です。作成時の GIN リポジトリはデフォルトでプライベート、つまりアクセスが制限されていますが、設定メニューのチェックボックスを使用してパブリックに設定できます。 GIN 上の公開データセットは、一意の永続的なデジタルオブジェクト識別子 (DOI) を受け取ることができ、これにより引用可能になります。出版物のメタデータの隣には、実験グループや時点などのデータセットに関する文書と、リレーショナルデータベースから取得した MRI シーケンスなどのモダリティ固有の情報が含まれます。

ここでは、専門家以外のユーザーが小動物データに適用できる FAIR データワークフローを実装するためのステップバイステップガイドを提供します。このワークフローでは、シンプルだが効率的なローカルバックアップスキームと標準化されたデータ構造を、パブリックデータ可用性のソリューションとして GIN と組み合わせて使用しています。 DataLad は、入力データ、コード、結果などのプロジェクトのすべての要素とそれらの接続方法に関する情報をカプセル化することを目的として、研究者間の透明性と信頼性の高いコラボレーションの基盤を提供するデータ管理ツールとして利用されました18。

このワークフローを実装する動機は、データの保存、効率的なコラボレーション、データ共有、再現性の向上を確保することでした。研究データ管理に関連するこのような実際的なニーズはこの分野に広く存在しており、これまでのところ単一のソリューションのみが提案されています (Kuhn Cuellar et al.19)。（人間の）神経画像処理におけるデータ管理と共有に関する最近の調査では、神経画像データの適切な管理と共有に関連する重大な課題が示されており、最大の制限は時間とベストプラクティスの欠如です20。研究者は、データ分析や収集の実践よりもデータ共有の方が未熟であると考えています。この制限を克服するために、私たちは無料で入手できるソフトウェアのみを使用し、特別な事前知識を必要としない、実装が簡単なワークフローに焦点を当てました。

標準化された被験者識別子とファイル/フォルダー構造 (「方法」セクションを参照) は、効率的な研究データ管理の基礎です。動物ごとに作成された識別子と標準化されたファイル名により、他のメタデータがない場合でもデータを追跡できるようになります。私たちの場合、動物プロトコルによって、どのメソッドをどのくらいの頻度で適用できるかが決まります。動物を使用する適正な科学的実践のガイドラインに従って完全な透明性を提供し 21、地方自治体による監査の文書を簡素化するために、当社はすべての実験データを電子リレーショナルデータベース 13 に収集し、動物によって事前に定義された構造に生データを保存します。プロトコル。この生データディレクトリは、後でアーカイブとして機能し、そのまま残ります。プロジェクト/出版関連の処理では、すべての生データ (さまざまな動物ライセンスに由来する可能性があります) が入力フォルダーにコピーされ、セキュリティのために生データがそのまま残されると同時に、データの操作に最大限の柔軟性が提供されます。 YODA 構造には、入力フォルダーだけでなく、出力、ドキュメント、コードも含まれます。ここで、私たちのアプローチは、以前に提案された 3 レベルの階層、つまり研究室レベル (複数のプロジェクトを保持する組織)、プロジェクトレベル、およびその後の実験レベル 22 を持つフォルダー構造とは異なります。公開またはコラボレーションの場合、YODA 構造全体がオンラインデータホスティングサービス (この場合は GIN) にアップロードされます。重要なのは、DataLad はデータの保存場所に柔軟性があることです。ユーザーが、放射線データ 23 の場合は XNAT サーバーや PACS サーバー、顕微鏡データの場合は OMERO24 などの代替ストレージソリューションに完全なデータを保存している場合は、専用の DataLad 拡張機能 (https://docs.datalad.org/) があるか、追加の拡張機能を使用できます。追加サービスをサポートするために最小限の労力で開発されました。当社のワークフローは、CKAN (https://ckan.org)、Harvard Dataverse (https://dataverse.harvard.edu)、Barcelonaβeta Brain25 などの他のソフトウェアおよびデータホスティングサービスを除外するものではなく、それぞれ独自の戦略で処理します。複雑で多様な研究データ。対照的に、小規模な研究室から大規模なマルチサイトコンソーシアムまで、ローカルな実験パラダイムや既存の IT インフラストラクチャに適応するために必要な柔軟性とシンプルさを備えた、多用途で相互運用可能な RDM を提供します 12,18。

メタデータは、現在の研究実践において非常に重要な要素であり、特に FAIR および神経画像コミュニティ固有のガイドラインに従った研究者間の透明性のあるコラボレーションに関しては非常に重要です 5,26。DICOM または NiFTI ファイル形式で保存された MRI については、 BIDS 標準は、MRI シーケンスに従ってファイルを構造化し、標準化されたメタデータを含めるために最も先進的で広く使用されているオプションです15。私たちのワークフローは BIDS 形式と完全に互換性があります (https://doi.org/10.12751/g-node.3yl5qi27 の例を参照) が、たとえばデータの場合のように、BIDS にワークフローを使用する要件を設けないことにしました。 OpenNeuro プラットフォームを使用すると、さまざまなファイル形式を扱う研究者の柔軟性を最大限に高めることができます。私たちはメタデータのレベルで標準化を最大限に高める取り組みを全面的にサポートしていますが、マルチモーダルデータ (MRI、行動、電気生理学、顕微鏡など) を扱った私たち自身の経験から言えば、中間ステップとして、できるだけ多くのデータの存在を優先することが必要です。メタデータは、可能な限り機械可読ファイル (txt、csv、json) で保存されます。必ずしも現在のコミュニティベースの構造である必要はありません。したがって、このような機械可読ファイルの生成を可能にする、独自に開発した 13 や REDcap28 などのリレーショナルデータベースとワークフローを組み合わせて使用することをお勧めします。基本的なプログラミングの専門知識があれば、サードパーティユーザーはこれらのファイルに基づいて共有データを検索およびフィルタリングすることが簡単になります。

処理に複数のステップまたは処理ツールが必要な場合は、さらに詳細なステップバイステップのガイド (例: https://github.com/aswendtlab/Project_C3a_peri-infarct) を含めることをお勧めします。これは、メタデータレポートの要件を超えています。既存の標準、つまり BIDS。このような段階的なガイドは、自動化されたルーチン (datalad run) を使用できない場合に備えて、データ複製に必要となる場合があります。

DataLad には時間とリソースの先行投資が必要ですが、最終的に効率、品質、信頼性が向上するため、私たちの経験ではそれらの投資は価値があるものであることに注意してください。

特定の研究の結果を再現できないことは、小動物の神経画像診断に特有のことではありません。これは主に、科学論文の段階的なプロトコルなど、透明性と方法論の詳細が欠如していることが原因です。研究を再現するには、スキャンパラメータ、前後処理手順、個々の被験者の特性など、他のさまざまな文書へのアクセスが必要です。この目的を達成するために、ここで紹介するワークフローに加えて、私たちは実践的なアプローチを採用しています。つまり、生データと処理済みデータを GIN で公開し、プロジェクト固有の GitHub ページで後処理の詳細を指定します。

データフォルダーを DataLad データセットに変換すると、上記の利点が得られるだけではありません。つまり、変更の追跡、データセットを兄弟に公開することによるデータセットの簡単な共有、転送とストレージのニーズの削減による大きなファイルの効率的な管理などです。前に述べたように、DataLad はデータセットをより広範な用途に開放し、DataLad サブデータセットメカニズムを通じて、公開されたデータセットを他の DataLad データセットで簡単に再利用できるようにします。 DataLad は、来歴追跡 (変更の再実行可能なアノテーション) とメタデータ管理も提供します。 DataLad の run-command と rerun-command を併用すると、データセットに対する操作の「追跡された実行」が可能になり、DataLad は真に再現可能な調査を可能にします29。

適切な RDM プロトコルに組み込まれたオープンデータ共有は、研究デザインや分析戦略の欠点を解決するものではありませんが、最も重要なことは、他の研究者が潜在的な欠点を特定し、将来の研究でそれらに対処することを可能にし、エラーの繰り返しを防ぐことです20。私たちの取り組みは、前臨床イメージングの他の分野の青写真として機能し、動物神経イメージング分野およびそれを超えた研究実践に大きな影響を与えます。動物の数を減らすための 3 R 原則に沿って、このワークフローを使用すると、コミュニティが異種収集および保存されたデータセットを収集して、マウスの脳シミュレーション実験を促進し、異種間モデリングアプローチを実装できるようになります。さらに、データとメタデータの標準化、来歴追跡とワークフロー管理、相互運用可能な研究データプラットフォームエコシステムへの統合、および標準化された手段を使用した計算モデルの仕様の取り組みとの緊密な連携は、すべての参加者の相互作用を強化し、問題を改善するのに役立ちます。基礎研究者と臨床研究者との間の現在のトランスレーショナルギャップ。

このセクションでは、ワークフローを再現するために必要な資料の詳細を説明します。

ここで説明するワークフロー (図 1A) は、サーバーモードで実行されるメインワークステーションとして Mac Pro (Late 2013) を使用して開発されました。このようにして、複数のユーザーが内蔵画面またはファイル共有 (VNC/SMB プロトコル) 経由で Mac にアクセスし、データを取得したり、プログラムを並行して実行したりできます。 Linux または Windows 10/11 インストールを実行しているワークステーションでも、リモートデスクトップ接続経由で同様の作業方法が可能です。データストレージ戦略は、バックアップ計画、さまざまなバックアップの場所、バックアップの有効性チェック、データストレージの拡張可能性などのベストプラクティス 30 に従って開発されました。ワークステーションに直接接続されているメインのローカルストレージは、Raid-5 モードで動作する 20TB LaCie Thunderbolt ドライブです (ファイルシステムはそのままで、1 台のハードドライブが損傷する可能性があります)。すべてのデータは、最初に責任ある実験者によって手動でこのローカルストレージにコピーされます。生データへのパスは電子データベースに文書化されています13。自動増分バックアップは、Carbon Copy Cloner (Bombich Software, Inc.、米国) を使用してローカルストレージからネットワークストレージ (大学病院の IT 部門が管理) に毎週実行されます。

ワークフロー (図 1A) は、無料のオープンソースソフトウェア: Python (https://www.python.org/、RRID:SCR_008394)、GIN (https://gin.g-node.org、RRID:) に基づいて構築されています。 SCR_015864)、および DataLad (https://www.datalad.org、RRID:SCR_003931)。他のデータホスティングオプションも存在し (表 1)、提供されているワークフローに簡単に統合できます。代表的なインストールガイドは補足資料に記載されています。最新のインストール手順については、関連 Web サイトを参照してください。

DataLad は、分散バージョン管理、つまりリンクされたデータセットのコピー (兄弟と呼ばれる) の作成、同期、追跡に使用されます。 DataLad データセットには 1 つまたは複数の兄弟を含めることができ、ローカル (バックアップドライブ、ローカルサーバー、さまざまなワークステーション) またはオンライン (GIN など) に保存できます。 1 つのデータセットコピーに加えられた変更は、他のコピーと同期でき、同期は常に明示的に行われます (バージョンが分岐しているかどうかを知るのは簡単です)。ファイルコンテンツの可用性が追跡され、リモートで利用可能なコンテンツをオンデマンドで取得してローカルのスペースを節約できます。これは、たとえ場所が異なっていても、ファイル交換、バックアップ、公開がすべて同じソフトウェアインターフェイスを通じて行われることも意味します。

リポジトリ: コードまたはデータ管理の構造単位としてファイルとサブフォルダーを含むフォルダー。フォルダー構造やデータ型が異なるファイルのセットまたは組み合わせを指定できます。場合によっては空でファイルが含まれていない場合もあります。

DataLad データセット: DataLad が実行され、バージョン管理が実行されているリポジトリ。

DataLad データセットの初期化: DataLad のバージョン管理の対象となる空のデータセットを作成します。その後、このデータセットにファイルが追加されると、それらは DataLad によって追跡されます。

既存のリポジトリでの DataLad の初期化: ファイル/フォルダー構造内のデータセットを DataLad で管理されるデータセットに移行します。

追跡/バージョン管理: ユーザーによる置換または編集によりファイルが変更された場合、DataLad はそれらの変更を時間の経過とともに記録します。

DataLad 兄弟/クローン: データセットのコピーとして定義できます。これは、必ずしもそれが正確なコピーであること、またはすべてのデータが完全に利用可能であることを意味するわけではありません。プレースホルダーは、元のファイルと同じ名前を持つ、内容のないファイルです。

Git: 小規模から非常に大規模なプロジェクトまでを効率的に処理するために使用される、無料のオープンソースのバージョン管理システム

Git-annex: git-annex は、大きなファイルのコレクションの共有と同期の問題を解決することを目的とした分散ファイル同期システムです。

データセットのネスト: データセットには他のデータセット (サブデータセット) を含めることができ、さらにそのデータセットにはサブデータセットを含めることもできます。別のサブデータセットを含むすべてのデータセットをスーパーデータセットと呼ぶことができます。最上位のデータセットは、データセットの階層内で最も高いレベルを持つスーパーデータセットです。

オンラインデータホスティングプロバイダーは、研究者がデータをアップロードして他のユーザーと共有するためのインフラストラクチャを提供します。これらのサービスは主な焦点が異なります。クラウドストレージ (ファイルストレージと限定された共有、メタデータインデックス作成なし)、シンプルなデータホスティングサービス (長期ホスティング、自動メタデータインデックス作成)、研究データプラットフォーム (長期ホスティング、共有、コラボレーション、データ)管理) (表 1)。

永続的識別子 (DOI) を提供するサービスとプラットフォームは、再現性とデータ再利用の側面に沿って FAIR とオープンサイエンスの実践を導入するための鍵となります。ただし、データを共有している研究は少数であり、出版社や資金提供機関からの需要の増加に応じて変更される可能性があります。私たちは、ドイツ政府 (BMBF Grant 01GQ1302) と LMU ミュンヘンによって支援されている研究データプラットフォーム GIN (https://gin.g-node.org/G-Node/Info/wiki/) を選択し、オープンなデータプラットフォームを開発しました。 - ドイツの神経情報学ノード (G-Node) によるソース。 GIN は登録リソース (https://doi.org/10.17616/R3SX9N) であり、INCF31 によって承認されたリポジトリおよび科学ゲートウェイの基準を満たしています。

データセットを GIN-DOI サービスの対象にするには、「datacite.yml」と呼ばれる GIN 固有のファイルを含む特定のメタデータを作成する必要があります。このファイルには、作成者、タイトル、説明、キーワード、およびライセンスに関する情報が含まれています。 DataCite スキーマ (https://schema.datacite.org/) を提供する必要があります。 GIN では、このメタデータはリポジトリのルートにある「datacite.yml」というファイルに存在する必要があります。ライセンスを選択して (例: https://creativecommons.org/choose/)、帰属、派生物、および共有要件を指定し、ライセンステキストを LICENSE というテキストファイルに含める必要があります。 GIN DOI サービスは、永続的な識別子 (https://gin.g-node.org/G-Node/Info/wiki/DOI) を使用してデータセットへの永続的なアクセスを保証します。

情報: データホスティングサービスの選択は、可用性、匿名性の暗号化、外部または内部ユーザーの一般的なターゲットグループ、データの範囲、使用頻度など、さまざまな要素が影響するため、慎重に行う必要があります。重要なのは、DataLad はリストされているすべてのサービスで動作することです。 DataLad のバージョン管理は、データがどこにあるか (ローカルまたはオンラインデータストアなど) に関係なく適用されます。ただし、データ、DataLad レコード、および関連する履歴へのアクセスを失わないようにするために、適切なバックアップが必要です。したがって、データセットのレプリカとそのバージョン管理された履歴を、十分な記憶領域のある別の場所に保存するのが一般的です。

私たちは 2 つのデータ構造を使用しています。1 つは承認された動物プロトコルに記載されている実験に従って (生の) データが保存される構造 (図 2C)、もう 1 つはプロジェクト固有のデータが保存される構造です (図 2C)。 2A）。まず、動物実験ライセンスのメインプロジェクトとサブプロジェクトに従い、地方自治体の承認に従って、すべての生データを統一フォルダー構造に収集します。一般的な生データフォルダー (MRI/raw_data/P1/SPs1c4m1_1_1_20180105_094610) は実験を指定します ( MRI）、データのタイプ（生データ）、時点（P1、つまり脳卒中後 1 日目）、スタディ ID（SPs1c4m1）、および MRI ハードウェア（Bruker）固有のコード（つまり、スタディ番号、再構成番号）、日付は YYYY-MM-DD、時刻は hh-mm-ss)。当局への文書作成を簡素化するために、生データを動物プロトコルに関連するフォルダー構造に保存することをお勧めします。 2 番目のステップでは、DataLad を初期化する前に、各プロジェクト/パブリケーションの YODA 構造内の 1 つまたは複数の生データフォルダーから生データがコピーされます。 YODA 構造は、データ入力、出力、ドキュメント、およびコードをプロジェクト固有の構造にアンサンブルします (図 2A)。

多数の実験を追跡するために、各マウス/スキャンに一意の識別子を作成しました (図 1)。識別子 (研究 ID) は、動物プロトコル、(サブ) プロジェクト、ケージ、およびケージごとの動物数の要素を組み合わせたものです。たとえば、SPs1c4m1 は、プロジェクト SPasticity、サブプロジェクト 1、ケージ 4、マウス 1 に関連します。原則として、性別や遺伝子型などの他の情報は、男性 (m) Tg( Rbp4-cre)KL100Gsat (短い Rbp4) マウス。トランスレーショナル研究にとって重要なことは、実験グループをユーザーに明らかにするために研究 ID を変更すべきではないことです。つまり、ユーザーはデータの収集と分析中に盲目的なままになります。いずれの場合も、識別子の主な機能は維持されるべきです。つまり、(実験の詳細に関して) 被験者を匿名化し、キーワード形式の検索/並べ替え用語によって識別可能な状態を維持する必要があります。

情報: ID は動物プロトコルを指し、BIDS 形式で使用されるものと同様の固定フォルダー構造に保存されます。ファイルの命名と構造化に関するファイル規則は、BIDS が動物の MRI データに普及する前に指定されました。したがって、TP_T1_4_1 のように、アンダースコアとハイフンを区切り文字として使用したデータセットがあります。ユーザーが BIDS 形式を使用する予定の場合でも、DataLad は BIDS と互換性があるため、ワークフローを適用できます。ただし、BIDS はハイフンやアンダースコアなどの特定の文字に敏感であるため、ID には数字と文字のみを含める必要があります。 SP_T1_4_1 の代替として考えられるのは、SPsT1c4m1 となります。これは、アンダースコアをサブプロジェクト (s)、ケージ (c)、およびマウス (m) の頭文字に置き換えます。注: 過去に検査 ID に特殊文字が含まれていた場合、ファイルを BIDS 互換にするためには、NIfTy ヘッダーや関連するすべてのメタデータファイルにも正しい情報を書き込むなど、より多くの注意が必要です。

可能な限り、ファイル名の要素は自動的に生成されるか、StudyID、テスト/実験、および時点 (該当する場合) を含む標準化されたスキームに従って割り当てられる必要があります。こうすることで、ファイル名は一意になり、すでに重要なメタデータが含まれます。例として、SPs1c4m1CytD4 は、研究 ID SPs1c4m1 で 4 日目 (D4) に実行されたマウス行動テストであるシリンダーテスト (Cyt) に関連します。ファイル/フォルダーのパスは、実験に関する重要なメタデータ情報とともに電子データベース 13 に保存されます。 MRI の場合、これには麻酔プロトコル (正確なタイミングと投与量を含む)、構成の詳細 (コイル、勾配など)、および MRI スキャンのリストが含まれます。

データストレージの基本ルール 30 に従って、可能な限りオープンデータ形式が使用されます。当社のデータセットには、小さなテキストファイルから大きな MRI ファイルやビデオ録画に至るまで、幅広いファイルが含まれています。ワークフローと互換性のあるファイル形式には一般的な制限はありません (表 2)。

情報: あらゆるテキストファイル形式 (txt、csv、json など) の場合、DataLad はファイル内の変更を行ごとに (全体的に) 追跡します。その結果、Python コードなどの各行は、(Git 機能を使用して) 最後に変更したコミット (および作成者) に起因することができます。他のすべてのデータ形式については、DataLad はファイルチェックサムを使用してファイルごとに違いを追跡します。つまり、いつ誰がドキュメントを変更したかに関する情報は保存されますが、ファイルのどの部分が変更されたかは保存されません。オープンサイエンスと長期的な使いやすさの観点から、可能な限り行ごとのファイルタイプ (機械可読、csv など) を使用することをお勧めします。

テストデータセット 27 (https://doi.org/10.12751/g-node.3yl5qi) を使用することをお勧めします。これには基本的なヨーダ構造 (図 2A) が含まれており、高速処理が可能なほど十分に小さいです。

DataLad と GIN は無料で利用できます。原稿には、ワークフローを再現するためのすべてのコードが含まれています。

ニコルズ、TE et al. MRI を使用したニューロイメージングにおけるデータ分析と共有のベストプラクティス。 Nature Neuroscience 20(3)、299–303 (2017)。

論文 CAS PubMed PubMed Central Google Scholar

Niso, G. et al. オープンで再現可能なニューロイメージング: 研究の開始から出版まで。 https://doi.org/10.31219/osf.io/pu5vb (2022)。

Markiewicz、CJ et al. 神経科学データを共有するための OpenNeuro リソース。 eLife 10 (10 月)。 https://doi.org/10.7554/eLife.71774 (2021)。

欧州原子核研究機構および OpenAIRE。ゼノド。ケルン。 https://doi.org/10.25495/7GXK-RD71 (2013)。

ウィルキンソン医学博士ら。科学データの管理と管理に関する FAIR の指導原則。科学データ 3 (3 月)、160018 (2016)。

記事 PubMed PubMed Central Google Scholar

マンディーノ、F.ら。動物機能的磁気共鳴イメージング: 標準化への傾向と道筋。ニューロインフォマティクスのフロンティア 13、78 (2019)。

論文 PubMed Google Scholar

Gabelica, M.、Bojčić, R. & Puljak, L. 多くの研究者が、公表されたデータ共有声明「混合法研究」に準拠していませんでした。 Journal of Clinical Epidemiology 150 (10 月)、33–41 (2022)。

論文 PubMed Google Scholar

人道的な実験技術の原則。オーストラリア医学ジャーナル 1(13)、500–500 (1960)。

Begley、CG & Ioannidis、JPA 科学における再現性: 基礎および前臨床研究の基準の改善。循環研究 116(1)、116–26 (2015)。

論文 CAS PubMed Google Scholar

ポルドラック、RA et al. 地平線のスキャン: 透明性と再現性のあるニューロイメージング研究に向けて Nature Reviews。神経科学 18(2)、115–26。（2017年）。

論文 CAS PubMed PubMed Central Google Scholar

JL クーチュール、RE ブレイク、CL マクドナルド、G. および CL ウォード資金提供者によって課されたデータ公開要件データ共有がきっかけとなることはほとんどありません。 PloS One 13(7)、e0199789 (2018)。

記事 PubMed PubMed Central Google Scholar

ハンケ、M.ら。分散型研究データ管理を擁護します。ニューロフォーラム0(0)。 https://doi.org/10.1515/nf-2020-0037 (2021)。

Pallast, N.、Wieters, F.、Nill, M.、Fink, GR & Aswentt, M. 2018. マルチモーダル動物データのためのクラウドベースのリレーショナルデータベース。データベース: The Journal of Biological Databases and Curation https://doi.org/10.1093/database/bay124 (2018 年 1 月)。

ハルチェンコ、Y.ら。 DataLad: コード、データ、およびそれらの関係を共同管理するための分散システム。 Journal of Open Source Software 6(63)、3262 (2021)。

記事 ADS Google Scholar

ゴルゴレフスキー、KJ 他脳画像データ構造、神経画像実験の出力を整理して記述するための形式。科学データ 3 (6 月)、160044 (2016)。

記事 PubMed PubMed Central Google Scholar

Pallast, N. et al. 構造的および機能的マウス脳 MRI (AIDAmri) のアトラスベースのイメージングデータ解析のための処理パイプライン。ニューロインフォマティクスのフロンティア 13(6 月)、42 (2019)。

記事 PubMed PubMed Central Google Scholar

Wang, Q. et al. Allen Mouse Brain の共通座標フレームワーク: 3D リファレンスアトラス。セル 181(4)、936–53.e20 (2020)。

論文 CAS PubMed PubMed Central Google Scholar

Wachtler、T. et al. NFDI-Neuro: ドイツで神経科学研究データ管理のコミュニティを構築。ニューロフォーラム0(0)。 https://doi.org/10.1515/nf-2020-0036 (2021)。

クーン、L.ら。ライフサイエンスにおけるイメージングデータとオミクスデータの統合のためのデータ管理インフラストラクチャ。 BMC バイオインフォマティクス 23(1)、61 (2022)。

記事 Google Scholar

Borghi、JA & Van Gulick、ニューロイメージングにおける AE データ管理と共有: MRI 研究者の実践と認識。 PloS One 13(7)、e0200562 (2018)。

記事 PubMed PubMed Central Google Scholar

Percie du Sert、N. 他 ARRIVE ガイドライン 2.0: 動物研究の報告に関するガイドラインを更新しました。脳血流と代謝のジャーナル: 国際脳血流と代謝学会の公式ジャーナル 40(9)、1769–77。（2020年）。

論文 PubMed Google Scholar

Colomb, J.、Arendt, T. & Sehara, K. ジントニックチーム。標準化されたリサーチフォルダー構造に向けて。 https://doi.org/10.25815/WCY6-M233 (2021)。

記事 Google Scholar

マーカス、DS et al. 拡張可能なニューロイメージングアーカイブツールキット: ニューロイメージングデータを管理、探索、共有するための情報学プラットフォーム。ニューロインフォマティクス 5(1)、11–34 (2007)。

論文 PubMed Google Scholar

Swedlow、JR、2007 年。オープン顕微鏡環境: 生物画像情報学のための共同データモデリングおよびソフトウェア開発プロジェクト。細胞および分子の生物学的機能のイメージング、71–92。ベルリン、ハイデルベルク：シュプリンガーベルリンハイデルベルク。

Huguet、J.ら。大規模な神経画像データセットの管理と品質管理: Barcelonaβeta Brain Research Center からの開発。 Frontiers in Neuroscience 15(April)、633438 (2021)。

記事 PubMed PubMed Central Google Scholar

ポーリン、JB et al. 神経画像研究におけるデータ共有。ニューロインフォマティクスのフロンティア 6 (4 月)、9 (2012)。

PubMed PubMed Central Google Scholar

Aswendt, M. & Kalantari, A. マルチモーダル動物データリポジトリの例示的な構造の DataLad データセット、G-Node、https://doi.org/10.12751/g-node.3yl5qi (2023)。

ペンシルバニア州ハリスら。 Research Electronic Data Capture (REDCap) – トランスレーショナルリサーチ情報学サポートを提供するためのメタデータ主導の方法論およびワークフロープロセス。生物医学情報学ジャーナル 42(2)、377–81 (2009)。

論文 PubMed Google Scholar

ワグナー、AS et al. FAIRly Big: 大規模データを計算上再現可能な処理を行うためのフレームワーク。科学的データ 9(1)、80 (2022)。

記事 PubMed PubMed Central Google Scholar

ハート、EMら。デジタルデータストレージに関する 10 の簡単なルール。 PLoS 計算生物学 12(10)、e1005097 (2016)。

記事 PubMed PubMed Central Google Scholar

サンドストローム、M. et al. 神経科学の観点から見たリポジトリと科学ゲートウェイの推奨事項。科学データ 9(1)、212 (2022)。

記事 PubMed PubMed Central Google Scholar

リファレンスをダウンロードする

この研究は、フリーベ財団 (T0498/28960/16) および Deutsche Forschungsgemeinschaft (DFG、ドイツ研究財団) – プロジェクト ID 431549029 – SFB 1451 から資金提供を受けました。私たちは、DFG (ドイツ研究財団) からの記事処理料金への支援を認めます。、491454339）。

Projekt DEAL によって実現および組織されたオープンアクセス資金調達。

ケルン大学医学部およびケルン大学病院神経科、ケルン、ドイツ

アレフ・カランタリ & マルクス・アスヴェント

精神情報学研究室、神経科学医学研究所、脳と行動 (INM-7)、ユーリッヒ研究センター、ユーリッヒ、ドイツ

ミハウ・シュチェパニック、シュテファン・ホイニス、クリスチャン・メンヒ、ミヒャエル・ハンケ

ハインリッヒ・ハイネ大学医学部システム神経科学研究所（ドイツ、デュッセルドルフ）

マイケル・ハンケ

ルートヴィヒ・マクシミリアン大学ミュンヘン生物学部、プラネック・マルティンスリード、ミュンヘン、ドイツ

トーマス・ワクトラー

認知神経科学、神経科学医学研究所 (INM-3)、ユーリッヒ研究センター、ユーリッヒ、ドイツ

マルクス・アスヴェント

PubMed Google Scholar でこの著者を検索することもできます

概念化: AK、MA、MS、データキュレーション: AK、形式分析: AK、MA、資金獲得: MA、MH、調査: AK、MA、方法論: AK、MS、TW、MH、MA、プロジェクト管理: MA、リソース: MA、ソフトウェア: AK、MA、監督: MA、MH、ビジュアライゼーション: MA、AK、執筆 – 原案: MA、AK、MS、SH、TW、執筆 – レビューおよび編集: MA、AK、CM、SH 、MH、TW、著者全員が最終原稿を読み、編集し、承認しました。

マルクス・アスヴェントへの通信。

MS、SH、CM、および MH は、無料のオープンソースソフトウェア DataLad の開発者です。 TW は、フリーのオープンソースソフトウェア GIN の開発と GIN プラットフォームの提供に取り組んでいます。他の著者は競合する利益を報告していません。

発行者注記 Springer Nature は、発行された地図および所属機関の管轄権の主張に関して中立を保っています。

オープンアクセスこの記事はクリエイティブコモンズ表示 4.0 国際ライセンスに基づいてライセンスされており、元の著者と情報源に適切なクレジットを表示する限り、あらゆる媒体または形式での使用、共有、翻案、配布、複製が許可されます。クリエイティブコモンズライセンスへのリンクを提供し、変更が加えられたかどうかを示します。この記事内の画像またはその他のサードパーティ素材は、素材のクレジットラインに別段の記載がない限り、記事のクリエイティブコモンズライセンスに含まれています。素材が記事のクリエイティブコモンズライセンスに含まれておらず、意図した使用が法的規制で許可されていない場合、または許可されている使用を超えている場合は、著作権所有者から直接許可を得る必要があります。このライセンスのコピーを表示するには、http://creativecommons.org/licenses/by/4.0/ にアクセスしてください。

転載と許可

Kalantari, A.、Szczepanik, M.、Heunis, S. 他 DataLad を使用してマルチモーダルな動物研究データセットを確立および維持する方法。 Sci Data 10、357 (2023)。 https://doi.org/10.1038/s41597-023-02242-8

引用をダウンロード

受信日: 2022 年 12 月 19 日

受理日: 2023 年 5 月 15 日

公開日: 2023 年 6 月 5 日

DOI: https://doi.org/10.1038/s41597-023-02242-8

次のリンクを共有すると、誰でもこのコンテンツを読むことができます。

申し訳ございませんが、現在この記事の共有リンクは利用できません。

Springer Nature SharedIt コンテンツ共有イニシアチブによって提供

前: ナノテクノロジーによる地下水循環井におけるオキシテトラサイクリン汚染浄化のシミュレーション研究次: 機会の解放: 金融ハブとしてのギフトシティの可能性を探る

お問い合わせを送信

送信