6/18 ライセンス検討小委員会セッションメモ
6/18のライセンス検討セッション、何とか無事に終了しました。
セッション詳細 6月18日（月）｜Japan Open Science Summit 2018（JOSS2018）
ご登壇いただいた皆様、参加していただいた皆様に大変感謝します。
当日のスライドや概要報告は追ってJOSSのサイトで公開される予定なので、ここでは個人的なメモ（というか反省と考察）を。
＝＝＝＝＝
セッションの趣旨としては、「研究者が」研究データの共有、公開を進めるために必要なガイドラインの策定。検討のcriteriaとしては、以下の3つを立てて登壇者に検討してもらい、会場も交えてディスカッションを行う、というもの。
近隣分野の登壇者から出たcriteriaへの回答としては、ざっくりまとめると
１．データ公開の可能性
→ （手法として）手順自体の標準化、公開状況（公開率）の共有、（アグリゲートサービスを前提とした）公開用データの作成
２．ルールの標準化
→ 約款で対応、政府標準利用規約＋手引書の作成、ガイドライン作成（パブリックドメイン作品/メタデータ利用ガイドライン（Europeana））。
３．表記方法
→ CCライセンスに準ずる（Europeanaガイドラインに明示）。
というもの。
ディスカッションはかなり荒れ模様・・・司会の実力不足を痛感。申し訳ない。
出た意見としては、研究者間のオープン化に対する意識の差、（分野ごとの）用語の使い方に対する微妙なずれ、メタデータ基準、インセンティブ、法律 vs 慣習、ライセンスのコミュニティ、open by defaultとの関係、といったところ。
ただ、非常に様々な視点からのコメントがあり、検討材料が一気に増えたのも事実。取り急ぎ自分なりに整理、考察してみた（「研究データ」と大きく括りすぎ＆数値データによりすぎ問題は一旦置いておいて）。
【研究データのフェーズごとの整理】
まず、今対象にする「研究データ」は、公開されておらず、「研究者の手元にある」データが中心。
- 作成当初のデータの取扱いについては民間データと同じ立ち位置で、（役に立つか分からないが）作成してみた段階なので、ここでの共有・公開は難しいしあまり意味もない（競合研究者にとっては意味があるが、共有・公開の視点ではなおのこと検討の余地がない）。
- 標準的な形で整理したりメタデータを付与したデータは使い勝手があがる。この段階のデータは共有、公開することによって活用が見込まれるが、この段階では研究者の業績の問題と衝突する。「共同研究の推進」、「公開による利活用促進の評価」という形で、貢献度を別の形で示す取り組みはあるものの、データ分析が研究者の主たる業務である以上この段階で強制力を働かせることは相当工夫がいる。単なる強制では、研究環境自体の崩壊につながりかねない。
- 論文の根拠データについては、既に政策、コミュニティの両面から強制力が働きつつある。この段階ではオープンデータやデジタルアーカイブの知見が非常に役立つ。事例の共有や見える化、ガイドラインの整備が有効だろう。
【公開に向けて】
・・・こうやってつらつらと書いてくると、3. 論文根拠データ以外の研究データは生貝先生の言う通り「open by default」の準備段階、というのがしっくりくる（そもそも公開できる＝人に見せて意味が分かる程度になっていない、という観点でも）。
ただ、公開に向けて努力しなければならないという原則を踏まえれば、準備段階から公開段階へ移行するための仕掛けが論文以外に必要。良く使われる手法としては取得からの年限を区切って公開してしまう手法だが、管理者よりの手法であることは否めない。これのカウンターとして（研究者の自律性を尊重する手法として）インセンティブの議論が位置づけられる訳だが、妙な既得権になっては困るのでこれまた難しい。
【公開条件：研究者の視点から】
ここでやっと本題だが、では、公開に当たってどのような条件があると公開が進むのか。対象は2. 整理済みデータ、かつ未公開のものになり、上記でいうインセンティブの議論と密接に絡む。
データを中心に考え直すと、現状存在するインセンティブは「論文」による業績化。なので、とりあえず論文と同等の効果が認められればよいだろう、というのが一つの指標になる。ということで、引用だとか業績として認めるだとかいう議論が出てくるが、論文には「分析による考察」という知的労働が含まれるので、同業者として全く同じ業績とは認めづらいだろう。似通ったスタンスであるプレプリントとの兼ね合いやアンケート結果を見ても、「引用」が妥当な線か。
【公開条件：データ管理者の視点から】
博士論文（あるいは知財権）の手法に倣えば、論文発表に必要な程度の公開猶予期間をまず確保しつつ、延長を認める（あるいは出しても問題ない形に加工したデータの提出を認める）、という手法になるだろうか。延長にも限度を定めておく必要はあるものの、準備の程度に差があるデータを一律に公開フェーズへ動かすことが出来るのは有力な手段だろう。
【公開条件：市民の視点から】
データ取得に対して納税している、という視点をきちんと明確にするべきなので、オープンデータ的に「出せるものはすぐ出す、出せないなら理由を」ということになる。ただ、現状研究者の業績評価システムと見事に衝突しているので、研究者コミュニティ維持の観点からも一定程度のエンバーゴはやむを得ない、というところまでは理解が得られる（と勝手に推測）。既存の制度に倣えば、データのカタログ公開＋データの公開請求（及び非公開事由の開示）制度の準備、カタログ内での延長理由の提示、あたりでフォローするところまでは容易にイメージできる。
補足として、データの保存範囲については保存コストを明示できると良さそう。この範囲までなら100万円、全部保存したら1000万円とか。データを出せる範囲、出せない範囲を納得してもらう、というのも公開の際に重要な視点。
※その意味でも、既に大分時間が経っている研究データ開示に対して、具体的な利活用のオファーがあると話が進みやすい気がするけれども。本当に使いたい人はいるのだろうか。。。
・・・単なる自分用のメモになってしまったものの、とりあえずアップします。
続きはまたそのうちに。
FAIRデータ原則に関する覚書き part 5: Reusable 1/1
試訳、何とか出張に間に合いました。揺れはあるだろうけど完成版ではないのでまあ良しとする。機会があれば作ります。
～～～～～
R1: (Meta)data are richly described with a plurality of accurate and relevant attributes
R1: (Meta)data are richly described with a plurality of accurate and relevant attributes - GO FAIR
これは何を意味するのでしょうか？
多くのラベルがデータに添付されている場合は、データを見つけて再利用することがはるかに簡単です。原則R1はF2に関連しますが、R1は、データが特定の状況において「実際に有用であるかどうか」を決定するユーザー（機械または人間）の能力に重点を置きます。この意思決定を助けるために、データ出版者は、発見を可能にするメタデータだけでなく、データが生成された文脈を説明する豊かなメタデータも提供する必要があります。これには、実験プロトコル、データを作成した機械またはセンサーのメーカーおよびブランド、使用されている種、薬物管理などが含まれる可能性があります。さらに言えば、R1は、データ出版者がデータ消費者の識別およびニーズの予測を試みる必要はないことを示します。我々は、メタデータに含まれる情報が一見無関係に見える場合でも、メタデータの作成者がメタデータを提供にあたりできるだけ気前がよい（注：メタデータの量や質の観点で）ことが望ましいことを示すために、”plurality”（複数の）という用語を選択しました。
考慮すべきいくつかの点（網羅的なリストではありません）：
・データ範囲の記述：どのような目的のために生成/収集されましたか？
・他のユーザーが認識すべきデータに関する特記事項や制限への言及
・データの生成/収集日、研究室（ラボ）のコンディション、データを準備した人物、パラメータ設定、使用するソフトウェアの名前とバージョンの特定
・生データか処理済みデータか？
・すべての変数名が説明されているか、自明である（つまり、研究分野ごとに統制語彙で定義されている）ことの確認
・保存されたデータおよび/または再利用されたデータのバージョンの特定及び文書化
Links to Resources
R1はこれらの間違いを避けるために役立ちます：
https://www.youtube.com/watch?v=N2zK3sAtr-4
＝＝＝＝＝
R1.1: (Meta)data are released with a clear and accessible data usage license
R1.1: (Meta)data are released with a clear and accessible data usage license - GO FAIR
これは何を意味するのでしょうか？
“I”（注：Interoperable）の下で、我々は技術的な相互運用性の要素をカバーしました。R1.1は法的な相互運用性に関するものです。あなたのデータにはどのような使用権利が付いていますか？これは明確に説明されるべきです。曖昧さは、組織としてライセンス制限を遵守しようとする際、データの再利用を厳しく制限してしまう可能性があります。ライセンス条件を明確にすることは、より多くのライセンスを考慮した自動検索においてより重要になるでしょう。データを使用できる条件は、機械および人間にとって明白でなければなりません。
例：
MITやCreative Commonsなどの一般的に使用されるライセンスは、あなたのデータにリンクすることができます。このメタデータをマークアップする方法は、DTL FAIRifierによって提供されています。（リンク：https://www.dtls.nl/fair-data/find-fair-data-tools/）
Links to Resources
https://wiki.creativecommons.org/wiki/License_RDF
＝＝＝＝＝
R1.2: (Meta)data are associated with detailed provenance
R1.2: (Meta)data are associated with detailed provenance - GO FAIR
これは何を意味するのでしょうか？
他のユーザーがデータを再利用するには、データの元の場所（明白な起源/履歴、R1参照）、引用者、および/またはどう謝辞に記載されたいか、を知っておく必要があります。データに続けて、ワークフローの説明を含めてください：誰がそれを生成または収集したか？どのように処理されたか？これまでに公開されているか？データには、誰かが手を加えたり完成させたりした可能性のあるデータが含まれているか？理想的には、このワークフローは機械可読形式で記述されます。
例：
https://commons.wikimedia.org/wiki/File:Sampling_coral_microbiome_(27146437650).jpg
作成者の詳細を含む、クリエイティブ・コモンズのShare Alikeライセンス（継承）を使用します。これは、データ作成者がどのように引用されたいかを正確に示します。
Links to Resources
https://creativecommons.org/licenses/by-sa/2.0/
＝＝＝＝＝
R1.3: (Meta)data meet domain-relevant community standards
R1.3: (Meta)data meet domain-relevant community standards - GO FAIR
これは何を意味するのでしょうか？
似通ったデータであれば、データセットの再利用はより簡単です：同じタイプのデータ、標準化された方法で組織化されたデータ、確立された持続可能なファイルフォーマット、共通のテンプレート、共通の語彙を使用したドキュメント（メタデータ）など。データの保存と共有のためのコミュニティの標準やベストプラクティスが存在する場合は、それに従うのが望ましいでしょう。例えば、多くのコミュニティは、最小限の情報標準（例えば、MIAME、MIAPE）を有しています。FAIRデータは少なくともこれらの基準を満たすことが望ましいでしょう。他のコミュニティ標準はあまりフォーマルではないかもしれませんが、コミュニティによる利用（能力）を向上させる方法で（メタ）データを公開することは、FAIRnessの主要な目的です。状況によっては、提出されるデータのタイプに関する標準的なグッドプラクティスから逸脱する、有効な、特定の理由が提出者にあるかもしれません。これはメタデータ内で扱われることが望ましいでしょう。なお、品質に関する問題は、FAIR原則で扱われていないことに注意してください。データの信頼性は、閲覧者の目にあり、意図するアプリケーションに依存します。
例：
https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSM1528447
Links to Resources
http://schema.datacite.org/[for general purpose, not domain-specific]
http://dublincore.org/specifications/[for general purpose, not domain-specific]
https://www.ncbi.nlm.nih.gov/geo/info/MIAME.html [microarrays]
http://cds.u-strasbg.fr/doc/catstd.htx [astrophysics]
https://www.iso.org/standard/53798.html [geographic information and services]
http://cfconventions.org/ [climate and forecast]
http://www.iucr.org/resources/cif [crystallographic information]
http://www.nexusformat.org/ [neutron, x-ray, and muon experiment data]
http://www.ddialliance.org/Specification [social, behavioral, and economic sciences]
https://sdmx.org/ [statistical data]
https://knb.ecoinformatics.org/#tools/eml [ecology]
～～～～～
最後はちょっと詰め込み過ぎましたね・・・まあいいか。
FAIRデータ原則に関する覚書き part 4: Interoperable 1/1
後半戦、"I"の翻訳。何か段々説明が短く（そして読みづらく）なってきているような・・・
慣れてきたのでスピードが上がってきました。一気にI1～I3まで。
～～～～～
I1: (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation
これは何を意味するのでしょうか？
人間はお互いのデータを交換して解釈できるはずです（死んだ言語を使わないようにすることが望ましいですが）。しかし、これはコンピュータにも当てはまります。データの意味は、特殊な、またはアドホックなアルゴリズム、トランスレーター、またはマッピングを必要とせずに、マシンで読み込み可能になるべきです。ここで、相互運用性は、通常、各コンピュータシステムが少なくとも他のシステムのデータ交換フォーマットの知識を持っていることを意味します。これを実現し、データセットの自動的な検索可能性と相互運用性を確保するためには、(1) 一般的に使用される統制語彙（controlled vocabularies）、オントロジー、シソーラス（グローバルに一意かつ永続的な識別子を解決する、F1参照）、（2）適切なデータモデル（（メタ）データを記述し構造化する明確な枠組み）、を使用することが重要です。
例：
RDF extensible 知識表現モデルは、データセットを記述し構造化する方法です。ダブリンコアスキーマを例として参照することができます。
OWL
DAML + OIL
JSON LD
テキストマイニングと組織遺伝子発現から予測される遺伝子疾患関連については、データモデルの例を参照してください。
このページの「ドキュメンテーション」リンクのEBIのデータモデルを参照してください。http://www.ebi.ac.uk/rdf/
Links to Resources
https://en.wikipedia.org/wiki/Programming_language
＝＝＝＝＝
I2: (Meta)data use vocabularies that follow the FAIR principles
I2: (Meta)data use vocabularies that follow the FAIR principles - GO FAIR
これは何を意味するのでしょうか？
データセットを記述するために使用される統制語彙は、文書化され、グローバルにユニークで永続的な識別子を使用してリゾルブ可能である必要があります。このドキュメントは、データセットを使用するすべての人が簡単に見つけてアクセスできる必要があります。
例：
FAIRデータポイント（後述）を使用するとI2が保証されます。
Links to Resources
FAIR Data Point Specification（https://docs.google.com/document/d/1WZE9oTUn_aPSRZhOur1GjWZ5vYxLsKJQqzmpWMxNpcs/edit#heading=h.1obiwd95lfrw）※2018年3月現在、編集中とのこと。
＝＝＝＝＝
I3: (Meta)data include qualified references to other (meta)data
I3: (Meta)data include qualified references to other (meta)data - GO FAIR
これは何を意味するのでしょうか？
“qualified reference”は、その意図を説明する相互参照です。例えば、”X is regulator of Y”は、”X is associated with Y”、または”X see also Y”よりもはるかに意味づけされた（注："qualified"の超訳）参照です。データに関する文脈を豊かにするために（メタ）データリソース間に可能な限り多くの「意味を持つ」リンクを作成し、適切なデータモデルを作成するのに必要な時間とエネルギーのバランスを取ることがゴールとなります。具体的には、あるデータセットが別のデータセットを元に構築されているかどうか、データを完成するために追加のデータセットが必要な場合、または補完的な情報が別のデータセットに格納されているかどうかを特定する必要があります。特に、データセット間の科学的リンク（注：引用関係のこと？）は記述する必要があります。さらに、すべてのデータセットを適切に引用する（つまり、グローバルに一意である永続識別子の利用を含みます）必要があります。
例：
FAIR Data Point (https://docs.google.com/document/d/1WZE9oTUn_aPSRZhOur1GjWZ5vYxLsKJQqzmpWMxNpcs/edit#heading=h.1obiwd95lfrw）※2018年3月現在、編集中とのこと。
http://www.uniprot.org/uniprot/C8V1L6.rdf
～～～～～
FAIRメタデータの種類
またも寄り道。データのFAIRification processで触れられていたが、
データのFAIR化の手順（FAIRification process） - みなみの備忘録
FAIRのうち、"Findable"と"Accessible"はメタデータのレベルでほぼ達成できるとのこと。では、どんなメタデータが必要か、ということがまとめられていたので試訳・抜粋してみました。
＝＝＝＝＝
GO FAIR metadata
・ライセンスに関する情報（どのようなアルゴリズムで、誰がどのような条件でデータにアクセスできるか）
が含まれている必要があるとのこと。また、相互運用性と再利用性のために
・データとメタデータのセマンティクスに関する情報
・データの来歴に関する情報
が含まれている必要があり、さらにメタデータはドメインに関連したコミュニティの標準に準拠している必要がある。
以上を前提に、次の層（レイヤー）で構成された多層的なメタデータのアプローチを推奨する、とのこと：
→ データとデータの実体（Entity）が含まれる。さらに、APIのバージョンやサービスライセンス等の情報を含む。
カタログのメタデータ：
→ データの組織化情報。
→ データセットの名前、説明、作者/出版社、バージョン、最終変更日、ライセンス、権利などの情報。
流通のメタデータ：
→ データセットをシリアル化（注：オブジェクトのステータス情報を保存または転送できる形式に変換するプロセス）した情報。RDFとかXMLとかCSVとか。
データレコードのメタデータ：
→ データ、関係性（relationship）、ドメイン、範囲、および制限で表される概念の情報。「データの構造とセマンティクス」って表現されている。
＝＝＝＝＝
やや複雑になってはいるが、良く言われる①記述的メタデータ、②管理用メタデータ、③構造的メタデータ、の枠組みと大きく異なることはない様子（セマンティクスの要素は大きいか）。しかし、確かにここまで書けば極めて充実したメタデータと言えようが、データ保有者はデータセットごとにこれを書く価値を見出してくれるだろうか・・・
FAIRデータ原則に関する覚書き part 3: Accessible 2/2
試訳もこれで折り返し。来年度あたりFAIR推進ワークショップとかやれないかな・・・
～～～～～
A2: Metadata should be accessible even when the data is no longer available
A2: Metadata should be accessible even when the data is no longer available - GO FAIR
これは何を意味するのでしょうか？
データセットは時間の経過とともに劣化または消滅する傾向があります。これは、データセットのオンラインプレゼンスを維持するコストが理由です。データセットの劣化または消滅が起こると、リンクは無効になり、ユーザーはもはや存在しないかもしれないデータを探す時間を浪費することになります。一般的に、メタデータの保存はずっと簡単で安価です。 したがって、原則A2は、データがもはや維持されていなくても、メタデータは維持すべきである、と述べています。A2は、F4で説明されている登録およびインデックス作成の問題に関連します。
例：
メタデータは、研究、特に複製の研究を計画する際には、それ自体に価値があります。元のデータがない場合でも、オリジナルの研究に関連する人や機関、または出版物を追跡することは非常に便利です。
データのFAIR化の手順（FAIRification process）
FAIRデータ原則の試訳を鋭意進めてる最中ですが、一番興味のあったFAIR化の話があったのでちょっと横道に。
FAIRification Process - GO FAIR
GO FAIRな方々が採用した標準的な手順、という理解で良さそう。
一応試訳はしたけれども、やや長いので抜粋で。
＝＝＝＝＝
・FAIRのうち、"Findable"と"Accessible"はメタデータのレベルでほぼ達成できる。
・"Interoperable"と"Reusable"はデータレベルでの取り組みが必要。
上記の理解のもと、以下7つのプロセスでデータをFAIR化できるとのこと：
～～～～～
1. 非FAIRデータの取得
2. 取得したデータの分析
→ データの概念、構造、関係性などを確認
3. データセットに適用するセマンティックモデルの定義
→ 既存のオントロジー、ボキャブラリによってデータを意味付ける
4. データをリンク可能に
→ step 3で定義したモデルが、ユーザー視点で適切かどうか確認（注：RDFっぽく言うとIRIにするかリテラルにするか、みたいな確認）
5. ライセンスの付与
→ 本来はメタデータ定義の一部だが、重要なので別枠で
→ https://www.go-fair.org/technology/go-fair-metadata/ の要素を満たすように
7. データの展開（Deploy）
～～～～～
明示されてはいないけれども、3～5のプロセスが"Interoperable"と"Reusable"に該当、6が"Findable"と"Accessible"に該当する、ということなんだろう。
手順としてはLOD作る時とほぼ同じだが、セマンティックをきちんと紐づけたりメタデータ付与したり、といったプロセスが学問分野によって変わる点がポイントか。
実装する際にFAIR化のためにひと手間かける、というのはなかなか想定しづらいので、（今日のDA学会の話題にも上がっていたけれども）ワークフローに組み込んでもらうことを考えながら推進する必要がありそう。
国内だとNBDCが積極的に推進しているので、
今度どなたかにお話を聞いてみよう。
FAIRデータ原則に関する覚書き part 3: Accessible 1.5/2
今日は学会参加。合間を縫って（？）仕事がはかどる感じがよいですね。Accessibleは1.1、1.2の枝番があるため、まとめて。
～～～～～
A1.1: The protocol is open, free and universally implementable
A1.1: The protocol is open, free and universally implementable - GO FAIR
これは何を意味するのでしょうか？
データの再利用（の可能性）を最大限にするには、プロトコルは無料（無償）でオープン（ソース）にし、データ検索を容易にするためにグローバルに実装可能でなければなりません。 コンピュータとインターネット接続を持つ人は、少なくともメタデータにアクセスできます。したがって、この基準はデータを共有するリポジトリの選択に影響を与えます。
例：
・電話（おそらく普遍的に実装可能ではないが、十分に近い）
・反例はSkypeであろう。独占的であるため、普遍的に実装可能ではない
・Microsoft Exchange Serverプロトコルも独自仕様である
Links to Resources
https://en.wikipedia.org/wiki/Skype_protocol
https://www.w3.org/Protocols/rfc959/
＝＝＝＝＝
A1.2: The protocol allows for an authentication and authorisation when required
A1.2: The protocol allows for an authentication and authorisation when required - GO FAIR
これは何を意味するのでしょうか？
これは誤解されることも多いですが、FAIRのキーとなる要素です。FAIRにおける「A」は、必ずしも「開かれた」または「無料」という意味ではありません。むしろ、データがアクセス可能である正確な条件を提供すべき、ということを意味します。したがって、強力に保護されたプライベートなデータであっても、FAIRである可能性があります。理想的には、「アクセシビリティ」は、マシンが自動的に要件を理解し、要件を自動的に実行するか、ユーザーに要件を警告するような手法（での実現）を求められます。リポジトリのユーザーアカウントを作成するようにユーザーに要求することは、しばしば理にかなっています。これは、各データセットの所有者（または貢献者）の認証を可能にし、ユーザーごとの権利を設定することができる可能性を持ちます。したがって、この基準は、データを共有するリポジトリの選択にも影響します。
例：
HMAC authentication
FTPS
Telephone
Links to Resources
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code
.jpg){kind=link}