# TogoID ミーティング議事録
# 2023-02-24
## 前回からのフィードバック対応実装差分
### No.7: 【バグ】テスト環境では順向きのペアしか取れなくなっている。例えば Ensembl Transcript から UniProt に変換できない(ペアとしては uniprot-ensembl_transcript の向きしかない)。
→ APIの実装不具合でした。修正しました。
### No.3: ExploreのSory ByのName とCategoryはAlphabeticalで、sourceとtargetは降順をデフォルトにする
→ 対応しました。
### No.8: Datasetsのフリーワード検索
→ データセットのラベルを対象に検索可能にしました。ご要望に応じて項目を調整可能です。
### IDに対するアノテーションを返すUIの開発
→ prefixの無いIDはアノテーションを取得できるところまで実装しました。
- GraphQLがタイムアウトしてしまう場面が多いかもしれません
## 次回
Slackのコミュニケーションで足りなそうなことがあれば、オンラインMTGを設定
# 2023-02-03
## Datasetsの絞り込み機能
- Color Legend配下のカテゴリ絞り込みについて、実装上はカンマ区切りで別のフィルタとして実装されているので、表示もそれに追従させる
- マウスオーバーでそれぞれ別にクリックできることを示す
## 2.1.2 出力結果でIDの入力順を保持する機能の開発
- compact のテーブルプレビュー時に文字を上詰め
- Formatのラジオボタンを右寄せ
## 2.2 IDに対するアノテーションを返すUIの開発
- https://github.com/togoid/grasp-config
- 一旦現状でGraphQLエンドポイントを立ててみる
- graspのconfigをビルドすると、期待するスキーマが見えるはず
- http://ep.dbcls.jp/grasp-togoid
## 次回
2/15(水) 11:00
# 2023-01-24
以下、前回からの開発差分
## 2.1.1 順引きと逆引きの結果をマージして返す機能の開発
実装を改善して、ご指摘のあった例でもタイムアウトしないようになりました。
https://api.togoid.dbcls.jp.il3c.com/convert?report=pair&route=uniprot,*ensembl_gene&ids=Q9UDY6
## 2.1.2 出力結果でIDの入力順を保持する機能の開発
開発環境に実装を適用しました。ID入力順を保持することをデフォルトとしつつ、reduced=1を付与すると1入力1行になります。
例) https://api.togoid.dbcls.jp.il3c.com/convert?route=togovar,*ensembl_gene,*hgnc,*uniprot,*mbgd_gene&ids=tgv1000000,tgv1000002&report=full&reduced=1
- プレビューモードを変えるスイッチを付ける
- FormatというタイトルでExpanded or Compact
- Expandedデフォルト、ラジオボタン
- Reportセクションの直下、Actionの上
## 2.2 IDに対するアノテーションを返すUIの開発
→ DBCLSさんにてアノテーションを取得できるエンドポイントを準備中？
- GraspにてSPARQLをGraphQLでラップして提供予定
- 現在投入している87のデータベースのうちの一部に対して、GraphQLでアノテーションを取得できるようにする予定
- 今回の開発範囲の対応としては、任意のIDのリストを投入して取得ボタンを押すと、GraphQLにリクエストしてアノテーション情報を取得してくれて、表形式なりで可視化するという機能を作る
- トップページのID入力窓の右に「Annotate」というサブミットボタンを押して、押下すると対応しているデータベースだったらアノテーションの一覧を画面表示する
- 取得結果をモーダルで立ち上げるアイディア
## 2.3 更新情報・統計情報のウェブページへの反映を自動化
開発環境に実装を適用しました。一つのDatasetに複数のテーブルが紐づくため、デザインを少し工夫する必要がありそうです。
- アプリ上では各データセットごとの最も遅いLast Updated atを1件のみ表示する。運用上、あるデータセットに紐づくテーブルは一括でアップデートするので、その割り切りで問題ない。かつ、Last Updated atあらため、LAST IMPORTED ATとする。また、LINK TOの各データセット名タグの末尾にカッコ書きで件数を付与する。
- やっぱりユーザーに混乱をもたらすので、将来課題としてLast Imported atは表示しない
## 次回
2/3(金) 11:00
# 2023-01-11
以下、前回からの開発差分
## 2.2 IDに対するアノテーションを返すUIの開発
→ DBCLSさんにてアノテーションを取得できるエンドポイントを準備中？
## 2.1.1 順引きと逆引きの結果をマージして返す機能の開発
開発環境に実装を適用しました
- 例1) https://api.togoid.dbcls.jp.il3c.com/convert?route=uniprot,*chembl_target&ids=P31946&report=full
- 例2) https://api.togoid.dbcls.jp.il3c.com/convert?route=togovar,*ensembl_gene,*hgnc,*uniprot,mbgd_gene&ids=tgv1000000&report=full
- 前回MTGの案1「順方向テーブルと逆方向テーブルの検索結果をunion allする」を採用しました。union all によるメモリ不足は今のところ発生せずに動作しています
- マージ用のオペレーターとして`*`を追加定義しました
## 2.1.2 出力結果でIDの入力順を保持する機能の開発
出力CSVフォーマットの検討をさせてください
- IDの入力順を維持することをデフォルトとする？
**入力例**
```
ENSG00000136997
ENSG00000204531
ENSG00000136997 // 重複
ENSG00000136826
ENSG00000000000 // 変換失敗予定
```
**今後のデフォルトCSV**
入力ID順は維持されるが、重複行は出力しないことが望ましい
→ limit, offsetすると完全な入力ID順の部分集合は作れないので、デフォルトで入力ID順は見送る。
→ 一応、SQLの文法上は`SELECT * FROM member ORDER BY id = 2 DESC, id = 4 DESC, id ASC`のように並び順を指定することはできるよう。パフ
ォーマンスに不安はあるが、動作を検証してみる。
→ 変換に失敗したIDをpython側で途中に差し込む処理が辛そう
→ 入力順ソートをデフォルトにすることが困難だった場合、せめて入力IDを昇順にソートすることをデフォルトとする
|Ensembl gene |Affymetrix probeset|NCBI gene|
|---------------|-------------------|---------|
|ENSG00000136997|202431_s_at |4609 |
|ENSG00000136997|239931_at | |
|ENSG00000204531|210265_x_at | |
|ENSG00000204531|210905_x_at |5460 |
|ENSG00000204531|210905_x_at |5462 |
|ENSG00000204531|214532_x_at |5460 |
|ENSG00000204531|214532_x_at |5462 |
|ENSG00000204531|208286_x_at |5460 |
|ENSG00000204531|208286_x_at |5462 |
|ENSG00000136826|220266_s_at |9314 |
|ENSG00000136826|221841_s_at |9314 |
|ENSG00000000000| | |
**現状得られるCSV**
|Ensembl gene |Affymetrix probeset|NCBI gene|
|---------------|-------------------|---------|
|ENSG00000136826|220266_s_at |9314 |
|ENSG00000136826|221841_s_at |9314 |
|ENSG00000136997|202431_s_at |4609 |
|ENSG00000136997|239931_at | |
|ENSG00000204531|210265_x_at | |
|ENSG00000204531|210905_x_at |5460 |
|ENSG00000204531|210905_x_at |5462 |
|ENSG00000204531|214532_x_at |5460 |
|ENSG00000204531|214532_x_at |5462 |
|ENSG00000204531|208286_x_at |5460 |
|ENSG00000204531|208286_x_at |5462 |
|ENSG00000000000| | |
**出力結果案1**
スペース区切りで変換後IDを1セルに集約する。ID間の経路は失われる
|Ensembl gene |Affymetrix probeset|NCBI gene|
|---------------|-------------------|---------|
|ENSG00000136997|202431_s_at 239931_at|4609 |
|ENSG00000204531|210265_x_at 210905_x_at 214532_x_at 208286_x_at|5460 5462|
|ENSG00000136997|202431_s_at 239931_at|4609 |
|ENSG00000136826|220266_s_at 221841_s_at|9314 |
|ENSG00000000000| | |
**出力結果案2**
2列に集約する。経路情報を維持しているが、独自にパースする必要がある
|Ensembl gene |Affymetrix probeset,NCBI gene|
|---------------|-----------------------------|
|ENSG00000136997|[202431_s_at,4609],[239931_at]|
|ENSG00000204531|[210265_x_at],[210905_x_at,5460],[210905_x_at,5462],[214532_x_at,5460],[214532_x_at,5462],[208286_x_at,5460],[208286_x_at,5462]|
|ENSG00000136997|[202431_s_at,4609],[239931_at]|
|ENSG00000136826|[220266_s_at,9314],[221841_s_at,9314]|
|ENSG00000000000| |
## UI全般フィードバック
- インフォ・ラウンジで一旦微調整をしてから、DBCLSさんに下記にフィードバックに集約をいただく
https://docs.google.com/spreadsheets/d/16Xl8Xc74jmR6iGbXAhzufIOv9onZswIk_sEoCfC6rrQ/edit#gid=0
# 2022-12-06
## 2.1.3 DATASETSタブの検索機能の追加
## 2.1.4 変換結果のIDのprefixを選択する機能の追加
## 2.1.5 変換候補のデータセットリストをソートする機能の追加
デザイン調整済
https://togoid.dbcls.jp.il3c.com/
Basic Auth : togoid / TgZMWVTD3Eo5ZV97tZ6u
## 2.3 更新情報・統計情報のウェブページへの反映を自動化
開発環境にて実装済み
https://api.togoid.dbcls.jp.il3c.com/config/statistics
```json
{
"affy_probeset-ncbigene": {
"count": 19063,
"last_updated_at": "2022-12-05T06:29:09Z"
},
(以下省略)
}
```
- last_updated_atはインポートスクリプトがMySQLのテーブルにデータを投入した時刻を記録している
## 2.2 IDに対するアノテーションを返すUIの開発
→ DBCLSさんにてアノテーションを取得できるエンドポイントを準備中？
## 2.1.1 順引きと逆引きの結果をマージして返す機能の開発
### 仕様案
- 案1) 現状の順引きオペレーター(>)、逆引きオペレーター(<)にマージ用のオペレーターを追加定義する
- <> の両方を使うか、*の一文字かで検討
- 案2) 変換の全ルートに一括でマージを許可するオプションを指定する（あまり良い仕様ではなさそう）
**現状のおさらい**
```
# 既存動作(順引きできないが逆引きして出している)
$ curl "https://api.togoid.dbcls.jp/convert?ids=0005854&route=mondo,nando&format=json"
{
"ids": [
"0005854"
],
"route": [
"mondo",
"nando"
],
"total": 2,
"results": [
"1200278",
"2200430"
]
}
# 順引き指定ではエラー
$ curl "https://api.togoid.dbcls.jp/convert?ids=0005854&route=mondo,>nando&format=json"
{
"message": "no route: mondo > nando"
}
# 逆引きならOK
$ curl "https://api.togoid.dbcls.jp/convert?ids=0005854&route=mondo,<nando&format=json"
{
"ids": [
"0005854"
],
"route": [
"mondo",
"nando"
],
"total": 2,
"results": [
"1200278",
"2200430"
]
```
**実装方法の案1**
---
**順方向テーブルと逆方向テーブルの検索結果をunion all する**
==動くけれど、union allで対象テーブルの全行をメモリ上に展開する可能性があるためメモリ不足に陥る==
例） togovar -> ensemble_gene -> hgncの変換においてensemble_gene -> hgnc間を両方向変換のマージにする例
`togovar` -> (`ensembl_gene-hgnc` union `hgnc-ensembl_gene`) として検索する
#### SQL
```sql
select
te.src_id as togovar,
te.dst_id as ensemble_gene,
eh.dst_id as hgnc
from
`togovar-ensembl_gene` as te -- 最初のテーブル
left join
(
select
src_id,
dst_id
from
`ensembl_gene-hgnc`
union all
select
dst_id as 'src_id',
src_id as 'dst_id'
from
`hgnc-ensembl_gene`
) as eh -- 2つのテーブルのunionをサブクエリとして連結する。ここでGene Ontologyのような巨大テーブルの場合
on (te.dst_id = eh.src_id)
where
te.src_id = 'tgv1000000';
```
#### Result
抜粋
```
+------------+-----------------+-------+
| togovar | ensembl_gene | hgnc |
+------------+-----------------+-------+
| tgv1000000 | ENSG00000176261 | 24094 | <-- togovar-ensembl_gene => ensembl_gene-hgnc の結果
| tgv1000000 | ENSG00000176261 | 24094 | <-- togovar-ensembl_gene => hgnc-ensembl_gene の結果
+------------+-----------------+-------+
```
**実装方法の案2**
---
**マージが発生する箇所では順方向の変換SQLと逆方向の変換SQLを二回発行し、最後にマージして返却する**
==変換経路でマージが指定される数の累乗で発行SQLが増えるが、概ね動く==
例） ncbigene -> ensembl_gene -> hgncの変換において全ての変換結果を両方向変換のマージにする例
- `ncbigene-ensembl_gene` → `ensembl_gene-hgnc`
- `ncbigene-ensembl_gene` → `hgnc-ensembl_gene`
- `ensembl_gene-ncbigene` → `ensembl_gene-hgnc`
- `ensembl_gene-ncbigene` → `hgnc-ensembl_gene`
の4通りの変換を実行して最後にマージする。マージが指定される経路が増えるほどにSQL発行回数が増えるのがデメリット
**実装方法の案3**
---
**予め順方向と逆方向をマージしたテーブルを生成しておく**
==生成処理を全面的に見直さねばならず、実装負荷が大きい。DBサイズも大きくなるが、マージ処理としては最も取り扱いやすい==
例えば `ensembl_gene-hgnc` と `hgnc-ensembl_gene` のテーブルがあったとき、別のテーブルにするのではなく、以下のようにマージして生成しておく
|src_id|dst_id|direction|
|------|-------|----------------|
|ENSG00000000003|11858|forward|
|ENSG00000000003|11858|reverse|
|ENSG00000000005|17757|forward|
|ENSG00000000005|17757|reverse|
|ENSG00000000419|3005|forward|
|ENSG00000000419|3005|reverse|
|ENSG00000000457|19285|forward|
|ENSG00000000457|19285|reverse|
|ENSG00000000460|25565|forward|
|ENSG00000000460|25565|reverse|
---
## 2.1.2 出力結果でIDの入力順を保持する機能の開発
→ 実装検討中
# 2022-11-02
- DATASETSタブの検索機能の追加
- 検索対象項目を絞り込むプルダウンUIがあり、デフォルトは「すべてのフィールド」になっている
- 絞り込みたければ、descriptionやorganizationを選択可能
- 変換結果のIDのprefixを選択する機能の追加
- IDs, Ids with prefix(hgnc:%s), Ids with prefix(HGNC:%s)
- formatがdataset.ymlにある場合
- %sのみのformatがあれば、それがIDsという表記で現れる。出現順はformatにしたがう
- %sのみのformatがない場合（GOのようなケース）はIDsがリストに現れない。先頭に指定されたformatがデフォルトで使用される
- 決定） APIの仕様を変更しないので、両者の一貫性を重視して、IDsは必ず選択肢にあることとする。かつ、選択肢の先頭にIDsが現れる。formatには%sのみの値は運用上記載しない
- formatがdataset.ymlに無い場合は、IDsのみあり、実質的に%sのことである
- APIのprefxに関する仕様もGUIの改修と併せて揃えたほうが良い
- APIの入力としてはprefix付きのIDも受け入れられるが、出力にprefixをつけて戻して上げる機能は無い
- formatの1つ目を自動付与して戻してあげても良いけど、formatを選べないという点に機能の片手落ち感がある
- ならば、現状そのまま、出力はprefixなしの値を返却する仕様を維持する
# 2022-05-24
## 更新作業の自動化
- Rakeを走らせている環境をコンテナ化するタスクが残項目のはず
- 実行周期は検討中のまま残ってしまっているが、他に技術的な課題が無いか整理してインフォ・ラウンジからご相談する
- 現状は同一の環境でRakeを回しているので、前回実行分のTSVがサーバーに残っている。それを活用して、更新すべき対象を判定することができている。でも、コンテナ化してしまうと前回実行分のTSVを新しいコンテナに引き継ぐ方法を考えねばならない
- ファイルのタイムスタンプが重要なので、タイムスタンプを引き継げるようなやり方が求められる。現在70GBほど
- キャッシュしているファイルにおいても、タイムスタンプ重要。現在238GBほど
- EFS使えばタイムスタンプ引き継げるのではないか。EFSはそんなに高価ではない。バーストも効く。EFSに対しコンテナから直接読み書きしてしまう？
## 各種ソースコード
- Githubにtogoidのorganizationを作ってしまう？
- https://github.com/togoid 作っていただきました
- togo-idではなくtogoidでリネーム
- 現在インフォ・ラウンジのorganization配下にある各種togoid関連レポジトリを移していく
- 順次可能ならOSSにしていく。issueとかPRが来たときの対応方針は予めすり合わせておきたい
- togo-id-converter(JSのアプリ)
- 現状はAmplifyで自動デプロイしている
- DBCLSさんの慣例に沿うと、レポジトリのオーナーシップをインフォ・ラウンジからDBCLSさんに移譲する形
- そして、ソースコードはOSSにしてしまう。インフォ・ラウンジはcontributorとして残る
- togo-id-api-flask
- 現状はGithub Actionsで自動デプロイしている
- レポジトリ移管に伴い、おそらくGithub Actionsのsecretは取り直しだろう
- ステージング環境をDBCLSさんのAWS配下に構築したい
- API(Lambda)やクライアントアプリ(Amplify)に加え、RDSのセットアップも必要そう
- インフォ・ラウンジが構築した開発環境は頃合いを見て閉鎖する
- togo-id-alert
- 大田さんのお手元で動作確認をいただく
- togo-id-admin-lambda
- S3の更新イベントを検知して更新スクリプトをキック
- togo-id-iac
- 環境を完全に新規立ち上げるときに使用する
# 2022/03/16
- /ontology には https://github.com/dbcls/togoid-config/blob/main/ontology/togoid-ontology.html を配置する
- 変換結果が 10000+ だった場合の左辺は "Unknown"改め"-"にする
- ランダムサンプリングして変換して、オーダー出せないか？（守屋）→無理っぽいか
- 22(火) リリース予定
-
## DBCLS から
> Toshiaki Katayama 10:07
> データ更新状況とかデータ数などの統計情報もサイトに載せる方が良いのですがどうしましょうかね、自動更新でMarkdown生成してDOCUMENTSからリンク貼りますか、SPARQLエンドポイントとか載せるのと合わせて。
- DBCLSで対応
# 本番環境へのリリース
- 更新の手順
- Webapp https://github.com/InfoLoungeLLC/togo-id-converter のDBCLS移行
- https://github.com/dbcls/togoid-config/tree/link-to-tio ブランチの合流はすぐやってOK
-
# 2022/03/08
## 開発環境への適応内容
- データセット間の関係性を https://raw.githubusercontent.com/dbcls/togoid-config/main/ontology/togoid-ontology.ttl から取得する改修（データ更新スクリプトの中でontologyを取得してconfig.yamlとマージしてデータベースに格納しています）
- 各変換経路の左辺に表示される数値を、入力されたIDのうち変換に成功したIDのユニークカウントに変更
- レイアウトの微調整
- APIドキュメントの更新 (開発環境のAPIドキュメントはこちら https://togoid.dbcls.jp.il3c.com/apidoc/ )
- configのexampleをuniprotに変更
- databasesのdescriptionもuniprotに
- convertのreport引数からverboseを削除、
- convertのlimit引数にmaxが10000である旨を追記
- relationのexample
- glytoucan-uniprot
- ontologyファイルの実体をtogoidのアプリと同じ領域にホストする
- https://togoid.dbcls.jp/ontology
-
## 運用
- API Gatewayの5XXエラーを検知してSNSでメール通知する設定 https://github.com/InfoLoungeLLC/togo-id-alert
- Rakeの実行タイミングをどうする？
- 平日中に対応しやすいように、毎週なり隔週なり月曜から更新かけて平日内に監視対応作業を集約する？
- 例えば第一、第三月曜日
- 各データセットの取得並列化は今後の課題
# 2022/02/22
- NavigateモードでResultsを見るとエラーになる問題を修正済み
- Datasetsタブで凡例が実際のデータセットリストとマッチしていない問題を修正済み
- 各変換プロセスにおける右辺の数値がユニークIDのカウントとなるように実装調整中
- データセット間のリンクをオントロジーから取得して表示するよう実装調整中（データ更新フローにも影響があり、少し広い改修となっています）
- データの更新が正常に完了したかどうか (=productionに反映されているデータの最終更新日がいつか) を GUI 上で表示できないか？
- 改修は必要だができるはず
- APIドキュメントのアップロードも作業予定
## API調整事項確認
### /convert
- キー名を include= → report=
- All → All converted IDs （デフォルト）/ API: all
- Origin and targets → Source and target IDs / API: pair
- Target → Target IDs / API: target （デフォルト）
- Verbose → All including unconverted IDs / API: なし、にする
- /convert のオプションから total, converted をなくす
- オプションにもJSONにも、常に total, converted は出さない
- 将来的に total カウントだけだす API を用意するかどうか → やめる
### /count
- /count/ds1-ds2?ids=xxx,yyy,...
- /count/hgnc-ensembl_gene?ids=hgnc1,hgnc2 → [ 4, ? ]
- /count/hgnc-ensembl_transcript?ids=hgnc1,hgnc2 → [ 4, 52 ]
- 渡したidsの変換できたIDと変換結果のIDのユニークカウント
- 返却するのは [ 数字, 数字 ] よりも { source: 数字, target: 数字 } の方が明確かも、ご検討ください
### /config
- /config/dataset?name=データセット名 → /config/dataset/データセット名 に変更
- /config/database?src=データセット名1&dst=データセット名2 → /config/relation/データセット名1-データセット名2 に変更
- （destination → target に統一、という話になったがそもそも引数として不要ということに）
- （データセット名1-データセット名2 の一覧が引数なしで返ってくるのでこの組み合わせ自体がrelationのIDだろうと）
# 2022/02/08
## アプリケーション
- データベース間のlinkのlabelを表示
- EXPLOREモードで3ステップ以上の変換結果が誤っていた不具合を修正
- DATABASESタブに凡例を追加
- 結果取得モーダルのレイアウト調整
をレビュー環境に適応しました。
https://togoid.dbcls.jp.il3c.com/
Basic Auth : togoid / TgZMWVTD3Eo5ZV97tZ6u
### DBCLSより修正提案
- DATABASESタブはDATASETSタブにリネーム
- DATABASESタブの凡例を[最新版](https://github.com/dbcls/togoid-config/blob/main/config/dataset.yaml)に更新
- Color Legendというタイトルをつける (Dataset name Index とは段落を分ける)
- dataset.yaml の category: にはクラス名が書いてあるので SequenceRun という CamelCase 表記になっている。オントロジーファイル内では SequenceRun クラスの label に Sequence run という表記が書いてあるし、厳密に言えばそれを取ってくるのが正しい。が、このような例は SequenceRun だけなので、よしなにしてもらえれば
```
Gene, Transcript, Ortholog, Probe: #53c666
Protein, Domain: #a2c653
Structure: #c68753
Interaction, Pathway, Reaction: #c65381
Compound: #a853c6
Glycan: #673AA6
Disease: #5361c6
Variant: #53c3c6
Taxonomy: #006400
Analysis, Experiment, Project, Literature, Sample, SequenceRun, Submission, Function: #696969
```
- Try keeping route と Clear ボタンはUIから削除
- Input from textfile の下に Reset ボタンを設置
- テキストボックス右上の x ボタンも消すかどうか
- Convert from の行も消す
- 変換ID数の表記
- 
- verbose の表記を変更する
- API の include オプションで使う単語も決める
- (API の default は target)
- IDs that were not converted の表記も改める
- ここで表示されるIDについては、出発IDに対して最終的に変換できなかったIDのみを表示する、ように変更
- property name の表示
- property の方向性を示すデザイン
- datasetを選択したら、そのpropertyを線と同じ色で囲って強調する
- Resultsでも同じ表現を採用する
- APIの変更仕様
- /config/dataset?name=データセット名 → /config/dataset/データセット名 に変更
- /config/database?src=データセット名1&dst=データセット名2 → /config/relation/データセット名1-データセット名2 に変更
- （destination → target に統一、という話になったがそもそも引数として不要ということに）
- （データセット名1-データセット名2 の一覧が引数なしで返ってくるのでこの組み合わせ自体がrelationのIDだろうと）
- /convert のオプションから total をなくす
- 常に total は出さない
- 将来的に total カウントだけだす API を用意するかどうか
## 運用 (おおた)
### ディスク飽和による検索エラーについて
- tmpが詰まっていた模様, failover で復活
- https://sparqlthon.slack.com/archives/C01CSCHFYSD/p1643185488021959
- 原因?
### ログの形式について (done)
- Common Log Format に変更してもらいました、ありがとうございました
- https://sparqlthon.slack.com/archives/C01CSCHFYSD/p1643814102887229
### モニタリングについて
- https://sparqlthon.slack.com/archives/C01CSCHFYSD/p1643185906541599
- 目的はサービスの状態の監視
- サイトがアクセス可能かどうかは監視できている
- エラーが起きているかどうかをチェックしたい
- API Gateway で起きたエラーを slack で通知できるとよい
- 逐一よりもDaily?
### データ更新プロセスのエラーとエラー処理について
- disk full で更新スクリプトが死亡
- https://sparqlthon.slack.com/archives/C01CSCHFYSD/p1644220792287749
- 原因？
- ロード途中で死ぬとスケールアップしたままになってしまうので、エラーが起きた場合にはスケールダウンするなどの後処理を入れる必要がありそう
- データの更新が正常に完了したかどうか (=productionに反映されているデータの最終更新日がいつか) を GUI 上で表示できないか？
###
# 2022/01/26
## production環境のAPIが返ってこない場合がある
- MySQLのディスクがフルになっているよう。引き続き調査する
## アプリケーション
- databasesページのUI改善を適応済み
- デザインはアップデート予定
- データベース間のリンク表現やUIバランスの調整は引き続き取り組み中
- リンク表現については専用のontologyを作成中
# 2022/01/13
## 変換成功入力ID数の返却APIを実装しました。
例）
https://api.togoid.dbcls.jp.il3c.com/convert?ids=CHEMBL1917897,CHEMBL3237997&route=chembl_compound,chembl_target,ensembl_gene&format=json&include=verbose&converted=true
開発版アプリケーションにも反映しました。
https://togoid.dbcls.jp.il3c.com/
## ２月末納品に向けて
### アプリケーション側残タスク
- togoid-configにおける各データベースのconfig.yamlのlinkのlabelを表示する機能
- 各DBの関係性には方向があるのでUI上もそれを示す
- レイアウト調整（Submitボタンのバランス、ResultsモーダルにおけるDB間の接続ラベルのレイアウト等
- その他、フィードバックシートから対応すべき項目があれば
- https://docs.google.com/spreadsheets/d/16Xl8Xc74jmR6iGbXAhzufIOv9onZswIk_sEoCfC6rrQ/edit#gid=638831521
- DBCLSにて検討いただく
### インフラ側残タスク
2.3.1 ECS Batch を用いたデータ更新の定期実行系の構築
- インフォ・ラウンジにてDocker化検討作業中、インフォ・ラウンジボール
2.3.2 データ整合性チェック機構の開発
- a. TSV生成後のデータの整合性確認 は上記のDocker化が済めば連動して完了
- b. データロード後のAPI動作確認 はチェックスクリプトは山本さんが実装済み
- https://github.com/dbcls/togoid-config/tree/main/test/test_api.pl を実行する
2.3.3 システムのモニタリングと通知の自動化
- RDS以外はあまりモニタリングが必要な対象はなさそう
- オートスケールを設定するか、CPU使用率に対してアラートを仕込むか
- 欲しいモニタリングとしては、APIの500エラーやタイムアウトの頻度など（大田さん）
- 大田さんから、欲しいモニタリング項目の一覧をいただく
- ログファイルを単一にマージできるか
- DBCLSの規定？でログファイルの一式を提出する必要がある。この作業を簡便にしたい
- まずはAWSコンパネのGUIから全件ダウンロードできるかもしれず、お試しいただく
- 入力されたIDの総数をログから収集できないか
- 少ない数のIDを入力するユーザがどれくらいいるか、大量のIDを投げつけてくるユーザがどれくらいいるか、などなど
- なんらか独自のロギングを入れる必要があり。API Gatewayに送られてきたパラメータをそのままどこかに吐き出す？
- ★APIのpythonコードの中にIDのリストをログに吐き出すような実装を試行する
### APIの逆引き指定パラメータ
現状の仕様で進める。なお、パラメータの渡し方は下記のいずれも等価
```
curl https://api.togoid.dbcls.jp.il3c.com/convert -d "ids=0005854" --data-urlencode "route=mondo,<nando" -d "format=json"
curl https://api.togoid.dbcls.jp.il3c.com/convert -d "ids=0005854&format=json" --data-urlencode "route=mondo,<nando"
curl https://api.togoid.dbcls.jp.il3c.com/convert -d "ids=0005854&format=json&route=mondo,nando"
```
## 次回
1/26(水) 16:00-17:00
# 2021/12/22
## 変換成功入力ID数の返却API仕様案
APIのoptionにconvertedパラメータを導入する。
convertedにtrueに評価される値が渡された場合、変換成功入力ID数を`converted`キーに返却する
例）このような変換結果があったとき、**totalは3、convertedは2**になる。
```SQL
select
t1.src_id,
t2.src_id
from
`chembl_compound-chembl_target` as t1
left join
`chembl_target-ensembl_gene` as t2 on (t1.dst_id = t2.src_id)
where
t1.src_id in ("CHEMBL1917897", "CHEMBL3237997", "CHEMBL536521")
;
>
+---------------+-----------+
| src_id | src_id |
+---------------+-----------+
| CHEMBL1917897 | NULL |
| CHEMBL1917897 | NULL |
| CHEMBL1917897 | NULL |
| CHEMBL1917897 | NULL |
| CHEMBL1917897 | NULL |
| CHEMBL1917897 | CHEMBL206 |
| CHEMBL1917897 | CHEMBL242 |
| CHEMBL1917897 | NULL |
| CHEMBL1917897 | NULL |
| CHEMBL1917897 | NULL |
| CHEMBL1917897 | NULL |
| CHEMBL3237997 | NULL |
| CHEMBL3237997 | NULL |
| CHEMBL536521 | NULL |
| CHEMBL536521 | NULL |
| CHEMBL536521 | CHEMBL286 |
+---------------+-----------+
```
APIレスポンス
```json
{
"ids": [
"CHEMBL1917897",
"CHEMBL3237997",
"CHEMBL536521"
],
"route": [
"chembl_compound",
"chembl_target",
"ensembl_gene"
],
"total": 3,
"converted": 2,
// "converted": [{in:2, out:5}, {in:4, out: 10}], # 変換できた入力ID数
"results": [
[
"CHEMBL1917897",
"CHEMBL206",
"ENSG00000091831"
],
[
"CHEMBL1917897",
"CHEMBL242",
"ENSG00000140009"
],
[
"CHEMBL536521",
"CHEMBL286",
"ENSG00000143839"
]
]
}
```
# 2021/12/8
### APIの逆引き指定パラメータ
動作例: `nando-mondo`テーブルはあるが、`mondo-nando`テーブルはない。`nando-mondo`はreverse可。
#### mondo -> nando
```bash
# 既存動作(順引きできないが逆引きして出している)
$ curl "https://api.togoid.dbcls.jp.il3c.com/convert?ids=0005854&route=mondo,nando&format=json"
{
"ids": [
"0005854"
],
"route": [
"mondo",
"nando"
],
"total": 2,
"results": [
"1200278",
"2200430"
]
}
```
```bash
# 順引き指定ではエラー
$ curl https://api.togoid.dbcls.jp.il3c.com/convert -d "ids=0005854" --data-urlencode "route=mondo,>nando" -d "format=json"
{
"message": "no route: mondo > nando"
}
```
```bash
# 逆引きならOK
$ curl https://api.togoid.dbcls.jp.il3c.com/convert -d "ids=0005854" --data-urlencode "route=mondo,<nando" -d "format=json"
{
"ids": [
"0005854"
],
"route": [
"mondo",
"nando"
],
"total": 2,
"results": [
"1200278",
"2200430"
]
}
```
#### nando -> mondo
```bash
# 既存動作（順引きできる）
$ curl "https://api.togoid.dbcls.jp.il3c.com/convert?ids=1200278&route=nando,mondo&format=json"
{
"ids": [
"1200278"
],
"route": [
"nando",
"mondo"
],
"total": 1,
"results": [
"0005854"
]
}
```
```bash
# 順引き指定
$ curl https://api.togoid.dbcls.jp.il3c.com/convert -d "ids=1200278" --data-urlencode "route=nando,>mondo" -d "format=json"
{
"ids": [
"1200278"
],
"route": [
"nando",
"mondo"
],
"total": 1,
"results": [
"0005854"
]
}
```
```bash
# 逆引きはできない
$ curl https://api.togoid.dbcls.jp.il3c.com/convert -d "ids=1200278" --data-urlencode "route=nando,<mondo" -d "format=json"
{
"message": "no route: nando < mondo"
}
```
- UIレビュー
- [https://docs.google.com/spreadsheets/d/16Xl8Xc74jmR6iGbXAhzufIOv9onZswIk_sEoCfC6rrQ/edit#gid=638831521](https://docs.google.com/spreadsheets/d/16Xl8Xc74jmR6iGbXAhzufIOv9onZswIk_sEoCfC6rrQ/edit#gid=638831521)
-
# 2021/11/17
## 開発状況
https://togoid.dbcls.jp.il3c.com/
Basic Auth : togoid / TgZMWVTD3Eo5ZV97tZ6u
- 実行した変換に対応するAPIのURLをコピーする機能
- verboseな変換結果をアプリに表示する機能
- 逆変換を指定するAPIの仕様案
- routeのパラメータそれぞれに@forwardと@reverseをつけられるようにする（optional）
- 何もなければ既存動作のまま（順引き -> 逆引きの順でルート検索）
- @forwardが指定されたら順引きのみ、逆引きは検索しない（順引き限定）
- @reverseが指定されたら逆引きのみ、順引きは検索しない（逆引き限定）
```
# ↓を refseq => uniprotは逆引き限定、uniprot => interproは順引きに指定する
?route=refseq,uniprot@reverse,interpro
# ↓を refseq => uniprotは順引き限定、uniprot => interproは逆引き限定に指定する
?route=refseq,uniprot@forward,interpro@reverse
# ↓を refseq => uniprotは逆引き限定、uniprot => interproも逆引き限定に指定する
?route=refseq,uniprot@reverse,interpro@reverse
```
URLエンコード不要文字
```
!'()*-._~
```
- @forward, @reverse
- テーブル名に修飾子をつけるので、"ルートが反転する"ということが伝わりづらい
- 大なり、小なり記号
- 人間の目には見やすいが、URLエンコードしないといけないのが欠点
- URLエンコードしなくてもサーバー側で取り扱えるならば、最もわかりやすいのでは？
- 動作検証してURLエンコードしなくてもcURL等で受け付けられるならこの仕様が良さそう
- ?route=refseq,>uniprot,\<interpro
- カンマのみのときは現状の動作（逆引きのフェールセーフつき、大なり記号つきなら順引き限定、小なり記号つきなら逆引き限定
- ?route=refseq,<>uniprot,\<interpro
- <>でUNION
- ?route=refseq,*uniprot,\<interpro（有力候補）
- *でUNION
- *でUNION、-で逆引き限定
- ?route=refseq,*uniprot,-interpro
- 順引き限定の記号をどうする？
- URLエンコード不要というメリットあり
- "-"で逆引き限定
- 順引きに限定するための記号はどうする？そもそも順引きに限定するニーズはあるのか
- 順引き限定とは別の話として、順引き逆引き両者のUNIONをしたいというニーズもあった
- "+"はURL中のスペースに対応するので、"+"を導入する際にもURLエンコードが必要
## 更新系現況
- https://github.com/dbcls/togoid-config/issues/100
- tsvの全生成は、現状シングルプロセスだと24時間以上かかる
- 並列実行は可能なように実装されているので、短縮可能
- 現状の想定では、2週間に一度実施するイメージ
- 現状、全データの生成のために700GBくらいストレージを使っている
- 半分以上はttl, tsvは80GBくらい
- ECS単体だと700GB確保するのは難しい
- NFSマウントせねば
# 2021/10/27
## 開発状況
- 変換先を指定してルートを逆算するオートパイロット機能等
-
## ログについて (DBCLSより)
- TogoID API gateway のログを手元にdumpしたい
- Cloudwatch `/aws/api-gateway/togo-id-api-prd` が log group が細分化されており cli でダウンロードするのにかなり時間がかかってしまいました、何かいい方法があるでしょうか
# 2021/10/07
## 新規ペアの追加
- glytoucan-uniprot
- glytoucan-doid
## TogoID のポスター発表で頂いたご意見および発覚した不具合
- InChi key も使いたい
- 化合物チームでデータを確認して検討中
- ペアセット全体でダウンロードしたい
- http://ep6.dbcls.jp/togoid/link/current/output/ は現状でも一応外から見える。リンクを TogoID ウェブサイト上に載せる？
- ダンプがほしいという問い合わせが来たら都度個別に対応する
- スライドにある「TogoID を構築して分かった課題」にあるような苦労は、ドキュメントかどこかにまとめておくと有用かもしれない
- [トーゴーの日のスライド](https://biosciencedbc.jp/event/symposium/togo2021/files/poster03_togo2021.pdf)へヘルプページからリンクしておく
- togoid-configにも書く。wiki or github.io?
- 「ID変換のセマンティクス」をきちんと仕上げて論文化
- 入力の末尾に改行があると、変換後のテーブルが表示できない
- 9/2に修正依頼し、修正済みを確認も、また復活した?
- ツリーに表示される数値の意味がわかりにくい
- (後で気づいたが、)最終的なペアの数ではなく、ゴールの ID をユニークした数になっているっぽい。要修正。
- MatchedはOK
- 2列目移行の数字の意味を表記したい
- results? pairs? にしてinfoボタンを付けて説明ページに飛ばす?
## 開発状況
- 2.1.3 変換できなかったIDを保持する機能の開発
- 2.1.5 エクスポートの際のプレビュー機能の開発
- 2.2.1 APIにおいて変換できなかったIDを保持する機能の開発
- 2.2.2 変換ルートの正引き逆引きを指定する機能の開発
# 2021/09/02
## 次期開発
-
## データ更新自動化
## エラー報告
- ID入力フォームにIDを改行区切りで入れた場合（エクセルで値をコピペした場合）、一番最後の行に改行が入ったまま検索を実行すると、Results画面が表示されなくなる(高月)
# 2021/08/19
## 次期開発
- Docs版: https://docs.google.com/document/d/1Ld1FCLK7bEEFZxtE6UP5hnS75M1x_lU8/edit
- 2.3 システムの高度化 を大田さんが追記
- 内容問題ないでしょうか? >インフォラウンジさん
## データ更新自動化
- [Slackで進行中](https://sparqlthon.slack.com/archives/C01CSCHFYSD/p1628652723023600)
-
# 2021/8/5
## データ更新
## APIのキャッシュ化対応(山本さん)
- クエリの最適化はできそう
-
## 次期開発？
- https://drive.google.com/file/d/1Ld1FCLK7bEEFZxtE6UP5hnS75M1x_lU8/view
- Docs版: https://docs.google.com/document/d/1Ld1FCLK7bEEFZxtE6UP5hnS75M1x_lU8/edit
- 2.2.2 変換ルートの正引き逆引きを指定する機能の開発
- sparqlのプロパティパス記法を使えばすべて表現できそうだが、"route=db1,-db2,db3だとdb1とdb2の間は逆引き、db2とdb3は正引きといった記法？""で最低限は賄えそう
- サーバーサイドのタスク切り分け
- Rakefile自体の改修はDBCLSさんで対応いただくが、それをECS Batch化する作業をDBCLSさんかインフォ・ラウンジがやるか検討したい
- インフォ・ラウンジがバッチ化するのが自然だろう
- Rakefileを動かすにはperlとかrubyとかpython、Shellscriptなど色々な言語が動かないといけないその環境を含めてコンテナ化する必要がある。この作業はインフォ・ラウンジが担当しつつも、DBCLSさんにも支援いただかねばならないだろう
- ロード後のデータ整合性チェックについても、チェック項目はDBCLSさんに検討いただき、チェックするための実装はインフォ・ラウンジが行う
-
# 2021/07/20
## 7/8に無事サービスイン
- [TogoIDを公開しました。](https://dbcls.rois.ac.jp/ja/2021/07/08/post1.html)
## バグ修正
- EXPLOREのiボタンを押したときに出るDescription にも Cited from Integbio Database Catalog を入れていただけますか。
- また、EXPLORE、DATABASES のいずれもDescription本文の後の Cited from Integbio Database Catalog の前に改行を入れていただきたいです。
- [｢対応する変換先 ID が見つからなかった入力 ID｣のバグ](https://sparqlthon.slack.com/archives/C01CSCHFYSD/p1626238694041100)
- 修正済み
- 別件
- 逆変換の候補テーブルを抽出する際に、そのテーブルがconfigによって逆変換を許可しているかどうかのチェックをせずに候補を選定してしまっていた
- 例えばinterpro-pubmedは逆変換を許可していませんが、アプリ上にこの逆変換を候補として表示してしまっていた。
- この問題についても、修正済
- Disease関係IDのデータ更新･取得に失敗
- 修正済み(高月さん)
- データ元のグラフ名が更新されていた
- rakeファイルの不備が見つかったので修正対応中(片山さん)
## APIのキャッシュ化対応(山本さん)
- APIのストレステストのようなことを先日行ったが、初回リクエスト時にタイムアウトが頻発してしまう問題があった
- MySQLのキャッシュはあるが、API側にはキャッシュはない
- APIに送信されるクエリごとにキャッシュされるので、初回立ち上げ時にウォームアップ的にいくつかクエリする、ということでは不十分
- DBCLSさんの既存サービスではMySQLのindexを/dev/nullに投げるなどしている。今回のようなAWSのマネージドサービスを使ってしまっているとなんらかアプローチを考えねばならない
## アクセスログ・アラート(大田さん)
- アクセスログ
- webapp
- Google Analytics 入れる？
- [CloudWatch](https://ap-northeast-1.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1#logsV2:log-groups/log-group/$2[…]api-gateway$252Ftogo-id-api-prd)でログ取っている
- API
- 形式
- apache 等の Common Log Format で定期的に取得 or S3等にエクスポートしたい
- オンプレのサービスと合わせて集計スクリプト(AWstats)を実行する必要があるため
- アラート
- 安定するまでは stats を通知?
- slack?
## AWS上でのtogoid データ更新自動化
- テストが必要。オンプレから更新して自動でデータベース更新のテストを行う(大田さん)
- togoid-configに新規IDペアを追加した時に、RDSにテーブルが自動追加される？(高月さん)
- されません。
- Rakeでtogoid-configにあるスクリプトをもとにTSVを作って(片山さん)、(更新ごとに作成されたIDペアTSVのチェックをして)、S3にアップロードし(大田さん)、それを検知してRDSにテーブルが追加される(インフォラウンジさん)
- これをなるべく自動化したい。
- 更新ごとに作成されたIDペアTSVのチェックも要る
- config のリリース作成とS3へのアップロード action 作成済み (おおた)
- https://github.com/dbcls/togoid-config/blob/main/.github/workflows/create-release-upload.yaml
## 次回予定
8/5(木) 13:00
# 2021/07/01
## UI関連
- 修正ありがとうございます!
- Topページ
- フッターの著作権表示を **©2021 DBCLS** にする
- 入力窓下のExamplesは改行区切りで入力
- Examplesの ' を取る
- Examples にして上に詰める
- DATABASES
- 各DBのdescriptionの下に、引用情報を書く
- Cited from [Integbio Database Catalog](https://integbio.jp/dbcatalog/record/**ID**)
- 各DBから、一番トップに戻れる、Go to Top ボタンを付ける
- インデックスの部分は DB Name Index とか見出しをつける?
- 各エントリのフォントを"Try ID set Examples"のフォントにするとかっこよさそう
- ↑見送り
- DOCUMENTS
- [help_ja.md](https://github.com/dbcls/togoid-config/blob/docs/docs/help_ja.md) 突っ込みました。
- 背景色とフォントのサイズを他のタブと合わせる
- 日･英切替ボタンの設置
- 7/7にニュース掲載予定。週明けまでに上記を対応する
## データ更新
> バケット内に config tsv と2つディレクトリを作っておいて、configの方も更新を通知するための空ファイル update.txt を作って、この更新日を見てDBの方をアップデートする
- S3のtsvあるいはconfigフォルダにupdate.txtがアップロードされたアクションにトリガーして取り込み処理を走らせる実装をしてテスト中
- 実運用環境のs3に現時点でTSVをアップロード済み
- 今から取り込み処理を走らせれば、一旦プロダクションDBを最新の状況にすることができる
- 継続的にAWS Batchに作り変える。今はEC2の中で走らせている
- update.txtが整ったら大田さんからご一報いただく→対応済み
## API
- 単純な単一テーブル変換で100IDを10リクエスト同時に投げると結構タイムアウトする印象
- そんなに重くない処理のはず
- API GatewayとかLamddaはパラライズ得意
- 再現用のスクリプトを山本さんからお預かりする
- Lambdaのスタッツ表示をインフォ・ラウンジにて準備する
# 2021/06/24
## UI関連
- 入力窓下のExamplesは改行区切りで入力
- Documents改めHelp
- ドキュメントにSwagger
- ResultsモーダルのRouteの下に等価なAPI呼び出しのURL？
- API URLを直接コピー
- cURLコマンドを直接コピー
# 2021/06/11
## DBCLSから
- dataset.yaml の更新 を反映してほしいです〜
- 設定ファイルの更新系もこれから方法を検討する
- CIの有無によるパフォーマンスの違い
- もとからCIで対応していた
```
MySQL [togo_id]> SELECT @@character_set_database, @@collation_database;
+--------------------------+----------------------+
| @@character_set_database | @@collation_database |
+--------------------------+----------------------+
| utf8mb4 | utf8mb4_general_ci |
+--------------------------+----------------------+
1 row in set (0.00 sec)
```
## データベース更新フロー
- データベース更新の起点となるS3のバケット作成処理をCloud Formationに追加する（インフォ・ラウンジ担当）
- 開発中のインポートスクリプトはupdate.txtというテキストファイルがS3にアップロードされる想定をしている。このサンプルをDBCLSにご提供する
## DBCLSのTODO
- ドキュメントのたたき台作成
- 正式リリースアナウンス前のレビュー → SPARKLthonオフライン or Slack で?
## 次回
2021/06/24(木) 14時から
# 2021/06/03
## WebApp
- IDの大文字小文字問題について、MySQLのCollationをciにするとした場合、検索速度の低下はどの程度か
- 背景は、PDBのIDが現状では大文字のみで格納されているところ、小文字の混じるIDをユーザが入力しても適切に検索をかける必要があるかもしれないこと。
- PDBは大文字小文字の違いはないが、DBCLS/NBDC側で大文字小文字の区別な必要なIDの有無について調査が必要。
- → パフォーマンスに大きなデメリットがなければ、MySQLの照合順序をcase insensitiveにする
- DLファイルでのPrefixの付け方
- 現時点では、変換後(経路も含め)のIDのみ、URLの一番最後の”/”の後ろが付けられる対応になっている
- InputのIDにもつけたほうがよい
- → そのように実装する
- 変換済みの経路を逆にたどることは不可とする。DBの変換候補から変換済み経路のデータベースは表示しないこととする
- 各データベースを示す四角いラベルと、それをマウスオーバーした時に表示されるアクションアイコン類のコントラストを調整する
- マウスオーバーしてアクションアイコンが現れたら背景の四角いラベルを暗くするなど
- ファビコンを作成し、掲載する
- Google Analyticsのようなアクセス解析ツールの導入については、DBCLSさんに可否を検討いただく
- API側についても、API Gatewayのログは把握しておきたい。どのログを記録してどのように集計するかはDBCLSさんにて検討いただく
## ベータリリース
- 現在DBCLSさんのAWS環境下にベータリリース用のデータを投入中
- APIの設置作業を進めているが、DNS設定はこのプロジェクトチームではない方に対応を依頼している。スムーズに設定が進めば明日6/4(金)にベータ公開が行える見込み
## ベータリリース後の進行
- データ及び togoid-config.yml の自動更新フローがまだ構築できていない。引き続き連携して設計・実装を行う必要がある
- S3にTSVをアップロードし、updates.txtのようなテキストファイルに取り込み対象のTSV名を列挙いただく想定
- togoid-config.ymlについても、Githubで変更検知したら自動デプロイというよりは、人間がチェックしてから適応するほうが当面は望ましい。これについてもS3に手動アップロードする方向で検討する
- アプリケーションについても、継続してフィードバックに対応していく
## 次回
6/11(金) 16:00-
# 2021/05/26
## アプリ & ベータリリースに向けて
- Prefix付きのIDについて、変換に不具合がある。早急に修正する
- 週内で再度アプリのレビューを行い、致命的な課題がなければ、可能な範囲でフィードバックを取り込んで6来週前半をターゲットにベータリリースを行う
- https://docs.google.com/spreadsheets/d/16Xl8Xc74jmR6iGbXAhzufIOv9onZswIk_sEoCfC6rrQ/edit#gid=0
- DBCLS共通のヘッダー&フッターを設置する https://github.com/dbcls/website/tree/master/DBCLS-common-header-footer/v2
- 将来的に、順方向の変換と逆方向の変換の両方の変換結果を取得したくなる可能性がある。ユースケースをDBCLSにて検討いただく
- Databasesのexamplesは、将来的にはデータベースごとに有用なIDサンプルを示すことが望ましい。ただ一旦は、 http://ep6.dbcls.jp/togoid/link/20210512/output/tsv から機械的にDBごとのIDを取り出してdataset.yamlに埋め込むこととする
- データベースの中身は現状のhttp://ep6.dbcls.jp/togoid/link/20210512/output/tsv でフリーズとする
## インフラ構築
- CloudFormationにはAPIとアプリの環境は含まれていない。APIはLambda Function、アプリはAmplifyでデプロイする予定
- API、Amplify共にGithub上にレポジトリを設置し、Github Actionsでデプロイするフローとする。まずはインフォ・ラウンジのプライベートレポジトリに環境を構築し、それをOwner TransferあるいはCloneしていただくことでDBCLSに移管する
- ベータリリースにおけるのデータベースへのデータ投入はインフォ・ラウンジで実施させていただいたほうが良さそう
- アプリ及びAPIのDNS設定はDBCLSにてご対応いただく
- 来週月曜あるいは火曜に大田さんとやり取りさせていただきながらベータリリース環境を構築する
## 次回
2021/6/3(木) 16:00
# 2021/05/19
## アプリ
- UI案の検討、実装状況のご共有
## データベース
- データベース更新自動化フローの整理とDBCLSさんとの役割分担検討
- 最新データの確認、テーブルが増えている？
1. S3にてTSVの受け渡し
- S3のアップロードされているTSVをマスターとし、データ受け渡しのインターフェースにすることできれいな設計になりそう
- TSVの生成チェックはtogoid-configのRakefile上で行うことが好ましい。様々なエラーパターンに対応するには、一年位運用経験を積まないといけないだろう
2. AWS Batchにより、定期的にS3上のTSVをチェック
- 定期実行ではなく、S3にupdate.txtのようなファイルを配置してもらって、そこにアップデートして欲しいDBのリストが書き込まれているという設計はどうか。Batch自体はS3のイベントにフックして起動する
4. TSVのハッシュ値を計算して、前回のハッシュ値と突き合わせる。何らかハッシュ値の保存方法が必要
- MySQLのconfigテーブルにハッシュ値を保存して比較可能にする
5. ハッシュ値が変わっていたらテーブル入れ替えのスクリプトをキック
## ベータリリースに向けて
- 6/1 のベータ版公開に向けた進め方
- インフォ・ラウンジからAWS環境へのAPI、DB、アプリ設置手順を示すメモを作成し、今週中に太田さんに共有
- アプリのUIフィードバック
- データベース名にはdataset.yamlのlabelを表示する
- 変換経路を線で結んで描画する
- ダウンロード、インフォメーション等のアクションボタンはデータベースのラベルにマウスオーバーをした際に表示する
- アクションボタンにクリップボードへコピーボタンがあると望ましい
- アクションボタンの表示位置はデータベースのラベルの四角形の中にある方がわかりやすいかもしれない
- 変換結果のプレビューモーダルには、フラットにアクションボタンを並べてしまって良い。クリック数を減らすため
- dataset.yamlのcategoryに従ってデータベースを色分けする。できるだけtogositeの配色を踏襲することが望ましい。現在dataset.yamlには25のカテゴリーがあるが、これをtogositeの分類（Variant, Geneなど）と対応付けをしていただく
- databasesの一覧には現在リンクのあるデータベースのみを表示する。fromあるいはtoに使用されているかどうかを判定する
- データベースのdescriptionにはデフォルトで英語説明文を表示する。日本語への切り替えを可能にするラジオボタンも設置する
- dataset.yamlにexamplesプロパティを追加する。DBCLSにてカンマ区切りで例となるidのリストを記述いただき、アプリ側ではそれをID入力欄の下に代表的なID変換の例として簡単に選べるようなUIを設置する
## 仕様書との照らし合わせ
- 初期のID入力にファイルインプットも可能にする（改行区切り、あるいはカンマ区切りでIDが列挙されたテキストファイル）
- 改行、スペース、カンマで区切られたテキストファイルを読み込み可能に
- "2.5. ID変換した結果を返すページ遷移機能の開発"
- 任意のウェブサイトへのリダイレクトを可能にすると、他サイトへのDDoS攻撃の踏み台に利用されてしまう懸念がある。将来的には、セッショントークンを発行するAPIを実装してリダイレクトを管理することでセキュリティを向上できると見込まれるが、短期的にはこの機能の需要は小さいと思われるため見送りとする。
## 次回
2021/5/26(水) 14:00
# 2021/05/12
## アプリ
UIフィードバックへの改善案の検討 https://hackmd.io/GlRhdq-6TsKzADKWcmVXjw
- 予め変換先データベースを決めているユーザーとそうでないユーザーが存在する
- 前者は、例えば使用するシステムが特定のデータベースのIDしか受け入れてくれないので手元のID群をそのDBのIDに変換したいケースなど
- 後者は、データベースにある程度詳しいユーザーなど
- 用途としてはどちらも価値があるので、両方カバーできるUIにしたい
- 変換経路を指定する上では、変換先データベースの変換結果がゼロではないことを予め知っておきたい
- 例えば変換先のデータベース候補が10個あった場合、現状のAPIでは10回変換APIをリクエストする必要があり、パフォーマンス上望ましくない。必要なAPIを検討する
- 変換結果がゼロだったデータベースは画面上グレーアウトとするか、それとも表示しないことにするか
- そのデータベースが変換候補には含まれていることを示すために、グレーアウトして選択不可とすることが望ましい
- 変換経路の指定途中では、変換元ID群の変換過程がプレビューできると望ましい。例えば画面の下半分に表が埋め込まれていて、行がID、列がデータベース名になっているなど
- 変換候補データベースの数が多いときにはプレビュー領域と変換候補データベース領域のバランスが難しいため、要検討
- 変換元と変換先を指定して間の経路はアプリに計算させるモードを設ける
- このとき、経路で中継する最大のノード数はアプリ側で制限する。仮に2ノードとして実装する
- 経路は複数導かれる場合がある。この場合、ユーザーに経路候補を選択させるUIを表示する
- 理想的には、任意のノード数ユーザー自身が経路を選択した上で、その末端ノードを支点として最終の変換先DBを自動計算できると望ましい
- 例えば、ある変換を行いたい時にわざとuniprotは経由したくないというケースが考えられるため
- ユーザーの能動的な経路探索と、アプリ側の自動経路探索が混ざったUIとなる
- 始点となるDBはユーザーに選択させる。すると、2列めに候補となるデータベースが表示されるが、その候補群とは別の領域に変換先DBをリストから選択できるUIも併設されている
- 変換経路を保存して再利用したいニーズはあるようだが、ユースケースは明確にできていない
- まずは、IDを入れ替えたときにもしそのID群が既存の変換経路とマッチするならば経路を維持することができればニーズを満たすだろう
- 自分の投入したID群のうち、変換過程でどのIDが最後まで変換できて、どのIDが途中で変換できずに終了したかを可視化できると望ましい
- どんなデータベースがサポートされていて、例えばどんな書式でどんなIDを投入すれば変換できるかをわかりたい
- DATABASEタブの中でデータベースの説明などを表示予定だが、ここにIDの例を含めて簡単にアプリ上で変換を試せるようなUIを用意する
## 次回
5/19(水) 10:00
### 次回アジェンダ
#### データベース
- データベース更新自動化フローの整理とDBCLSさんとの役割分担検討
- 4/25版データの要差し替えテーブルの確認
1. S3にてTSVの受け渡し
- S3のアップロードされているTSVをマスターとし、データ受け渡しのインターフェースにすることできれいな設計になりそう
- hourly, daily等のFrequencyを確認しながら、必要なTSVを生成してS3にアップロードする実装はDBCLSさんの環境化で行う？
2. AWS Batchにより、定期的にS3上のTSVをチェック
3. TSVのハッシュ値を計算して、前回のハッシュ値と突き合わせる。何らかハッシュ値の保存方法が必要
- MySQLのconfigテーブルにハッシュ値を保存して比較可能にする
4. ハッシュ値が変わっていたらテーブル入れ替えのスクリプトをキック
##### 課題
- ピンポイントで特定のテーブルを差し替えたいときどうするか
##### テーブルの差し替え時にサービス停止を避けるアプローチ
- RDSのクラスタにwriterとreaderの2台構成にし、テーブルの差し替えを直列に行う
#### API
- APIのPOSTリクエストパラメータをJSON形式に変更することの確認
# 2021/04/27
## API
- http://ep6.dbcls.jp/togoid/link/20210409/ 版のデータで投入を行いました。http://ep6.dbcls.jp/togoid/link/20210425/ も揃ったようですので、入れ替えを行います。
- 以下のIDペアはDBCLSで修正対応中です。
- uniprot-pfam は終わらなかったので上記の通り更新から外しています
- uniprot-ec は更新時に 502 Proxy Errorや 500 Internal Server Error が出ていたようで要確認
- oma_protein-uniprot はヘッダ行の削除が必要
- optionを返却するエンドポイントを追加しました。
```
$ curl "https://api.togoid.dbcls.jp.il3c.com/config/dataset?name=uniprot"
{
"label": "UniProt",
"catalog": "nbdc00221",
"category": "Protein",
"regex": "^(?:(?<id>[A-NR-Z][0-9](?:[A-Z][A-Z0-9][A-Z0-9][0-9]){1,2})|(?<id2>[OPQ][0-9][A-Z0-9][A-Z0-9][A-Z0-9][0-9])(?:\\.\\d+)?)$",
"prefix": "http://purl.uniprot.org/uniprot/"
}
```
```
curl "https://api.togoid.dbcls.jp.il3c.com/config/database?src=uniprot&dst=dbsnp"
{
"link": {
"file": "pair.tsv",
"forward": {
"namespace": "rdfs",
"label": "seeAlso",
"prefix": "http://www.w3.org/2000/01/rdf-schema#",
"predicate": "seeAlso"
},
"reverse": {
"namespace": "rdfs",
"label": "seeAlso",
"prefix": "http://www.w3.org/2000/01/rdf-schema#",
"predicate": "seeAlso"
}
},
"update": {
"frequency": "Monthly",
"method": "sparql_thread.pl -t 10"
}
}
```
### 発散するクエリの例
https://api.togoid.dbcls.jp.il3c.com/convert?ids=0016021&route=go,uniprot,hgnc&format=json
go→uniprotの変換で約3000万レコードに膨らむが、uniprot→hgncに変換すると約1万レコードに収束する
### API仕様
- limit
- SQLのLIMIT句に相当。デフォルト=10000, 1-10000の整数で指定可能
- offset
- SQLのOFFSET句に相当 。デフォルト=0, 0以上の任意の整数で指定可能
- include
- 出力するIDの出し方。デフォルト=target
- all:
- routeの全ID (例:uniprot_id, xxx_id, yyy_id, mondo_id)
- pair:
- sourceとtargetのID (例:uniprot_id, mondo_id)
- target（デフォルト）:
- targetのIDだけ (例:mondo_id)
- format:
- csv, tsv, json デフォルト=tsv
- total
- トータルを含めるかどうか、デフォルトはfalse。total={trueに評価できる値}でtrueにする
- totalの需要として、アプリのページング目的だけではなく、totalのカウントを元に計算をしたいケースもある
- APIのタイムアウトを調整して、うっかり重たいクエリが来てもDBに負荷をかけずに切断するようにする
- 仮に、MySQL側のクエリのタイムアウトを15sとする
- File Loadのときのタイムアウトもセットで短くなってしまわないように注意する
- routeパラメータで変換の重複は禁止する。A→Bという変換がrouteの中に複数出現したらエラーとする
- A→B→C→A→BはNG
- A→B→AはOK？
- A→B→C→B→AはOK
- 複数回APIを呼び直せば結局変換A→Bの重複ができてしまうから、やっぱり禁止することをあきらめる
### データベース
- 8プロセス同時実行で6時間弱に減少した。スクリプトの中でRDSのインスタンスサイズを大きくして取り込み処理を実行している。db.r5.2xlarge（$1.40USD/h）
- 取り込み処理実行時のAPIの瞬断や、レスポンスの遅延をできるだけ回避したい
- Daily更新が見込まれるので、サービスの安定性、運用にかかる費用等を丁寧に詰めていきたい
- ブルーグリーン方式というか、DBインスタンスを一度複製してからデータを差し替えて切り替える方式はどうか
- 複製そのものに時間がかかるかもしれないが、一度試行してみる
### アプリ
【アプリレビュー環境】
https://togoid.dbcls.jp.il3c.com/
Basic Auth : togoid / TgZMWVTD3Eo5ZV97tZ6u
- CSVダウンロード、URLダウンロード、IDダウンロード、クリップボードに結果をコピーする機能を実装しました。
### 次回
2021/05/12 13時から
# 2021/04/21
## API
- reverseを実装しました
- 手違いで、20210324版データを投入してしまっていました。再投入を行います
- POSTパラメータ、エラーハンドリングの対応
- ページングはlimit, pageにて実装 https://api.togoid.dbcls.jp.il3c.com/convert?ids=AP_000046,AP_000047,AP_000052&route=refseq_protein,uniprot,interpro&format=json&type=all&limit=3&page=2
### 変換候補のDBを返却するエンドポイントの追加
- config.yaml
## DB投入
【前提条件】
・DBインスタンス Aurora MySQL (Provisioned) db.r5.2xlarge (4core / 8 vCPU / 64GiB) <1.40USD/h>
・処理単位分 1,000,000 行 (約 20MB程度)
| 同時実行プロセス数 (N) | 同一テーブルに対してインポート (/MLine) | 全て別テーブルに対してインポート (/MLine) |
| ---------------------- | --------------------------------------- | ----------------------------------------- |
| 1 | 15 secs | 15 secs |
| 2 | 24～26 secs (12～13 secs/N) | 23 secs (11.5 secs/N) |
| 4 | 31～33 secs (7.5～8.25 secs/N) | 26～28 secs (6.5～7 secs/N) |
| 8 | 53～61 secs (6.625～7.5 secs/N) | 51 secs (6.375 secs/N) |
- データ更新フローの自動化にAWS Batchを検討中
- Labmda FunctionなどからKickすると、バッチ処理の間だけインスタンスが立ち上がる
## アプリ
まだ順方向の変換のみで、GUIアプリとして調整すべきこと・未実装は多々ありますが、新しいAPIと連携したアプリケーションです。
https://togoid.dbcls.jp.il3c.com/
Basic Auth : togoid / TgZMWVTD3Eo5ZV97tZ6u
- DBごとの色分け、アイコンについて
- アイコンの優先度は低い、どちらかというと色分けをtogo siteと揃えることと、似ている概念が似た色をしている
## 次回
2021/4/27(火) 11時
# 2021/04/16
## API
- API データベースの単位をデータベースのペアに変更し、最新のデータを投入しました。total件数の表示や、ページングにも対応しています。パラメータの調整も行いました。
- Reverse変換について、実装中です
- https://api.togoid.dbcls.jp.il3c.com/convert?ids=AP_000046,AP_000047,AP_000052&route=refseq_protein,uniprot,interpro&format=json&type=all&limit=3&page=2
## DB投入
- Aurora Serverless はインポート中にスケールダウンが発生すると処理が停止する現象が見られ、安定性に欠けるので通常のAuroraを使用する方向に変更
- 通常のAuroraでバルクインポートをする際に、DBサーバー側で一度メモリに全データを格納しているようで、大きなデータの場合にそこが律速になっている状況が見られたので、バルクインポートを行う前に、データを100万行毎に分割する処理を入れた。（interpro__uniprotで564分割）
- このサイズのバルクインポートでインスタンスのサイズを変えて、投入速度が頭打ちになるインスタンスタイプを探索したところ、db.r5.2xlarge になったので、インポート時のインスタンスタイプはこれに決定（$1.40USD/h）
- 全データの投入にかかった時間は 16.5 h 程度（インスタンス課金で$23.1）
- 通常使用時はdb.t3.small ($0.063USD/h)
- インポート時にaws apiでインスタンスタイプを自動的に上げるスクリプトは実装済
db.t3.small → 30.9時間
db.r5.large → 25.7 時間
db.r5.xlarge → 18.5 - 20.6時間
db.r5.2xlarge → 15.4時間
db.r5.4xlarge → 14.4 - 15.4時間
## 次回の予定
- 2021/04/21 14時から
# 2021/04/08
- curl -s "https://api.togoid.dbcls.jp.il3c.com/convert?source_ids=IPR027417&routes=uniprot,pdb&format=json" | jq
## API
- 変換結果が爆発するルートの変換検証を今後行う。再現しうるのは下記の候補か。これらは逆方向のリンク数であることに注意
- uniprot-go リンク数多すぎ問題
- 38357930リンク ID: 0016021
- 14150779リンク ID: 0005524
- 11323128リンク ID: 0046872
- 10595509リンク ID: 0005737
- 10178489リンク ID: 0003677
- 9915671リンク ID: 0005886
- 3921633リンク ID: 0016787
- 3878579リンク ID: 0016491
- 2953330リンク ID: 0003723
- 2863697リンク ID: 0006355
- uniprot-interpro リンク数多すぎ問題
- 10523155リンク ID: IPR027417
- 5101624リンク ID: IPR036388
- 4785182リンク ID: IPR036291
- 4163070リンク ID: IPR003593
- 3553194リンク ID: IPR036390
- 2769455リンク ID: IPR003439
- 2409690リンク ID: IPR029063
- 2144387リンク ID: IPR017871
- 2136301リンク ID: IPR009057
- 2124964リンク ID: IPR013785
- reverseの整理
- APIのパラメータでreverse変換を指定できる必要はない
- databaseA,databaseBというrouteが指定されたら、まずはdatabaseA_databaseBというテーブルを探す。見つかればそのテーブルで変換
- もしdatabaseA_databaseBが見つからなければ、databaseB_databaseAテーブルを探す。見つかったら、更に対応するconfig.yamlにreverseが定義されているかをチェック。reverseが存在しなければ変換しない。reverseが存在すれば、逆順で変換する
- マスターデータのTSVとしては、databaseA_databaseBとdatabaseB_databaseA両方のTSVを作成することはしない。RDF的には方向が違えば述語が異なるので意味があるが、今回のID変換では両者は単一のテーブルに統合し、forwardとreverseで整理する
- ページネーションを実装する
- limitの最大値は10000とする
- 少なくともcountは取得可能にする
- 内部的には2クエリ必要になる
- パラメータ名
- routesだと、変換経路が複数あるように見えるのでrouteに変更
- source_idsももっとシンプルにして、idsとする
- データベース更新の費用感
- 新しいデータベース構造に合わせてデータ投入を行う際に、インスタンスサイズの変動や要した時間などをインフォ・ラウンジからご共有する
- 月内にDBCLSのAWS環境内にインフォラウンジのAPIを移設し、気兼ねなくAPIを呼べる状況を目指す
# 2021/04/01
## API
- APIプロトタイプのご共有
- `curl -s "https://api.togoid.dbcls.jp.il3c.com/convert?source_ids=11099,11114&routes=refseq_protein,uniprot,ncbigene,refseq_protein,uniprot,orphanet,omim_phenotype&format=json" | jq`
- `curl -s "https://api.togoid.dbcls.jp.il3c.com/convert?source_ids=1012,25120&routes=hgnc,uniprot&format=json" | jq`
- 現実装ではsource_dbを指定しなくても変換できる実装としていたが、利用者のメリットが無いので開始DBの指定は必須である
- また現実装では、routesの最終がtarget_dbという解釈で実装している。source_db,target_db,routesの役割にやや重複があるのではないか
- ★データベース指定に関するパラメータをroutesに一本化する。routes=hgnc,uniprotのように開始と終了を指定し、間のデータベースを追加で指定することも可能とする
- 現実装では、投入されたIDが、最終DBにたどり着くまでにどのデータベースのどのIDに変換されたかの軌跡を出力することは難しい。それを記録するためには、1IDの1変換ごとに1SQLをリクエストする必要があるため
- いや、変換の回数だけ発行しているサブクエリ内で、取得結果にasで変数名を付与することで実現できるのではないか。実装を調整する
- 逆方向のID変換をしたいケースは存在する。どのようなときに逆方向変換を行うかには検討が必要だが、実装の準備をする。
- 逆方向変換を行うルールの候補
- 各DBペアのconfig.yamlにreverseが定義されている
- 逆方向にあたるDBペアがconfig/datasets.yaml
- ユーザーがAPIのリクエストパラメータにより逆方向変換を指定する
- 本日の検討後のAPI仕様
- routes: config/datasets.yaml のキーDB名をカンマ区切りで列挙(必須)
- include:
- （オプショナル、デフォルトはtarget）
- all:
- routeの全ID (例:uniprot_id, xxx_id, yyy_id, mondo_id)
- pair:
- sourceとtargetのID (例:uniprot_id, mondo_id)
- target（デフォルト）:
- targetのIDだけ (例:mondo_id)
- output:
- （オプショナル、デフォルトはid）
- id:
- ID文字列だけ (例:uniprot_id, mondo_id)
- uri:
- URIだけ (例:uniprot_uri, mondo_uri)
- id,uri:
- IDとURI両方 (例:uniprot_id, uniprot_uri, mondo_id, mondo_uri)
- format: csv, tsv, json（オプショナル、デフォルトはtsv）
## データ更新フロー
- https://github.com/dbcls/togoid-config のGithub Actionsにスケジューラーを設定し、定期処理でGithub Actions上でTSVを生成してコミットはせずそのままS3に送るフローを検討した
- しかし、Github Actions上で取り扱えるファイルサイズの上限が2.5GBらしいという情報があり、今回大きいTSVだと10GB近くなるため困難と判断
- 当初、Aurora Serverlessでのデータベース運用を検討したが、S3から直接TSVをMySQLに投入することができないことがわかったため、通常のAuroraに戻した。しかし通常のAuroraでは、投入処理を行うときのみインスタンスサイズを手動で大きくする必要がある
- 現在のデータを全て投入するのに半日、インスタンス使用量としても1万円近くかかる
- インスタンスサイズを投入のたびに手動変更することは現実的でないので、やはりAurora Serverlessを採用することとする。Aurora Serverlessならオートスケールが可能
- ただし、S3から直接TSVをDBに投入できない問題は残るので、S3を使わずにEC2を立ててそこにtogoid-configをcloneしてセットアップし、crontab等でTSVを生成し、更新があればMySQLの LOAD DATA INFILEでAurora Serverlessに投入する
## データベース設計
- 現状は巨大な単一テーブルだが、これに対して安全に更新を行うためには、テーブルごと、あるいはデータベースごと、さらにはRDSのインスタンスごと複製を作って更新し、差し替えるというフローが必要になる
- 日次で更新するデータベースもあるなか、これはコストが掛かりすぎるアプローチとなる
- 初期のアイディアに戻し、DBペアごとにテーブルを細分化する。
- uniprot-interproに更新があるときには、uniprot-interpro__newテーブルを作成して新規データを投入し、終わったらrenameして差し替えるイメージ
- これまで単一の巨大テーブルにしていたメリットは、source_dbの指定をしなくても変換できること。しかし、利用者としてはそのメリットは小さいのでこだわらなくて良い
## 次回
4/8(火) 14:00
# 2021/03/24
# 議題
- 現状確認
- 20210303 版の更新は uniprot-oma で落ちていて、残りはだいたい大丈夫
- 20210321 版の更新は uniprot-interpro, uniprot-go が途中で落ちていて不完全
- ここ数日の修正分を反映してもう一度更新をかける必要あり
- 残作業･要議論
- APIの仕様案
- こんな感じで呼びたい
- % curl -s -H 'Accept: text/csv' http://togoid.dbcls.jp/convert?source_db=uniprot&target_db=mondo&route=uniprot-xxx-yyy-mondo&source_ids=P####,Q#####,...&include=all:id(&format=csv)
- source_db, target_db:
- config/datasets.yaml のキーDB名
- route:
- source_db から target_db への変換経路（オプショナル）
- include:
- all: routeの全ID (uniprot_id, xxx_id, yyy_id, mondo_id)
- pair: sourceとtargetのID (uniprot_id, mondo_id)
- target: targetのIDだけ (mondo_id)
と
- id: ID文字列だけ (uniprot_id, mondo_id)
- uri: URIだけ (uniprot_uri, mondo_uri)
- id_uri: IDとURI両方 (uniprot_id, uniprot_uri, mondo_id, mondo_uri)
- の組み合わせ (例 all:id_uri, pair:uri, target:id など)
- format:
- csv, tsv, json くらい？
- 指定がなければ Content-type ネゴシエーション、それもなければデフォルト (tsv?)
- エラー処理とかも含めSwaggerか何かで定義したほうが良さそうですね
- UI、データロード、納品もろもろ発注部分の確認
- APIの仕様調整案（インフォラウンジ）
`% curl -s -H 'Accept: text/csv' https://api.togoid.dbcls.jp/convert?source_db=uniprot&target_db=mondo&route=uniprot-xxx-yyy-mondo&source_ids=P####,Q#####,...&include=all&output=id,uri&format=csv`
- source_db, target_db:
- config/datasets.yaml のキーDB名(必須)
- route: source_db から target_db への変換経路（オプショナル）
- include:
- （オプショナル、デフォルトはtarget）
- all:
- routeの全ID (uniprot_id, xxx_id, yyy_id, mondo_id)
- pair:
- sourceとtargetのID (uniprot_id, mondo_id)
- target:
- targetのIDだけ (mondo_id)
- output:
- （オプショナル、デフォルトはid）
- id:
- ID文字列だけ (uniprot_id, mondo_id)
- uri:
- URIだけ (uniprot_uri, mondo_uri)
- id,uri:
- IDとURI両方 (uniprot_id, uniprot_uri, mondo_id, mondo_uri)
- format: csv, tsv, json（オプショナル、デフォルトはTSV）
- APIの挙動
- 投入されるID群には、慣例上プリフィックスが付与されている場合がある。APIにはsource_dbが必須なので、そのデータベースのID正規表現と突き合わせることで不要な接頭辞は置換することが可能。DBには純粋なID部分のみ格納されているので、そのように加工してからクエリする
- 変換結果の件数はlimitされる。limit以上の件数が結果として存在する場合、APIレスポンスのヘッダー領域等にそれを通知するメッセージを返却する
- 複数のデータベースをホップして変換した場合、途中経過のjoinされたテーブルは数十万、数百万レコードにもなりうる。それはパフォーマンスに影響をもたらす見込み
- DBCLSで議論
- config/dataset.yamlのFIXME
- uniprot-go で何を何からひろうべきか
- uniprot-xxx は idmapping を使えばもう少し増やせるが必要？
- IDのペアの情報をどこでホストするか
- 現行のep6は暫定だけど、当面はこのままでも
- AWS EC2で取得しS3に置くのがよいのでは?
- 4月以降の運用の中で整理
- 今後の更新体制や分担
- TogoID全体としては、各データセットペアについて、なにを取り上げ、何を収録しないか、について判断を共有するページを作るとか
- 定例会や議事録をもつなどの体制を作って情報共有・公開しないといけない
- リンクのセマンティクスの整備
- 次期[LINC](https://linc-ai.jp/)との連携対応
# 2021/03/17
- テストサイト
- https://togoid.dbcls.jp.il3c.com/
- Basic Auth : togoid / TgZMWVTD3Eo5ZV97tZ6u
- システム構築
- AWSの見積もり
- 月間何ユーザくらいが変換しに来るか
- TogoWSで 数万/月 アクセス
- 数万、十万、百万アクセスでどのくらい見積もりが変わるか
- uniprot-go リンク数多すぎ問題
- 38357930 GO_0016021
- 14150779 GO_0005524
- 11323128 GO_0046872
- 10595509 GO_0005737
- 10178489 GO_0003677
- 9915671 GO_0005886
- 3921633 GO_0016787
- 3878579 GO_0016491
- 2953330 GO_0003723
- 2863697 GO_0006355
- uniprot-interpro リンク数多すぎ問題
- 10523155 IPR027417
- 5101624 IPR036388
- 4785182 IPR036291
- 4163070 IPR003593
- 3553194 IPR036390
- 2769455 IPR003439
- 2409690 IPR029063
- 2144387 IPR017871
- 2136301 IPR009057
- 2124964 IPR013785
- 次回 2021/03/24 17時〜
# 2021/03/08
- インフォ・ラウンジの開発環境でMySQLにpair.tsvをいくつか投入した。例えば、`hgnc-ncbigene`のようなテーブル名にauto incrementのidと、from、toの3カラムだけのもの
- MySQLと接続するシンプルなAPIを実装済み。API用のインスタンスを建てるとメンテナンスが必要になってしまうので、最終的には、AWS上にLambdaに載せる形でAPIを構築したい
- https://github.com/dbcls/togoid-config/blob/refactoring/config/dataset.yaml
- refactoringブランチにてアプリが使用するであろう設定情報を単一のyamlに集約してくださった。
- `internal_format` がDBに投入されるIDのフォーマット
- `external_format` がアプリ上で表示されるIDのフォーマット
- `catalog` プロパティはDBCLSで整備しているDBカタログのID。SPARQLエンドポイントに各DBの説明文も投入されているので、そこから取得してDB一覧を描画できる
- https://integbio.jp/dbcatalog/record/nbdc02559
- https://integbio.jp/rdf/sparql
```
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX db: <http://purl.jp/bio/03/dbcatalog/>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix dcat: <http://www.w3.org/ns/dcat#>
SELECT ?id ?db_name_ja ?description_ja ?organization_label_ja
FROM <http://rdf.integbio.jp/dataset/dbcatalog/main>
WHERE
{
values ?db {db:nbdc01099}
?db a dcat:Dataset ;
dcterms:identifier ?id ;
dcterms:title ?db_name_ja ;
dcterms:description ?description_ja ;
dcterms:publisher / rdfs:label ?organization_label_ja .
FILTER (lang(?db_name_ja) = "ja" )
FILTER (lang(?description_ja) = "ja" )
FILTER (lang(?organization_label_ja) = "ja" )
}
```
- APIエンドポイントへのリクエストには、DBの名前が含まれる見込み。よって、ドット(.)が含まれてしまうとURLと相性が悪いので、 config/db.1-db.2 を config/db_1-db_2 にする
- 次回 3/17(水) 14:00 - 操作可能な開発環境をご共有予定
# 2021/02/22
- ローンチ後のデータ更新フロー
- http://ep6.dbcls.jp/togoid/link/ 配下のTSVやyamlが実際にサービスに投入する予定のディレクトリ。ただし、あくまでワークディレクトリ
- 月イチ更新のような定期パターン
- config.yamlの更新頻度パラメータを参照
- 失敗を検出して通知したいけど、失敗の定義が難しい
- 正規表現によるTSVのバリデーション？
- 自動でプロダクトDBに反映してしまうと、失敗したときに変なデータが入ってしまう。更新のたびに更新対象のテーブルを単体でダンプ取って、ロールバックできるような仕組みが可能か
- LinkDBはデータベースを使用せず、ファイル単位でIDのペアを管理している
- 任意のタイミング
- 基本は定期的な入れ替えだが、コマンドラインででも、人間が手動で任意ののテーブルを差し替えられる方法は必要
- config.yamlの更新であれば、GithubにコミットされるのでAction hook等で更新をかけられるかも
- AWS側でまるっとスナップショットを継続的に取ってしまって、ロールバックはAWSのコンパネ側で担保してしまうというアイディア
- 全てをロールバックしてしまうと、更新に失敗したDB以外も巻き戻ってしまう問題がある
-
- 掲載しているデータベースの一覧画面
- NDBCのデータベースカタログを活用してデータベースの説明文を取得したい
- 信定さんに相談
- typeに（Gene等）ついても、整備してアイコン表示等に活用したい
- 次回: 2021年3月8日(月)13時から
# 2021/02/09
- 実装はRDB?
- スペックはどれくらいを想定?
-
- ペアのファイルを追加中(DBCLS作業)
- http://ep6.dbcls.jp/togoid/link/
- https://github.com/dbcls/togoid-config に設定ファイルとペアのファイル(デモ版)を追加中
-
- config.yaml
- 各labelをGUIに使用する
- forward, reverseは（label以外は）RDFにしたときに意味がある
- A→Bの変換において、まずはA→Bのtsvの左から右
- APIにはNホップまとめて指定したい
- 次回: 2021年2月22日(月)15時から
# 2021/01/28
- クエリの投入上限
- 100件?(伊藤さん)
- 4000件くらいいけるのでは?(守屋さん調査)
- IDとURlの違い?
- エクスポートCSVには、変換ホップの中間のIDリストも出力したい
- 変換に使用したDB→述語→DB→述語のチェーンは、現時点では変換ごとに共通になるので、繰り返しテーブルに表示する必要がない。CSVの見出し行に示せれば良いのでは
- 変換に使用した述語をCSVに出力する必要があるかは迷うところがある
- IDを返却するか、URIを返却するかのオプションは準備したい
- 述語が見たいのなら、むしろSPARQLクエリを見せたほうが良いのでは
- DB間のIDの関係性をつなぐ述語は、基本的には単一にできるのでは、アプリ側は、DBごとの間がどの述語でつながっているかを設定で持っているべきで、そうでなければSPARQLが書けないだろう（片山様）
- 参考 https://togoid.dbcls.jp/resolver#chembl.compound:knapsack:lipidbank
- 一旦はID変換にはrdfs:seeAlsoでRDF上はつないでしまう。AとBの変換がhasVariantなのか、hasProteinなのかはアプリ側で設定ファイルとして持ってしまい、現時点ではRDFでは表現しない。
- DBペアのフォーマットテンプレの議論
- 設定ファイルとIDペア対応ファイルを用意する
- 設定ファイルの中に、書くものを決める
-
- DB Aと DB B のIDが書かれた TSV or CSV
- YAMLで設定ファイル書く
```config.yaml
left:
prefix:
right:
prefix:
property: rdfs:seeAlso
file:
- id_pair_1.tsv
- id_pair_2.tsv
- id_pair_3.tsv
```
- 次回: 2/9 11時から
# 2021/01/27
1. ep6に格納するIDのペアのファイルフォーマットについて
- どちらにする？あるいは両方可？あるいは別のフォーマットも可？
- turtle
- （例）uniprot:P56218 rdfs:seeAlso chembl:CHEMBL4857 .
- csv/tsv
- （例）uniprot, chembl #1行目はヘッダとしてデータ名（これも決める必要あり）を記入
P56218, CHEMBL4857
2. IDフォーマット（１との兼ね合いで決まるかも）
- URIで記載（プレフィックス使用可）
- （例） uniprot:P56218
- IDのみ記載
- （例） P56218
3. ID情報取得の方法
- ダイナミック
- 検索される度にsparql+スクリプトを動かして取得
- スタティック
- システム内にID情報を保存
- 定期的にID情報ファイルを読み込んで更新
# 2021/01/25
- TogoIDで変換するDBペアの状況確認をしました(高月･池田･小野)
- データの優先度
1. 既にデータがRDF形式になっている物 + http://ep6.dbcls.jp/togoid/link/ に収納済みかどうか
2. 遺伝子関連情報（俯瞰ビューのサンプルとするデータ）
- TODO
- 書き込まれたデータに関して、実態の確認を行う
- データを確認した各担当者に、レビューの内容を確認し、問題点の吸い上げを行う
- （データの作成元、更新頻度等も把握しておく必要がある。）
- 実際にSPARQLを叩いて、データがきちんと取れるのかを確認
- EP6に既にデータがあるものは除外
- 今後の課題
- データの更新やメンテナンスをどうするのか？
# 2021/1/15 議事録
- http://ep6.dbcls.jp/togoid/link/ にDB to DBのID対応付RDFを順次格納している
- あるDB上のID <http://rdf.ebi.ac.uk/resource/ensembl/ENSG00000006634> があったときに、まずそれがidentifiers.org上のどのURIと一致するのかがのsameAs的なトリプルを用意したほうが良さそう。そのうえで、seeAlso的なID変換を表現するトリプルを追加していくことが好ましい
- ユースケース、ペルソナ https://hackmd.io/ONtAnIaIQcejn_sGw2Tt1Q?view
- 随時追記、また他のユースケースも書いていきます(おの)
- データベースカタログの参考 http://biodb.jp/
# 2021/1/8 議事録
## 新togoID 開発MTG
- ユースケースとして、100のIDリストを投入されたとき、それは基本的に単一のデータベースのID群とみなしてよいか
- 基本的には、複数のデータベースのIDが混在しているリストを持つことは、ほぼ無いと思う（小野さん）
- ★インプットのIDリストは単一のDBとみなして良い
- 80%のユーザーは、とにかくスムーズにID変換して結果だけを得たい。変換の根拠に興味を持つのは残り2割（小野さん）
- インプットのIDリストから推測されるDBが複数あったとき、その一覧をわかりやすく確認できると良い。ただし、実際に変換を行う始点とするのは単一のDBで良い。複数のDB候補を同時に変換する必要はない
- 1つのIDが、あるDBにおいては複数のIDに変換されるケースもある
- DBの分類を示す背景色は容易に差し替え可能にする
- 遺伝子のデータベースなのか、生物のデータベースなのか、などの分類を示すにあたってはアイコンも有ると良さそう
- 自由に使えるアイコン https://togotv.dbcls.jp/pics.html
- 変換後のIDを利用するサービスに移行する機能は、今年度の範囲ではtogoサイトのみを想定する
- インプットのIDはqname形式の場合もある
- hgnc:11111 はIDだけど、PDF:3abcのようにコロン以前をqnameとみなして記述する慣例もある。qname形式で来ることも想定したい（川島さん）
- 入力されたIDと思われる文字列について、まずはIDとみなして正規表現でDBを特定する。次に。コロン以前を取り除いた文字列でも正規表現でDBを特定する
- seeAlso以外のID変換の根拠になる述語について、DBCLS様で検討中。RDFの記述と投入までを行っていただく想定
- ID変換後のアウトプットには、大まかに下記
- 単一のDBに変換した結果のシンプルなIDリストのテキスト
- from - toがわかるCSV
- IDリストをtogoサイトで使えるURLに変換したリスト
- 次回 1/15(金) 13:00
2020/12/23 議事録
# 新togoID 開発MTG
## Slackでの議論まとめ
### ID Navigator
- https://docs.google.com/spreadsheets/d/16I2HJCpDBeoencNmzfW576q73LIciTMZOCrD7PjtXS4/edit#gid=165008900
のC列の正規表現ベースでIDの類推を行いつつ、どのデータベースを優先して特定するかの順位付けは別途必要そう
### ID Converter
- NCBI Gene, RefSeq, Ensembl Gene, HGNC の5つはHGNCのRDFを使ってID変換可能
- Affymetrixへの変換はRefExの公開しているAffyとNCBI Geneの対応表を使ってID変換可能
- それ以外に変換可能なDB間の関係性は、別途追加検討
### IDマトリックスに入れる、IDの正規表現
- identifiers.orgからパターンをバルクで取得し、Googleスプレッドシートのlookup関数で流し込み(山本さん)
- 正規表現が得られなかったものは手動で入力(片山さん、小野、ほぼ済)
### IDの推測におけるデータベースの優先度設定等の必要性について
- 現togoIDのID Resolverではpublic/dbmapping.json を用いてDBの関係性を展開している。
- (片山さん)dbmapping.json にあるDB間の関係は、おそらく手作業で作ったんじゃないかと思います。今回↑のシートのマトリックスから関係する部分（oがついているもののうち、TogoIDに収録が完了したもの）を用いて作り直す必要があります。データの持ち方も変更していただいても構いません。
- (片山さん)C列の正規表現での推測はデータベースが増えてくると対応出来ないものが増えてきます（数字だけのIDなど）ので、自動推測出来ない場合は重要度に応じてどのデータベースを優先するかといったルール作りが必要になります。
## 議事
- togo var https://togovar.biosciencedbc.jp/ みたいに、サンプルのクエリを見せておきたい
- そもそもNavigator、Conterter、Resolverを一体化できるのでは
- 現togogenomeのRDFデータベースは、基本的にidentifiers.orgのURIを使うように推奨している
- http://dev.togogenome.org/sparql-app?default-graph-uri=&query=select+*+where+%7B%3Chttp%3A%2F%2Fidentifiers.org%2Fncbigene%2F1012%3E+%3Fp+%3Fo+%7D&format=text%2Fhtml&timeout=0&debug=on
- 現状では、ID変換ルールはrdfs:seeAlsoになってしまう。将来的には、もう少し厳密な意味付けをしたプロパティを使いたい
- seeAlsoのobjectのrdfs:typeによって、ある程度ID変換結果の意味づけができるかも
- https://integbio.jp/rdf/dataset/refex を使ってID変換することも可能だが、今年度の範囲では現togogenomeのRDFデータベースのseeAlsoに依存したID変換で良いだろう
# DBCLS 宿題
- 今年度開発でTogoIDに載せるDBの選定
- DBのIDのペアのD列を完成させる
- RDFでとれるものはなるべく対応
- 2項関係の表を作れるものもなるべくとりたい
- DB間の関係についてのクラスの定義
- 正規表現で推測できないIDの調査と、優先度の指定
- 全部出したらよくね?
- どんな種類のDBか分かれば人間は良さそう、APIはどうする?
-
- UI開発のための想定ユーザ・利用例を文章化
- ふらっと来た人、resolver使う人
- http://david.ncifcrf.gov/tools.jsp
- 数百、数千のIDをペタっと貼って使うケースが多い
# すすめかた
- 2021/1/15(金) 13:00
- 以降は、何らかの周期で定例化
2020/11/13 議事録, 11/27 仕様書修正・議事録
# TogoID 仕様書会議
##
「TogoID v2」に関する開発仕様書
1. 目的
本仕様書は、大学共同利用機関法人情報・システム研究機構(以下「機構」という。) ライフサイエンス統合データベースセンター (以下「DBCLS」という。) の「統合データベースにおける基盤技術開発とデータベース運用に係る共同研究」において必要とされるソフトウェアの開発に関するものである。
DBCLSではこれまでの共同研究で様々なデータベースをResource Description Framework（RDF）で表現するRDF化の作業を進め、RDF Portalを始めとして様々な形で公開してきた。また、DBCLSでは、RDF化したデータベースのID情報を簡易に変換するサービスとして、「TogoID(https://togoid.dbcls.jp/)」を公開している。しかしながら、現行のTogoIDでは、入力となる変換できるIDが5種類のみとなっているほか、変換後の遷移先サービスもDBCLS提供サービスのみの留まっているなど、試験公開的な内容となっている。一方で、NBDC/DBCLS全体の課題として、RDFデータをフル活用したポータルサイト「Togoサイト(仮称)」の構築を進めており、それに資するデータベースID間の変換および連携、更新体制の構築などのバックエンドを担うサービスが必要になっている。
そこで本案件では、既存の「TogoID」サービスを改修し、多くの生命科学系データベースのIDを入力として、他のデータベースに対応する変換可能なIDを提示し変換するサービスを開発する。また、TogoIDのID変換・更新機能を充実させることにより、別途開発中の「Togoサイト(仮称)」で提供予定のRDFデータの俯瞰ビューを実現するためのバックエンドとして機能するよう開発する。
2. システム詳細
TogoIDシステムに含まれる機能として次に掲げる事項を開発する。変換可能なIDの組み合わせについては、ライフサイエンス統合データベースセンターが提供する。
2.1 現行のTogoIDのウェブサイトのリファクタリング
* ユーザがIDを入力もしくはファイルアップロードする機能
* 入力はweb formでのテキスト入力, file upload (フラットファイル、形式は要相談), API (JSONをPOSTする) を想定する
* 入力されたIDのデータベースを自動判定する機能（オプショナル)
* 無効なIDが入力された場合は可能な限り正規化する（全角半角の違いの吸収、空白、記号の有無の吸収など）
* 変換先のDBを指定する機能
* 入力から変換可能な他のデータベースを提示する
* DB間の関係性を定義したトリプルから変換の意味をUIに反映させる
* 変換後のIDをダウンロードする機能
* 変換後にそのIDを利用するサービスへ移行する機能
* 変換後のID(リスト)を利用して遷移可能な他のDBを列挙する
* （2.5で対応したDBをSend toの先のサービスとして登録する機能）
* ウェブサイトのユーザーインターフェースの改良
2.2 変換後のIDの返却フォーマットの策定
* 変換結果のIDを返却する
* csv, json, sparql-result+json
* 変換後のIDだけ
* 変換後のURIだけ
* 変換後のIDとURI
* 変換元、変換後のIDとURI
* 変換元、途中経過ID、変換後のIDとURI
2.3 ID 変換 API の開発
* 入出力の詳細はOpenAPIに従う仕様として明記し、Swagger UIを用いたウェブページで確認できるようにする。
* IDが列挙されたデータを受け取る
* from DB (auto)
* to DB
* format (content-type negotiation)
* 2.2 で策定した指定されたフォーマットで結果を返却する
2.4 そのIDを取りうるURIのリストに変換
例：http://identifiers.org/taxonomy
* 入力 9606 （ヒト)
* 出力
* https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?mode=Info&id=9606
* http://purl.bioontology.org/ontology/NCBITAXON/9606
* https://www.ebi.ac.uk/ena/data/view/Taxon:9606
* https://www.ebi.ac.uk/ols/ontologies/ncbitaxon/terms?short_form=NCBITaxon_9606
* https://purl.uniprot.org/taxonomy/9606
* https://bio2rdf.org/taxonomy:9606
* http://togogenome.org/organism/9606
* :
2.5 ID変換した結果を返すページ遷移機能の開発
ウェブアプリケーション（例：Togoサイト）からTogoIDのUIに変換後のDB名および、任意のパラメータ（例：key=0a85a7b2689d15337232d978753df73b)と返却先URLとつきで遷移し、TogoIDにIDリストを入力またはアップロードし、変換後のIDをもともと渡された任意のパラメータつきで返却する機能を開発する。
（イメージ→http://togoid.dbcls.jp/api/convert?target_db=uniprot&format=CSV|JSON|...(&method=GET|POST)&return_to=http://togosite.org/return=）
2.6 変換IDペアの追加更新機能の開発
DB1とDB2のIDペア（TSVなど）およびメタデータ（DB名や関係をおよび更新日などの情報を記述したYAMLなど）のファイルを入力として、RDFを生成し、検索対象のトリプルストアで運用する機能を開発する。
3. 稼働環境
（1）動作オペレーションシステム：アプリケーションが実行されるウェブブラウザは開発時における最新の安定版で、Google Chrome、Firefox、Safari、Microsoft Edgeとする。
（2）ソフトウェア開発言語：JavaScript, SPARQL
（3）動作システム環境：CPU：インテル Core i7/主記憶：32GB以上、メモリ：64GB、SSD・ハードディスク：1TB以上
なお、構築に必要な検証環境は受託者が用意すること。
4. 納入期日
いつくらいかは相談する。
1月だと：令和3年1月29日（金）
2月だと：令和3年2月26日（金）
3月だと：令和3年3月26日（金）←多分これ
5. 納入形態
納入するシステムに関しては、すべて発注者指定のコンピューターシステムにインストールした状態をもって納入とする。
6. 納入場所
納品物：ライフサイエンス統合データベースセンター
〒277-0871 千葉県柏市若柴178-4-4
東京大学柏の葉キャンパス 駅前サテライト6階
プログラム：本機構指定の機器にインストールすること
7. 納入物品
（1）プログラム一式（電子媒体、GitHubに置く、及びコンピューターシステムへのインストール）
（2）システム利用者向けドキュメント.md（githubのREADME的な粒度）
8. 検収方法
開発したシステムが仕様を満たし、本機構指定の稼働環境で正常に動作することを確認し、検収とする。ドキュメント類は内容を確認して検収とする。
9. 保証条件
保証期間：検収後12ヶ月
10. 留意事項
（１）仕様書について不明な点は、本機構と協議し、その指示に従うこと。
（２）担当者の資質
本仕様書に記述するシステム開発の能力を有していること。
（３）成果の帰属
本作業により得られた全ての成果及び著作権物の知的所有権は本機構（大学共同利用機関法人 情報・システム研究機構）に帰属するものとする。
（４）秘密の保持
受注者及びその業務従事者は、本作業の遂行に際して知りえたデータ、知見、成果等の一部または全部を第三者に漏らさないこと。
また、他の目的に使用しないこと。
（５）情報の適切な管理
納入物およびシステムをインストールした機器に不要な個人情報を記載しないこと（本開発では個人情報は取り扱わない）。また、開発時および納入時の機器においては他人に容易に推測されるようなパスワードを用いないなど情報漏洩等の事故に十分に留意すること。
以上
## メモ
- 現行の https://togoid.dbcls.jp/
- 不満
- 既存サービスの機能を切り出しただけの状態
- 対象のDBが少ない
- パフォーマンスが悪い
- 動かないとこがある
- ID resolver 死んでる
- IDの更新どうするのか決まってない
- いいとこ
- ガワがよくデザインされている => 引き継ぐのは実装コスト的にさしあたり現実的でなさそう？
- 新バージョンではどうやってID変換を実装する？
- plan A: redis/ESとかにぶちこむ
- pros パフォーマンス出る
- cons 更新が必要
- plan B: NBDC RDF Portal
- pros: javascriptだけでSPA化できる、モジュール化の夢が膨らむ
- cons: パフォーマンスが微妙な可能性ある
- 片山さんコメント(2020/11/13)
- どうやってIDのペアを追加したり、更新管理するのか
- IDとIDの対応が書かれたファイルが送られてきてTogoIDに載せてください、と言われたときにどうやってRDF化して取り込むか、次回以降の更新を同自動化するか（対応関係のセマンティクスづけは初回にマニュアルで行うとして）
- ID と ID の間の関係（セマンティクス）をどのようにナビゲートするのか
- 現状rdfs:seeAlsoをたどるのがほとんどだと思いますが、遺伝子IDから医薬品のIDでも何でもいいですけど、数ステップ辿っていくときに途中で経由する過程でどういう意味の扱いになるのかを意識できるシステムになっているとよいと思います（遺伝子→ゲノム→生物種→タンパク質リスト→相互作用の相手化合物→そのうちの医薬品、とか辿っても「遺伝子→ゲノム」の時点で意味なくなってる、とかとか）。
- 現状のTogoIDのID converter/resolverは可能なパスが全部出るだけなのですが、shortest pathが一番いいのかどうか・複数ある場合はどうするのかも含めて、変換サービスとしてはちゃんと考えたほうがいい
などなど、いろいろな要件が抜けている
2020/10/28 議事録
# TogoID ブレスト
### 検討している仕様
- IDを入力として、変換可能なIDを提示し、変換する
- 複数のIDリストを入力として、変換可能なIDを提示し、変換する
- 変換したID(リスト)を検索クエリとして、任意のサービスに飛ばす
- 変換したID(リスト)を使って、利用可能な他のDBを列挙する
- 研究分野、実験手法別など(例えばトランスクリプトーム、プロテオーム、メタボローム等)の分類をわかりやすく表示する
- 入力されたIDを受け付ける外部サービスをサジェストしてくれる機能
- TogoサイトからユーザがIDセットをアップロードする際にTogoIDに一旦遷移して変換後に戻ってくる仕組み
### 検討事項
- リソース間のequivalentな関係に限らず、"AはBに使われている"のような関係も変換ルールに含めたい
- "AはBに使われている"のような関係はキュレーションに近い。これはDBCLSの皆様に定義いただく必要がある
- 構築中の"Togoサイト"で充実した検索機能を提供したい。TogoidはID変換+α
- Togoサイトでは、例えばネットワークグラフのような検索結果の可視化も検討中
- ライフサイエンスの分野では、同一のリソースに対して複数のURIが割り当てられ、運用されてしまっている現状がある
- 純粋なsameAsのID変換と、キュレーション的なID変換は対象とする利用ケースが異なりそう
- 二項関係の述語に相当するものに、どんな関係性を用意するかはDBCLSで検討予定
- リソースごとの特殊な状況や例外的なケースなどを利用者に補足情報として提供できると好ましい
- 検索結果のCSVダウンロード
- togoサイトは1月にα版リリース。でも、年度内にちゃんとリリースできるか怪しい
- 検索のホップ数
- 利用例としては、そんなにホップ数が大きくなることはない。2-3ホップできれば良さそう？
- ただし、それぞれの変換のコンテキストを示す必要がある。どこからどこにつながったかのプロパティパス
- 検索結果のコンテキストはしっかりアピールしたい（プロパティパス）
- アカウントの必要性
- 検索履歴？
- マイプロフィールで分野を絞っておく
- 手作業で作るsameAsのトリプル数、キュレーション用の述語におけるトリプル数
- 58のDBが列挙されており、単純計算では58 x 58の関係
- DB間のIDを機械的に変換するルールを定める。完全ではないけど、概ねカバーできる？
- 機械的に変換して得られたIDが、本当に参照できるか、存在しているかは要検証
- キュレーション用のプロパティは数十から数百？
### 参考情報
- togoid https://togoid.dbcls.jp のクエリ例 1012,11034,11078,1094
- http://identifiers.org/
- https://registry.identifiers.org/registry/ncbigene
- https://www.genome.jp/linkdb/
- https://www.uniprot.org/uniprot/?query=yourlist:M20201028216DA2B77BFBD2E6699CA9B6D1C41EB2025E72E&sort=yourlist:M20201028216DA2B77BFBD2E6699CA9B6D1C41EB2025E72E&columns=yourlist(M20201028216DA2B77BFBD2E6699CA9B6D1C41EB2025E72E),id,entry%20name,reviewed,protein%20names,genes,organism,length
以下、以前いただいたメッセージの引用
様々なデータベースにおいて、たとえば遺伝子であれば、各遺伝子に対してIDが振られていますが、同じ遺伝子を、他のデータベースでは異なるIDで表現している場合、それらを適宜変換すること。
および、更に一歩進んで、ある遺伝子があったときに、その遺伝子から作られるタンパク質のIDが得られること。
これらについてお開発を願いすることになりそうです。
ID間のペアはこちらで用意します。
現状で58のDBが列挙されており、単純計算では58 x 58の関係があり得るわけですが、実際にはかなり疎なのでペア数はそこまで多くはありません。
明示的にDBとIDのセットが与えられるか、IDだけ与えられて関連するDBを推定するか、そして、出力としてペアの相手方を列挙する、という仕様かな、というところです。
もちろん、今度のブレストで変わりうることもあると思います。
参加人数はもっと増えるかもしれません。
以上、現状のご報告です。
よろしくお願いいたします。
これは以前私が参加した会議で撮影したものですが、ここに描かれているように、たとえば、Proteinに関するDBにも幾つかあり、それぞれがID体系をもっています。そこで、その間で同じタンパク質を示すIDペアが作れます。さらに、ProteinとMoleculeとの間にもIDのペアを作れます。これは、直接DBに参照先のDBのIDが書かれている場合が多いので、それをまずは取得してペアとします。
このようなペアを私たちで用意します。
2020/10/22 議事録
# TogoID 開発
- https://togoid.dbcls.jp/
- https://github.com/dbcls/togoid
## 戦略
### 提供する価値
- 生命科学研究するときに必要になるさまざまなIDを利用者の求めるIDに変換する
- 一般に、利用者はIDをただ変換したいだけではないので、自分の持っているIDでは直接利用することができないサービスへの導線を用意する
- アクセスした時点で常にアップデートされた最新のIDを入手できる
- RDFのリンク情報が元DBになかったり、URI違いだった場合の補完
- IDの対応関係を管理・利用したいサードパーティのグループに対するサービス提供 (LINCなど)
-
- Togoサイトがうまく行かなかったときのプランB
## 要件
### 外注
- IDを入力として、変換可能なIDを提示し、変換する
- 複数のIDリストを入力として、変換可能なIDを提示し、変換する
- 変換したID(リスト)を検索クエリとして、任意のサービスに飛ばす
- TogoサイトなどNBDC/DBCLSのサービスへの誘導
- EBI/NCBIなどの主要サービスへも誘導？
- 変換したID(リスト)を使って、利用可能な他のDBを列挙する
- 研究分野、実験手法別など(例えばトランスクリプトーム、プロテオーム、メタボローム等)の分類をわかりやすく表示する
- 入力されたIDを受け付ける外部サービスをサジェストしてくれる機能
- TogoサイトからユーザがIDセットをアップロードする際にTogoIDに一旦遷移して変換後に戻ってくる仕組み
-
### 内製
- 変換可能なIDのリンク情報を常にアップデートする
- 現状のEdgeStoreの管理運用をTogoIDに移管し、担当者がきちんと定期的にデータ更新する (TogoGenomeに入っているデータを別エンドポイントにして運用)
- スプレッドシートで今使えるIDの対応関係を書き出す
DB 関係 こちらはとりあえずペンディング
- Togoサイトを念頭に重要なものを先にマニュアルで整理
- TogoIDでID変換するDBペアごとの情報
入力
現状: Affy, RefSeq, Gene ID, Ensembl, HGNC
追加: PubMed, プププローブ, …
TogoID
コンバートするDBペアごとに↓の項目を整理
例: Affy - Gene
どこから入手？
データフォーマット
URL prefix
更新頻度
関係の意味 (semantics)
出口
Send to: Gendoo, GGRNA, RefEx, Chip-Atlas
追加: Togoサイト, PubCaseFinder, …
Togoサイトが受け付けたいID
Gene ID, Protein, PDB, Disease, Variant, Reaction 等
+ Compound, Drug
さらに追加していくもの
自動で取れそうなペア: RDFに内在するリンク
委託されるペア: LINCなど
要相談: KEGGなど
参考(バリデーションにも): Chris MのBiolink
## メインターゲット
- 実験系生命科学研究者?
## 構造
- スキーマ図を書く
## 骨格
- 導線設計
## 表層
- グラフィックデザイン
## 発注予定業者
- [インフォ・ラウンジ株式会社](https://info-lounge.jp/company)
- 山本さんの紹介
- [JSON2LD Mapper](https://json2ld.mapper.tokyo/) の開発を担当
## 凍結リストより抜粋
- RDF化するデータ・DB
- 全てのRDFデータセット間のリンク情報
- そのRDFがいつまでにできるか
- Togoサイト立ち上げまでには必須、開発体制は白紙
- Togoサイトへの寄与の仕方
- データセット間を複合的に検索する基盤およびユーザが持つIDからのTogoサイトとNBDC/DBCLSのサービスへの誘導
- RDF化することによって関係してくる他のツールやDB（DBCLS以外のツールやDBも含む）
- 全RDFデータ、各種DBCLSのサービス、およびLINC(https://linc-ai.jp/)など協力依頼を頂いているプロジェクト
- 2021年度末（2022年3月）時点の到達目標（応用との位置付けについても含める）
- 今年度のTogoサイトで使われる全データベース間のリンクで不足している情報を補完、更新担当体制の構築、（ポスト）LINCとの連携
## おまけ
https://github.com/btoews/Google-Docs-Markdown
http://identifiers.org/
https://registry.identifiers.org/registry/ncbigene
https://www.genome.jp/linkdb/
https://www.uniprot.org/uploadlists/
Google Drive
Gist
Clipboard
Sign in with Wallet
